The energy data space that OMEGA-X is developing builds on the foundation of the reference architectures of Gaia-X, IDSA and DSBA. An architecture conveys fundamentals concepts and properties of a system, specifying its elements, their functions, their interrelation with each other and with the environment, as well as the principles of the system’s design and evolution.
The ambition of OMEGA-X project is to leverage the work of existing initiatives such as Gaia-X, International Data Spaces Association (IDSA) and the Data Spaces Business Alliance (DSBA) and create a design guaranteeing compliance and interoperability among energy data spaces, as well as enabling data sovereignty, trust and data value creation.
Towards this, while designing the architecture of the project, we have leveraged the work of granular specifications provided by Gaia-X Federation Services (GXFS) and IDSA Reference Architecture Model (RAM 4.0) as well as high level ones such as the DSBA Technical Convergence report (v2). We have adopted the methodology of IDSA RAM, which models five layers to a data space architecture:
- Business Layer: specifies and categorizes the different roles of the participants, and the main activities and interactions assumed by these roles.
- Functional Layer: defines the functional requirements of the data space & concrete features to be derived from these.
- Process Layer: specifies the interactions (dynamic view) taking place between the different components of the data space
- Information Layer defines a conceptual model describing both static and dynamic aspects of data space’s constituents.
- System Layer is concerned with the decomposition of the logical software components, considering aspects such as integration, configuration, deployment, and extensibility of these components.
On the other hand, for defining the architecture of OMEGA-X a key design consideration we adopted is re-using existing work from data spaces initiatives, hence an alignment with the components specified in Gaia-X architecture was sought whilst a mapping of the components to other implementations (e.g. IDSA) was created at the same time. The work on designing the systems layer (high-level view) has converged to the graphic presented in the following figure. The design is divided into four main sections:
- the Data & App Marketplace, which acts as the main “entry” point for end-users in the data space, through its graphical user interface;
- Federated Infrastructure, providing the mechanisms for secure and sovereign data exchanges;
- the Connectors enabling data exchanges and service provision;
- Compliance Services enabling Trust and Interoperability.
Additional design consideration captured during this initial phase of the project are the following:
- Gaia-X implementations such as the Gaia-X Digital Clearing House (GXDCH) can facilitate achieving compliance with Gaia-X and facilitate data space creation.
- There is a variety of available data space connectors, which provide the core operations of a data space. In the case of OMEGA-X, the Eclipse Dataspace Connector can act as a baseline solution for the project, since it fosters compliance to both IDS and Gaia-X.
- OMEGA-X envisions interoperability not only at the level of data space components but also at the level of smart energy business services. Therefore, the collaboration with other projects will be sought for a common Vocabulary Hub, enabling the semantic and syntactic representation of the energy services domain data.
- There is flexibility on whether to follow decentralized vs. centralised operation of data space components and services, however a decision should be made on what would be the supporter operation.
A final conclusion from this first iteration of OMEGA-X architecture, is that there still work to be done on providing clear guidelines enabling the establishment of interoperable data space architectures and compatible with Gaia-X and IDSA initiatives. There is complementarity on the scope of each initiative (e.g. service offerings in Gaia-X vs data in IDSA) but there is also overlap (e.g. data contracting) and in some occasions conflicts (e.g. security).