Enterprise Architecture for a clean, digital and participative energy system

Unlocking the Power of Data - Paving the Way for a Greener Energy Future in Europe!

2024-09-05T00:00:00Z

Europe is at a turning point in the energy sector, and data is the key to unlocking its full potential. But what exactly does a data-driven energy economy mean? Imagine a network where energy data flows seamlessly across borders, enabling smarter grid management, reducing carbon footprints, and empowering both consumers and businesses to make informed, energy-efficient decisions. This vision of interconnected and sustainable energy management is the foundation of the European Data Strategy, which aims to position Europe as a leader in data-driven energy innovation.

Yet, despite this promising future, the current reality paints a more complex picture. Today’s energy market is marked by fragmented regulations, incompatible systems, and a lack of unified infrastructure, making it difficult for energy data to flow freely across borders. Each country has its own data-sharing regulations and platforms, making cross-border data exchange cumbersome. This fragmentation has created isolated energy “islands,” where innovative solutions struggle to scale and thrive across the continent.

The Challenges of Building a Data-Driven Energy Economy

So, what are the main barriers to achieving a unified, data-driven energy market in Europe?

Fragmented Data Access and Regulation: Different countries have different regulations and policies for managing energy data, resulting in a complex and often incompatible landscape.
Lack of Interoperable Infrastructure: Many energy data platforms are not designed to communicate with one another, making data exchange difficult.
High Costs of Data Integration: Integrating data across diverse platforms and infrastructures is expensive, with up to 80% of costs spent on data integration alone.
Lack of Consumer Awareness and Engagement: The average consumer has limited access to their energy data, preventing informed decision-making.

Introducing EDDIE: A Game-Changing Solution for European Energy Data Integration 🏗️

This is where the European Distributed Data Infrastructure for Energy (EDDIE) comes into the picture. EDDIE is not just another centralized data repository; it’s a decentralized, distributed, and open-source platform designed to connect Europe’s fragmented energy data landscape. Initiated and led by Entarc.eu in collaboration with over 16 European partners, EDDIE is paving the way for a truly unified energy data space.

What makes EDDIE unique?

A Harmonized European Interface: EDDIE proposes a federated system that respects local diversity while providing a unified interface for accessing data from different member states.
Decentralized Data Sharing: EDDIE’s architecture enables direct data sharing between market actors, ensuring high scalability and real-time data flows.
Real-Time and Close-to-Real-Time Data Integration: Provides access to real-time data from smart meters and other grid-edge devices, crucial for new energy services.
User Empowerment and Consent Management: EDDIE’s Administrative Interface for In-house Data Access (AIIDA) gives users control over their data while complying with GDPR regulations.

Creating a Virtuous Cycle of Data-Driven Innovation

By addressing these challenges, EDDIE is creating a virtuous cycle of data sharing and service development that:

Unlocks New Market Opportunities: Companies can enter new markets faster and at a lower cost.
Boosts Innovation and Competitiveness: A unified data space makes it easier for startups and SMEs to develop and deploy new energy solutions.
Enables Cross-Border Energy Communities: Consumers will have more options to join energy communities and participate in energy management schemes across borders.
Lowers Integration Costs: A standardized interface and open-source tools reduce the cost of data integration.
Empowers Consumers: Platforms like AIIDA give consumers control over their data, enabling informed decisions.

The Road Ahead: Building the Future of Europe’s Energy Market

The journey to a fully data-driven energy economy will not happen overnight, but EDDIE is a crucial first step towards that vision. By leveraging a decentralized approach and focusing on interoperability, EDDIE sets the stage for a more flexible, efficient, and competitive energy market across Europe.

Identification and Authentication in a Common European Data Space

2024-09-10T00:00:00Z

Identification and Authentication (I&A) are essential building blocks for creating a secure and integrated energy data space in Europe. Project EDDIE addresses the challenges of establishing a reliable I&A framework that spans multiple countries and systems, ensuring that data exchange is streamlined and secure.

Key Challenges in Identification and Authentication for Energy Data

Project EDDIE identifies four main challenges in the context of a Common European Energy Data Space:

Integration with Existing Federated Infrastructures: Each EU member state has its own processes and platforms for managing energy data. EDDIE’s I&A strategy must harmonize with these national requirements while maintaining compliance.
Dynamic I&A for Distributed Participants: Managing large numbers of participants, from distributed energy resources (DERs) to flexible consumers, is complex and requires advanced technologies like Public Key Infrastructure (PKI) and eIDAS.
Platform Orchestration: EDDIE needs to manage identification and access for multiple platforms, ensuring that data is accessible and secure across diverse environments.
Cross-Space Data Connectivity: Establishing a bridge between EDDIE and other data spaces is crucial to facilitate comprehensive data sharing across the European energy ecosystem.

EDDIE’s Identification and Authentication Strategy

EDDIE’s I&A strategy revolves around leveraging the eIDAS Regulation and the European Digital Identity Framework to create a secure, cross-border I&A system. The following are the core domains covered in this strategy:

1. Integration with National Federated Data-Sharing Infrastructures

Each country has its own unique way of managing energy data. For example, in Austria, market participants must register through the Energy Data Exchange Austria platform. EDDIE’s solution is to offer a consent management layer that harmonizes local practices into a unified European interface.

2. Dynamic I&A for Large Numbers of Distributed Participants

In distributed energy systems, devices such as heat pumps or electric vehicle chargers must be securely identified and authenticated. EDDIE employs cryptographic certificates and secure communications protocols to ensure that every participant, whether it’s a device or an individual, can be trusted and validated.

3. I&A for Platform Orchestrations

The EDDIE framework incorporates components like the EDDIE Marketplace, Admin Console, and AIIDA (Administrative Interface for In-house Data Access) to support user and system authentication. Technologies such as Keycloak are used to manage roles and permissions across these platforms.

4. Data Space Connectors

EDDIE aims to connect seamlessly with other data spaces, such as GAIA-X and sister projects like Synergies and OMEGA-X, through dedicated data space connectors. This integration will help create a cohesive European energy data landscape, promoting data accessibility and interoperability.

Key Policy Recommendations

Mandate eID/eIDAS Authentication for All Eligible Parties: Using a common European authentication framework will reduce barriers and make it easier for new participants to join the market.
Standardize IDs for Connection Agreement Points: Consistent identification for all key actors in the data exchange process is crucial for secure and efficient operations.
Encourage Deployment of eID/eIDAS on Flexibility Platforms: This will streamline authentication processes and support the development of a unified European energy data space.

Project EDDIE is at the forefront of creating a standardized, secure, and interoperable I&A framework for the European energy sector. By addressing these key challenges, EDDIE aims to lay the foundation for a truly integrated Common European Energy Data Space that supports innovation, efficiency, and security.

To learn more about Project EDDIE and its I&A strategy, explore the full document on the EDDIE website.

Network Code on Demand Response Issue I - Definition of Controllable Unit

2025-06-23T00:00:00Z

Throughout the recent months we have analysed carefully the ACER-reviewed version of the European Network Code on Demand Response ( [here] ). The document is a step forward, yet it contains a series of severe issues that need to be resolved. In a series of posts, we are highlighting some of these issues and make proposals for how to improve the final European legislative framework. We will begin with the definition of "Controllable Unit" or "CU" - the smallest active entity in the conceptual framework of the legal act.

System Operator Proposal

In order to understand the issue, it is important to review what ENTSO-E and EU DSO Entity had written in their proposal - firstly the definitions of 'controllable unit' and 'technical resource' in Article 2:

'Controllable unit' or 'CU', means a single technical resource or an ensemble of technical resources behind the same single accounting point, if these technical resources are commonly controlled.

‘Technical resource’ means an individual power generating module of type A, B, or C as defined according to Regulation (EU) 2016/631 connected to the distribution system, individual energy storage unit, demand units according to Commission Regulation (EU) 2016/1388 or any other consumption device.

The important reason for this is that both basic aggregation models - (i) dealing with the full customer site as a controllable unit and (ii) dealing with the more complex scenario of treating behind-the-meter assets are viable. (i) is used in many - if not even most - operational settings.

The picture above shows potentially registered 'controllable unit's colored in pink. Depending on the scenario, a charging station or battery may be registered and treated as a CU, but also a household as a whole may be treated as a CU. It is a very important conceptual basis for the set of rules defined in the Act to treat both options as viable.

ACER - proposed definition in Article 2

'controllable unit' or 'CU' means a single power-generating module and/or demand unit pursuant to Article 2 (5) of [RfG NC 2.0] and Article 2 (4) of [DC NC 2.0].

Please see the definitions of 'power-generating module' in the Requirements for Generators amendment proposal: ‘demand unit’ means an indivisible set of installations containing equipment which can be actively controlled by a demand facility owner or by a CDSO, either individually or commonly as part of demand aggregation through a third party to provide demand response services to relevant system operators and relevant TSOs or is a V1G electric vehicle and associated V1G electric vehicle supply equipment, power-to-gas demand unit or heatpump.

Please see the definitions of 'demand unit' in the Demand Connection Code amendment proposal: ‘demand unit’ means an indivisible set of installations containing equipment which can be actively controlled by a demand facility owner or by a CDSO, either individually or commonly as part of demand aggregation through a third party to provide demand response services to relevant system operators and relevant TSOs or is a V1G electric vehicle and associated V1G electric vehicle supply equipment, power-to-gas demand unit or heatpump.

The Issue

IMPORTANT: The change of definition of 'controllable unit'/'CU' actively invalidates Aggregation Model A - treating a customer installation as a whole as a 'CU'. Whilst to us the problem doesn't seem to be created intentionally, it is very important to get this corrected in the final legal text.

Recommendation

The final version of the code should revert back to the rationale of the systems operator proposal, allowing for technology and implementation neutrality, and restain from linking to single assets too much. Both basic aggregation models must remain viable.

Network Code on Demand Response Issue II - Definition of Compensation Effect

2025-06-24T00:00:00Z

In our next session on important issues with the current version of the ACER review of the upcoming European Network Code on Demand Response, we are highlighting another breaking change that will lead to a lot of trouble if not corrected - the Definition of Compensation Effect

In order to understand the issue, it is important to review what ENTSO-E and EU DSO Entity had written in their proposal ( see [here] ) - firstly the definition of 'compensation effect'.

Compensation of sold flexibility services intendedly to be provided by behind-the-meter assets - probably measured by DMDs - will happen in the default scenario AND: not only because of 'other (activated or non-activated) controllable units' (also technical resources that are not known or not measured or not registered will contribute). Home Energy Mangement and Building Automation Systems are focussed on optimising/minimising the inflow/outflow at the connection agreement point / the exchange point with the distribution grid (usually targetting the point where smart metering systems are deployed. This is also what most procuring system operators will define as the point of delivery / service validation point. Only flexiblity that arrives in the grid can be paid for. Otherwise society as a whole will have to pay for services procured by systems operators that never arrive. Also we need to consider that SOs will procure flexibility in critical phases of grid operation, and a failure to deliver these services will have a big negative impact. If delivery is not reliable SOs will turn to other solutions, which will have a very negative effect on the development of market-based solutions.

System Operator Proposal

(48) ‘Compensation effect’ means the alteration of generation or consumption of other nonactivated technical resources in the time frame of a delivery of a local or balancing product, that compensate for the effects that the activation implies.

The picture above shows potentially registered 'controllable unit's colored in pink. Gray circles indicate 'technical resources' that are not necessarily registered as 'controllable units' behind the same connection point. In the upper right, you see an indication that activated behaviour change doesn't arrive at this point. In order to provide a good and implementable regulation on this, it is very important to differentiate between 'technical resource', 'controllable unit', 'connection point' and 'connection agreement point', with the latter indicating the end of customer premises - and with that the link between public infrastructure and the parts that can be attributed to a final customer's responsibility.

The Issue

IMPORTANT: The big problem is that these compensation effects will lead to flexibility being paid but not delivered to the grid. The upcoming implementing regulation proposals define a so-called service validation point, that defines where flexibility services need to arrive. There, it must be possible to have - ideally - measurements (e.g. from the near real-time interface that must be available for every smart metering system systematically rolled out after July 2019 as of Article 20 of Directive (EU) 2019/944, or through validated historical data / billing timeseries or reliable calculations, or a mixture of either. Validating the reflection at this point is therefore super important - and a decisive for reliable markets.

NOTE: Please note that these effects will happen in the DEFAULT-Configuration of most Home or Building Energy Management Systems, so it is not a matter of acting mala fide or in an erroneous sense. Therefore, getting this definition not right will invalidate many other parts of the Act.

Recommendation

The final version of the code must clearly refer to ALL compensations of activations at this Connection Agreement Point.

It must be made clear that data and measurement requirements and the degree of reflection at the SVP must be defined by the Procuring System Operator in the product requirements.

‘compensation effect’ means the alteration of injection or withdrawal by any technical resource different from the concerned controllable unit of the activated SPU or SPG, during the activation period of a local or balancing service, which counteracts the effects of the activation at the service validation point;

Network Code on Demand Response Issue III - Responsibility for the Operation of the CU Module

2025-10-20T00:00:00Z

Throughout the recent months we have analysed carefully the ACER-reviewed version of the European Network Code on Demand Response ( [here] ). The document is a step forward, yet it contains a series of issues that should be resolved with the finally released code. We will commence with the assignment of default responsibilities for modules in the Flexibility Information System.

Modules of a Flexibility Information System

In order to understand the problem, we first should commemorate definitions:

'flexibility information system' means a system to record at least the qualification of service providers, the product prequalification, product verification and grid prequalification of SPUs and SPGs and the switch of controllable units for the provision of balancing and local services and to exchange data for such processes;
'CU module' means a data space of a 'flexibility information system' that contains, manages and makes available data about controllable units;
'SP module' means a data space of a 'flexibility information system' that conains, manages, and makes available data about service providers, service providing groups, service providing units and system users.

In addition to that, each FIS shall have a 'common front-door', a machine-usable API for service provider to interact with the FIS modules in a standardised manner. It should furthermore be highlighted that these definitions have been put in place to support realities in many Member States. Some MS have centralised flexibility information systems in place, some have been developing these platforms alongside existing distributions of responsibility and in a de-centralised manner. In some MSs there will be a single and combined CU Module/ SP Module, some will have multiple CU Modules and a single SP Module and some will have multiple CU Modules and multiple SP Modules.

Option 1: Centralised Flexibility Information System operating a single CU module and a single SP module combined

Option 2: ACER Version Option - each Procuring SO running both a CU module and an SP module

Option 3: Better approach - each Connecting SO running a CU module for all assets connected to its grid, one centralised SP module

Now, in the ACER version published March 2025, puts a responsibility to each procuring system operator to operate a CU module and an SP module: Article 25(4) - Each procuring system operator shall be responsible for operating and maintaining one or more SP modules and one or more CU modules. This is problematic, as it will lead to inefficient and diffuse structures.

The Issue

Recommendation

Concluding from the abovementioned considerations, it is much better and follows more stringently the natural distribution of responsibilities, if the default responsibility for operating a CU module lies with the connecting system operator. For the market-sided SP module, it is ok to leave it under the responsibility of procuring system operators.

Hence, Article 25(4) should be reformulated: Each connecting system operator shall be responsible for operating and maintaining a CU module. Each procuring system operator shall be responsible for operating and maintaining an SP module.

Please note, that delegation is still possible as of Article 8 of the ACER NC proposal.