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:
- Stammdaten: Zentrale Informationen zu Teilnehmern und Infrastruktur
- Energiedaten: Messwerte zu Erzeugung, Verbrauch und Netzeinspeisung
- Abrechnungsdaten: Finanztransaktionen und Verrechnungen
- 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:
| Bibliothek | Inhalt |
|---|---|
Basic | Allgemeine Bausteine: benannte Entitäten, Baumknoten, Adressen, Kontakte, Zeiträume, Mengen |
Basic.Energy | Energiedomäne: OperatingFacility, der abstrakte MeteringPoint mit Consumer und Producer, EnergyMeasurement, die Enums DataQuality, ProductionType, CarrierType |
EnergyCommunity | Gemeinschaftsspezifische 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.
| Register | Zählpunkt | Bedeutung |
|---|---|---|
1-1:1.9.0 G.01 | Verbraucher | Gesamtverbrauch laut Zähler |
1-1:2.9.0 G.01 | Erzeuger | Gesamterzeugung, ins Netz eingespeist |
1-1:2.9.0 G.02 | Verbraucher | Nach statischem Verteilschlüssel zugewiesener Anteil (kann über dem Verbrauch liegen) |
1-1:2.9.0 G.03 | Verbraucher | Eigendeckung: aus der Gemeinschaft gedeckte Energie; das ist die Menge, die die Gemeinschaft abrechnet |
1-1:2.9.0 G.01T | Erzeuger | Der Gemeinschaft angebotene Erzeugung (Erzeugung × Teilnahmefaktor) |
1-1:2.9.0 P.01T | Erzeuger | Teil 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.03je 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):
| Wert | Bedeutung |
|---|---|
L1 | Gemessener 15-Minuten-Wert |
L2 | Lineare Interpolation zwischen zwei bekannten Zählerständen |
L3 | Schätzwert (wird auch für fehlende Werte in der Verteilung verwendet) |
Manual | Von einer Benutzerin oder einem Benutzer eingegeben oder korrigiert |
Unknown | Keine 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:
- Für jeden Slot ist die angebotene Erzeugung jedes Erzeugers seine
Erzeugung mal Teilnahmefaktor (
G.01T). - Der anrechenbare Bedarf jedes Verbrauchers ist sein Verbrauch mal Teilnahmefaktor.
- 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. - 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.