1. Introduction
This work presents the vision of the project OneNet, which aims to enable a pan-European electrical system where the heterogeneous landscape of stakeholders, markets and platforms across Europe can openly participate at all levels. The ongoing shift of the electrical grid from a centralized configuration toward a decentralized paradigm compels grid operators to respond to fundamentally altered operating conditions. This transition requires a reconfiguration of existing business models in order to support rapid decision-making and enhanced adaptive capabilities. Addressing these demands constitutes a challenge of unprecedented scope, calling for equally innovative approaches. In response, the project assembles a consortium of over seventy partners, including prominent IT companies, internationally recognized research organizations, and the two principal associations representing grid operators.
The paper offers an overview of the essential findings of the project and outlines the vision for an interoperable open-source and open-access architecture, which enables the full exploitation of flexibilities in the energy system by maximizing the integration of distributed resources and end customers enabling interaction and coordination among all stakeholders.
To comprehensively present this vision, the central aspects harmonization, interoperability, the technical part of the reference architecture and cybersecurity measures are discussed.
The paper is organized as follows. Chapter 2 presents the methodology that has been followed for the analysis of the harmonization, interoperability, and technical implementation aspects. Chapter 3 elaborates the findings of the work focused on products and market design, chapter 4 introduces the vision and recommendations of the project in terms of interoperability, and chapter 5 presents the OneNet architecture with the corresponding implementation and cybersecurity aspects. Finally, chapter 6 summarizes the conclusions of the paper.
2. Methodology
This chapter presents the methodology followed in this paper and introduces the terms used, the concepts, the followed procedure for the analysis, requirements and implementation.
2.1 Harmonization
OneNet approached harmonization with different methodologies depending on the topic being addressed. The following outlines the individual methodologies utilized surrounding harmonization of products, market architecture, and market phases.
2.1.1 Product harmonization assessment
The objective of the product harmonization assessment is to evaluate the degree of alignment between the characteristics and parameter values of standardized OneNet products and those implemented within the demonstrators. This evaluation seeks to identify whether a common set of products can be adopted at the European level or whether distinct local solutions are required to address specific regional, national, or local requirements. To achieve this, the assessment methodology was structured around four principal steps (as visualized in
Figure 1):
• Compilation and Comparison: A comprehensive inventory of the demonstrator products and their associated attributes was developed and systematically compared against the standardized OneNet product definitions. Areas of convergence and divergence were identified, and demonstrators were invited to justify their respective design choices. The results of this analysis were presented and discussed during an internal workshop held in November 2022.
• Identification of Barriers: Potential obstacles to product harmonization were consolidated into a structured list, drawing on prior project activities and relevant academic literature. This list was subsequently reviewed and refined through discussions with OneNet partners during an internal workshop in March 2023.
• Investigation of Non-Compliance: The underlying factors contributing to deviations from OneNet product specifications were explored through a dedicated survey. Demonstrators were asked whether their demonstration products would be deployed in real-world settings, the rationale behind their decisions, and their perspectives on possible barriers to harmonization.
• Development of Recommendations: Informed by stakeholder feedback and insights from the literature, a set of overarching recommendations aimed at supporting product harmonization was developed.
Figure 1. Overview of product harmonization assessment methodology.
Market architecture
The market architecture harmonization potential in terms of bid forwarding for the OneNet demonstrators’ solutions has been assessed by adopting a three-step methodology1:
• Step 1 - Describing the market architecture using the theoretical market framework proposed in2 and identifying the relevant submarkets;
• Step 2 - Market design elements pertinent to bid forwarding were examined in detail in order to identify existing constraints and barriers;
• Step 3 - Based on the identified barriers, targeted recommendations were formulated to support their mitigation and resolution.
Market phases
The project OneNet suggests recommendations for market phase harmonisation by analyzing barriers identified through the experiences of OneNet demonstrators. The methodology applied to assess the harmonization of market phases within the OneNet demonstrators’ solutions is structured around four principal steps. First, market phases identification involves identifying the market phases relevant to the OneNet demonstrators’ activities. Second, the definition of principles and practices for the design of the market phases is based on the Framework Guidelines for Demand Response (FGDR) and recommendations from other European regulations and general principles. Third, an analysis of the demo design for market phases is conducted, considering design motivation, by mapping the demo design with the identified principles and practices. Fourth, an analysis of barriers for market phases harmonisation, based on the demos’ design motivation, leads to the formalisation of recommendations for market phases harmonisation.
2.2 Interoperability
Interoperability, as a central topic within the context of a pan-European electrical, is addressed twofold: first, in terms of data exchange for the coordination among transmission system operators (TSO), distribution system operators (DSO) and customers, and second, regarding interoperability platforms.
The analysis of data exchange and communication requirements in the interaction among TSO, DSO, and customer was divided in three tasks and carried out individually from the perspective of the corresponding actor, focusing on their individual requirements, specific processes and limitations. The first two working groups focused on TSO and DSO concerns respectively, partly working closely together, as most of the stakeholder interaction in power systems is TSO-DSO coordination. The third working group focused entirely on customer-related communication and data exchange and covered also some non-technical aspects such as consumer types and engagement strategies.
All three working groups employed a methodology derived from the prior work of the BRIDGE initiative, as depicted in
Figure 2. The process began with a comprehensive review of numerous H2020 projects to identify those most relevant from each actor’s perspective. The selected projects were then analyzed to map the current state of the art and to highlight gaps and barriers related to data exchange, communication, and interoperability. In the final step, this methodology was applied directly to the project’s use cases.
Figure 2. Methodology architecture.
Building on this analysis, the assessment formulated detailed requirement specifications and proposed concrete measures to address the identified gaps in communication and data exchange. In addition, system-level guidelines were developed to support a TSO–DSO–customer integration framework aimed at enhancing interoperability, maximizing the utilization of flexibility, and facilitating the integration of renewable and distributed energy resources.
In parallel, the project’s findings on interoperability and common market design were further explored through an additional assessment. This exercise classified solutions into four thematic areas and generated recommendations for actionable next steps. Within this framework, both barriers and enablers were examined and systematically mapped to the proposed solutions, considering technical, economic, and regulatory dimensions.
2.3 OneNet Architecture and Data spaces
The design of the OneNet Reference Architecture as a Data Space ecosystem for energy stakeholders, was implemented following an incremental and hybrid approach, taking into consideration the most relevant Data Space initiatives and projects, as well the conceptual architectures, use case and requirements coming from the OneNet Demo Clusters.
The design phase has been divided into four separate steps and bases the foundations on three pillars (see
Figure 3): the evolution of the OneNet concept and the main objectives of the project (blue pillar); setting up an analysis of both the results already existing from the most relevant EU projects, architectures and initiatives related to Data Spaces and possible applications to energy domain (green pillar); architectures, use cases and requirements coming from the OneNet demo clusters (yellow pillar).
Figure 3. Design of the OneNet Reference Architecture.
Step 1 – Initial draft of the OneNet architecture
The initial step involved the creation of an early version of the OneNet Reference Architecture (v0.1). This preliminary draft incorporated the overarching vision of the OneNet project and the key characteristics of an Open Reference Architecture capable of supporting a Data Space ecosystem within the energy domain. The draft was reviewed and refined through discussions with technical and domain experts during dedicated Technical Workshops.
Step 2 – Bottom-Up and Top-Down analysis
The second step represents a central component of the methodology, encompassing a comprehensive analysis of all information relevant to the design of the OneNet Reference Architecture. This phase employed a hybrid approach: the Bottom-Up component focused on developing the architecture based on use cases, requirements, and specifications gathered from the OneNet Demo Clusters, emphasizing actors and data exchange needs; the Top-Down component examined leading Data Space initiatives and projects. The analysis drew upon outcomes from the most relevant EU projects, with particular attention to achieving seamless integration of cross-platform services. Additionally, the architectures of both the projects and OneNet Demo Clusters were mapped using the Bridge Reference Architecture Model, enabling the collection of comparable information across all demo architectures.
Step 3 – Integration of the results
The information gathered during Step 2 was consolidated through a gap analysis, identifying convergences and divergences among projects, demos, architectures, and initiatives to define the core characteristics of the OneNet Reference Architecture.
Concurrently, the preliminary architecture was updated to version 0.2, incorporating the first round of feedback.
Step 4 – Release of the OneNet Reference Architecture
The final step consisted of producing the first consolidated version of the OneNet Reference Architecture (v1), synthesizing all information, requirements, specifications, and concepts collected throughout the preceding phases of analysis and design.
3. Products and market design
3.1 Harmonized products
The project underscores the pivotal role of product harmonization in navigating the evolving landscape of electricity markets, particularly as the industry faces new challenges in system operation. With the emergence of complex demands for flexibility, especially in areas like congestion management and voltage control, there’s a pressing need to standardize approaches across diverse markets to ensure seamless coordination and maximize the efficiency of resource utilization.
At the heart of this endeavor lies the development of a robust product framework, which serves as the cornerstone for harmonization efforts. This framework offers a structured approach to categorizing and defining flexibility products, providing a common language that facilitates communication and collaboration among stakeholders. By establishing standardized classifications of product attributes, such as timing, power type, and geographical scope, the framework lays the groundwork for harmonization initiatives that span regional and national boundaries.
Within the framework of OneNet Deliverable 2.2,3 six distinct harmonized products have been meticulously developed to cater to a spectrum of operational needs and market dynamics. These products, each tailored to address operational challenges and timeframes, represent a concerted effort to promote harmonization and interoperability across diverse market segments.
Table 1 summarizes these six products and their usages within OneNet.
Table 1. Overview of harmonised products and their usages developed in OneNet.3
| OneNet harmonised product | Usage |
|---|
| Corrective local active power | This product is designed to respond to unexpected incidents requiring corrective action within one hour. It can support services that are independent of location, such as FCR, aFRR, or mFRR, as well as location-specific applications including congestion management and, potentially, voltage control through active energy. |
| Predictive short-term local active power | Intended to address forecasted operational challenges, this product allows for planned activation within the operational planning horizon. The advance planning enables the utilization of flexibility resources with longer full activation times, thereby increasing market liquidity. It is procured in day-ahead and intraday timeframes, primarily to manage forecast deviations, and is typically employed for congestion management (e.g., day-ahead congestion management) and balancing services (FCR, mFRR, aFRR), though it may also support inertia and voltage control. |
| Predictive long-term local active power | This flexibility product provides scheduled services procured in advance to maintain network security over extended periods. Its activation windows are planned months or years ahead, and it is primarily intended for congestion management. It may also support pre-scheduled or reserved voltage control services as part of long-term network planning associated with organic network growth. |
| Corrective local reactive power | Procured mainly to address real-time voltage control issues, this product is activated following unexpected faults. While its primary purpose is voltage control, it can also be applied to corrective congestion management when needed. |
| Predictive short-term local reactive power | Procured on timeframes shorter than one month, this product is primarily intended to manage voltage control issues, though it can also be applied to congestion management. Activation occurs within day-ahead and intraday periods, ensuring timely voltage regulation while maintaining secondary applicability for congestion management.
|
| Predictive long-term local reactive power | This product is procured to address voltage control challenges forecasted over extended periods. It supports the integration of flexibility into long-term planning and can be procured several years in advance. While its primary function is voltage control, it can also contribute to congestion management when required. |
These harmonized products, meticulously crafted to align with operational needs and market dynamics, represent a significant milestone in the journey towards product harmonization within coordinated and integrated electricity markets. By offering standardized solutions that transcend geographical boundaries and operational complexities, they lay the foundation for enhanced market efficiency, operational resilience, and sustainable growth within the energy sector.
However, the journey towards product harmonization is not without its challenges. As markets continue to evolve, there will be a need for the development of additional products for system services. A comprehensive four-step methodology has been devised to enable policymakers to evaluate how specific design attributes influence the participation of market participants and flexibility service providers.3 This methodology aims to identify and address entry barriers, linking them with TSO-DSO coordination schemes to foster the integration of markets seamlessly. Moreover, a broad framework is proposed to facilitate ongoing evolution towards more standardized products for system services, catering to both existing and novel service offerings.
Table 2 presents several of the main barriers faced by the demonstrators within OneNet as they implemented and tested flexibility product harmonization within their unique environments.
Table 2. Overview of relevant barriers to product harmonization for the different OneNet demos.1
| Barrier name | NOC | CYP | GRC | FRA | PRT | ESP | CZE | HUN | POL | SVN |
|---|
| Structure of the grid
| Y | N | N | Y | Y | Y | Y | Y | N | Y |
| SO market maturity
| N | N | Y | Y | Y | Y | Y | Y | Y | N |
| ICT challenges
| Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| Unclear product needs
| N | N | N | N | N | N | N | N | N | N |
| Diverging requirements
| Y | N | Y | N | N (TSO) Y (DSO) | Y | N | N | N | N |
| Economic development
| N | Y | N | N | Y | N | N | N | N | Y |
| Product life cycle stage
| N | N | N | N | N | N | N | N | N | Y |
| Competition/liquidity
| N | Y | N | Y | N (TSO) Y (DSO) | Y | Y | Y | N | Y |
| Political choice
| Y | N | N | N | N | N | N | N | N | N |
| Regulatory limitations
| Y | Y | Y | N | Y | Y | N | N | N | N |
| Contextual differences
| N | N | N | N | N | Y | N | N | N | N |
The OneNet project presents several key recommendations4 aimed at tackling these barriers and facilitating harmonizing products and services within electricity markets to promote flexibility, enhance market efficiency, and facilitate the integration of European markets. Firstly, product design is highlighted as a critical enabler for the development of flexibility markets. Harmonized products offer increased value by catering to multiple services across different markets, thereby accelerating market participation and supporting coordinated and integrated markets at the European level. This recommendation targets policymakers, NRAs, and system operators, emphasizing the pivotal role of harmonized products in driving market evolution and fostering cross-border cooperation.
Secondly, the project promotes the harmonization of both existing and newly developed products, with particular emphasis on areas such as congestion management and voltage control. By fostering consistency and coherence in product design, newly introduced flexibility products can optimize value creation from the outset and achieve seamless integration with pre-existing frequency services. This recommendation underscores the importance of aligning product development strategies with broader harmonization objectives, catering to evolving market needs and operational requirements.
Furthermore, the project emphasizes the necessity of establishing common terminology and classification of attributes to support the harmonization process effectively. While acknowledging the importance of national-level product definitions, the project advocates for a common EU approach to flexibility products to overcome barriers related to infrastructure and market maturity. Furthermore, it is essential to balance the fulfillment of local-specific requirements with the overarching goals of product harmonization, taking into account the distinctive characteristics of local flexibility resources and the technical challenges of the grid. The project also emphasizes that product harmonization will proceed progressively, reflecting the differing levels of market maturity and liquidity across local DSO and national TSO markets. This recommendation underscores the importance of adapting product design to kick-start local markets while maintaining a long-term vision for harmonization across all market segments.
3.2 Market design
As flexibility is increasingly expected to be provided across all grid voltage levels for services delivered to both TSOs and DSOs, the development of coordinated TSO-DSO flexibility markets becomes essential to (i) maximize the value-stacking potential of flexibility and (ii) ensure the secure operation of all involved grids during both procurement and activation. OneNet has contributed to this effort by developing a range of fundamental TSO-DSO coordinated market models, each exhibiting different efficiency levels and sensitivities to key driving parameters. These models are simulated within the OneNet flexibility markets simulation environment, taking into account the strategic behavior of flexibility service providers (FSPs).
Overall, common or multi-level market designs are recommended due to their efficiency and broader participation benefits. However, establishing joint or coordinated market platforms requires network data exchange. OneNet has implemented and validated these market mechanisms through various demonstration activities, supporting their potential scalability.
In addition, OneNet has devised methodologies and analyses to evaluate the harmonization potential of market architectures and market phases. The assessment of market architecture harmonization focuses on enhancing the efficiency of resource allocation and maximizing value stacking opportunities for participants. This methodology involves detailing the market architecture, analyzing market design elements related to bid forwarding, and identifying potential barriers. Similarly, the harmonization assessment of market phases seeks to standardize market procedures to minimize redundancies, with particular attention to prequalification, baselining, and market clearing processes.
Harmonization of market architecture
Harmonized market architectures improve value stacking, broaden market participation, and unlock additional flexibility resources. Aligning market architecture supports more efficient resource allocation across markets, with bid forwarding playing a central role in this process.5
Figure 4 provides a schematic overview of the bid forwarding mechanism.
Figure 4. Standard UC methodology according to IEC-62559.
In multi-market environments, such as European electricity markets, bids that are not cleared in one market can be transferred to another market trading a similar product. This process, known as bid forwarding, often involves an intermediate bid processing stage to select and adapt bids for use in the second market. For instance, if the minimum bid size in the second market exceeds that of the first, an aggregation step may be required before bids are forwarded to ensure compatibility.
OneNet’s bid forwarding concept enables flexibility bids that are not cleared in an initial market to be automatically transferred to subsequent markets. The demonstrators’ solutions, however, encounter several challenges: (i) economic barriers arising from perceived high setup and operational costs of flexibility markets and procurement platforms; (ii) regulatory barriers caused by variations in market structures and service requirements for different system operators across countries; and (iii) technical challenges associated with developing the necessary platforms, tools, algorithms, and network models. Regulatory support is essential to facilitate market integration and coordination, enabling bid forwarding and other multi-market participation mechanisms for flexibility resources. OneNet has demonstrated the technical feasibility of the proposed solutions, including market platforms and clearing engines/algorithms. The next step involves scaling these solutions through repeated or interoperable implementations and potential pan-European applications, while addressing regulatory gaps to support wide-scale adoption.
Harmonization of market phases
The acquisition of system services is structured around several distinct phases1,6:
Technical Pre-Qualification: Procedures to assess the technical capability of service providers (SPs) to deliver the required service, encompassing grid and product prequalification as well as SP qualification.
Grid Prequalification: Verifies that the connecting and intermediate grids can technically support service delivery.
Product Prequalification: Ensures SP assets meet the technical specifications of the service.
SP Qualification: Confirms that the service provider possesses adequate communication tools and correctly registered data for both the SP and associated units.
Baselining: Defines the expected behavior of SPs prior to service provision, establishing the ex-ante scenario for each SP.
Procurement: Encompasses procedures where demand (buyers) meets supply (sellers), defining binding agreements for service delivery. Procurement includes bid collection, market clearing, quantification of cleared bids, and determination of associated remuneration.
Activation: Initiates the delivery of the procured service.
Measurement: Observes SP and/or grid behavior during service delivery, collecting evidence that legally validates the service provided.
Settlement: Executes the financial exchange between buyer and seller based on the measured performance during service delivery.
OneNet has addressed entry barriers associated with non-harmonized phases for similar products across markets, misaligned prequalification timing relative to trading phases, and inconsistent baseline methodologies. Flexibility register tools have been introduced to streamline resource registration, facilitate information access, and enhance coordination among FSPs, SOs, and IMOs. Acting as a single point of contact, the flexibility register simplifies and harmonizes prequalification without compromising grid safety or service reliability. Nonetheless, implementing these registers and harmonizing prequalification processes faces economic, regulatory, and technical challenges, including development costs, difficulties in modifying existing procedures among multiple stakeholders, unclear requirements for new prequalification processes, and privacy concerns in data sharing. Pilot demonstrations conducted by OneNet address these challenges, incorporating perspectives from all key stakeholders and establishing initial steps toward scalable implementation.
Baseline methodologies are critical for determining the volume of flexibility delivered and utilized during activation, measurement, and settlement. Selecting an appropriate baseline methodology requires balancing simplicity, accuracy, and integrity. Within OneNet, a six-question framework has been introduced to clarify regulatory options regarding baseline methodologies, covering the scope of application, grid operational states, responsibility for baseline setting, types of customers and distributed energy resources (DERs), and product specifications. Insights from demonstration projects complement this framework, illustrating practical implementation approaches. The framework emphasizes methodological flexibility depending on stakeholder expertise, regulatory constraints, and service characteristics.
Analysis of market clearing barriers indicates a preference for pay-as-bid solutions over alternatives such as uniform pricing, unrestricted bidding, or enhanced transparency, largely due to concerns about competitive limitations. Operational challenges, stemming from limited historical data and experience in new local system service markets, drive market clearing designs that mitigate risks of service supply disruptions. Lessons from demonstrations highlight the importance of simplification, transparency, and openness. Market clearing mechanisms that facilitate simplified prequalification and aggregation can increase SP revenue potential. While greater transparency may raise concerns about gaming, providing participants with predictable income estimates is essential for attracting new market entrants. Mandatory capacity reservation can limit resource availability for near-real-time activation, potentially inflating activation costs, whereas allowing free bids in activation markets helps reduce market concentration and lower prices.
Advancing coordination, participation, and efficiency mechanisms in the procurement phase is vital for flexible and reliable market operation. OneNet has proposed theoretical market frameworks to guide the establishment and integration of novel flexibility markets. The project has also implemented TSO–DSO coordinated market platforms,6,7 supporting effective interaction among TSOs, DSOs, FSPs, and IMOs in flexibility procurement. Additionally, an optimization-based market clearing engine has been developed, enabling grid-safe and cost-efficient clearing of flexibility markets, supporting various traded products, respecting operational constraints, and fulfilling both TSO and DSO flexibility requirements.8
4. Interoperability
The concept of interoperability is discussed in OneNet firstly, according to the general definition of interoperability, where legal, technical, economical and regulatory requirements for the unhindered interaction among different actors and stakeholders are discussed, and, secondly, in terms of the technical data exchange addressing communication protocols, data models, interfaces, etc. Both perspectives are discussed in the following in 4.1 and 4.2. Finally, subsesction 4.3 introduces the identified gaps in terms of data exchange, as well as the recommendations and guidelines formulated in the project.
4.1 Requirements for interoperability
According to the interoperability roadmap developed within OneNet,4 the seamless interaction among different actors and stakeholders using different platforms and solutions is key to a European energy market with improved integration of flexibilities and distributed resources. In this context, interoperability would facilitate the deployment of cross-border solutions leading to a common and coordinated market for flexibility services. In this context, OneNet promotes replicable and interoperable solutions, identifying following four aspects as crucial:
To support process standardization, OneNet promotes interoperability, scalability, and data ownership. To do so, recommendations and previous outcome of widely recognized initiatives such as IDS, FIWARE and BRIDGE have been adopted, and standards such as CIM have been considered as a primary choice for the development of solutions. Furthermore, a wide range of cross-platform service were implemented in order to cover possible interactions among all actors to enable the seamless communication of diverse platforms. The principle of standardization and the deployment of existing solutions is also considered in the proposed OneNet Information Model, which is based on the NGSI-LD standard.
Within the framework of process standardization, OneNet recommends the harmonization of workflows and data exchange information models in order to ensure interoperability across operational contexts. Experience gained from the demonstration activities indicates that modular and adaptable architectural approaches are particularly well suited to facilitating the integration of emerging systems and services. In addition, the wider adoption of CIM and HEMRM is strongly encouraged.
Within OneNet, a dedicated task addressed these concerns, underscoring their critical importance for ensuring the resilience and trustworthiness of data exchange mechanisms and underlying infrastructures. The solutions developed within the project adopt a holistic approach to mitigating cybersecurity and privacy-related risks. In addition, OneNet put forward a set of concrete recommendations, tools, and frameworks intended for further examination within the project itself and in future research initiatives.9
On the topic of cyber security, it seems crucial to execute security tests on a regular basis to the platforms and the integrated services, as well as to update and patch existing software solutions to detect vulnerabilities and ensure protection against threats. Furthermore, the administration of a proper consent management for private data can improve the seamless communication and integration of FSP. In terms of robustness, a risk assessment is essential to understand potential risks which the cybersecurity solutions might present to the grid, as well as the integration of information mechanisms to ensure transparency in case of a cyber attack.
The project adopts open standards and implements solutions grounded in the decentralized Data Space concept to ensure inclusive market access for all stakeholders, while placing strong emphasis on the scalability and replicability of the developed solutions in order to support effective technology deployment and exploitation.
In this context, OneNet points out, that standardized data models are central to enable a smooth and seamless technological integration, and data-driven approaches will improve the integration of available solutions and components. Another unresolved issue for the grid operators seems to be the analysis of the trade-off of modern economically efficient flexibility solutions compared to other alternatives in order to plan the short- and middle-term operation as well as long-term planning based on well-informed decisions.
In the changing conditions of grid operation with distributed resources, scalable and adaptive solutions will facilitate the integration of flexibilities in such a way, that the system is able to adapt to changes and emerging technologies and novel development can be easily integrated. Here, data analytics seems to have significant potential to support decisions in an increasingly complex system.
A central outcome of the work in the project is the finding that a close collaboration between system operators, technology providers, utilities and other stakeholders is a key to development and innovation, as well as the targeted incentivization of interoperable solutions.
To achieve the goal of stakeholder interaction and coordination, interoperability among systems has to be improved by the deployment of standards and the data transparency used and exchanged by stakeholders. In this context, the project points out the necessity for clear role definitions, duty separation and the deployment of scalable, adaptable and user-friendly architectures and interfaces for the integration of actors and stakeholders.
Here, a clear definition of jobs, duties and responsibilities, but also of interactions and interfaces helps to avoid conflicts and achieve operational integrity and optimal interoperability.
In order to maximize the integration of FSP, regulations have to include concerns of small-scale residential FSPs to ensure their access to the market. To support this process, knowledge exchange in the context of workshops and marketing initiatives can inform consumers about their options to participate at the market and the importance of their contribution to the grid operation. Furthermore, modular and flexible infrastructures and user-friendly interfaces facilitate the integration of heterogeneous systems and interfaces and therefore, the participation of new stakeholders. In this context, the introduction of mechanisms to manage the equitable distribution of economic benefits to all stakeholders is expected to foster the participation of a broader range of stakeholders, including those who see insufficient financial incentive as a burden.
4.2 Interoperability in terms of data exchange
The generic business process is designed to facilitate the alignment of diverse use cases (UC) and technical solutions. It outlines the steps and procedures followed by the OneNet team to map various use cases in a general business process diagram. Emphasizing the identification of data exchange and interfaces at the TSO level, DSO level and customer level this process adheres to international standards. Illustrated in
Figure 5, the standard use case methodology, as described in the IEC-62559 standard, is employed, consistent with previous EU-funded projects. This methodology employs templates to structure use cases.
Figure 5. Structures of data spaces.10
The generic business process describes the exchange of data among distinct business roles, such as aggregators, TSOs, and market operators. Individual functions define the interactions between these roles by specifying the relevant interfaces, which may require access to external data sources (e.g., metering information) or control capabilities (e.g., load management). This representation encompasses both the functional and information layers of the Smart Grid Architecture Model (SGAM) and is intended to support the assessment of interoperability for flexibility assets. Its designation as “generic” reflects its independence from specific technical implementations, allowing it to be applied across projects employing different solutions.
The process is illustrated by a simplified sequence diagram that captures the interactions between business roles involved in the delivery of flexibility services. Each row in the diagram corresponds to a specific role, with functions shown as rectangular elements and data exchanges or interfaces represented by arrows. Functions denote discrete steps within the business process, receiving inputs from preceding steps, making use of external data or control commands, and generating outputs for subsequent functions.
Interfaces enable the systematic identification of information exchanged between functions, as summarized in an accompanying table. Use cases from selected Horizon 2020 (H2020) projects are mapped across both the functional and information layers, thereby establishing a link between the data exchanges defined in the SGAM information layer and the corresponding interfaces. Furthermore,
Figure 5 illustrates the alignment between system architectures and the relevant generic business processes. This mapping facilitates the identification of key aspects, including the application of existing solutions and standards, the need for extensions or modifications, the suitability of standards for the procurement of flexibility services, the detection of gaps or missing solutions for specific functions or interfaces, and the implementation of measures to address deficiencies or the absence of solutions for data exchange and interfacing.
Through this mapping process, each function and interface within the selected use cases allows for the identification of the following elements:
• The solutions or standards employed.
• Instances where standard-based solutions are embraced, necessitating extensions or modifications to meet requirements.
• Whether the solutions or standards adequately meet the needs for procuring flexibility services.
• The presence of gaps or the absence of existing solutions for particular functions or interfaces.
• The types of solutions implemented to address gaps and the absence of existing solutions for data exchange and interfaces.
4.3 Identified interoperability gaps, recommendations and guidelines
In the following, the identified gaps in terms of interoperability are presented from the perspective of each of the three main stakeholders, which were analyzed in OneNet: TSO, DSO and customer, as well as at system level, where the stakeholder-relevant gaps are considered in a comprehensive manner to analyze how they affect the system and how resources at system level can be beneficial to compensate these gaps. The stakeholder perspective reflects the specific challenges related to the interaction of the corresponding stakeholder with other actors, e.g. for DSO typical data models and communication protocols are considered, and the interoperability issues in their interactions with other DSOs (DSO-DSO), with TSO (DSO-TSO) and to customers (DSO-customer). In consideration of the identified interoperability gaps, but also based on findings from the project UC and previous projects, the formulated recommendations and guidelines and introduced in the end of the subsection.
Interoperability gaps
TSO
The implementation of a proprietary information model raises the necessity for additional insights into the specific information model utilized and the communication protocols employed. However, the inability to pinpoint each data model and communication protocol for every interface poses a challenge, hindering a comprehensive analysis. This lack of data not only limits the depth of gap analysis but also inhibits the computation of forecasting for diverse flexibility needs that aren’t addressed in existing standards. Moreover, the reliance on customized solutions for data models instead of adhering to standardized practices further complicates matters. Details regarding the information exchange, including data description, volume, frequency, and the specifics of the data model and communication protocols, are either missing or not publicly available, impeding a thorough understanding of the system.
In some cases, customized solutions for data models are employed, as evidenced in the Western cluster use cases. However, there remains a dearth of information concerning the components and characteristics of these data models, posing challenges for comprehensive analysis and interoperability. While the Eastern cluster demo expresses intentions to incorporate the Common Information Model (CIM) in the future, standardized data models are currently absent. Additionally, there is no indication of whether communication protocols adhere to standardized formats, further complicating interoperability and analysis efforts.
DSO
The analysis identifies gaps in harmonization and standardization, particularly in DSO ancillary service markets, which are either in early development or non-existent across most European countries. This contrasts with the mature and pan-European harmonization of TSO ancillary service markets. Due to their local orientation, DSO markets often require tailored solutions adapted to local conditions, limiting incentives for harmonization and standardization. However, OneNet use cases piloting TSO-DSO coordination for ancillary service acquisition demonstrate mostly harmonized data models and communication protocols. Communication protocols are generally defined for entire use cases or specific functions rather than individual interfaces, partly due to the involvement of consumers with lower technical capabilities. Specific examples from demos in Czech Republic, Slovenia, Spain, France, and Hungary highlight the need for customized or extended standards to cover all data exchanges, particularly at the DSO level. The analysis aligns with findings from the EU-Sysflex project, which also identifies gaps in CIM standards for DSO-level data exchanges.
Customer
From customer’s perspective, key gaps identified in previous H2020 projects relate primarily to standards governing data exchange between SCADA systems and distributed energy resources (DERs), including storage units, load controllers, microgeneration, electric vehicles, and prosumer devices. The limited consideration of prosumer-centered aspects within existing standards and protocols results in communication ambiguities and delays in the deployment of comprehensive strategies for integrating active customer-side assets.
Another significant gap concerns the absence of clear policies for data anonymization, consent management, and personal data handling within standards and regulatory frameworks. Additionally, the complex communication requirements associated with more sophisticated products can present barriers for smaller flexibility service providers (FSPs), as standards and interfaces are not uniform and data exchange modalities vary considerably.
The OneNet use case further highlighted the challenges posed by proprietary information models, which could restrict FSPs’ ability to operate across multiple national market FROs should these be established independently. The proliferation of diverse information models also limits FSPs’ opportunities to participate in multiple markets, creating additional obstacles to market integration.
Recommendations and guidelines
TSO
In order to foster seamless data exchange within the energy sector, adherence to established standards is paramount. Here are some guidelines to ensure alignment with existing standards and protocols:
1.
Alignment with Existing Standards: Rather than relying on proprietary solutions, it is advisable to adhere to established standards for data exchange. Proprietary solutions may hinder interoperability and create unnecessary barriers. Extending existing data models is encouraged as a means to replace proprietary solutions, promoting consistency and compatibility across systems.
2.
Adherence to Common Standards and Protocols: Emphasize alignment with common standards and communication protocols. This ensures compatibility and facilitates smooth interactions between different systems and stakeholders.
3.
Recommendation for CIM/CGMES: The use of CIM/CGMES standards (IEC 61970–600-1 and IEC 61970–600-2) is strongly recommended. These standards have been widely accepted and provide a solid foundation for data exchange within the energy domain.
4.
Reinforcement of CIM Coverage for Data Exchange: Focus on enhancing CIM coverage, particularly for data exchange between smaller Distributed Energy Resources (DERs) and system operators. Real-time data, including setpoints of devices providing services, should be within the scope of data exchange.
5.
Standard Messaging System Development: Develop a standard messaging system to facilitate the implementation of business applications. Such a system should enable seamless communication of balancing requirements among all involved parties across European countries.
6.
Consideration for Insufficient Classes and Attributes in CIM/CGMES: While CIM/CGMES is recommended due to its well-established nature and interoperability benefits, it’s important to note that there may be insufficient classes and attributes for certain business objects, particularly in TSO-DSO data exchange. Efforts should be made to address these gaps to ensure comprehensive coverage.
7.
Alignment with Objectives of Eastern Cluster: The adoption of CIM/CGMES aligns with the objectives of the Eastern cluster, further emphasizing its suitability and relevance in the context of regional planning and integration efforts.
DSO
Within the context of data exchange interfaces involving Distribution System Operators (DSOs), four main categories have been identified:
1.
TSO-DSO Coordination: For effective collaboration between Transmission System Operators (TSOs) and DSOs, the adoption of CIM-based standards is recommended.
2.
DSO-Market Operator (MO) Interaction: Numerous demonstration projects have utilized proprietary extensions of CIM standards or alternative data models, often to maintain compatibility with legacy systems or due to limitations in current standards for DSO-specific applications. To address this, it is suggested that existing standards, including IEC 62325, 61968, and 61850, be extended to better accommodate the operational needs of DSOs.
3.
DSO-Flexibility Service Providers (FSP): Data exchange practices between DSOs and flexibility providers—particularly smaller actors—vary widely. Although comprehensive data models such as CIM can enhance interoperability, their implementation costs may outweigh benefits in some contexts. Consequently, a single universal standard is not always advisable, and decisions should be guided by local cost-benefit considerations.
4.
Interoperability Assurance: Despite the diversity of platforms and tools employed for data exchange, maintaining a baseline level of interoperability across all stakeholders remains essential.
In Horizon Europe projects analyzing DSO-market platform interfaces, bespoke platforms are commonly developed, with IEC standards like CIM being prevalent for structuring data. However, proprietary formats are also common. Communication protocols vary, including MQTT or REST API.
Common gaps identified across use cases include insufficient coverage of DSO-specific use cases by existing standards, leading to the deployment of proprietary solutions. Recognizing this diversity, recommendations are tailored based on the actors involved:
•
System Operators: Standardized common data models like CIM are recommended for interfaces between system operators.
•
DSOs and End Users: Less expensive and more readily implementable proprietary solutions can be appropriate for data exchanges between DSOs and end users or small-scale flexibility providers; however, ensuring interoperability remains essential.
Beyond recommendations concerning data models, two additional key lessons can be drawn:
1.
Need for Standardization Advancement: It is essential to further develop standardization of data models to address DSO-specific use cases at the European level, engaging both industry stakeholders and policymakers in the process.
2.
Focus on European Solutions: Standardization initiatives should prioritize solutions at the European scale rather than at the national level, ensuring cross-border consistency and effectiveness.
Customer
Mainly, the identified gaps concern the lack of FSP-related aspects in the standards. In this context, the processes, roles, tools, standards and responsibilities for DER-SCADA data exchange should be clearly defined, and standards such as IEC CIM should be updated to include DER-SCADA exchange. Furthermore, smaller units should be integrated via data exchange platforms, flexibility registers and aggregation services.
In the context of the variety of applied information models, the harmonization of the information system to facilitate the interoperability between countries would be highly beneficial. To do so, a proposal to the CIM expert group should made to extend the CIM profiles, and corresponding working groups could be created to assist the identification of FSP characteristics and requirements to facilitate the development.
In order to deal with the complex communication requirements, the introduction of aggregation units would be helpful, which could handle the requirements and facilitate the process for smaller FSPs. Therefore, business models for aggregation units should be incentivized.
System
In order to abstract from the actor-centered perspective and map the findings of the working groups to the system level, the consequences of actor-specific gaps for the system were discussed.
For instance, the adoption of proprietary information models can have several significant impacts on the system. Primarily, it may hinder the development of flexibility markets and the integration of new participants, thereby limiting the full potential of available flexibility and compromising overall system stability and resilience. Moreover, the use of common information models is essential to facilitate seamless data exchange among stakeholders in an increasingly digitalized energy sector, supporting rapid and efficient communication across all parties.
Unlike proprietary approaches, adherence to relevant standards guarantees that data exchange and communication infrastructures can interface with a wide range of systems across multiple stakeholders, thereby facilitating the effective implementation of flexibility markets.
Another critical issue is the absence of standardized frameworks for DSO flexibility services at the data exchange level, compounded by the lack of uniform data exchange protocols and information models at the national level. Flexibility services addressing local challenges are particularly important for grids with growing shares of renewable generation and distributed resources. Consequently, the current lack of standard solutions and the resulting complexity in stakeholder interactions can undermine the stability and resilience of both local markets and the broader system. Implementing CIM standards on the distribution side offers a pathway to streamline and enhance data exchange between DSOs and other stakeholders.
It is therefore recommended that standards explicitly address data exchange for real-time and near-real-time measurements, as well as flexibility activation requests. The absence of these provisions in current standards is linked to critical operating conditions in electrical grids, where rapid interventions are required to mitigate technical issues. Incorporating these aspects into standards is crucial to ensure that grid operators can effectively leverage the flexibility offered by DERs to resolve operational challenges.
From the consumer perspective, there is currently no control over interactions and data exchanges. Aggregators and flexibility management platforms often do not disclose information regarding data formats or model setpoints, and consent management is largely unregulated. Establishing proper consent management mechanisms would facilitate the development of new tools and algorithms for flexibility services based on consumer data. The lack of such mechanisms may influence prosumers’ willingness to participate in energy markets and could give rise to legal challenges for flexibility traders. When viewed at the system level, these issues can slow the integration of small FSPs, undermine small FSP-centered business models, and consequently reduce profitability and tax revenue for green energy enterprises.
5. Technical solution
5.1 Data spaces
With the ongoing technological advances in all sectors of business and daily life, increasing amounts of data need to be securely and efficiently exchanged and aggregated across many types of systems.10 Within the energy sector in particular, the transition from unidirectional to multidirectional power flows, the increased amount of volatile renewable energy, and the inclusion of new actors and roles such as prosumers, all lead to an increased need for control. Unprecedented amounts of data need to be aggregated and processed from disparate sources.11
This data collection, aggregation and processing needs to be both efficient and secure, the scale of which poses a substantial challenge to the development and integration of such systems.12 The Energy Transition Expertise Center (EnTEC) has comprised a report on a Common European Energy Data Space (CEEDS), which names four major issues European companies faced related to data sharing:
• Data formats – interoperability is hindered by a lack of standards and substantial overhead in aligning data originating from different sources.
• Data access – sets of data that need to be considered together are not always generated and owned together. Lack of accessibility caused distributed data ownership and storage poses a significant hurdle to efficient data processing and development of a “big picture” perspective
• Data privacy – within the energy sector, certain kinds of information such as individual household consumption data can be traced back to individual people. Such personal data needs to be handled with care and according to relevant regulations, such as the General Data Protection Regulation (GDPR) in the EU.
• Cyber security – energy data is relevant to a state’s infrastructure, and the rapidly increasing need for transmission of this data results in risks of interception and manipulation by bad actors.13
Data Spaces aim to address these issues. The notion of a Data Space can be seen as a form of collaboration on data by a set of participants. Instead of physically moving needed data into a central data base, data stays stored at the source (or on specific distributed data stores), and the owner can control who may gain access through the data space’s governance tools.14
The basic concept of a data space includes three roles for participants: Data Provider, Data Consumer, and the Federator. As mentioned, there is no central data store – exchange of data happens directly between the Provider and Consumer. As a result, data redundancies may occur – Data Spaces allow for co-existence of the same data in several places. However, this also means there is no need for a common schema across the entire data space. Integration happens instead on a semantic level, e.g. through shared vocabularies between Data Provider and Data Consumer.
The Federator of a Data Space is responsible for ensuring security, trust, and other governance principles through intermediary services. Depending on the extent of the Data Space and applicable regulations, this e.g. includes cataloguing and brokering of data sources, logging of data exchange, etc.
The structures inhabited by these basic actors can become arbitrarily complicated, depending on the variety of stakeholders involved and the kinds of data to be exchanged. The simplest form is a Closed Ecosystem, with a set amount of participants, where the federator’s duties may be handled by one or several of the general members. In contrast, an Open Ecosystem contains a dedicated Federator node and allows fluctuation in further participants, joining and leaving the ecosystem depending on necessity. Finally, complicated and large systems (such as energy grids with large amounts of ICT) tend to require a Federation of Ecosystems, in which participants may be included in more than one Ecosystem at a time, and the ability to share data across different Federator’s realms is a necessity. This results in additional requirements regarding interoperability as well as trust.
Within these structures, OpenDEI (a Coordination and Support Action spanning a significant amount of related H2020 projects) defined a set of basic design principles for Data Spaces.
•
Data Sovereignty. Participants in a Data Space should reap its benefit regarding opportunities for data management and processing, while keeping full control over its accessibility.
•
Data Level Playing Field. A Data Space requires a system based on cooperation instead of competition. This includes a low barrier to entry as well as the absence of a hierarchy among participants based on the amount of data they control.
•
Decentralized soft infrastructure. A Data Space is not characterized by a centralized and fixed IT Infrastructure or platform. It can instead span several platforms and technologies, which are connected by common agreements and contracts regarding technical and operational as well as legal aspects.
•
Public-Private Governance. In order for all stakeholders to be equals in a Data Space, public as well as private interests need to be represented and enforced. This requires specific legislation and regulations across the relevant fields.
Adherence to these principles enables a Data Space to address the previously mentioned hurdles to data sharing (data formats, access, privacy, security).
Figure 6 shows a set of building blocks defined by OpenDEI, taking the next step from a conceptual idea to an actual implementation.
Figure 6. Building Blocks for Data Spaces.
Compared to other sectors, energy data spaces must comply with a broader and more specialized set of regulatory requirements. Nevertheless, well-established regulatory authorities and industry associations provide structured processes for developing market-wide standards covering communication protocols and data management. These existing frameworks, which often share strong alignment with recognized data space reference architectures, should be linked and extended to establish a unified, federated ecosystem referred to as the Common European Energy Data Spaces (CEEDS), despite the significant interoperability demands this entails.
As illustrated in
Figure 7, interoperability represents a critical dimension for the successful deployment of energy data spaces. In accordance with ISO/IEC 21823–1, interoperability is defined as the capacity of two or more components or systems to exchange specific data and to process that data into usable information. More specifically for data spaces, the Data Space Support Centre (DSSC) defines interoperability as “the ability of participants to seamlessly exchange and use data within a data space or between two or more data spaces.” [1]
Figure 7. OneNet Reference Architecture.
Interoperability within energy data spaces can be categorized into three main dimensions: technical interoperability, semantic interoperability, and governance interoperability.
1. Technical interoperability: This dimension establishes the foundational technical framework that enables all participants in an energy data space to correctly interpret and process metadata associated with available services and data, ensuring reliable and seamless data exchange among stakeholders. Key components of this framework include:
Technology plays a central role in enabling these functionalities. In many data spaces, the “data space connector” acts as an endpoint through which actors interact within the space. In addition, shared registries and services are necessary to provide common functionalities, such as participant registration, across the data space.
2. Semantic interoperability: refers to the ability of diverse systems and devices to exchange information and interpret it consistently and accurately, based on a shared understanding of its meaning and context. Implementing frameworks that harmonize data sharing within a common semantic structure enhances interoperability by promoting standardized and uniform data exchanges. Such frameworks define shared vocabularies, data models, and ontologies, ensuring coherent interpretation across otherwise heterogeneous systems. By standardizing data-sharing practices, stakeholders can integrate and analyze data seamlessly, enabling efficient communication and collaboration. Common ontologies provide a unified vocabulary and conceptual structure, supporting consistent data interpretation and facilitating the integration and fusion of information from multiple sources. Within this context, CEEDS depends on the harmonization and application of widely recognized standards-based data models and ontologies, including SAREF, IEC 61970, IEC 61850, OCPP, the Open Data Protocol (OData), and the Common Information Model (CIM).
3. Governance interoperability: This dimension addresses questions related to regulatory frameworks, decision-making processes, stakeholder involvement, and accountability within a data space. It requires collaborative efforts among relevant actors to establish decision-making mechanisms, define responsibilities, and implement communication and enforcement protocols.
The emergence of new paradigms in energy flow management—such as active participation of distributed energy resources (DER), e-mobility, and flexibility solutions—is driving novel interactions among stakeholders and creating new opportunities for data exchange. Identifying the key interactions to be supported becomes crucial, alongside equipping data spaces with solutions that comply with policies and regulations while enabling the development and deployment of innovative services for resilient and reliable energy systems.
Interoperability in the energy domain is the focus of the Horizon-EU project int:net - interoperability network for the energy transition [2]. The primary aim of int:net is to harmonize interoperability endeavors concerning energy services across Europe by fostering an interdisciplinary network of stakeholders engaged in continual discourse on the subject throughout and beyond the project’s duration.
int:net specifically influences the interoperability landscape for energy services by achieving the following objectives:
• Creating a shared knowledge base for interoperability in European energy services: advancing the interoperability of energy services, data, and platforms at both functional and business levels through the development and maintenance of a repository documenting interoperability activities and best practices.
• Developing a comprehensive and widely recognized Interoperability Maturity Model (IMM): evaluating the capabilities and competencies required for the interoperability community to effectively design, implement, and maintain interoperable solutions.
• Establishing a framework for interoperability testing across a network of facilities: drawing on insights from multiple European initiatives to promote a standardized approach for testing interoperability in ongoing projects, aligning testing procedures, and creating a self-sustaining, formally institutionalized distributed network of interoperability testing laboratories.
• Building a community network for the European interoperability ecosystem: supporting horizontal coordination and fostering sustainable adoption of energy services related to interoperability, data spaces, and digital twins, while actively engaging legal and regulatory stakeholders in cross-domain modeling and interoperability testing activities.
Moreover, int:net coordinates the Energy Data Space Cluster Projects (EDSCP); it is composed, in its inner layer, by the five Horizon-EU projects that establish the grounds for a common European energy data space: OMEGA-X, ENERSHARE, SYNERGIES, DATA CELLAR and EDDIE. The overall goal of the cluster is aligning the various implementations of the pilots, through the identification of the reference use-cases to be commonly leveraged, the definition of the key building blocks, and the promotion of the most effective technologies and components. The cluster activities aim to set the baseline for the interoperability, technical and semantic, of energy data spaces, to achieve their complete federation.
Among its accomplishments, the EDSCP has identified new business opportunities for energy sector stakeholders. In particular, it has defined a set of high-level Business Use Cases (BUCs) that fully leverage data space technologies.[3] A critical requirement for realizing the full potential of data spaces in the energy sector is the integration of data from multiple sources using standardized data models and ontologies. The BUCs specify the precise data exchanges between relevant participants, including consumers, local communities, TSOs, DSOs, multi-energy utilities, e-mobility operators, RES investors and operators, and non-energy service providers. Collectively, these five BUCs facilitate and support the large-scale deployment of CEEDS, maximizing the value of data exchanges through the data space approach and enabling the creation of innovative energy services. They correspond to:
• Use case #1 – “Collective self-consumption and optimized sharing for energy communities”
• Use case #2 – “Residential home energy management integrating Distributed Energy Resources (DER) flexibility aggregation”
• Use case #3 – “TSO-DSO coordination for flexibility”
• Use case #4 – “Electromobility: services roaming, load forecasting and schedule planning”
• Use case #5 – “Renewables O&M optimization and grid integration”
Reference to OneNet (business perspective)
As presented earlier the evolving decentralization of the power grids denotes the need for increased flexibility from versatile energy stakeholders in both transmission and distribution levels. Gradually, new energy stakeholders act as Flexibility Service Providers incorporating the flexibility of heterogenous energy sources on the active system management. The value chain of electrical grids increases along with the interactions among the stakeholders with subsequent data and information exchanges.
The OneNet Framework is built upon a fully replicable, open, flexible, and scalable architecture designed to enable the European electrical system to function as a unified, efficient network, contingent on secure and trusted connections among energy stakeholders. Through participation in multiple market mechanisms, OneNet facilitates universal access for all stakeholders, from small consumers to large producers, irrespective of their physical location. By clearly defining stakeholder interactions and harmonizing potential data exchanges at a European level, the framework enhances data and service interoperability across actors, systems, and platforms, while also supporting connectivity for cross-border flexibility markets.
The framework enables direct communication between participating stakeholders, encompassing both data producers and data consumers. Its Middleware, Workbench, Monitoring, and Analytics components operate exclusively on metadata to support this communication, without accessing the underlying data itself. Each data producer retains full control over its information, determining which data can be shared and with whom. Predefined Cross-Platform Services and Business Objects ensure that exchanges occur in a standardized and harmonized manner, while stakeholders retain the flexibility to define additional Services or Business Objects as needed.
5.2 OneNet framework
One of the ley points of the OneNet Vision was the creation of a P2P fully decentralized ecosystem for interoperability and data exchange, able to implement the first pan-European Energy Data Space.
The first important step to achieve this result was the definition of the reference architecture for the entire OneNet system, capable of identifying and mapping existing systems and actors, from the point of view of an ecosystem based on data exchange.
As described in Chapter 5.1, the OneNet Reference Architecture was designed in an iterative way, starting from a detailed analysis of the most relevant initiatives and projects about data space and the energy domain. The final version of the OneNet Reference Architecture, shown in
Figure 8, considered all the important common points as well as the missing gap, for having a complete and flexible solution able to enable pan-European market models and coordinated operations, in a business-model agnostic approach.
Figure 8. Data management with the OneNet middleware for a decentralized approach.
The OneNet Reference Architecture is structured into three logical layers::
• Bottom layer: This layer encompasses data sources and energy stakeholders, referred to as the OneNet Participants.
• Middle layer: Serving as the foundation for the OneNet Network of Platforms, this layer includes all platforms involved in data exchange and the utilization of cross-platform services. It also incorporates the first OneNet-provided component, the OneNet Connector.
• Top layer: Referred to as the OneNet Framework, this layer constitutes the core of the OneNet Architecture, providing the central functionalities and governance for the ecosystem.
Onenet framework
The OneNet Framework is designed to achieve three primary objectives:
• Enable cross-border participation of stakeholders at all levels, ranging from TSOs and DSOs to small consumers and large producers.
• Support integration and cooperation of platforms for cross-platform market operations and network services.
• Provide secure and trusted access to data from diverse sources, while ensuring data ownership, privacy, and controlled usage.
Within the OneNet Framework, two systems (OneNet Participants) can exchange data directly with one another without relying on intermediaries. Any energy stakeholder can join the OneNet Ecosystem through the OneNet Middleware and OneNet Connector. In addition, the framework includes supporting components to facilitate the implementation of data-space–enabled solutions, namely the OneNet Orchestration Workbench and the OneNet Monitoring and Analytics Dashboard.
Onenet middleware and onenet connector
The OneNet Middleware, together with the OneNet Connector, is essential for implementing the Decentralized data exchange, ensuring the scalability of the system and, most importantly, that data is exchanged between OneNe participatns in a p2p manner, without third-party actors involved.
The OneNet Middleware plays a key role for implementing all those functionalities of the OneNet Framework, which cannot be decentralized.
In fact, even if, thanks to OneNet Connector, the actual data exchange the data access management as well is performed at system level, some of the features must be implemented in a central instance, for ensuring:
• Registration and Identification of the OneNet Participants
• Creation and discovery of data sources on the Data Catalogue
• Definition and exploitation of semantic vocabularies for data models standardization
• Access to external data services
A basic schematic decentralized approach is described in
Figure 9 below, where after the registration and the data discovery, the OneNet Participants are able to manage the data access and the data exchange whenever they deem appropriate, without the necessity to pass any time for the central middleware instance.
Figure 9. Architecture of the OneNet Connector.
The OneNet Connector represents a core building block for the implementation of a decentralized Energy Data Space, designed to ensure data interoperability, sovereignty, and trust, while simultaneously enabling value creation from data. It facilitates decentralized data exchanges within the OneNet ecosystem as a plug-and-play solution at the platform level, allowing for straightforward platform integration into the OneNet Data Space while preserving data ownership and controlled access to data sources.
The OneNet Connector builds upon two well-established implementations of data space components: the IDS-based Connector and the Fiware NGSI-LD Context Broker.
The IDS Connector, as defined in the IDS Reference Architecture Model (RAM),15 guarantees that data providers and consumers can reliably verify the identity of ecosystem participants across different security domains. The IDSA framework provides several architectural components essential for creating trusted and sovereign data spaces, with trust and data sovereignty being among the most critical. While these elements are necessary, they alone are insufficient for establishing fully functional, market-adopted data spaces; standard APIs, standardized data models, and marketplace functionalities are also required.
The Fiware Context Broker [ref], adopted in 2019 as part of the Connecting Europe Facility (CEF) program, has demonstrated seamless integration with other relevant CEF Building Blocks (e.g., eIDAS, EBSI) for the creation of Data Spaces,16 enabling alignment between these initiatives. The integration of FIWARE and IDSA ensures coordinated contributions from both ecosystems to the success of data spaces and supports the OneNet implementation, relying on an open-source IDS architecture built on Fiware enablers, fully compatible with Fiware architectural principles.
From the implementation point of view the OneNet Connector, inherits from the IDS based TRUE Connector17 all the core functionalities for implementing the IDS core services and extends them with a more mature and rich architecture, extending it with Fiware-based components for data exchange, standardized interfaces (GUI and APIs) for a seamless integration and additional data services. The OneNet Connector Architecture is shown in
Figure 10.
Figure 10. OneNet services.
Figure 11. OneNet Cybersecurity layer - central communication.
The OneNet Connector provides additional data services built upon IDS specifications and guidelines. Within the IDSA framework, two key components focused on data management are particularly relevant: the Clearing House and the Usage Control App.
The Clearing House functions as an intermediary that records all activities occurring during data exchanges within the IDS ecosystem, offering clearing and settlement services for both financial transactions and data exchanges.
The Usage Control App enables the definition and enforcement of usage policies. Each Data Owner or Data Provider can attach usage control policies to their outbound data, ensuring that IDS participants can trust their data will be handled in accordance with the specified usage policies.
In the OneNet Connector implementation, the Clearing House and Usage Control App are closely integrated. Following IDS specifications, the Clearing House ensures that both Data Providers and Data Consumers comply with their contractual obligations, such as:
• The Data Provider sharing data with the Data Consumer according to Usage Contracts and Data Usage Policies defined.
• The Data Consumer using data according to Usage Contracts and Data Usage Policies defined.
For every data exchange transaction, the OneNet Connector facilitates contract negotiation between the Data Provider and the Data Consumer – covering aspects such as data access, usage restrictions, and validity periods – while logging all authorized transactions to ensure that data sovereignty is fully maintained.
5.3 Cross platform services and business objects (CIM)
Cross-platform services
To guarantee that system requirements are both technically feasible and broadly adopted, it is essential to employ internationally recognized standards for file formats, metadata, vocabularies, and identifiers.
The “Cross-Platform Access” pattern is crucial for an interoperable ecosystem. This pattern allows an application to access services or resources from multiple platforms through a single interface. For example, a “grid monitoring” application can gather data from different platforms that measure or estimate grid states. The challenge lies in enabling applications or services on one platform to interact with relevant services or applications on other platforms, possibly from different providers, using the same interface and data formats. This approach facilitates the reuse and composition of services and the easy integration of data from different platforms.
A variety of services from past and ongoing H2020 projects and the OneNet demo clusters were mapped consistently to create a list of services for the OneNet framework. These services received the name of cross-platform services and were developed considering different roles and actor designations. A step-by-step harmonization process took place to map all possible roles to the Harmonized Electricity Market Role Model (HEMRM) and BRIDGE Roles.
Based on the established concept for cross-platform services, and following the reduction of redundancy through data filtering and merging, approximately 60 services were identified and organized into ten categories of cross-platform services. Each category specifies the associated actors (roles), data producers (senders), and data consumers (receivers). For practical implementation, a refined sub-list of cross-platform services was developed, aligned with the demonstrator’s SUCs, in which OneNet was explicitly designated as an actor responsible for data exchange.
Figure 10 presents the identified service categories (shown at the bottom of the figure), supported by OneNet System Services and products, while
Table 3 provides the service categories along with a brief description of each.
Table 3. Categories of cross-platform services.
| No | Category Name | Description |
|---|
| 1 | Authentication & Authorization | Activities related to cross-platform authentication and authorization. This category is different from the other categories of cross-platform services, since it specifies cross-domain services for authentication and data access policies. |
| 2 | Measurements & Monitoring | Exchanging measurements or other data related to monitoring, e.g., state estimation results |
| 3 | Forecasts | Exchanging forecast of any kind |
| 4 | Reports & invoices | Activities related to reporting or invoicing of system or other services, incl. Reporting energy/flexibility settlement |
| 5 | (Flexibility) Market participation | Activities related to participation in market, e.g., sending bids, market clearing etc. |
| 6 | Grid models | Exchange of grid models, for example for grid reconfiguration |
| 7 | Simulation results | Exchange of simulation results, for example power flow results |
| 8 | Resource (pre-)qualification | Activities related to the (pre-) qualification of resources, incl. Qualification of product’s/service’s technical parameters |
| 9 | System service activation | Ask system operator to activate/start certain system service |
| 10 | Resource control | Sending set points to assets/flexibility sources etc. |
Potential of the technical solution to improve interoperability
A promising strategy for enhancing interoperability involves the development of Data Exchange Platforms (DEPs), which can operate in cloud environments to enable seamless machine-to-machine communication among diverse stakeholders, including Distribution System Operators (DSOs) and Transmission System Operators (TSOs). These DEPs act as bridges between on-premises data lakes, connecting them via a set of standardized APIs. Communication middleware can be utilized to link external entities to the operational layers of each DEP through REST APIs or the OneNet Connector. Data transfers may use formats such as JSON or XML, depending on the requirements of the specific System Use Case (SUC).
The structure, fields, and data types to be exchanged must be agreed upon by all participating parties. Interoperability can be further strengthened through the use of the OneNet Connector’s standardized interfaces, which provide clearly defined service categories and explicit data models, formalized through a semantic definition interface. This approach ensures that data exchange processes are consistent, reliable, and scalable, enabling broader functional and business capabilities across the energy data space.
5.4 Cyber security considerations
The mission of OneNet is to establish a new digital ecosystem for the deployment of grid services, enabling the full exploitation of demand response, storage, and distributed generation, while ensuring fair, transparent, and open conditions for consumers. To safeguard the cybersecurity of this ecosystem, a stepwise approach was adopted during the design and development of the OneNet digital ICT platform. A comprehensive analysis of potential societal, ethical, legal, and business concerns was conducted in relation to the OneNet architecture and its operation.
Guided by the IDSA security and privacy principles for trustworthy data management, the OneNet Data Governance Framework incorporates a Data Security building block under the Data Access pillar, addressing the data security requirements essential for cross-stakeholder governance. In line with the European Interoperability Framework – which recommends establishing a common security and privacy framework for cross-stakeholder data exchange – the OneNet System implements a dedicated cybersecurity layer to ensure, at every level, that:
• Apply “know-your-data-user” principle, ensuring that data owners can easily access comprehensive information on how their data is being used, at no cost.
• Harmonise authentication and authorization schemes, aligning security mechanisms across Europe and sectors to provide consistent and interoperable access control.
Figure 12 and
Figure 13 show how the OneNet Cybersecurity layer intervenes both in the central communication with the OneNet system and at any data exchange between OneNet Participants, within the OneNet Connector.
Figure 12. OneNet Cybersecurity layer - data exchange.
Figure 13. OneNet Cybersecurity layer intervenes both in the central communication with the OneNet system and at any data exchange between OneNet Participants, within the OneNet Connector.
A central element of the OneNet Architecture is the OneNet Decentralized Middleware, which supports the regulated management and exchange of information within a governed administrative framework. It is responsible for functions such as user administration, centralized metadata brokering, and the recording of all transactions for audit and compliance purposes. Importantly, the middleware neither accesses nor transmits the data shared among OneNet participants, thereby ensuring that data providers retain full sovereignty and control over their information.
The OneNet Decentralized Middleware coordinates core processes including identity management, data cataloguing, data quality assurance, transaction logging, and access control. The OneNet Connector represents a deployable instance of this middleware and, once integrated into the platforms of individual OneNet participants, enables the establishment of a trusted pan-European data space for the electricity sector with a focus on flexibility procurement and utilization. The design and implementation of the OneNet Connector address both functional and non-functional cybersecurity requirements, in accordance with the NISTIR 7628 standard:
-
SG.AC Access Control:
The OneNet Connector follows a predefined access control framework in which permissions are established through user registration within the Identity Management system and the configuration of specific access rules via a dedicated graphical user interface. This approach ensures that system resources are made available exclusively to duly authorized users.
-
SG.AU Audit and accountability:
For each data exchange that takes place, the corresponding audit and logging records are captured within the Clearing House in accordance with the IDS Reference Architecture.
-
SG.CA Security assessment and authorization
: To gain access to the OneNet ecosystem, participants are required to deploy the OneNet Connector locally and ensure the provision of appropriate SSL certificates, which are registered within the OneNet Middleware. Following deployment, users are assigned to each Connector and corresponding institution. This process is iterative and continues throughout the development phase until finalization.
-
SG.CM Configuration management:
This process has already been established within the GitHub environment and applied consistently from the initial to the final middleware versions. All configuration modifications are transparently tracked through version control, and every update or patch undergoes comprehensive testing prior to deployment in the production environment. Deployed Connectors at demonstration partner sites are notified of new versions through their user interfaces, in coordination with the central Middleware.
-
SG.CP Continuity of operations:
This requirement is fulfilled through the peer-to-peer decentralized design underpinning the entire data exchange process. The combination of decentralized execution of data transactions and centralized logging of all exchanges within the OneNet Middleware effectively satisfies this requirement.
-
SG.IA Identification and authentication:
Every user accessing the system is uniquely identified and verified (Keycloak IDM).
-
SG.ID Information and document management:
Every outside participant is identified and can access the system by the same access control schema. No specific SG.ID Information and document management process is in place though.
-
SG.IR Incident response:
Non-applicable as it is covered by the OneNet Dashboard.
-
SG.MA Smart grid information system development and maintenance:
A complete maintenance plan will be developed as part of the final Interoperable Network of Platforms version.
-
SG.MP Media protection:
Data exchanges occur exclusively between Data Producers and Providers, with no other parties able to initiate or interfere in these operations. Access to the physical media is restricted solely to designated administrators.
-
SG.PE Physical and environmental security:
Not applicable, as physical and environmental access fall outside the scope of the middleware’s functionality and are instead governed by the deployment procedures and the security protocols of the respective stakeholders for local installations.
-
SG.PL Planning:
See SG.CP Continuity of operations (above).
-
SG.PM Security program management:
Part of the project cybersecurity implementation and management aspect.
-
SG.PS Personnel security:
As defined in SG.PM Security program management methodology (above).
-
SG.RA Risk management and assessment:
As defined in PM Risk Management process.
-
SG.SA Smart grid information system and services acquisition:
According to the SG.CA Security Assessment and Authorization, all new users are permitted to freely access, deploy, and test the OneNet Connector. Participation in the OneNet data ecosystem, however, requires formal registration with the OneNet Middleware.
-
SG.SC Smart grid information system and communication protection:
See SG.PM Security program management.
-
SG.SI Smart grid information system and information integrity:
The entire OneNet Middleware operates on the foundational principles of security, trust, integrity, and data sovereignty. Consequently, maintaining the integrity of sensitive data is a fundamental priority. Assurance that such data have not been altered or deleted in an unauthorized or undetected manner is ensured through the service provisioning process and formal registration, supported by the contractual agreement established between the data producer and consumer.
6. Conclusions
The vision of OneNet for a pan-European electrical system with an open access of all actors and platforms to enable seamless integration and flexibility exploitation is based on three main aspects: harmonization, interoperability, and the implementation of the OneNet Framework.
6.1 Harmonization
In terms of harmonization, this work differentiates between product harmonization and market design. Regarding the former, harmonized products increase market participation and support coordinated markets by offering value across multiple services, and harmonization should apply to both existing and new products, especially in areas like congestion management and voltage control. Establishing common terminology and classification of attributes is necessary to support effective harmonization.
Harmonization is a gradual process, considering varying maturity and liquidity levels of local DSO and national TSO markets. Product design should adapt to kick-start local markets while maintaining a long-term vision for harmonization across all market segments.
It turns out, harmonized product design is essential for developing flexibility markets, enhancing market efficiency, and facilitating European market integration. Consistent and coherent product design maximizes value and integrates new products with existing ones. However, the support of policymakers, NRAs, and system operators is crucial, as they play a key role in driving market evolution and fostering cross-border cooperation through harmonized products. Here, a common EU approach to flexibility products can overcome barriers related to infrastructure and market maturity, while balancing local needs and harmonization goals.
In the context of harmonized market design, we differentiate between prequalification procedures, baselining, and market clearing. Harmonising prequalification is essential for streamlining operations and promoting market liquidity. Prequalification procedures should be scalable for different market structures and sizes. The study showed that harmonised products facilitate harmonised prequalification, and also that efficiency improves if prequalification is closer to the trading phase. Furthermore, streamlined processes for SPs connected to DSO and TSO networks are necessary. Regulatory frameworks should be adaptable to field adjustments.
Recommendations support harmonised baselining design among EU countries, however unique solutions are challenging due to diverse market setups across Europe. Submeters are expected to improve baseline calculations, but require acceptance and guarantees. In future works, innovative baseline methodologies should be explored to establish a flexibility register operator.
In terms of market clearing, technical entry barriers should be reduced, timely market results should be ensured and free bidding should be allowed in activation markets. Free bids in activation markets can reduce market concentration and lower prices. However, simplified, transparent, and open market clearing designs are recommended, despite potential gaming concerns.
6.2 Interoperability
The work within the project showed that interoperability a key to innovation and development and the integration of all stakeholders into the energy system to fully exploit the potential flexibility in the grid. Especially in the European context, where the solutions applied by stakeholders such as small DSOs often reflect regional and geopolitical specifics and have been developed based on proprietary solutions, it is usually not recommended to induce the transition to a common solution due to the expected financial burden, the time and cost for implementation and integration, which could cause significant limitations to smaller utilities. Here, interoperability should be rather enabled by unified requirements for all solutions, systems and platforms to be able to exchange data and information. However, the need for standardization has been pointed out in several use cases, especially regarding the use of CIM/CGMES standards (IEC 61970–600-1 and IEC 61970–600-2). As those standards have been widely accepted and provide a solid foundation for data exchange within the energy domain, CIM should be extended by the requirements for data exchange among DERs and system operators, including real-time data such as setpoints and schedules.
In terms of systemic interoperability for the future energy grids, the main recommendations are:
- Harmonization of processes and protocols to improve the compatibility across systems, process standardization
- Cybersecurity and privacy: implementation of measures and policies to protect sensitive data and systems and guarantee user data confidentiality
- Technological enablement and exploitation: development of scalable and replicable solutions developed to facilitate the implementation in different circumstances and environments and conform to local specifics in different countries
- Stakeholder participation and coordination: Support the interaction and collaboration among all actors and stakeholders
6.3 Implementation
The technical implementation of the OneNet Framework as an enabler for digitalization for the energy sector supports the cooperation and coordination of Energy Stakeholders at any level, leveraging on the concept of Data Space. In fact, the OneNet Framework is one the first completely open-source solutions, that implements the key building blocks for implementing the first concept of European Energy Data Space.
The Framework offers not only technology enablers like OneNet Middleware and OneNet Connector but also key elements for interoperability and standardization mechanisms providing a rich cross-services vocabulary hub for implementing several market and grid services.
The main advantages of the Framework are:
- Completely open-source solution submitted under the Linux Foundation Energy (LFE) Community
- Flexible Framework Open to all Energy Stakeholders
- Implementation of Vocabulary Hub for “Standardised” processes & data services
- Fully decentralized One-to-One secure data exchange
- Standardized interfaces (GUI and open APIs) for facilitating configuration, integration and deployment
- Validated in a relevant set of use cases, including cross-countries scenarios
The methodology for the definition of the Cross-Platform Services and their associated Business Objects, along with a repository containing around 60 such services and their data schemas, can be used to significantly enhance domain-specific interoperability.
6.4 Data spaces
In the context of data spaces, the analysis shows that the multiple changes in the energy sector (e.g., the transition from unidirectional to multidirectional power flows, the increased amount of volatile renewable energy, and the inclusion of new actors and roles) require more control and more data collection and data processing. Data sharing has some current open issues: data formats, access, privacy and cyber-security. Data Spaces seems to be a promising alternative to solve these issues. Here, OPEN DEI defined four key principles: data sovereignty, data level playing field, decentralized soft infrastructure and public-private governance. One key aspect for data spaces is the interoperability, addressed in three different aspects: technical, semantic and governance interoperability. The project int:net addresses interoperability in energy and it coordinates the Energy Data Space Cluster Projects (EDSCP), composed by several EU projects. EDSCP has proposed an implementation architecture for energy data spaces, which supports the implementation of several business use cases.
Cybersecurity
In the context of cybersecurity, the growing decentralization and digitalization of the energy system necessitate a structured and systematic approach to security protection. Within OneNet, the NISTIR 7628 guidelines were identified as the most pertinent reference for addressing smart grid information system security requirements. To support this, OneNet has developed and deployed the Monitoring and Analytics Dashboard GUI, which processes and indexes collected logs, applies machine learning-assisted anomaly detection, and aggregates and visualizes both historical and real-time data. The OneNet cybersecurity layer offers detailed insights into Connector usage patterns, enabling the rapid identification of anomalies and potential malicious activities.
Ethics and consent
Ethical approval and consent were not required.
