1 Einleitung

1.1 Motivation

Die Reduzierung des C02 Ausstoßes und die damit verbundene Energiewende weg von fossilen Kraftwerken hin zu erneuerbaren Energien sind die Leitlinien der europäischen Energiepolitik (EPRS 2023, EU COM (2022) 552 Nr. 4.3). Dies zeigt sich auch an der Gesetzgebung in diesem Bereich in den vergangenen Jahren, welche von einem Gesetz zum Kohleausstieg in Deutschland (< 2035) (Kohleverstromungsbeendigungsgesetz) bis hin zu einer staatlichen Förderung von Effizienzmaßnahmen und erneuerbaren Energien reichen (Erneuerbare-Energien-Gesetz). Die Wirksamkeit zeigt sich beim Blick auf die Reduzierung des CO2-Ausstoßes von 1990 bis 2022 um 36,8 % (UBA 2023c). Bedingt wurde diese Reduktion auch durch den Zubau erneuerbarer Energien im Strommarkt, welche im Jahr 1990 19 TWh lieferten und im Jahr 2023 bereits 268 TWh (UBA 2023a). Vom durch erneuerbare Energien gelieferten Strom entfallen rund 72,8 % auf die dargebotsabhängigen erneuerbaren Energien Wind und PV (UBA 2023b). Der Zubau der erneuerbaren Energien bedingt durch die Dargebotsabhängigkeit der Energieträger und der damit verbundenen Volatilität auch einen immer weiter steigenden Ausgleichsbedarf im Netz, da Last und Erzeugung zu jedem Zeitpunkt im Gleichgewicht gehalten werden müssen, um die Netzstabilität und die Versorgungssicherheit zu gewährleisten. Die in der Vergangenheit benötigte Regelleistung wurde durch regelbare Kraftwerke auf Basis konventioneller Energieträger erbracht, was künftig durch den Umbau des Kraftwerksparks nicht mehr möglich sein wird (Agricola et al. 2014). Dies führt zur Notwendigkeit weiterer Ansätze für den Ausgleich zwischen Last und Erzeugung (Agricola et al. 2015). Mögliche Ansätze hierzu sind ein flächendeckender, kostenintensiver Netzausbau in den Verteilnetzen (100–134 Mrd. € bis 2037 (Fritz et al. 2023)) als auch eine aktive Regelung der Erzeuger und Verbraucher in den unteren Netzebenen (Agricola et al. 2014). Wird die Regelung dezentral, d. h. direkt am Ort der Entstehung des Regelungsbedarfes durchgeführt und nicht auf die höhere Netzebene übertragen, können somit die höheren Netzebenen entlastet werden (VDE 2015). Ein gesteuerter Ausgleich auf dieser Ebene erfordert Kenntnisse der momentanen Zustände und Planungen der einzelnen Netznutzer, wofür eine geeignete Infrastruktur aus Mess- und Steuergeräten (Smart Meter) notwendig ist (Agora 2018).

Der derzeit im Rollout befindliche Smart Meter kann als Bindeglied zwischen einem aktiven externen MarktteilnehmerFootnote 1, dem Netzbetreiber und dem Endkunden die notwendigen Daten bereitstellen und bringt mit den Zusatzgeräten eine Möglichkeit zur Steuerung von Anlagen und durch eine Applikationsplattform eine Möglichkeit für neue Geschäftsmodelle mit (DENA 2022). Die möglichen Geschäftsmodelle gehen hierbei von dem notwendigen Ausgleich der Last und der Erzeugung hin zu Energy Sharing Konzepten, die neben dem lokalen Ausgleich ökonomische Effizienzpotentiale aufweisen (Großjohann 2020). Die theoretische Ausgestaltung solcher Energy Sharing Konzepte ist derzeit Gegenstand mehrerer Untersuchungen (Chen und Zhao 2022). Neben Verteilungs- & Regelungskonzepten stellt sich allerdings die Frage nach den Anforderungen an solch ein Konzept in Bezug auf die Datenhaltung und die Datenverarbeitung, welche bisher nicht abschließend geklärt sind und in diesem Paper analysiert werden sollen.

1.2 Definition Use-Case

Der Funktionsumfang des echtzeitfähigen Steuersystems, das in diesem Paper betrachtet wird und in einer Smart Meter Umgebung implementiert ist, ermöglicht die Verbindung verschiedener Prosumer, die Steuerung von Anlagen über einen sicheren Controllable-Local-System (CLS) – Kanal sowie die Steuerung von industriellen Anlagen über Ethernet- und Funkschnittstellen.

Das System übernimmt auch die Funktion eines Energiemanagementsystems, das eine dynamische Regelung der Energieflüsse ermöglicht. Dabei werden verschiedene Faktoren berücksichtigt, wie beispielsweise der Grünstromindex, aktuelle Strommarktpreise, Netzbedingungen, Produktionsprogramme, Einspeisung, potenzielle Flexibilität der Anlagen, Maschinenzustand sowie die Anforderungen anderer verbundener Prosumer. Des Weiteren werden Entgeltkomponenten und Nutzergewohnheiten in das System eingebunden. Zusätzlich übernimmt dieses System die automatisierte Abrechnung der erbrachten Dienstleistungen zwischen den Teilnehmern.

Die nachfolgenden Anforderungen werden innerhalb des Use-Case an das System gestellt.

  • Datensicherheit – Hohe Anforderungen an Integrität und Vertraulichkeit personenbezogener Daten.

  • Daten‑/Aufgabenkonsistenz – Hohe Anforderungen aufgrund des Energiemengenausgleichs und der Abrechnung zwischen Teilnehmern.

  • Skalierbarkeit – Möglichst hohe Skalierbarkeit, allerdings muss dies nicht sehr dynamisch erfolgen.

  • Kosten – Aufgrund vieler erwarteter Ausgleichshandlungen und hoher zeitlicher Auflösung der Messwerte möglichst geringe Kosten.

  • Latenz – Sehr geringe Latenz für EchtzeitanforderungenFootnote 2 im System.

  • Verfügbarkeit – geringere Anforderungen da nicht sicherheitsrelevante oder keine zeitkritischen Prozesse.

  • Komplexität – mittlere Anforderung, aufgrund des breiten Anwendungsfeldes.

  • Notwendige Netzwerkbandbreite – Geringe Bandbreite, um an Standorten mit eingeschränkter Verbindung einwandfreien Betrieb zu gewährleisten.

  • Notwendige Leistung der Endgeräte – Geringe Leistungsanforderungen für Edge Devices.

2 Analyse von Konzepten für die Datenhaltung & -verarbeitung

Ein Steuersystem kann anhand des 3‑Schicht Modells in eine Logik-Schicht, eine Daten-Schicht und eine Grafik-Schicht unterteilt werden (IBM 2024). Da die Grafik-Schicht für die weitere Auslegung nicht relevant ist, wird sie hier nicht weiter betrachtet. Im Folgenden werden für die Logik- und die Daten-Schicht verschiedene Architekturen und deren und Vor- und Nachteile erläutert.

2.1 Mögliche Architekturen für Verarbeitungsschicht der Steuersysteme

Die Verarbeitung der Daten kann an unterschiedlichen Orten durchgeführt werden. Es kann sowohl zwischen zentralen und dezentralen (Hansen 1983) als auch zwischen lokalen (on-premise) und Cloud Konzepten unterschieden werden (Gonzalez 2023).

2.1.1 Lokale dezentrale Verarbeitung

Die lokale dezentrale Verarbeitung erfolgt direkt oder nahe am Ort der Datenerzeugung (Ostler 2018). Eine direkte Verarbeitung am Ort der Erzeugung ermöglicht einen direkten Zugriff auf verarbeitete Daten ohne Latenzen (Schumny 1987; Ostler 2018). Dies ist besonders nützlich für Echtzeit-Anwendungen. Beim Einsatz zusätzlicher Edge-Geräte zur Verarbeitung der Daten nahe der Erzeugung können wiederrum geringe Latenzen auftreten (Rosenberger et al. 2022). Eine direkte Verarbeitung ermöglicht eine Reduktion der Datenmenge im Netzwerk (Appius et al. 2021). Zudem kann der Informationsgehalt der Daten angepasst werden (Appius et al. 2021), was die Sicherheit gegen unbefugten Zugriff erhöht (Shi et al. 2019). Allerdings erfordert diese Methode hohe Anforderungen an Endgeräte in Bezug auf Kompatibilität mit der Infrastruktur und erforderliche Rechenleistung (Qiu et al. 2020).

2.1.2 Lokale zentrale Verarbeitung

Im Gegensatz dazu erfolgt bei der lokalen zentralen Verarbeitung die Datenverarbeitung an einer zentralen Stelle (Laural 2024). Dies reduziert die Anforderungen an Endgeräte (Rosenberger et al. 2022), da sie nur Rohdaten an diese Stelle senden müssen (Laural 2024). Allerdings führt die Übertragung aller Rohdaten (Krishnan 2013) zu einer höheren Netzwerkauslastung und einem potenziell erhöhten Sicherheitsrisiko (Kisters 2023). Zudem können Latenzen bei der Datenübertragung auftreten (Kisters 2023), was für Echtzeit-Anwendungen problematisch sein kann (Rosenberger et al. 2022).

2.1.3 Cloud-basierte Verarbeitung

Bei der Cloud-basierten Verarbeitung werden Daten an einen Cloud-Service gesendet und dort verarbeitet. Dies ermöglicht eine einfache Skalierung von Ressourcen wie Leistung und Datenspeicher in der Cloud (Hasan et al. 2012). Ähnlich wie bei der lokalen zentralen Verarbeitung benötigen Endgeräte weniger Leistung (Minnich 2017). Jedoch erfordert die Übertragung aller Daten in die Cloud eine hohe Bandbreite und birgt ein erhöhtes Sicherheitsrisiko (Minnich 2017). Zudem können die Übertragungslatenzen variieren (Todd 2019), was Echtzeitanwendungen beeinträchtigen kann (Panwar 2020).

2.2 Mögliche Datenbankschemata für die Datenschicht der Steuersysteme

Wie auch bei der Verarbeitungsschicht, ist bei der Datenschicht eine zentrales sowie ein dezentrales Konzept möglich, was im Zusammenhang mit dem Datenhaltungsmodell zu verschiedenen Eigenschaften und dementsprechend zu Vor- und/oder Nachteilen führt (Abb. 1).

Zentrale Datenspeicherung:

Bei zentralen Datenspeichersystemen wird der größte Teil der zu speichernden Daten an einem zentralen Ort abgelegt. Dabei können sich, gleich wie bei dezentralen Systemen, der Ort und die Art des Datenspeichers je nach Anwendungsfall unterscheiden (Reinfurt 2021). Beispielsweise kann ein Server on- oder off-premise, ein direkt angebundener lokaler Datenspeicher oder auch eine Cloud genutzt werden (Chouhan et al. 2015). Es wird sehr häufig eine relationale Datenbank genutzt (Gehring und Gabriel 2022).

Dezentrale Datenspeicherung:

Bei dezentralen Datenspeichersystemen erfolgt die Speicherung an mehreren Orten, die als Knoten bezeichnet werden (Posey und Sheldon 2024; Gehring und Gabriel 2022). Es gibt keine festgelegte Einschränkung bezüglich der Art der Knoten oder ihrer Verwaltung (Fill und Meier 2020). Zum Beispiel kann eine zentrale Schnittstelle genutzt werden, um die Daten auf die Knoten zu verteilen. Allerdings ist auch eine dezentrale Datenspeicherung ohne eine zentrale Verwaltung möglich (Alt 2022). In der Literatur wird dafür oft der Begriff Distributed Ledger Technologie (DLT) verwendet, zu der beispielsweise die Bitcoin-Blockchain gehört (Alt 2022).

Abb. 1
figure 1

Möglichkeiten der Datenspeicherung

Full size image

2.3 Datenhaltungsmodelle

Im Folgenden werden ausgewählte gängige Datenhaltungsmodelle als zentrale und dezentrale Variante anhand der bereits beim Use-Case definierten Kriterien untersucht. Die Unterscheidung zwischen zentral und dezentral bezieht sich auf den Speicherort der Daten und nicht den Ort der Verarbeitung.

  • Datensicherheit – Kryptografische Grundsicherheit des Systems

  • Daten/Aufgaben Konsistenz – Widerspruchsfreie Datenhaltung

  • Skalierbarkeit – Möglichkeit der Skalierung des Systems

  • Kosten – Kosten für eine Implementation

  • Latenz – Verzögerungen welche durch den Datenaufruf entstehen

  • Verfügbarkeit – Erreichbarkeit bei einem Ausfall einzelner Komponenten

  • Komplexität – Beurteilung des Aufwandes für eine Implementation und Pflege

2.3.1 Relationale Datenbank

Datensicherheit:

Die Sicherheit zentraler relationaler Datenbanken hängt stark von der DBMS-Konfiguration ab. Oft bieten sie standardmäßig geringen Schutz durch falsche Konfigurationen und Ressourcenallokationen. Unverschlüsselte Kommunikationen und übermäßige Nutzerrechte erhöhen die Gefahr bei Systemangriffen. SQL-Injections können die Systemsicherheit weiter beeinträchtigen (BSI 2021a; Bertino und Sandhu 2005).

Dezentrale Datenbanken verteilen Daten auf mehrere Knoten, was den Schaden bei unberechtigtem Zugriff verringert, erfordert aber sichere Kommunikation zwischen den Knoten (BSI 2021a).

Daten/Aufgaben Konsistenz:

Relationale Datenbanken gewährleisten Konsistenz der Datenverknüpfungen, nicht zwingend ihres Inhalts, wodurch unberechtigte Änderungen schwer zu erkennen sind (BSI 2021a).

Bei dezentralen relationalen Datenbanken müssen alle Aktionen mit allen Knoten synchronisiert werden, damit eine Daten- und Aufgabenkonsistenz vorliegt (BSI 2021a).

Skalierbarkeit:

Zentrale relationale Datenbanken haben eine begrenzte Skalierbarkeit. Vertikale Skalierung durch Hardwareaufrüstung ist bis zu einem Punkt möglich, wird jedoch zunehmend komplex und kostspielig (Anderson 2009; Stefano Marmonti 2016).

Dezentrale Datenbanken ermöglichen horizontale Skalierung, indem weitere Knoten hinzugefügt werden, was mit moderatem Aufwand möglich ist. (Anderson 2009; Stefano Marmonti 2016).

Kosten:

Die Kosten zentraler Datenbanken hängen von der Serverhardware ab, steigen zunächst proportional, später exponentiell. Die Betriebskosten sind niedrig, da sie wenig Rechenleistung benötigen (Stefano Marmonti 2016; Anderson 2009; Kumar et al. 2017).

Für einen Vergleich der Anschaffungs- & Betriebskosten eines eigenen lokalen Servers kann die Miete eines Cloud-Serverdienstes herangezogen werden. Als Beispiel kann der Provisioned Compute-Tarif für SQL-Datenbanken von Azure mit 10,2 GB Arbeitsspeicher und 2 virtuellen Prozessoren genannt werden, der monatlich 355,54 € kostet (Microsoft Corporation 2023).

Dezentrale Datenbanken ermöglichen die Verteilung der Datenknoten auf vorhandene Hardware, was Kosten senken kann (Microsoft Corporation 2023).

Latenz:

Die Latenz bei Datenbanken ergibt sich aus der Übertragungsgeschwindigkeit des Netzwerks und der Zugriffsgeschwindigkeit durch den Overhead bei der Datenbankabfrage. Diese Latenz variiert je nach Systemleistung und Abfragestruktur (Vicknair et al. 2010; Kolonko 2018).

In dezentralen relationalen Datenbanken kann die Latenz bei Datenabfragen steigen, da mehrere Übertragungen von verschiedenen Orten erforderlich sind. Bei komplett unterschiedlichen Quellen kann die Notation O(n) verwendet werden, unter der Annahme gleicher Netzwerk- und ReaktionsgeschwindigkeitenFootnote 3 der Knoten.

Verfügbarkeit:

Die Verfügbarkeit von zentralen relationalen Datenbanken beruht maßgeblich auf der VerfügbarkeitFootnote 4 der Serverkomponente, auf der sich die Datenbank befindet. Fällt diese Komponente aus, ist kein Zugriff auf die Datenbank mehr möglich.

Dezentrale Datenbanken bieten eine höhere Verfügbarkeit, da bei Knoten-Ausfall weiterhin auf andere Knoten zugegriffen werden kann, aber auch hier ist ein Datenzugriff bei DBMS-Ausfall nicht mehr möglich (Nishtha et al. 2012).

Komplexität:

Die Komplexität zentraler Datenbanken steigt mit Anzahl der Clients, Datenmenge und dynamischer Datenstruktur, was sie für Big DataFootnote 5 und schnelle Anforderungen weniger geeignet macht (Chu et al. 2015).

Dezentrale relationale Datenbanken erweiterten die bereits genannten Punkte um die Komplexität einer Kommunikationsstruktur zwischen den einzelnen Datenknoten und deren Absicherung (Nishtha et al. 2012).

2.3.2 Blockchain

Datensicherheit:

Die Sicherheit von Blockchains hängt vom gesamten Systemaufbau ab. Die Datenintegrität wird durch die Verkettung mittels Hash-Werten gewährleistet, wobei die Sicherheit der verwendeten Hash-Funktionen im Laufe der Zeit nachlassen kann (Mouha und Celi 2023). Zudem ist der Zeitpunkt der garantierten Integrität durch den Validierungsmechanismus zu berücksichtigen. In privaten Blockchains ist auf eine ausreichende Anzahl von Verbindungen zu achten (Berghoff et al. 2019).

Die Vertraulichkeit der Daten ist eine Herausforderung, da Transaktionsdaten allen Teilnehmern zugänglich sein müssen (de Haro-Olmo et al. 2020; Sanka und Cheung 2021). Im privaten Umfeld kann Vertraulichkeit durch begrenzten Netzwerkzugang und Rollen- sowie Rechteverteilung erreicht werden (Berghoff et al. 2019). Die Authentifizierung der Teilnehmer im Netzwerk erfordert ein Public-Key-Kryptosystem, da die Blockchain zwar Identitäten innerhalb des Netzwerks sicherstellt, jedoch keine Zuordnungsprüfung vornimmt (Berghoff et al. 2019).

Daten/Aufgaben Konsistenz:

Blockchains bieten eine hohe Daten- und Aufgabenkonsistenz, die über mehrere Knoten im Netzwerk gesichert ist (Salagrama et al. 2022). Es kann jedoch je nach Struktur eine gewisse Zeit dauern, bis Daten als konsistent betrachtet werden können. Zudem erfordert es eine separate Überprüfung, um Aktionen den Knoten zuzuordnen (Berghoff et al. 2019).

Skalierbarkeit:

Blockchains sind theoretisch nahezu unbegrenzt skalierbar, doch der Ressourcenbedarf, Speicherplatz und die Leistungsfähigkeit der Knoten stellen limitierende Faktoren dar. Jeder Knoten benötigt eine lokale Kopie der Blockchain und ausreichende Rechenleistung für die Validierung neuer Blöcke. Die Infrastruktur, insbesondere Netzwerk und Energieversorgung, ist entscheidend für die Skalierbarkeit. Ein größeres Netzwerk erhöht den Datendurchsatz für Validierungen (Dorri et al. 2017; Sanka und Cheung 2021).

Kosten:

Die Einführung einer Blockchain beginnt mit niedrigen Kosten, da keine spezielle Hardware wie ein Server benötigt wird. Allerdings müssen die Infrastruktur und der Energieverbrauch während des Betriebs berücksichtigt werden. Zum Beispiel war die Bitcoin-Blockchain 2023 Schätzungen zufolge für 0,4 % des weltweiten Stromverbrauchs verantwortlich (Bussac 2023). Bei der Kostenberechnung für einen Anwendungsfall sind der erhöhte Strombedarf für die kontinuierliche Verfügbarkeit, die Kühlung der Knoten, die Netzwerkbereitstellung und mögliche Speicheraufrüstungen zu beachten (Berghoff et al. 2019).

Latenz:

Durch lokale Kopien der Blockchain ist das System mit sehr geringer Latenz beim Lesen und Schreiben ausgestattet (Berghoff et al. 2019). Dennoch kann es je nach System und Validierungsmechanismus eine gewisse Zeit dauern, bis die zu schreibenden Daten für andere Knoten verfügbar sind (Neumann 2021).

Verfügbarkeit:

Blockchains bieten im Allgemeinen eine hohe Verfügbarkeit, solange jeder Knoten eine lokale Kopie besitzt (Schlatt et al. 2016). Eine größere Anzahl von Knoten im Netzwerk führt zu höherer Verfügbarkeit, selbst bei Ausfällen einzelner Knoten (Yang et al. 2020). Es ist jedoch wichtig zu beachten, dass die Verfügbarkeit nur gewährleistet ist, solange die Daten direkt in der Blockchain und nicht als Verweise gespeichert sind (Berghoff et al. 2019).

Komplexität:

Im Vergleich zu relationalen Datenbanken ist die Blockchain komplexer, da nicht nur eine zentrale Implementierung vorliegt. Jeder Knotenpunkt erfordert eine Anbindung an die Blockchain mit entsprechenden Sicherheitsmechanismen, die Datensicherheitskriterien, insbesondere die Sicherheit von Übertragungen, erfüllen müssen. Es ist auch wichtig, die Verfügbarkeit der Knoten für Validierungsaufgaben sicherzustellen und die erforderliche Netzwerkinfrastruktur für den Einsatz zu prüfen (Berghoff et al. 2019).

2.3.3 Dokumentorientierte Datenbank

Aufgrund des geplanten Einsatzfeldes der Datenbank und der damit einhergehenden Individualität und Inkonsistenz der Datenstruktur werden hier nur die dokumentorientierten Datenbanken betrachtet.

Datensicherheit:

Die Sicherheit von dokumentorientierten Datenbanken hängt stark von der Systemstruktur ab. Ein geschützter Speicherort und ein Authentifizierungskonzept sind essenziell, einschließlich der Protokollierung von Datenbankaktionen (Zahid et al. 2014). Die verschlüsselte Speicherung der Daten minimiert potenzielle Schäden bei einem Angriff. Sowohl Datenabfragen als auch Datenübertragungen sollten ausreichend abgesichert sein. Bei Datenbankabfragen sollten alle Nutzereingaben überprüft und bereinigt werden (Ron et al. 2015).

In verteilten NoSQL-Datenbanken kann der Schaden durch unberechtigten Zugriff reduziert werden, da sich Daten auf verschiedenen Knoten befinden. Es ist jedoch wichtig, ausreichende Sicherheit für die Kommunikation zwischen den Knoten zu gewährleisten, da dies eine weitere potenzielle Sicherheitslücke darstellt (Eisermann und Gerold 2022).

Daten/Aufgaben Konsistenz:

Bei der Datenspeicherung in dokumentorientierten Datenbanken muss der Anwender selbst auf die Daten- und Aufgabenkonsistenz achten und regelmäßige Überprüfungen durchführen. Obwohl es nicht möglich ist, zwei identische Dokumente zu erstellen, können Informationen durch die strukturschwache Speicherung redundant sein (Mohamed et al. 2014; Klettke et al. 2016).

Skalierbarkeit:

Gleich wie relationale Datenbanken besitzen auch Dokument-orientierte NoSQL Datenbanken eine bedingte Skalierbarkeit. Bis zu einer gewissen Größe ist ebenfalls eine vertikale Skalierung möglich. Jedoch ist hier die Komplexität der Skalierung durch den grundlegenden Aufbau deutlich geringer, was ebenfalls für eine horizontale Skalierung gilt (Mohamed et al. 2014; Schreiner et al. 2019; Mason 2015).

Kosten:

Die Kostenstrukturen ähneln denen relationaler Datenbanken, da auch hier separate Hardware erforderlich ist (Eisermann und Gerold 2022). Je nach Anwendungsfall kann jedoch aufgrund der Datenbankstruktur eine geringere Rechenleistung benötigt werden (Kunda und Phiri 2017).

Auch bei dezentralen dokumentenbasierten Datenbanken variieren die Kosten stark je nach verwendeter Serverhardware. Es besteht jedoch je nach System die Möglichkeit, Datenknoten auf vorhandene Teilnehmer aufzuteilen und so auf spezielle Hardware zu verzichten (Eisermann und Gerold 2022).

Latenz:

Die Latenz besteht aus der Übertragungsgeschwindigkeit des Netzwerks und der Zugriffsgeschwindigkeit bei Datenbankabfragen. Bei dokumentorientierten Datenbanken ist die Latenz oft geringer als bei relationalen Datenbanken, da keine verknüpften Tabellenstruktur vorhanden ist (Aust 2021). In dezentralen Datenbanken kann die Latenz bei Abfragen mehrerer Dokumente ansteigen, da mehrere Übertragungen erforderlich sind. Geht man von völlig unterschiedlichen Quellen aus, kann dies unter der Annahme gleicher Netzwerk- und Reaktionsgeschwindigkeiten der Knoten als O(n) notiert werden (Eisermann und Gerold 2022).

Verfügbarkeit:

Die Verfügbarkeit hängt stark von der Verfügbarkeit der Serverkomponente ab. Sie bieten jedoch im Vergleich zu relationalen Datenbanken eine höhere Verfügbarkeit, da redundante Speicher mit geringem Aufwand bereitgestellt werden können. Allerdings erfordert es einen erheblichen Aufwand, um alle Datenspeicher konsistent zu halten (Eisermann und Gerold 2022).

Komplexität:

Dokument-orientierte NoSQL Datenbanken besitzen standardmäßig eine geringe Komplexität. Jedoch nimmt die Komplexität stark zu, wenn Sicherheitskonzepte und eine durchgehende Konsistenz der Daten über mehrere Systeme geschaffen werden sollen (Eisermann und Gerold 2022; Mohamed et al. 2014).

3 Gegenüberstellung der Konzepte

In diesem Kapitel werden die verschiedenen Architekturen für die Verarbeitungsschicht und die möglichen Datenbankschemata gegenübergestellt und verglichen. Zudem wird für den genannten Use Case die optimale Kombination von Architektur und Datenbankschema anhand der gegenübergestellten Konzepte und der Anforderungen an das Konzept ermittelt.

Die möglichen Datenhaltungsmodelle werden anhand der in Abschn. 2.3. festgelegten Kriterien und Ausführungen verglichen. Der Vergleich der Datenverarbeitung erfolgt anhand der Punkte Latenz, Informationsgehalt der übertragenen Daten, der Datensicherheit, der notwendigen Bandbreite für die Datenübertragung und der notwendigen Leistung der Endgeräte.

Die Bewertungen in Tab. 1 beziehen sich auf alle Modelle ohne Berücksichtigung eines spezifischen Anwendungsfalls und können sich daher je nach individuellem Anwendungsfall und Systemauslegung unterscheiden. Sie stellen eine Einordnung der einzelnen Datenhaltungsmodelle zueinander dar.

Tab. 1 Bewertung der Datenhaltungsmodelle
Full size table

Die Bewertung der verschiedenen Architekturen für die Verarbeitungsschicht des Steuersystems erfolgt qualitativ im Vergleich zueinander, wobei die Bewertungen von den anderen genannten Architekturen abhängig sind.

Beim Vergleich der Vorgaben aus dem Use-Case in Abschn. 1.2 und den Eigenschaften der Datenhaltungsmodelle in Tab. 1 wird erkenntlich, dass keins der analysierten Datenhaltungsmodelle alle Anforderungen des Use-Case abdeckt.

Die relationale Datenbank erfüllt fünf der sieben Anforderungen des Use-Case:

  1. 1.

    Je nach Implementierung ist die relationale Datenbank sowohl vertikal als auch horizontal skalierbar, was die im Use-Case geforderte hohe Skalierbarkeit mit sich bringt.

  2. 2.

    Die Kosten einer relationalen Datenbank sind auf Grund der vergleichsweise geringen notwendigen Rechenleistung ebenfalls gering, was wiederrum die Anforderungen an geringe Kosten aus dem Use-Case erfüllt.

  3. 3.

    Die Latenz wird hauptsächlich durch die Übertragungsgeschwindigkeit des Netzwerkes und den Overhead bei der Datenabfrage bestimmt, was zur benötigten geringen Latenz führt.

  4. 4.

    Die Verfügbarkeit ist zwar aufgrund fehlender Redundanzen gering, erfüllt aber dennoch die Anforderungen.

  5. 5.

    Die Komplexität bewegt sich bei kleiner Datenmenge und nicht dynamischen Systemen im mittleren bis niedrigen Bereich, wovon auf Grund des genannten Use-Case ausgegangen wird, da hier keine große Anzahl an Clients oder einer dynamischen Struktur vorhanden ist.

Die Blockchain hingegen erfüllt nur die Anforderungen im Bereich der Daten- & Aufgabenkonsistenz, der Latenz und der Verfügbarkeit aufgrund ihrer verteilten Struktur.

Die hohe Daten- & Aufgabenkonsistenz, die im Use-Case gefordert wird, wird bei der Blockchain durch die Sicherung der Daten auf mehreren Knoten erreicht. Die Anforderung an die Latenz wird bei der Blockchain durch die Verfügbarkeit der lokalen Kopien erreicht, obwohl hier ebenfalls die Zeit der Validierung zu berücksichtigen ist. Die aus dem Use-Case geforderte geringe Verfügbarkeit der Daten wird durch die hohe Verfügbarkeit auf Grund der lokalen Kopie der Daten erfüllt.

Die NoSQL Datenbank erfüllt das Kriterium der geringen Kosten aufgrund der geringen benötigten Rechenleistung und der somit notwendigen Hardware. Die Strukturierung der NoSQL Datenbanken ohne verknüpfte Tabellen führt zu einer geringen Latenz, wodurch die Anforderungen an eine geringe Latenz erfüllt sind. Die Anforderungen an das Kriterium der Verfügbarkeit sind erfüllt, da bei NoSQL Datenbanken im Gegensatz zu relationalen Datenbanken redundante Speicher mit geringem Aufwand bereitgestellt werden.

Bei der Gegenüberstellung der möglichen Architekturen für die Verarbeitungsschicht in Tab. 2 zeigt sich, dass keine der angegebenen Architekturen die Anforderungen aus dem Use-Case vollständig erfüllen kann. Bei der lokal zentralen Architektur sowie bei der Verarbeitung in der Cloud wird nur das Kriterium der geringen notwendigen Leistung der Endgeräte erfüllt, da hier eine zentrale Einheit die Verarbeitung der Daten vornimmt. Die lokal dezentrale Architektur erfüllt wiederum mit vier von fünf Punkten einen Großteil der Kriterien. Das Kriterium der geringen Latenz wird aufgrund der direkten Datenverarbeitung am Entstehungsort erfüllt. Da nur bereits verarbeite Daten versandt werden müssen, wird das Kriterium des geringen Informationsgehaltes der versendeten Daten erfüllt, sowie die damit einhergehende Datensicherheit und die notwendige Bandbreite.

Tab. 2 Bewertung möglicher Architekturen der Verarbeitungsschicht
Full size table

Um nun eine konkrete Aussage für ein Konzept treffen zu können, ist eine weitere Spezifizierung des Use-Case beziehungsweise eine Gewichtung der Anforderungen an die einzelnen Kriterien notwendig.

4 Analyse bestehender Umsetzungen

Bei der Betrachtung der Konzepte im Bereich der Steuerungssysteme, welcher den Bereich der digitalen Plattformen und Peer-to-Peer Energiehandelsansätze einschließt, konnten in mehreren in der Vergangenheit abgeschlossenen Projekten Schwachstellen identifiziert werden.

Im Forschungsprojekt Pebbles wurde eine Blockchain-basierte Plattform für den Peer-to-Peer-Handel entwickelt. Im Konzept wurde eine private Blockchain verwendet. Die Verbindung der verwendeten Edge-Devices und der digitalen Handelsdienste erfolgt anhand von Konnektoren (Lucke et al. 2022). Wie bereits im Abschn. 2.3.2 beschrieben, liegen hier Schwachstellen in der Sicherheit des Systems, da bei der Verwendung einer Blockchain zusätzliche Sicherheitsmaßnahmen für die Vertraulichkeit zu implementieren sind und für die Verfügbarkeit und die allgemeine Sicherheit einer Blockchain eine entsprechende Anzahl an Knoten zur Verfügung stehen müssen.

Im Projekt Landau Micro Grid (Lamp) wurden die Daten der Teilnehmer in einer objektrelationalen Datenbank gespeichert. Die Datenverarbeitung fand zentral auf einem Server statt und die Übertragung zum Server erfolgte über LoRaWAN-Technologie (Richter et al. 2021). Objektrelationale Datenbanken kombinieren Elemente relationaler und objektorientierter Datenbanken, was zu mittelmäßiger Skalierbarkeit und höheren Latenzen führen kann, was ein Nachteil des Systems ist. Ebenfalls wird die Sicherheit des Systems, wie bei der lokalen zentralen Verarbeitung beschrieben, durch die Übertragung der Daten verringert.

Das Verbundprojekt Smart Energy Communitys (SMECS) etablierte eine Plattform für den Handel von Strommengen für den Folgetag. Die Datenspeicherung erfolgte auf der Ethereum-Blockchain, wobei das Matching auf einer eigenen Plattform stattfand (Zinke 2020). Die Grundsicherheit des Systems wurde durch die Nutzung einer etablierten Blockchain gewährleistet. Die Schnittstellen zur Matching-Plattform ergeben wiederum ein potenzielles Sicherheitsrisiko, wenn diese nicht ausreichend gesichert sind.

Im ETIBLOGG-Projekt wurde ein Peer-to-Peer-Energiehandelskonzept verfolgt, das flexiblen Akteuren einen Zugang zum Strommarkt geben soll. Eine Blockchain bildete die technische Handelsstruktur, wobei die Verbindung der Teilnehmer über Blockchain-Devices erfolgte, welche die lokale Handelslogik bereitstellen. Das Blockchain-Framework WRHML (Wormhole) wurde für B2B-Prozesse verwendet (Zinke 2020). Da es sich auch hier um eine private Blockchain handelt, sei auf das Projekt Pebbles verwiesen.

Eine von Wunderlich et al. (2018) durchgeführte Untersuchung betrachtete den dezentralen Energiehandel mittels des Peer-to-Peer-Ansatzes Chord. Als Datenbank wurde eine objektrelationale Datenbank verwendet. Die Erzeugungs- & Verbrauchsdaten wurden hier lokal abgelegt. Die Transaktionsdaten wurden im P2P-Netzwerk verteilt auf jedem Knoten gespeichert. Die verteilte Speicherung der Daten auf den einzelnen Knoten sowie das Hashen der IP-Adressen erhöht hierbei die Datenintegrität. Die Übertragung der Daten birgt wiederum ein potenzielles Sicherheitsrisiko.

Allgemein lässt sich zusammenfassen, dass einige Konzepte gerade im Bereich der Datenverfügbarkeit Schwachstellen aufweisen. Dies resultiert maßgeblich aus der Verfügbarkeit einzelner Komponenten und der Anzahl an Knotenpunkten, welche für eine Redundanz innerhalb des Systems sorgen können. Des Weiteren stellt häufig die Datensicherheit des Systems eine Schwachstelle dar. Da die Systeme häufig nur einen geringen Datenschutz aufweisen, muss bei der Umsetzung das Augenmerk auf die Implementierung von Maßnahmen zur Sicherheit gelegt werden. Die Anwendung von zusätzlichen Datenschutzmaßnahmen erhöht wiederrum die Komplexität des Systems, senkt die Skalierbarkeit und kann unter Umständen zu Latenzproblemen führen.

5 Handlungsempfehlungen, Fazit & Ausblick

5.1 Handlungsempfehlung

Im Folgenden wird eine Handlungsempfehlung für den im Kapitel 1.2 beschriebenen Use-Case gegeben.

Bei der Handlungsempfehlung, die aus der zuvor durchgeführten Analyse bisheriger Konzepte zur Gestaltung digitaler Plattformen und Peer-to-Peer Energiehandelsansätze resultiert, werden die identifizierten Schwachstellen berücksichtigt.

Durch die Verwendung einer industriellen und echtzeitfähigen Steuerung ergeben sich verschiedene limitierende Faktoren wie die nutzbare Speichergröße und die begrenzte Rechenleistung. Dabei ist zu beachten, dass die Erfassung und Speicherung von Daten im Vergleich zu der Ausführung von Steuerungs- und Regelungsaufgaben eher eine geringe Priorität besitzt und somit lediglich ein Teil der verfügbaren Ressourcen dafür verwendet werden kann. Diese Faktoren müssen zwingend bei der Auswahl berücksichtigt werden.

Auf Basis der hohen Anforderungen an die Datensicherheit und die Aufgaben- und Datenkonsistenz können zunächst entweder eine relationale Datenbank oder eine Blockchain genutzt werden, da diese standardmäßig eine hohe Daten- und Aufgabenkonsistenz bieten. Eine NoSQL Datenbank bietet standardmäßig keine Aufgaben- und Datenkonsistenz, weshalb sie hier zunächst nicht weiter betrachtet wird.

Durch die genannten limitierenden Faktoren der echtzeitfähigen Steuerung, welche anhand der Tab. 1 und 2 beurteilt werden können und der Annahme, dass die Steuerung nicht nur Echtzeitaufgaben, sondern auch weitere Steuerungsaufgaben übernimmt, eignet sich für den Anwendungsfall am ehesten eine zentrale relationale Datenbank. Eine Blockchain ist hier eher ungeeignet, da nur ein begrenzter Speicherplatz zur Verfügung steht, welcher je nach Größe der Blockchain nicht ausreicht, was die nötige Flexibilität einschränkt. Zudem können die begrenzte Rechenleistung und die niedrige Priorität bei der regelmäßigen Validierung neuer Blöcke der Blockchain und der gleichzeitigen Ausführung von Steuerungsaufgaben zu Problemen führen.

Daher empfiehlt sich unter Berücksichtigung der genannten Punkte für den Use-Case die Nutzung einer zentralen relationalen Datenbank.

5.2 Fazit

Dieser Artikel leistet einen Beitrag im Bereich der Auslegung der Datenhaltung und der Planung des Ortes der Datenverarbeitung von Steuerungssystemen. Insbesondere erweitert er den Bereich der Entwicklung von Steuerungssystemen im Energiesektor um eine vergleichende Betrachtung der Datenhaltungskonzepte unter Berücksichtigung der Zentralität und Dezentralität des Systems, welche so bisher nicht durchgeführt wurde. Anhand der erzielten Ergebnisse und der daraus resultierenden Handlungsempfehlung können in zukünftigen Entwicklungen, die aus den bisher durchgeführten Projekten identifizierten Schwachstellen vermieden und dadurch sicherere, leistungsfähigere Steuerungssysteme entwickelt werden.

5.3 Ausblick

Wie aus dem Artikel und der gegeben Handlungsempfehlung deutlich wird, kann keins der aufgeführten Konzepte alle Anforderungen vollständig abdecken. Dies wirft die Frage auf, wie ein System gestaltet werden müsste, welches alle Anforderungen gleichermaßen erfüllt. Dieser Punkt wird in Zukunft durch die immer größer werdende Menge an Daten der Systeme und den wachsenden Stellenwert der personenbezogenen Daten immer relevanter und ist bereits heute Gegenstand der Forschung zum Beispiel bei Konzepten mit einem Second Layer Ansatz (Denga 2022).

Diese Ansätze verfolgen z. B. die getrennte Speicherung von Daten auf und neben einer Blockchain z. B. in einer relationalen Datenbank, mit dem Ziel die sich durch die Technologie ergebenden Nachteile mit Hilfe dieser Kombination auszugleichen (Pop et al. 2019; Kalajdjieski et al. 2023).

Solche Ansätze, die auf Kombinationen verschiedener Technologien setzen, zeigen vielversprechende Wege auf, um die Herausforderungen der aktuellen Technologielandschaft zu bewältigen. Es ist daher ratsam, nicht nur den vorliegenden Use-Case zu betrachten, sondern auch weitere Anwendungsfälle zu definieren und die technischen Entwicklungen in diesem Bereich genau zu beobachten.

Abschließend ist festzuhalten, dass in diesem Artikel der Scope auf dem Use-Case und den damit einhergehenden Anforderungen lag. Ebenfalls basiert die Auswahl der betrachteten Konzepte auf dem in der Literatur zu findendem Stand der Technik. Eine ausführliche Analyse über die Möglichkeiten der Datenverarbeitung für ein solches System wird in einer zukünftigen Arbeit veröffentlicht werden.