get.dexma.com Deliverables/D8_3.pdf · WP8 Project management D.8.3 MANAGEMENT REPORT (SECOND YEAR)...

This project has received funding from the European

Union’s Horizon 2020 research and innovation

programme under grant agreement No 768619

D8.3 Management report (2nd

year)

The RESPOND Consortium 2019

Integrated Demand REsponse

SOlution Towards Energy

POsitive NeighbourhooDs

WP 8: Project management

T8.2: Project management and EC reporting

Ref. Ares(2019)7362792 - 29/11/2019

WP8 Project management

D.8.3 MANAGEMENT REPORT (SECOND YEAR)

2 | 155

PROJECT ACRONYM RESPOND

DOCUMENT D8.3 Management report (second year)

TYPE (DISTRIBUTION LEVEL) ☐ Public

☐ Confidential

☐ Restricted

DELIVERY DUE DATE 30/11/2019

DATE OF DELIVERY 29/11/2019

STATUS AND VERSION v1.0

DELIVERABLE RESPONSIBLE FEN

AUTHOR (S) Antonio Colino (FEN), Rodrigo López (FEN),

Agustina Yara (FEN); Francisco Diez (TEK), Iker

Esnaola (TEK); Nikola Tomasevic (IMP), Lazar

Berbakov (IMP); Toke H. Christensen (AAU);

Henrik N. Knudsen (AAU), Laura Martinez

(DEXMA), Andreu Pagès (DEXMA), Federico Seri

(NUIG).

OFFICIAL REVIEWER(S) N/A



3 | 155

DOCUMENT HISTORY

ISSUE DATE CONTENT AND CHANGES

v0.0 14/09/2019 Draft version - Table of Contents

v0.1 20/11/2019 First version

v0.2 28/11/2019 Reviewed version

v1.0 29/11/2019 Final version



4 | 155

EXECUTIVE SUMMARY

This report constitutes the Deliverable 8.3 Management report (second year). The document has been elaborated by FENÍE ENERGÍA SA, responsible partner for WP8 Project management and Project Coordinator within the RESPOND project. The purpose of this document is to report the activities carried out during the reporting period M13-M24 (October 2018-September 2019).

The present management report (second year) focuses on the description of the current status of

activities, objectives, impact, main results, work progress and achievements for all tasks

scheduled for the reporting period. Complete description of finished tasks and open tasks,

significant results of all tasks, deviation and corrective actions within tasks.

Also, the RESPOND project management report contains an overview of the project meetings,

meetings attendance statistics, description of the project issues founds, amendments to the

agreements, risk assessment, dissemination activities report (website and blog posts,

publications, events, workshops and television broadcast).

Furthermore, it is presented a list of deliverables submitted and milestones achieved. Moreover,

it is reported the use of resources for the period, detailing the costs and efforts per WPs and per

partners. Finally, conclusions are presented.



5 | 155

TABLE OF CONTENTS

1. INTRODUCTION ............................................................................................................................... 12

2. MANAGEMENT REPORT (SECOND YEAR) .............................................................................. 13

2.1 CURRENT STATUS .................................................................................................................. 13

2.2 OBJECTIVES .............................................................................................................................. 15

2.3 IMPACT........................................................................................................................................ 16

2.4 MAIN RESULTS ......................................................................................................................... 18

2.5 WORK PROGRESS AND ACHIEVEMENTS ........................................................................ 29

2.5.1 WP1: PILOT SITE CHARACTERIZATION ..................................................................... 29

2.5.2 WP2: USE CASE DEPLOYMENT AND FOLLOW-UP ................................................. 33

2.5.3 WP3: USER ENGAGEMNET PROCESS ....................................................................... 41

2.5.4 WP4: ICT ENABLED COOPERATIVE DEMAND RESPONSE MODEL ................... 48

2.5.5 WP5: SYSTEM INTEGRATION AND INTEROPERABILITY ....................................... 77

2.5.6 WP6: VALIDATION AND REPLICATION OF PROJECT RESULTS ......................... 96

2.5.7 WP7: DISSEMINATION AND EXPLOITATION ACTIVITIES ....................................101

2.5.8 WP8: PROJECT MANAGEMENT ..................................................................................112

3. PROJECT MANAGEMENT ...........................................................................................................119

3.1 CONSORTIUM MANAGEMENT TASKS .............................................................................119

3.1.1 PROJECT MEETINGS .....................................................................................................119

3.1.2 PROJECT MEETINGS ATTENDANCE STATISTIC ...................................................125

3.2 PROJECT ISSUES ..................................................................................................................128

3.2.1 AMENDMENTS .................................................................................................................129

3.3 RISK ASSESSMENT ...............................................................................................................130

3.4 MANAGEMENT STRUCTURE ..............................................................................................131

3.4.1 EXTERNAL ADVISORY BOARD (EAB) .......................................................................131

3.5 ADMINISTRATIVE MANAGEMENT TOOLS .......................................................................131

3.6 DISSEMINATION ACTIVITIES ..............................................................................................132

3.6.1 WEBSITE AND BLOG POSTS .......................................................................................132

3.6.2 PUBLICATIONS ................................................................................................................133

3.6.3 EVENTS, WORKSHOPS, TELEVISION .......................................................................135



6 | 155

4. DELIVERABLES AND MILESTONES .........................................................................................140

4.1 DELIVERABLES .......................................................................................................................140

4.2 MILESTONES ...........................................................................................................................144

5. USE OF RESOURCES ..................................................................................................................145

5.1 EFFORTS SUMMARY ............................................................................................................145

5.2 COSTS SUMMARY .................................................................................................................148

6. CONCLUSIONS..................................................................................................................................152



7 | 155

LIST OF FIGURES

FIGURE 1. GENERAL ENERGY FLOW IN AARHUS, MADRID AND ARAN ISLANDS PILOT SITE ........................................................ 19 FIGURE 2. DATA FLOW IN RESPOND CONTROL LOOP .................................................................................................................. 20 FIGURE 3. EXAMPLE OF DATA POINTS LIST TO MAP MADRID DEVICES ....................................................................................... 20 FIGURE 4. QUESTIONNAIRE FOR PROSPECTIVE PILOT PARTICIPANTS ......................................................................................... 21 FIGURE 5. MOBILE APP MOCKUPS ............................................................................................................................................... 21 FIGURE 6. RESPOND ONTOLOGY'S DOCUMENTATION AVAILABLE ONLINE................................................................................. 22 FIGURE 7. OGEMA GATEWAY IN RESPOND .................................................................................................................................. 22 FIGURE 8. SCHEMA OF DATA PROCESS WITHIN RESPOND PROJECT ........................................................................................... 23 FIGURE 9. EXCERPT OF EXCELL COSTS AND EFFORTS BUDGETED VS ACTUAL USE OF RESOURCES ............................................ 23 FIGURE 10. RESPOND PLATFORM ARCHITECTURE ....................................................................................................................... 24 FIGURE 11. TOPICS OVERVIEW TOPICS COVERED BY THE FIVE INDIVIDUAL FOCUS GROUPS AT THE THREE PILOT SITES .......... 24 FIGURE 12. RESPOND OPTIMIZATION LOOP ................................................................................................................................ 25 FIGURE 13. NOTIFICATION TRANSLATION SERVICE WORKFLOW ................................................................................................. 25 FIGURE 14. WEATHER FORECAST API ........................................................................................................................................... 26 FIGURE 15. MQTT BASED PROTOCOL FOR ACTUATOR CONTROL ................................................................................................ 26 FIGURE 16. T5.4 DESKTOP DASHBOARD AND SMART MOBILE CLIENT ........................................................................................ 27 FIGURE 17. INTEGRATION OF THE ADAPTER INTO ENERGOMONITOR BACKEND ....................................................................... 27 FIGURE 18. RESPOND KPIS ........................................................................................................................................................... 28 FIGURE 19. WP1: PILOT SITE CHARACTHERIZATION GANTT CHART ............................................................................................ 29 FIGURE 20. EQUIPMENT AVAILABLE IN ONE OF THE PILOT HOUSES OF ARAN ISLANDS ............................................................. 30 FIGURE 21. DR ACTION EXAMPLE ................................................................................................................................................. 31 FIGURE 22: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP1 DURING THE 2ND YEAR ................................................... 33 FIGURE 23. WP2: USER CASE DEPLOYMENT AND FOLLOW-UP GANTT CHART............................................................................ 33 FIGURE 24. RESPOND’S MEASURE-FORECAST-OPTIMIZE-CONTROL LOOP .................................................................................. 37 FIGURE 25: EXCERPT OF THE EXCEL DATA POINT LIST FILLED BY PEOPLE IN CHARGE OF RESPOND PILOT SITES ....................... 38 FIGURE 26: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP2 DURING THE 2ND YEAR ................................................... 40 FIGURE 27. WP3: USER ENGAGEMENT PROCESS GANTT CHART ................................................................................................. 41 FIGURE 28. MOBILE APP’S NAVIGATION DIAGRAM ..................................................................................................................... 46 FIGURE 29: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP3 DURING THE 2ND YEAR ................................................... 48 FIGURE 30. WP4: ICT ENABLED COOPERATIVE DEMAND RESPONSE GANTT CHART ................................................................... 48 FIGURE 31. MODULES TO BE DEVELOPED IN DIFFERENT TASKS WITHIN WP4 ............................................................................ 49 FIGURE 32: GENERAL STRUCTURE OF THE ENERGY HUB ............................................................................................................. 50 FIGURE 33. THE OPTIMIZATION PROCESS .................................................................................................................................... 51 FIGURE 34. THE OPTIMIZATION PROCESS .................................................................................................................................... 51 FIGURE 35. PRODUCTION FORECAST MODEL SPECIFICATION ..................................................................................................... 53 FIGURE 36. DEMAND FORECAST OF THE USE CASE OFFICE WITH ARIMA ................................................................................... 55 FIGURE 37. POTENTIAL PERFORMANCE OF DIFFERENT SYSTEMS AND COMPONENTS ............................................................... 57 FIGURE 38. RESPOND PLATFORM'S DATA FLOW ......................................................................................................................... 58 FIGURE 39. RESPOND ONTOLOGY'S MAIN CLASSES AND PROPERTIES ........................................................................................ 59 FIGURE 40. DATA POINT LIST EXCERPT ........................................................................................................................................ 59 FIGURE 41 - ENERGY HUB STRUCTURE FOR DIFFERENT USE CASES ............................................................................................ 61 FIGURE 42 - DR LOAD DEVIATION ................................................................................................................................................ 62 FIGURE 43. PREDICTED AND OPTIMIZED LOAD PROFILES ............................................................................................................ 62 FIGURE 44. PREDICTED AND OPTIMIZED LOAD PROFILES ............................................................................................................ 62 FIGURE 45. SIMPLE ONE-HOUSEHOLD SETUP .............................................................................................................................. 63



8 | 155

FIGURE 46. HOMOGENEOUS MULTI-HOUSEHOLD SETUP ........................................................................................................... 64 FIGURE 47. AARHUS PILOT MODEL .............................................................................................................................................. 65 FIGURE 48. ARAN PILOT MODEL .................................................................................................................................................. 65 FIGURE 49. MADRID PILOT MODEL .............................................................................................................................................. 65 FIGURE 50. IMPORTED POWER PROFILES WITH LOAD REDUCTION ............................................................................................ 66

FIGURE 51. AARHUS PV FORCASTER ............................................................................................................................................ 69

FIGURE 52. REAL VS FORECASTED ENERGY CONSUMPTION OF A PREDICTIVE MODEL WITH A GOOD PERFORMANCE ............ 70

FIGURE 53. REAL VS FORECASTED ENERGY CONSUMPTION OF A PREDICTIVE MODEL WITH A BAD PERFORMANCE ................ 70

FIGURE 54. RESIDUALS OF A PREDICTIVE MODEL WITH A GOOD PERFORMANCE. ..................................................................... 70

FIGURE 55. RESIDUALS OF A PREDICTIVE MODEL WITH A BAD PERFORMANCE. ........................................................................ 71

FIGURE 56. FORECASTED VS ACTUAL ELECTRIC CONSUMPTION IN MADRID (NEIGHBOURHOOD LEVEL) .................................. 71

FIGURE 57. HOLISTIC OPTIMIZATION APPROACH ........................................................................................................................ 72

FIGURE 58. ROM MODEL SCHEME ............................................................................................................................................... 73

FIGURE 59: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP4 DURING THE 2ND YEAR ................................................... 77

FIGURE 60: WEATHERBIT.IO JSON FORMAT EXAMPLE ................................................................................................................ 79

FIGURE 61: EMS DASHBOARD INTEGRATION ............................................................................................................................... 81 FIGURE 62 RESPOND PLATFORM ARCHITECTURE ........................................................................................................................ 84 FIGURE 63 APACHE OPENWHISK HIGH LEVEL ARCHITECTURE (SOURCE: CLOUD.IBM.COM) ...................................................... 85 FIGURE 64: RESPOND PLATFORM MODULES DIAGRAM .............................................................................................................. 86 FIGURE 65: HIERARCHICAL TREE OF PILOT SITES IN DEXCELL ...................................................................................................... 87 FIGURE 66: LDAP SERVER FOR RESPOND MOBILE APP'S ACCESS CONTROL. ............................................................................... 90 FIGURE 67: NOTIFICATION FLOW ................................................................................................................................................. 91 FIGURE 68: RESPOND MOBILE APP'S PROXY SERVER. .................................................................................................................. 92 FIGURE 69: RESPOND MOBILE APP'S PUBLICATION IN APP STORE. ............................................................................................ 93 FIGURE 70 DR EVENT DATA FLOW ............................................................................................................................................... 95 FIGURE 71: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP5 DURING THE 2ND YEAR ................................................... 96 FIGURE 72: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP6 DURING THE 2ND YEAR ................................................. 101 FIGURE 73: RESPOND WEB PAGE ............................................................................................................................................... 105 FIGURE 74: RESPOND PUBLIC DELIVARABLES REPOSITORY ....................................................................................................... 106 FIGURE 75: RESPOND PUBLICATIONS SECTION .......................................................................................................................... 106 FIGURE 76: RESPONS ARTICLE EXAMPLE .................................................................................................................................... 106 FIGURE 77: RESPOND WEB ANALYTICS EXAMPLE 1 ................................................................................................................... 108 FIGURE 78: RESPOND WEB ANALYTICS EXAMPLE 2 ................................................................................................................... 108 FIGURE 79: RESPOND WEB ANALYTICS EXAMPLE 3 ................................................................................................................... 109 FIGURE 80: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP7 DURING THE 2ND YEAR ................................................. 112 FIGURE 81: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP8 DURING THE 2ND YEAR ................................................. 118 FIGURE 82: SCREEN SHOT OF RESPOND WEBPAGE: BLOG SECTION.......................................................................................... 133 FIGURE 83: MAGAZINE PUBLICATION ........................................................................................................................................ 134 FIGURE 84: OPEN ACCESS GOVERNMENT PUBLICATION ........................................................................................................... 135 FIGURE 85: RESPOND PROJECT PARTICIPATION AT SUSTAINABLE PLACES 2019 ...................................................................... 136 FIGURE 86: RESPOND PROJECT PARTICIPATION AT LDAC 2019 ................................................................................................. 136 FIGURE 87: EVENTS’ PICTURES: ECEEE SUMMER STUDY 2019, FRANCE .................................................................................... 137 FIGURE 88: RESPOND PROJECT PARTICIPATION AT ETSI IOT 2019 ............................................................................................ 138 FIGURE 89: RESPOND PROJECT PARTICIPATION AT EUROPEAN UTILITY WEEK 2019 ................................................................ 138 FIGURE 90: RESPOND PROJECT FEATURED IN IRISH TV ............................................................................................................. 139 FIGURE 91: TOTAL EFFORTS (ACTUAL AND BUDGET) BY PARTNER IN THE 2ND YEAR ............................................................... 146 FIGURE 92: TOTAL EFFORTS (ACTUAL AND BUDGET) FOR EACH PARTNER IN THE 2ND YEAR................................................... 147 FIGURE 93: TOTAL COSTS (ACTUAL AND BUDGET) BY PARTNER IN THE 2ND YEAR................................................................... 149 FIGURE 94: TOTAL COSTS (ACTUAL AND BUDGET) FOR EACH PARTNER IN THE 2ND YEAR ...................................................... 150 FIGURE 95: TOTAL COSTS (ACTUAL AND BUDGET) FOR EACH TYPE IN THE 2ND YEAR.............................................................. 151



9 | 155

LIST OF TABLES

TABLE 1. RESPOND MILESTONES LIST 13 TABLE 2. RESPOND SPECIFIC OBJECTIVES FOR M13-M24 15 TABLE 3. SUMMARY OF DR ACTIONS PER PILOT SITE 32 TABLE 4. STC PRODUCTION PROTOTYPE RESULTS 54 TABLE 5. OBTAINED MAES FOR DEMAND PREDICTION USING DIFFERENT ALGORITHMS 55 TABLE 6: DEXCELL KPIS 89 TABLE 7: RESPOND STAKEHOLDERS 94 TABLE 8: LIST OF PUBLICATIONS 102 TABLE 9: LIST OF ARTICLES 104 TABLE 10. RESPOND PROJECT LIST OF DELIVERABLES SUBMITTED DURING REPORTED PERIOD M1-M24 140 TABLE 11. RESPOND PROJECT MILESTONES 144 TABLE 12: TOTAL EFFORTS (ACTUAL AND BUDGET) BY PARTNER AND WP IN THE 2ND YEAR 145 TABLE 13: PERCENTAGE OF ACTUAL EFFORTS VS BUDGET BY PARTNER AND WP IN THE 2ND YEAR 145 TABLE 14: TOTAL COSTS (ACTUAL AND BUDGET) BY PARTNER AND TYPE IN THE 2ND YEAR 148 TABLE 15: PERCENTAGE OF ACTUAL COSTS VS BUDGET BY PARTNER AND TYPE IN THE 2ND YEAR 148



10 | 155

ABBREVIATIONS AND ACRONYMS

AAU AALBORG UNIVERSITET

ALBOA ALMEN BOLIGORGANISATION AARHUS

ARAN COMHARCHUMANN FUINNIMH OILEAIN ARANN

TEORANTA

AURA AURA RADGIVNING AS

D Deliverable

DEV DEVELCO PRODUCTS AS

DEXMA DEXMA SENSORS SL

DoA Description of Action

DR Demand Response

e.g. exempli gratia = for example

EAB External Advisory Board

EASME Executive Agency for Small and Medium-sized

Enterprises

EC European Commission

EM Exploitation Manager

EMS Electronics Manufacturing Services

ENE ENERGOMONITOR S.R.O

EU European Union

FEN FENIE ENERGIA S.A.

GA Grant Agreement

GHG Greenhouse Gas

ICT Information and Communication Technology

KPI Key Performance Indicator

IMP INSTITUT MIHAJLO PUPIN



11 | 155

JSON JavaScript Object Notation

iOS iPhone Operative System

IP Internet Protocol

M Month

MQTT Message Queue Telemetry Transport

MS Milestone

NUIG NATIONAL UNIVERSITY OF IRELAND, GALWAY

OpenADR Open Automated Demand Response

PC Project Coordinator

PCC Pilot case Coordinator

PMT Project Management Team

REA Research Executive Agency

RESPOND Integrated Demand REsponse SOlution Towards Energy

POsitive NeighbourhooDs

RV Review

SCADA Supervisory Control and Data Acquisition

SH/SW Software/hardware

ST Steering Committee

TEK FUNDACION TEKNIKER

TL Technical Leaders

UEL User Engagement Leader

WP Work Package

WPL Work package Leader



12 | 155

1. INTRODUCTION

The purpose of this document is to provide a complete report of the activities that have been

performed by the RESPOND project Consortium during the second year of the project.

Full descriptions of the tasks carried out during the reported period (M13-M24) are presented.

The aim has been to comply with the scheduled DoA from the Quality Assurance Plan established

at the beginning of the project.

The present document contains the actions and measures performed in order to guarantee an

administrative, financial risk management and also scientific and technology management of the

project.

In the previous Management report (first year) submitted in M14, the work was focused on the

three pilot’s characterization and deployment (namely Madrid, Aarhus and Aran Islands), also on

finding demand response actions for each of the scenarios, design of the system architecture and

platforms setting up. At the same time, the user engagement process was defined and

progressing.

In the present Management report (second year) submitted in M26, the focus has been still on

user engagement process and final deployment in the three pilots, besides on the development

of all the systems and models that integrate the complexity of RESPOND solution. In this phase,

data collection has been crucial to move forward to an integration and interoperability of all

technical components.

All partners have been contributing from the different backgrounds to the realization of the

scheduled tasks, deadlines and milestones assigned for the period.

The document aims to report the activities performed during the first second year of RESPOND

project, M13-M24 (October 2018-September 2019), from an administrative, risk, financial,

scientific & technologic point of view.



13 | 155

2. MANAGEMENT REPORT (SECOND YEAR)

2.1 CURRENT STATUS

RESPOND project has reached the second year in terms of timing (24 out of 36 months). During this year, the Consortium members worked with the purpose of achieving the phase II, which consists in RESPOND platform integration and advancement, and the beginning of phase III, based on the Project validation and replication.

TABLE 1. RESPOND MILESTONES LIST

Milestone number

Milestone title WP number

Lead beneficiary

Due date (in months)

Means of verification

MS1 Pilots characterization

WP1 FEN 6 Complete pilot descriptions

MS2 First deployment WP2 DEV 12 Early deployment of devices done

MS3 Final deployment WP3, WP4, WP5

TEK 24 Project developments deployed in pilots

MS4 Reporting period midterm

WP6, WP7 DEXMA 30 Midterm of reporting period

MS5 End of pilot demonstration

WP6, WP7, WP8

FEN 34 End of pilot demonstration

During the reporting period, M13-M24, the main goal was the achievement of milestone MS3: Final deployment (M24). Some tasks from WP1, WP2 and WP3 were scheduled to be finished in M12 (September 2018), but it was applied and extra month (approved by the Project Officer) in order to complete the work. Therefore, the following tasks finished in M13 (October 2018):

• WP1 Pilot site characterization:

o T1.4 Demand response actions discovery for each pilot

• WP2 Use case deployment and follow-up:

o T2.2 Seamless integration of RESPOND technology tiers o T2.4 Early deployment at pilot sites

• WP3 User engagement process:



14 | 155

o T3.1 Criteria and framework for participant recruitment o T3.4 Smart mobile client and personal energy performance assistant design

In parallel, the main activities during M13-M24 pivoted around the progress of the following tasks from WP3, WP4, WP5, WP6, WP7:

• WP2 use Case Deployment and follow-up:

o T2.5 Demand response platform deployment

• WP3 User engagement process:

o T3.3 Detailing the user context and improvements of user interaction

• WP4 ICT enabled cooperative demand response model:

o T4.1 Semantic information model o T4.2 Integration of demand response with supply demand side management o T4.3 Optimal energy dispatching at household and neighbourhood level o T4.4 Energy production and demand forecasting o T4.5 Data analytics and optimized control

• WP5 System integration and interoperability:

o T5.1 Home automation interoperability interfaces o T5.2 Smart grid connectivity o T5.3 RESPOND middleware development o T5.4 Integration with desktop dashboard and smart mobile client o T5.5 Data protection and security measures

• WP6 Validation and replication of project results:

o T6.1 Validation methodology and acceptance criteria o T6.2 Validation analysis and reporting o T6.3 Qualitative evaluation of user experience and recommendations o T6.4 Replication plan development

• WP7 Dissemination and exploitation activities:

o T7.2 Products, services and supporting business model definition o T7.3 data life cycle management

In addition, the following tasks have been running since the beginning of the project, in M1, and will continue until the end of the project, in M36:

o T7.1 Dissemination and communication strategy



15 | 155

o T7.6 Contribution to EASME dissemination

o T8.1 Project administration & quality assurance

o T8.2 Project management and EC reporting

In the section 2.5 detailed results and achievements for each work package are presented.

2.2 OBJECTIVES

Overall objectives of RESPOND project:

• Energy costs savings

To deliver an ICT solution for demand response that will result in energy reduction of about 10% and economic cost savings of at least 20% in residential sector by adapting the user behavior to maximize the exploitation of renewable sources.

• Integrated solution for demand response

To design, construct, deploy and validate a system that is able to integrate with any building SW/HW system in relation to energy and comfort, while supporting and facilitating the end user to understand and directly engage with DR activities.

• Integral business model

To design, apply and validate a business model and exploitation plan for a large-scale uptake of the ICT system deployed and integrated in the RESPOND project.

Work package specific objectives for the second year of RESPOND project are shown in table 2:

TABLE 2. RESPOND SPECIFIC OBJECTIVES FOR M13-M24

Specific Objectives for reported period M13-M24

WP OBJECTIVES ACHIEVEMENTS

WP1 Pilot site characterization Successful submission of D1.4 in M13

WP2 Use case deployment and follow-up Successful submission of D2.2 and D2.4 in M13 and D2.5 in M24



16 | 155

WP3 User engagement process

Successful submission of D3.1 and D3.4 in M13 and D3.3 in M24

WP4 ICT enabled cooperative demand response model

Successful submission of D4.1 in M18 and D4.2, D4.3 in M24

WP5 System Integration and Interoperability Successful submission of D5.1 in M18 and D5.2, D5.3, D5.4, D5.5 in M24

WP6 Validation and Replication of Project Results D6.1 was delayed and submitted in M26 instead of M24 because additional time for

baseline checking WP7 Dissemination and Exploitation Activities Successful submission of D7.4 in M18

WP8 Project management Successful preparation of Official Periodic Report M1-M18, the submission was delayed

because of amendment process opened

2.3 IMPACT

The project aims to address each of the expected impacts started by EE-12-2017, which sets the specific challenge in terms of integrating the demand response enabling elements into Energy Management Systems (EMS) and achieving full interoperability between smart grids, energy systems and smart home devices. The table 3 shows how RESPOND will contribute to each of the impacts expected by the call.



17 | 155

TABLE 3. RESPOND IMPACT

Besides the expected impacts mentioned by the work program, the proposal aims to make the following additional impacts:

• Contribution to Europe’s Energy Security RESPOND will have a direct impact not only on the financial (e.g. minimizing costs of energy dispatching, and influencing at energy prices as previously stated), but also on the environmental aspect of energy market (e.g. by lowering GHG emissions).



18 | 155

• Generates skilled job opportunities

District energy systems contribute to employment opportunities, ranging from system design, construction, equipment manufacturing, to the operation and maintenance.

• Promotion of cooperative movement

Cooperative movement consist in the association of people to get common objectives by collaboration of everybody involved.

An example of this type of movement is one of the project partners, Aran Islands (ARAN), that thanks to the cooperative association projects increased significantly the use of sustainable energy sources as compared to 2008.

• Open data use

Performance can be improved, which contributes to enhancing the efficiency of public services. Owing to the cross-sectorial sharing of the data, greater efficiency in processes and delivery of public services can be achieved.

Social welfare can also be improved as society benefits from more transparent and accessible information.

Economy can benefit from an easier access to information and knowledge, contributing to the development of innovative services and creation of new business models.

Reutilization of Open Data sources proposed by RESPOND will contribute in raising the awareness and consciousness level of the Open Data.

2.4 MAIN RESULTS

The main results during the reporting period of the project focus on pilot specific demand response strategy, integration of key RESPOND technology tiers, early deployment activities report, criteria and framework for recruiting and engaging, personal energy performance assistance design, semantic information model, energy gateway for home automation interoperability, data life cycle management policy (preliminary), Official Periodic Report M1-M18, deployment of RESPOND cloud-based platform, findings and recommendations from focus groups on user context, demand response optimization model, optimal energy dispatching at neighbourhood level, RESPOND connectivity to smart grid services, RESPOND middleware deployment, desktop dashboard and smart mobile client, data protection and security, RESPOND validation methodology.

Towards pilot specific demand response strategy RESPOND (M13) TEK RESPOND pilot sites are very different between them not only with respect to the location, but more importantly in terms of the climate associated to each of these locations, the type of houses and dwellers habits. Besides, houses in each pilot site count on different appliances and equipment, as well as different renewable energy sources (RES) and exploitation modality. This idiosyncrasy of each RESPOND pilot site makes them unique. Therefore, a plethora of DR actions were envisioned to be implemented in the project, each of them implemented in the site that best fits. All these findings were presented by TEK in D1.4.



19 | 155

FIGURE 1. GENERAL ENERGY FLOW IN AARHUS, MADRID AND ARAN ISLANDS PILOT SITE

Towards Integration of key RESPOND technology tiers (M13) DEXMA One of the main challenges has been to match the existing systems and underlying technology concepts with system reference architecture designed in T2.1. To do so, the existing technology available in pilot sites has been taken into consideration along with the new MQTT based architecture, which will be able not only to integrate the new RESPOND technology tiers, but also the legacy systems present in the pilot sites. In addition, the inputs from WP1 in terms of exact deployment options and project requirements have been considered for the activities performed in this task. DEXMA reflected all these results in D2.2.



20 | 155

FIGURE 2. DATA FLOW IN RESPOND CONTROL LOOP

Towards early deployment activities report (M13) ENE The Excel file Data Point List (figure 3) that was created for getting information of all devices deployed in Aarhus (Denmark), in the Aran Islands (Ireland) and in Madrid (Spain), is very important and useful for follow the state of the deployment, map in the system all devices and it is necessary also to create the topological data structure. This data was used to generate the instances of the deployed infrastructure in the semantic repository according to the defined ontology and also to define the data structure in DEXCELL system. ENE reflected these information in D2.4.

FIGURE 3. EXAMPLE OF DATA POINTS LIST TO MAP MADRID DEVICES



21 | 155

Towards criteria and framework for recruiting and engaging (M13) AAU

Detailed criteria for the selection of households at the three RESPOND pilot sites (Aarhus, Aran Islands and Madrid) was developed. The aim was to recruit household samples with a relative high diversity with regard to demographic and socio-economic variables such as income level, household size, family type etc. AAU presented in D3.1 how the recruitment went out in practice, present a socio-economic and demographic profile of the recruited households.

FIGURE 4. QUESTIONNAIRE FOR PROSPECTIVE PILOT PARTICIPANTS

Towards personal energy performance assistance design (M13) TEK

The state of the art of existing mobile apps were reviewed, especially the focusing on the ones facing DR problems. TEK reflected in D3.4 the design of RESPOND personal energy performance assistant. The app is in development process.

FIGURE 5. MOBILE APP MOCKUPS



22 | 155

Towards semantic information model (M18) TEK

The semantic information model developed for the RESPOND project was presented in D4.1 by TEK. One of the main outputs was the RESPOND Ontology, which is based on the NeOn Methodology and following the best practices of reusing existing well-known ontologies. The reuse is not a trivial task.

FIGURE 6. RESPOND ONTOLOGY'S DOCUMENTATION AVAILABLE ONLINE

Towards energy gateway for home automation interoperability (M18) IMP

The aim was to support integration of RESPOND platform with external hardware and software systems, thus enabling not only acquisition of data, but also providing a way to issue the control actions to be performed under the cooperative demand strategy. To achieve this overarching goal, the concept of energy gateway was deployed in the pilots. The gateway comprises open software platform OGEMA as well as custom developed modules aimed at integrating different RESPOND components and external systems. IMP reflects in D5.1 the work done.

FIGURE 7. OGEMA GATEWAY IN RESPOND



23 | 155

Towards data life cycle management policy (preliminary) (M18) FEN

The data life cycle management policies necessary to safeguard at all time both, the privacy of the trials participants in the pilot sites and the unauthorized access to the information in the ICT related environment were addressed. FEN presents in D7.4 a preliminary version of the policies to be used in RESPOND project and therefore this document must be updated with the work done during the second half of project’s lifetime.

FIGURE 8. SCHEMA OF DATA PROCESS WITHIN RESPOND PROJECT

FIGURE 9. EXCERPT OF EXCELL COSTS AND EFFORTS BUDGETED VS ACTUAL USE OF RESOURCES

Towards deployment of RESPOND cloud-based platform (M24) IMP Key activities towards deployment of RESPOND cloud-based platform and its core services at pilot sites were undertaken. First, the RESPOND cloud-based platform architecture with its main building blocks was briefly revisit. Then, deployment of different analytic services was carried out. IMP has reflected all the details in D2.5.

PARTNER UNITRESOURCES /

EXPENSES% SPENT

REMAINING

RESOURCES

M6 M12 M18 M24 M30 M36 Total M6 M12 M18 M24 M30 M36 Total

a1 a2 a3 a4 a5 a6 A b1 b2 b3 b4 b5 b6 B B/A A-B

PMs WP1 37,67 7,33 0,00 0,00 0,00 0,00 45,00 33,62 13,66 1,37 0,00 0,00 0,00 48,64 108% -3,64

PMs WP2 16,50 33,00 9,00 9,00 0,00 0,00 67,50 22,18 26,10 9,29 0,00 0,00 0,00 57,57 85% 9,93

PMs WP3 9,25 22,25 3,00 3,00 0,00 0,00 37,50 6,24 16,86 8,09 0,00 0,00 0,00 31,18 83% 6,32

PMs WP4 0,00 10,17 28,33 23,83 11,67 0,00 74,00 0,78 5,46 16,35 0,00 0,00 0,00 22,59 31% 51,41

PMs WP5 0,00 19,50 19,50 39,00 0,00 0,00 78,00 1,25 16,58 20,60 0,00 0,00 0,00 38,42 49% 39,58

PMs WP6 0,00 0,00 9,00 18,23 23,86 28,90 79,99 0,00 0,00 6,50 0,00 0,00 0,00 6,50 8% 73,49

PMs WP7 3,50 3,50 11,00 11,00 27,00 27,00 83,00 7,30 3,22 7,12 0,00 0,00 0,00 17,65 21% 65,35

PMs WP8 3,83 3,83 3,83 3,83 3,83 3,83 23,00 4,06 4,32 3,59 0,00 0,00 0,00 11,98 52% 11,02

PMs Total 70,75 99,58 83,67 107,90 66,36 59,74 487,99 75,43 86,19 72,91 0,00 0,00 0,00 234,53 48% 253,46

Euros Personnel costs 370.212,09 521.093,34 437.800,70 564.588,71 347.224,58 312.628,58 2.553.548,00 394.338,90 415.375,48 365.369,20 0,00 0,00 0,00 1.175.083,57 46% 1.378.464,43

Euros Subcontracting 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0% 0,00

Euros Other direct costs 66.890,67 66.890,67 66.890,67 66.890,67 66.890,67 66.890,67 401.344,00 31.504,52 52.290,30 133.176,93 0,00 0,00 0,00 216.971,75 54% 184.372,25

Euros Indirect Costs 109.275,69 146.996,00 126.172,84 157.869,84 103.528,81 94.879,81 738.723,00 100.473,43 103.506,40 120.147,56 0,00 0,00 0,00 324.127,40 44% 414.595,60

Euros Total Costs 546.378,44 734.980,01 630.864,21 789.349,22 517.644,06 474.399,06 3.693.615,00 526.316,85 571.172,18 618.693,69 0,00 0,00 0,00 1.716.182,72 46% 1.977.432,28

EurosRequested

EU funding464.749,51 625.173,99 536.613,10 671.420,45 440.308,04 306.444,67 3.044.709,75 435.293,92 480.603,52 507.859,54 0,00 0,00 0,00 1.406.366,81 46% 1.638.342,94

ALL

PARTNERS

BUDGET ACTUAL EXPENSES



24 | 155

FIGURE 10. RESPOND PLATFORM ARCHITECTURE

Towards findings and recommendations from focus groups on user context (M24) AAU

Collection of data on the user context from the pilot sites needed for adapting the tested demand response (DR) model to the specific locality and actual users’ everyday practices. The goal was to ensure that RESPOND DR solutions and mobile app will work in actual user context and to avoid unsuitable design features that do not engage users and could cause participant dropout. AAU reflected all the details in D3.3.

FIGURE 11. TOPICS OVERVIEW TOPICS COVERED BY THE FIVE INDIVIDUAL FOCUS GROUPS AT THE THREE PILOT SITES

Towards demand response optimization model (M24) IMP A methodology that employs the Energy Hub modelling concept specifically modified for load management applications was developed. Since RESPOND focuses on the neighbourhood perspective, the loads are managed jointly as an aggregate value (a sum of either individual



25 | 155

appliance activations or multiple household’s aggregate load). IMP presented all the details in D4.2.

FIGURE 12. RESPOND OPTIMIZATION LOOP

Towards optimal energy dispatching at neighbourhood level (M24) IMP It was defined an extension to the methodology developed in D4.2 with which the single-user Energy Hub models are extended to form aggregate neighbourhood models of the Aarhus, Madrid and Aran Islands pilot sites of the RESPOND project. The production and demand are scaled up and real-world demand curves are generated from IoT sensor data that is registered in the InfluxDB time-series database. IMP presented all the details in D4.3.

FIGURE 13. NOTIFICATION TRANSLATION SERVICE WORKFLOW



26 | 155

Towards RESPOND connectivity to smart grid services (M24) IMP The goal of T5.2 was to support RESPOND platform connectivity through an open Application Programming Interface (API) and enable exploitation of data provided by smart grid and other third-party services (e.g. provision of energy prices, weather forecast data, etc.). Open API is designed to provide single endpoint for programmatic access to RESPOND services such as: DR optimization algorithms, forecasted energy consumption, performance evaluation, global ranking, etc. IMP presented all the details in D5.2.

FIGURE 14. WEATHER FORECAST API

Towards RESPOND middleware deployment (M24) IMP Deployment of service-oriented communication middleware, according to the specifications provided in WP1, in order to ensure integration of RESPOND cores services and system components. For this purpose, open source Message Queuing Telemetry Transport (MQTT) broker and data collection software stack has been deployed with the primary role of providing interconnectivity between different system components.

FIGURE 15. MQTT BASED PROTOCOL FOR ACTUATOR CONTROL



27 | 155

Towards desktop dashboard and smart mobile client (M24) DEXMA The results from T5.4 carried out by DEXMA and TEK were presented in a demonstrator D5.4. An easy to use, yet powerful web-based desktop dashboard and smart multifunctional mobile application that will serve as RESPOND cloud platform clients was delivered.

FIGURE 16. T5.4 DESKTOP DASHBOARD AND SMART MOBILE CLIENT

Towards data protection and security (M24) IMP The goal of T5.5 was to undertake proper security measures in order to deal with possible communication threats that RESPOND system may encounter in relation to data collection, transmission and storage. In order to ensure this, a complete end-to-end data protection measures have been designed and implemented. In particular, RESPOND has implemented encryption of communication links and internal data storage as well as implementation of client authorization. IMP presented all the details in D5.5.

FIGURE 17. INTEGRATION OF THE ADAPTER INTO ENERGOMONITOR BACKEND



28 | 155

Towards RESPOND validation methodology (M24>M26) NUIG In D6.1 NUIG detailed the list of KPIs and Business Cases, RESPOND validation methodology was defined, based on RESPOND objectives and also taking into account RESPOND framework.

FIGURE 18. RESPOND KPIS

• Renewable total energy consumption

• Energy savings

Energy

• Reduction of greenhouse gas emissions

CO2

• Peak load reduction

• Rescheduled Demand

• Analytical services accuracy

Demand Response

• Capex

• Economic savings during the DR Event

• OPEX

Economic

• Data security control

• GDPR Risk

Security and Privacy

• Coefficient of performance – COP

• Communication performance

System Operation

• DR campaigns penetration

• Number of user manual actions

• Comfort level according to the user

User

• Indoor Air Quality

• Thermal comfort

Comfort



29 | 155

2.5 WORK PROGRESS AND ACHIEVEMENTS

This section provides an overview of the progress of the work within the work packages WP1, WP2, WP3, WP4, WP5, WP7 and WP8 during the reporting period M13-M24 (October 2018 - September 2019).

2.5.1 WP1: PILOT SITE CHARACTERIZATION

WP1 started in M1 (October 2017) and finished in M13 (October 2018).

FIGURE 19. WP1: PILOT SITE CHARACTHERIZATION GANTT CHART

The main objectives of WP1 were:

• Technical characterization of pilot sites and their respective neighborhoods. • Definition of operation scenarios and key performance indicators. • Analysis of demand response programs at pilot countries and EU level. • Analysis of interoperability issues and smart grid connectivity. • Identification of possible demand side opportunities.

T1.1, T1.2 and T1.3 finished in M6. Only T1.4 has been carried out during the reporting period.

2.5.1.1 DESCRIPTION OF TASK

T1.4 DEMAND RESPONSE ACTIONS DISCOVERY FOR EACH PILOT. M4-M13 TEK

T1.4 started in M4 according to what it was scheduled, but it was carried out until M13 instead of

M12. An extension of one month was applied for and accepted by the Project Officer.

The resulting DR actions recommended for each pilot have been represented in deliverable D1.4

Pilot specific demand response strategy. This document has been delivered in M13. For these

recommendations, the initial analysis made on D1.2 has been very valuable.

This task had a scheduled duration of nine months; however, it was prolonged one extra month

in order to collect all the complete information about the early deployment that had been

prolonged one extra month.

During the first nine months the main findings learned in this task have been potential DR actions

for each pilot’s, the following information is given:



30 | 155

• DR Action: The name used to refer to the DR action.

• Description: A brief explanation of the DR action.

• Equipment involved: The equipment and appliances that enable the implementation of the

DR action.

• Pre-condition: The conditions necessary to enable the execution of the DR action.

• Services involved: The RESPOND services that enable the implementation of the DR

action.

• Recommended DR Type: The type of DR action recommended for an optimal operation of

the DR action.

• Feasible DR Type (optional): The type of DR action that may also be applicable for the

operation of the DR action. In case there are more than one DR Type, they are sorted

according to its suitability.

• DR Type Unfeasible (optional): The type of DR action that cannot be applied for the

operation of the DR action.

2.5.1.2 SIGNIFICANT RESULTS


During the last extra month, the main results obtained in this task can be summarized as follows:

• The finalization of deliverable D1.4 Pilot specific demand respond strategy.

This task aimed at discovering suitable DR actions for each pilot site. Towards that purpose,

having a clear vision of what are the devices each pilot site counts on played a key role. For that

purpose, information collected in T2.3 Design of the initial deployment plan has been leveraged.

The figure below shows the equipment available in one of the pilot houses in the Aran Islands

(Ireland).

FIGURE 20. EQUIPMENT AVAILABLE IN ONE OF THE PILOT HOUSES OF ARAN ISLANDS



31 | 155

The characterization done in T1.1 Operational scenarios and technical characterization of pilot

sites has provided the starting information to clearly identify the possibilities of, on the one hand,

the energy generation and grid distribution and on the other, the significant energy users (SEUs).

The analysis of existing DR done in deliverable D1.2 Demand response programs overview has

allowed the definition of generic DR actions adapted to the environment of the three pilots. These

generic actions are described throughout the deliverable D1.4 as shown in the figure.

FIGURE 21. DR ACTION EXAMPLE

These generic DR actions have been then customized for each pilot site. To do so, first of all,

each pilot site’s available equipment for producing, distributing and consuming energy have been

considered. After that, monitoring, metering and actuating systems’ availability have been

integrated because they are indispensable for knowing both the status and results of the actions.

Furthermore, recommendations made by T3.2 User engagement approach and T3.3 Detailing

the user context and improvements of user interaction have also been key to the discovery and

proposal of the suitable DR actions for each pilot site.

Furthermore, below table shows the recommended DR actions for each pilot site.



32 | 155

TABLE 3. SUMMARY OF DR ACTIONS PER PILOT SITE

DR Action Aarhus Aran Madrid

Load control switches for smart appliances leveraging PV panels

Load control switches for appliances leveraging PV panels

Load control switches for smart appliances leveraging electricity price

Load control switches for appliances leveraging electricity price

Smart thermostats for heating systems

Ventilation control

Thermal load shifting

Smart load shift control for solar photovoltaic

Load control switches for heat pumps

Neighbourhood electric load shifting

Thermal inertia for optimizing heating systems

Thermal inertia for optimizing cooling systems

Neighbourhood DHW shifting

2.5.1.3 DEVIATIONS AND CORRECTIVE ACTIONS IN TASKS

WP1 has achieved its objectives and technical goals for the period with minor deviations.


Deviations from GA:

There has been a deviation from GA as the finalizing of T1.4 was delayed by one month due to

the work with recruiting pilot households in the Aran Islands pilot and the early deployment in



33 | 155

Aran Islands and Madrid pilot sites being more complicated and time-consuming than originally

anticipated. Thus, T1.4 was prolonged, but finalized at the end of month M13.

Corrective actions:

As described above, an extension of one month of T1.4 was applied for and accepted by the

Project Officer.

2.5.1.4 USE OF RESOURCES

Below you can see the efforts performed in this work package by each partner, both, the initial

budget figures and the real efforts carried out.

FIGURE 22: EFFORTS BY PARTNER (BUDGET AND REAL) IN THE WP1 DURING THE 2ND YEAR

2.5.2 WP2: USE CASE DEPLOYMENT AND FOLLOW-UP

WP2 started in M1 (October 2017) and ended in M24 (September 2019).

FIGURE 23. WP2: USER CASE DEPLOYMENT AND FOLLOW-UP GANTT CHART



34 | 155

Specific objectives of WP2 were:

• Specification of system reference architecture. • Specification of interfaces toward legacy systems, smart home devices, and third-party

services. • Definition of pilot deployment plan adapted to each pilot’s topological and functional

perspective. • Configuration of existing energy assets and devices. • Deployment of monitoring and home automation systems for early set up. • Deployment of RESPOND platform with HW/SW systems at project pilot sites.

T2.1 and T2.3 were concluded in the first year. T2.2, T2.4 and T2.5 has been carried out during the reporting period.

2.5.2.1 DESCRIPTION OF TASKS

T2.2 SEAMLESS INTEGRATION OF RESPOND TECHNOLOGY TEARS. M1-M13 DEXMA

T2.2 deals with the communication and integration among the key technology tiers of RESPOND

platform, i.e. the set of technical modules developed in the following working packages. In this

regard, it has been analyzed the integration of all underlying concepts featured by core services

of RESPOND platform, such as DR optimization, energy production models, energy demand

forecasting, etc., and suggest their relations and interaction necessary to conduct cooperative

demand management and optimal control strategy.

This task was carried out during the first thirteen months of the project, an extension of one month

of T2.2 was applied for and approved by the Project Officer.

D2.2 Integration of key RESPOND technology tiers was delivered in M13, ensuring at all time a

proper coordination between other project task related like T2.1, T2.3 and also WP4 about ICT

enabled cooperative demand response model and WP5 about System integration and

interoperability.

T2.4 EARLY DEPLOYMENT AT PILOT SITES. M9-M13 ENE

T2.4 started in M9 and finished in M13 instead of in M12, an extension of one month of T2.2 was applied for and approved by the Project Officer. The activities carried out within this task defined the initial RESPOND deployment plan for each pilot site, adapting to the specific characteristics (topological, functional, technical and users’ requirements) of each of the demonstration areas and were conducted respecting the requirements defined in WP1 and fitting the needs of operation scenarios. The main tasks were:



35 | 155

• Specification of deployment plan to meet DR requirements at pilot sites and match the system architectural model defined in Task 2.1.

• Identification of the monitoring needs and required measuring points for each pilot in relation to both monitoring of energy data and comfort parameters.

• Definition of corresponding measurement framework, necessary to support the collection of the minimal data.

• Analyses of how the RESPOND database(s) will be partitioned and where that data will be recorded, stored, processed and communicated.

T2.5 DEMAND RESPONSE PLATFORM DEPLOYMENT. M13-M24 IMP

T2.5 started in M13 and will carried out until M24. The activities within T2.5 aimed to perform the deployment of RESPOND cloud-based platform and its core services at pilot sites. The goal of these activities is to ensure the proper assembly of the RESPOND solution’s underlying concepts and their deployment in order to conduct optimized control actions under cooperative demand strategy. Activities within this task have been carried out for all the pilots in parallel, having in mind particularities of each of them. This work has been performed in an iterative manner in order to ensure synchronization of activities of related WPs. In order to stay aligned with the operation scenarios defined for each pilot, this task has been performed in accordance with the overall DR requirements and technical characterization made in WP1.


T2.2 SEAMLESS INTEGRATION OF RESPOND TECHNOLOGY TEARS. M1-M13 DEXMA

As a result, the interfaces between internal system components and core services, as well as towards external HW/SW systems (such as smart home devices, legacy systems, third party services, etc.) have been specified. All relevant communication details, among all possible layouts of the RESPOND key technology tiers, have been reported in D2.2 document to allow the seamless integration of RESPOND solution in the following WPs (particularly in WP4 and WP5). One of the main challenges has been to match the existing systems and underlying technology concepts with system reference architecture designed in T2.1. To do so, the existing technology available in pilot sites has been taken into consideration along with the new MQTT based architecture, which will be able not only to integrate the new RESPOND technology tiers, but also the legacy systems present in the pilot sites. In addition, the inputs from WP1 in terms of exact deployment options and project requirements have been considered for the activities performed in this task. Last but not least, one of the key objectives of this task has been the definition of the strategy for integration of RESPOND platform enabling early deployment and interfacing with ICT infrastructure at pilot sites.



36 | 155

During these thirteen months the main results obtained in this task have been:

• A detailed analysis of the integration of all underlying concepts of each analytical service

in aspects such as:

o Description of the application

o Involved developers

o Inputs

o Outputs

o Functionalities

o Additional comments

• The matching of key technology tiers using the reference architecture done in T2.1, has

also been done.

• The interfaces between internal system components, core services and external HW/SW

systems (such as smart home devices, legacy systems, third party services, etc.) has been

provided.

• The strategy for integration of RESPOND platform that will enable early deployment and

interfacing with ICT infrastructure at pilot sites has been described.

This task has allowed to define the main inputs that will be used for the development of the ICT

architecture, the analytical services and the demand response platform, nevertheless is important

to highlight that some minor changes might be expected during the advance of the project.

T2.4 EARLY DEPLOYMENT AT PILOT SITES. M9-M13 ENE

As a result, the deployment plan designed in this task enabled early deployment activities that

provide baseline period measurements on time. Also, it delivered a plan for integration with ICT

systems and energy assets, and home automation systems, either existing or additionally

installed at pilot sites during the project.

Deliverable 2.4 Early deployment activities report was submitted in M13. The document contained a detailed description of what has been implemented at the three pilot sites as well as the related back-end systems. When any part of the implementation has not gone completely according to the plan, those details were discussed on a case by case basis by detailing any blocking elements and suggested resolutions.


The overall control loop composed of measure-forecast-optimize-control main block can be seen

in 25.



37 | 155

FIGURE 24. RESPOND’S MEASURE-FORECAST-OPTIMIZE-CONTROL LOOP

First, the monitoring layer collects measurements from various sensors and smart meters

deployed in people home which are connected through a dedicated gateway. The collected data

are stored in time-series database InfluxDB (part of the central Data repository) and made

available to other parts of the RESPOND platform. Furthermore, all the building topological

information, including the location of each device and the properties measured or controlled by

each of them, is stored in an Openlink Virtuoso Semantic Repository. This information is obtained

from some Excel sheets containing data point lists (Figure 255) which are filled by people in

charge of each pilot site. As some devices were replaced and new ones were installed within

these last 6 months, the data point list has been in constant change and the Semantic Repository

content has been updated accordingly. Furthermore, the addition of new devices resulted in the

update of the RESPOND ontology in order to cover such devices. The update of the ontology has

been performed following the NeOn methodology and reusing the existing vocabularies as much

as possible.



38 | 155

FIGURE 25: EXCERPT OF THE EXCEL DATA POINT LIST FILLED BY PEOPLE IN CHARGE OF RESPOND PILOT SITES

Next, in the forecast stage, production and demand forecasters, which employ historical measurements in addition to weather data, provide production and demand profiles for different types (electricity, heating and cooling).

Based on the forecast results, the optimization seeks to find the optimal control and scheduling

of available energy assets, while also considering other contextual information such as energy

prices, import/export regulation, etc. As a result, the optimization stage provides optimal energy

dispatching in a multi-carrier energy environment. Next, these results are translated into

applicable control actions, which can be applied to existing energy assets. This translation is

performed by employing both building simulation (for cooling and heating) and

Heuristics/Optimization (for other energy assets). The control actions must be approved by the

user. This confirmation is done by user preferences (stored in User Adapter) of explicit

confirmation thanks to the smart mobile assistant. User Adapter component can also provide

stored user preferences to other parts of RESPOND platform, such as constraints on temperature

setpoint, device operation intervals, etc. Finally, the control actions are sent to the installed

actuators by complementing both manual and semi-automatic control approaches.

Some of the aforementioned components have been developed by TEK and tested in their

facilities. Afterwards, these components have been dockerized and sent to IMP for their

deployment in the RESPOND platform. Namely, the list of sent dockers contained:

1. Openlink Virtuoso Semantic Repository

2. Nginx proxy server

3. OpenLDAP

4. phpLDAPadmin

5. PostgreSQL database



39 | 155

6. Apache Tomcat and mobile app proxy

7. Apache Tomcat and demand forecasting service

8. Apache Tomcat and user adapter service

9. RServe


T2.2 SEAMLESS INTEGRATION OF RESPOND TECHNOLOGY TEARS. M1-M13

Deviations from GA:


the work with recruiting pilot households in the Aran Islands pilot and the early deployment in

Aran Islands and Madrid pilot sites being more complicated and time-consuming than originally

anticipated. Thus, T2.2 was prolonged, but finalized at the end of month M13.

Corrective actions:

As described above, an extension of one month of T2.2 was applied for and approved by the

Project Officer.

T2.4 DEMAND RESPONSE PLATFORM DEPLOYMENT. M9-M13

Deviations from GA:

An extension of one moth was applied to this task, that was scheduled to be concluded in M12,

however, was finally finished in M13.

Corrective actions:

The majority of actions were on schedule and going according to plan. However, there were a

few deviations that had to be solved:

Aran islands pilot: the biggest blocker was related to Develco devices shipment delays delivery to Aran islands by DEV. So far, two of the houses on the Aran islands were initially installed due to this issue. In addition, there were a few technical blockers, namely Develco devices technical incompatibilities with Irish electrical domestic system, that need to be remedied. However, they were resolved, as finally, the decision of installing Energomonitor devices in the pilot was consensually agreed. For this step, an amendment was initiated in order to shift devices budget between ENE and DEV. Also, the Irish pilot team was strengthening to ensure the engagement process.

Aarhus pilot: there were some budget considerations due to specifics with the installation namely legal requirements and certifications required when dealing with certain types of infrastructure equipment.



40 | 155

Madrid pilot: there were a few other minor delays, such as the delay of gas measurement in Madrid due to incompatible hardware which was fixed by the end of 2018.

So far, the consortium managed to start collecting baseline data, as well as some survey results from the initial installation and other than the issues specified, the project deployment and overall initial stages run smoothly.


Deviations from GA:

The task leader of T2.5 changed from DEV to IMP. DEV reduced their efforts. See section X

Amendments for detailed information.

Corrective actions:

The aforementioned deviation from GA has been solved through the amendment submitted to

EC.







41 | 155

2.5.3 WP3: USER ENGAGEMNET PROCESS

WP3 ran from M1 to M24. The overall aim of it was to ensure that the RESPOND pilots would

work in actual user context and avoid unsuitable design features that could cause participant

dropout. This was done through developing practical guidelines and criteria for engaging

households (task T3.1), developing the user engagement approach (T3.2) and collecting data on

the user context of the pilots important for adapting the tested DR model to the specific locality

and the users’ everyday practices (T3.3). Finally, and informed by the previous WP3 tasks, WP3

designed a smart mobile application providing a personal energy performance assistant to the

end users (T3.4). T3.1, T3.2 and T3.4 has been finalized during previous reporting periods, while

T3.3 was completed during M19-M24 (i.e. April-September 2019).

FIGURE 27. WP3: USER ENGAGEMENT PROCESS GANTT CHART


• Definition of the framework for participant recruitment. • Specification of user engagement approach. • Design specific feedback mechanism according to different user’s patterns. • Engaging end users and promoting their social interaction. • Design of smart mobile application providing a personal energy performance assistant to

the end users.

T3.2 was concluded in the first year. T3.1, T3.3 and T3.4 has been carried out during the reporting

period.


T3.1 CRITERIA AND FRAMEWORK FOR PARTICIPANT RECRUITMENT. M1-M13 AAU

In collaboration with RESPOND pilot partners, criteria and guidelines for the recruitment of pilot

households have been developed. Focus of these criteria was to ensure a minimum degree of

socio-economic and demographic diversity within and between the household pilot samples at

the three pilot sites. On basis of the guidelines, recruitment of households was carried out

throughout 2018 up to time of reporting. At time of reporting, 20 households have been recruited

in Aarhus, 11 in Madrid and 11 on Aran Islands. The recruitment process continuous at the Madrid

and Aran Islands locations. As part of the recruitment process, a survey was carried out to provide



42 | 155

insight into the socio-economic and demographic profiles of the household samples. Also,

qualitative data on existing habits in relation to a selected number of energy-consuming everyday

practices (particularly dishwashing and laundering) was collected. The survey results and

qualitative data inform the work with designing the final demand response model (WP6) as well

as the mobile application (T3.4).

T3.3 DETAILING THE USER CONTEXT AND IMPROVEMENTS OF USER INTERACTIONS. M7-M24 AAU

This task started in M7 and a first outline of the upcoming focus groups with pilot households was

developed and presented for discussion within the consortium at the Madrid F2F meeting in

October 2018. Input from this meeting has been incorporated in an elaborated draft of guidelines,

which was used as the basis for carrying out two focus groups at the Aarhus pilots in late January

2019.

• Work carried out before the period reported here: At the beginning of the reporting period

(M19-M24), the general outline (guidelines) for caring out focus groups at pilot sites had

already been developed and discussed among the pilot partners. The final guidelines were

ready by March 2019. Also, two focus groups had been carried out in Aarhus in January

2019; these followed the preliminary version of the guidelines, and experiences from the

focus groups provided input to the final version of the guidelines. One focus group focused

on user habits and demand response in relation to heating, the other on habits and demand

response in relation to electricity (appliance use). The focus groups went well with in total

17 participants representing in total 13 households. The participants represented fairly the

diversity of the Aarhus sample regarding age and household composition (family type).

The focus groups were recorded and detailed summaries have been written. At time of

reporting, these summaries are being analysed and condensed into analytical summaries

that will feed into the further preparation of the RESPOND solutions and design.

Detailed summaries of these focus groups had been written. Also, the preparation of the

focus groups in Madrid and Aran Islands had been started.

• Work carried out during the period reported here: In order to tailor the individual focus

groups to the local context of the pilot sites, the pilot partners prepared the topics to be

discussed in the local focus groups by modifying the topics suggested in the general

guidelines (see Appendix 1 of deliverable D3.3). For instance, DR of heating is less

relevant to discuss in Madrid than in, e.g., Aarhus due to differences in weather and

climate. Instead, it is more relevant to discuss DR of air cooling in Madrid, and therefore

one of the focus groups in Madrid focused on the participants’ view on DR of heating, while

one of the Aarhus focus groups focused on heating instead (cooling is not relevant in a

Danish context). By tailoring the specific focus group topics and questions to the local

settings of the pilots, it was ensured that the focus group discussions would be relevant to

the participants and provide the relevant findings for the final analysis and

recommendations of T3.3. The focus groups in Madrid were carried out in May 2019, while

the focus group on Aran Islands was carried out in July 2019. In total, 37 RESPOND

participants (householders) from the local sites took part in the focus groups; 24 men and



43 | 155

13 women. In order to ensure consistency in how the findings from the focus groups were

reported to AAU for the final (comparative) analysis, AAU developed a guideline/template

on how the pilot partners should prepare the summaries of the individual focus groups. On

basis of the summaries from the individual focus groups, AAU prepared the final analysis

and recommendations reported in deliverable D3.3 Findings and recommendations from

focus groups on user context.

In total, the focus groups provided a better understanding of the user context and feed into

the final design of the demand response solution. An important part of the focus groups is

the discussion of the draft version of the DR solution and mobile application for feedback

from pilot households on these.

T3.4 SMART MOBILE CLIENT AND PERSONAL ENERGY PERFORMANCE ASSISTANT. M7-M13 TEK

This task aims at developing an intuitive and simple mobile app towards the engagement of the

users (pilot households).


Overall, WP3 is proceeding well and are providing detailed information on the user context at the

pilot sites as well as recommendations for developing user engaging DR designs and mobile

apps.


The findings have been reported in D3.1 Criteria and framework for recruiting and engaging

finalized in M13 (October 2018). Among other things, it is concluded that a sufficient level of

diversity with regard to key socio-economic and demographic variables such as age, gender,

education and family type has been achieved at all places (with the Aarhus sample representing

the highest level of diversity). This diversity is important as this helps ensure representativeness

and validity of the RESPOND findings. Though, there are still some biases that needs to be taken

into account then carrying out the pilots and analysing the results of them. For instance, the Aran

and Madrid household samples have some over-representation of older generations (and less

families with children), which should be considered in the later analysis.


The following is a brief summarize of the key findings of T3.3 (see D3.3 for details):

• Dishwashing and laundry come up across all sites as the types of electricity consumption that

the focus group participants find most likely and practical to time-shift.



44 | 155

• The focus groups show that whether people are working or not (i.e. at home or not during

daylight hours) is important for how difficult and realistic it is perceived to time shift

consumption, although this might be less decisive in the Madrid case as many households

here have housekeepers staying at home during the day.

• Regarding automation or remote control of demand response actions (e.g. time shifting

dishwashing), the focus groups come up with mixed results. Many favour the idea of

automation or remote control, but several also find it attractive if they just can get

notifications/recommendations via the mobile app about when it is optimal for them to

consume energy.

• Regarding variable electricity prices (dynamic pricing), the consensus across focus groups is

that real-time pricing is too difficult to follow, while many find the static Time-of-Use pricing

much simpler and easier to follow (e.g. to build daily routines around). Peak Production

Rebates also got a positive reception on general, especially in Aarhus as this scheme could

help them optimise the consumption of their local renewable electricity production (PVs)

• Money saving is in general seen as a key motivational driver for changing daily habits and do

demand response actions. However, also other motivational drivers are mentioned such as

doing something good for the environment or the positive feeling of consuming local renewable

energy. The latter seems to be another important motivational driver that might have a similar

strength as money savings.

• In Madrid, demand response of air cooling was discussed. Consensus was that at least some

of the cooling could be time shifted or peaks could be shaved (e.g. by using less power-

consuming mechanical ventilators instead of air conditioning).

• The Aarhus focus group on heating shows a high diversity between households regarding

heating practices and preferences as well as often idiosyncratic approaches of the individual

households on how to control and adjust heating. This diversity needs to be considered when

designing the RESPOND solution.

• The RESPOND demand response solution for heating, which is going to be trialled in Aarhus,

was overall well-received by the Aarhus focus group participants. There is agreement that the

demand response scheme (temperature set-back in morning hours with a short pre-heating

before set-back) must be automated. Also, it should be easy to “override” the automated

control in cases of deviations in peoples’ daily routines or if they feel the temperature is not as

desired.

• The focus groups provided much feedback on the preliminary RESPOND mobile app design.

Some of the key recommendations and observations are: The app should not be too

complicated to use and navigate in, although it might be a good idea to have “two levels” of

user interfaces to accommodate different user needs (a simple and a more detailed level).

Across focus groups, there was also a widespread interest in getting access to appliance-

specific breakdowns of the electricity consumption of households. The idea of comparing the

energy performance of the individual household to the performance of neighbours got a mixed

reception; comparing the level of individual self-sufficiency was the type of comparison that

attracted most interest. Furthermore, the idea of recommendations and notifications on, e.g.,

optimal demand response actions were in general well-received.



45 | 155

• The deliverable presents four different usage scenarios. The aim of these scenarios is to

“translate” the findings from the focus groups into a limited number of scenarios with

recommendations on how the design of the RESPOND solutions in general – and the

RESPOND app specifically – can be tailored/adapted to the everyday practices, needs and

wishes of the residents (as reported in the focus groups). Each scenario focuses on one

specific usage (feature/function) of the RESPOND demand response solution and app. The

four scenarios are: 1) demand response of heating; 2) Peak production rebates and local

demand response; 3) demand response of cooling; and 4) Automated and remote control of

appliances.

• Finally, the deliverable concludes with some proposals for competitions that might be set up

at the local pilot sites in order to promote the pilot households’ interest and engagement in the

RESPOND demand response solutions and mobile app.


Existing mobile apps have been analysed, as well as the latest app design techniques and

methodology. Furthermore, latest trends in users experience have been investigated, with views

to proposing a high quality and engaging mobile app. Finally, feedback from RESPOND project

partners have been collected. This information has been valuable, as they cover different areas

of expertise related to the DR in dwellings. On basis of this, the overall design concept for and a

first version of the RESPOND mobile app have been developed, as reported in D3.4 Personal

energy performance assistant design (finalized in M13). This first version of the mobile app will

be subject to further improvements and extension throughout the time up to the final validation

trial, partly based on the outcome of user context analysis in T3.3. Below is the navigation diagram

of the mobile app and two selected screenshots illustrating the real-time neighbourhood

consumption for Android (left) and the neighbourhood energy generation for iOS (right):



46 | 155

FIGURE 28. MOBILE APP’S NAVIGATION DIAGRAM



Deviations from GA:


the work with recruiting pilot households being more complicated and time-consuming than

originally anticipated. Thus, T3.1 was prolonged, but finalized at the end of month M13.

Corrective actions:


Project Officer.


Deviations from GA:

There have been two deviations from GA (both deliberately chosen to optimize the completion of

T3.3):

1) In the GA, it was planned to carry out two focus groups at each pilot site. This was done in

Madrid and Aarhus, but on Aran Islands only one focus group was carried out. This was due to a

combination of fewer pilot households on Aran Islands and the timing of the focus groups (to be

done during the busiest tourist season of the year, which made many of the pilot households



47 | 155

having little time for participating in the focus group). It was therefore decided to carry out only

one focus group (with invitation sent to all pilot households) in order to ensure a sufficiently high

turnout for this focus group.

2) In the GA, it is stated that the focus groups should be audio recorded (to provide optimal basis

for the later analysis of the participants’ comments and discussions). However, the pilot partner

in Madrid (FEN) judged – on basis of their close knowledge with the pilot households – that this

would create troubles as the pilot households would not feel comfortable with being recorded.

Therefore, it was decided to have one person from FEN to make detailed notes of comments and

discussion during the focus groups. This provided a good and sufficiently detailed basis for the

later analysis of the Madrid focus groups.

Corrective actions:

See above.


Deviations from GA:

There has been a deviation from Grant Agreement as the finalizing of T3.4 was delayed by one

month due to the work with recruiting pilot households being more complicated and time-

consuming than originally anticipated. Thus, T3.4 was prolonged, but finalized at the end of month

M13.

Corrective actions:


Project Officer.






48 | 155


2.5.4 WP4: ICT ENABLED COOPERATIVE DEMAND RESPONSE MODEL

WP4 runs from M7 (April 2018) to M30 (March 2020). Overall, WP4 is proceeding well. The overall

aim of it is to undertake the key activities that will enable cooperative demand response actions.

Within this WP, task 4.1 built the semantically enriched information model that provides a common

understanding between all components of the system, and concretely, with the smart services

that are being developed in the WP. The rest of the tasks will lead to the development of the smart

analytical services and their integration. As a consequence, this will allow the optimization of the

energy usage at local and neighbourhood level to take advantage of the local RES resources and

to be adapted to the Demand Response targets.

FIGURE 30. WP4: ICT ENABLED COOPERATIVE DEMAND RESPONSE GANTT CHART


• Development of semantic information model serving as a common vocabulary. • Intergradation of multi-carrier supply side optimization and demand side management. • Energy dispatch optimization at both household and neighborhood level. • Energy demand and production forecasting. • Energy data analytics empowered by system modelling to perform an optimized control.



49 | 155

Below image shows the RESPOND services interaction diagram, emphasizing on the modules to

be developed by each Task within the WP. It is worth mentioning that this figure lacks the

Predictive Maintenance module which, due to the scarce data availability, will be implemented in

during the last 6 months of the WP4.

FIGURE 31. MODULES TO BE DEVELOPED IN DIFFERENT TASKS WITHIN WP4

T4.1, T4.2, T4.3, T4.4 and T4.5 has been carried out during the reporting period.


T4.1 SEMANTIC INFORMATION MODEL. M7-M18 TEK

T4.1 has been carried out during the months 7 to 18 according to what it was scheduled. The aim

of this model is to provide resources with an explicit and unambiguous semantics. Without this

explicit semantic assignment, different users could refer to the same resource with different

meanings. Furthermore, a semantic information model improves semantic interoperability,

providing both humans and machines with a shared meaning of terms. The proposed semantic

model is based on the RESPOND ontology, which has been developed based on the well-known

NeOn Methodology to ensure its quality. Moreover, a set of related ontologies have been

reviewed and the most adequate have been reused. On top of that, the ontology has been made

online and it is well-documented, which is expected to further foster its understandability and

reusability. The ontology has been then instantiated with information of buildings and installed

devices. This information is extracted from a set of Excel sheets filled by people in charge of the

RESPOND pilot sites. However, the measurements and actuations made by IoT systems is not

used to instantiate the ontology. Instead, this information is stores in InfluxDB and the ontology

instantiation contains the Data Point ID.



50 | 155

The model development process has been reported in D4.1 Semantic Information Model finalized

in M18.

T4.2 INTEGRATION OF DEMAND RESPONSE WITH SUPPLY/DEMAND SIDE MANAGEMENT. M7-M24 IMP

This task started in M7 and ended in M24. The essential core of the optimization procedure that is essentially described in task T4.2 is the underlying model. For this application, we have selected the Energy Hub depicted in Figure 32, or to be more precise, its linear variant. Such a model represents energy flow through a so-called unit of energy consumption that can either be a household, office, or a larger infrastructure such as a neighborhood, a building and so on.

FIGURE 32: GENERAL STRUCTURE OF THE ENERGY HUB

The Energy Hub models the fundamental processes regarding energy – energy transformation and energy conversion by utilizing matrix multiplication in different stages. In the input stage, we find input storage conversion (𝑆_in, not depicted in the figure), input transformation (𝐹_in), conversion (𝐶), export (𝐷_exp, not depicted in the figure), output transformation (𝐹_out) and output storage conversion (𝑆_out, not depicted in the figure). Out of these, the matrices representing energy conversions (S_in, C and S_out) are essentially diagonal matrices whose coefficient represent the loss factor that is used to model losses when, for example, converting electric energy from AC to DC or vice versa when storing or drawing energy from an electric battery, or otherwise, the losses that occur in a heat exchanger when filling a hot-water tank. Also, these losses also model AC to AC transformations that occur in conventional transformers or DC to DC transformations in adequate scenarios. On the other hand, transformation matrices (𝐹_in and 𝐹_out) depict energy carrier aggregation and disaggregation. For example, if the electric load

can be fulfilled by both energy from the solar PV and the grid, 𝐹_out should model this energy aggregation before the load stage adequately. Conversely, if a single energy carrier, district heating for example, fulfills both thermal demand and domestic hot water (DHW), 𝐹_in should model this disaggregation adequately. The Energy Hub is fully described by its variables (input power 𝑃_in, input storage energy 𝑞_in, power to converters 𝑃_cin, power from converters 𝑃_cout, exported power 𝑃_exp, output power

𝑃_out, output storage energy 𝑞_out, and load 𝐿). Because these variables exist in every time step, they are usually represented by vectors and are optimized using (mixed integer) linear programming. The optimizer, in a process depicted in Figure 33 should maintain two goals in mind when looking for the optimal solution: minimization of consumer costs and minimization the differences between the measured load profile and the required load profile. In order to provide such capabilities, the optimizer receives inputs from the demand forecaster (red line) service in form of an array that describes the predicted load in the next (let’s say) 24



51 | 155

hours, the grid requests in form of indicators when a demand response (DR) event will occur in the next 24 hours and what is the requested load profile at that (those) time (times), the production forecaster services in form of an array that describes the predicted availability of renewable sources and finally, the day-ahead (or fixed) pricing scheme. The optimizer then returns an optimized profile (green line) that serves as an input for another service called the rule-based notification engine.

FIGURE 33. THE OPTIMIZATION PROCESS

This service considers the differences in the forecast load and the optimized load profile, potentially checks the statuses of smart appliances (smart plugs, smart cables etc.) and issues adequate notifications and/or recommendations to the end users but can also communicate with visualization dashboards etc. When the user receives a notification, he is presented with the options of dismissing (ignoring) it, choosing to take manual actions (sometimes these are the only ones available) or allowing for an automatic response (if the considered appliance is connected to a smart plug or cable) and giving the system the authorization to act on his behalf.

FIGURE 34. THE OPTIMIZATION PROCESS

Although DR events are most commonly used when referring to electric loads, the assumed model allows for simple and straightforward definitions of DR events for any type of load, be it electric or thermal. Therefore, the considered example, presented in figure 34¡Error! No se



52 | 155

encuentra el origen de la referencia., will implement a DR event for all three types of load. The figure shows how the optimizer upholds the requested load profile at times when a DR event is active while simultaneously minimizing overall costs of system operation by shifting the load difference within the appropriate bounds to a period where, in this case, local energy production is present (the time of day where the sun shines the brightest and therefore the PV array outputs the most energy). The same algorithm could also be used when variable tariffs are at play in which case that the load shifting would be executed when the price of importing energy is smaller.

T4.3 OPTIMAL ENERGY DISTPACHING AT HOUSEHOLD AND NEIGHBOURHOOD LEVEL. M13-M24 IMP

This task started in M13 and ends in month 24. This task aims at enabling the application of the

Integrative Energy Optimiser (developed in Task 4.2) both at the household and district levels. A

single Energy hub can be used to model systems of different scale (i.e. small, intermediate and

large scale), from single households to entire flats, neighborhoods or even city blocks as long as

the modelled units share a common topology.

However, if the differences in topology are too significant, or the interconnections and cross-

trading between individual users need to be facilitated, the use of multiple different Energy hub

models should be considered. In this case, additional constraints allow for achieving various

different tasks with the optimization. At the moment of writing this report, the aforementioned

models are being developed.

T4.4 ENERGY PRODUCTION AND DEMAND FORECASTING. M13-M36 TEK

T4.4 started in M13 and ends in month 30.

M13-M18 period:

Production forecast

This part of the T4.4 has been worked on for six months at this point. The aim of this service is to

provide necessary information about renewable sources’ production depending on the weather

conditions for the optimizer in order to adequately reschedule consumer’s consumption.

In the first stage, different state-of-the-art techniques were studied, so as to select the appropriate

methodology for the RESPOND project. Numerous factors were taken into account when the

choice was to be made. The Forecasting horizon, which represents the time interval for which the

forecast should be made, was defined by the optimizer’s specification. Namely, due to the fact

that other inputs that affect optimization process, such as pricing, are available only one day

ahead, it was clear that the forecasting horizon should be 24 hours, as well. Having in mind both

previously discussed, recently published, papers from the field of forecasting the renewable

sources’ production and previous work on FP7 Energy Warden project, as a final decision, data

driven, or precisely machine learning, models were chosen as the most appropriate ones for this

task.



53 | 155

Strictly speaking, the architecture for the production forecaster was specified, as shown in Figure

35, where sub model m forecasts production in m hours and its inputs correspond to the

characteristics for that same time. So, for every renewable source 24 sub models for forecasting

its production for the next 24 hours in hourly resolution will be provided.

FIGURE 35. PRODUCTION FORECAST MODEL SPECIFICATION

After defining the architecture, analysis on adequate input characteristics was conducted.

Namely, it was indisputable that various weather conditions should be included, nonetheless it

emerged that performance dramatically decreased if solar irradiation was not introduced.

Therefore, weather services which provide this necessary information were explored, and the

Weatherbit.io has been chosen, as it covers the variety of weather data together with irradiation.

Apart from data, analysis on adequate models was carried out with the available data, as well.

Namely, two different scenarios were tested – one considering photovoltaic panel and one

considering solar thermal collector’s production.

Photovoltaic panel

When production of a PV panel is considered, apart from the available historical data from

Weatherbit.io service, we have used data obtained from PUPIN’s local power plant for developing

the prototype and obtained results are shown in ¡Error! No se encuentra el origen de la

referencia. (MAE – mean absolute error, MSE – mean square error, RSE – relative square error,

RAE – relative absolute error). Comparing MSE between different methodologies, neural network

performed the best. However, due to the fact that different methodologies performed similarly and

that performance highly depends on the data, the final decision on which methodology will be

MODEL 1

MODEL 2

MODEL 3

MODEL 24

x(t+1) y(t+1)

x(t+2)

x(t+3)

x(t+24)

y(t+2)

y(t+3)

y(t+24)



54 | 155

implemented on each pilot has not been made yet. Namely, different methodologies will be tested,

and the one with the highest performance will be chosen. Moreover, for different pilots, different

models might be picked.

TABLE 4. PV PRODUCTION PROTOTYPE RESULTS

methodology MAE MSE RSE RAE

SVR - RBF 0.73 2.29 0.7 0.41

SVR - RBF 0.68 1.91 0.65 0.34

SVR - linear 0.72 2.1 0.69 0.37

SVR - sigmoid 0.66 1.8 0.64 0.32

Linear regression 0.76 1.6 0.73 0.28

Neural network 0.69 1.46 0.66 0.26

KNN 0.76 2.2 0.73 0.39

KNN weighted 0.71 2.12 0.69 0.38

Random forest 0.67 1.84 0.65 0.33

Solar thermal collector

Similarly to the PV production, a prototype was developed for the STC forecaster, as well. As the

outputs for the training and validation purposes, publicly available data from

www.solarheatdata.eu service was used, whilst the weather data was obtained from the same

service as before, and the results are presented in ¡Error! No se encuentra el origen de la

referencia..

TABLE 4. STC PRODUCTION PROTOTYPE RESULTS

methodology MAE MSE

SVR - RBF 0.115 0.023

SVR - RBF 0.110 0.025

SVR - linear 0.125 0.024

SVR - sigmoid 0.123 0.024

Linear regression 0.118 0.026

Neural network 0.104 0.024

KNN 0.107 0.033

KNN weighted 0.106 0.032

Random forest 0.084 0.023

After developing these prototypes, our next steps are developing the corresponding pilot models

and deploying the service on the web server.

http://www.solarheatdata.eu/



55 | 155

Energy demand forecast

The main aim of developing this service is to be able to foresee the energy demand of dwellers

ahead of time. Combining this information with the expected production of RES is expected to

enable the suggestion of suitable DR actions, thus reducing peak demands and allowing the

exploitation of renewable energy.

Similar to the energy production forecaster’s development, different state-of-the-art techniques

were analysed as well as related work in existing literature. As for deciding the horizon of the

energy demand forecaster, bearing in mind the factors that affect the optimization process, it was

set to 24 hours. Furthermore, since mathematical or physics-based models may fail at accurately

predicting the energy demand due to the existing gap between the theoretical and real

consumption of the different assets, data-driven models were chosen for this task.

Due to the scarcity of available data coming from RESPOND pilot houses, a prototype of energy

demand forecaster was developed for another use case where similar data was available.

Namely, an energy demand forecaster for an office was developed in order to test the

performance of different machine learning algorithms. Among the variables taken into

consideration for the development of this prototype the dweller’s electric consumption, calendar

and the external weather conditions can be highlighted. Regarding the analysed algorithms, they

include linear regression, SVM, decision trees and time series models ARIMA. ¡Error! No se

encuentra el origen de la referencia. summarizes the obtained MAEs for this use case.

TABLE 5. OBTAINED MAES FOR DEMAND PREDICTION USING DIFFERENT ALGORITHMS

ALGORITHM MAE

Linear regression 0.386

SVM - SMOReg 0.263

Decission Trees 0.287

ARIMA 0.223

In this use case, best results were obtained with ARIMA, as shown in Figure 36.

FIGURE 36. DEMAND FORECAST OF THE USE CASE OFFICE WITH ARIMA

Forecasts from ARIMA(3,1,0)

0 50 100 150 200

1.0

1.5

2.0

2.5



56 | 155

The development of this prototype is aimed at being calibrated with data coming from different

pilot houses, thus allowing an accurate estimation of the energy demand both at a house and at

a district level. The most immediate energy demand development of upcoming weeks is for the

Madrid pilot site due to the data availability.

T4.5 DATA ANALYTICS AND OPTIMIZED CONTROL. M13-M36 TEK

T4.5 started in M13 and it ends in M30. This task aims at integrating the outcomes of all previous

tasks of the WP in order to perform actual control actions and influence the load according to

cooperative DR strategies.

M13-M18 period:

During the last six months the main results obtained in this task can be summarized as follows:

• Survey of Aran Island pilot houses to help on the installation of a smart metering system

and collect all the needed information to develop a detailed simulation model of one

residential house

• Development of simulation models of one dwelling in Aran Island

• Identification of potential predictive maintenance task.

For the development of the selected dwelling in the Aran Islands, the IESVE simulation software

has been used. In addition, a dedicated library for grey-box building simulation modelling has

been developed in Modelica language. As a result, the ROM (Reduced Order Model) has been

developed, which is meant to be able to forecast the energy consumption of a single house due

to heating/cooling system with a defined indoor air temperature set point. Moreover, the

development of a dedicated interface for data input collection to generate ROM of a single

residential house has been undertaken. Finally, a preliminary analysis of accuracy comparison

between a detailed IESVE simulation model and a ROM has been performed.

The identification of suitable predictive maintenance tasks to ensure the adequate performance

of systems and equipment has also been performed. Driven by the performance prediction of

different component and assets, early anomalous performances are expected to be identified, in

order to suggest the corresponding maintenance tasks. Figure 37 shows the different scenarios

identified in predictive maintenance tasks regarding performance of different components and

systems.



57 | 155

FIGURE 37. POTENTIAL PERFORMANCE OF DIFFERENT SYSTEMS AND COMPONENTS

As part of this task, the feasibility of Demand Response scenarios for each pilot test house has

been analyzed. Towards this goal, the analysis made on T1.4: Demand Response actions

discovery for each pilot, and the dedicated conference calls in order to have a clear picture of

data availability for each pilot test case have played a key role. Among the list of potential DR

strategies, focus has been placed on exploiting building inertia and indoor air temperature set-

point adjustment.

The latest work performed in this task is related to the survey performed on other two dwellings

in the Aran Islands in order to the installation of a smart metering systems and for the development

of detailed and ROM building simulation models. The activity is expected to help continuing the

research related to ROM input/output accuracy.

RESPOND platform’s main objective is collecting, storing and processing data obtained from

different field level devices, and sending the control actions to actuators. The collected data is

further processed by means of analytic services which will be developed during RESPOND

project. The platform proposed in deliverable D2.2: Integration of key RESPOND technology tiers

has been modified due to the findings after completing deliverable D1.4: Pilot specific demand

response strategy and tasks performed throughout WP3. Namely, User Adapter and Scheduler

modules have been added. The former enables the adaptation of DR actions to user preferences,

as it gathers concrete occupants’ preferences regarding comfort levels, preferred timetables and

automation possibilities to be considered prior to the execution of a recommended action. The

latter module allows scheduling automatic actions taking into consideration user’s preferences

as well. Therefore, a suitable DR action can be executed in a time slot preferred by the occupant.

These considerations have been captured in the two new modules of the diagram. The resulting

flow of data between different components is shown in Figure 38.



58 | 155

FIGURE 38. RESPOND PLATFORM'S DATA FLOW


T4.1 SEMANTIC INFORMATION MODEL. M7-M18 TEK

The resulting semantic information model, which will be the glue to integrate all the data managed

by the RESPOND platform, has been presented in deliverable D4.1 Semantic Information Model.

During the last six month the main results obtained in this task can be summarized as follows:

• The update and publication of the semantic model

• The development of an ontology instantiation process

• The definition of predefined parametrizable SPARQL queries

Although a first version of the RESPOND ontology was developed by the end of month 12, new

ontology requirements have triggered the need of updating the ontology. For instance, the new

version of the RESPOND ontology reuses another ontology that was not initially reused, namely,

the SEAS Feature of Interest ontology. Therefore, the RESPOND ontology reuses BOT, SAREF

and SEAS Feature of Interest ontologies.

Figure 39 shows the RESPOND ontology's main classes and properties. It is worth mentioning

that every update of the ontology is methodically performed, based on the well-known NeOn Methodology.



59 | 155

FIGURE 39. RESPOND ONTOLOGY'S MAIN CLASSES AND PROPERTIES

In order to ease the understanding of the semantic model, a documentation with diagrams, human readable descriptions of the ontology terms and a summary of changes with respect to previous versions of the ontology has been created. Furthermore, the ontology has been made online to foster its reusability. The RESPOND ontology’s instantiation, often referred to as the ABox, was generated leveraging the pilot sites data point lists. These data point lists are captured in Excel sheets and contain information regarding the devices installed in pilot sites and include additional information such as their location and the property they measure. Figure 40 shows an excerpt of the pilot sites data point list.

FIGURE 40. DATA POINT LIST EXCERPT

However, the measurements and actuations made by IoT systems is not used to instantiate the ontology. Instead, this information is stores in InfluxDB and the ontology instantiation contains the Data Point ID. Instantiating each and every pilot house or device can become an arduous task. Specially, bearing in mind that new houses can be added at any point, and devices can be added, removed or relocated. Therefore, there is a dire need to automatize this data point list instantiation process. For that purpose, RESPOND has developed a service based on Apache Jena framework.



60 | 155

Furthermore, the instantiation process has been helpful to detect new ontology requirements and even ontology weaknesses. This has led to the update of the RESPOND ontology, redefining existing concepts and relationships, as well as introducing new ones to fully satisfy existing requirements. Moreover, this allows a more accurate representation of the pilot site status and enables the exploitation of this information.

Thanks to this semantic representation, different information can be queried. To ease this

information query process, a set of predefined and parametrizable SPARQL queries have been

defined. These queries allow the users to retrieve the required information only by adding a few

parameters. For instance, the list of devices installed within a house can be retrieved executing

the SPARQL query shown in

Listing 1, by replacing the wild card $HOUSE_ID is replaced by the target house’s identifier.

PREFIX dc: <http://purl.org/dc/terms/> PREFIX bot: <https://w3id.org/bot#> SELECT DISTINCT ?deviceID WHERE{ {?space bot:hasElement ?device; dc:identifier ?houseID.} UNION {?space bot:hasSpace ?subspace; dc:identifier ?houseID. ?subspace bot:hasElement ?device.} ?device dc:identifier ?deviceID. FILTER( ?houseID = $HOUSE_ID ) }

LISTING 1: SPARQL QUERY TO RETRIEVE THE LIST OF DEVICES INSTALLED WITHIN A HOUSE

T4.2 INTEGRATION OF DEMAND RESPONSE WITH SUPPLY/DEMAND SIDE MANAGEMENT. M7-M24 IMP

With the aim of influencing grid stability and environmental protection through the Demand

Response (DR) events, optimization engine was proposed to be the core of the innovative solution

in the RESPOND platform. The main idea was to provide the optimal profile in accordance with

the forecasted production and demand, day-ahead prices and DR events using demand flexibility.

Therefore, within Task 4.2 the methodology has been developed and potential use cases in which

a DR event is induced using peak pricing in order to force load adaptations.

For the optimization purposes, the Energy Hub model has been used. Its core idea is modelling

energy transformation and conversion through matrix multiplication. Namely, the fundamental

constraints of the Energy Hub system depict energy flow and energy transformations through a

set of stages input (raw) energy storage 𝑄in, input energy transformation 𝐹in, energy conversion



61 | 155

𝐶, energy export 𝐸exp, output energy transformation 𝐹out, output (user) energy storage 𝑄out and

loads 𝐿.

Finally, within the Task 4.2, simulations for the Energy Hub optimization for individual households

for each pilot were carried out.

With regards to the topology of each pilot, optimization constraints, synthetized demand profiles

for different load types (electric, thermal, DHW), forecasted renewable energy and prices were

defined. Finally, implicit DR showcase was defined through price adoption. In other words, grid

price has been increased from 4pm to 10pm, while decreased for the rest of the day. Price for the

district heating was decreased from 6am to 5pm and increased during the rest of the day. Results

are shown in Figure and Figure, where it can be seen how consumption is adapted to fit the

pricing scheme. All of these results are deeply analyzed in Deliverable 4.2 which was submitted

on time on September 30th.

𝛥𝐿+ ≤ +𝐼ሺ𝛥𝐿+ሻ ⋅ Δ𝐿max+

𝛥𝐿− ≥ −𝐼ሺ𝛥𝐿−ሻ ⋅ Δ𝐿max−

𝐼ሺ𝛥𝐿+ሻ + 𝐼ሺ𝛥𝐿−ሻ ≤ 1

𝐿ሺ𝑘ሻ

23

𝑘=0

= 𝐿predictedሺ𝑘ሻ

23

𝑘=0

𝐿 + 𝛥𝐿+ + 𝛥𝐿− = 𝐿required

Use case 1

Use case 2

FIGURE 41 - ENERGY HUB STRUCTURE FOR DIFFERENT USE CASES



62 | 155

FIGURE 42 - DR LOAD DEVIATION

FIGURE 43. NOMINAL AND OPTIMIZED INDIVIDUAL

FIGURE 44. PREDICTED AND OPTIMIZED LOAD PROFILES

FIGURE 42. EXAMPLE OF LOAD SHIFTING IN TIME FROM NOMINAL LOAD SCHEDULE (TOP) WITH SHIFTING WINDOWS TO THE

OPTIMIZED LOAD SCHEDULE (BOTTOM)



63 | 155

T4.3 OPTIMAL ENERGY DISPATCHING AT HOUSEHOLD AND NEIGHBOURHOOD LEVEL. M13-M24 IMP

M13-M18 period:

A very useful feature of the Energy hub model (chosen in T4.2) is its high scalability potential. Namely the same type of model can be used to model a wide variety of different microgrid infrastructures. First of all, the most basic, single-unit system, like a household, apartment or an office can be modeled using one energy hub. However, if a larger multi-unit system is considered, but it is comprised out of different units that share a common topology, such a system, although being multi-unit, can still be represented using one energy hub. On the other hand, if a system is comprised out of units that have different setups, i.e. they do not share a common topology, such a setting requires multiple Energy hubs to be used. When considering optimization complexity, using one hub to represent multiple units yields a model that has a significantly larger number of dimensions than what a single model for one such unit would have. Therefore, if time is an essential factor, a setup where each household is individually represented might give better results against a setup where one big hub is used because the complexity of individual models increases linearly (O(N)) whilst the complexity of solving big unified models grows exponentially (O(N^a)). However, since the Respond projects tackles the optimization from a neighborhood standpoint and individual users are generally not modeled, unified models are preferred. Also, the Energy hub has clearly segregated input and output variables (imported energy P_in, exported energy P_exp and loads L) and therefore allows for simple and easy interconnections between models i.e. placing them in series or in parallel. This behavior can be obtained by specifying adequate constraints over these input/output variables. Having this in mind, modeling a system where besides the traditional energy trading between users and the grid, importing and exporting energy from local production capabilities and peer-to-peer (P2P) trading can be easily achieved. Beginning with a simplest setup, Below image shows a single unit of energy consumption that can import electric energy from the grid or local distributed production and thermal energy from a power plant or, again, local renewable production, but can also sell excess energy back to the grid (this is usually only the case for electric for now). Such a simple setup is easily obtained by using a single energy hub because it supports for all the mentioned features natively.

FIGURE 45. SIMPLE ONE-HOUSEHOLD SETUP



64 | 155

Moving on, if we consider a homogeneous system where a neighborhood of households (or a flat

of apartments) share a common topology, such a system, in the below image, can also be easily

modeled with one Energy hub. If individual units require modeling, specific variable ranges are

assigned to each of the units.

FIGURE 46. HOMOGENEOUS MULTI-HOUSEHOLD SETUP

Finally, if a heterogeneous system is considered, where different units have different topologies,

like in the below diagram, such a system should be modeled by using individual Energy hubs per

each different unit because different matrices or constraints need to be applied.

FIGURE 47. HETEROGENEOUS MULTI-HOUSEHOLD SETUP

In conclusion, a single Energy hub can be used to model systems of different scale (small, intermediate and large scale), from single households to entire flats, neighborhoods or even city blocks as long as the modeled units share a common topology. On the other hand, if the differences in topology are too significant, or we want to facilitate interconnections and cross-trading between individual users, we should opt for the use of multiple different Energy hub models. In this case, additional constraints allow for achieving various different tasks with the optimization. In accordance with the given analysis, models of the pilot sites were developed and are presented in the figures below.



65 | 155

FIGURE 47. AARHUS PILOT MODEL

FIGURE 48. ARAN PILOT MODEL

FIGURE 49. MADRID PILOT MODEL



66 | 155

M19-M24 period:

Energy Hub optimization methodology chosen in Task 4.2 has been further exploited within Task

4.3. Namely, its important characteristic being the scalability potential was especially exploited

having in mind that RESPOND project tackles aggregated sets of users, at the so-called

neighbourhood level. Therefore, the main goal of Task 4.3 was the instantiation of the individual

model for each pilot site and developing the optimization as a service.

Two distinct types of models were employed within the RESPOND project for the purposes of

energy flow modelling: one where the pilot consisted of homogeneous units i.e. where each

apartment or house within the neighbourhood has the same topology, input carrier types, pricing

scheme, etc. (used for Aarhus and Madrid pilots) and one in which the pilot consisted of

heterogeneous households and therefore to depict it truthfully, multiple interconnected Energy

Hubs had to be employed to obtain a proper model for simulation (used for Aran Islands).

As the apartments form the Aarhus pilot are situated within two buildings with the shared PV plant,

one Energy Hub model was initialized in consistence with the pilot’s topology. Prices were taken

as the current ones, whilst for the purpose of developing the optimization service, forecasted

demand and production energy has been collected from the MySQL database. Madrid

optimization model consists out of one Energy Hub as well, because of its homogenous structure.

However, electrical energy pricing scheme is dynamically changing, resulting in the optimization

service collecting day-ahead prices from MySQL database.

Figure 51. Modified price profile for load

reduction

Figure 52. Load profile with load reduction

Figure 50. Imported power profiles with load reduction



67 | 155

Finally, Aran Islands pilot site’s optimizer was the most complex due to its heterogeneous

structure. Therefore, the model consisted out of three different Energy Hubs – one representing

houses without any renewable energy source generation or storage, one representing houses

with PV panels and without any storage infrastructure and the last one for the home with both PV

panels and battery. Even though this model has been developed, it has not been integrated with

in the platform so far, due to the fact that finalization of the pilot houses is in progress, so the

topology is not finalized yet.

Having developed appropriate optimization models, two different use cases using implicit and

explicit DR were defined. The implicit one is used for Madrid pilot site, as a result of dynamical

pricing, whilst for Aarhus and Aran DR event generator will be developed in order to simulate

explicit DR events depending on the typical demand and forecasted production of the renewable

sources. The example of implicit DR using time-of-use pricing is given in Figure , where price was

modified in order to reduce afternoon energy demand peak, but the average price has not been

modified. The effects that this change has on the load profile and on the imported power profiles

are given in Figure and Figure 50. The results for this case show that around 5% of energy

imported from the grid can be saved with the optimal use of PV energy dispatching and smart

utilization of the battery system. Savings are more significant with regards to the cost, with the

solution being reported as 20% cheaper in this case that the baseline output. Mainly due to the

savings in energy imported from the grid, the carbon footprint is also reduced, by around 13%.

Finally, apart from the simulation engine, optimization service has been deployed in order to

perform real time simulations with in the RESPOND platform. Namely, for each optimization within

the service demand and production forecasts are collected from the MySQL database and pricing

scheme if needed. In the end, results are again stored in MySQL database in order to be further

used for translation of the optimal profile to control actions suggested to the end user.


M13-M18 period:

Production forecast

With the aim of improving ecological interest, share of the renewable energy sources (RES) in

the energy production is to be increased. Nonetheless, that growth influences the grid’s instability,

as a result of the dependency between the RES production and weather conditions. Therefore,

with the aim of providing stable energy system, it is necessary to plan the consumption in

advance, with respect to the availability of the RES production. Therefore, the main goal of this

sub-task developing the service which should provide forecast for the RES available on each pilot

site – 2 photo-voltaic (PV) forecasters for Aarhus and Aran pilot and Solar thermal collector (STC)

forecaster for the Madrid one.

Within the workflow five steps were localized – State of the Art research, data collecting,

development of the prototype model, final model development and service deployment and

integration.

During State-of-the-Art review process, numerous potentially suitable techniques for RESPOND

use case were selected. In order to provide as high performance as possible, it was decided to



68 | 155

use a data-driven models if possible. Unfortunately, for Aran Island pilot, it might be the case that

not enough data will be available, in which case physical model will be deployed.

The next phase was consisted out of collecting necessary data – weather and production in order

to train models. Weather data was collected from the WeatherBit web service, as data with one-

hour time resolution was available both for the historical and day-ahead forecast, which were

conditions set by optimizer. Production data for Aarhus was collected from the Evishine service,

whilst Madrid’s was from the RESPOND’s InfluxDB. When Aran Island is concerned, only data

from two houses were available at the time this report is written, which is why it might be the case

that physical model will be deployed.

During prototyping, five different data driven techniques were tested (support vector regression

(SVR), linear regression (LR), neural networks (NN), k nearest neighbours (kNN), random forests

(RF)) and results were presented within the previous progress report. The best performance for

the PV production was achieved using NNs, whilst for STC it was the case when using RF, which

is why these models were selected for further use during the final model development phase.

During the development phase, necessary weather inputs were defined. Namely, both for PV and

STC as input parameters relative humidity, wind speed, pressure, UV, wind direction,

temperature, cloud coverage and global horizontal irradiance were used, whilst direct horizontal

irradiance, direct normal irradiance and previous productions were used only in case of STC.

Precisely, for each timestamp in which the forecast was to be given, this set of input parameters

is to be provided during service running phase.

When Aarhus pilot production forecaster is considered, NN has been trained in Python with the

mean absolute error (MAE) of approximately 8.5%. Performance of this model is illustrated in

Figure 51, and it was concluded that the estimation adequately represents the real production.

Therefore, this model was integrated within the RESPOND platform and deployed on the server

using Open Whisk. Integration required developing the component which collects the most recent

weather forecast data for the required timestamps from MySQL database and stores the provided

output back in the database in order to be further used by optimizer.

When Madrid is considered, RF model has been trained in Python and performed with MAE ≈

6.6%. It was then integrated with in the RESPOND platform to communicate with MySQL for

collecting weather data and information about the previous production, and finally for output

storage.

Development of the Aran Island pilot’s forecaster is in progress. Currently, the first version of the

service is deployed and integrated within the platform. This model relies on the Aarhus one, as

for the same type of RES. However, in the following weeks, the physical and data-driven models

will be compared, so in the following month the final more prices model will be deployed



69 | 155

.

Demand forecast

Regarding the demand forecaster, data-driven predictive models have been chosen. After

analyzing the performance of different state-of-the-art algorithms, best results were obtained with

Support Vector Machine (SVM) and k-Nearest Neighbours (k-NN) algorithms. After further

analyzing both algorithms, the k-NN was selected as it got the most accurate predictions.

Depending on the data availability, performance of forecasters varies, and three different

categories can be identified. On the one hand, predictive models with a good accuracy which are

able to predict daily schedules and routines, with a mean average error (MAE) below 90kW (see

Figure 52). On the other hand, less accurate predictive models with errors of different magnitudes

with MAEs over 125kW. Last but not least, predictive models that have a bad accuracy (see

Figure 53) with MAEs over 250kWs. These former two type of models don’t adjust well to the

dweller’s routine at certain time intervals, as there is not enough data to learn from them. More

historical data is required to train and adjust the model, which is foreseen to be achieved during

the last six months of the T4.4.

Figure 52 shows a predictive model with good accuracy for predicting the electric consumption of

a dwelling in Madrid. It can be seen that red dots (predicted consumptions) are rather close to

blue dots (real consumption). As for Figure 53, it compares the predictions made by a predictive

model with a worse performance with the real consumption of another house in Madrid. It can be

concluded that these predictions are not as accurate as the ones shown in Figure 52.

FIGURE 51. AARHUS PV FORCASTER



70 | 155

FIGURE 52. REAL VS FORECASTED ENERGY CONSUMPTION OF A PREDICTIVE MODEL WITH A GOOD

PERFORMANCE

FIGURE 53. REAL VS FORECASTED ENERGY CONSUMPTION OF A PREDICTIVE MODEL WITH A BAD

PERFORMANCE

Figure 54 and Figure 55 show the residuals of a predictive model with enough data, and a

predictive model developed with scarce data respectively. It can be seen that the quality of the

former model is better than the latter, as most differences between observed and predicted values

are closer to 0.

FIGURE 54. RESIDUALS OF A PREDICTIVE MODEL WITH A GOOD PERFORMANCE.



71 | 155

FIGURE 55. RESIDUALS OF A PREDICTIVE MODEL WITH A BAD PERFORMANCE.

The neighborhood consumption is also forecasted, leveraging the already developed predictive

models. As it can be seen on Figure 56, the developed predictive models have a good accuracy,

which is expected to be improved as more data is available.

FIGURE 56. FORECASTED VS ACTUAL ELECTRIC CONSUMPTION IN MADRID (NEIGHBOURHOOD LEVEL)

All these predictive models are periodically retrained in an automatic manner. As a matter of fact,

results are expected to be improved as more historical data is available.



72 | 155


This task started in M13 and ends in month 30. This task aims at integrating the outcomes of all

previous tasks of the WP in order to perform actual control actions and influence the load

according to cooperative DR strategies.

M13-M18 period:

Heuristics Optimization

As part of the work performed in the last six months, the holistic optimization approach shown in

Figure 57 has been undertaken. The holistic optimization module is in charge of generating the

adequate DR event for users, leveraging the energy demand and production forecasts (Task

T4.4.) and the optimal demand profile (Task 4.2) generated previously. Furthermore, the holistic

optimization module needs to calculate which is the best period of time to execute the

aforementioned demand side management actions, taking into consideration the previous

profiles.

FIGURE 57. HOLISTIC OPTIMIZATION APPROACH

User Preferences

Within Task 4.5, the user preferences have been collected in terms of the type of actions allowed

by each dweller (e.g. switching on or off), the appliances upon which these actions may be

performed (e.g. dishwasher or washing machines), the periods of time for these actions (e.g. from

19:00 onwards) and the type of notifications preferred by dwellers (e.g. informative, prescriptive

or none) among others. These preferences are used to develop a user profile for each dwelling,

which is leveraged by the User Adapter module to decide which DR events generated by the

Holistic Optimization module are the most suitable for each dwelling.

At the moment of writing this document, recommended actions are sent to users via mobile app

notifications. Then, users need to manually make those recommended actions. The T4.5 is

envisioned to be implemented in an incremental manner. Therefore, after analyzing how users

behave with these recommendations, recommendations with an action triggering option will be



73 | 155

sent to users. This way, users will be able to trigger specific actions as recommended by the

RESPOND platform. The final stage of this incremental approach would be the automatized

actions, where user lets the RESPOND platform decide which actions to perform. The last 6

months of this task are expected to enrich the user adapter module by receiving user feedback

on recommended actions, and therefore, for improving the overall performance of the DR event

recommendation system.

Building simulation model

Optimized control services on RESPOND platform is referred to the translation of results from the

optimization service into optimal control actions related to the building heating/cooling systems.

In particular, the developed service is based on a Reduced Order Model (ROM), which is a

simplified model of a building and its energy systems able to reproduce the effect of

heating/cooling control actions on indoor thermal comfort (mean indoor air temperature value).

The Building Reduced Order Model (ROM) is developed using the Modelica language. The

Modelica Standard library and IBPSA Project 1 Library (2018) have been used to develop the

elements of the model. During the last 6 months, further development has been performed to

reach a final version of the ROM.

The ROM is composed of the following four main components:

1) Internal Gains

2) Heating and Cooling

3) Building

4) Weather

FIGURE 58. ROM MODEL SCHEME



74 | 155

The methodology to develop the RESPOND service is composed by three main steps:

1. The Tool for the ROM parameters estimation which receives building data as input; 2. A .fmu file of the Modelica models described in the section above; 3. The ROMFit Python script for the model simulation and the automatic calibration.

A Tool has been created to estimate the parameters needed for the model. The information

needed by the Tool can be simply obtained during the tendering phase through data collection

and during on-site site surveys. In case of missing data, standardized packages and

associated parameter values have been provided to support good model parameters

estimation. Since the model considers the main physical dependencies among the variables,

the calibration phase is much simpler compared to a Whole Building Energy model. A

dedicated Python script (ROMFit) has been developed to simplify the parameter insertion and

increase the speed and accuracy of the calibration procedure using a FMU file (Functional

Mock-up Interface,2018) generated from JModelica.org (2018). By using ROMFit the model is

simulated and then, after the first simulation, it adjusts the uncertain parameters and simplifies

the model calibration and its verification using real data collected by the RESPOND platform.

The model is considered calibrated only if the model forecasting performances are within

verified statistical values from comparison with real measured data. The model will use the

inputs to generate several scenarios in terms of heating/cooling control actions (i.e shifting the

heating profile from 6 am to 8 am, instead of 7 am to 9 am) to reproduce the optimized thermal

energy profile for the next day, provided by the optimization service. In case the service is able

to find a proper scenario able to be complaint with both, the hard constrains defined by the

dwelling owner and the optimized thermal energy profile, a message, using the RESPOND

app, will be sent to the dwelling owner to perform (manually or automatically) the DR scenario

during the next day. In case the service is not able to find a successful solution, the DR

scenario will not be performed on the next day.

We are currently testing the ROM model accuracy. In case the ROM model accuracy will not

be sufficient to provide the optimal control actions for the heating/cooling system of the

dwelling, a contingency plan was developed.

A detail simulation model in IESVE simulation software has been developed for one dwelling

in Aran Island pilot. Most of the Aran Island dwellings, which has been retrofitted, have similar

characteristics (envelope, heating/cooling system, pv panels). The simulation model has been

calibrated using data collected from an SD card installed on the dwelling heat pump. The idea

is to generate a simplified version of that model and using it for Optimal control service in

RESPOND platform. The idea is also to extend the methodology to other dwelling with similar

characteristics in the Aran Island.


Overall, WP4 is proceeding well.



75 | 155

Deviations from GA:

Due to the delay of the early deployment of the devices in pilot sites, data coming from these

devices are not as many as expected. This shortage of data may difficult the development of data-

based predictive as well as building simulation models. Furthermore, data from different pilot sites

started to be recorded in different instants. Therefore, we foresee a difference in the performance

of predictive models of each pilot site.

Furthermore, models used for production forecast might differ from the ones used in Energy

Warden project. Having production data from pilot sites available, data driven models outperform

the physical ones.

Corrective actions:

In case the building simulation models based on ROM approach will not reach the requested

accuracy, a parallel methodology based on development/calibration of detail simulation models

in IESVE software is under testing phase as well.

T4.1 SEMANTIC INFORMATION MODEL. M7-M18

Deviations from GA:

Although in the GA ontologies such as BOnSAI and IFC were suggested, after the related

ontology analysis, it was concluded that other ontologies such as SEAS Feature of Interest (for

representing qualities and their features of interest) and BOT (for representing building topological

information) were more adequate.

Corrective actions:

No corrective actions are needed.

T4.2 INTEGRATION OF DEMAND RESPONSE WITH SUPPLY/DEMAND SIDE MANAGEMENT. M7-M24

Deviations from GA:

There are no deviations from GA.

Environmental factors like CO2 emissions reduction have not (yet) been taken into consideration

in the criterion function. The primary focus on the development that has been done is the

monetary aspect (i.e. energy and cost savings, operational costs).

Corrective actions:

The criterion function can easily be modified to include elements that depict the environmental

impact, however if that segment were to be included, it should be carefully specified not to

represent a linearly scaled version of the already included monetary aspect.



76 | 155

T4.3 OPTIMAL ENERGY DISPATCHING AT HOUSEHOLD AND NEIGHBOURHOOD LEVEL. M13-M24 IMP

Deviations from GA:


In cases where the pilot site is represented with a homogeneous set of households and where

the concept of multiple interconnected Energy Hubs could enable interaction between

participating entities (e.g. buildings in a district) in order to deliver an optimised energy exchange

and cooperative energy dispatching but having in mind that energy exchange between users

cannot be performed, modelling such a system (from a neighbourhood point of view) can be

considered redundant and should be avoided to increase performance.

Corrective actions:

Multiple interconnected Energy Hubs can be implemented in a simulated scenario as a research

effort to test the possibilities of peer-to-peer trading and similar concepts.


Deviations from GA:


Models used for production forecast differs from one used in Energy Warden project due to the

fact that having available data on production form pilot sites, data driven models outperform the

physical ones.

Corrective actions:

No corrective actions.


Deviations from GA:

The delay of the early deployment of the devices in pilot sites derives in a shortage of data, which

may in turn hinder the process of developing building simulation models.

Corrective actions:

No corrective actions are needed.






77 | 155


2.5.5 WP5: SYSTEM INTEGRATION AND INTEROPERABILITY

WP5 which lasts from M7 to M24 comprises 5 tasks related to system integration and

interoperability.

• T5.1 Home automation interoperability interfaces. M7-M18

• T5.2 Smart grid connectivity. M7-M24

• T5.3 RESPOND middleware development. M7-M24

• T5.4 Integration with desktop dashboard and smart mobile client. M19-M24

• T5.5 Data protection and security measures M19-M24

Although only first three tasks have officially started before M18 reporting period, initial work has

also been performed in tasks T5.4 and T5.5, to ensure continuity of other related tasks and work

packages.

In particular T5.4 started to ensure that development of mobile app can be advanced, and ready

for the first review meeting. Besides, T5.5 related to data protection and security was considered

from the beginning of development of all system component. In the sequel, we outline the work

performed in tasks T5.1, T5.2, T5.3 and T5.4.

FIGURE 1 - WP5: SYSTEM INTEGRATION AND INTEROPERABILITY GANTT CHART



78 | 155

T5.1, T5.2, T5.3, T5.4 and T5.5 has been carried out during the reporting period.


T5.1 HOME AUTOMATION INTEROPERABILITY INTERFACES. M7-M18

T5.1 has been carried out from M13 to M18 of the project according to the schedule. The goal of

this task was to deal with interoperability of RESPOND platform towards home automation and

building management systems, metering equipment (both energy and comfort), and energy

resources. In particular, it aimed to support integration of RESPOND platform with external

hardware and software systems, thus enabling not only acquisition of data, but also providing a

way to issue the control actions to be performed under the cooperative demand strategy. To

achieve this overarching goal, the concept of energy gateway will be deployed in the pilots. The

gateway comprises open software platform OGEMA as well as custom developed modules aimed

at integrating different RESPOND components and external systems: Develco custom firmware,

Energomonitor custom adapter, water consumption parsing service, and interface towards

external systems.

T5.2 SMART AND CONNECTIVITY. M7-M24 IMP

The goal of T5.2 is to support the connectivity of the RESPOND platform through an open

Application Programming Interface (API), enabling exploitation of data provided by smart grid and

third-party services (such as provision of energy prices, weather data, etc.). The current state of

the art has been revisited. In M18, the open API model was in the process of design and

implementation. It will act as a single endpoint for programmatic access to features such as DR

optimisation algorithms, forecasted energy consumption, performance evaluation, global ranking,

etc. and allow reuse of core RESPOND components by interested parties.

The component which integrates with weather API has been realized in CakePHP framework. It

has been configured to fetch the current weather data and weather forecasts from Weatherbit.io

service daily and hourly.

Weatherbit.io service provides http API at the following address:

https://api.weatherbit.io/v2.0/current?city=Raleigh,NC&key=API_KEY

which returns the data in JSON format:

https://api.weatherbit.io/v2.0/current?city=Raleigh,NC&key=API_KEY



79 | 155

FIGURE 60: WEATHERBIT.IO JSON FORMAT EXAMPLE

The data are stored in a MySQL database and made available to other components of RESPOND

system.

T5.3 RESPOND MIDDLEWARE DEVELOPMENT. M7-M24 IMP

The goal of this task is to develop a middleware which aims to integrate the core RESPOND

services, system components, deployed field level devices, external services, web dashboard

and mobile application. It will enable plug-and-play connectivity of deployed sensing and actuating

equipment with the rest of the RESPOND system in order to ensure collection, storage and

processing of data obtained by sensing devices, analytic services and external systems. The

RESPOND middleware is based on an open source publicly available software which is

commonly used in other similar systems:

• TICK stack – stack of different standalone software components which enable data

collection, processing and storage in an efficient and scalable manner.

• MQTT broker – supports lightweight MQTT protocol suitable for Internet of Things

applications with publish/subscribe messaging pattern.

The part of the middleware corresponding to data collection has already been deployed and the

data from pilot sites have been collected since Month 11 of the project, as shown in Figure 2. In

M18, deployment and integration of core RESPOND services as well as visualisation layer is

being performed.



80 | 155

FIGURE 2: RESPOND PLATFORM CHRONOGRAFT INTERFACE

T5.4 INTEGRATION WITH DESKTOP DASHBOARD AND SMART MOBILE CLIENT. M7-M24 DEXMA

As a summary, most of the activities under the Task 5.4 have been carried out according to the

project plan (GA Annex I). These activities can be classified in 2 categories depending on the

target platform they were dedicated. The two categories are: a) DEXCell dashboard, b) Mobile

platform.

DEXCell dashboard activities

EMS dashboard integration with RESPOND MQTT broker:

In this task the DEXMA’s development team has implemented a self-made solution in order to

retrieve the data sent from the pilot sites and insert into DEXCell data base. This was required in

order to work under the project Canonical Data Model. The solution was divided in 2 parts, the

bridge that connects the broker with DEXCell and the DEXCell device definition, according to the

new data origin.



81 | 155

FIGURE 61: EMS DASHBOARD INTEGRATION

Dwellings configuration plan

As the current project includes a huge number of Dwellings and it is expected to be able to classify

devices in room level a planning and design for the pilot structure has been done. Then helped

by the partners in charge of pilots, the updated list of devices is assigned to each location and

room.

Residential demand response analytic app definition:

The first draft of how the demand response events generated in the Analytic Services and

executed by the End User through the Mobile app should be displayed in the DEXCell dashboard

have been carried out.

KPI definition:

Support was given to the definition of KPI’s that will be used to allow the project partners and the

final users to get an outcome of the project and the product. Some example of these KPI’s are

presented in the list below:

• Consumption per square meter

• Consumption per cubic meter

• Consumption per inhabitant

• Consumption per square meter and inhabitant

• RES energy generated

• Energy generation/consumption balance

• Energy cost per year and inhabitants

• Energy cost per year and square meter

• Energy cost per year

• Electricity energy consumption

• Thermal energy consumption

Mobile platform activities

Infrastructure preparation:



82 | 155

In order to prepare a smooth integration between. The two platforms several subtasks have been

carried out. Main ones were related to configuration: account settings, permissions, etc

Also, some technical changes were required in the DEXCell’s API in order to share the data

gathered from devices subscribed in the project’s MQTT broker.

Integration support:

DEXCell already has different solutions in order to interact with other apps. To prepare the

integration with the mobile app support has been done to TEKNIKER, the partner in charge of the

app. Both companies have worked hand to hand to design the best approach for the users’ needs.

T5.5 DATA PROTECTION AND SECURITY MEASURES. M19-M24 IMP

The goal of this task was to undertake proper security measures in order to deal with possible

communication threats that RESPOND system may encounter in relation to data collection,

transmission and storage. In order to ensure this, a complete end-to-end data protection

measures have been designed and implemented. In particular, RESPOND has implemented

encryption of communication links and internal data storage as well as implementation of client

authorization. Whenever possible, standard encryption and data protection mechanisms for ICT

systems have been employed. In addition, RESPOND has deployed authorization mechanisms

where user will be given specific access rights depending on user role, whether it be building

inhabitant, building manager or energy provider personnel.



In the context of the RESPOND project, the project partners have designed the architecture of

the system so that interoperability is supported from the beginning. Besides, the goal of the

RESPOND project is to complement and enhance the existing smart home and building

management systems, with the aim to improve the energy efficiency and optimize the costs by

seamless integration of cooperative DR programs.

In Figure 1, we present the interfaces among different components of RESPOND platform. As

can be seen, field level devices (Develco and Energomonitor), Energy gateway OGEMA, and

water consumption custom adapter use MQTT protocol for monitoring data and control action

transfer from/to RESPOND platform. On the other hand, external systems (weather and energy

pricing services), Energy manager dashboard (Dexcell), and Smart mobile application use

standard HTTP protocol for integration with RESPOND.



83 | 155

FIGURE 1: RESPOND PLATFORM CONECTIONS

D5.1 was completed and submitted on time successfully.

T5.2 SMART AND CONNECTIVITY. M7-M24

Information regarding energy pricing is crucial in energy management systems and it allows

optimal scheduling of energy consumers by also considering the forecasted energy prices. Based

on this requirement of the RESPOND project, a custom API module has been developed, which

allows the energy providers for all pilot sites to input the current and future energy prices. This

information is stored once a day in a RESPOND platform’s central database, and it is made

available to other platform and external services via secure API.

An example of the request body used to save the energy pricing is given as follows:

0

MQTTbroker

DevelcoGateway

EnergomonitorGateway

MQTT client

MQTT client

Telegraf

InfluxDB

TICK

Kapacitor

Chronograf

MQTT client

0

Analytic services

MQTT client

Production Forecast Demand Forecast

Local Optimization Global Optimization

Building Simulation Optimized Control

Predictive Maintenance

SemanticRepository

AnalyticRepositiory

Energy GatewayOGEMA

Adapter (API)

External Systems (Aggregators,

Weather)

Energomonitor cloud

EnergomonitorBridge service

EMSDesktop Dashboard

Smart Mobile App

EMS Platform (DEXCell EM)

Water consumption custom adapter



84 | 155

T5.3 RESPOND MIDDLEWARE DEVELOPMENT. M7-M24 IMP

The goal of this task was to develop a middleware which aims to integrate the core RESPOND

services, system components, deployed field level devices, external services, web dashboard

and mobile application, as it is shown in Figure below:

FIGURE 62 RESPOND PLATFORM ARCHITECTURE

It will enable plug-and-play connectivity of deployed sensing and actuating equipment with the

rest of the RESPOND system in order to ensure collection, storage and processing of data

obtained by sensing devices, analytic services and external systems.

The part of the middleware corresponding to data collection has already been deployed and the

data from pilot sites have been collected since Month 11 of the project. In addition, deployment

and integration of core RESPOND services has been performed by using Apache OpenWhisk

(see Figure below):



85 | 155

FIGURE 63 APACHE OPENWHISK HIGH LEVEL ARCHITECTURE (SOURCE: CLOUD.IBM.COM)


During the period M19-M24, the following tasks have been carried out according to the plan: Task

5.4 Integration with desktop dashboard and smart mobile client (DEXMA).

During the period M13-18 the preparation and plan for the different activities was carried out. The

requirements for the desktop dashboard and the smart mobile client were defined. During the

period M19-24 these activities were done separately for the two partners: Dexma and Tekniker.

Dexma in charge of desktop dashboard integration and Tekniker of smart mobile client.

The following figure presents the place of each module in the RESPOND platform. It can be

observed that desktop dashboard and smart mobile client are two separated modules, that target

different end users. However, there is shared information between the two modules.



86 | 155

FIGURE 64: RESPOND PLATFORM MODULES DIAGRAM

The activities carried out during M19-24 period are explained separated between the two modules

here below.

Desktop dashboard integration

In the RESPOND platform (based on DEXCell EMS), the desktop dashboard has two specific

objectives: i) analyse the project results, and ii) allow energy managers to monitor the building

properly so they can help the residents.

According to these two objectives, several functionalities were defined from the DoW (Description

of Work) in the GA (Grant Agreement) and story mapping sessions to understand which would

be the expected user experience. The following activities were carried out according to the

planned tasks on these planning processes. Note that the following mentioned features are

extensively explained in D4.5.

EMS dashboard configuration

The present activity objective was to prepare the RESPOND monitoring platform, which is based

on DEXCell EMS, to be used for the dashboard desktop specific objectives. This includes:

• Device status validation

• Location configuration

• Metadata configuration

• Features configuration



87 | 155

This monitoring platform configuration has been possible thanks to the previous development of

tasks in WP1, 2 and 4, that connected DEXCell to the RESPOND platform.

Each of the previous bullets have been done for each of the pilots’ buildings and dwellings and in

collaboration with the pilot coordinators. The following figure shows the current hierarchical tree

of pilot sites:

FIGURE 65: HIERARCHICAL TREE OF PILOT SITES IN DEXCELL

The different features configured for the platform are further explained in D5.4, however here

below are listed and briefly explained:

• Consumption analysis Feature that displays the energy consumption for electrical, gas and thermal. It can also

display water consumption. Different time windows can be displayed and with different time

scales.

• Cost analysis The energy cost can be configured by means of energy supply contracts that are related

to specific devices. From it an accurate economic project analysis can be done.

• Comparison Specific periods for consumption device can be compared in the same chart to compare

specific behaviours or anomalies.

• Comfort Temperature and humidity parameters are displayed in different time windows and with

different time scales.



88 | 155

• Carbon emissions It allows to track the CO2 footprint for a specific device. The CO2 emission calculation can

be customized depending on the energy source.

• Map rankings Depending on different ratios (previously configured according to the project KPIs) the

project dwellings can be ranked either by pilot site or per building.

• DR event tracking Brand new feature developed for the purpose of tracking the DR events sent through the

RESPOND platform. The DR event will be displayed on a consumption chart, which will

allow to later analyse the impact of the events in the consumption curves.

DR Event tracking functionality definition

According to the module specific objectives and the task’s DoW, it was required to display the DR

event in the platform. The development of this feature has been carried out in task T4.5, however

it was on this task where it was defined. Some meetings and story mapping sessions were done

internally in Dexma, followed by meetings with the rest of consortium partners (under T5.2

activities), ended with the definition of this feature.

Support to pilot coordinators

In order to let the pilot coordinators, use the platform with all its potential individual demos and

tutorials were done. The pilot coordinators where instructed by Dexma support team in how to

analyse the different dwellings and to keep a proactive attitude in the platform maintenance. This

way pilot coordinators can ensure residents are engaged and can give them full support.

Platform KPI preparation

While configuring the platform some meetings were held with some of the technical partners in

order to validate which of the project’s KPIs could be analysed using DEXCell EMS. This was

done under task 6.1 is led by NUIG.

The following table was done by Dexma to explain which of the KPIs are already displayable in

DEXCell, which steps are required to configure them and also which KPIs were not possible or

require further development.



89 | 155

TABLE 6: DEXCELL KPIS

Type KPI DEXCell Comments

Energy Renewable total energy

consumption Possible

You can visualize this kind of data as a ratio or

create a virtual device to get the % output

Energy Savings

Possible with

developments

If a DP can be send with 1 or -1 values to indicate

when the event takes place, this can be

performed in DEXMA

CO2 Reduction of greenhouse gas

emissions Possible Carbon Emissions App

Demand Peak load reduction Possible Virtual devices App and Advanced Analytics

Rescheduled Demand

Possible with

developments

If a DP can be send with 1 or -1 values to indicate

when the event takes place, this can be

performed in DEXMA

Analytical services accuracy Possible Virtual devices

Economic

Capex – Capital Expenditures Possible

If you want this as a Datapoint, it can be imported

as a turnover (cost parameter)

Economic savings during the

DR Event Possible

If the 2 costs inputs are DPs, this can be achieved

through Virtual Devices App

Economic operational cost

savings - OPEX Difference Possible

If the 2 costs inputs are DPs, this can be achieved


Security

Data security control

Possible with

developments Specific data point should be created

System

operation

Coefficient of performance –

COP Possible

If the 2 time inputs are DPs, this can be achieved


Communication performance Possible

If the 2 inputs are DPs, this can be achieved


User

DR campaigns penetration Possible



Number of user manual

actions Possible



Comfort

Indoor Air Quality - IAQ

Possible with

developments

Not possible unless we add conditions in Virtual

Devices App

Thermal comfort

Possible with

developments Specific data point should be created



90 | 155

Deliverable preparation

Deliverable D5.4 - Desktop dashboard and smart mobile client was prepared in collaboration

with Tekniker and presented according to the plan presented on the project plan.

Smart mobile client

In the RESPOND platform, the personal energy performance assistant service is based on a

smart mobile client. This mobile app is aimed at engaging users and involving them in Demand

Response programs, therefore, it is multiplatform (both for Android and iOS) and multilingual (in

English, Spanish and Danish). Thanks to the mobile app, the user not only visualizes energy-

related consumption and generation, but also receives optimal DR strategies proposed by the

optimizer and acts over different devices and appliances.

The following activities were carried out according to the planned tasks on these planning

processes. Note that the following mentioned features are extensively explained in D3.4 and D5.4.

Implementation of security mechanisms

In order to ensure the identification, authentication and authorization within the RESPOND mobile

app, an LDAP hierarchical directory service has been implemented. Namely, an OpenLDAP

server version 1.2.5 has been implemented to manage the access control, that is, to manage

what type of access (e.g. read or write) should each user have with regards to the available

resources. In order to easily configure such access control list, a phpLDAPadmin Server version

0.0.8 has also been deployed, which provides an intuitive graphic interface. Figure 66 shows a

snippet of the RESPOND mobile app’s hierarchical directory service.

FIGURE 66: LDAP SERVER FOR RESPOND MOBILE APP'S ACCESS CONTROL.



91 | 155

Implementation of notification services

The communication of optimal DR events and other notification messages to users is foreseen to

be made via the RESPOND mobile app. That is, each user will receive (according to the set of

preferences that he/she has defined) notifications in the RESPOND mobile app which may refer,

for example, to of potential energy-saving opportunities. Towards that goal, a notification service

based on Google Firebase Cloud Messaging (FCM) has been implemented. FCM is a cross-

platform solution for delivering messages. In the case of the RESPOND mobile app, these

messages are sent in the form of push notifications. Figure 67 shows the sequence diagram of

module interactions to send a notification to the user.

FIGURE 67: NOTIFICATION FLOW

Users receive the system notifications via “Push” messages received in their smartphones.

Received messages could be also viewed in the RESPOND app’s notification list in case the user

finds it necessary or if they arrived at a time that was not convenient for the user to read it.

User engagement

Task 3.3 “Detailing the user context and improvements of user interaction” deals with the best

way to engage to the users with Demand Response actions. The personal energy performance

assistant is the main tool towards this engagement and its design has been modified to adopt the



92 | 155

recommendations concluded in this task. These recommendations address the information

shown to the user, as well as the appearance and understandability of the app.

Development of a proxy server

The proxy server is the intermediary that deals with the calls to different services, thus alleviating

the heavy load that would otherwise be in the mobile app. For example, when a user wants to

visualize the energy consumption of a given appliance, the proxy server is the component that

handles the message exchange between the LDAP directory (to gran user’s authentication), the

Virtuoso semantic repository (to get the appliance’s information) and the InfluxDB time series

database (to retrieve the appliance’s energy consumption). Figure 68 depicts the role of the proxy

server.

FIGURE 68: RESPOND MOBILE APP'S PROXY SERVER.

Mobile app publication in marketplaces

Once the RESPOND mobile app has been developed, it needs to be published so that project

participants can download and install it in their smartphones. Since the app has been developed

both for Android and iOS, it needs to be published in both marketplaces. The publication of the



93 | 155

app is an ongoing work. The Android version is already published in the Alfa channels, which is

the previous stage to the publication in Google Play, and the version for iOS is published in

Apple’s Testflight environment, which is the previous step to be published in the App Store (see

Figure 69). The process of publishing a mobile app in each platform differs, and different

requirements needs to be addressed prior to their acceptance.

FIGURE 69: RESPOND MOBILE APP'S PUBLICATION IN APP STORE.


Security in RESPOND platform is not implemented via particular software component. Instead, it

is implemented with a set of tools and mechanisms already provided by different components that

are part of RESPOND architecture. The components of RESPOND system are deployed in a

private cloud environment, which have many advantages, especially in terms of security. The

communication between different parts of RESPOND platform can be rigorously controlled to

prevent any misuse. Besides, the access point that consortium software developers need for

implementation of RESPOND analytic service (e.g. Secure Shell - SSH) can be completely

separated from the one necessary for public use by external software developers (Open API) or

end-users (mobile application and web dashboard).

In order to be able to identify different security measures to be applied, it is necessary to identify

different stakeholders which provide or consume collected data in RESPOND platform, as it is

shown in Table 7 below:



94 | 155

TABLE 7: RESPOND STAKEHOLDERS

Stakeholder Notes

Household tenants Household tenants allow installation of home automation

devices in their household. They use services developed by

RESPOND project consortium partners via custom developed

mobile app.

Energy/building managers Energy/building managers access the collected and analysed

data via Dexcell dashboard.

Third-party service providers Provide information necessary for correct functioning of

RESPOND analytics services, such as energy prices, weather

observations and forecast.

Smart grid operators RESPOND platform is connected to smart grid operators that

can exchange information and can send DR signals to

RESPOND platform.

Consortium software

developers

Develop RESPOND analytic services and provide application

program interface (API) to allow other interested stakeholders

to use part or whole RESPOND system.

External Software developers External software developers can use RESPOND analytic

services based on the credentials (e.g. API key) provided by

RESPOND project.



Deviations from GA:

N/A

Corrective actions:

N/A

T5.2 SMART AND CONNECTIVITY. M7-M24

Deviations from GA:

Currently, in the consortium there exists no connection to DR aggregators.

Corrective actions:



95 | 155

A custom developed component will be developed as a replacement to DR aggregators. This

component will generate DR signals which will be used as an input for other RESPOND system

components, as shown in Figure below:

FIGURE 70 DR EVENT DATA FLOW

T5.3 RESPOND MIDDLEWARE DEVELOPMENT. M7-M24

Deviations from GA:

N/A

Corrective actions:

N/A


Deviations from GA:

N/A

Corrective actions:

N/A


Deviations from GA:

N/A

Corrective actions:

N/A



96 | 155





2.5.6 WP6: VALIDATION AND REPLICATION OF PROJECT RESULTS

WP6 runs from M13 to M36. This work package develops a specific validation methodology for

RESPOND demonstration results. It is closely related to outcomes from pilot characterization

(WP1) and use case deployment (WP2). To achieve this, verification and validation of the

RESPOND solution at three pilot sites will be conducted by monitoring the performance of

installed and integrated ICT solution for a minimum of 12 months and compared the outcomes

with the baseline period of the previous 12 months.

The main objectives are:

• Development of specific validation methodology and definition of acceptance criteria.

• Verification and validation analysis of obtained results at the project pilot sites.

• Feedback extraction of the user engagement for evaluation non economical aspects.

• Development of replication plan ensuring maximal scalability of project results.

• Reporting on lessons learnt and recommendations for similar activities.

• Demonstration of effective operation scenarios through validation results.

FIGURE 2 - WP6: VALIDATION AND REPLICATION OF PROJECT RESULTS GANTT CHART



97 | 155


T6.1 VALIDATION METHODOLOGY AND ACCEPTANCE CRITERIA. M13-M18 NUIG

T6.1 started in M13 and it ends in M24. The aim of this task is to define RESPOND validation

methodology able to provide an assessment of project results and related use cases from the

perspective of energy/cost saving, carbon emission reduction and economic sustainability.

The main activities carried on during the first six months of the task can be summarized as follows:

• Literature review to complete the list of relevant KPIs provided as output of WP1; • Update of measurement points and information available for each pilot site to reach the

user requirements defined in Task3.1 and assure the user acceptance considering system performance, indoor thermal comfort, functionality, usability, security and safety;

• Analysis for a further definition of DR scenarios to be applied to the pilot test cases, taking into account available measurement points, control actions and information;

• Literature review related to IPMVP protocol for performance measurement and verification, EU initiatives for energy savings measurements.

• Definition of table of content for D6.1

T6.2 VALIDATION ANALYSIS AND REPORTING. M16-34 NUIG

T6.2 started in M16 and it ends in M34. The aim of the task is to collect and analyse all the data

produced in the pilot tasks and by operation scenarios. Validation analysis will be carried out by

monitoring the performance for installed and integrated RESPOND solution for baseline and

reporting period.

T6.3 QUALITATIVE EVALUATION OF USER EXPERIENCES AND RECOMMENDATIONS. M16-34 AAU

This task runs from M21 to M34. The aim of the task is to report on the overall user engagement

and satisfaction during the RESPOND demonstration activities at pilot sites and in interaction with

system itself. In the last month of the trial, it is planned to carry out two focus groups at each site

with pilot households, which should provide the basis for a detailed qualitative analysis of user

experiences and the users’ own recommendations for possible further improvements. In addition,

a survey targeted all pilot households is carried out to measure general user attitudes and

experiences in relation to the pilot. On basis of the focus group and survey outcomes, this task

uncovers the impact of social competition among end consumers as part of district and residential

communities. The task will also report on best practices and recommendations on how to further

motivate and engage end users to participate in DR activities, the role of social norm compliance

in end user engagement, and document project findings and statistical results regarding the user

engagement.



98 | 155

T6.4 REPLICATION AND DEVELOPMENT. M23-M34 FEN

T6.4 begins in M23 and ends in M34. The goal of this task is to clearly identify and analyse all

possible RESPOND opportunities for replicating of its products and services.

In this regard, the tasks that have been started are:

• Market analysis in order to exploit the real needs for DR services

• Analysis of involved stakeholders

The following tasks will be performed during the third year of the project:

• Alternative business models for energy services taking into account main RESPOND

functionalities

• Incentives and identification of potential non-technical barriers and risks for new business

and service models


During the last six months (M19-M24) the main activities of WP4 have been:


The aim of this task is to define RESPOND validation methodology able to provide an assessment

of project results and related use cases from the perspective of energy/cost saving, carbon

emission reduction and economic sustainability.

To do so, the following sub-tasks has been performed:

• Review of the state of art of Measurement & Verification (M&V) methodologies, focused

Demand Response (DR) application;

• Review of current Key Performance Indicator (KPI) already validated in other ongoing EU

DR projects;

• Final selection and definition of KPIs;

• Development of a specific M&V methodology, using RESPOND services from data

collection to baseline definition;

• Definition of specific DR use cases per pilots in terms of RESPOND validation

methodology: data monitoring, RESPOND services involved, KPIs calculus;

• Definition of a recovery plan for RESPOND solution testing and application, due to missing

data for late deployment of monitoring equipment on pilot site;

• The D6.1 due to M24, but it is still under finalization due to baseline checking and recovery

plan definition;



99 | 155


Due to delay on T6.1 for baseline checking and recovery plan definition, the task is still on the

phase of optimization of the data flow inside the RESPOND platform for validation purpose, in

order to collect and analyse all the data in best way.


The task commenced a few months before the time of reporting, and activities have so far been

limited. This is due to that the detailed planning of the task should be based on first experiences

from the pilot demonstrations that begin around the time of reporting. However, within the coming

2-3 months, detailed plans and guidelines for carrying out the focus groups will be prepared, and

the questionnaire will be set up.

As part of this, it might be considered if it would be relevant and more informative to combine the

focus groups with qualitative interviews of individual households – perhaps by combining one

focus group at each site (instead of two) with a few qualitative in-depth interviews. The benefit of

doing qualitative interviews could be to get a deeper insight into how the individual

residents/households experience the RESPOND demand response solutions on a day-to-day

level and how it affects their energy consumption practices.

T6.4 REPLICATION AND DEVELOPMENT. M23-34 FEN

At this stage of the project there are not substantial results yet. In a later stage, during the third

year of the project, when RESPOND solution will be completed defined, the replication plan will:

• capture all pertinent project knowledge that supports the adoption and utilisation of

RESPOND solution by non-consortium members

• ensure maximum possible scalability of project results.

• include the methodology, approach, analysis and benchmarking of DR solution, parts of

the software development, interoperability design, and all practical and technical

information for design, engineering, installing and commissioning RESPOND compliant

solutions learned from the pilot activities.

The design and development of sustainable and coherent business models is mandatory in order to guarantee the address of the effective exploitation of the delivered results. The following tasks will be performed:

• Risk management methods and mitigation in delivering a RESPOND solution to buildings and households will be analysed.



100 | 155

• Guidelines will be defined to assure the dissemination of the replication plan to all relevant private and public organizations identified over the course of the project.



Deviations from GA:

The T6.1 supposed to finish in M24, the task continued due to late deployment of measurement

and control devices in pilot sites. The delay produced the need of additional time for baseline

checking and recovery plan definition.

Corrective actions:

A recovery plan will be included in D6.1, taking into account RESPOND solution testing period

and application.


Deviations from GA:

The T6.1 supposed to finish in M24, the task continued due to late deployment of measurement

and control devices in pilot sites. The delay produced the need of additional time for baseline

checking and recovery plan definition.

Corrective actions:

A recovery plan will be included in D6.1, taking into account RESPOND solution testing period

and application.


Deviations from GA:

N/A

Corrective actions:

N/A

T6.4 REPLICATION AND DEVELOPMENT. M16-34 FEN

Deviations from GA:

N/A



101 | 155

Corrective actions:

N/A





2.5.7 WP7: DISSEMINATION AND EXPLOITATION ACTIVITIES

During the period M13-M24, the following tasks have been carried out according to the schedule:

• Task 7.1 Dissemination and communication strategy (DEXMA)

• Task 7.2 Products, services and supporting business model definition (FEN)

• Task 7.3 Data life cycle management (FEN)

• Task 7.6 Contributions to EASME dissemination activities (FEN)

FIGURE 3 - WP7: DISSEMINATION AND EXPLOITATION ACTIVITIES GANTT CHART



102 | 155


T7.1 DISSEMINATION AND COMMUNICATION STRATEGY. M1-M36 DEXMA

As a summary, dissemination about Respond Project has been carried out according to the plan

defined on deliverable 7.1 (submitted in M6) using also the project website (defined on deliverable

7.2).

a. Targets of dissemination

The different stakeholder groups have been identified, such as General public,

commercial/industrial stakeholders, scientific community, together with the conferences,

workshops and events. Besides the dissemination KPIs have been defined together with the

collaboration with other projects.

b. Project identity

b.1. RESPOND Blog

The following articles have been published in the second year of work:

• RESPOND in the News: Alboa Magazine spotlights the project • 4 differences between Demand Side Management & Demand Response • The role of DR in Smart Cities • Meet the Madrid Pilot Site • The key points of Respond Project in 2018 • Demand Response and Space Heating Practices in Homes • Semantic Technologies for Integrating Demand Response Data • RESPOND Events: RESPOND was at Sustainable Places 2019 • Project News: Devices deployed at the Aran pilot Site • Integrating Building and IoT data in Demand Response solutions • Optimising the energy demand of neighbourhoods under DR umbrella • RESPOND Events: We were at the ECEE Summer study 2019 • RESPOND Events: We were at ETSI IoT Week 2019

The updated 2019 publication list and publication plan can be observed on the following table.

TABLE 8: LIST OF PUBLICATIONS

Publication Date Forecast

Proposed Blog Posts Topics Responsible Partner

Suggested Partners Accepted Status Contact

Name

March Project Update: Project RESPOND Looks Back on 2018 DEXMA yes Published Andreu

April Demand response and heating practices in homes AAU (Aalborg University)

yes Published Henrik & Toke

http://project-respond.eu/respond-alboa-energy-consumption/

http://project-respond.eu/4-differences-between-demand-side-management-demand-response/

http://project-respond.eu/the_role_of_demand_respond_in_smart_cities/

http://project-respond.eu/meet-the-madrid-pilot-site/

http://project-respond.eu/2019/03/

http://project-respond.eu/demand-response-space-heating-practices-in-homes/

http://project-respond.eu/semantic-technologies-for-integrating-demand-response-data/

http://project-respond.eu/respond-events-respond-was-at-sustainable-places-2019/

http://project-respond.eu/project-news-devices-deployed-at-the-aran-pilot-site/

http://project-respond.eu/building-iot-data-demand-response/

http://project-respond.eu/optimising-the-energy-demand-of-neighbourhoods-under-dr-umbrella/

http://project-respond.eu/respond-eceee-summer-study-2019/

http://project-respond.eu/respond-events-at-etsi-iot-week-2019/



103 | 155

May Semantic repository. Potential to enhance management of DR programs

TEKNIKER yes Published Iker

May Article written by TEKNIKER: LDAC TEKNIKER yes Published Iker

June RESPOND Events: Meet us at our Workshop in LDAC2019 DEXMA TEKNIKER yes Published

June RESPOND Events: RESPOND was at Sustainable Places 2019 DEXMA yes Published

June Project News: Devices deployed at the Aran Pilot Site ARAN yes Published Avril

July Integrating Building and IoT data in Demand Response solutions DEXMA yes Published Elodie

July Optimizing the energy demand of neighborhoods under DR umbrella PUPIN yes Published Marko

Jelić

August

ECEEE Summer Study 2019 - https://www.eceee.org/summerstudy/ And here’s the reference:Christensen, T. H., Larsen, S. P. A. K., & Knudsen, H. N. (2019).

AAU (Aalborg University)

yes Published Toke

August Measures of Demand Response in isolated countries (comparison in europe)

ENERGOMONITOR Never replied

September NEWSLETTER TEKNIKER - http://www.newtek-tech.es/newtek/boletin/28/proyecto4.php

TEKNIKER Yes Email Sent Francisco Javier Díez

September Utilities becoming more customer-centric FENIE yes

Sent reminders 26/09 + 21/10

Agustina

October ETSI IoT Week 2019.I will present the ontology-based approach we are using in RESPOND to integrate Building and Sensor Data.

TEKNIKER yes Iker

October Demand Flexibility TEKNIKER yes Iker

b.2. RESPOND in the Press

Within our aim to reach general and technical public, the project has also had some buzz on the

press. These press articles are included in the blog whenever possible:

• Energiwatch (Denmark) • Energysupply (Denmark) • Europapress (Spain) • El Economista (Spain) • Energias Renovables (Spain) • Teinteresa.es (Spain)

During this period an article and dissemination campaign was launched in Open Access

Government online magazine. The following table summarizes the campaign actions.

https://www.etsi.org/events/1601-etsi-iot-week-2019

http://project-respond.eu/respond-news-energiwatch/

http://project-respond.eu/respond-in-the-news-energy-supply/

https://www.europapress.es/economia/energia-00341/noticia-fenie-energia-coordina-proyecto-europeo-buscar-soluciones-eficiencia-energetica-hogares-20180605113155.html

https://www.eleconomista.es/economia/noticias/9185217/06/18/Fenie-Energia-coordina-un-proyecto-europeo-para-buscar-soluciones-de-eficiencia-energetica-para-hogares.html

https://www.energias-renovables.com/ahorro/respond-un-proyecto-europeo-que-busca-soluciones-20180605

http://www.teinteresa.es/dinero/empresas/Fenie-Energia-soluciones-eficiencia-energetica_1_2027807221.html



104 | 155

TABLE 9: LIST OF ARTICLES

Open Access Government

June 2019

Stakeholder page + display banner

https://www.openaccessgovernment.org/category/stakeholders/energy-stakeholders/ . // . https://www.openaccessgovernment.org/respond-project-active-demand-management/67203/

- 2 pages article - 1 stakeholder page - 1 online banner => 3000€

Published

Open Access Government

October 2019

Article published in their online magazine

http://edition.pagesuite-professional.co.uk/html5/reader/production/default.aspx?pubname=&edid=0d5ad7a6-fb33-40ea-b275-9a1234b94ddb&pnum=362

Published

b.3. RESPOND Social Media

RESPOND Twitter

We have been working with official RESPOND project twitter account to spread the news about

the project and other news related to it.

RESPOND LinkedIn

Same as above, all materials related to the project have been shared on the official LinkedIn

group of the project.

RESPOND Facebook

We have also used Facebook as another channel to share the news about the project.

RESPOND Video

A 1-minute video that explains the project scope in a simple and direct way has been done in

English, Spanish and Danish. It will be done by the end of April to be used on social media,

events, etc.

b.4. RESPOND Materials

RESPOND Roll Up

A roll up that will be used in events has been done.

https://www.openaccessgovernment.org/category/stakeholders/energy-stakeholders/

https://www.openaccessgovernment.org/category/stakeholders/energy-stakeholders/

https://www.openaccessgovernment.org/respond-project-active-demand-management/67203/







https://twitter.com/project_respond

https://www.linkedin.com/groups/8648278

https://www.facebook.com/EUProjectRESPOND/

https://www.youtube.com/watch?v=EeWLCJIZtTc

https://www.youtube.com/watch?v=jrRfNqgJyrY

https://www.youtube.com/watch?v=ihyCj4t6sD4



105 | 155

FIGURE 4 - RESPOND ROLL UP

b.5. RESPOND Website

A website was built in the first period for RESPOND Project, to serve as the main platform for

dissemination and communication to interested stakeholder: http://project-respond.eu/.

FIGURE 73: RESPOND WEB PAGE

RESPOND Repository

A dedicated section for the deliverables has been included within RESPOND website. Thus, the

whole list of public reports and deliverables can be downloaded by everyone.

http://project-respond.eu/



106 | 155

FIGURE 74: RESPOND PUBLIC DELIVARABLES REPOSITORY

Also, further publications such as scientific articles, will be added to the website:

FIGURE 75: RESPOND PUBLICATIONS SECTION

RESPOND SEO

Search Engine Optimization has been reviewed for each page of RESPOND website.

• Meta descriptions • Meta Titles • Keywords • Internal links

This helps the website to get visibility on Google Search Engine for Demand Response focus

keyword, and thus appear in the first positions of the results page.

FIGURE 76: RESPONS ARTICLE EXAMPLE

b.6. Respond Events

The attendance to the following events has been arranged by DEXMA:

• Sustainable places 2019 -> 05/06/19.



107 | 155

• EU Sustainable Energy Week + Article publication in the European Energy Innovation Magazine -> 18/06/19.

• Energy Utility week -> 12/11/19.

T7.2 PRODUCTS, SERVICES AND SUPPORTING BUSINESS MODEL DEFINITION. M13-M36 FEN

This task investigates innovative business models for the services that RESPOND can enable.

• The value system and the target market sectors involved in the potential business

opportunities for the outcomes of the project have been studied.

• Collaboration opportunities are being studied and will be exploited with a focus on scaling

to commercialization.

• A deep market analysis and a competitive analysis have been started to performed to get

a clear insight of market size, potential market growth rate, actors, as well as potential

competitors.

• The technical and non-technical barriers to enter the market and the regulatory restrictions

are being investigated.

• A SWOT analysis has been done, based on Canvas Business Model

T7.3 DATA LIFE CYCLE MANAGEMENT. M13-M36 FEN

This task will address a usual problem that recently has gained importance because the increased value of the data due to the new exploitation possibilities. In this project a several types of data are being monitored. This data includes data related to the participant’s behaviour and this type of data is very sensitive because their privacy considerations. This project is an integration project and therefore several companies are involved in the data life cycle. The technical solution for secured and anonymized data is defined in T5.5 but this solution has been complemented with a clear agreement of how all the data is managed in their life cycle starting at the time that is acquired and following by their management including sharing until the data must be destroyed. Considering that this is a European project, legislation of different countries has been taken in account and European directives in this area. An important input was the Big Data Value public private partnership (BDVA PPP). The task has followed the recommendations produced by the task force 5: Legal (Policy and Regulation) of this association for creating a framework that allow the adequate data treatment without invading the household habitant’s rights.

T7.6 CONTRIBUTION TO EASME DISSEMINATION ACTIVITIES. M1-M36 FEN

This task contributes, upon invitation by the EASME, to common information and dissemination activities to increase synergies between, and the visibility of H2020 supported actions. Moreover, this task envisions participation in the activities organized by EASME, such as training for coordinators, exchange meetings with other H2020 contractors, making presentations in high level conferences, and giving feedback on the impact of projects.



108 | 155



RESPOND Google Analytics (updated)

Comments M13-M18: Clear increase of the traffic at the beginning of March, thanks to the

optimisation of the Google Analytics parameters.

On 12th of March, Google released a new algorithm called Florida2 that affected a lot of websites

in terms of ranking, what explains the drop.

Bounce rate is a little high and could definitely improve through the new publications.

Session duration has a good average.

FIGURE 77: RESPOND WEB ANALYTICS EXAMPLE 1




109 | 155

Comments M13-M18: we acquire most of our audience through Organic & Direct Search.

Funnels by order:

• Organic: our content appears on Search Navigators after a user looked for keywords such as: Demand Response, Residential Energy efficiency, etc.

• Direct: users search RESPOND on the Navigators. Also, a bit of Organic Search appears in that section.

• Social: posts published on FCBK + Twitter + LinkedIn. • Referral: websites that talk about RESPOND. • Other: Include repository, deliverables, referral campaigns

Spain is where most of our audience comes from followed by India and the UK.


The page that receives more traffic talks about the difference between Demand Side Management

and Demand Response: http://project-respond.eu/4-differences-between-demand-side-

management-demand-response/ .

The top device used to visit the website is the desktop, with 550 users over the last 90 days

versus 98 users with mobile.

RESPOND Social Media Statistics M13-M19: Statistics about members, subscribers, visits, open rates, click trough rates have been tracked in Social Media activities (Facebook, Twitter, LinkedIn, Youtube) and in direct marketing (Mailing campaigns).

• Facebook (22 followers, 9 posts) • Twitter (78 followers, 24 publications, 2810 impressions per month, 320 visits) • Youtube (45 followers) • LinkedIn (21 members)





110 | 155

M19-M24: Statistics about members, subscribers, visits, open rates, click trough rates have been tracked in Social Media activities (Facebook, Twitter, LinkedIn, Youtube) and in direct marketing (Mailing campaigns).

• Facebook (30 followers, 41 posts) • Twitter (107 followers, 114 publications, 2810 impressions per month, 320 visits) • Youtube (45 followers) • LinkedIn (30 members)


After, the firsts tasks of T7.2 described in section Description of tasks, which result in a Minimum Valuable Product, the focus have moved on the development of innovative and adequate business models. This task aims at providing the basis for sustainability of the RESPOND results after the end of the project and future exploitation. Besides, it will optimize the impact of the project in the EU and beyond. Discussions of the strategies for further use of the RESPOND results with designated stakeholders will be conducted and particular attention will be paid in the identification of the main procurement channels in order to foster the market uptake.


The main activities from T7.3 have been focus on:

• Description of data types used during the project: sensitive and non-sensitive data. • Pilot countries data protection policies and legislation (Ireland, Denmark and Spain) before

and after the General Data Protection Regulation (GDPR) which entries into force on 25 May 2018.

• Analysis of common EU policies. • Definition of RESPOND GDPR approach. Objectives, pilots and participants. Treatment of

personal data (data life cycle management for each pilot, treatment activities registry, risk analysis, security measures), authorization model of personal data.

• Definition of ICT security measures. Backend infrastructure, desktop front-end, mobile-app.

• Analysis of other entities recommendations (Open Access, Research data).

The work carried out has been reflected in Deliverable 7.4 Data life cycle management policy (Preliminary) that was submitted in M18. It contains both, sensitive personal data protection (GDPR issues) in one hand, and the ITC protection measures in the other. Nevertheless, this second part will be fully addressed in the deliverable D5.5 Data protection and security which task starts according to the Gantt chart in M19 although, the ITC security measures have been already designed and implemented to start protecting the information since the very first day.



111 | 155


The RESPOND project has attended to Sustainable Places, Aix-Le-Bains, France, in May 2018,

upon invitation by our Project Officer, Pierre Antoine, who had contacted us. At first, the project

was intended to participate in the event as a dissemination activity, with the representation of

NUIG partner, anyhow after the invitation by the EASME, FEN partner attended also, as

coordinator of the project.



Deviations from GA:

There have been no deviations from the GA.

Corrective actions:

Any corrective action has been required.


Deviations from GA:


Corrective actions:



Deviations from GA:


Corrective actions:



Deviations from GA:


Corrective actions:



112 | 155






2.5.8 WP8: PROJECT MANAGEMENT

WP8 runs from M1 (October 2017) to M36 (September 2020). The overall objectives of WP8 are to guarantee the coordination and work between interacting partners that integrate the Consortium and also a fluid communication with the European Commission, with efficient administrative, financial and contractual management. Also, it ensures that the decision-making processes and quality assurance procedures specific to the RESPOND project are established and followed.

Tasks T8.1 Project administration & quality assurance and T8.2 Project management and EC

reporting started in M1 and run along the project duration.

D

FIGURE 5 - WP8: PROJECT MANAGEMENT GANTT CHART



113 | 155

During the second year (M13-M24) the main activities within T8.1 and T8.2 have been the

following.

2.5.8.1 DESCRIPTION OF TASK

T8.1 PROJECT ADMINISTRATION & QUALITY ASSURANCE. M1-M36 FEN

This task sets the basis for the project management. The aim is to facilitate and promote the use

of a performance-based management process in the RESPOND project, according to the Grant

Agreement [2] and its Annexes and the Consortium Agreement [3].

FEN, on behalf of Project Coordinator of RESPOND, kept under control all the procedures

stablished in D8.1. FEN worked in close cooperation with the individual WP leaders and rest of

partners. The consortium run regular meetings to monitor progress and coordinate the

development of specific WPs and associate Deliverables, call conferences and/or face-to-face

meetings.

T8.2 PROJECT MANAGEMENT AND EC REPORTING. M1-M36 FEN

This task also sets the basis for the project management. The specific objectives are: • Administrative, risk & financial management • Scientific & technology management


T8.1 PROJECT ADMINISTRATION & QUALITY ASSURANCE. M1-M36

The actions and main results obtained in this task have been:

• Collection of significant information to create internal periodic reports for periods M13-M18 and M19-M24 with the purpose of monitoring and recording the progress in line of the Project with specified project milestones. Every six months, all partners provided contributions to the Project Coordinator, in order to report description of tasks executed, main results, deviations and corrections and fulfillment of efforts and costs Excel.



114 | 155

These documents have been used to create the present deliverable D8.3. Management

report (second year). Also, the information contained in the internal reports are valuable

for the Official Reports that the consortium has to submit to the European Commission.

• Redaction of Official Periodic Report for the first three semesters of the project (M1-M6, M7-M12, M13-M18). The document contains follow up of partners accountability (costs and efforts) and also summaries of tasks carried out during the periods. It couldn’t be submitted to EC because the amendment process that had been opened was not concluded yet at the time of Official Reporting M19-M20 (April 2019-May 2019). The Project Officer informed that once the amendment was concluded the consortium would be able to report.

• Follow up of the tasks that have been carried out during the reporting period, M13-M24:

TABLE 2. TASKS LIST FOR SECOND YEAR (M13-M24 PERIOD)

WP Task Description Lead beneficiary

Status

WP1 T1.4 Demand response platform deployment TEK Finished

WP2 T2.2 Seamless integration of RESPOND technology tiers DEXMA Finished

T2.4 Early deployment at pilot sites ENE Finished

T2.5 Demand Response platform deployment IMP Finished

WP3 T3.1 Criteria and framework for participant recruitmement AAU Finished

T3.3 Detailling the user context and improvements of user interaction

AAU Finished

T3.4 Smart mobile client and personal Energy performance assistant design

TEK Finished

WP4 T4.1 Semantic information model TEK Finished

T4.2 Integration of demand response with supply/demand side management

IMP Finished

T4.3 Optimal Energy dispatching at household and neighbourhood level

IMP Finished

T4.4 Energy production and demand forecasting IMP Open until M30



115 | 155

T4.5 Data analytics and optimized control TEK Open until M30

WP5 T5.1 Home automation interoperability interfaces IMP Finished

T5.2 Smart grid connectivity IMP Finished

T5.3 RESPOND middleware development IMP Finished

T5.4 Integration with desktop dashboard and Smart mobile client

DEXMA Finished

T5.5 Data protection and security measures IMP Finished

WP6 T6.1 Validation methodology and acceptance criteria NUIG Finished

T6.2 Validation analysis and reporting NUIG Open until M34

T6.3 Qualiative evaluation of user experiences and recommendations

AAU Open until M34

T6.4 Replication plan development FEN Open until M34

WP7 T7.1 Dissemination and communication strategy DEXMA Open until M36

T7.2 Products, services and supporting business model definition

FEN Open until M36

T7.3 Data life cycle management FEN Open until M36

T7.6 Contribution to EASME dissemination activities FEN Open until M36

WP8 T8.1 Project administration & qualitity assurance FEN Open until M36

T8.2 Project management and EC reporting FEN Open until M36

• On-time preparation and delivery of the following Deliverables:



116 | 155

TABLE 2. DELIVERABLES LIST FOR SECOND YEAR (M13-M24 PERIOD)

Specific Objectives for reported period M13-M24

WP OBJECTIVES ACHIEVEMENTS

WP1 Pilot site characterization Successful submission of D1.4 in M13

WP2 Use case deployment and follow-up Successful submission of D2.2 and D2.4 in M13 and D2.5 in M24

WP3 User engagement process

Successful submission of D3.1 and D3.4 in M13 and D3.3 in M24

WP4 ICT enabled cooperative demand response model

Successful submission of D4.1 in M18 and D4.2, D4.3 in M24

WP5 System Integration and Interoperability Successful submission of D5.1 in M18 and D5.2, D5.3, D5.4, D5.5 in M24

WP6 Validation and Replication of Project Results D6.1 was delayed and submitted in M26 instead of M24 because additional time for

baseline checking WP7 Dissemination and Exploitation Activities Successful submission of D7.4 in M18

WP8 Project management Successful preparation of Official Periodic Report M1-M18, the submission was delayed

because of amendment process opened

• Guidance to consortium members for defining the initial versions, reviewing or updating

any output in the progress of work, with a common format of project delivery.

• Coordination of external advisory boards approach.

T8.2 PROJECT MANAGEMENT AND EC REPORTING. M1-M36

• Handling of project correspondence and day-to-day requests from partners and external bodies.

• Implementing and maintaining the project management infrastructure. The tools used are

efficient and have facilitated the execution of the project objectives: the internal platforms

for information exchange as Google Drive document sharing infrastructure and Adobe

Connect for remote meetings, distribution mail list, long-term calendar, to do’s list, etc.

• Implementing and maintaining a project-specific database for reporting and controlling, including the adaptation of the structure after changes in the work plan and the Consortium.



117 | 155

• Preparing, executing and post-processing the major project meetings (tasks: agendas, invitations, location of meeting places, organization of rooms and equipment, preparation and distribution of materials, minutes and action lists).

• Designing and maintaining specific templates for collecting input to the required EC

documents.

• Checking the dissemination and exploitation plan versus the EC’s requirements.

• Preparing and post-processing of EC reviews from the consortium-side including support

in the implementation of recommendations from the EC and reviewers.

• Handling of legal issues, Data protection issues, IPR issues and maintenance of the

consortium agreement, if necessary.

• Preparing and executing internal and project level quality assurance measures.


T8.1 PROJECT ADMINISTRATION & QUALITY ASSURANCE AND T8.2 PROJECT MANAGEMENT AND EC

REPORTING. M1-M36 FEN AND T8.2 PROJECT MANAGEMENT AND EC REPORTING. M1-M36 FEN

Deviations from GA:

The deviations are described in section 3.2 Project issues and 3.2.1 Amendments.

Corrective actions:

Submission of amendment.






118 | 155




119 | 155

3. PROJECT MANAGEMENT

3.1 CONSORTIUM MANAGEMENT TASKS

3.1.1 PROJECT MEETINGS

The consortium run regular meetings to monitor progress and coordinate the development of

specific WPs and associate Deliverables. The following meetings have been held during the

second year, M13-M24.

During the reporting period the following face-to-face meetings (3 meetings per year, as

stipulated by Consortium Agreement) have been held:

• Spanish pilot visit, Oct. 24&25, 2018, Madrid

Agenda:

Wednesday 24 Oct

Time What Who Where

7:45-08:30 Bus to FEN Headquarters

8:30-09:00 WP8 - Housekeeping FEN

Feníe Energía headquarters

9:00-09:30 PMT conclusions FEN

9:30-10:30 WP7 FEN, DEXMA

10:30-11:00 Coffee break

11:00-12:30 WP2 DEV, TEK, ENE

12:30-13:30 Bus to city centre

13:30-15:30 Lunch La Esquina

Restaurant

16:00-17:00 Pilot Visit Madrid Pilot

Site

19:30 Dinner Lateral

Castellana 89 Restaurant

Thursday 25 Oct

Time What Who Where

7:45-08:30 Bus to FEN headquarters

8:30-09:00 WP1 TEK

9:00-11:00 WP4 TEK, IMP



120 | 155

11:00-11:30 Coffee Break Feníe Energía headquarters 11:30-13:00 WP5 IMP

13:00-14:00 Lunch

14:00-14:30 WP6 NUIG

14:30-15:30 WP3 AAU, TEK


16:00-16:30 WP3 (Cont.) AAU, TEK

16:30-17:00 Wrap up FEN

17:00-18:00 Bus to hotel

19:30 Dinner Tapas

FIGURE 6. RESPOND CONSORTIUM AT MADRID MEETING

• IK-4Tekniker, Mar. 13&14, 2019, Eibar

Agenda:

Wednesday 13 March

Time What Who Where

8:00-08:30 Transport to TEK Headquarters

8:30-09:30 WP8 - Housekeeping FEN

Tekniker

9:30-10:30 Pilot status FEN, ARAN, AURA


11:00-12:00 WP3 AAU, TEK

12:00-13:00 WP6 NUIG

13:00-14:00 Lunch

14:00-15:00 Tekniker Visit TEK


15:30-16:30 WP7 DEXMA

16:30-17:00 WP4 status TEK

17:00-17:30 WP5 status IMP



121 | 155

17:30-18:00 Wrap up FEN

19:00-20:00 Cider house visit TEK Cider house restaurant 20:00 Dinner

Thursday 14 March

Time What Who Where

8:00-08:30 Transport to TEK Headquarters

8:30-10:30 WP4 workshop TEK, IMP, DEXMA,

NUIG

Tekniker

10:30-11:00 Coffee Break

11:00-13:00 WP4 workshop (Cont.) TEK, IMP, DEXMA,

NUIG

13:00-14:00 Lunch

14:00-16:00 WP5 workshop TEK, IMP, DEXMA


16:00-17:00 WP5 workshop (Cont.) TEK, IMP, DEXMA

17:00-17:30 Wrap up FEN

19:00 Pintxos

FIGURE 7. RESPOND CONSORTIUM AT IK4-TEKNIKER

• Institute Mihajlo Pupin, Oct. 23&24, 2019, Belgrade (It will also be reported in D8.4 in M34 as it was held in M25 and it corresponds to the third year period).

Agenda:

Wednesday 23 October

Time What Who Where

8:30-09:00 WP8 - Housekeeping FEN INSTITUTE MIHAJLO

PUPIN

9:00-10:00 Pilot status FEN, ARAN, AURA

10:00-11:00 Review preparation

▪ WP1 status FEN, IMP, AURA, AAU, NUIG



122 | 155

▪ WP2 status ▪ WP3 status

Volgina 15, Belgrade,

Serbia 11:00-11:30 Coffee break

11:30-12:30 Review preparation (Cont.)

▪ WP4 status ▪ WP5 status

WP leaders

12:30-13:30 External Advisory Board feedback

13:30-14:30 Lunch

14:30-16:00 Review preparation (Cont.) LIVE DEMO

WP leaders


16:30-17:30 Steering Committee ALL

17:30-18:00 Wrap up FEN

20:00 Dinner

Belgrade Kalemegdan

Fortress Restaurant

Thursday 24 October

Time What Who Where

8:30-10:00

Review preparation (Cont.)

▪ WP6 status ▪ WP7 status ▪ WP8 status

TEK, IMP

INSTITUTE MIHAJLO

PUPIN Volgina 15, Belgrade,

Serbia

10:00-10:30 WP4 workshop


11:00-13:00 WP4 workshop (Cont.) TEK, IMP

13:00-13:30 WP5 workshop IMP, DEXMA

13:30-14:30 Lunch

14:30-16:00 WP5 workshop (Cont.) IMP, DEXMA


16:30-17:00 WP5 workshop (Cont.) ALL

17:00-17:30 Wrap up FEN



123 | 155

FIGURE 8. RESPOND CONSORTIUM AT BELGRADE

During the reporting period the following general call conferences meetings have been held

(with a periodicity of fifteen days, as stipulated by the Consortium Agreement):

• Oct. 19, 2018 • Nov. 16, 2018 • Nov. 30, 2018 • Dec. 14, 2018 • Jan. 11, 2019 • Jan. 25, 2019 • Feb. 08, 2019 • Feb. 22, 2019 • Mar. 08, 2019 • Mar. 29, 2019 • Apr. 12, 2019

• Apr. 26, 2019 • May 10, 2019 • May 24, 2019 • Jun. 07, 2019 • Jun. 21, 2019 • Jul. 05, 2019 • Jul. 19, 2019 • Aug. 30, 2019 • Sep. 13, 2019 • Sep. 27, 2019

During the reporting period the Project Management Team have met twice per year (as stipulated by the Consortium Agreement, the Project Management Team, constitutes the supervisory body for the execution of RESPOND Project, is led by the Project Coordinator (FEN) and also composed by the Technical Leaders (IMP & TEK) and the Exploitation Manager (DEXMA)):

• Third PMT meeting, Dec. 13, 2018, Call Conference Agenda:

Time What Who

12:00 – 13:00

1. Approval of the agenda and minutes of 22 Oct 2018 (PMT meeting) ALL

2. Amendments ALL

3. AOB ALL



124 | 155

• Fourth PMT meeting, Sep. 19, 2019, Call Conference (It will be reported in D8.3 in M26 as well as it was celebrated in M13). Agenda:

Time What Who

09:30 – 10:00

1. Approval of the agenda and minutes of 13 Dec. 2018 (PMT meeting) ALL

2. Official Periodic Report ALL

3. AOB ALL

During the reporting period the Steering Committee, with representatives of nine partners from the eleven (ALBOA and ARAN didn’t attended) held the annual SC meeting (as stipulated by the Consortium Agreement: once per year with the participation of all partners).

• Second year Steering Committee during Institute Mihajlo Pupin face-to-face meeting,

Oct. 23, 2019, Belgrade.

Agenda:

1. Consortium pending issues. Amendment.

During the reporting period the following specific technical meetings have been held:

• Calorimeters-Building simulator call conference meeting, Mar. 28, 2019, Call Conference

• Demo plan + deployment status plan call conference meeting, Sept. 12, 2019, Call Conference

• Energy production measurements call conference meeting, Oct. 08, 2019, Call Conference

• DEXCell tutorial call conference meeting, Oct. 16, 2019, Call Conference

• Pilots next steps call conference meeting, Oct. 29, 2019, Call Conference



125 | 155

• Validation scenarios call conference meeting, Nov. 15, 2019, Call Conference

Besides, technical points have been included in the agenda of the general call conferences along

the whole project.

3.1.2 PROJECT MEETINGS ATTENDANCE STATISTIC

FEN, on behalf of Project Coordinator, has done attendance statistics for the different types of meetings that the Consortium holds.

• Face-to-face meetings statistics for the first year M1-M12 (October 2017 - September 2018) and second year M13-M24 (October 2018 - September 2019). Also, aggregated for the period of two years M1-M24.

FIGURE 9. F2F meetings attendance per partner graphic for 1st year

100,00% 100,00%

66,67%

100,00% 100,00% 100,00% 100,00% 100,00% 100,00%

66,67%

100,00%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

FEN TEK ALBOA AURA AAU ARAN NUIG IMP DEV ENE DEXMA

F2F Meetings attendance RESPOND Project 1st year, M1-M12



126 | 155

FIGURE 10. F2F MEETINGS ATTENDANCE PER PARTNER GRAPHIC FOR 2ND YEAR

FIGURE 11. F2F MEETINGS ATTENDANCE PER PARTNER GRAPHIC AGGREGATED FOR M1-M24 PERIOD

All partners, TEK, AURA, AAU, ARAN, NUIG, IMP, DEV, ENE, DEXMA, FEN have actively

attended to the F2F meetings.

ALBOA, has progressively reduced their involvement within the project. This change has been

implemented with the submission of the amendment, in which there is a transference of ALBOA

100,00% 100,00%

0,00%

100,00% 100,00%

66,67%

100,00% 100,00%

66,67%

100,00% 100,00%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%


F2F Meetings attendance RESPOND Project2nd year, M13-M24

100,00% 100,00%

33,33%

100,00% 100,00%

83,33%

100,00% 100,00%

83,33% 83,33%

100,00%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%


F2F Meetings attendance RESPOND Project M1-M24



127 | 155

PMs. However, this partner remains in the Consortium as their association is still represented by

the users (inhabitants of the Danish pilot).

• General call conference meetings (remote via Adobe Connect platform) statistics for

the reporting period: two semesters M13-M18 and M19-M24 of the second year (October 2018 - September 2019). Also, aggregated for the period of two years M1-M24.

FIGURE 12. CALL CONFERENCES MEETINGS ATTENDANCE PER PARTNER GRAPHIC FOR SEMESTER M13-M18

FIGURE 13. CALL CONFERENCES MEETINGS ATTENDANCE PER PARTNER GRAPHIC FOR SEMESTER M19-M24

100,00%

90,00%

0,00%

70,00%

80,00%

90,00%

100,00% 100,00%

10,00%

70,00%

100,00%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%


Meetings attendance RESPOND Project 2nd year, semester M13-M18

100,00% 100,00%

0,00%

72,73%

100,00%

63,64%

72,73%

81,82%

27,27%

9,09%

100,00%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%


Meetings attendance RESPOND Project 2nd year, semester M19-M24



128 | 155

FIGURE 14. CALL CONFERENCES MEETINGS ATTENDANCE PER PARTNER GRAPHIC AGGREGATED FOR M1-M24

PERIOD

All partners, TEK, AURA, AAU, ARAN, NUIG, IMP, DEV, ENE, DEXMA, FEN have actively

attended to the general call conferences meetings (remote via Adobe Connect platform) held

regularly every fifteen days. Although, DEV and ENE have a lower percentage of attendance to

these meetings, there has been a constant communication via email with them and their technical

tasks have been fulfilled.

3.2 PROJECT ISSUES

During the previous reporting period we had identified the following issues. At the moment of this report those issues have been solved:

• AURA Raadgivning termination and addition of AURA A/S.

• ALBOA effort reduction (reallocation to other partners)

• DEVELCO effort reduction (reallocation to other partners)

• Increase of PMs and advance of the task’s beginning for TEK’s mobile App.

• DEXMA PMs internal reallocation within WP4.

• Reduce of PMs in T6.5 IMP’s efforts due to a mistake.

• Correction of typo in the deadline of deliverables D8.2 and D8.3.

• Equipment for pilot sites: Reduction of Develco’s budget for Irish pilot and increase of

Energominor’s to step in that pilot.

SUMMARY: Efforts increased 4.2 PMs; total cost decreased 135,17 €

• ALBOA: Non-profit status validation: Its funding ratio increases from 70% to 100%

100,00% 97,50%

7,50%

72,50%

87,50%

67,50%

92,50% 92,50%

30,00%

60,00%

92,50%

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%


General call conferences meetings attendance RESPOND Project M1-M24



129 | 155

3.2.1 AMENDMENTS

As explained in the previous section 3.2, the Project Coordinator submitted, following the EC

procedures, the Amendment Reference No AMD-768619-14 to the Grant Agreement, to solve

the issues aforementioned.

The amendment encompasses several changes of different nature such us mistakes in deadlines

of some deliverables, advance of the beginning of one task, change of efforts between partners,

change of budget between devices providers and change of organization taking part in the project

between a corporate group.

All these changes have been explained to the consortium and agreed by all and also explained

for feedback and guidance to the Project Officer.

The changes were:

• ALBOA has been validated as Non-profit organization after the kick-off of the project. • AURA Raadgivning termination and addition of new participant AURA A/S (PIC

907660720). There was a mistake within the organization as the employees taking part in the project are part of the new partner although their office is in the previous partner building.

• ALBOA effort reduction: Agreed between ALBOA and AURA to shift some PMs from one company to the other. ALBOA doesn’t have enough human resources for the project since the employees taking part have leave the company. AURA as a local partner with very good relationship will step in for these tasks. Furthermore, the travel budget for ALBOA has been also reduced.

• DEVELCO effort reduction: Agreed with them and the involved partners to shift some PMs to TEK, PUP, AURA, ENE and DEXMA. The necessary effort has been higher than they can afford and they will like to share with another partner with enough resources to not affect the performance of the project.

• DEXMA PMs internal reallocation within WP4 due to errors in the original planning. Mistake in proposal regarding the internal distribution of DEXMA effort along tasks in WP4.

• Increase of PMs for TEK in T5.4 as the mobile App was proposed to be developed only for Android and it was assessed that also iOS version will be necessary to promote engagement which implies more efforts.

• Advance of the beginning of the task T5.4. To allow enough time to develop iOS version and the integration with related tasks.

• Reduction of PMs for IMP in T6.5 as the original number of PMs was to high according to the DoA for that action. During the amendment proposal it raised that to many PMs were allocated to IMP according to the description of the action.

• Changes in equipment devices for pilot sites: Reduction of Develco’s budget for Irish pilot and increase of Energominor’s to step in that pilot. During the early deployment it was realized that the Develco’s equipment wasn’t compatible with the peculiarities of the Irish electrical system. As Energomonitor’s equipment are compatible (after a test) it was agreed to replace one provider for another one.

• Correction of the deadline of deliverables D8.2 and D8.3. A mistake was detected as it is not possible to submit the yearly management report the same date that the period to be reported, it is necessary 2 extra month to collect all the information and prepare the deliverable. In the case of D8.3 it was scheduled by mistake in the medium of the period to be reported.



130 | 155

After the changes, as a summary, the efforts in the project will increase by 4.2 PMs while the total

cost will decrease by 135.17 €.

3.3 RISK ASSESSMENT

In the proposal phase of the project the following main critical risks related to the project were

listed:

• Management risks

• Functional risks

• Technical risks

• Visibility risks

• Business risks

A Risk Register was created with the purpose of monitoring the main potential risks and the

response action performed to avoid it.

The procedure that has been carried out to maintain it updated is the following: after a potential

risk is identified, the Risk Register is updated and finally a response action is implemented with

the consensus of the Consortium members, usually during a meeting. The excel contains fields

for the following concepts:

• Description of the risk

• Potential impact: low, medium or high

• Responsible

• Response action taken to avoid it

• Status

During the first two years of RESPOND project, the following resolutive actions were performed:

• iOS application development to guarantee the compatibility with the users engaged

devices in addition to the initial idea of android development.

• Aran islands pilot particularities: Irish pilot team strengthening to ensure the

engagement process, Develco fabric and shipment delays, Develco devices technical

incompatibilities with Irish electrical domestic system.

• Amendment submission



131 | 155

3.4 MANAGEMENT STRUCTURE

The Management Structure for RESPOND Consortium has remained as it was articulated. There are two organization levels:

• An Operational level:

The operational level of the management is constituted by the Project Management Team (PMT): led by the Project Coordinator (PC) and also composed by the Technical Leaders (TL) and the Exploitation Manager (EM).

• A Strategy level:

The strategy level is represented by the Steering Committee (SC): composed by one

representative per partner and is chaired by the Project Coordinator.

The Project Management is composed by two different bodies that will assure the correct orientation of the project to the expected results and that will be supported by:

• Work Packages Leaders (WPL)

• User Engagement Leader (UEL)

• Pilot Case Coordinator (PCC)

• External Advisory Board (EAB)

3.4.1 EXTERNAL ADVISORY BOARD (EAB)

In this reporting period, the Consortium consulted some External Advisory Board experts and got

feedback from them. The feedback obtained will be presented at the 1st Review (scheduled for 4-

5 Dec. 2019 in Brussels).

The idea is to schedule a meeting with the following EAB members in Brussels in 2020.

• Milos Banjac, National Energy DSO (IMP)

• NorthQ, Smart home provider, and AVA, District Heat provider (AURA)

• Bianca Barth, German Association of Energy Market Innovators BNE (FEN)

3.5 ADMINISTRATIVE MANAGEMENT TOOLS

During this reporting period, the same administrative management tools have been used by the

Consortium:



132 | 155

• Document sharing infrastructure

• To do’s

• Partner Pictures Directory

• Distribution Mail List

• Long-term calendar

3.6 DISSEMINATION ACTIVITIES

3.6.1 WEBSITE AND BLOG POSTS

A website for RESPOND project was developed, to serve as the main platform for dissemination and communication for interested stakeholders ( www.project-respond.eu ). It was set up in M3 and has been maintained actively over the reporting period. The design of RESPOND project website focuses on following objectives:

• To present RESPOND to the world and provide a means of contact for interested stakeholders.

• To share project objectives and describe each of the pilot demonstration sites.

• To provide updates on project progress, events, articles and final results.

We have been publishing information about partners, pilots, publications of deliverables submitted

and news.

The project news page functions as a blog, with a tone adapted for a more general audience,

avoiding institutional or scientific jargon. It also includes news stories that have been produced

during the course of the reported period as well as information about the events where the

RESPOND partners have participated.

http://www.project-respond.eu/



133 | 155

FIGURE 82: SCREEN SHOT OF RESPOND WEBPAGE: BLOG SECTION

3.6.2 PUBLICATIONS

• Our partner from Institute Mihajlo Pupin (IMP: Lazar Berbakov, Nikola Tomašević, Marko

Batić) published the following article:

“Architecture and implementation of IoT system for energy efficient living,” Proceedings

of 26th Telecommunications forum TELFOR 2018, ISBN: 978-1-5386-7171-9, pp. 265-

268, Serbia, Belgrade, November 20-21, 2018. DOI: 10.1109/TELFOR.2018.8611888

• Our Partner from Aalborg University (AAU: Toke H. Christensen, Henrik N. Knudsen) published an article in ECEEE Summer Study 2019. The paper is available at AAU depository on the following page:



134 | 155

https://vbn.aau.dk/da/publications/how-to-engage-households-in-energy-demand-response-solutions

• Our partner from Fundación Tekniker (TEK: Francisco Díez, Iker Esnaola) published an article in the European Energy Innovation Magazine. The paper is available in:

FIGURE 83: MAGAZINE PUBLICATION

• Our partner from National University of Ireland, Galway (NUIG: Federico Seri) wrote two papers, the proceedings/DOI are not available yet, but these are the information:

1) 4th Annual APEEN 2019 - Energy Demand-Side Management and Electricity Markets

University of Beira Interior - Covilhã - Portugal. October 17-18th 2019

Paper: Demand Response for residential buildings: case studies and DR program design

by the RESPOND project.

2) AICS2019 - 27th AIAI Irish Conference on Artificial Intelligence and Cognitive Science

for Sustainability

NUI Galway - Galway - Ireland. December 5-6th 2019

Paper: Machine Learning Methods Applied to Building Energy Production and

Consumption Prediction

3) he 16th IBPSA International Conference and Exhibition, Building Simulation 2019,

Rome, Italy, from September 2 – 4, 2019.

Paper: Development Of A Reduced Order Model For Standard-Based Measurement And

Verification To Support ECM

https://vbn.aau.dk/da/publications/how-to-engage-households-in-energy-demand-response-solutions



135 | 155

• Several Open Access Government publications:

Our partner from Feníe Energía (FEN: Rodrigo López) wrote the article “Demand

Response 101: how to get paid to cut power use for Utilities”.

FIGURE 84: OPEN ACCESS GOVERNMENT PUBLICATION

3.6.3 EVENTS, WORKSHOPS, TELEVISION

For dissemination activities, RESPOND project has participated at the following events during the

reporting period:

• Sustainable places 2019, Cagliari, Italy

https://www.sustainableplaces.eu/

https://www.sustainableplaces.eu/



136 | 155

FIGURE 85: RESPOND PROJECT PARTICIPATION AT SUSTAINABLE PLACES 2019

• LDAC 7th Linked Data in Architecture and Construction Workshop, Lisbon, Portugal

http://linkedbuildingdata.net/ldac2019/?utm_content=92663726&utm_medium=social&utm_source=facebook&hss_channel=fbp-1752724508354974

FIGURE 86: RESPOND PROJECT PARTICIPATION AT LDAC 2019

• EU Sustainable Energy Week 2019, Brussels, Belgium





137 | 155

https://ec.europa.eu/info/events/eu-sustainable-energy-week-2019-jun-18_en

FIGURE 15. RESPOND PROJECT PARTICIPATION AT EU SUSTAINABLE ENERGY WEEK 2019

• ECEEE Summer Study 2019 – Is efficient sufficient? – from the 3rd to 8th of June 2019, in France https://www.eceee.org/summerstudy/

FIGURE 87: EVENTS’ PICTURES: ECEEE SUMMER STUDY 2019, FRANCE

https://ec.europa.eu/info/events/eu-sustainable-energy-week-2019-jun-18_en

https://www.eceee.org/summerstudy/



138 | 155

• ETSI IoT Week 2019, 21-25 October 2019, Sophia Antipolis, France. ( https://www.etsi.org/events/1601-etsi-iot-week-2019 )

FIGURE 88: RESPOND PROJECT PARTICIPATION AT ETSI IOT 2019

• Energy Utility week 2019, 12 November 2019, Paris, France

( https://www.smarten.eu/european-utility-week-2019/ )

FIGURE 89: RESPOND PROJECT PARTICIPATION AT EUROPEAN UTILITY WEEK 2019

https://www.etsi.org/events/1601-etsi-iot-week-2019

https://www.smarten.eu/european-utility-week-2019/



139 | 155

• The RESPOND Project has been featured on a current affairs programme, on a National

Irish Language broadcaster TG4. The broadcast took place in the Aran islands, which is

one of the 3 RESPOND pilot sites.

Link to the video of the TV coverage (from 0:51 to 5:10), and you’ll see some of the

equipment we installed: https://dex.ma/305yCF3

FIGURE 90: RESPOND PROJECT FEATURED IN IRISH TV

https://dex.ma/305yCF3



140 | 155

4. DELIVERABLES AND MILESTONES

4.1 DELIVERABLES

Table below shows the deliverable that have been submitted from the beginning of the project

until the end of this period M1-M24, according to the DoA.

TABLE 10. RESPOND PROJECT LIST OF DELIVERABLES SUBMITTED DURING REPORTED PERIOD M1-M24



141 | 155



142 | 155



143 | 155



144 | 155

4.2 MILESTONES

Table below shows the project Milestones that have been scheduled for completion from the

beginning of the project until the end of this period M1-M12, according to the DoA.

TABLE 11. RESPOND PROJECT MILESTONES



145 | 155

5. USE OF RESOURCES

Within this section a wider vision of the figures related to efforts and costs of the project will be presented, both looking RESPOND as a whole with the aim to check if the project is in track and also a detailed view per partner. Together with the data, an explanation is provider in the situation of big differences between the budget and actual expenses and efforts. The below information regarding real values have been provided by each partner according to their best knowledge without audit from the project coordinator that, in addition to define the guidelines and templates for reporting, provide help or clarifications when demanded and ask for further explanations in the case of sensitive differences according to the expected values, is just a mere aggregator of the information. During the second year of RESPOND project (October-18 to September-19) under review in this deliverable there has not been changes in the initial Grant Agreement subscribed by all partners and the commission and therefore no new budgets have been put in place.

5.1 EFFORTS SUMMARY

The following paragraphs reflects the current situation of the project after their second year of live

focusing on the efforts performed by the consortium as a whole and partner by partner.

TABLE 12: TOTAL EFFORTS (ACTUAL AND BUDGET) BY PARTNER AND WP IN THE 2ND YEAR

TABLE 13: PERCENTAGE OF ACTUAL EFFORTS VS BUDGET BY PARTNER AND WP IN THE 2ND YEAR

[PMs] BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL

01-FEN 18,22 18,30 0,00 0,00 4,00 4,01 0,67 0,67 0,00 0,00 0,00 0,00 4,57 4,60 4,67 4,68 4,32 4,33

02-TEK 37,79 40,59 0,00 0,00 0,00 3,22 0,00 1,38 15,00 13,30 13,50 20,58 6,12 0,25 2,84 1,54 0,33 0,32

03-ALBOA 1,20 0,42 0,00 0,07 0,00 0,06 1,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,15 0,20 0,14

04-AURA 9,75 9,56 0,00 1,04 2,20 1,85 1,00 4,24 0,00 0,00 0,00 0,12 2,00 1,16 4,00 0,49 0,55 0,66

05-AAU 9,60 7,03 0,00 0,00 0,00 0,00 7,00 6,38 0,50 0,00 0,00 0,00 1,00 0,00 0,80 0,63 0,30 0,02

06-ARAN 4,83 3,50 0,00 0,00 1,00 1,50 0,50 0,50 0,00 0,00 0,00 0,00 2,00 0,50 1,00 0,67 0,33 0,34

07-NUIG 11,50 14,75 0,00 0,00 0,00 0,00 0,00 0,00 3,50 6,50 0,00 0,00 8,00 8,25 0,00 0,00 0,00 0,00

08-IMP 44,60 46,27 0,00 0,00 0,00 4,00 0,00 0,00 14,00 9,51 24,00 27,21 5,00 3,79 1,30 1,20 0,30 0,56

09-DEV 18,30 9,92 0,00 0,00 4,00 3,30 0,00 0,00 0,00 0,00 8,00 3,70 2,00 0,74 4,00 1,99 0,30 0,19

10-ENE 10,20 1,10 0,00 0,00 4,00 0,00 0,00 0,00 0,00 0,00 2,00 0,61 1,00 0,00 3,00 0,00 0,20 0,49

11-DEXMA 29,15 30,26 1,70 1,76 6,70 7,20 1,95 2,14 5,00 5,07 7,80 7,67 0,00 0,00 6,00 6,37 0,00 0,03

TOTAL 195,15 181,69 1,70 2,87 21,90 25,15 12,12 15,31 38,00 34,38 55,30 59,89 31,69 19,29 27,60 17,72 6,84 7,08

WP8WP3 WP4 WP5 WP6 WP7TOTAL WP1 WP2

TOTAL WP1 WP2 WP3 WP4 WP5 WP6 WP7 WP8

[%] ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD

01-FEN 100% 100% 100% 100% 100% 100% 101% 100% 100%

02-TEK 107% 100% 100% 100% 89% 152% 4% 54% 96%

03-ALBOA 35% 100% 100% 0% 100% 100% 100% 100% 70%

04-AURA 98% 100% 84% 424% 100% 100% 58% 12% 120%

05-AAU 73% 100% 100% 91% 0% 100% 0% 79% 5%

06-ARAN 72% 100% 150% 100% 100% 100% 25% 67% 101%

07-NUIG 128% 100% 100% 100% 186% 100% 103% 100% 100%

08-IMP 104% 100% 100% 100% 68% 113% 76% 92% 187%

09-DEV 54% 100% 83% 100% 100% 46% 37% 50% 63%

10-ENE 11% 100% 0% 100% 100% 30% 0% 0% 247%

11-DEXMA 104% 103% 108% 110% 101% 98% 100% 106% 100%

TOTAL 93% 169% 115% 126% 90% 108% 61% 64% 104%



146 | 155

FIGURE 91: TOTAL EFFORTS (ACTUAL AND BUDGET) BY PARTNER IN THE 2ND YEAR

As it is shown, in general terms, all partners are aligned with the expected amount of efforts encompassed in the original Grant Agreement description of action. Below it is a compilation of individual graphs per partner.

FEN TEK

ALBOA AURA



147 | 155

FIGURE 92: TOTAL EFFORTS (ACTUAL AND BUDGET) FOR EACH PARTNER IN THE 2ND YEAR

AAU ARAN

NUIG IMP

DEV ENE

DEXMA



148 | 155

5.2 COSTS SUMMARY

The following paragraphs reflects the current situation of the project after their second year of live

focusing on the cost incurred by the consortium as a whole and partner by partner.

TABLE 14: TOTAL COSTS (ACTUAL AND BUDGET) BY PARTNER AND TYPE IN THE 2ND YEAR

TABLE 15: PERCENTAGE OF ACTUAL COSTS VS BUDGET BY PARTNER AND TYPE IN THE 2ND YEAR

[€] BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL BUDGET ACTUAL

01-FEN 240992,58 247053,47 48198,52 49410,69 74333,34 99603,27 118460,72 98039,50 168694,81 172937,43 0,00 0,00

02-TEK 234686,34 231233,14 46937,27 46246,63 6416,67 9150,91 181332,41 175835,60 234686,34 231233,14 0,00 0,00

03-ALBOA 13950,00 3655,83 2190,00 731,17 0,00 0,00 8760,00 2924,66 9765,00 2559,08 3000,00 0,00

04-AURA 110900,31 82112,90 22180,06 16422,58 8000,00 2603,15 80720,25 63087,17 77630,22 57479,03 0,00 0,00

05-AAU 105942,00 57752,13 21188,40 0,00 5400,00 4740,17 79353,60 53011,96 105942,00 57752,13 0,00 0,00

06-ARAN 27493,33 21239,23 5498,67 4247,85 2666,67 2991,38 19328,00 14000,00 27493,33 21239,23 0,00 0,00

07-NUIG 67285,51 75177,80 13457,10 15035,56 3714,28 3360,90 50114,13 56781,34 67285,51 75177,80 0,00 0,00

08-IMP 172686,66 172234,11 34537,33 34446,82 6133,33 5963,42 132016,00 131823,87 172686,66 172234,11 0,00 0,00

09-DEV 232837,50 118578,11 46567,50 23715,62 60000,00 15066,66 126270,00 79795,83 162986,25 83004,68 0,00 0,00

10-ENE 70075,00 11356,72 14015,00 2271,34 2000,00 3262,00 54060,00 5823,38 49052,50 7949,70 0,00 0,00

11-DEXMA 156962,50 170185,65 31392,50 34037,13 14800,00 10625,77 110770,00 125522,75 109873,75 119129,95 0,00 0,00

TOTAL ######### ######### 286162,35 226565,39 183464,28 157367,63 961185,11 806646,05 ######### ######### 3000,00 0,00

TOTAL Indirect Costs Other direct costs Personnel costs Requested EU funding Subcontracting

[%] ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD ACT/BUD

01-FEN 103% 103% 134% 83% 103% 100%

02-TEK 99% 99% 143% 97% 99% 100%

03-ALBOA 26% 33% 100% 33% 26% 0%

04-AURA 74% 74% 33% 78% 74% 100%

05-AAU 55% 0% 88% 67% 55% 100%

06-ARAN 77% 77% 112% 72% 77% 100%

07-NUIG 112% 112% 90% 113% 112% 100%

08-IMP 100% 100% 97% 100% 100% 100%

09-DEV 51% 51% 25% 63% 51% 100%

10-ENE 16% 16% 163% 11% 16% 100%

11-DEXMA 108% 108% 72% 113% 108% 100%

TOTAL 83% 79% 86% 84% 84% 0%

Requested

EU fundingSubcontracting

Indirect

Costs

Other direct

costs

Personnel

costsTOTAL



149 | 155

FIGURE 93: TOTAL COSTS (ACTUAL AND BUDGET) BY PARTNER IN THE 2ND YEAR

As it is shown, in general terms, all partners are aligned with the expected amount of budget encompassed in the original Grant Agreement description of action. Below it is a compilation of individual graphs per partner.

FEN TEK

ALBOA AURA



150 | 155

FIGURE 94: TOTAL COSTS (ACTUAL AND BUDGET) FOR EACH PARTNER IN THE 2ND YEAR

AAU ARAN

NUIG IMP

DEV ENE

DEXMA



151 | 155

FIGURE 95: TOTAL COSTS (ACTUAL AND BUDGET) FOR EACH TYPE IN THE 2ND YEAR

PERSONNEL COSTS REQUESTED EU FUNDING

SUBCONTRACTING TOTAL COSTS

INDIRECT COSTS OTHER DIRECT COSTS



152 | 155

6. CONCLUSIONS

During the present reported period M13-M24 (October 2018 – September 2019) the global picture

regarding the status of RESPOND project is positive.

The Consortium overcame the real-world challenges, which constitute a natural part of working

on field. From the multidisciplinary backgrounds involved in the project (technical, sociological,

aspects), those difficulties have been solved with effective solutions.

In order to achieve RESPOND project objectives, all the available resources have been used, we

have been constantly checking over if the results of the tasks converge towards the same

direction.

The scheduled deliverables have been reported on time focusing on a high-quality level. The

scheduled tasks have been accomplished and milestones achieved.

As in the previous management report (first year), the management structure for RESPOND

governance (Project Coordinator, technical Leaders, Exploitation Manager) with its different

bodies (Work Packages Leaders, User Engagement Leader, Pilot Case Coordinator) still works

effectively at both, operational level and strategy level. The Consortium has been ensuring the

effective execution of the technical work in order to achieve the main goals for the progress of the

project.

The management procedures and administrative tools have been functional and useful.

The same meetings structures performed during the first year of project have been kept.

Overall, the project execution is progressing well. From the three phases scheduled, namely:

1) Phase I: Project set up and early deployment 2) Phase II: RESPOND platform integration and advancement 3) Phase III: Project validation and replication

The third phase, project validation and replication, will be crucial to wrap up the tasks performed

in the period of 24 months, 1st and 2nd years.

The efforts from the third year onwards are in the following work packages:

WP4, ICT enabled cooperative demand response model, in particular for tasks:

• T4.4 Energy production and demand forecasting

• T4.5 data analytics and optimized control

WP6, Validation and replication of project results.

WP7, Dissemination and exploitation activities: the dissemination activities keep promoting the

project in order to build opportunities within the market.

Deliverables D6.5 Best practices and lessons learnt (M36) and D7.2 RESPOND business model

(M36) will be key for the final definition of RESPOND project.



153 | 155

The project keeps adapting to obtain a final result in the real world that accomplish with actual

technology completed and qualified trough test and demonstrations (TRL 8).



154 | 155

REFERENCES

RESPOND DOCUMENTS

Consortium Agreement, version 1.5, 2017-09-22

Grant Agreement number: 768619 – RESPOND integrated demand REsponse Solution towards energy POsitive NeighbourhooDs (RESPOND) – H2020-EE-2016-2017/H2020-EE-2017-PPP Amendment Reference No AMD-768619-14

D1.1 Pilot technical characterization and operation scenarios

D1.2 Demand response programs overview

D1.3 RESPOND strategy to support interoperability

D1.4 Pilot specific demand response strategy

D2.1 RESPOND system reference architecture

D2.2 Integration of key RESPOND technology tiers

D2.3 Initial Deployment Plan

D2.4 Early deployment activities report

D3.1 Criteria and framework for recruiting and engaging

D3.2 RESPOND use engagement strategy

D3.3 Findings and recommendations from focus groups on user context

D3.4 Personal energy performance assistant design

D4.1 Semantic information model

D4.2 Demand response optimization model

D4.3 Optimal energy dispatching at neighborhood level

D5.1 Energy gateway for home automation interoperability

D5.2 RESPOND connectivity to smart grid services

D5.3 RESPOND middleware deployment

D5.4 Desktop dashboard and smart mobile client

D5.5 Data protection security



155 | 155

D6.1 RESPOND Validation methodology

D7.1 Dissemination and communication plan

D7.2 RESPOND dissemination and project website (preliminary)

D7.4 Data life cycle management policy (Preliminary)

D7.8 RESPOND dissemination and project website (final)

D8.1 Quality assurance plan

D8.2 Management report (first year)

get.dexma.com Deliverables/D8_3.pdf · WP8 Project management D.8.3 MANAGEMENT REPORT (SECOND YEAR)...

Documents

Transcript of get.dexma.com Deliverables/D8_3.pdf · WP8 Project management D.8.3 MANAGEMENT REPORT (SECOND YEAR)...