Reference framework : October 2024.
Date: 2024-11-12
Institutions: Directorate-General for Energy, European Climate, Infrastructure and Environment Executive Agency
Subjects: digitisation, energy efficiency, energy grid, energy market, energy storage, energy technology, exchange of information, innovation, project evaluation, report, systems interconnection

bridge 
Reference 
Framework 
Updated report 2024 

Data Management Working Group

October - 2024 

 
 
 
 
REFERENCE FRAMEWORK 

AUTHORS 

Olivier Genest, Trialog 

Isidoros Kokos, Intracom Telecom 

Mário Couto, EPRI 

Ismini Dimitriadou, Hypertech 

Krzysztof Piotrowski, IHP 

Stelios Zikos, CERTH/ITI 

OTHER CONTRIBUTORS 

Ferdinando Bosco, Engineering 

Marjolaine Farre, Trialog 

Dune Sebilleau, Trialog 

Kostas Tsatsakis, Suite5 

Pinelopi Valiouli, isZEB 

Denisa Ziu, Engineering 

Joaquim Meléndez i Frigola, Universitat de Girona 

Elena Boskov Kovacs, Blueprint Energy 

Vincenzo Croce, Engineering 

Jukka Rinta-Luoma, Fingrid 

CONTRIBUTION FROM PROJECTS 

ACCEPT,  BRIGHT,  ebalance-plus,  ECHO,  EDDIE,  ELECTRON,  ENERGICA,  Enershare,  ENFLATE,  EUniversal,  FEVER, 
FlexCHESS, GIFT, IANOS, int:net, InterConnect, MAESHA, NaturSea-PV, OMEGA-X, OneNet, OPENTUNITY, PARITY, 
PARMENIDES,  PlatOne,  Re-Empowered,  REEFLEX,  RESCHOOL,  RESONANCE,  ROBINSON,  SENDER,  SERENE, 
SINNOGENES, Senergy-Nets, TIGON, X-FLEX 

BRIDGE WG/TF CHAIRMANSHIP 

Olivier Genest – Chair 

 bridge 

 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

EUROPEAN COMMISSION  

European Climate, Infrastructure and Environment Executive Agency  
Directorate C - Green research and innovation  
Unit C.C2 “Horizon Europe Energy” 

Directorate General for Energy 
Directorate B – Just Transition, Consumers, Energy Efficiency and Innovation  
Unit B5 – Innovation, Research, Digitalisation, Competitiveness 

Contact: Mugurel-George Păunescu ;  Mariana Stantcheva 
E-mail : mugurel-george.paunescu@ec.europa.eu ; mariana.stantcheva@ec.europa.eu 
European Commission 
B-1049 Brussels 

ACKNOWLEDGEMENTS 

The editors would like to acknowledge the valuable inputs from BRIDGE projects and Data Management WG who 
participated in the meetings and consultation rounds as well as members of the Secretariat team, all contributing 
to this BRIDGE Reference Framework Report. 

 bridge 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Reference Framework 

Data Management Working Group 

October 2024 

 bridge 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

LEGAL NOTICE 

This document has been prepared for the European Commission. However, it reflects the views only of the authors, 
and the European Commission is not liable for any consequence stemming from the reuse of this publication. More 
information on the European Union is available on the Internet (http://www.europa.eu). 

PDF Web 

ISBN 978-92-9405-151-6 

doi: 10.2926/9862411 

HZ-01-24-018-EN-N 

Luxembourg: Publications Office of the European Union, 2024 

Manuscript completed in October 2024 

First edition 

© European Union, 2024 

The reuse policy of European Commission documents is implemented by the Commission Decision 2011/833/EU 
of 12 December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Except otherwise 
noted, the reuse of this document is authorised under a Creative Commons Attribution 4.0 International (CC - BY 
4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided 
appropriate credit is given and any changes are indicated.  

For any use or reproduction of elements that are not owned by the European Union, permission may need to be 
sought directly from the respective right holders.  

 bridge 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

INDEX 

List of Acronyms and Abbreviations ................................................................................................................. 8 
List of references ........................................................................................................................................... 10 
List of Figures ................................................................................................................................................ 12 
List of Tables .................................................................................................................................................. 13 
Executive Summary ....................................................................................................................................... 14 
Introduction .................................................................................................................................................. 16 
1  General approach ..................................................................................................................................... 17 

1.1 

1.2 

Context ....................................................................................................................................................... 17 

Reference Framework components ........................................................................................................... 17 

1.2.1 

1.2.2 

1.2.3 

Generic business process .............................................................................................................. 18 

Functions and Interfaces .............................................................................................................. 19 

Extension of the Reference Framework ....................................................................................... 20 

Settlement implementation ......................................................................................................................... 20 

2 

Increasing the impact of the Reference Framework.................................................................................... 21 

2.1 

Investigation from BRIDGE projects ........................................................................................................... 21 

2.1.1 

2.1.2 

2.1.3 

Reference Framework Usability Survey ........................................................................................ 21 

Usability Survey Results ................................................................................................................ 22 

Usability Survey Conclusions ........................................................................................................ 28 

2.2 

Contribution to the BRIDGE Use Case Repository ...................................................................................... 28 

2.2.1 

2.2.2 

2.2.3 

Opportunity to harmonise use-case descriptions thanks to the Reference Framework ............. 28 

Generic Actor List.......................................................................................................................... 29 

Update of the Generic Actor List .................................................................................................. 30 

Plan for the Generic Actor List Update ......................................................................................................... 31 

3  Guidelines for Settlement Implementation ................................................................................................ 33 

3.1 

3.2 

3.3 

Settlement .................................................................................................................................................. 33 

Lessons Learned from EU-Funded Projects ................................................................................................ 33 

Guidelines for Settlement Implementation................................................................................................ 34 

3.3.1 

3.3.2 

Measurement and Verification ..................................................................................................... 34 

M&V Methods .............................................................................................................................. 35 

3.4 

3.5 

3.6 

Baselining Methodologies .......................................................................................................................... 39 

Data Requirements ..................................................................................................................................... 42 

Settlement subprocess ............................................................................................................................... 44 

4  Conclusion and Perspectives ..................................................................................................................... 45 

4.1  Main Findings and Recommendations ....................................................................................................... 45 

4.2 

Perspective and next steps ......................................................................................................................... 48 

 bridge 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

5  Annex 1: Reference Framework ................................................................................................................. 49 

5.1 

Definition of Terms ..................................................................................................................................... 49 

5.1.1 

5.1.2 

5.1.3 

Flexibility ....................................................................................................................................... 49 

Flexibility Stakeholders ................................................................................................................. 49 

Energy Services Stakeholders ....................................................................................................... 50 

Generic Business Processes .................................................................................................................................... 50 

5.1.4 

5.1.5 

5.1.6 

5.1.7 

5.1.8 

5.1.9 

GBP1 – Flexibility for SOs through Open Market ......................................................................... 50 

GBP2 – Flexibility for SO via Prior Bilateral Agreement ................................................................ 51 

GBP3 – Flexibility for BRP Portfolio Optimisation ........................................................................ 52 

GBP4 – Flexibility for Energy Community Optimisation ............................................................... 53 

GBP5 – Implicit Flexibility Using Dynamic Steering Signals .......................................................... 54 

GBP6 – Energy Monitoring and Energy Management .................................................................. 54 

5.1.10  GBP7 – P2P Trading in Energy Communities ................................................................................ 55 

5.1.11 

Settlement Subprocess ................................................................................................................. 55 

Functions and Interfaces ........................................................................................................................................ 60 

5.1.12 

Functions ...................................................................................................................................... 60 

5.1.13 

Arrows (information flows) .......................................................................................................... 81 

 bridge 

7 

 
 
 
 
 
 
 
 
List of Acronyms and Abbreviations 

REFERENCE FRAMEWORK 

AhG 

Ad-hoc Group 

BPMN 

Business Process Model and Notation 

BRP 

BTM 

Balance Responsible Party 

Behind-the-Meter 

CG-SG 

Coordination Group on Smart Grids 

CEN 

Comité Européen de Normalisation (European Committee for Standardisation) 

CENELEC  Comité Européen de Normalisation en ÉLectronique et en ÉlectroteChnique (European 

DER 

Committee for Electrotechnical Standardisation) 
Distributed Energy Resources 

DMWG 

Data Management Working Group 

DR 

DSO 

EG 

EMS 

ESCo 

ETSI 

EV 

FO 

FSP 

FTM 

GBP 

GUC 

Demand Response 

Distribution System Operator 

Expert Group 

Energy Management System 

Energy Service Company 

European Telecommunications Standards Institute 

Electrical Vehicle 

Flexibility Offer 

Flexibility Service Provider 

Front-of-the-Meter 

Generic Business Process 

Generic Use Case 

HEMRM  Harmonised Electricity Market Role Model  

IEC 

IRM 

LEC 

MO 

International Electrotechnical Commission 

Interface Reference Model 

Local Energy Community 

Market Operator 

M&V 

Measurement & Verification 

P2P 

Peer-to-peer 

SG-CG 

Smart Grid Coordination Group 

SGAM 

Smart Grid Architecture Model 

SGTF 

Smart Grid Task Force 

SLA 

SO 

Service Level Agreement 

System Operator (i.e. TSO or DSO) 

 bridge 

8 

 
 
 
 
TSO 

UC 

UML 

WG 

Transmission System Operator 

Use-Case 

Unified Modelling Language 

Working Group 

REFERENCE FRAMEWORK 

 bridge 

9 

 
 
 
 
 
 
List of references 
BRIDGE,  «BRIDGE  General  Assembly  February  2020  –  Conclusions  &  Next  Steps,»  [En  ligne].  Available: 
https://www.h2020-bridge.eu/wp-content/uploads/2020/03/BRIDGE-GA2020_Conclusions-and-next-steps.pdf. 

REFERENCE FRAMEWORK 

BRIDGE,  «BRIDGE  – 
ligne].  Available: 
https://ec.europa.eu/energy/sites/default/files/documents/bridge_wg_data_management_interoperability_of_
flexibility_assets_report_2020-2021.pdf. 

flexibility  assets  –  April  2021,» 

Interoperability  of 

[En 

BRIDGE,  «Interoperability  of 
https://op.europa.eu/en/publication-detail/-/publication/a00be176-ac1f-11ed-b508-01aa75ed71a1/language-
en. 

-  Version  2.0,»  2022. 

ligne].  Available: 

flexibility 

assets 

[En 

BRIDGE, «BRIDGE General Assembly March 2022 – Conclusions & Next Steps,» [En ligne]. Available: https://bridge-
smart-grid-storage-systems-digital-
projects.ec.europa.eu/sites/default/files/download/BRIDGE%202022%20GA%20-%20Conclusions.pdf. 

BRIDGE,  «Reference  framework  v1.0,»  [En 
/publication/13183bbf-4d33-11ee-9220-01aa75ed71a1/language-en/format-PDF/source-294051135. 

ligne].  Available:  https://op.europa.eu/en/publication-detail/-

BRIDGE, «BRIDGE Use Cases Repository,» [En ligne]. Available: https://bridge-smart-grid-storage-systems-digital-
projects.ec.europa.eu/use-cases-repository. 

BRIDGE,  «Set  up  a  use  case  repository  2.0,»  2022.  [En  ligne].  Available:  https://op.europa.eu/en/publication-
detail/-/publication/30ac0765-ac1e-11ed-b508-01aa75ed71a1/language-en. 

IEC, «Use case methodology – Part 2: Definition of the templates for use cases, actor list and requirements list,» 
2015. 

EFET, 

ebIX, 
ENTSO-E,  «Harmonised 
https://www.ebix.org/artikel/role_model. 

Electricity  Market  Role  Model,» 

[En 

ligne].  Available: 

SGTF EG1, «Towards Interoperability within the EU for Electricity and Gas Data Access & Exchange,» March 2019. 
[En 
https://energy.ec.europa.eu/system/files/2019-
Available: 
05/eg1_main_report_interop_data_access_0.pdf. 

ligne]. 

CEN-CENELEC-ETSI  Smart  Grid  Coordination  Group,  «Sustainable  Processes,»  November  2012.  [En  ligne]. 
Available: 
https://www.cencenelec.eu/media/CEN-CENELEC/AreasOfWork/CEN-
CENELEC_Topics/Smart%20Grids%20and%20Meters/Smart%20Grids/smartgrids_sustainableprocesses.pdf. 

IEC, «Application integration at electric utilities - System interfaces for distribution management - Part 1: Interface 
architecture and general recommendations». 

EPRI,  «Measurment  and  Verification  (M&V)  for  Distributed  Energy  Resources  Providing  Grid  Services  -  New 
Complexities, Common Approaches, and Research Needs,» 2021. 

OneNet,  «D3.4  Regulatory  and  demo  assessment  of  proposed  integrated  markets,»  [En  ligne].  Available: 
https://www.onenet-project.eu//wp-content/uploads/2023/09/OneNet_D3.4_V1.0.pdf. 

OneNet Project, «D3.4 Regulatory and demo assessment of proposed integrated markets,» 2023. 

CoordiNet,  «D2.1  Markets  for  DSO  and  TSO  procurement  of  innovative  grid  services:  Specifications  of  the 
architecture, operation and clearing algorithms,» 2021. 

Smart Grid Task Force, «Regulatory Recommendations for the Deployment of Flexibility: EU SGTF-EG3 Report,» 
2015. 

 bridge 

10 

 
 
 
«IEC 

IEC, 
webstore.iec.ch/publication/27785. 

63097:2017 

TR 

Smart 

grid 

standardisation 

roadmap,» 

[En 

ligne]. 

Available: 

REFERENCE FRAMEWORK 

 bridge 

11 

 
 
 
 
 
REFERENCE FRAMEWORK 

List of Figures 
Figure  1.  Description  of  the  Reference  Framework  as  part  of  the  methodology  set  in  2020  to  study  the 
interoperability of flexibility assets ............................................................................................................................ 17 
Figure 2: Example mapping between the SGAM layers of a specific solution/use case and a Generic Business Process 
used as a reference ..................................................................................................................................................... 18 
Figure 3. Example of business process diagram ......................................................................................................... 19 
Figure 4 Q1. Please rate the usefulness of the Reference Framework for your project ............................................ 22 
Figure 5 Q2. How did you use the framework? .......................................................................................................... 23 
Figure 6 Q3. Did you face any difficulties in using/understanding the framework?   (e.g. from regulation, standards 
or other expert) – pink = yes ; blue = no .................................................................................................................... 23 
Figure 7 Q5. Do you see inconsistencies between BRIDGE Reference Framework and other frameworks? orange = 
yes, red = no ............................................................................................................................................................... 24 
Figure 8 Q7. Please indicate which GBPs are relevant for your project(s) ................................................................. 24 
Figure 9 Q8. Please rate the level of alignment of your UC with GBPx from “0 – No alignment” (blue) to “4 – Full 
alignment” (yellow) .................................................................................................................................................... 25 
Figure 10  Q10. Please  indicate  how  satisfied you are  with the level of detail of the GBP analysis from “0  –  Not 
satisfied” to “4 – Very satisfied” (red) ........................................................................................................................ 26 
Figure 11 Q13. In 2020 and 2021, surveys were conducted to identify relevant standards  for each interface of the 
GBPs. Please rate the usefulness of this work from “0 – Not useful” to “4 – Very satisfied” (blue) ......................... 27 
Figure 12 Q14.Would you consider an updated analysis of standards useful?  from “0 – Not useful” to “4 – Very 
satisfied” (blue)........................................................................................................................................................... 27 
Figure 13: Overall schedule for the Generic Actor List update .................................................................................. 32 
Figure  14  System  of  Notifications  (based  on  EPRI,  «Measurment  and  Verification  (M&V)  for  Distributed  Energy 
Resources Providing Grid Services - New Complexities, Common Approaches, and Research Needs,» 2021.) ........ 36 
Figure 15 Measurements before/after  service activation request (based on EPRI, «Measurment and Verification 
(M&V) for Distributed Energy Resources Providing Grid Services  -  New Complexities, Common Approaches, and 
Research Needs,» 2021) ............................................................................................................................................. 37 
Figure  16  Performance  evaluation  against  a  group  of  similar  providers  (based  on  EPRI,  «Measurment  and 
Verification  (M&V)  for  Distributed  Energy  Resources  Providing  Grid  Services  -  New  Complexities,  Common 
Approaches, and Research Needs,» 2021) ................................................................................................................. 38 
Figure  17  Performance  assessment  against  baseline  (based  on  EPRI,  «Measurment  and  Verification  (M&V)  for 
Distributed  Energy  Resources  Providing  Grid  Services  -  New  Complexities,  Common  Approaches,  and  Research 
Needs,» 2021.) ............................................................................................................................................................ 38 
Figure 18 Baseline decision framework adopted in the CoordiNet project ............................................................... 42 
Figure 19 Metering configurations: dedicated meter (1-a) or sub-meter (1-b), vs. meter shared between participating 
and non-participating resources (2) ........................................................................................................................... 43 
Figure 20 Business process diagram – GBP1 “SO flexibility through open market” .................................................. 51 
Figure 21. Business process diagram for GBP2 “SO flexibility via prior bilateral agreement” ................................... 52 
Figure 22: Business process diagram for GBP3 “BRP portfolio optimisation” ........................................................... 53 
Figure 23. Business process diagram for GBP4 "Energy community optimisation" ................................................... 53 
Figure 24. Tentative business process diagram for GBP5 "Implicit flexibility using dynamic steering signals" (“price 
signal” scenario) ......................................................................................................................................................... 54 
Figure 25. Energy Monitoring and Management GBP ................................................................................................ 55 
Figure 26. P2P Trading in energy community GBP ..................................................................................................... 55 
Figure 27. Business process diagram for the settlement subprocess ........................................................................ 56 
Figure 28 Business process diagram for the Settlement subprocess in the PARITY project ...................................... 56 
Figure 29 Business process diagram for the Settlement subprocess in the ACCEPT project ..................................... 58 
Figure 30 Business process diagram for the Settlement subprocess in the X-Flex project ........................................ 58 

 bridge 

12 

 
 
 
 
REFERENCE FRAMEWORK 

List of Tables 
Table 1. Template for function description ................................................................................................................ 19 
Table 2. Template for interface description ............................................................................................................... 20 
Table 3 Reference Framework Usability Survey ......................................................................................................... 21 
Table 4: List of relevant fields for each of the actors in a Generic Actor List ............................................................. 30 
Table 5: List of areas for the update of the Generic Actor List................................................................................... 32 
Table  6  Comparison  of  common  M&V  approaches  (based  on  EPRI,  «Measurment  and  Verification  (M&V)  for 
Distributed  Energy  Resources  Providing  Grid  Services  -  New  Complexities,  Common  Approaches,  and  Research 
Needs,» 2021) ............................................................................................................................................................. 35 
Table 7 Overview of baseline methodology per product used in the OneNet demonstrators .................................. 40 

 bridge 

13 

 
 
 
 
REFERENCE FRAMEWORK 

Executive Summary 
Initially, the topic of “Interoperability of flexibility assets” was discussed and its scope defined during the BRIDGE 
General Assembly held on 11-12 March 2020 in Brussels1. A first report2 on this topic was published in April 2021. 
It included a Reference Framework made of 3 Generic Business Processes (GBPs) and performed an interoperability 
analysis over 10 use cases from 4 projects. Since then, the Reference Framework has been extended to add 2 new 
GBPs and proposes a first version of the settlement subprocess. This second version of the Reference Framework 
was detailed in the “Interoperability of flexibility assets” report version 2.03 completed in June 2022, together with 
an interoperability analysis based on 36 use cases from 14 projects.   

Following  the  BRIDGE  General  Assembly  of  March  20224,  it  was  decided  to  focus  the  activities  on  the  further 
development of the Reference Framework, in particular: 

●  Refine the existing GBPs based on the feedback from new projects; 
●  Extend the Reference Framework to include new GBPs beyond flexibility;  
● 

Improve  the  Settlement  subprocess  based  on  the  BRIDGE  projects  that  are  effectively  implementing 
settlement. 

A report5 was published in June 2023 to present an update of the Reference Framework, now describing 7 GBPs 
and also detailing the Settlement subprocess. It also identified 3 main recommendations: 

●  Ensure consistency with existing standards and ongoing initiatives (e.g. IEC 62913, SGTF EG1). 
● 
●  Further understand the implementation of the Settlement sub-process. 

Identify expectations and related benefits from the Generic Business Processes. 

This report presents the activities performed in 2023-2024 on these three priority areas, in particular: 

1.  A survey has been conducted to identify the expectations from the BRIDGE projects and how the Reference 

Framework could be practically improved.  

●  There  is  a  strong  interest  to  conduct  a  survey  on  the  standards  used  in  the  projects  and  their 

mapping to the GBPs, as done in 2020 and 2021. 

●  The Reference Framework should be extended to support more use cases and the existing GBPs 

could be further investigated to increase the generalisation of the framework. 

2.  A workstream has been launched to establish an updated Generic Actor List to enable the definition of use 

case to be harmonised, in particular within the BRIDGE Use-Case Repository. 

●  Experts from the projects and CEN/CLC/ESTI CG-SG will be involved and a first revision is planned 

at the end of 2024. 

3.  A guideline for settlement implementation has been developed. 

●  Adaptable baseline methodologies should be standardised to support various flexibility products 

and grid conditions. 

●  Standardised  protocols  and  granularity  requirements  should  be  established  for  real-time  data 

exchange. 

●  Data collection, validation and exchange should be standardised, including accuracy and frequency 

requirements, to ensure reliable settlement calculations. 

1  BRIDGE,  «BRIDGE  General  Assembly  February  2020  –  Conclusions  &  Next  Steps,»  [En 
content/uploads/2020/03/BRIDGE-GA2020_Conclusions-and-next-steps.pdf. 
2

Interoperability 

of 

flexibility 

assets 

 BRIDGE, 

«BRIDGE 

– 

– 

ligne].  Available:  https://www.h2020-bridge.eu/wp-

April 

2021,» 

[En 

ligne]. 

Available: 

https://ec.europa.eu/energy/sites/default/files/documents/bridge_wg_data_management_interoperability_of_flexibility_assets_report_2020-2021.pdf. 
3 BRIDGE, «Interoperability of flexibility assets - Version 2.0,» 2022. [En ligne]. Available: https://op.europa.eu/en/publication-detail/-/publication/a00be176-
ac1f-11ed-b508-01aa75ed71a1/language-en. 
4 BRIDGE,  «BRIDGE  General  Assembly  March  2022  –  Conclusions  &  Next  Steps,»  [En  ligne].  Available:  https://bridge-smart-grid-storage-systems-digital-
projects.ec.europa.eu/sites/default/files/download/BRIDGE%202022%20GA%20-%20Conclusions.pdf. 
5  BRIDGE,  «Reference  framework  v1.0,»  [En 
01aa75ed71a1/language-en/format-PDF/source-294051135. 

ligne].  Available:  https://op.europa.eu/en/publication-detail/-/publication/13183bbf-4d33-11ee-9220-

 bridge 

14 

 
 
 
 
●  Robust notification mechanisms should be implemented to alert stakeholders about discrepancies 

between ordered and delivered flexibility volumes. 

REFERENCE FRAMEWORK 

 bridge 

15 

 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Introduction 
The  Data  Management  Working  Group  aims  to  cover  a  wide  range  of  aspects,  from  the  technical  means  for 
exchanging and processing data between stakeholders to the definition of rules for exchanging, including security 
issues  and responsibility distribution. Accordingly,  the  WG has identified 3 areas of collaboration around which 
mutual exchange of views and discussions have been set: 

1.  Communication Infrastructure, embracing the technical and non-technical aspects of the communication 

infrastructure needed to exchange data and the related requirements 

2.  Cybersecurity  and  Data  Privacy,  entailing  data  integrity,  customer  privacy  and  protection  and  general 

security of energy systems 

3.  Data Handling, including the framework for data exchange and related roles / responsibilities, together 
with the technical issues supporting the exchange of data in a secure and interoperable manner, and the 
data analytics techniques for data processing 

This  report  is  part  of  the  3rd  area,  “Data  Handling”,  and  covers  the  topic  of  a  “Reference  Framework”  for 
interoperability. 

Initially, the topic of “Interoperability of flexibility assets” was discussed and its scope defined during the BRIDGE 
General Assembly held on 11-12 March 2020 in Brussels6. A first report7 on this topic was published in April 2021. 
It included a Reference Framework made of 3 Generic Business Processes (GBPs) and performed an interoperability 
analysis over 10 use cases from 4 projects. Since then, the Reference Framework has been extended to add 2 new 
GBPs and proposes a first version of the Settlement subprocess. This second version of the Reference Framework 
was detailed in the “Interoperability of flexibility assets” report version 2.08 completed in June 2022, together with 
an interoperability analysis based on 36 use cases from 14 projects.   

Following  the  BRIDGE  General  Assembly  of  March  20229,  it  was  decided  to  focus  the  activities  on  the  further 
development  of  the  Reference  Framework.  The  report 10 published  in  June  2023  presented  an  update  of  the 
Reference Framework, now including 7 Generic Business Processes and also detailing the Settlement subprocess.  

In 2023-2024, the work around the Reference Framework focuses on three topics: 

● 

Identify the expectations from the BRIDGE projects and how the Reference Framework could be practically 
improved. 

●  Launch  the  definition  of  an  updated  Generic  Actor  List,  to enable  the  definition  of  the  use  cases  to  be 

defined, in particular within the BRIDGE Use-Case Repository. 

●  Develop a guideline for settlement implementation. 

This report presents the results of these three activities. The Reference Framework is attached in Annexe 1. 

6  BRIDGE,  «BRIDGE  General  Assembly  February  2020  –  Conclusions  &  Next  Steps,»  [En 
content/uploads/2020/03/BRIDGE-GA2020_Conclusions-and-next-steps.pdf. 
7

Interoperability 

of 

flexibility 

assets 

 BRIDGE, 

«BRIDGE 

– 

– 

ligne].  Available:  https://www.h2020-bridge.eu/wp-

April 

2021,» 

[En 

ligne]. 

Available: 

https://ec.europa.eu/energy/sites/default/files/documents/bridge_wg_data_management_interoperability_of_flexibility_assets_report_2020-2021.pdf. 
8 BRIDGE, «Interoperability of flexibility assets - Version 2.0,» 2022. [En ligne]. Available: https://op.europa.eu/en/publication-detail/-/publication/a00be176-
ac1f-11ed-b508-01aa75ed71a1/language-en. 
9 BRIDGE,  «BRIDGE  General  Assembly  March  2022  –  Conclusions  &  Next  Steps,»  [En  ligne].  Available:  https://bridge-smart-grid-storage-systems-digital-
projects.ec.europa.eu/sites/default/files/download/BRIDGE%202022%20GA%20-%20Conclusions.pdf. 
10  BRIDGE,  «Reference  framework  v1.0,»  [En 
01aa75ed71a1/language-en/format-PDF/source-294051135. 

ligne].  Available:  https://op.europa.eu/en/publication-detail/-/publication/13183bbf-4d33-11ee-9220-

 bridge 

16 

 
 
 
 
 
REFERENCE FRAMEWORK 

1  General approach 

1.1 Context 

The  Reference  Framework  was  initially  developed  to  support  a  methodology  to  analyse  how  projects  achieve 
interoperability of flexibility assets, including standards assessment (adequacy, maturity …) and gaps identification.  

Used as a common denominator between all the projects, the Reference Framework’s objective was to define some 
generic business processes (GBPs), which are agnostic to any specific technical solution, enabling the mapping of 
each of the projects’ specific solutions to these GBPs to enable cross-projects comparison and analysis. 

This diagram below depicts how the methodology relied on the Reference Framework to compare and harmonise 
the contributions from different projects with different technical solutions, and how it was used to analyse these 
contributions to establish outcomes such as a map of standards, standards assessment and gaps identification. 

Reference framework 

Generic business processes 
Functions and interfaces 

architecture 

solutions 

feedback 

Analysis 
methodology 

Map of standards  
(and standards assessment) 

Gaps 

Contribution from projects 

Outcomes of the methodology 

Color legend: stable – update in case of novel use-cases – regular update to include inputs from new projects  

Figure 1. Description of the Reference Framework as part of the methodology set in 2020 to study the 
interoperability of flexibility assets 

Following  the  BRIDGE  General  Assembly  of  March  2022,  it  was  decided  to  focus  on  the  development  and 
enhancement  of  the  Reference  Framework,  beyond  flexibility,  as  a  tool  to  support  interoperability  and  to 
harmonise use cases descriptions between projects (e.g. via the BRIDGE use-case repository). 

1.2 Reference Framework components 

The Reference Framework is a common base to compare and harmonise the use cases from different projects with 
different technical solutions. 

It relies on GBPs, made of functions and interfaces, with which each project’s use cases and architecture can be 
mapped. 

 bridge 

17 

 
 
 
 
REFERENCE FRAMEWORK 

Figure 2: Example mapping between the SGAM layers of a specific solution/use case and a Generic Business 
Process used as a reference 

1.2.1 Generic business process 

Each GBP is a description of a process between business roles such as DSO and aggregator. It is broken down into 
subprocesses which are called “functions” (see below). These functions may require information exchange between 
roles, through interfaces. They may also require external data (e.g. metering data) or external command capabilities 
(e.g. load control). 

Such a business process description allows users to cover both the function layer and the information layer of the 
SGAM, which are the focus for the interoperability of flexibility assets. They are called “generic” because they are 
independent to any technical solution and several use cases could be mapped to them. 

These  GBPs  are  described with  a  simple  diagram  derived  from  BPMN.  Each  row  refers to  a  role.  Functions  are 
represented  as  rectangles  and  interfaces  are  represented  as  arrows.  Where  several  paths  are  possible,  the 
alternative path is drawn with dotted lines. 

 bridge 

18 

 
 
 
 
REFERENCE FRAMEWORK 

Figure 3. Example of business process diagram 

1.2.2 Functions and Interfaces 

The “functions” represent each of the steps of the business process. They receive inputs from the previous function, 
use external data or commands, and finally provide outputs to the following function. They can be broken down 
into “subfunctions”, which might be useful for more detailed mapping with some specific architecture. 

They are defined in the following table: 

Description 

Inputs 

Outputs 

X1 / Function name 

This  cell  describes  the  purpose  of  the  function,  e.g.  “the  aggregator 
collects  flexibility  offers  of  all  prosumers  and  calculates  the  available 
flexibility for its portfolio” 

This  cell  lists  the  inputs  received  from  the  previous  function,  e.g. 
“flexibility offer of prosumer(s)” 

This  cell  lists  the  outputs  provided  to  the  following  function,  e.g. 
“aggregated flexibility” 

External required data or 
command 

This cell lists the data or commands that are not linked to the previous 
or  following  functions  but  are  required  to  perform  the  function.  An 
example of external data could be “weather data”, “metering data”, … 
An example of command could be “control of flexible loads”. 

Decomposition into 
functions/subfunctions 

This cell describes the decomposition of the function into subfunctions. 

Table 1. Template for function description 

The “interfaces” represent the information exchanges between the functions. They are defined  in the following 
table: 

 bridge 

19 

 
 
 
 
REFERENCE FRAMEWORK 

X1 → Y1 

Purpose 

This cell describes the purpose of the information exchange, e.g. “inform 
aggregator about possible flexibility on Prosumer side” 

Involved roles 

This cell lists the involved roles 

List of exchanged data 

This cell lists the exchanged data, e.g. “flexibility offer” 

Table 2. Template for interface description 

The  analysis of  the  functions  allows  function  layer  interoperability  to  be  studied.  The  analysis of  the  interfaces 
allows information layer interoperability to be studied. 

1.2.3 Extension of the Reference Framework 

A  survey  was  performed  in  January  2023 11 to  identify  relevant  GBPs  to  be  added,  based  on  use  cases  from 
contributing projects. As a result, three new GBPs have been added: E-mobility based flexibility; P2P energy trading; 
Energy monitoring and energy management of households.  

Following this update, it was acknowledged that the Reference Framework is now mature and therefore further 
benefits should be  explored to help ongoing and future  projects, including  the framework's    practical use.  Two 
complementary approaches have been implemented:  

●  A survey was distributed to all BRIDGE projects to identify their needs and expectations, as well as their 

current barriers to the use of the Reference Framework (see §2.1). 

●  The establishment of an updated Generic Actor List has been initiated to enable use-case harmonisation, 

in particular via the BRIDGE Use-Case Repository (see §2.2). 

Settlement implementation 

A workstream on settlement was initiated in 2020, in particular by identifying and cooperating with the BRIDGE 
projects implementing settlement. The focus was to understand how settlement is handled within each project and 
if their implementation can be mapped to the Settlement subprocess currently set out in the Reference Framework. 
Five projects were analysed in 2023 report12. 

The next approach was then to extract the main approaches and recommendations from these projects to support 
other ongoing or future projects. The result is a guideline on settlement implementation (see §3). 

11  BRIDGE,  «Reference  framework  v1.0,»  [En 
01aa75ed71a1/language-en/format-PDF/source-294051135. 
12  BRIDGE,  «Reference  framework  v1.0,»  [En 
01aa75ed71a1/language-en/format-PDF/source-294051135. 

ligne].  Available:  https://op.europa.eu/en/publication-detail/-/publication/13183bbf-4d33-11ee-9220-

ligne].  Available:  https://op.europa.eu/en/publication-detail/-/publication/13183bbf-4d33-11ee-9220-

 bridge 

20 

 
 
 
 
 
2  Increasing the impact of the Reference Framework 

REFERENCE FRAMEWORK 

2.1 Investigation from BRIDGE projects 

2.1.1 Reference Framework Usability Survey 

A survey was launched in January 2024 to analyse how the Reference Framework is already supporting BRIDGE 
projects for use-case development and to identify ways to increase its impact and associated benefits. To this end, 
a survey was shared with projects, investigating their expectations and benefits regarding BRIDGE GBPs. 

The questionnaire is analysed in the following table. 

Table 3 Reference Framework Usability Survey 

BRIDGE Reference Framework Section 

Q1. Please rate the usefulness of the Reference Framework for your project. 

Q2. How did you use the framework? 

Q3. Did you face any difficulties in using/understanding the framework?  (e.g. from  regulation, standards or 
other expert groups)? 

Q4. If yes, please explain 

Q5. Do you see inconsistencies between BRIDGE Reference Framework and other frameworks? 

Q6. If yes, please explain 

Generic Business Process (GBP) Section 

Q7. Please indicate which GBPs are relevant for your project(s) 

Q8. Please rate the level of alignment of your UC with GBPx 

Q9. Please describe main misalignment points (if any) 

Q10. Please indicate how satisfied you are with the level of detail of the GBP analysis 

Q11. Please indicate any suggestions for improvement of the GBP analysis 

Q12. Are there any GBPs that you would like to see added in the Framework? Please, briefly describe them 

Standards Mapping Section 

Q13. In 2020 and 2021, surveys were conducted to identify relevant standards for each interface of the GBPs. 
Please rate the usefulness of this work 

Q14. Would you consider an updated analysis of standards useful? 

Concluding Section 

Q15. Do you have suggestions on how to make the Reference Framework more practical?  
(e.g. formal UML/BPMN modelling of the GBPs, online browsing tools to see relevant standards/references for 
each interface) 

 bridge 

21 

 
 
 
REFERENCE FRAMEWORK 

2.1.2 Usability Survey Results 

The survey was answered by 27  projects (ROBINSON, EUniversal, ACCEPT, InterConnect, MAESHA, RESONANCE, 
NaturSea-PV,  PARMENIDES,  SERENE,  ENFLATE,  IANOS,  Energica,  ECHO,  ELECTRON,  RESCHOOL,  OPENTUNITY, 
int:net,  Enershare,  SENDER,  ELECTRON,  TIGON,  SINNOGENES,  REEFLEX,  EDDIE,  FlexCHESS,  ebalance-plus,  Re-
empowered) represented by 19 different organisations. 

In regards to the usefulness of the framework, as presented in the following figure, most projects have a positive 
experience from using it. 

Figure 4 Q1. Please rate the usefulness of the Reference Framework for your project 

As presented in Figure 4, most of the projects have found the work useful for guiding the UC design, for validation 
of UC design and source of standards or for other uses. Figure 5 below details how it has been used, mostly to 
support UC design and identify relevant standards. 

 bridge 

22 

 
 
 
 
REFERENCE FRAMEWORK 

Figure 5 Q2. How did you use the framework? 

Most of the projects didn’t face challenges in using the framework (Figure 6) with some reported difficulties (Q4) 
in understanding regulation aspects related to the effort of modelling the respective flow or design constraints of 
the projects. 

Figure 6 Q3. Did you face any difficulties in using/understanding the framework?  
 (e.g. from regulation, standards or other expert) – pink = yes ; blue = no 

 bridge 

23 

 
 
 
 
 
REFERENCE FRAMEWORK 

Figure 7 Q5. Do you see inconsistencies between BRIDGE Reference Framework and other frameworks? 
orange = yes, red = no 

No  major  inconsistencies  were  indicated  with  other  references/frameworks  (Figure  7),  but  projects  have 
complementarily reported (Q6) the use of additional frameworks (e.g. IEC 62746-2; EN 50491-12; IEC 62913-2), in 
particular for flexibility activation/provision as well as regulatory and legal / certification frameworks. 

Figure 8 Q7. Please indicate which GBPs are relevant for your project(s) 

 bridge 

24 

 
 
 
 
 
 
As presented in Figure 8, all of the GBPs were found relevant from the projects that participated in the survey, with 
GBP6: Energy monitoring and energy management and GBP4: Flexibility for energy community optimisation, having 
the most widespread use. Also, GBP3 (Flexibility for BRP portfolio optimisation) appears to be the less relevant.  

REFERENCE FRAMEWORK 

Figure 9 Q8. Please rate the level of alignment of your UC with GBPx 
from “0 – No alignment” (blue) to “4 – Full alignment” (yellow) 

In terms of alignment per GBP3: Flexibility for BRP portfolio optimisation seems the least aligned whereas GBP6: 
Energy monitoring and energy management seems to have a high level of alignment. The main misalignment points 
(Q9) concern: 

• 

• 

• 

• 

The  main  misalignment  is  around  the  fact  that  there  is  no  intermediary  party  between  the  flexibility 
provider and the flexibility consumer (i.e., the flexibility service provider).  

“We see some specificities of LEC, P2P and energy monitoring use cases in some pilots (typically due to 
market structure or specific business models)” 

“Use cases have been established in 2020 / 2021 before the set out of the current version of the Reference 
Framework.” 

“BRIDGE GBP focus on flexibility trading/procurement but not so much on flexibility provision/activation”   

•  GBPs not relevant/considered for/in the project scope (e.g. Settlement, P2P) 

 bridge 

25 

 
 
 
 
 
 
REFERENCE FRAMEWORK 

Figure 10 Q10. Please indicate how satisfied you are with the level of detail of the GBP analysis 
from “0 – Not satisfied” to “4 – Very satisfied” (red) 

The overall rating of the granularity of detail of GBPs is satisfactory for the projects (see Figure 10).  

Some suggestions on improvement (Q11. Please indicate any suggestions for improvement of the GBP analysis), 
concern: 

• 

“Align with work in other DMWG Actions, with work of the Smart Grid Task Force, refine the sub-process 
on  settlement,  include  examples  of  GBP  end-to-end  implementation  from  projects  to  provide  further 
details of certain processes.” 
“Possibly include more intermediate steps for some of the GBPs?” 

• 
•  The  process  could  be  simplified  or  having  a  simplified  version  e.g.  flexibility  market  operator  could  be 

omitted if not involved in the process 

regarding possible additions to the framework (Q12. Are there any GBPs that you would like to see added in the 
Framework? Please, briefly describe them), the project indicated the following ideas: 

• 
• 
• 
• 
• 
• 

“Add GPB related to flexibility provision / activation.” 
“GBP related to Energy Apps?” 
“Allocation and management of dynamic connections” 
“Data-driven Digital Twins” 
“EU-wide interoperable Energy Community solutions” 
“Community dataspace for Net Zero homes” 

 bridge 

26 

 
 
 
 
 
 
REFERENCE FRAMEWORK 

Figure 11 Q13. In 2020 and 2021, surveys were conducted to identify relevant standards  
for each interface of the GBPs. Please rate the usefulness of this work 
from “0 – Not useful” to “4 – Very satisfied” (blue) 

Figure 12 Q14.Would you consider an updated analysis of standards useful? 
from “0 – Not useful” to “4 – Very satisfied” (blue) 

Analysis of the usefulness of standards mapping was also conducted with projects indicating as useful both the 
previous  analysis  (Q13)  on  standards  that  took  place  in  20-21  (Figure  11)  as  well  as  the  possibility  (Q14)  of  an 
updated analysis (Figure 12).  

 bridge 

27 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Finally, in terms of improving the usability of the framework (Q15. Do you have suggestion on how to make the 
Reference Framework more practical?), the following ideas were provided: 

•  Online browsing tools for standards/interface references (even at GBP level) 

• 

• 

“Online tool with mapping to relevant standards” 

“A formal UML modelling of the GBP would facilitate their comparison with use cases UML diagrams from 
other projects.” 

•  More formal BPMN process modelling can be leveraged (with clear start and end events of the processes) 
to avoid wrong interpretations of the process diagrams and clear demarcations of the attributes used in 
the diagrams. The details of the interface that can be linked to the diagrams would be add-on. 

• 

“Roadmap  and  responsibilities  for  developing  Operating  Environments  and  core  services  /  core  service 
provider legal framework. “ 

•  Work could be merged with the use case repository (action #1) and show the overlaps of each use case and 

the GBPs to visualise similarities or differences 

•  Practical examples could be useful for understanding the GBP. 

2.1.3 Usability Survey Conclusions 

The survey has provided useful information on the usability of the framework and how  to  increase its value  to 
BRIDGE projects. During the next period, the working group should leverage the survey results and identify how to 
better align GBPs with project use cases, extend the list of GBPs, improve the practicality of the framework and its 
alignment with other frameworks. 

2.2 Contribution to the BRIDGE Use Case Repository 

2.2.1 Opportunity to harmonise use-case descriptions thanks to the 

Reference Framework 

The BRIDGE Use-Case Repository13 has been set up to gather use cases from many different projects. However, one 
of the challenges of using this database is the heterogeneity of the UC descriptions and the lack of references or a 
glossary. Thanks to the massive adoption of IEC 62559-214 template, heterogeneity is not about the structure of the 
use cases' content but the semantics used to describe the use cases. 

This challenge is in fact what motivated the development of the Reference Framework: when performing the first 
analysis of use cases from different projects in 202015, there was a need to establish a reference and map it with 
each of the use cases to enable cross-project analysis.  

When looking at use cases, it appears that the following items would benefit from harmonised semantics: 

13  BRIDGE,  «BRIDGE  Use  Cases  Repository,»  [En  ligne].  Available:  https://bridge-smart-grid-storage-systems-digital-projects.ec.europa.eu/use-cases-
repository. 
BRIDGE, «Set up a use case repository 2.0,» 2022. [En ligne]. Available: https://op.europa.eu/en/publication-detail/-/publication/30ac0765-ac1e-11ed-b508-
01aa75ed71a1/language-en. 
14 IEC, «Use case methodology – Part 2: Definition of the templates for use cases, actor list and requirements list,» 2015. 
15
2021,» 

Interoperability 

flexibility 

«BRIDGE 

 BRIDGE, 

ligne]. 

assets 

Available: 

April 

[En 

of 

– 

– 

https://ec.europa.eu/energy/sites/default/files/documents/bridge_wg_data_management_interoperability_of_flexibility_assets_report_2020-2021.pdf. 

 bridge 

28 

 
 
 
 
REFERENCE FRAMEWORK 

•  Functions:  a  function  is  a  feature  that  the  system  or  a  part  of  it  is  implementing.  It  may  be  related  to 
business  (e.g.  energy  management)  or  be  horizontal  (e.g.  authentication).  Similar  functions  are  found 
across systems, however, often with different names. 

•  Actors: an actor is an entity that communicates and interacts within a use case16. It can include people, 
software applications, systems, databases, … Actors endorse roles. Similar actors are found across systems, 
however, often with different names. The mapping to roles is already helping as the roles are somehow 
already harmonised (see the HEMRM17). However this approach lacks precision and does not reflect the 
system perspective (system actors). 
Information exchanged: to offer the functions, actors are exchanging information. This is detailed in each 
step of the scenarios (see Section 4 of the UC template). The description of information is already being 
harmonised,  in  particular  through  the  development  of  ontologies  (such  as  SAREF4ENER  or  IEC  CIM). 
However, there is no convergence yet. 

• 

As  seen  in  §1.2  and  Annex  1,  the  Reference  Framework  covers  these  3  items:  GBPs  focus  on  defining  which 
stakeholders  (i.e.  actors)  are  performing  which  functions  based  on  which  Information  and  through  which  data 
exchanges (i.e. interfaces). Therefore, there is a relevant opportunity for Action #3 “Reference Framework” to build 
libraries  of  functions,  actors  and  information  exchange  to  support  the  harmonisation  of  use-case  descriptions 
within the BRIDGE Use-Case Repository. 

2.2.2 Generic Actor List 

The Generic Actor List is a concept defined in IEC 62559-218 Section 6. In particular, it has the following objective: 
“[with a] a generic actor list […], only actors of this generic actor list should be used as far as possible in the use 
case”. It is also stated that a Generic Actor List includes: “(1) System actors [that] are covering functions or devices 
(for example in the energy system area, system actors are defined in the interface reference model (IEC 61968-1); 
(2) business actors [that] specify in fact a “role” (roles can be taken by diverse entities)” 

The  Supporting  Materials  of  the  SGTF  EG1  report  of  201919 emphasise  the  need  for  a  Generic  Actors  List.  In 
particular, an existing list is referenced: “A list of actors provided by CENCENELEC-ETSI SG-CG in the Sustainable 
Processes report as well as the actors defined in the Harmonised Electricity Market Role Model can be used here”. 

Indeed, in the CEN/CENELEC/ETSI Sustainable Processes report20, a generic list of actors is detailed in Annexe A (12 
pages of actors description). This list is mostly based on IEC Interface Reference Model (61968-1:2012) and the 
Harmonised Electricity Market Role Model (HEMRM) available at that time (named “ENTSO-E role model” in the 
document). Other sources are referenced such as “SGTF EG3”, “AhG Charging”, “GUC”. This list contains 170 entries 
and certainly requires updating. 

The IEC 62559-221 documents list the expected information for each actor: 

Field 

Example / Comment 

Area 

Example: Smart grid/energy systems 

Mapping to grouping 

Example: To sort requirements for "smart metering" within the area 
"energy system" 

16 IEC, «Use case methodology – Part 2: Definition of the templates for use cases, actor list and requirements list,» 2015. 
17 ebIX, EFET, ENTSO-E, «Harmonised Electricity Market Role Model,» [En ligne]. Available: https://www.ebix.org/artikel/role_model. 
18 IEC, «Use case methodology – Part 2: Definition of the templates for use cases, actor list and requirements list,» 2015. 
19  SGTF  EG1,  «Towards  Interoperability  within  the  EU  for  Electricity  and  Gas  Data  Access  &  Exchange,»  March  2019.  [En  ligne].  Available: 
https://energy.ec.europa.eu/system/files/2019-05/eg1_main_report_interop_data_access_0.pdf. 
20 CEN-CENELEC-ETSI Smart Grid Coordination Group, «Sustainable Processes,» November 2012. [En ligne]. Available: https://www.cencenelec.eu/media/CEN-
CENELEC/AreasOfWork/CEN-CENELEC_Topics/Smart%20Grids%20and%20Meters/Smart%20Grids/smartgrids_sustainableprocesses.pdf. 
21 IEC, «Use case methodology – Part 2: Definition of the templates for use cases, actor list and requirements list,» 2015. 

 bridge 

29 

 
 
 
 
REFERENCE FRAMEWORK 

Name of the actor 

Example: Distribution system operator (DSO) 

Abbreviation for the actor 
name 

Example: DSO 

Actor type  
(e.g. roles, application, …) 

Example: DSO is a role, an energy management system (EMS) is an 
application 

Definition of actor 

Here the actor shall be described. Usually the actor is taken from an 
existing actor list so that the definition already exists 

Possible actors fulfilling this 
role 

Example: For the actor “meter operator” it might be a DSO or an 
independent  meter  operator,  depending  on 
the  national 
background or the specific project 

International, regional or 
national relevance 

Actors might differ in definition depending on regional or national 
legislation or markets 

Source of the definition 

Actors should be based as far as possible on existing data models in 
the relevant area or domain 

Example:  Data  models  like  CIM  common  information  model  (IEC 
61968/61970) or COSEM in the metering domain (IEC 62056) 

Parent 

This column is used to build up a kind of hierarchy of actors 

Example: A grid operator as parent of transmission or distribution 
system operator (TSO or DSO) 

Further comments 

Table 4: List of relevant fields for each of the actors in a Generic Actor List 

Considering the current scope and purpose of the new Generic Actor List, it is proposed to focus on the following 
fields: Area, Name of the actor, Actor type, Definition of actor, Source of the definition.  

2.2.3 Update of the Generic Actor List 

As mentioned above, the Generic Actor List established by CEN/CENELEC/ETSI in 2012 is based on outdated sources. 
Therefore, an update of this list is planned, based on updated references and new sources, in particular:  

IEC Interface Reference Model (IRM) as defined in IEC 61968-1:202022; 

• 
•  Harmonised Electricity Market Role Model (HEMRM) as set out in its release of January 202223. 

For this update, the following approach has been set out: 

22  IEC,  «Application  integration  at  electric  utilities  -  System  interfaces  for  distribution  management  -  Part  1:  Interface  architecture  and  general 
recommendations». 
23 ebIX, EFET, ENTSO-E, «Harmonised Electricity Market Role Model,» [En ligne]. Available: https://www.ebix.org/artikel/role_model. 

 bridge 

30 

 
 
 
 
 
1.  A first analysis is performed by the leader of this task (Trialog, on behalf of InterConnect and RESONANCE) 
2.  Groups of experts, clustered by area, are set up to further analyse each actor and build the updated list 
3.  The  updated  list  will  be  submitted  to  CEN/CLC/ETSI  Coordination  Group  on  Smart  Grid  (CG-SG)  for 

validation and approval 

4.  The updated list will be included in the BRIDGE Use-Case Repository as a library of actors 
5. 

If relevant, this updated list will also be shared with IEC standardisation 

REFERENCE FRAMEWORK 

Plan for the Generic Actor List Update 

Step 1 has been performed by Trialog, on behalf of InterConnect and RESONANCE. The first analysis contains about 
200 entries. The list of actors has been clustered depending on the area and priorities have been established: 

 bridge 

31 

 
 
 
 
 
REFERENCE FRAMEWORK 

Area 

Number of 
items 

Grid Management 

Smart Metering 

Electric Mobility 

Market Operation 

Power Generation / 
DER 

Smart Home / Smart 
Building / Smart City 

Data Management 

Customer 
Relationship 

Third parties / Other 

68 

15 

12 

31 

7 

23 

5 

15 

23 

Priority 

1 (high) 

1 (high) 

1 (high) 

1 (high) 

2 (medium) 

2 (medium) 

2 (medium) 

3 (low) 

3 (low) 

Table 5: List of areas for the update of the Generic Actor List 

For  Step  2,  a  call  for  participation  was  circulated  in  the  Data  Management  WG  and  Regulation  WG  in 
January/February  2024.  Based  on  the  23  answers  received,  a  list  of  16  contributors  was  identified  and  a  few 
additional reviewers were appointed.  

The Step 3 was started in February 2024. The following overall schedule is planned: 

Figure 13: Overall schedule for the Generic Actor List update 

As detailed in this diagram: 

•  Areas with priority level 3 will be treated in parallel with level 2 areas 
•  Review meetings with CEN/CLC/ETSI CG-SG will be planned regularly 
• 

Intermediate releases will occur after each review meeting 

A connection will also be established with the ENTSO-E / EU DSO Entity JWG to ensure consistency with the latest 
developments of the HEMRM and the Electricity Directive Implementing Acts. 

 bridge 

32 

 
 
 
 
 
REFERENCE FRAMEWORK 

3  Guidelines for Settlement Implementation 

3.1 Settlement 

Settlement in flexibility procurement processes refers to the finalisation of transactions and agreements between 
the parties involved in the procurement of flexibility services within the energy sector. It involves the financial and 
contractual aspects of acquiring flexibility resources to balance supply and demand on the energy grid. Settlement 
in flexibility procurement processes aligns closely with the generic business process framework established by the 
BRIDGE Working Group (WG). In the context of electricity grids, settlement occurs after a flexibility service provider 
has delivered the contracted amount of flexibility, which could include adjusting energy production or consumption 
levels in response to grid needs. The settlement process ensures that the provider is compensated appropriately 
for the services rendered. Key components of settlement in flexibility procurement processes typically include: 

•  Metering and Measurement: Accurate measurement of the flexibility provided is essential for settlement. 
This  involves  metering  the  relevant  parameters,  such  as  energy  production  and/or  consumption,  to 
determine the quantity of flexibility delivered. 

•  Validation and Verification: Before settlement occurs, there is often a validation and verification process 
to ensure that the flexibility services meet the requirements specified in the procurement agreement. This 
may involve checking the quality, accuracy, and timeliness of the provided flexibility. 

•  Calculation  of  Payments:  Settlement  involves  calculating  the  payments  owed  to  the  flexibility  service 
provider based on the agreed-upon terms and conditions outlined in the procurement contract. Payments 
may be structured based on various factors, including the quantity and quality of flexibility delivered, as 
well as any performance incentives or penalties. 
Invoicing and Payment Processing: Once the settlement calculations are completed, invoices are issued to 
the relevant parties, detailing the amount owed for the flexibility services. Payment processing involves the 
transfer of funds from the procuring entity to the flexibility service provider in accordance with the agreed-
upon payment terms. 

• 

•  Reporting  and  Documentation:  Settlement  processes  often  require  comprehensive  reporting  and 
documentation  to  ensure  transparency  and  accountability.  This  includes  maintaining  records  of 
transactions, metering data, validation results, and payment documentation for auditing and regulatory 
compliance purposes. 

3.2 Lessons Learned from EU-Funded Projects 

This  section  presents  insights  gathered  from  various  EU-funded  projects  regarding  the  implementation  of  the 
Settlement sub-process in the provision of flexibility. As the transition towards more flexible and sustainable energy 
systems accelerates as does the deployment of flexibility markets, the efficient settlement of transactions between 
market participants becomes increasingly crucial. In this context, understanding the challenges, best practices, and 
emerging trends in settlement processes is paramount for ensuring the smooth operation of energy markets. The 
feedback provided encompasses a range of perspectives and experiences from stakeholders involved in EU-funded 
projects: 

•  Clarity  in  Contractual  Agreements:  Clear  and  well-defined  contractual  agreements  between  parties 
involved  in  flexibility  procurement  are  essential.  This  includes  specifying  terms  related  to  pricing 
mechanisms,  service 
levels,  performance  metrics,  and  settlement  procedures  upfront  to  avoid 
misunderstandings during the settlement process. 

•  Standardisation of Data Formats: Standardising data formats and communication protocols for reporting 
flexibility service delivery is crucial for streamlining the settlement process. Consistent data formats enable 
automated metering, validation, and reconciliation, reducing manual intervention and potential errors. 
•  Automated Metering and Validation: Implementing automated metering and validation processes helps 
ensure  the  accuracy  and  reliability  of  data  used  for  settlement.  Automated  systems  can  detect 

 bridge 

33 

 
 
 
REFERENCE FRAMEWORK 

discrepancies or anomalies in reported data more efficiently, facilitating faster resolution and reducing the 
risk of disputes. 

•  Transparent and Timely Reporting: Establishing transparent and timely reporting mechanisms for flexibility 
service  delivery  enables  stakeholders  to  track  performance  and  monitor  compliance  with  contractual 
obligations. Real-time or near-real-time reporting allows for proactive management of settlement-related 
issues and enhances trust between parties. 

•  Robust Dispute Resolution Mechanisms: Despite  efforts to standardise  processes  and ensure accuracy, 
disputes  may  still  arise  during  the  settlement  process.  Having  robust  dispute  resolution  mechanisms  in 
place,  such  as  arbitration  or  mediation  procedures,  helps  address  disagreements  promptly  and  fairly, 
minimising disruptions to ongoing operations. 

•  Continuous Monitoring and Improvement: Continuous monitoring of the settlement process is essential 
for  identifying  inefficiencies,  bottlenecks,  or  areas  for  improvement.  Regular  evaluations  and  feedback 
loops  enable  stakeholders  to  refine  procedures,  enhance  system  performance,  and  adapt  to  evolving 
requirements over time. 

•  Collaboration and Knowledge Sharing: Collaboration and knowledge sharing among stakeholders involved 
in  flexibility  procurement  and  settlement  processes  are  vital  for  promoting  best  practices  and  driving 
innovation. Sharing lessons learned, success stories, and challenges encountered can benefit the broader 
energy community and contribute to continuous improvement efforts. 

•  Harmonisation  of  Telemetry  and  Time-Granularity  Requirements:  Guidelines  for  telemetry  and  time-
granularity requirements should be harmonised at the European level, considering the time characteristics 
of  flexibility  products  to  ensure,  in  turn,  broader  harmonisation  of  settlement  processes  in  European 
flexibility  markets.  Real-time  telemetry  harmonisation,  addressing  factors  such  as  data  quality  and 
granularity of measurements, is essential. 

•  Attributes of Flexibility Products: Flexibility products are characterised by attributes, including preparation 
time and time activations, which clearly determine the telemetry requirements. Fast flexibility products 
that should be activated in seconds have different time-granularity requirements than those activated in 
hours. 
Independent  Aggregation  and  Data  Collection:  Enabling  independent  aggregation  while  managing  the 
responsibilities of different actors entails complexity in data collection. Developing strategies to address 
this complexity is crucial for ensuring accurate and reliable settlement processes. 

• 

•  Best Practices for Verification and Compensation: Establishing a set of best practices for verification and 
compensation processes is necessary. These practices should address both information exchange needs 
among market players (e.g., BRPs access to FSP resource information) and means of verification of actual 
flexibility delivery for SOs. 

3.3 Guidelines for Settlement Implementation 

3.3.1 Measurement and Verification  

For  flexibility  services,  measurement  and  verification  (M&V)  needs  are  typically  more  stringent  compared  to 
traditional DR programs. This is because distribution services involve the direct management and control of DER 
within  the  distribution  grid.  These  resources,  which  can  include  solar  panels,  battery  storage  systems,  electric 
vehicles, and demand response-enabled appliances, are located closer to end users and are often interconnected 
with the distribution grid. As a result, M&V processes for  flexibility  services require accurate and granular data 
collection to measure the performance of individual DER and their collective impact on grid operations. This may 
involve  real-time  monitoring  of  energy  consumption,  generation,  voltage  levels,  frequency,  and  other  grid 
parameters at the distribution level. Sophisticated metering, telemetry, and data analytics technologies are often 
deployed  to  capture  and  analyse  this  data  effectively.  In  contrast,  traditional  DR  programs  typically  focus  on 
aggregating flexible loads or generation from a diverse portfolio of participants to provide a statistical response to 
grid  events.  The  M&V  requirements  for  these  programs  may  be  less  stringent,  as  they  rely  on  aggregated 
measurements and statistical methods to estimate overall program performance rather than individual resource 
performance. 

 bridge 

34 

 
 
 
REFERENCE FRAMEWORK 

Similarly, settlement processes for flexibility services tend to be more complex and detailed compared to traditional 
DR programs. Flexibility services involve active participation in grid operations and may require bidirectional energy 
flows,  dynamic  pricing  mechanisms,  and  flexible  contracting  arrangements  between  SOs  and  DER  owners. 
Settlement  for  flexibility  services  involves  accurately  quantifying  the  energy  exchanged  between  the  grid  and 
individual DERs, accounting for bidirectional energy flows, time-of-use pricing, and any ancillary services provided. 
This  requires  robust  billing  systems,  metering  infrastructure,  and  contractual  frameworks  to  ensure  fair  and 
transparent compensation for DER participation in grid services. In contrast, settlement for traditional DR programs 
may be based on predetermined payment structures, capacity commitments, or incentive-based mechanisms that 
do not necessarily require detailed energy accounting or bidirectional transactions. 

Overall, the greater stringency of M&V requirements for distribution services reflects the evolving nature of grid 
operations  and  the  increasing  role  of  distributed  energy  resources  in  supporting  grid  reliability,  resilience,  and 
efficiency. As distribution systems become more dynamic and interconnected, accurate measurement, verification, 
and settlement processes become essential for effective grid management and DER integration. 

3.3.2 M&V Methods 

M&V methods play a critical role in the procurement of flexibility services within the energy sector. These methods 
are essential  for  ensuring the  accuracy,  reliability,  and  transparency of  flexibility  service  delivery, as well  as  for 
verifying compliance with contractual agreements and regulatory requirements. One key aspect of M&V methods 
is the measurement of actual flexibility provided by market participants. This involves collecting and analysing data 
related to energy consumption, generation, or demand response activities in real-time or near-real-time. Advanced 
metering infrastructure, telemetry systems, and data analytics tools are often used to capture and process this data 
efficiently. 

Verification of flexibility delivery entails comparing the  measured performance against  predefined benchmarks, 
targets, or service level agreements (SLAs). This verification process may involve validating the timing, duration, 
and  magnitude  of  flexibility  responses,  as  well  as  ensuring  adherence  to  quality  standards  and  operational 
constraints. Various methodologies for M&V exist to facilitate the provision of grid services by DERs, ranging from 
straightforward schemes to more intricate verification processes. This section offers an outline of five prevalent 
approaches,  each  differing  in  complexity,  as  summarised  in  Table  6.  To  determine  the  most  suitable  M&V 
approach(es) for verifying the performance of providers of specific grid services, several factors need to be taken 
into account. These encompass the nature of the service requirements in question, the positioning of the DER(s) 
delivering the service (Front-of-the-Meter or Behind-the-Meter), whether the service is delivered by an individual 
DER  or  an  aggregation,  and  the  availability  and  granularity  of  existing  metering  equipment,  along  with  the 
associated data. 

Table 6 Comparison of common M&V approaches (based on EPRI, «Measurment and Verification (M&V) for 
Distributed Energy Resources Providing Grid Services - New Complexities, Common Approaches, and Research 
Needs,» 2021) 

M&V Approach 

Principle 

Time Horizon of 
Assessment 

Metering 
Requirements 

Relative Complexity 

(1) System of 
notifications 

No explicit 
performance 
assessment or 
limited to receipt 
of basic messages. 

None, or limited 
to receipt of 
basic messages. 

No meter required. 

Lower 

(2) Measurements 
before/ after service 
activation 

Verify that 
response trend is 
consistent with 
expected response. 

Period of time 
before/ after 
service 
activation. 

Meter upstream of 
resource providing 
service, with 

Medium 

 bridge 

35 

 
 
 
(3) Evaluation against 
comparable service 
providers 

(4) Use of historical 
baselines 

Compare 
performance of 
service provider 
against other 
similar service 
providers. 

Compare 
performance of 
service provider 
against its own 
behaviour when 
not delivering 
service. 

Service delivery 
window. 

Service delivery 
window. 

(5) Dedicated Meter 

Assess DER 
response through 
dedicated 
metering data. 

Service delivery 
window. 

REFERENCE FRAMEWORK 

sufficient data 
granularity. 

Meter upstream of 
resource providing 
service, with 
sufficient data 
granularity. 

Meter upstream of 
resource providing 
service, with 
sufficient data 
granularity. 

Dedicated meter 
required to 
monitor resource 
providing service, 
with sufficient data 
granularity. 

Medium 

Higher 

Higher 

3.3.2.1  System of Notifications 

According to Figure 14, this method, commonly employed in demand response (DR) programs, entails dispatching 
activation  signals  to  enrolled  resources,  such  as  extensive  collections  of  small-scale  flexible  loads  (e.g.,  water 
heaters). Each activation signal is dispatched either directly by the entity requesting the service or through a third-
party aggregator. Upon receiving an activation signal, each resource is required to engage local controls to adjust 
its operation. The activation signal may specify a start time and/or the desired level of response ("normal," "critical," 
etc.). In certain DR programs, this "open loop" notification system suffices, while in others, the resource is expected 
to  transmit  an  acknowledgement  message  confirming  receipt  of  the  activation  signal.  In  this  initial  approach, 
individual resources are not expected to provide detailed reports on their performance (e.g., kW reduction). 

Figure 14 System of Notifications (based on EPRI, «Measurment and Verification (M&V) for Distributed Energy 
Resources Providing Grid Services - New Complexities, Common Approaches, and Research Needs,» 2021.) 

is  necessary  for  evaluating 
Advantages–Implementation  simplicity:  No  specialised  metering  equipment 
performance, and communication requirements are minimal. This method is applicable to all types of DER as long 

 bridge 

36 

 
 
 
 
REFERENCE FRAMEWORK 

as the predetermined local response to be triggered upon receiving an activation request is specified (e.g., for a 
water heater, ceasing consumption until its energy content reaches a specific threshold). 

Disadvantages–Lack of detailed performance verification: A resource that receives an activation request may only 
partially  adjust  its  behaviour  or  not  modify  it  at  all,  even  after  sending  an  acknowledgement  signal  confirming 
receipt of the request. Additionally, two resources exhibiting different performance levels would likely receive the 
same  financial  compensation  since  detailed  performance  assessment  is  not  conducted,  potentially  leading  to 
unfairness and free-riding issues. 

3.3.2.2 Measurement Before/After Service Activation 

This  method,  depicted  in  Figure  15,  acknowledges  that  all  DERs  supplying  a  grid  service  are  consistently  linked 
downstream of a revenue-grade meter, either individually or alongside other co-located resources. Its objective is 
to use existing metering apparatus to validate that the observed "trend" in metering data immediately following 
service activation aligns with the anticipated response. The goal is not to conduct a thorough evaluation over the 
entire service delivery duration but rather to evaluate the coherence of the initial response trend.  

Advantages–Ease  of  implementation:  Uses  existing  metering  infrastructure  to  confirm  that  the  response  trend 
immediately after activation aligns with anticipated  behaviour; eliminates the need for comprehensive baseline 
calculations at the service provider level to establish historical baselines. 

Disadvantages–Potential for manipulation: Customers might attempt to artificially boost their consumption before 
receiving  an  activation  request,  particularly  those  with  low  load  factors;  the  granularity  of  data  from  existing 
revenue meters may be inadequate for accurately assessing the response trend, and accessing the data may be 
challenging; overall, performance evaluation is conducted with limited detail. 

Figure 15 Measurements before/after service activation request (based on EPRI, «Measurment and Verification 
(M&V) for Distributed Energy Resources Providing Grid Services - New Complexities, Common Approaches, and 
Research Needs,» 2021) 

3.3.2.3 Evaluation Against Comparable Service Providers 

This method operates under the assumption that service providers can be categorised based on similarities, such 
as water heaters or AC systems of comparable sizes. It evaluates the effectiveness of each individual response by 
comparing it to the average  response achieved by similar service  providers (refer to Figure 4). This approach is 
especially pertinent for extensive collections of service providers with shared characteristics. 

 bridge 

37 

 
 
 
 
 
REFERENCE FRAMEWORK 

Figure 16 Performance evaluation against a group of similar providers (based on EPRI, «Measurment and 
Verification (M&V) for Distributed Energy Resources Providing Grid Services - New Complexities, Common 
Approaches, and Research Needs,» 2021) 

Advantages–Implementation is relatively simpler compared to Approach 4 outlined below, as it doesn't necessitate 
historical baselines, yet it still quantifies the observed performance  level; consequently, financial compensation 
could  potentially  be  linked  to  the  quantified  performance  level.  This  method  also  enables  consideration  of 
independent variables, such as weather-related factors, which might affect performance across a group of similar 
providers. 

Disadvantages–Like Approach 2 (measurement before/after service activation), this method requires sufficiently 
granular  metering  data,  which  may  not  be  available  from  existing  meters.  Additionally,  it  doesn't  evaluate 
performance against what the service provider would have done if not responding to the service request, which 
may be desirable for certain services. Instead, it assesses how effectively the provider delivers a particular service 
compared to similar providers. 

3.3.2.4 Use of Historical Baselines 

This  method  evaluates  the  actual  behaviour  of  each  service  provider  throughout  the  service  delivery  period.  It 
compares the observed behaviour against a baseline, which represents what the resource would have done if it 
weren't delivering the service. Performance is determined by the variance between 1) the actual behaviour of the 
resource when providing the service, and 2) the anticipated behaviour indicated by the baseline. The baseline can 
be established at different levels, depending on the service under consideration. For instance, it might be set at an 
end-user  meter  that  measures  multiple  co-located  resources,  including  the  ones  providing  the  service. 
Alternatively, it could be set at a meter (or sub-meters) dedicated solely to monitoring the DER(s) delivering the 
service. 

Figure 17 Performance assessment against baseline (based on EPRI, «Measurment and Verification (M&V) for 
Distributed Energy Resources Providing Grid Services - New Complexities, Common Approaches, and Research 
Needs,» 2021.) 

Advantages—Similar to Approach 3 (evaluation against comparable service providers), this method allows for the 
quantification of performance and the consideration of independent factors (e.g., weather) when calculating the 

 bridge 

38 

 
 
 
 
 
baseline. However, unlike Approach 3, this approach assesses the provider's response against what it would have 
done if it were not delivering the service. 

Disadvantages—Sufficient granularity in the metering data is necessary, which may not be provided by existing 
meters.  Additionally,  establishing  meaningful  baselines  can  be  challenging  for  small-size  resources,  particularly 
flexible loads with a low load factor, as their discrete behaviour is more difficult to represent using baselines. 

REFERENCE FRAMEWORK 

Dedicated Meter 

This  approach  necessitates  individual  metering  for  each  resource  delivering  a  grid  service,  whether  through  a 
dedicated meter for Front-of-the-Meter  (FTM) resources or a dedicated sub-meter for  behind-the-meter (BTM) 
resources.  For  DERs  providing  a  mix  of  grid  and  customer  services,  dedicated  metering  may  be  coupled  with 
baseline comparisons. 

Advantages—This method offers resource-specific metering data for every grid service provider, enabling detailed 
performance evaluation and providing operational advantages like load unmasking. 

Disadvantages—Costs pose a significant challenge with this approach, encompassing expenses related to metering 
equipment and communication infrastructure needed for data transmission. Also, end users sometimes object to 
installing  additional  sub-metering  equipment  in  their  households/buildings,  especially  when  these  are  visible. 
Additionally,  for  BTM  DERs,  there  are  concerns  about  potential  tampering  with  third  party-owned  sub-meters, 
along with privacy and security issues associated with data transmission from these endpoints. 

3.4 Baselining Methodologies 

Baselining  methodologies  for  flexibility  services  are  essential  for  accurately  evaluating  the  performance  of 
resources providing flexibility services. These methodologies establish a reference point against which the actual 
behaviour of resources is compared during service delivery. One common approach involves using historical data 
to  create  historical  baselines,  reflecting  the  typical  behaviour  of  resources  when  not  delivering  the  service. 
Statistical methods are often employed to develop baselines based on historical data, such as averaging historical 
performance  over  a  specific  period  or  using  statistical  models  to  predict  resource  behaviour.  Some  baselining 
methodologies are described as follows: 

•  High  X  of  Y:  This  method  selects  the  highest  value  (X)  from  a  set  of  historical  data  points  (Y)  within  a 

specified time frame to establish the baseline. 

•  Regression: Regression analysis is used to model the relationship between relevant factors (such as time, 
weather conditions) and energy consumption, enabling the prediction of expected consumption levels. 
•  Comparable Day: The baseline  is determined by comparing the energy consumption of the current  day 
with that of similar days in the past, adjusted for relevant factors like weather conditions and day type. 
•  Rolling  Average:  This  method  calculates  the  baseline  by  averaging  energy  consumption  over  a  defined 

historical period, such as the past few days or weeks, to smooth out short-term fluctuations. 

•  Statistical Sampling:  A subset of historical data points is randomly selected to represent  typical energy 

consumption patterns, providing a simplified baseline estimation. 

•  Meter Before/Meter After: The baseline is established by comparing energy consumption before and after 

a specific intervention or change, such as the activation of a demand response event. 

•  Maximum Base Load: This method sets the baseline as the maximum energy consumption observed during 

a specified historical period, representing the highest expected demand level. 

•  Metering Generator Output: The baseline is determined by monitoring the output of a generating source 
(e.g., solar panels, wind turbines) under normal operating conditions, providing a reference for expected 
energy production. 

•  Machine  Learning:  Machine  learning  algorithms  analyse  historical  energy  consumption  data  to  identify 

patterns, trends, and anomalies, enabling the prediction of future consumption levels. 

 bridge 

39 

 
 
 
REFERENCE FRAMEWORK 

•  Control Groups: A baseline is established by comparing the energy consumption of a group receiving the 
service  with that of a control group not  receiving the service,  allowing for the isolation of the service's 
impact. 

•  Self-declared Baseline: Participants declare their expected energy consumption levels based on historical 
usage patterns or other relevant factors, providing a simple and flexible baseline estimation method. 

The selection of baseline methodologies for different flexibility products in the demonstration, as well as the factors 
influencing this choice, is addressed in the deliverable D3.4 of the OneNet project24. The demonstration experience 
highlights that only a subset of available baselining methodologies is practically used, reflecting the complexity of 
decision-making in this context. Furthermore, the absence of a distinct preference for any specific methodology 
underscores the importance of accommodating diverse approaches, echoing the principles outlined in D3.4. The 
process for selecting a methodology is contingent upon various factors, including stakeholder expertise, regulatory 
requirements,  and  available  resources,  which  aligns  with  the  considerations  discussed  in  the  OneNet  project. 
Moreover, the need for alternative solutions and robust verification measures to ensure accuracy and integrity, as 
suggested in the demonstration, corresponds to the recommendations put forth in D3.4 of the OneNet project for 
establishing  a  reliable  regulatory  framework  for  baselining.  This  example  from  the  OneNet  project  serves  as  a 
valuable example for determining the appropriate baseline methodology to apply to various flexibility products. 

Table 7 Overview of baseline methodology per product used in the OneNet demonstrators25 

Product 

High X to Y 

Comparable day 

Meter before / 
Meter after 

Self-declared FSP 

aFRR 

mFRR 

RR 

Corrective Local 
Active Power 

Corrective local 
reactive power 

Greece 

Northern Cluster, 
Greece 

Poland 

Northern 

Poland 

Northern Cluster 

Spain 

Slovenia 

Greece 

Predictive short-
term active power 

Northern Cluster, 
Greece 

Spain 

Poland 

Predictive long-
term local active 
power 

Northern cluster 

Spain 

Northern Cluster, 
Cyprus, Spain 

Cyprus 

Northern Cluster, 
Spain, Poland 

Northern Cluster, 
Spain 

The conclusions extracted from the analysis presented in D3.4 of the OneNet project offer valuable insights into 
various aspects of baselining methodologies and their application in the context of flexibility services. As the energy 
sector  transitions  towards  greater  flexibility  and  decentralisation,  understanding  the  intricacies  of  baselining 

24  OneNet,  «D3.4  Regulatory  and  demo  assessment  of  proposed  integrated  markets,»  [En  ligne].  Available:  https://www.onenet-project.eu//wp-
content/uploads/2023/09/OneNet_D3.4_V1.0.pdf. 
25 OneNet Project, «D3.4 Regulatory and demo assessment of proposed integrated markets,» 2023. 

 bridge 

40 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

becomes increasingly crucial, particularly within the Settlement subprocess of flexibility procurement. Through a 
comprehensive  examination  of  key  questions  surrounding  baselining,  informed  by  both  literature  review  and 
OneNet  demonstrator  experiences,  a  nuanced  understanding  emerges  regarding  the  principles  of  simplicity, 
accuracy,  and  integrity.  These  insights  provide  valuable  guidance  for  policymakers,  regulators,  and  industry 
stakeholders navigating the evolving landscape of energy markets and seeking to develop effective frameworks for 
the deployment of flexibility services. The following questions were analysed in the OneNet project, shedding light 
on critical considerations in the design and implementation of baselining methodologies26: 

1.  Which relationship is the baseline methodology applied to? 

a.  When considering the relationship, baselining methodologies can be broadly categorised into two 
fields: contractual relationships between customers and intermediaries, and relationships between 
aggregators and system operators (SOs). Upholding principles of simplicity, accuracy, and integrity 
is crucial for both relationships, given the public interest in maintaining trust and reliability in the 
energy system. 

2. 

In which grid operational state is the baseline methodology used? 

a.  The choice of baseline methodology may vary depending on the operational state of the grid. While 
simplicity and transparency are vital during normal grid operation, accuracy and integrity become 
more  critical  during  emergency  states  to  maintain  trust  in  the  system.  Balancing  these 
requirements  needs  careful  consideration  and  may  require  separate  baselines  for  different 
operational states. 

3.  Who is responsible for setting the baseline? 

a.  Four actors are typically considered for setting the baseline: the system operator (SO), independent 
market  operator  (IMO),  flexible  service  provider  (FSP),  or  an  independent  third  party  like  the 
regulator.  Each  allocation presents  trade-offs,  such  as  simplicity versus  information  asymmetry. 
Demos  often  assign  this  responsibility  to  FSPs  or  SOs,  with  fallback  options  and  monitoring 
measures in place to ensure accuracy and compliance. 

4.  Which type of customer is baselining applied to? 

a.  Baselining methodologies are tailored to different  customer types. Non-professional customers, 
such as households, prefer simple baselines for transparency, while professional customers, like 
commercial entities, prioritise accuracy without excessive complexity. This preference influences 
the  choice  of  baseline  methodology  in  OneNet  demos,  with  a  focus  on  simplicity  and  medium 
accuracy. 

5.  Which type of DER is baselining applied to? 

a.  Baselining approaches differ for various types of DERs based on their participation and aggregation 
levels. While accuracy is crucial for isolated DERs in electricity markets, combined DERs  require 
baselines  that  accurately  reflect  their  contributions  while  maintaining  simplicity.  The  choice 
between aggregated or individual baselines depends on factors like technology type and portfolio 
composition. 

6.  Which product is baselining applied to? 

a.  Different flexibility products necessitate distinct baselining methodologies, primarily determined 
by  product  characteristics  such  as  capacity,  activation  duration,  and  preparation  time.  While 
simplicity  remains  consistent  across  methodologies,  accuracy  and  integrity  are  influenced  by 
product-specific requirements. While demo experiences often employ a single methodology across 
all products, the choice is influenced by regulatory frameworks and existing tools and information. 

DERs, including heat pumps, PV/wind, back-up generation, combined heat and power, or storage/batteries, offer 
diverse  participation  possibilities  in  flexibility  markets.  They  can  operate  independently  or  be  combined  with 
demand reduction actions of an active consumer behind the main meter. Alternatively, they may be aggregated 
into  a  larger  portfolio  managed  by  an  aggregator.  Baseline  methodologies  for  isolated  DERs  vary  in  terms  of 
simplicity, accuracy, and integrity, depending on the DER type. For combined DERs, accuracy is crucial to avoid over- 
or under-incentivisation, especially when both demand reduction and generation assets are involved. Submetering 
is advocated to improve accuracy, particularly for combined DERs, enabling better performance quantification and 
supplier  accountability.  Aggregated  baselines  may  be  calculated  for  the  same  or  different  types  of  DERs,  each 

26 OneNet Project, «D3.4 Regulatory and demo assessment of proposed integrated markets,» 2023. 

 bridge 

41 

 
 
 
 
REFERENCE FRAMEWORK 

requiring tailored methodologies. Simpler baseline approaches may enhance accuracy when aggregating DERs of 
the same type, while transparent and consistent calculation methods are vital for integrity, especially in aggregated 
baselines, to prevent manipulation and ensure fairness and reliability. 

Assessing selected baseline methodologies in accordance with the type of DER against the baselining principles of 
accuracy (A), simplicity (S), integrity (I), and efficacy (E) draws upon the research conducted within the CoordiNet 
project  as outlined  in  deliverable D2.127.  This  assessment  involves  scrutinising  different  baseline  approaches  to 
determine their effectiveness in accurately quantifying the contribution of DERs (accuracy), minimising complexity 
for market participants (simplicity), ensuring the reliability and robustness of baseline calculations (integrity), and 
ultimately achieving the desired outcomes of flexibility provision and grid stability (efficacy). 

Figure 18 Baseline decision framework adopted in the CoordiNet project28 

3.5 Data Requirements 

There are two categories of metering data that are integral to the M&V process. Firstly, there is revenue-grade 
meter data, which has conventionally been used for retrospective verification and settlement purposes. Secondly, 
there is real-time operational data, the use of which depends on factors such as the nature of the flexibility service, 
the  available  metering  resolution,  and  the  frequency  of  data  streaming  to  the  entity  requiring  the  service.  For 
instance, operational data can be employed to promptly identify instances where a DER service provider fails to 
fulfil their contractual commitments, allowing for immediate action to be taken if necessary. Both types of metering 
data may originate from a single or multiple metering infrastructures. 

DERs are typically smaller than traditional resources, which can result in higher costs for conventional metering and 
telemetry solutions when applied to DER  projects. Additionally, DERs often deliver services to multiple entities, 
such as DSOs and TSOs, introducing new challenges in terms of "accounting" for these services. This is in contrast 
to  conventional  resources,  which  typically  operate  within  a  single  service  domain.  Moreover,  geographically 
dispersed DERs may offer services as part of an aggregated group, unlike conventional resources that are usually 

27 CoordiNet, «D2.1 Markets for DSO and TSO procurement of innovative grid services: Specifications of the architecture, operation and clearing algorithms,» 
2021. 
28 CoordiNet, «D2.1 Markets for DSO and TSO procurement of innovative grid services: Specifications of the architecture, operation and clearing algorithms,» 
2021. 

 bridge 

42 

 
 
 
 
 
 
standalone assets. However, despite these differences, the fundamental objective of M&V remains consistent: to 
ensure that each service provider adheres to the service requirements outlined in their contracts. 

REFERENCE FRAMEWORK 

The positioning of DERs on the grid, whether they are "behind-the-meter" (BTM) or "front-of-the-meter" (FTM), is 
crucial for effective M&V planning, especially in the context of settlement processes. BTM DERs are situated on the 
customer's side of the electricity meter, allowing on-site energy consumption without metering, while FTM DERs 
deliver energy off-site, necessitating metered passage  through the  end-user meter. This distinction significantly 
impacts  settlement  procedures,  with  BTM  resources  typically  operating  under  retail  tariffs  and  FTM  resources 
subject to retail or wholesale tariffs, depending on various factors such as DER type and service offerings. 

Figure 19 Metering configurations: dedicated meter (1-a) or sub-meter (1-b), vs. meter shared between 
participating and non-participating resources (2) 

The  majority  of  prevalent  M&V  methodologies  outlined  in  Table  6  rely  on  metering  data  to  evaluate  the 
effectiveness of the grid services rendered. These data configurations can generally be classified into two primary 
categories.  In  the  first  category,  DERs  delivering  grid  services  are  equipped  with  their  own  dedicated  metering 
infrastructure (Configuration 1-a in Figure 19) or sub-meter (Configuration 1-b in Figure 19). Alternatively, in the 
second  category,  DERs  are  metered  alongside  loads  and  other  resources  that  may  not  provide  the  same  grid 
services or may offer different ones (Configuration 2 in Figure 19). Configuration 1-a is typically used for FTM DERs 
engaged in grid services provision, while Configuration 1-b becomes pertinent when individual metering of BTM 
DERs  is  mandated  within  the  M&V  framework.  Configuration  2  is  commonly  observed  in  M&V  methodologies 
employed  in  demand  response  (DR)  programs;  whose  baseline  establishment  relies  on  data  obtained  from  the 
existing end-user meter. 

In addition to DER location and data granularity, the aggregation of DERs and the potential for submetering play 
crucial  roles  in  M&V  planning,  particularly  concerning  settlement  processes.  Aggregating  DERs  allows  for  the 
collective assessment of multiple distributed resources, providing a comprehensive view of their combined impact 
on the grid. This aggregation can streamline settlement procedures by consolidating data from various sources and 
simplifying the calculation of payments or credits for grid services. Submetering offers a valuable tool for M&V, 
enabling the isolation and measurement of specific components within a larger system. Submetering allows for the 
precise monitoring of individual DERs or subsets of DERs, facilitating accurate assessment of their performance and 
contribution to grid services. By submetering, the granularity of data collection can be enhanced, providing detailed 
insights into the operation and efficiency of each DER unit. 

 bridge 

43 

 
 
 
 
 
REFERENCE FRAMEWORK 

The granularity of data required varies across different flexibility services, reflecting the diverse operational needs 
and  objectives  of  each  service.  For  instance,  services  involving  real-time  response  to  grid  conditions,  such  as 
frequency  regulation  or  voltage  support,  demand  highly  granular  data  with  rapid  sampling  rates  to  capture 
fluctuations  in  supply  and  demand.  On  the  other  hand,  services  focused  on  longer-term  optimisation,  such  as 
capacity  provision  or  energy  arbitrage,  may  require  less  frequent  data  sampling  but  still  necessitate  detailed 
information on energy consumption and generation patterns. Furthermore, the granularity of data may differ based 
on  the  specific  characteristics  of  the  flexibility  service  and  the  underlying  technologies  involved.  For  example, 
services  using  fast-responding  resources  like  battery  storage  or  fast-acting  demand  response  may  require  sub-
second  granularity  to  capture  rapid  changes  in  output  or  consumption.  In  contrast,  services  relying  on  slower-
responding resources such as thermal storage or distributed generation may tolerate coarser data granularity but 
still require sufficient resolution to capture relevant operational parameters. 

As an illustrative example, the identification of needs for explicit DR in the ACCEPT project is presented below: 

•  Quantify delivered flexibility  

o  Power and energy consumption data from eligible prosumers  and district level assets respectively  
o  Data granularity – 15 minutes 
o  Flexibility provided period (specific hours during the day) 
o  Power/energy from controllable loads (i.e. dhw,hvac) 
o  Power/energy from building-level PVs (generation) 
o  Power/energy from district-level PVs (generation) 

•  Quantify procured flexibility  

o  Data granularity – 15 minutes 
o  Baseline power/energy from each consumer (W/kWh) 
o  Actual power/energy from each consumer (W/kWh) 

•  Flexibility sold  

o  Data granularity – 15 minutes 
o  Quantify delivered flexibility 
o  Remuneration price in €/kWh based on the SLAs 

•  SC229 – flexibility fee calculation  

o  Data granularity – 15 minutes 
o  Quantify procured flexibility (W/kWh) 
o  Price in €/kWh specified by the provider 

•  SP329 – flexibility fee validation  

o  Data granularity – 15 minutes 
o  Flexibility fee calculated (€/kWh) 
o  Dynamic  pricing  factors  (such  as  Electricity  Market  Prices,  Network  Constraints,  Weather 

Conditions, etc.) 

•  SP429 – settle flex  

o  Data granularity – 15 minutes 
o  Flexibility fee validation (€/kWh) 
o  Actual Consumption and Generation Data (W/kWh) 
o  Baseline Consumption and Generation Data (W/kWh) 
o  Flexibility Fee Rates (€/kWh) 
o  Dynamic Pricing Data (€/kWh) 

3.6 Settlement subprocess 

The Settlement generic subprocess is detailed in Annexe 1 (§3.6), together with a comparative analysis with projects 
implementing the settlement (performed last year). 

29 See Figure 27. Business process diagram for the settlement subprocess 

 bridge 

44 

 
 
 
 
REFERENCE FRAMEWORK 

4  Conclusion and Perspectives 

4.1 Main Findings and Recommendations 

This section describes the main findings and recommendations regarding the Reference Framework. 

Topic 

Usability Survey – Standards Mapping 

Findings 

The  survey  on  standards  conducted  in  2020  and  2021,  identifying  relevant 
standards  for  each  interface  of  the  GBPs,  was  considered  useful  by  project 
participating in the survey.  

Recommendation 

A new survey on the use of standards used by different projects, in the context of 
the Reference Framework, could provide useful insights, enabling faster alignment 
among stakeholders.  

Topic 

Usability Survey – Extension 

Findings 

Recommendation 

Most of the use cases seem aligned with the projects’ work, but there are cases 
where  no  alignment  was  indicated.  These  cases  could  be  further  investigated, 
enabling a more generic definition of the business processes. In terms of the level 
of granularity of the GBP analysis, the general assessment was positive, but room 
for  improvement  was  indicated  in the  comments  section,  with  some  indicating 
more  steps,  whilst  other  indicting  fewer.  Finally,  a  list  of  suggestions  for  the 
extension of the GPB set was provided from projects. 

The  Reference  Framework  could  benefit  from  the  modelling  of  new  use  cases, 
stemming from the current work of the projects, whereas the misalignment of the 
current  GBP  can  be  further  investigated  to  increase  the  generality  of  the 
Reference Framework. Furthermore, link with other frameworks indicated by the 
projects can be further investigated. 

The consistency of the Reference Framework with ENTSO-E / EU DSO Entity JWG 
activities (in particular in TF2) should be ensured via a coordination effort. 

Topic 

Generic Actor List 

Findings 

Use-case definition needs to be harmonised to enable cross-project comparison 
and support interoperability. Several items of a use-case definition could be based 
on reference libraries: actors, functions, information exchanged, … 
A Generic Actor List was established in 2012 by CEN/CLC/ETSI, but it now needs to 
be updated with the latest sources, including the IEC Interface Reference Model 
(IEC 61968) and the Harmonised Electricity Market Role Model (HEMRM). 

 bridge 

45 

 
 
 
 
 
REFERENCE FRAMEWORK 

Topic 

Generic Actor List 

Recommendation 

Gather relevant expects from projects to analyse the  current Generic Actor List 
and the new available sources and then update the list. It should be clustered to 
enable experts to contribute where they are the most knowledgeable. At the end, 
the updated list should be submitted to the CEN/CLC/ETSI Coordination Group on 
Smart Grids (CG-SG) for review and approval. 

Topic 

Settlement – Baseline methodologies 

Findings 

Recommendation 

In examining the provision of flexibility services to both TSOs and DSOs developed 
in  the  scope  of  EU-funded  projects,  it  becomes  evident  that  baselining 
methodologies  must  be  adaptable  to  various  flexibility  products  and  grid 
conditions.  Different  flexibility  products  may  require  tailored  approaches  to 
baseline  calculation,  considering  factors  such  as  granularity,  accuracy,  and 
simplicity.  Furthermore,  the  provision  of  flexibility  services  to  TSOs  and  DSOs 
necessitates clear regulatory guidelines, effective coordination mechanisms, and 
standardised baseline methodologies to ensure interoperability and transparency 
across the grid. 

Stakeholders  should  prioritise  developing  standardised  baseline  methodologies 
that  balance  accuracy  and  simplicity.  Regulatory  bodies  should  establish  clear 
guidelines  for  market  access,  compensation  mechanisms  and  operational 
protocols.  Collaboration  among  flexibility  service  providers,  TSOs,  and  DSOs  is 
essential to streamline communication, data exchange, and market participation. 
Continuous review and improvement of baseline methodologies are necessary to 
adapt  to  evolving  grid  conditions  and  stakeholder  feedback,  ensuring  the 
effectiveness and reliability of flexibility services. 

Topic 

Settlement – Protocols for real-time data exchange & granularity requirements 

Findings 

Recommendation 

The analysis of data needs for real-time monitoring and granularity in the context 
of DER aggregation revealed varying requirements across flexibility services and 
grid  operators.  Real-time  data  exchange  is  crucial  for  efficient  operation  of 
flexibility  markets,  but  the  specific  data  needs  differ  depending  on  the  type  of 
service and grid operation scenario. Similarly, granularity requirements vary, with 
some  services  necessitating high-resolution data while  others can operate  with 
lower granularity. 

To  address  these  findings,  stakeholders  should  collaborate  to  establish 
standardised protocols for real-time data exchange and granularity requirements. 
This  includes  defining minimum  standards  for  data  transmission  frequency  and 
resolution based on the specific needs of each flexibility service and grid operation 
scenario.  Additionally,  stakeholders should  invest  in technologies  that  facilitate 
secure and efficient data exchange, such as advanced metering infrastructure and 
data management systems. Moreover, clear guidelines should be developed for 

 bridge 

46 

 
 
 
 
 
Topic 

Settlement – Protocols for real-time data exchange & granularity requirements 

aggregating  DERs,  including  data  reporting  requirements  and  compensation 
mechanisms, to ensure transparency and interoperability in flexibility markets. 

REFERENCE FRAMEWORK 

Topic 

Settlement – Data collection, validation & exchange among stakeholders 

Findings 

Recommendation 

The  assessment  of  data  roles  in  the  settlement  process  highlighted  the  critical 
importance  of  accurate  and  timely  data  for  ensuring  transparent  and  efficient 
settlement  procedures.  Real-time  data  plays  a  crucial  role  in  verifying  the 
performance of flexibility services and determining appropriate compensation for 
service providers. Additionally, the granularity of data required varies depending 
on the type of flexibility service and the level of aggregation involved. 

To  enhance  the  data  roles  in  the  settlement  process,  it  is  recommended  to 
establish  clear  standards  and  protocols  for  data  collection,  validation,  and 
exchange  among  relevant  stakeholders.  This 
includes  setting  minimum 
requirements  for  data  accuracy,  frequency,  and  resolution  to  ensure  reliable 
settlement  calculations.  Moreover,  stakeholders  should  invest  in  advanced 
metering  and monitoring  technologies  to  improve  data  quality  and  granularity, 
enabling  more  precise  settlement  procedures.  Additionally,  collaboration 
between grid operators, service providers, and regulatory authorities is essential 
to address data interoperability issues and establish common data formats and 
interfaces for seamless data exchange. By implementing these recommendations, 
stakeholders  can  streamline  the  settlement  process  and  enhance  the  overall 
efficiency and transparency of flexibility markets. 

Topic 

Settlement – Notification mechanisms 

Findings 

Recommendation 

The analysis revealed several areas where the settlement process lacks adequate 
attention, including the notification of differences between delivered and ordered 
flexibility  volumes,  settling  non-delivered  supply  volumes,  compensating  for 
imbalances,  and  ensuring  validated  measured  data  for  the  quantification  and 
settlement  of  flexibility  services.  These  gaps  can  lead  to  discrepancies  in 
settlement calculations, challenges in accurately compensating service providers, 
and potential inefficiencies in the overall flexibility market operation. 

To  address  these  shortcomings,  it  is  recommended  to  implement  robust 
notification  mechanisms  that  promptly  alert  stakeholders  to  any  discrepancies 
between  ordered  and  delivered  flexibility  volumes.  Additionally,  mechanisms 
should  be  established  to  settle  non-delivered  supply  volumes  fairly  and 
transparently,  taking  into  account  factors  such  as  contractual  obligations  and 
operational constraints. Compensating for imbalances should be done accurately 
and  promptly,  with  clear  guidelines  for  determining  liability  and  appropriate 
compensation  levels.  Furthermore,  efforts  should  be  made  to  ensure  the 
availability  of  validated  measured  data,  including  implementing  data  validation 
processes  and  establishing  standards  for  data  quality  assurance.  By  addressing 
these  recommendations,  the  settlement  process  can  become  more  reliable, 

 bridge 

47 

 
 
 
 
 
Topic 

Settlement – Notification mechanisms 

transparent,  and  efficient,  leading  to  improved  market  performance  and 
stakeholder satisfaction. 

REFERENCE FRAMEWORK 

4.2 Perspective and next steps 

The activities of the Action #3 should be continued in 2024 and beyond.  

Based on the recommendations, several actions have been identified: 

1.  Further  improve  the  Reference  Framework:  align  GBPs  with  project  use  cases,  extend  the  list  of  GBPs, 

improve alignment with other frameworks. 

2.  Reinforce  the  Reference  Framework  to  support  practical  implementation:  use-case  harmonisation  (incl. 

Generic Actor List), list of relevant protocols/standards, … 

3.  Follow up on the application of the settlement guidelines to current and future projects. 
4.  Share this report with relevant  parties  such as ENTSO-E / EU DSO Entity JWG (in particular the team in 

charge of the Demand-Response Implementing Act) and CEN/CLC/ETSO CG-SG. 

A detailed plan will be set out to achieve most of these actions by the BRIDGE General Assembly of 2025. 

 bridge 

48 

 
 
 
 
 
5  Annex 1: Reference Framework 

In this chapter, the Reference Framework is described. As defined in §1.2, it is made of generic business processes, 
functions and interfaces. 

REFERENCE FRAMEWORK 

5.1 Definition of Terms 

5.1.1 Flexibility 

For the sake of clarity in the following discussion, the terms and relations used in the latter context are defined.  

The first term to be defined is the flexibility itself. According to30 flexibility can be defined as follows: 

“On an individual level, flexibility is the modification of generation injection and/or consumption patterns in reaction 
to an external (signal or activation) in order to provide services within the energy system.” 

This  generic  definition  was  further  extended  by  adding  some  details  related  to  the  relations  between  system 
components and the implementation of flexibility, which might in the end limit the generality of the definition. But 
what is more important is that it also defines parameters to describe the flexibility. Such parameters are important 
in order to be able to define the flexibility offer (or request) and its respective value, but also  to verify that the 
flexibility was indeed released. 

Thus, to summarise, we can say that: 

“Flexibility is a service based on measurable and verifiable modification of energy production and/or consumption 
behaviour in reaction to external signal (request or activation).” 

5.1.2 Flexibility Stakeholders 

We can further define a set of generic stakeholders related to providing and consuming flexibility. These can be as 
follows: 

Flexibility Provider – is a party able and willing to adapt or modify its energy-related behaviour in exchange for 
some compensation. This party operates in its own name and doesn't represent anyone else. It can be a private 
and small energy grid stakeholder, but it can also be an industrial and large stakeholder. In general, it is an energy 
prosumer. 

Flexibility Consumer – is a party that needs the flexibility, i.e., it is willing to provide some compensation for the 
flexibility providers in order to achieve (or avoid) a specific condition  on the energy grid.  Examples of flexibility 
consumers are TSOs, DSOs, BRPs and other energy grid stakeholders that may require the change of energy grid 
parameters. 

Flexibility Service Provider (incl. aggregator) – is a party that doesn't usually offer flexibility on its own, but rather 
it represents the individual flexibility providers to help them access the market, in exchange for some fraction of 
the compensations they get for the flexibility. It bundles (aggregates) the flexibility offered by its clients and by that 
may offer more flexibility to larger flexibility consumers. It needs to handle the individual flexibility providers. 

30 Smart Grid Task Force, «Regulatory Recommendations for the Deployment of Flexibility: EU SGTF-EG3 Report,» 2015. 

 bridge 

49 

 
 
 
 
REFERENCE FRAMEWORK 

Flexibility  Facilitator  –  is  a  party  that  represents  one  or  several  flexibility  consumers  to  help  them  access  the 
market. Depending on the local regulation and market model, this party might not be necessary or might part of 
the BRP scope. 

Flexibility  Market  Operator  –  is  a  party  that  connects  the  flexibility  providers  and  flexibility  consumers.  It may 
require  all these parties to have specific features or parameters to be able to participate in the service processes, 
e.g. minimum amount of flexibility that may be provided or only industrial parties. It provides means to announce 
flexibility requests and/or offers allowing the providers/aggregators and consumers to find each other in order to 
use and provide the service.  

Depending on the Generic Business Processes, these stakeholders can be mapped to one party or another, e.g. in 
GBP1 the flexibility consumer is the SO, while in GBP3 it is the BRP. 

5.1.3 Energy Services Stakeholders 

In addition, we define a set of stakeholders related to energy services: 

Energy Service Company – Based on the HEMRM31, a party offering energy-related services to the party connected 
to grid, but not directly active in the energy value chain or the physical infrastructure itself. The  energy service 
company (ESCO) may provide insight services as well as energy management services.  

Energy Supplier – Based on the HEMRM, an energy supplier supplies electricity to or takes electricity from a party 
connected to the grid at an accounting point.   

P2P Market Operator – Responsible for the maintenance and operation of a peer to peer (P2P) energy market, 
including management of participants (peers).  

Electrical Vehicle Charge Point Operator (EV CPO) – Owner/operator/manager of EV charging infrastructure. 

Generic Business Processes 

5.1.4 GBP1 – Flexibility for SOs through Open Market 

The GBP for the case of SOs (i.e. DSO or TSO) utilising flexibility through open market mechanism – mapping mostly 
to  the  case  of  grid  normal  operation  –  is  presented  in  the  following  figure.  The  diagram  depicts  the  different 
subprocesses/functions of each stakeholder in the flexibility lifecycle. In the open market scenario, the process may 
involve all the relevant stakeholders in the flexibility market: 

●  System operator (SO) as a flexibility consumer, aiming to optimise the operation of the grid via the use of 
flexibility. This SO initiates the process of flexibility activation lifecycle (function S1), assesses the flexibility 
offered by the market (function S3) and handles the settlement process (function S). 

●  Balance responsible party (BRP), acting as a flexibility facilitator for flexibility procurement, placing a buying 
offer in the flexibility market (function B2), processing the results (function B3) and handling some part of 
the settlement process (function B4). In some cases, the BRP is skipped and the SO goes directly to  the 
market. 

●  Flexibility market operator (FMO), enabling the flexibility trading by operating a market (function M2). 
●  Flexibility  service  provider  (e.g.  aggregator),  facilitating  the  pooling  of  flexibility  from  various  sources 
(function A1), participating in the market (function A2) and optimally managing its portfolio (function A3) 
to provide the contracted flexibility. It also provides a settlement function for the utilised flexibility source. 

31 ebIX, EFET, ENTSO-E, «Harmonised Electricity Market Role Model,» [En ligne]. Available: https://www.ebix.org/artikel/role_model. 

 bridge 

50 

 
 
 
 
●  Prosumer,  the  flexibility  provider,  who  offers  flexibility  to  the  market  via  the  aggregator  (function  P1), 
activated  taking  care  modelled  preferences  and  constraints  (function  P2)  and  properly  remunerated  or 
penalised (function S). 

REFERENCE FRAMEWORK 

Figure 20 Business process diagram – GBP1 “SO flexibility through open market” 

5.1.5 GBP2 – Flexibility for SO via Prior Bilateral Agreement 

The SO (i.e. DSO or TSO) business process for flexibility via prior bilateral agreement (Figure 21) is quite different 
from the one described above, even though flexibility is offered to the SO in this case as well. The purpose of this 
case is to provide near real-time flexibility activation after an SO request, in particular for the SO to deal with an 
emerging network congestion/load balancing problem. Flexibility is not expected to be delivered through a market; 
therefore, no market operator is involved in order to simplify and speed up the process. Priority must be given due 
to the emergency status. Therefore, if there are other flexibility offers and requests available in a market (e.g., local 
flexibility market), these planned transactions could be temporarily disregarded. 

The roles involved in this process are the SO, the flexibility providers (prosumers) and the flexibility service provider 
(prosumers, aggregator). The SO flexibility via prior bilateral agreement process comprises two distinct phases: 

● 

In the first phase, a bilateral agreement between the SO and the aggregator is made in order to set out 
details such as minimum/maximum amount of flexibility, pricing of the service that aggregator provides to 
the SO, and estimated amount of aggregated flexibility that can be provided. The amount of flexibility that 
can  be  delivered  to  SO  is  determined  dynamically  by  the  flexibility  service  provider,  who  continuously 
estimates aggregated flexibility within a rolling horizon T, based on the flexibility offers that are received 
by the participating prosumers. Flexibility is being updated within T, however, it is usually considered fixed 
for a period of time determined by a fixed timestep (current time + timestep). 

●  The second phase is initiated when the SO effectively requires flexibility, for example, when detecting or 
predicting a critical network problem  and, therefore, requests flexibility from the flexibility service provider 
based  on  the  bilateral  agreement.  The  amount  of  flexibility  that  will  be  provided  to  SO  is  calculated 
dynamically by the flexibility service provider.  

●  During  runtime,  flexibility  providers  provide  the  information  on  the  availability  of  flexibility  (directly  or 
through  an  aggregator,  including  amount  of  flexibility,  duration,  time  span,  etc.  The  set  of  parameters 
should  include  the  amount  of  available  flexibility,  the  time  span  and  the  conditions  under  which  the 
flexibility offer is valid. This is to enable the evaluation of the availability of flexibility at a specific time and 
classify  it  according  to  the  different  needs  of  the  SO  (immediate  actions  in  the  event  of  time-critical 
emergencies and planning to compensate for predicted deviations). 

 bridge 

51 

 
 
 
 
REFERENCE FRAMEWORK 

●  Under normal conditions, the process ends with the generation of asset control schedules at the prosumers’ 

side, flexibility activation and settlement. 

●  The  applied  rules  are  set  by  the  regulator,  however,  the  regulator  does  not  participate  actively  in  the 
process during runtime. However, the regulator is expected to perform control/audit to assure that the 
agreement is in line with the set rules.  

Regarding the settlement process, a separate “Settlement subprocess” is established, which is discussed in further 
detail in section 5.1.9.  The established Settlement subprocess is common for all GBPs. 

Figure 21. Business process diagram for GBP2 “SO flexibility via prior bilateral agreement” 

5.1.6 GBP3 – Flexibility for BRP Portfolio Optimisation 

The main objective of balancing markets is to deal with the power system's temporary imbalances to ensure grid 
stability and security of supply. The flexibility can be used to optimise trading portfolios and reduce balancing costs 
resulting from deviations between scheduled and actual inflow/off-take. The costs for this balancing mechanism 
are charged to BRPs with an imbalance in their portfolio. The BRPs optimise their portfolio so that instantaneous 
deviations  between  predicted  and  actual  production  and  consumption  are  kept  as  low  as  possible  to  avoid 
imbalance costs and prevent the power system going into the emergency mode. The flexibility services are offered 
to energy suppliers/BRPs from the aggregator flexibility asset pools comprising the flexibilities services offered by 
customers or network users to balance the flexibility assets in the grid or energy markets. The responsibility might 
be borne by existing bundled roles in the energy market, like energy suppliers with variable prices, aggregators.  

It is worth emphasising that the BRP sets out its optimisation strategy by undertaking the role of an aggregator and 
using the received flexibility offer. Moreover, the BRP can participate in new or existing balancing power markets 
and  energy  services.  The  difference  between  the  DSO  leveraging  flexibility  through  open  market  and  portfolio 
optimisation  is  that  the  market  settlement  is  undertaken  by  the  BRP.  Market  settlement  is  analysed  further  in 
section 5.1.9, entitled ‘Settlement Subprocess’, and is common across all GBPs, incl. GBP3. 

 bridge 

52 

 
 
 
 
REFERENCE FRAMEWORK 

Figure 22: Business process diagram for GBP3 “BRP portfolio optimisation” 

5.1.7  GBP4 – Flexibility for Energy Community Optimisation 

The main objective of an energy community is to optimise the energy flows within the community. This optimisation 
can  follow  different  strategies,  e.g.  the  goal  may  be  to  maximise  the  collective  self-consumption  (i.e.  make 
consumption equal to production so there is no energy exchange with the grid outside the community). The energy 
community  is  managed  by  a  flexibility  service  provider,  or  aggregator.  Independent  of  the  goal  and  of  the 
participation  to  the  market,  there  are  some  actions  related  to  the  internal  optimisation  within  the  energy 
community as shown in the Figure 23. If the optimisation process is not managed by a central entity, but by some 
distributed approach involving the community members, the flexibility service provider, or aggregator, is virtually 
present. The energy community as a whole can also participate to the above GBPs, either as an active participant 
(the  aggregator/flexibility  service  provider  has  access  to  market)  or  as  a  prosumer  represented  by  another 
(external) aggregator/flexibility service provider. The GBP covers scenarios related to energy communities, virtual 
power plants and similar.  

Figure 23. Business process diagram for GBP4 "Energy community optimisation" 

 bridge 

53 

 
 
 
 
 
 
REFERENCE FRAMEWORK 

5.1.8  GBP5 – Implicit Flexibility Using Dynamic Steering Signals 

The flexibility offering and buying can be performed implicitly. The demand for adapting energy production and 
consumption  can  be  triggered  by  issuing  adequate  signals  (e.g.  price  signal,  CO2/kWh  indicator  or  other  grid 
notifications) that should indicate  if there is too much or too less energy in the grid and the  prosumers should 
adapt. This approach is usually applied with focus on active energy, but extending the trigger can also cause this 
approach to be useful in other areas of flexibility (power factor, etc.). Mainly in this GBP there exists no bidding 
phase,  the flex consumer defines  the  signal  parameters  (e.g. price table  or peak  notice)  with the hope to have 
enough prosumers reacting according to the wish of the buyer. The accounting is done according to the measured 
amount of flexibility provided with respect to potential additional parameters (like power factor). 

This  approach  actually  does  not  need  to  involve  the  market  nor  the  aggregator.  But  variations  are  possible  in 
different implementations. In the basic approach the flexibility consumer takes the risk of being exploited by the 
flexibility providers, i.e., if they are very flexible, they can become speculators, they can consume only cheap energy, 
while producing energy while it is expensive. This scenario is necessary to be supported by regulations. 

This GBP is still under construction. A tentative business process diagram for the “price signal” scenario is provided 
below: 

Figure 24. Tentative business process diagram for GBP5 "Implicit flexibility using dynamic steering signals" (“price 
signal” scenario) 

5.1.9 GBP6 – Energy Monitoring and Energy Management 

A key enabler of the energy transition is the management of energy at individual premises level, through energy 
monitoring and optimisation of an asset’s operation in respect to the end-consumer preferences, local production, 
as well as considering external factors such as energy prices, CO2 equivalent of the energy generation mix, weather 
conditions  and  forecasts,  etc.  Such  solutions  can  be  offered  by  ESCOs,  who  provide  the  infrastructure  and/or 
support the prosumer in achieving an efficient operation of its premises.  

The aim of this GBP is to model the feedback to the prosumer with regards to energy monitoring and management 
based on detailed energy and external data. The  form of the feedback  can range  from actions that need to be 
applied manually by the end user to automatic operation that are transparently applied to home appliances with 
dedicated control signals.  

Furthermore, the ESCO can perform these operations on a prosumer basis or for a group of prosumers in a larger 
context involving aggregation and extended processing.   

 bridge 

54 

 
 
 
 
REFERENCE FRAMEWORK 

Figure 25. Energy Monitoring and Management GBP  

5.1.10 

GBP7 – P2P Trading in Energy Communities 

Extending  the  description  provided  in  GBP  4,  this  GBP  aims  to  describe  the  trading  of  energy  among  peers  / 
members  of  an  energy  community.  This  can  be  enabled  via  a  local  energy  market  (aka  P2P  market),  which  is 
managed  by  an  operator,  responsible  for  its  maintenance,  monitoring  of  transactions  as  well  as  for  the 
management  of  participants.  The  following  diagram  depicts  the  different  sub-processes/  functions  of  each 
stakeholder in the P2P trading lifecycle.  

Figure 26. P2P Trading in energy community GBP  

5.1.11 

Settlement Subprocess 

5.1.11.1 

Generic Process 

The  purpose  of  the  settlement  is  to  prepare  the  billing  process  by  determining  the  delivered  flexibility  and 
computing  the  flexibility  fee  based  on  the  contractual  agreement  between  the  flexibility  service  provider  (e.g. 
aggregator)  and  the  flexibility  consumer  (e.g.  SO  or  BRP).  It  relies  first  on  the  quantification  of  the  flexibility 
provided,  and  then  on  the  comparison/reconciliation  of  the  flex  fee  between  the  flexibility  provider  and  the 
flexibility consumer. 

As this phase is similarly structured for all the flexibility GBPs, it is described in a common subprocess. 

 bridge 

55 

 
 
 
  
 
 
REFERENCE FRAMEWORK 

Figure 27. Business process diagram for the settlement subprocess 

5.1.11.2 

Comparative Analysis with Projects Implementing the Settlement 

This  year,  feedback  was  collected  on  implementing  the  settlement  in  order  to  understand  how  the  different 
projects are approaching it and to see if they are considering a similar sub-process to the one depicted in Figure 27. 

For that purpose, 7 projects (PARITY, ACCEPT, OneNet -Northern Demo Cluster, X-Flex, Platone, BRIGHT and IANOS) 
have shared how they are implementing the Settlement subprocess of the flexibility procurement. Based on their 
feedback, this section provides an in-depth analysis of the approaches followed by different projects implementing 
the Settlement subprocess. It then goes on to briefly explain each project concerning the settlement Subprocess. 

5.1.11.2.1  PARITY 

In  PARITY's  local  energy  market  /  local  flexibility  market,  settlement  is  done  automatically  with  a  software 
component (named Oracle) which runs per prosumer. It communicates with the blockchain platform and checks 
the rules that are set out within the smart contracts (these rules are referred to as Service Level Agreements). It 
calculates the sold flexibility by directly accessing the corresponding measurement data, i.e. power consumption 
and production, per consumer or prosumer involved. According to this description, this project adopts the sequence 
diagram presented in Figure 27. Business process diagram for the settlement subprocess. 

For  the  delivery  of  aggregated  flexibility  to  the  DSO  or  external  markets  (e.g.  ancillary  services  market),  the 
Aggregator  Toolset,  which  is  a  software  component that  assumes  the  role of the  aggregator  within  the PARITY 
framework,  acts  as  the  aggregated  flexibility  provider  and  performs  the  settlement  and  remuneration.  It  then 
distributes the corresponding tokens of the energy/flexibility transaction to each participating prosumer. 

Figure 28 Business process diagram for the Settlement subprocess in the PARITY project 

 bridge 

56 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

5.1.11.2.2  ACCEPT 

Within the ACCEPT project, the flexibility provider's role is assumed by the prosumer/ consumer (in this case, this 
is an energy community member). The main scenarios under which the prosumer/consumer is asked to provide 
flexibility to a third party are:  

i. 
ii. 
iii. 

the P2P trading scenario among members of the same energy community,  
the explicit demand response scenario, and  
the implicit (i.e., price-based) demand response scenario. In all three scenarios, the settlement  process, 
based  on  the  outputs  of  which  the  prosumer/consumer  is  remunerated  for  their  provided  flexibility,  is 
carried out automatically by a software component called P2P Exchange Platform. 

The P2P Exchange Platform performs the remuneration based on consumption measurements gathered from the 
consumer/prosumer (this is the external input depicted in the GBP diagram of Figure 27) and a set of rules agreed 
between the consumer/prosumer and the flexibility service provider (within ACCEPT, this role could be assumed by 
either an ESCO, a retailer or an aggregator, based on the scenario implemented at any given time). The consumption 
measurements, post-flexibility provision, are compared to the previously calculated baseline consumption of the 
user to estimate the delivered flexibility (verification of response estimation) of the prosumer/consumer.  

It should be noted that the set of rules mentioned before, referred to as Service Level Agreements, are included in 
smart  contracts  between  the  flex  service  provider  and  the  flex  provider.  Among  those  rules,  for  the  i)  and  iii) 
scenarios, the remuneration price for the flexibility provision is calculated based on a P2P trading mechanism which 
is executed on a Smart Contract. For the ii) scenario, the price is provided by the flex service provider on a day-
ahead basis (this price is calculated by the flex service provider, here the retailer, with inputs from the DSO and the 
wholesale market, and the demand elasticity calculated by a relevant ACCEPT software component). 

The flexibility service provider has in turn a bilateral agreement with the flexibility consumer (in our case, this is the 
DSO,  whose  functions  are  performed  by  a  software  component  called  ACCEPT  System  Emulator),  where  the 
commercial terms under which flexibility is procured and then settled are described (i.e., the price per kWh that 
the flexibility consumer is willing to pay for procuring flexibility). How the agreement between the two parties was 
achieved  (either  through  a  tender  or  through  the  energy  flex  market)  is  beyond  the  project's    scope.  Once  all 
flexibility  providers  send  their  verification  of  response  (i.e.,  their  provided  flexibility  calculated  based  on  the 
baseline  consumption  and  the  measured  actual  consumption)  to  the  flexibility  service  provider,  the  latter 
aggregates these responses to calculate the actual sold flexibility. The remuneration is then carried out by the DSO 
to  the  community,  which  then  distributes  the  revenue  to  the  participating  members  according  to  the  bilateral 
agreements.  

It should be noted that the set of rules mentioned before, referred to as Service Level Agreements, are included in 
Smart  Contracts  between  the  flex  service  provider  and  the  flex  provider.  Among  those  rules,  for  the  i)  and  iii) 
scenarios, the remuneration price for the flexibility provision is calculated based on a P2P trading mechanism which 
is executed on a Smart Contract. For the second scenario, the price is provided by the flex service provider on a 
day-ahead basis (this price is calculated by the flex service provider, here the retailer, with inputs from the DSO and 
the wholesale market, and the demand elasticity calculated by a relevant ACCEPT software component). 

The flexibility service provider has, in turn, a bilateral agreement with the flexibility consumer (in this case, this is 
the DSO, whose functions are performed by a software component called ACCEPT System Emulator), where the 
commercial terms under which flexibility is procured and then settled are described (i.e., the price per kWh that 
the flexibility consumer is willing to pay for procuring flexibility). How the agreement between the two parties was 
achieved (either  through  a  tender or  through  the  energy  flex  market)  is  the  project's  scope.  Once  all  flexibility 
providers  send  their  verification  of  response  (i.e.,  their  provided  flexibility  calculated  based  on  the  baseline 
consumption and the measured actual consumption) to the flexibility service provider, the latter aggregates these 
responses to calculate the actual sold flexibility. The remuneration is then carried out by the DSO to the community, 
which then distributes the revenues to the participating members according to the bilateral agreements. Therefore, 
the business process diagram adopted in the ACCEPT projects is adapted from Figure 27 and depicted in Figure 29. 

 bridge 

57 

 
 
 
REFERENCE FRAMEWORK 

Figure 29 Business process diagram for the Settlement subprocess in the ACCEPT project 

5.1.11.2.3  X-FLEX 

In the XFLEX project, no BRP role and thus the market clearing is performed at the MO level. The overall settlement 
process is centralised as the MO is responsible for the market clearing and thus the settlement of the amount of 
the flex offered by flex providers (aggregators) to the flex consumers (SOs). Therefore (SC1= SP2) and (SC2=SP3) 
performed towards the valuation of the flexibility offered by the flex service provider to the system operator and 
then the remuneration for the provided flexibility (based on the financial terms defined in the offer). 

The remuneration is performed based on flexibility availability and use. Different scenarios are examined in XFLEX 
project taking into account the settlement parameters for both availability and use. The flex settlement approach 
applies  also  at  the  level  of  flexibility  provider  (consumer/flexibility  asset  owner)  and  flexibility  service  provider 
(aggregator). In that case, the aggregator is responsible for the settlement of flexibility offered. The approach is 
similar to what was presented in GBP definition. More specifically: 

•  SC1: Flex service provider is responsible for the calculation of the flex offered (vs flex potential) from the 

different flex providers; 

•  SC2=SP3: Flex service provider get from the MO the information about flex offered to SO and validate the 
amount of flex provided. Then the settlement disaggregation to flex providers is performed on the basis of 
the contractual terms agreed between flex service provided and flex providers; 

•  SP4/SC3: is performed by default by both entities (flex service provider AND flex provider) to perform the 

flexibility settlement validation; 

Taking  into  account  the  explanation  described  above  for  the  X-Flex  project,  the  sequence  diagram  for  the 
Settlement subprocess in the X-Flex project is represented below.  

Figure 30 Business process diagram for the Settlement subprocess in the X-Flex project 

5.1.11.2.4  Platone 

The  settlement  process  in  the  Italian  use  case  of  the  Platone  Project  is  implemented  by  the  Platone  Market 
Platform, which is also in charge of collecting the flexibility requests and offers, matching them and providing the 
market  results  for  the  flexibility  activation.  The  settlement  process  is  divided  into  two  phases:  validation  and 
remuneration.  In  order  to  validate  the  flexibility  provided  by  the  resources,  the  market  platform  acquires  the 
certified measurements (using blockchain) from the shared customer database at the end of the activation phase. 

 bridge 

58 

 
 
 
 
 
REFERENCE FRAMEWORK 

The Platone Market Platform is able to calculate the settlement for each resource and to enable the remuneration 
process through the smart contract and Platone tokens, using blockchain technology. More in detail, the Platone 
Market Platform implements two different smart contracts for the settlement remuneration: 

•  Settlement  agreement,  a  dynamic  smart  contract  able  to  manage  multiple  agreements  between  the 

aggregator and its own customers. This smart contract is used for the settlement management. 

•  Platone token, an ERC-20 based token is used for the payment of the flexibility provisioning to the end 
customers. Each customer has its own wallet linked to its own point of delivery (PoD) and Platone tokens 
are provided to the customer wallet at the end of the settlement phase. 

Below is a step-by-step sequence diagram for the settlement process: 

1)  Market platform receives measurements for market data verification and settlement.  
2)  Market platform verifies on the blockchain services layer the agreement between aggregator and customer 
3)  Market platform performs settlement based on measurement, market outcomes and agreements. 
4)  Market platform assigns the Platone tokens to the respective customers.  
5)  Market platform shares the settlement data to all the market participants (with specific access permission)  
6)  Aggregator, TSO, and DSO can visualise all the data via web user interface (UI). 

5.1.11.2.5  OneNet (Northern Cluster) 

In turn, for the Northern Cluster of the OneNet project, the settlement process is conducted in a component called 
the flexibility register (FR). The Northern Demonstrator implemented a software system for the needs of the demo. 
The FR receives information about the trades made on the market (for congestion management) and does first the 
verification process. In this process the metering data is compared to either schedules (plans) sent by the flexibility 
service provider, or alternatively the FR calculates a baseline from based on historical data. These results are then 
communicated to relevant parties.  

The  verification  process  quantifies  the  delivered  flexibility  and  the  settlement  process  uses  this  information  to 
conclude financial and imbalance settlement done partly outside of the FR. The sequence diagram for the use case 
can be found in Figure 2.7. The objective of this use case is to quantify the delivered flexibility volumes and support 
the  financial  and  imbalance  settlement  based  on  the  results  in  the  context  of  OneNet  Northern  Demonstrator 
scope. This is one of the FR’s core functionalities. 

This process also includes the calculation of a baseline, which is conducted by the FR based on historical metering 
data.  The  Northern  Demonstrator  concept  presented  two  alternatives  for  establishing  the  reference  value  for 
metering data of resources, against which the behaviour of the resources is evaluated in the verification process. 
These two are the baseline calculated by the FR and schedules sent by the FSP operating the respective resources. 
In  this  demo  cluster,  an  optimisation  model  for  SOs  is  also  implemented  to  procure  flexibility  together  for 
congestion management. It is reported that in this case doing the financial settlement is not trivial. 

5.1.11.2.6  BRIGHT 

In the BRIGHT project, demand response (DR) programs are implemented at the community level using peer-to-
peer flexibility trading to determine the DR signals.  

The implementation is done on top of the blockchain energy ledger that stores, in a tamper-proof manner, the 
energy (and non-energy) information collected by smart devices. The DR signals are injected into the blockchain 
self-enforcing  smart  contracts  managing  the  community's  flexible  entities.  The  smart  contracts  enable  to 
programmatically  define  the  expected  energy  flexibility  to  be  delivered  by  each  local  prosumer  as  well  as  the 
associated remuneration. The commitments for energy flexibility delivery are saved in blockchain as transactions 
for each flexible entity participant. They will be processed and compared to the real-time monitored values during 
delivery time. 

The DR programs settlement is based on the monitored data to activate the appropriate financial remuneration for 
the community flexibility providers. During flexibility delivery, energy transactions are generated and stored in the 

 bridge 

59 

 
 
 
REFERENCE FRAMEWORK 

blockchain based on the  energy  data monitoring gathered from the  smart meters associated with each flexible 
entity. The new data triggers the execution of smart contracts that are associated with the flexibility entities. The 
smart contracts check and compare the monitoring data with the corresponding commitments, and based on these 
values, the actual settlement is generated. 

The payments represent the transfer of tokens associated with energy flexibility delivery. 

5.1.11.2.7  IANOS 

In the IANOS project the application of a P2P market platform enables prosumers in a local network to directly 
trade energy with each other, by avoiding RES curtailment and future grid transport costs. 

The settlement process is implemented using smart contracts by considering both the energy and financial aspects 
of trading management and the energy data acquired by smart meters. 

During  delivery  based  on  the  energy,  monitoring  data  gathered  from  the  smart  meters  associated  with  each 
prosumer energy transactions is generated and stored in the blockchain. The new data triggers the execution of 
the smart contracts associated with the prosumers. The smart contract checks and compares the monitoring with 
the corresponding commitments and the actual settlement is made based on these values. Fungible tokens based 
on ERC-20 standard are exploited as a payment for the purchase of energy between prosumers. 

Functions and Interfaces 

This section describes the functions and interfaces used in the generic business processes. To easily compare with 
the previous version of the Reference Framework32, all the changes and additions are marked in red. 

5.1.12 

Functions 

5.1.12.1 

Summary of relevant functions per Generic Business Process 

Function 

GBP1  GBP2  GBP3  GBP4  GBP5  GBP6  GBP7 

S1 / Flexibility Request 

S2 / Results validation 

S3 / Process Market Results 

S4 / Process Settlement 

S5 / Request for bilateral agreement 

S6 / Flexibility request 

S7 / Process Flex response 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

32 BRIDGE, «Interoperability of flexibility assets - Version 2.0,» 2022. [En ligne]. Available: https://op.europa.eu/en/publication-detail/-/publication/a00be176-
ac1f-11ed-b508-01aa75ed71a1/language-en. 

 bridge 

60 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Function 

GBP1  GBP2  GBP3  GBP4  GBP5  GBP6  GBP7 

REFERENCE FRAMEWORK 

B1 / Flexibility request 

B2 / Placement of Buying Offer 

B3 / Process Results 

B4 / Process Settlement 

M1 / Market Results Clearing (BRP) 

(✓) 

(✓) 

✓ 

✓ 

✓ 

✓ 

M2 / Market Results Clearing (SO) 

✓ 

A1 / Flexibility Offer Aggregation 

(✓) 

(✓) 

(✓) 

A2 / Placement Selling Offer 

A3 / Offer Disaggregation 

A4 / Settlement Disaggregation 

A5 / Offer for bilateral agreement 

A6 / Process request and assess response 

A7 / Request disaggregation 

✓ 

(✓) 

✓ 

(✓) 

✓ 

✓ 

✓ 

(✓) 

A8 / Process market results 

✓ 

✓ 

A9 / Aggregation 

A10 / Optimisation & Flexibility request 

✓ 

✓ 

P1 / Flexibility offer 

P2 / Process schedule 

P3 / Process Settlement 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

P4 / Flexibility forecast (feasibility) 

P5 / Flexibility offer (energy community) 

✓ 

✓ 

 bridge 

61 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Function 

GBP1  GBP2  GBP3  GBP4  GBP5  GBP6  GBP7 

REFERENCE FRAMEWORK 

P6 / Flexibility optimisation 

P7 / Energy usage capturing 

P8 / Applying the feedback 

P9 / Energy Forecast 

P10 / Bid Calculation 

P11 / Process Trading Result 

I1 / Computation of Price Signal 

E1 / Data Aggregation & Processing 

E2 / Optimisation & Control signal / feedback 
generation 

P2PM1 / Bid Matching among peers 

B / Billing 

SS / Settlement subprocess: 

•  SP1 / Quantify delivered flexibility 
•  SP2 / Calculate sold flexibility 
•  SP3 / Validate flex fee with own calculation 
•  SP4 / Settle flex 
•  SC1 / Calculate procured flexibility 
•  SC2 / Calculate flex fee based on contract 
•  SC3 / Settle flex 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

5.1.12.2 

S functions 

Description 

Inputs 

S1 / Flexibility Request 

The Flexibility Consumer sends a flexibility request to the market or to 
the Flexibility Facilitator, specifying volume, date(s), location, expiration 
date (and price in the case of market bid). 

 bridge 

62 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
REFERENCE FRAMEWORK 

S1 / Flexibility Request 

Outputs 

Flexibility request 

External required data 

Flexibility pool, Grid Operational Status, Flexibility availability 

Decomposition into 
functions/subfunctions 

S2 / Results validation 

Description 

The  foreseen result  of  the market  cycle is provided  by  the  Flexibility 
Market Operator to the SO, so the SO can validate that the proposed plan 
is acceptable from the grid perspective. 

Inputs 

Flexibility offers and offer results (what, when, where, how much, …)  

Outputs 

Acceptance or refusal of the proposed plan  

External required data 

Grid operational status 

Decomposition into 
functions/subfunctions 

S3 / Process Market Results 

Description 

The  SO  receives  information  on  activated  flexibility.  It  processes  the 
result and in case of inadequate volumes, corrective actions are taken 
(e.g.  new  request).  It  also  informs  about  the  corresponding  flexibility 
transaction/agreement to enable the settlement. 

Inputs 

Flexibility order 

Outputs 

Corrective actions 

Flexibility transaction/agreement 

External required data 

Decomposition into 
functions/subfunctions 

 bridge 

63 

 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

S4 / Process Settlement 

Deprecated 

S5 / Request for bilateral agreement 

Description 

The  Flexibility  Consumer  makes  a  request  to  the  Flexibility  Service 
Provider to make bilateral agreement regarding the flexibility that can be 
provided 

Inputs 

Special flag to indicate an emergency operation scenario 

Desirable amount of flexibility 

Outputs 

Start iterative negotiation process with the Flexibility Service Provider 

External required data 

Decomposition into 
functions/subfunctions 

Description 

Inputs 

S6 / Flexibility request 

Flexibility Consumer makes a flexibility request to the Flexibility Service 
Provider to deal with a predicted grid issue (e.g. emergency situation) 

Outputs 

Time period 

Amount of energy 

Location information 

External required data 

Grid network area status (emergency state) 

Decomposition into 
functions/subfunctions 

 bridge 

64 

 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

S7 / Process Flex response 

Description 

Flexibility Consumer  processes  the  flexibility response  received.  It also 
informs  about  the  corresponding  flexibility  transaction/agreement  to 
enable the settlement. 

Inputs 

Flexibility response 

Outputs 

Selected flexibility response 

Flexibility transaction/agreement 

External required data 

Decomposition into 
functions/subfunctions 

5.1.12.3 

B functions 

Description 

Inputs 

B1 / Flexibility request 

The  Flexibility  Consumer  prepares  a  flexibility  request,  specifying 
volume, date(s), location, expiration date (and price in the case of market 
bid). 

Outputs 

Flexibility request 

External required data 

Production/Consumption forecast, Portfolio status, Flexibility availability 

Decomposition into 
functions/subfunctions 

B2 / Placement of Buying Offer 

Description 

Flexibility  Facilitator  places  a  flexibility  bid  in  the  market,  specifying 
volume, date(s), location, expiration date and price. 

Inputs 

Flexibility request by Flexibility Consumer 

Outputs 

Flexibility request to the market 

 bridge 

65 

 
 
 
 
 
 
 
 
B2 / Placement of Buying Offer 

REFERENCE FRAMEWORK 

External required data 

Decomposition into 
functions/subfunctions 

B3 / Process Results 

Description 

Flexibility  Facilitator  receives  information  on  activated  flexibility.  It 
forwards  relevant  information  to  Flexibility  Consumer.   It  also  informs 
about the corresponding flexibility transaction/agreement to enable the 
settlement. 

Inputs 

Flexibility order (s) from market 

Outputs 

Flexibility order(s) to Flexibility Consumer 

Flexibility transaction/agreement 

External required data 

Decomposition into 
functions/subfunctions 

Deprecated 

5.1.12.4  M functions 

B4 / Process Settlement 

M1 / Market Results Clearing (BRP) 

Description 

Matching of the buying requests and the selling offers from the Flexibility 
Service Provider 

Inputs 

Flexibility request from Flexibility Consumer 

Selling offer(s) from Flexibility Service Provider 

Validated Results 

 bridge 

66 

 
 
 
 
 
 
 
 
 
M1 / Market Results Clearing (BRP) 

REFERENCE FRAMEWORK 

Outputs 

Market Results clearing 

External required data 

Flexibility pool 

Decomposition into 
functions/subfunctions 

M2 / Market Results Clearing (SO) 

Description 

Matching of the request (buy) and offers (sell) of flexibility. 

Inputs 

Flexibility request from Flexibility Consumer  

Selling offer(s) from Flexibility Service Provider 

Outputs 

Flexibility order(s) 

External required data 

Flexibility pool 

Decomposition into 
functions/subfunctions 

5.1.12.5 

A functions 

A1 / Flexibility Offer Aggregation 

Description 

Inputs 

Flexibility  Service  Provider  collects  flexibility  offers  of  all  Flexibility 
Providers and calculates the available flexibility for its portfolio. 

Flexibility  offer  of  Flexibility  Providers  (incl.  consumers,  prosumers, 
electric vehicle charging point operators, etc.)  

Outputs 

Aggregated flexibility 

External required data 

Decomposition into 
functions/subfunctions 

 bridge 

67 

 
 
 
 
 
 
 
 
 
A2 / Placement Selling Offer 

REFERENCE FRAMEWORK 

Description 

Flexibility Service Provider places a bid of flexibility in the market. The 
bid  has  an  expiration  date  and  the  location  of  the  grid.  Location  can 
relate  to  physical  infrastructure  (e.g.  substation,  feeder)  or  logical 
segment (area of the grid). 

Inputs 

Aggregated flexibility 

Outputs 

Flexibility offer (market level) 

External required data 

Decomposition into 
functions/subfunctions 

A3 / Flexibility Offer Disaggregation 

Description 

Flexibility Service Provider receives flexibility schedule from the market. 
It activates flexibility of Flexibility Providers following internal process of 
optimisation. 

Inputs 

Flexibility order from market or optimisation process 

Outputs 

Flexibility order(s) of Flexibility Provider(s) 

External required data 

Decomposition into 
functions/subfunctions 

Deprecated 

A4 / Settlement Disaggregation 

A5 / Offer for Bilateral Agreement 

Description 

The Flexibility Service Provider provides an offer for bilateral agreement 
with the Flexibility Consumer 

 bridge 

68 

 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

A5 / Offer for Bilateral Agreement 

Aggregated flexibility (calculated from previous step ) 

Min/Max  amount  of  flexibility  that  can  be  used  after  a  Flexibility 
Consumer flexibility request 

Price  per  flexibility  unit  to  be  paid  for  providing  the  service  to  the 
Flexibility Service Provider 

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

A6 / Process request and assess response 

Description 

Flexibility Service Provider receives the flexibility request and checks if it 
is  valid  according  to  the  bilateral  agreement.  If  yes,  highest  priority  is 
given to respond to the flexibility request. 

Inputs 

Flexibility request information (time period, amount of energy, location) 

Outputs 

Flexibility schedule returned as response 

External required data 

Decomposition into 
functions/subfunctions 

A7 / Request disaggregation 

Description 

Flexibility  Service  Provider  performs  disaggregation  of  the  selected 
flexibility response to the appropriate Flexibility Providers, by applying 
optimisation methods 

Inputs 

Flexibility that can be provided to Flexibility Consumer after its request 

Outputs 

Flexibility schedule(s) of prosumer(s) 

External required data 

 bridge 

69 

 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

A7 / Request disaggregation 

Decomposition into 
functions/subfunctions 

A8 / Process market results 

Description 

Flexibility Service Provider receives information on activated flexibility. It 
forwards  relevant  information  to  disaggregation  or  directly  to  the 
Flexibility Provider.  

Inputs 

Flexibility order(s) from market 

Outputs 

Flexibility order(s) to disaggregation or Flexibility Provider 

External required data 

Decomposition into 
functions/subfunctions 

A9 / Aggregation 

Description 

The  Flexibility  Service  Provider  aggregates  all  available  flexibility 
forecasts received from the flexibility providers within their portfolio.  

Inputs 

Outputs 

This  function  is  very  similar  to  A1.  It  is  to  be  investigated  if  there  are 
major differences stemming from the different GBPs or if these two can 
be merged. 

Flexibility forecast per flexibility provider (prosumer) 

Aggregated flexibility forecast (I.e., community/portfolio-level flexibility 
forecast,  where  portfolio  here  comprises  all  available  and  eligible 
flexibility providers). 

External required data 

None 

Decomposition into 
functions/subfunctions 

 bridge 

70 

 
 
 
 
 
 
 
 
 
 
Description 

REFERENCE FRAMEWORK 

A10 / Optimisation & Flexibility request 

The Flexibility Service Provider receives (on a dynamic or static way) an 
optimisation request/task (depending on the optimisation scenario/use 
case) and performs an iterative optimisation process. Based on the initial 
flexibility  offers  by  the  Flexibility  Providers,  the  Flexibility  Service 
Provider may send an individual flexibility request to eligible Flexibility 
Providers and receive a reassessed flexibility offer from them. Based on 
the available offers, the optimisation engine calculates and produces the 
flexibility profile at the cumulated level.  

Inputs 

Aggregated flexibility forecast 

Flexibility offer per flexibility provider (prosumer) 

Outputs 

Flexibility request to each prosumer 

Aggregated flexibility profile (flexibility profile at community or portfolio 
level  based  on  the  aggregation  of  available  flexibility  offers  per 
prosumer) 

External required data 

Optimisation constraints and goals (the optimisation scenario driving the 
optimisation  and  calculation  of  the  required  flexibility,  translated  into 
optimisation constraints) 

Decomposition into 
functions/subfunctions 

5.1.12.6 

P functions 

P1 / Flexibility offer 

Description 

Flexibility  Provider’s  flexibility  is  provided  to  the  Flexibility  Service 
Provider. Flexibility Provider is aware and agrees that provided flexibility 
can be procured via market transactions or based on bilateral agreement 
between  the  Flexibility  Consumer  and  the  Flexibility  Service  Provider 
(incentives for prosumer involvement can be provided in the latter case). 

Inputs 

Flexibility calculation from individual assets: P2H, EV charging, etc. 

Flexibility time period  

Outputs 

Flexibility offer 

External required data 

Any  data  required  for  calculating  flexibility  that  can  be  offered 
dynamically based on current and forecasted parameters’ values:  usage 

 bridge 

71 

 
 
 
 
 
REFERENCE FRAMEWORK 

P1 / Flexibility offer 

patterns,  types  of  devices,  set-points  preferences,  weather  data 
(including forecasts), calendar, state of charge (SoC), etc. 

Decomposition into 
functions/subfunctions 

1 
2 

Calculation of flexibility per controllable, flexible asset  
Aggregated flexibility at the level of the flexibility provider   

The  calculation  of  the  flexibility  per  controllable,  flexible  asset  may 
require an extra step for the creation of certain profiles (e.g., EV charging 
profile, occupancy profile, thermal comfort profiling, etc.). 

Description 

Inputs 

Outputs 

P2 / Process schedule 

Flexibility  Provider  receives  flexibility  schedule  from  the  Flexibility 
Service Provider. Assets are activated following the received schedule. It 
also informs about the corresponding flexibility transaction/agreement 
to enable the settlement. 

Disaggregated  Flexibility  order/request/offer  (from  Flexibility  Service 
Provider to Flexibility Provider) 

Control  actions  (to  controllable  assets)  based  on  flexibility  request 
Verification of response to flexibility request  

Flexibility transaction/agreement 

External required data 

•  Control of assets – specific setpoints   
•  Response from controllable assets   

Decomposition into 
functions/subfunctions 

1 
2 

Create process schedule per asset  
‘Translation’  of  process  schedule  to  specific  control  actions/asset 
setpoints  

P3 / Process Settlement 

Deprecated 

 bridge 

72 

 
 
 
 
 
 
 
 
P4 / Flexibility forecast (feasibility) 

REFERENCE FRAMEWORK 

Description 

The Flexibility Provider (prosumer) generates flexibility forecasts based 
on  data  from  available  IoT  infrastructure  (meters,  sensors,  etc.)  and 
available EV infrastructure. 

This  Function  is  very  similar  to  P1.  It  is  to  be  investigated  if  there  are 
major differences stemming from the different GBPs or if these two can 
be merged. 

Inputs 

Metering  and  sensoring  IoT  data  /  Request  for  provision  of  flexibility 
forecast  /  profiling  data  (e.g.,  occupancy  profiling,  thermal  comfort 
profiling,  thermal  building  profile,  etc.)  /  data  from  EV  infrastructure 
(e.g., SoC, EV charging pattern, etc.)  

Outputs 

Prosumer-level flexibility forecast 

External required data  Metering and sensor IoT data, weather data (including forecasts), data 

from EV infrastructure  

Decomposition into 
functions/subfunctions 

1 
2 

Calculation of available flexibility per asset   
Aggregation  of  asset-level  flexibility  forecasts  into  provider-level 
flexibility forecast   

Description 

Inputs 

Outputs 

P5 / Flexibility offer (energy community) 

The  Flexibility  Provider  receives  a  flexibility  request  by  the  Flexibility 
Service Provider,  assesses  it  and  returns  their  flexibility  offer  (I.e.,  the 
flexibility profile that they can offer in response to the request made by 
the Service Provider) 

Flexibility request by the Flexibility Service Provider 

Flexibility offer per  flexibility provider (incl. prosumers, consumers, EV 
charging points operators, etc.)  

External required data 

None 

Decomposition into 
functions/subfunctions 

 bridge 

73 

 
 
 
 
 
 
REFERENCE FRAMEWORK 

P6 / Flexibility optimisation 

Description 

The  Flexibility  Provider  receives  the  implicit  steering  signal  (dynamic 
energy price, CO2/kWh indicator, etc.) and decides on the activation of 
available assets 

Inputs 

The implicit steering signal 

Outputs 

Schedule for activating the available assets 

External required data 

Decomposition into 
functions/subfunctions 

Description 

Inputs 

P7 / Energy usage capturing 

This  function  is  realised  at  the  prosumer  household  and  covers  the 
collection of energy usage data and any data related to energy usage. 
This  can  cover  the  summarized  usage,  but  also  the  energy  usage  of 
individual appliances as well as other data collected by relevant sensors. 
There might also be a diversity in the temporal resolution of the data.  

•  Smart Meter data  
•  Appliance status (on/off, mode of operation)  
•  Appliance Schedule  
•  Temperature/Humidity/Occupancy/Luminance Sensor data  

Outputs 

Energy usage and related data (diverse temporal and spatial resolutions 
possible)  

External required data 

External data that can influence the energy monitoring (weather, time, 
etc.)  

Decomposition into 
functions/subfunctions 

P8 / Applying the Feedback 

Description 

The prosumer receives the feedback that covers the suggestions on how 
to improve the energy usage and can apply these to improve efficiency 

 bridge 

74 

 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P8 / Applying the Feedback 

in the household. This feedback can be applied manually by the end user 
or in automated manner.  

Inputs 

•  Energy related feedback  
•  Appliance operation schedule  

Outputs 

Steering signals to control the appliances  

External required data 

Decomposition into 
functions/subfunctions 

Description 

Inputs 

Outputs 

P9 / Energy Forecasting   

Execution of energy forecasting algorithms at the level of the prosumer 
in order to identify the energy to be exported or imported from other 
peer of the energy community or from the contracted retailer.  

Energy Data (data on energy demand and generation – if available)  

Forecasts  

External required data  Weather Historic and Forecast Data  

Decomposition into 
functions/subfunctions 

Description 

Inputs 

Outputs 

External required data 

P10 / Bid Calculation   

Based on the energy forecasts and the prosumer’s preference the energy 
to be exported or imported from other peer of the energy community or 
from the contracted retailer is identified.  

Forecast Data, Prosumer Preferences  

Bid  

 bridge 

75 

 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P10 / Bid Calculation   

Decomposition into 
functions/subfunctions 

P11 / Process Trading Result 

Description 

The outcome of the trading mechanism is communicated in this step.   

Traded Quantity/Price  

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

5.1.12.7 

I functions 

I1 / Computation of Price Signal 

Description 

The explicit flexibility request is translated into an implicit steering signal 
to be distributed among the interested Flexibility Providers 

Inputs 

Outputs 

Explicit Flex Request 

Implicit steering signal (energy price) 

External required data 

Decomposition into 
functions/subfunctions 

5.1.12.8 

E functions 

E1 / Data Aggregation & Processing 

Description 

If  needed  to  consider  the  prosumer  (or  many  prosumers)  in  a  larger 
context  their  energy  usage  data  can  be  aggregated  and  all  the  data 

 bridge 

76 

 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

E1 / Data Aggregation & Processing 

related to their energy usage (sensor data, IoT data) can be processed 
for the main optimisation.  

Energy usage and related data from the prosumers  

Aggregated and pre-processed data   

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

E2 / Optimisation & Control signal / feedback generation 

Description 

Inputs 

Outputs 

The energy usage and related data are here processed, and optimisation 
processes are executed. This might involve also training of Digital Twins. 
The  output  of  these  is  a  summary  that  covers  the  improvement 
suggestions (feedback) or directly applicable steering signals that can be 
executed on the appliances within the households.  

The pre-processed or aggregated energy usage and related data from the 
monitored prosumers.  

The feedback (suggestion on the energy usage change) or direct steering 
signals to be applied on the appliances  

External required data 

The  optimisation  process  may  use  external  data  on energy  price,  CO2 
generation, weather, etc., as additional drivers.  

Decomposition into 
functions/subfunctions 

5.1.12.9 

P2PM functions 

P2PM1 / Bid Matching among peers 

Description 

Based on the energy forecasts and the prosumer’s preference the energy 
to be exported or imported from other peer of the energy community or 
from the contracted retailer is identified.  

 bridge 

77 

 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P2PM1 / Bid Matching among peers 

Inputs 

Outputs 

Bids  

Traded Quantities/Prices  

External required data 

Decomposition into 
functions/subfunctions 

5.1.12.10  Billing function 

B / Billing 

Description 

In this process the service provider gets the payment for the service, the 
results are evaluated, and their value is defined. 

Energy Usage data 

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

5.1.12.11 

Settlement functions 

SP1 / Quantify delivered flexibility 

Description 

The  Flexibility  Provider  and/or  the  Flexibility  Service  Provider  quantify 
the flexibility that has been indeed provided/delivered by the Flexibility 
Provider, based on appropriate measurements and monitoring. 

Inputs 

Flexibility transaction/agreement 

Outputs 

Delivered flexibility (how much, when, …) 

External required data  Metering data 

 bridge 

78 

 
 
 
 
 
 
 
 
 
 
SP1 / Quantify delivered flexibility 

REFERENCE FRAMEWORK 

Decomposition into 
functions/subfunctions 

SP2 / Calculate sold flexibility 

Description 

The  Flexibility  Service  Provider  maps  the  delivered  flexibility  with  the 
flexibility contract(s) to characterise the sold flexibility. 

Inputs 

Delivered flexibility (how much, when, …) 

Outputs 

Sold flexibility (contract reference, quantity, time period, …) 

External required data 

Decomposition into 
functions/subfunctions 

SP3 / Validate flex fee with own calculation 

Description 

The  Flexibility Service  Provider  validates the  compensation fee  for the 
sold  flexibility  by  comparing  the  flex  fee  claimed  by  the  Flexibility 
Consumer and the flex fee computed by itself based on the contract and 
sold flexibility. 

Inputs 

Sold flexibility 

Compensation fee for the procured flexibility (from Flexibility Consumer) 

Outputs 

Compensation fee for the sold flexibility 

External required data 

Decomposition into 
functions/subfunctions 

 bridge 

79 

 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

SP4 / Settle flex 

The  flexibility transactions  are validated  and  the  payment  information 
for  settlement  is  agreed  between  the  Flexibility  Consumer  and  the 
Flexibility Service Provider. 

Compensation fee for the sold flexibility 

Description 

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

SC1 / Calculate procured flexibility 

Description 

The  Flexibility  Consumer  calculates  the  amount  (and  time  period)  of 
procured flexibility, based on the existing contracts and past Flexibility 
requests 

Inputs 

Flexibility transaction/agreement 

Price signals (for GBP5) 

Outputs 

Procured flexibility 

External required data 

Decomposition into 
functions/subfunctions 

SC2 / Calculate flex fee based on contract 

Description 

The  Flexibility  Consumer  computes  the  compensation  fee  for  the  sold 
flexibility based on the contract and procured flexibility 

Inputs 

Procured flexibility 

Outputs 

Compensation fee for the procured flexibility 

 bridge 

80 

 
 
 
 
 
 
 
 
 
 
SC2 / Calculate flex fee based on contract 

REFERENCE FRAMEWORK 

SC3 / Settle flex 

The  flexibility transactions  are validated  and  the  payment  information 
for  settlement  is  agreed  between  the  Flexibility  Consumer  and  the 
Flexibility Service Provider. 

Compensation fee for the sold flexibility 

External required data 

Decomposition into 
functions/subfunctions 

Description 

Inputs 

Outputs 

External required data 

Decomposition into 
functions/subfunctions 

5.1.13 

Arrows (information flows) 

5.1.13.1 

Summary of Relevant Interfaces per Generic Business Process 

GBP 

GBP 

Interface 

1 

2 

3 

4 

5 

6 

7 

Interface 

1 

2 

3 

4 

5 

6 

7 

P1 → A1 

(✓) 

(✓) 

(✓) 

A1 → A2 

(✓) 

P1 → A2 

✓ 

(✓) 

✓ 

A1 → A5 

P1 → A5 

(✓) 

✓ 

A2 → M2 

✓ 

M1 → B3 

M1 → A8 

B3 → B4 

B4 → A4 

P4 → A9 

A9 → A10 

✓ 

✓ 

✓ 

✓ 

 bridge 

81 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
S1 → B2 

(✓) 

B2 → M2 

(✓) 

S1 → M2 

✓ 

M2 → B3 

(✓) 

B3 → S3 

(✓) 

M2 → S3 

✓ 

S3 → B4 

B4 → A4 

S3 → S4 

S4 → A4 

M2 → A8 

✓ 

A8 → A3 

(✓) 

(✓) 

A3 → P2 

(✓) 

(✓)  ✓ 

A8 → P2 

✓ 

✓ 

P2 → P3 

A4 → P3 

A5 ↔ S5 

S6 → A6 

A6 → S7 

A6 → A7 

A7 → P2 

A6 → P2 

S7 → S4 

✓ 

✓ 

✓ 

(✓) 

(✓) 

✓ 

REFERENCE FRAMEWORK 

A10 ↔ P5 

A10 → A3 

S1 → I1 

I1 → P6 

P6 → P2 

✓ 

✓ 

✓ 

✓ 

✓ 

S3 → SS 

✓ 

P2 → SS 

✓  ✓  ✓  ✓  ✓ 

S7 → SS 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

B3 → SS 

A3 → SS 

I1 → SS 

P2PM1 → 
SS 

S1 ↔ Ext 

✓ 

S2 ↔ Ext 

S6 ↔ Ext 

✓ 

M1 ↔ Ext 

M2 ↔ Ext  ✓ 

A4 ↔ Ext 

P1 ↔ Ext 

✓  ✓  ✓ 

P2 ↔ Ext 

✓  ✓  ✓ 

P4 ↔ Ext 

P7 ↔ Ext 

✓ 

✓ 

 bridge 

82 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A2 → M1 

B1 → B2 

B2 → M1 

M1 ↔ S2 

P7 → E1 

E1 → E2 

E2 → P8 

P8 → B 

P9 → P10 

P10 → 
P2M1 

P2PM1 → 
P11 

✓ 

✓ 

✓ 

✓ 

  ✓ 

  ✓ 

  ✓ 

  ✓ 

  ✓ 

  ✓ 

  ✓ 

REFERENCE FRAMEWORK 

P9 ↔ Ext 

P10 ↔ 
Ext 

P11 ↔ 
Ext 

A10 ↔ 
Ext 

✓ 

SP1 → SP2  ✓  ✓  ✓  ✓  ✓ 

SP2 → SP3  ✓  ✓  ✓  ✓  ✓ 

SC1 → SC2  ✓  ✓  ✓  ✓  ✓ 

SC2 → SP3  ✓  ✓  ✓  ✓  ✓ 

SP3 → SP4  ✓  ✓  ✓  ✓  ✓ 

SP4 ↔ 
SC3 

✓  ✓  ✓  ✓  ✓ 

SP1 ↔ Ext  ✓  ✓  ✓  ✓  ✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

✓ 

5.1.13.2 

Internal Interfaces 

Option 1: with Aggregation 

P1 → A2 

P1 → A1 

Purpose 

Inform  Flexibility  Service  Provider  about  possible  flexibility  on 
Flexibility Provider side for the next hour/day/…  

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Could be: 

 bridge 

83 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P1 → A2 

●  A set of Timeseries of flexibility (tolerance) including baseline 
(estimation  of  desired  power  consumption  considering  only 
Flexibility Provider’s comfort), upper bound (maximum energy 
that can absorb) lower bound (minimum energy required). 
●  Granularity of the timeseries,  its  length  (horizon) and  unit  is 

also contained in message description. 

●  Location: geographical (latitude and longitude) or grid-related 

(substation ID or connection point) 

●  Communication  endpoints  for  central  EMS  (or  individual 

assets) 

Other  information:  e.g.  flexibility  timeseries  are  valid  till  are  not 
exploited, once the flexibility is used, Flexibility Service Provider needs 
to consider a rate of flexibility adjustment or make frequent queries to 
get  latest  updates  from  Flexibility  Provider.  Or  data  about  rebound 
effects of storage-like flexibility. 

A1 → A2 

Purpose 

Inform about aggregated flexibility that can be offered to the market 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Option 2: no aggregation 

P1 → A2 

Purpose 

Inform  Flexibility  Service  Provider  about  possible  flexibility  on 
Flexibility Provider side for the next hour/day/…  

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Could be: 

●  A set of Timeseries of flexibility (tolerance) including baseline 
(estimation  of  desired  power  consumption  considering  only 
Flexibility Provider’s comfort), upper bound (maximum energy 
that can absorb) lower bound (minimum energy required). 

 bridge 

84 

 
 
 
  
REFERENCE FRAMEWORK 

P1 → A2 

●  Granularity of the timeseries,  its  length  (horizon) and  unit  is 

also contained in message description. 

●  Location: geographical (latitude and longitude) or grid-related 

(substation ID or connection point) 

●  Communication  endpoints  for  central  EMS  (or  individual 

assets) 

Other  information:  e.g.  flexibility  timeseries  are  valid  till  are  not 
exploited, once the flexibility is used, Flexibility Service Provider needs 
to consider a rate of flexibility adjustment or make frequent queries to 
get  latest  updates  from  Flexibility  Provider.  Or  data  about  rebound 
effects of storage-like flexibility. 

Option 1: with Aggregation 

P1 → A5 

P1 → A1 

Purpose 

Inform  Flexibility  Service  Provider  about  possible  flexibility  on 
Flexibility Provider side for the next hour/day/…  

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Could be: 

●  A set of Timeseries of flexibility (tolerance) including baseline 
(estimation  of  desired  power  consumption  considering  only 
Flexibility Provider’s comfort), upper bound (maximum energy 
that can absorb) lower bound (minimum energy required). 
●  Granularity of the timeseries,  its  length  (horizon) and  unit  is 

also contained in message description. 

●  Location: geographical (latitude and longitude) or grid-related 

(substation ID or connection point) 

●  Communication  endpoints  for  central  EMS  (or  individual 

assets) 

Other  information:  e.g.  flexibility  timeseries  are  valid  till  are  not 
exploited, once the flexibility is used, Flexibility Service Provider needs 
to consider a rate of flexibility adjustment or make frequent queries to 

 bridge 

85 

 
 
 
  
 
REFERENCE FRAMEWORK 

P1 → A5 

get  latest  updates  from  Flexibility  Provider.  Or  data  about  rebound 
effects of storage-like flexibility. 

A1 → A5 

Purpose 

Communication of the available aggregated flexibility for the horizon 
of  interest,  to  be  processed  with  an  offer  optimisation  function 
(regarding  portfolio  of  clients,  and  estimation  of  the  bids/imbalance 
fees). 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Aggregated flexibility offers per zone 

Option 2: no aggregation 

P1 → A5 

Purpose 

Inform  Flexibility  Service  Provider  about  possible  flexibility  on 
Flexibility Provider side for the next hour/day/…  

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Could be: 

●  A set of Timeseries of flexibility (tolerance) including baseline 
(estimation  of  desired  power  consumption  considering  only 
Flexibility Provider’s comfort), upper bound (maximum energy 
that can absorb) lower bound (minimum energy required). 
●  Granularity of the timeseries,  its  length  (horizon) and  unit  is 

also contained in message description. 

●  Location: geographical (latitude and longitude) or grid-related 

(substation ID or connection point) 

●  Communication  endpoints  for  central  EMS  (or  individual 

assets) 

Other  information:  e.g.  flexibility  timeseries  are  valid  till  are  not 
exploited, once the flexibility is used, Flexibility Service Provider needs 
to consider a rate of flexibility adjustment or make frequent queries to 

 bridge 

86 

 
 
 
  
REFERENCE FRAMEWORK 

P1 → A5 

get  latest  updates  from  Flexibility  Provider.  Or  data  about  rebound 
effects of storage-like flexibility. 

A2 → M2 

Purpose 

Submit flexibility offer to the market 

Involved roles 

Flexibility Service Provider 

MO 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

Option 1: through Flexibility Facilitator 

S1 → M2 

S1 → B2 

Purpose 

Inform about flexibility need that should be placed to the market 

Involved roles 

Flexibility Consumer 

Flexibility Facilitator 

List of exchanged data 

Flexibility request (what, when, where, how much, …) 

B2 → M2 

Purpose 

Place flexibility request 

Involved roles 

Flexibility Facilitator  

MO 

List of exchanged data 

Flexibility request (what, when, where, how much, …) 

 bridge 

87 

 
 
 
  
 
 
REFERENCE FRAMEWORK 

Option 2: direct 

S1 → M2 

S1 → M2 

Purpose 

Place flexibility request 

Involved roles 

Flexibility Consumer 

MO 

List of exchanged data 

Flexibility request (what, when, where, how much, …) 

Option 1: through Flexibility Facilitator 

M2 → S3 

M2 → B3 

Purpose 

Inform about flexibility transaction/agreement 

Involved roles 

MO 

Flexibility Facilitator 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

B3 → S3 

Purpose 

Inform about flexibility transaction/agreement 

Involved roles 

Flexibility Facilitator 

Flexibility Consumer 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

 bridge 

88 

 
 
 
  
  
 
 
REFERENCE FRAMEWORK 

Option 2: direct 

M2 → S3 

M2 → S3 

Purpose 

Inform about flexibility transaction/agreement 

Involved roles 

MO 

Flexibility Consumer 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

Purpose 

Inform about flexibility transaction/agreement 

M2 → A8 

Involved roles 

MO 

Flexibility Service Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

Option 1: with Aggregation 

A8 → P2 

A8 → A3 

Purpose 

Inform about flexibility transaction/agreement   

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

 bridge 

89 

 
 
 
  
 
  
 
 
REFERENCE FRAMEWORK 

A8 → P2 

A3 → P2 

Purpose 

Inform about flexibility activation to be scheduled (disaggregated) 

Involved roles 

Flexibility Service Provider 

Flexibility Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

Option 2: no aggregation 

A8 → P2 

Purpose 

Inform about flexibility activation to be scheduled 

Involved roles 

Flexibility Service Provider 

Flexibility Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

A3 → P2 (for GBP4) 

Purpose 

Inform about flexibility activation to be scheduled (disaggregated) 

Involved roles 

Flexibility Service Provider 

Flexibility Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

 bridge 

90 

 
 
 
  
  
 
 
REFERENCE FRAMEWORK 

A5 → S5 

Purpose 

Bid/offer for bilateral agreement (iterative phase) 

Note:  As  a  prerequisite,  bilateral  agreements  between  Flexibility 
Consumer  and  Flexibility  Service  Provider  (and/or  Flexibility  Provider) 
must  be  foreseen 
in  the  regulation.  Involved  parties  (Flexibility 
Consumer, Flexibility Service Provider) have to proceed with the bilateral 
agreement in fully compliance with the regulation dictates. 

Involved roles 

Flexibility Consumer 

Flexibility Service Provider 

List of exchanged data 

Imbalance Settlement period and its duration. Hourly table of flexibility 
and corresponding offer 

request/bid for flexibility in specific slot(s) of time 

Validation/refusal message 

Reconsider  offers  until  all the  forecasted  energy  requirement  is  safely 
satisfied. 

Lead time; Time before the (recurring) flexibility option expires. 

Problematic point (node) 

Remuneration scheme 

Others: 

●  Maximum number of activations 
●  Minimum time between activation 
●  Penalties for deviation from contract 

S6 → A6 

Purpose 

Flexibility request in operation phase (once the agreements are settled) 

Involved roles 

Flexibility Consumer 

Flexibility Service Provider(s) 

List of exchanged data 

Amount of flexibility and timing 

Location  (geocoding  or  node  specification)  of  the  points  in  which 
flexibility is required 

 bridge 

91 

 
 
 
 
REFERENCE FRAMEWORK 

A6 → S7 

Purpose 

Flexibility response  

Involved roles 

Flexibility Consumer 

Flexibility Service Provider 

List of exchanged data 

Response; Validation, rejection 

Option 1: with Aggregation 

A6 → P2 

A6 → A7 

Purpose 

Inform about flexibility agreement 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

A7 → P2 

Purpose 

Inform about flexibility activation to be scheduled 

Involved roles 

Flexibility Service Provider 

Flexibility Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

Option 2: no aggregation 

A6 → P2 

Purpose 

Inform about flexibility activation to be scheduled 

Involved roles 

Flexibility Service Provider 

 bridge 

92 

 
 
 
 
 
  
REFERENCE FRAMEWORK 

A6 → P2 

Flexibility Provider 

List of exchanged data 

Flexibility order (what, when, where, how much, …) 

A2 → M1 

Purpose 

Submit flexibility offer to the market 

Involved roles 

Flexibility Service Provider 

MO 

List of exchanged data 

Flexibility offer (what, when, where, how much, …) 

B1 → B2 

Purpose 

Inform about flexibility need that should be placed to the market 

Involved roles 

Flexibility Consumer 

List of exchanged data 

Flexibility request (what, when, where, how much, …) 

B2 → M1 

Purpose 

Place flexibility request 

Involved roles 

MO 

Flexibility Consumer 

List of exchanged data 

Flexibility request (what, when, where, how much, …) 

 bridge 

93 

 
 
 
  
 
 
 
 
REFERENCE FRAMEWORK 

M1 ↔ S2 

Purpose 

Exchange between market and SO to ensure a harmless and efficient bid 
selection from the grid perspective 

Involved roles 

SO 

MO 

List of exchanged data 

Flexibility offers and offer results (what, when, where, how much, …)  

Acceptance or refusal of the proposed plan of the MO and/or selection 
of most relevant offers from SO perspective 

Purpose 

Inform about market results to Flexibility Consumer 

M1 → B3 

Involved roles 

MO 

Flexibility Consumer 

List of exchanged data  Market results (what, when, where, how much, …) 

M1 → A8 

Purpose 

Inform about market results to Flexibility Service Provider 

Involved roles 

MO 

Flexibility Service Provider 

List of exchanged data  Market results (what, when, where, how much, …) 

P4 → A9 

Purpose 

Inform the Flexibility Service Provider of available flexibility at prosumer 
level. 

Involved roles 

Flexibility Provider 

 bridge 

94 

 
 
 
  
 
  
Flexibility Service Provider 

List of exchanged data 

Flexibility forecasts per flexibility provider 

REFERENCE FRAMEWORK 

A9 → A10 

Purpose 

Provide  the  optimisation  engine  of  the  aggregator  with  data  on  the 
available community- or portfolio-level flexibility. 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Aggregated flexibility forecast 

Purpose 

Inform Flexibility Provider of a request for the provision of flexibility 

A10 → P5 

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Request for flexibility 

A10 → A3 

Purpose 

Inform aggregator about the actual flexibility that can be offered by the 
Flexibility Provider 

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Prosumer flexibility offer 

S1 → I1 

Purpose 

Provide  the  flexibility  need  to  the  Intermediary  Stakeholder  so  it  can 
compute  the  Price  Signal  to  be  transmitted  to  the  potential  Flexibility 
Providers 

 bridge 

95 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Involved roles 

Flexibility Consumer 

Intermediate Stakeholder 

List of exchanged data 

Flexibility request 

I1 → P6 

Purpose 

Inform the prosumer about the energy price for the upcoming periods 

Involved roles 

Intermediate Stakeholder 

Flexibility Provider 

List of exchanged data 

Implicit steering signal (energy price) 

P6 → P2 

Purpose 

Inform the Flexibility Provider about the flexibility to schedule 

Involved roles 

Flexibility Provider 

List of exchanged data 

Schedule for activating the available assets 

P7 → E1 

Purpose 

Share all the data necessary to provide the prosumer with feedback  

Involved roles 

List of exchanged data 

Energy usage data, data related to energy usage (many options possible, 
including sensor data and IoT data)   

E1 → E2 

Purpose 

Provide  necessary  near  real-time  and  historical  data  to  train  the 
necessary models used by the optimisation engine of the ESCo.   

Involved roles 

Prosumer and ESCo  

 bridge 

96 

 
 
 
 
 
 
  
 
REFERENCE FRAMEWORK 

List of exchanged data 

1  Metering  data  (total  consumption,  consumption  of  individual 

2 

appliances)  
Sensoring  data 
luminance, etc.)  

(indoor 

temperature,  occupancy,  humidity, 

3  Weather data   
4  Monitoring  data  (appliances  status  (on/off),  appliances  mode  of 

operation)  

E2 → P8 

Purpose 

Send optimised operational schedule to the prosumer for achieving the 
desired goal (e.g., save energy, save money from energy bills, maximise 
their self-consumption, etc.)  

Involved roles 

Prosumer, ESCo  

List of exchanged data 

1 

2 

Recommendations  on  optimum  operation  of  controllable 
appliances for implementation of manual actions by the prosumer  
for  automatic 
to  gateway  of  prosumer 
Control 
implementation  of  optimal  operational  schedule  by  applicable 
controllable devices.  

signals 

E2 → B 

Purpose 

Estimate of the process results from the ESCO   

Involved roles 

ESCO  

List of exchanged data 

To be defined how these results are estimated  

P8 → B 

Purpose 

Process results from the prosumer   

Involved roles 

Prosumer  

List of exchanged data 

To be defined how these results are provided  

P9 → P10 

 bridge 

97 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Purpose 

Realise the actual needs of the prosumer (to either buy energy to cover 
demand or sell surplus generation). Should flexibility be considered, the 
purpose is to realise the needs of the prosumer while respecting their 
comfort and convenience and achieving certain optimisation goals, such 
as maximising the consumption of local generation.  

Involved roles 

Prosumer  

List of exchanged data 

1  Demand  forecast  or  flexibility  forecast  (baseline  demand  forecast 

plus upwards/downwards available flexibility)  

2  Generation forecast  

P10 → P2PM1 

Purpose 

Realise  the  available  generation,  as  well  as  the  total  demand  at 
community/local  market  level.  Realise  the  needs  of  each  prosumer 
within  the  community/local  market  (incl.  energy  needs  and  needs 
relating to comfort and convenience).  

Involved roles 

Prosumer, P2P Market Operator  

List of exchanged data 

1 
2 

Selling bid: Prosumer-level generation surplus  
Buying bid: Prosumer-level demand needs  

P2PM1 → P11 

Purpose 

Provide result of trading  

Involved roles 

P2P Market Operator, Prosumer  

List of exchanged data 

Traded Quantity/Price  

S3 → SS 

Purpose 

Inform  about  the  past  flexibility  transaction/agreement  to  enable  the 
settlement 

Involved roles 

Flexibility Consumer 

List of exchanged data 

Flexibility transaction/agreement 

 bridge 

98 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P2 → SS 

Purpose 

Inform  about  the  past  flexibility  transaction/agreement  to  enable  the 
settlement 

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility transaction/agreement 

S7 → SS 

Purpose 

Inform  about  the  past  flexibility  transaction/agreement  to  enable  the 
settlement 

Involved roles 

Flexibility Consumer 

List of exchanged data 

Flexibility transaction/agreement 

B3 → SS 

Purpose 

Inform  about  the  past  flexibility  transaction/agreement  to  enable  the 
settlement 

Involved roles 

Flexibility Consumer 

List of exchanged data 

Flexibility transaction/agreement 

A3 → SS 

Purpose 

Inform  about  the  past  flexibility  transaction/agreement  to  enable  the 
settlement 

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data 

Flexibility transaction/agreement 

 bridge 

99 

 
 
 
 
 
 
REFERENCE FRAMEWORK 

Purpose 

Inform about the past price signals to enable the settlement 

I1 → SS 

Involved roles 

Intermediary Stakeholder 

Flexibility Consumer 

List of exchanged data 

Price signals 

P2PM1 → SS 

Purpose 

Trade settlement  

Involved roles 

P2P Market Operator  

List of exchanged data 

Traded Quantity/Price  

5.1.13.3 

External interfaces 

S1 ↔ Ext 

Purpose 

Exchange data for Flexibility Request 

Involved roles 

Flexibility Consumer, External 

List of exchanged data 

Flexibility pool, Grid Operational Status, Flexibility availability 

S2 ↔ Ext 

Purpose 

Exchange data for Results validation 

Involved roles 

SO, External 

 bridge 

100 

 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

List of exchanged data 

Grid operational status 

S2 ↔ Ext 

S6 ↔ Ext 

Purpose 

Exchange data for Flexibility request 

Involved roles 

Flexibility Consumer, External 

List of exchanged data 

Grid network area status (emergency state) 

M1 ↔ Ext 

Purpose 

Exchange data for Market Results Clearing (BRP) 

Involved roles 

MO, External 

List of exchanged data 

Flexibility pool 

M2 ↔ Ext 

Purpose 

Exchange data for Market Results Clearing (SO) 

Involved roles 

MO, External 

List of exchanged data 

Flexibility pool 

P1 ↔ Ext 

Purpose 

Exchange data for Flexibility offer 

Involved roles 

Flexibility Provider, External 

List of exchanged data 

Any  data  required  for  calculating  flexibility  that  can  be  offered 
dynamically based on current and forecasted parameters’ values:  usage 

 bridge 

101 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

P1 ↔ Ext 

patterns,  types  of  devices,  set-points  preferences,  weather  data, 
calendar 

P2 ↔ Ext 

Purpose 

Exchange data for Process Schedule 

Involved roles 

Flexibility Provider, External 

List of exchanged data 

Control of assets 

P4 ↔ Ext 

Purpose 

Trigger  received  by  third  party or  the  community  to provide  flexibility 
forecast 

Involved roles 

Flexibility Provider 

List of exchanged data 

Request for flexibility forecast 

P7 ↔ Ext 

Purpose 

Gather  all  necessary  prosumer-level  data  required  by  the  ESCo  for 
optimising the operation / use of household appliances of the prosumer  

Involved roles 

Prosumer  

List of exchanged data 

1 
2 
3 

4 

Total consumption  
Consumption of individual (controllable) appliances  
Status  and  mode  of  operation  of 
individual 
appliances  
Indoor ambient conditions  

(controllable) 

P9 ↔ Ext 

 bridge 

102 

 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

Purpose 

Calculate the energy demand and energy generation (where applicable) 
forecasts required for understanding the bid needs of a prosumer.   

Involved roles 

Prosumer  

List of exchanged data 

1.  Energy measurements (generation and consumption)  
2.  Weather conditions   

P10 ↔ Ext 

Purpose 

Retrieve  energy  price  data  from  the  market  enabling  the  proper 
calculation of the bids.  

Involved roles 

Prosumer  

List of exchanged data 

Energy Prices  

P11 ↔ Ext 

Purpose 

Decide  on  the  P2P  transactions  to  take  place  among  peers  of  the 
community/local  energy  market  based  on  prosumer-level  needs  and 
energy prices.  

Involved roles 

P2P Market Operator  

List of exchanged data 

1.  Energy Prices for local energy market  
2.  Grid energy prices  

A10 ↔ Ext 

Purpose 

Trigger the  optimisation engine  of the  aggregator to request flexibility 
offers from available prosumers 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Request for flexibility 

 bridge 

103 

 
 
 
 
 
 
5.1.13.4 

Settlement subprocess interfaces 

SP1 → SP2 

REFERENCE FRAMEWORK 

Purpose 

Provide the characteristics (amount, time, …) of the provided/delivered 
flexibility to the Flexibility Service Provider 

Involved roles 

Flexibility Service Provider 

Flexibility Provider 

List of exchanged data 

Delivered flexibility (how much, when, …) 

SP2 → SP3 

Purpose 

Provide  the  information  about  the  sold  flexibility  (contract,  amount, 
time, …) 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Sold flexibility (contract reference, quantity, time period, …) 

SC1 → SC2 

Purpose 

Inform about the procured flexibility 

Involved roles 

Flexibility Consumer 

List of exchanged data 

Procured flexibility (contract reference, quantity, time period, …) 

SC2 → SP3 

Purpose 

Inform 
compensation fees for the procured flexibility 

the  Flexibility  Service  Provider  about 

the  calculated 

Involved roles 

Flexibility Consumer 

Flexibility Service Provider 

 bridge 

104 

 
 
 
 
 
 
List of exchanged data 

Compensation fee for the procured flexibility 

REFERENCE FRAMEWORK 

SP3 → SP4 

Purpose 

Inform about the compensation fee to be paid for the sold flexibility 

Involved roles 

Flexibility Service Provider 

List of exchanged data 

Compensation fee for the sold flexibility 

SP4 ↔ SC3 

Purpose 

Validate  the  flexibility  transactions  and  agree  on  the  payment 
information for settlement 

Involved roles 

Flexibility Consumer 

Flexibility Service Provider 

List of exchanged data 

Flexibility transaction data 

Payment information 

SP1 ↔ Ext 

Purpose 

Collect metering data to characterise the provided/delivered flexibility 

Involved roles 

Flexibility Provider 

Flexibility Service Provider 

List of exchanged data  Metering data 

 bridge 

105 

 
 
 
 
 
 
 
 
 
 
 
REFERENCE FRAMEWORK 

GETTING IN TOUCH WITH THE EU 

In person 

All over the European Union there are hundreds of Europe Direct centres. You can find the address of the centre 

nearest you online (european-union.europa.eu/contact-eu/meet-us_en). 

On the phone or in writing 

Europe Direct is a service that answers your questions about the European Union. You can contact this service:  

⎯ 

 by freephone: 00 800 6 7 8 9 10 11 (certain operators may charge for these calls),  

⎯  at the following standard number: +32 22999696,  

⎯  via the following form: european-union.europa.eu/contact-eu/write-us_en. 

FINDING INFORMATION ABOUT THE EU 

Online 

Information about the European Union in all the official languages of the EU is available on the Europa website 

(europa.eu). 

EU publications 

You can view or order EU publications at op.europa.eu/en/publications. Multiple copies of free publications can 

be  obtained  by  contacting  Europe  Direct  or  your 

local  documentation  centre 

(european-

union.europa.eu/contact-eu/meet-us_en). 

EU law and related documents 

For access to legal information from the EU, including all EU law since 1951 in all the official language versions, 

go to EUR-Lex (eur-lex.europa.eu). 

Open data from the EU 

The  portal  data.europa.eu  provides  access  to  open  datasets  from  the  EU  institutions,  bodies  and  agencies. 

These can be downloaded and reused for free, for both commercial and non-commercial purposes. The portal 

also provides access to a wealth of datasets from European countries. 

 bridge 

106 

 
 
 
 
 
 
 
 
 
The Service Contract (n. CINEA/2023/OP/0001/SI2.901723) supports BRIDGE activities, funded by the EU.