Zum Hauptinhalt springen

Energiegemeinschaften

Was sind Energiegemeinschaften?​

Energiegemeinschaften sind kollaborative Organisationen, in denen Bürger, lokale Unternehmen und weitere Beteiligte gemeinsam in erneuerbare Energie investieren sowie diese erzeugen, verwalten und verbrauchen. Diese Gemeinschaften stehen für einen grundlegenden Wandel von zentralisierten Energiesystemen hin zu einem dezentralen, demokratischen Energiemanagement.

Wesentliche Merkmale​

Lokale Energieerzeugung und -verbrauch Mitglieder erzeugen erneuerbare Energie (typischerweise Solar-, Wind- oder Wasserkraft) und teilen sie innerhalb der Gemeinschaft. Energie wird dort verbraucht, wo sie erzeugt wird, wodurch Übertragungsverluste und Netzabhängigkeit reduziert werden.

Gemeinschaftliches Eigentum Die Mitglieder der Gemeinschaft besitzen oder pachten Anlagen zur Energieerzeugung gemeinsam. Demokratische Entscheidungsfindung stellt sicher, dass alle Mitglieder bei den Aktivitäten der Gemeinschaft ein Mitspracherecht haben.

Energie-Sharing Überschüssige Energie eines Mitglieds kann mit anderen in der Gemeinschaft geteilt werden. Dadurch entsteht ein lokaler Energiemarkt mit optimierter Verteilung auf Basis von Angebot und Nachfrage in Echtzeit.

Netzunabhängigkeit Obwohl sie für die Absicherung weiterhin mit dem Hauptnetz verbunden sind, streben Gemeinschaften eine maximale Eigenständigkeit an. Überschüssige Energie kann an das Netz zurückverkauft werden, wodurch zusätzliche Einnahmequellen entstehen.

Vorteile​

  • Wirtschaftlich: Niedrigere Energiekosten durch gemeinsame Verhandlungsmacht und geteilte Infrastruktur
  • Ökologisch: Verstärkte Nutzung erneuerbarer Energie und reduzierter CO₂-Fußabdruck
  • Sozial: Gestärkter Gemeinschaftszusammenhalt und lokale Wirtschaftsentwicklung
  • Resilienz: Erhöhte Energiesicherheit und geringere Abhängigkeit von externen Anbietern

Regulatorischer Rahmen​

Energiegemeinschaften agieren innerhalb bestimmter regulatorischer Rahmenbedingungen, die je nach Region variieren. In der EU sind sie im Rahmen des Clean Energy Package anerkannt, das Folgendes definiert:

  • Renewable Energy Communities (RECs)
  • Citizen Energy Communities (CECs)

Diese Rahmenbedingungen begründen Rechte für Energie-Sharing, Netzzugang und faire Behandlung im Energiemarkt.

Technische Anforderungen​

Der Betrieb einer Energiegemeinschaft erfordert ein anspruchsvolles Datenmanagement für:

  • Echtzeitüberwachung von Energieerzeugung und -verbrauch
  • Abrechnung und Verrechnung der Mitglieder
  • Management der Netzinteraktion
  • Berichterstattung zur Einhaltung regulatorischer Vorgaben
  • Verfolgung der Anlagenleistung

Hier liefert die Data-Mesh-Technologie von OctoMesh die strukturierte Datengrundlage, die erforderlich ist, um diese komplexen, vernetzten Systeme effektiv zu verwalten.

Lösungsarchitektur mit OctoMesh​

Systemüberblick​

Die OctoMesh-Plattform dient als zentrale Datendrehscheibe zur Verwaltung von Energiegemeinschaften, integriert sich mit externen Systemen und stellt Benutzeroberflächen für verschiedene Beteiligtengruppen bereit.

Wesentliche Komponenten​

1. Externe Integrationen​

EDA-Integration über Ponton X/P KEP

  • Bidirektionale Kommunikation mit der Plattform für den Austausch von Energiedaten
  • Verarbeitung von EDIFACT/XML-Nachrichten
  • Automatisierte Verarbeitung von Status- und Fehlermeldungen

Excel-Import

  • Funktionalität zum initialen Import von Stammdaten
  • Stapelverarbeitung für Teilnehmer- und Zählpunktdaten
  • Validierung und Fehlerbehandlung

2. OctoMesh-Kernplattform​

Construction Kit

  • Objektorientierte Datenmodellierung (Klassen, Vererbung, Attribute, Assoziationen)
  • Unterstützung für einfache Datentypen (Zeichenketten, Zahlen, boolesche Werte) und komplexe Records
  • Versionsverwaltetes Schema-Management

Business-Logic-Schicht

  • Algorithmen zur Energiezuteilung
  • Abrechnungsberechnungen
  • Regeln zur Einhaltung regulatorischer Vorgaben

API-Schicht

  • RESTful-APIs für die Anwendungsintegration
  • Ereignisgesteuerte Architektur für Echtzeit-Aktualisierungen
  • Handhabung von Sicherheit und Authentifizierung

3. Benutzeranwendungen​

Verwaltungsanwendung für Energiegemeinschaften

  • Vollständige Stammdatenverwaltung
  • Erfassung und Zuteilung von Energiemengen
  • Abwicklung von Abrechnung und Verrechnung
  • Überwachung und Verarbeitung von EDA-Nachrichten
  • Berichtswesen und Analysen

Teilnehmerportal

  • Self-Service-Zugang für Mitglieder der Gemeinschaft
  • Persönliche Ansichten zu Energieverbrauch/-erzeugung
  • Abrechnungshistorie und Abrechnungen
  • Zugriff auf Dokumente

Datenarchitektur​

Die Lösung verwaltet vier primäre Datendomänen:

  1. Stammdaten: Zentrale Informationen zu Teilnehmern und Infrastruktur
  2. Energiedaten: Messwerte zu Erzeugung, Verbrauch und Netzeinspeisung
  3. Abrechnungsdaten: Finanztransaktionen und Verrechnungen
  4. Kommunikationsdaten: EDA-Nachrichten und Systembenachrichtigungen

Datenmodell und Messdaten​

Dieser Abschnitt beschreibt, wie die EnergyCommunity-Lösung Stammdaten und Messwerte in OctoMesh speichert. Das praktische Gegenstück ist das Tutorial Energiedaten verstehen.

Construction Kits​

Die Lösung baut auf drei Construction-Kit-Bibliotheken auf:

BibliothekInhalt
BasicAllgemeine Bausteine: benannte Entitäten, Baumknoten, Adressen, Kontakte, Zeiträume, Mengen
Basic.EnergyEnergiedomäne: OperatingFacility, der abstrakte MeteringPoint mit Consumer und Producer, EnergyMeasurement, die Enums DataQuality, ProductionType, CarrierType
EnergyCommunityGemeinschaftsspezifische Typen: Customer, Consumer und Producer mit Teilnahmeattributen, ParticipationPeriod, EnergyPrice, Abrechnungsdokumente, CommunitySettings
  • Ein Kunde (Mitglied der Gemeinschaft) besitzt eine oder mehrere Anlagen (ein Haushalt, ein Betriebsstandort, eine PV-Anlage).
  • Eine Anlage hat einen oder mehrere Zählpunkte. Ein Verbraucher-Zählpunkt misst die aus dem Netz bezogene Energie, ein Erzeuger-Zählpunkt die ins Netz eingespeiste. Die Zählpunktnummer ist die 33-stellige Kennung des Netzbetreibers (in Österreich AT…).
  • PartitionFactor (1–100 %) ist der Anteil des Zählpunkts, der an dieser Gemeinschaft teilnimmt; ein Zählpunkt kann an mehreren Gemeinschaften teilnehmen.
  • Teilnahmezeiträume geben an, von wann bis wann ein Zählpunkt zur Gemeinschaft gehört.
  • Eine Energiemessungs-Entität ist der Anker einer Zeitreihe: ein Anker pro Zählpunkt und Register (OBIS-Code). Ihr Well-known Name ist <meteringPointRtId>_<obisCode>. Die Werte selbst werden als Stream Data gespeichert, nicht an der Entität.

Die vollständige Typreferenz finden Sie unter EnergyCommunity-4 und Basic.Energy.

Zählerregister (OBIS-Codes)​

Jeder Wert trägt einen OBIS-Code, der angibt, was gemessen wurde. Die Richtung steckt im Code (1.9.0 = aus dem Netz bezogen, 2.9.0 = eingespeist bzw. innerhalb der Gemeinschaft verteilt), nie im Vorzeichen: Alle Werte sind positive kWh pro 15-Minuten-Intervall.

RegisterZählpunktBedeutung
1-1:1.9.0 G.01VerbraucherGesamtverbrauch laut Zähler
1-1:2.9.0 G.01ErzeugerGesamterzeugung, ins Netz eingespeist
1-1:2.9.0 G.02VerbraucherNach statischem Verteilschlüssel zugewiesener Anteil (kann über dem Verbrauch liegen)
1-1:2.9.0 G.03VerbraucherEigendeckung: aus der Gemeinschaft gedeckte Energie; das ist die Menge, die die Gemeinschaft abrechnet
1-1:2.9.0 G.01TErzeugerDer Gemeinschaft angebotene Erzeugung (Erzeugung × Teilnahmefaktor)
1-1:2.9.0 P.01TErzeugerTeil der angebotenen Erzeugung, der nicht verteilt wurde (Überschuss)

Abgeleitete Größen werden nicht gespeichert, weil sie sich aus den Registern ergeben:

  • Restbezug vom Lieferanten: 1.9.0 G.01 − 2.9.0 G.03 je Verbraucher.
  • Von einem Erzeuger verteilte Energie: G.01T − P.01T.
  • Bilanz je 15-Minuten-Slot: Σ G.03 (Verbraucher) = Σ (G.01T − P.01T) (Erzeuger).

In einer Gemeinschaft, die vom Netzbetreiber versorgt wird, kommen die Register über EDA-Verbrauchsdatensätze. In einer Gemeinschaft ohne EDA (selbst gemeldete oder simulierte Zählpunkte) berechnet die tägliche Verteilung G.03, G.01T und P.01T aus den Rohregistern 1.9.0 G.01 und 2.9.0 G.01.

Datenqualität​

Jeder Wert hat eine Datenqualität (Enum Basic.Energy/DataQuality):

WertBedeutung
L1Gemessener 15-Minuten-Wert
L2Lineare Interpolation zwischen zwei bekannten Zählerständen
L3Schätzwert (wird auch für fehlende Werte in der Verteilung verwendet)
ManualVon einer Benutzerin oder einem Benutzer eingegeben oder korrigiert
UnknownKeine Qualitätsinformation

Das Rohdatenarchiv löst konkurrierende Schreibvorgänge für dasselbe Intervall zuerst nach Qualität auf (der niedrigere L-Wert gewinnt) und dann nach dem Datum des Quelldokuments. Ein Schätzwert überschreibt also nie einen Messwert, und ein endgültiger Wert ersetzt einen vorläufigen. Die Abrechnung zählt nur L1 und L2; L3-Intervalle werden gesondert ausgewiesen.

Speicherung: 15-Minuten-Fenster und Rollups​

Messwerte werden in einem Time-Range-Archiv mit 15-Minuten-Fenstern gespeichert (window_start, window_end, amount.value, amount.unit, obisCode, dataQuality), eine Zeile pro Anker und Fenster. Eine Kaskade von Rollup-Archiven aggregiert sie zu stündlichen, täglichen, wöchentlichen, monatlichen und jährlichen Summen (SUM der Menge, MAX der Datenqualität). Kalender-Rollups sind an der Zeitzone Europe/Vienna ausgerichtet. Siehe Stream-Data-Archive.

Tägliche Verteilung (D+1)​

In einer Erneuerbare-Energie-Gemeinschaft wird die von Mitgliedern erzeugte Energie im selben 15-Minuten-Slot mit Mitgliedern geteilt. Der Netzbetreiber, oder OctoMesh bei Gemeinschaften ohne EDA, berechnet die Verteilung einmal täglich für den Vortag (D+1), nachdem alle Werte für Tag D gemeldet wurden:

  1. Für jeden Slot ist die angebotene Erzeugung jedes Erzeugers seine Erzeugung mal Teilnahmefaktor (G.01T).
  2. Der anrechenbare Bedarf jedes Verbrauchers ist sein Verbrauch mal Teilnahmefaktor.
  3. Mit einem dynamischen Schlüssel wird die angebotene Energie im Verhältnis zum anrechenbaren Bedarf verteilt, nie mehr als der eigene Bedarf eines Verbrauchers (G.03). Mit einem statischen Schlüssel erhält jeder Verbraucher einen festen Anteil (G.02) und wird bis zu seinem Verbrauch gedeckt.
  4. Was übrig bleibt, ist der Überschuss (P.01T), aufgeteilt auf die Erzeuger im Verhältnis zu ihrem Angebot. Er wird außerhalb der Gemeinschaft verkauft.

Die Verteilungspipeline der Lösung läuft nach einem konfigurierbaren Meldeschluss (Standard 06:00 Europe/Vienna, Einstellung CommunitySettings.AllocationCutOffTime), schreibt die Register in das Rohdatenarchiv und ist idempotent: Ein erneuter Lauf für denselben Tag erzeugt identische Zeilen. Zählpunkte, deren Daten von der EDA kommen, werden nie überschrieben, weil dort der Netzbetreiber verteilt.

Kennzahlen​

Zwei Quoten charakterisieren eine Gemeinschaft über einen Zeitraum:

  • Deckungsgrad = Σ 2.9.0 G.03 / Σ 1.9.0 G.01: der Anteil des Verbrauchs der Mitglieder, der aus der Gemeinschaft gedeckt wird.
  • Überschussquote = Σ P.01T / Σ G.01T: der Anteil der angebotenen Erzeugung, der innerhalb der Gemeinschaft nicht genutzt werden konnte.

Eine Gemeinschaft mit viel PV und wenigen Verbrauchern hat mittags eine hohe Überschussquote und abends einen niedrigen Deckungsgrad; eine Gemeinschaft mit überwiegend Verbrauchern hat eine niedrige Überschussquote und einen niedrigen Deckungsgrad.