EDDIE Architecture

Appearance

Alignment with the Grant Agreement

TODO

  • Move to an appendix section over solution strategy?
  • Keep outside the EDDIE Framework system and also compare Marketplace and AIIDA?

This page aims to describe the journey from the initial project specification towards the implemented architecture by relating the methodology outlined in the Grant Agreement (Part B, Section 1.2, Pages 11–25) to the documented architecture.

For those familiar with the Grant Agreement or early publications, it might serve as an improved point of entry towards the current state of the EDDIE Framework. Others may find in it a more coherent view on architectural drivers and functional requirements. Please note that the Grant Agreement is not a public document and therefore not shared with this documentation. If you have access to the Grant Agreement, this section uses the same diagrams and headlines for an easy comparison.

With its methodological structure, this page can be read as a historical companion to the solution strategy.

EDDIE core components ​

The following diagram shows the most important parts and actors of EDDIE as laid out by the Grant Agreement.

Comparing this diagram to the updated version below, one can see that each existing component maps nicely to a specific concept implementing its envisioned functionality.

The most notable adaptation is the implementation of the Data Streaming Infrastructure and Interoperable Communication Layer through the concepts of Outbound Connectors and Region Connectors. Both Outbound Connectors and Region Connectors are implemented using a plugin architecture, where each plugin supports a specific data exchange protocol or energy data provider. Outbound Connectors and Region Connectors do not communicate directly, but use a separate component as a mediator.

Another notable change is the column on the right where the EDDIE Framework uses specialized software to tackle specific problems.

  • System monitoring is done separate from the admin console and handled by an existing software solution.
  • Authentication, authorization, and user management are delegated to a configured Keycloak instance and no longer stored in the shared database.
  • The shared database is configured to track process states and configuration for region connectors, as well as metrics for the admin console. It does not include authentication information.

The Grant Agreement also highlights how the EDDIE Framework can be installed with a single command through the use of scripted deployment configurations and provides the following diagram describing three deployment options. All these options can be achieved by configuration of the EDDIE Framework as described in the Operation Manual. Details on the deployment of the EDDIE Framework are found in its Deployment View.

Functionality provided by the EDDIE Framework ​

To demonstrate the functionality of the EDDIE Framework, the Grant Agreement describes a scenario of four stages. This section highlights how these descriptions differ from the implemented architecture. An updated collection of use-cases can be found in the Runtime View of the EDDIE Framework.

Installation and setup ​

TODO

We are not yet sure if we can or even want to support the onboarding/configuration of region connectors through the admin console.

service provided by the eligible party the specification of the data was termed a data need.

From the perspective of the eligible party, the acquisition of data begins with the definition of a data need in the admin console.

Consent Facade -> Permission Facade

Multistep Form

Manage active consents ​

Admin Console

Data transfer ​

Termination and revocation ​

Kafka ​

From the Grant Agreement:

For the purpose of our project, it will account for the management of [1] in-house data streams (flowing in from AIIDA) as well as [2] online data streams (from MDAs and online near real-time data-sharing infrastructures) and the combination of the two, and also [3] the communication between different EDDIE Framework applications.

  1. AIIDA communicates with EDDIE via MQTT.
  2. Region connectors communicate with MDAs using their preferred (usually only) option. TODO: Check with Flo
  3. EDDIE Framework applications communicate using a suitable option. EDDIE ↔ Admin via HTTP/REST Outbound Connectors ↔ Core ↔ RCs via Flux (TODO: Link architectural decision)

Despite not being used in its originally intended contexts, Kafka is still available as an option for data streaming towards the eligible party. Kafka Outbound Connector -> TODO: Link Framework Docs?

TODO: Link architectural decision