Projekt NetzDatenStrom (NDS)
Das openKONSEQUENZ begleitende Forschungsprojekt NetzDatenStrom:
Standardkonforme Integration von Big-Data-Lösungen in existierende Netzleitsysteme
Neues aus dem Forschungsprojekt NDS
Die Software in netzleitsystemnahen Umfeld beeinflusst kritische Infrastruktur und sollte deshalb unter sicherheitstechnischen Aspekten gestärkt sein. Die Berücksichtigung von Sicherheit bereits während der Entwurfsphase einer Software wird als Security-By-Design bezeichnet. Es ist dabei davon auszugehen, dass Angreifer mit hohem Budgeteinsatz (zeitlich, personell, monetär) eine Möglichkeit finden werden, ein System zu kompromittieren. Durch die Anwendung bekannter Sicherheitstaktiken und Sicherheitsmuster, soll dies erschwert werden. Die Hürden für Angriffe sollen so hoch gelegt werden, dass sich der Aufwand für die meisten Angreifer nicht lohnt und diese nach kurzem Versuch davon ablassen. Ein Sicherheitskonzept nur zur Entwurfsphase ist jedoch aus Sicht der am vorliegenden Bericht beteiligten Personen nicht ausreichend für die Gewährleistung der Sicherheit einer Software. Deshalb werden über Security-by-Design-Prinzipien während der Entwurfsphase von Software hinaus weitere Themen behandelt.
Während der Implementierung von Software können unabhängig vom umgesetzten Sicherheitskonzept der Entwurfsphase Angriffsflächen entstehen, die berücksichtigt werden müssen und durch bekannte und einfache Muster gering gehalten werden können. Auch bei der Verwendung von Software können sich durch Fehlbedienungen kritische Situationen ergeben, denen durch eine geeignete Darstellung vorzubeugen ist. Zudem sollte die Sicherheit von Open Source Software durch verschiedene Parteien nachvollziehbar bewertet werden können und die Einhaltung von Sicherheitsvorgaben ein Teil einer Zertifizierung von Software sein. Des Weiteren muss für Schnittstellen sichergestellt werden, dass ein Datenaustausch sowohl syntaktisch als auch semantisch korrekt durchgeführt wird, damit sich Software interoperabel in bestehende Systemwelten integrieren lassen.
NetzDatenStrom hat dazu den Technical Report „Sicherheitsanforderungen an netzleitsystemnahe Software für den Energienetzbetrieb und Empfehlungen für Security-by-Design und Sicherheitszertifizierung von Open Source-Lösungen am Beispiel von Open Source in openKONSEQUENZ“ erarbeitet. In diesem Bericht werden Empfehlungen zur Sicherheit und ein Vorgehen zur Bewertung der Sicherheit von Software sowie die Entwicklung von Zertifikaten für Open Source Software im Umfeld von Netzleitsystemen vorgestellt.
Der Bericht greift die Sicherheitsanforderungen aus der IEC 62351 Reihe, dem BSI Grundschutz (BSI, 2020) und dem BDEW Whitepaper (BDEW, 2018) auf und vertieft diese Anforderungen für die Entwicklungsphasen des Software-Lebenszyklus (Anforderungsspezifikation, Entwurf, Entwicklung, Testen und Update/Patch-Management) bis zur Bereitstellung der Softwarequellen basierend auf Erfahrungen aus NetzDatenStrom und den Entwicklungsprojekten von openKONSEQUENZ. Der sichere IT-Betrieb sowie die Netzwerksicherheit obliegen den die Software einsetzenden/bereitstellenden Unternehmen. Sie sind in den oben genannten Quellen sowie der ISO 27000 und folgende detailliert aufbereitet und sind deswegen im Bericht nicht weiter vertieft.
Der entsprechende Technical Report findet sich im Downloadbereich.
Für den Datenaustausch zwischen den im Projekt NetzDatenStrom anzubindenden Komponenten wurden standardisierte Schnittstellen verwendet und standardbasierte Schnittstellenprofile entwickelt, welche auf das Common Information Model (CIM) IEC 61970, IEC 61968, IEC 62325 aufbauen. Dies erfolgte unter Berücksichtigung bereits verabschiedeter aber auch in Entwicklung befindlicher Bestandteile des kanonischen CIM Datenmodells als auch unter Berücksichtigung bereits bestehender Normen beispielsweise zur Smart Meter Kommunikation (IEC 62056 COSEM, IEC 61968-9 MeteringReadings) oder zur Feldkommunikation (IEC 60870-5-104), um die Kombinierbarkeit von Big Data-Komponenten unterschiedlicher Entwickler und Hersteller mit (kommerziellen) State-of-the-Art-Netzleitsystemen zu erreichen. Hierbei wurden besondere Big Data-Anforderungen durch die Kombinierbarkeit einer Vielzahl von Daten in zusammenhängenden Nachrichtenpaketen berücksichtigt.
Darüber hinaus hat das Projekt NetzDatenStrom den Bedarf an einer einheitlichen Anfragesprache für Zeitreihen offensichtlich gemacht, damit Zeitreihenarchive untereinander ausgetauscht werden können, aber auch neue Arten von Anfragen an Archive erfolgen können, ohne eine neue Implementierung für jede dieser Anfragen für das Archiv vornehmen zu müssen. So können anfragende Module und Archive voneinander entkoppelt entwickelt werden.
Die Anfragesprache wurde an SQL angelehnt definiert, um eine hohe Wiederverwendbarkeit hinsichtlich existierender SQL-Mechanismen sicherzustellen und eine Einstiegshürde bei möglichst vielen Anwendern gering zu halten. Aufgrund des Bekanntheitsgerades von SQL ist von einer schnellen Verwendbarkeit der Anfragesprache auszugehen. Im Wesentlichen wurden neue und einfache Möglichkeiten für die Abfrage von Zeiten und Zeiträumen, sowie der Interpolation, Aggregation und Rasterung von Zeitreihendaten beschrieben und des Weiteren neue Prefix- und Infix-Funktionen für Zeitreihendaten ermöglicht. Die Anfragesprache setzt keine relationalen Datenbanken voraus. Je nach unterliegender Technologie wird die Implementierung jedoch unterschiedlich komplex sein. Die einheitliche Anfragesprache stellt aber sicher, dass auf unterschiedlichen Technologien basierende Zeitreihenarchive austauschbar sind und gleich angesprochen werden können. Die Zeitreihenanfragesprache wird im Projekt NDS in Teilen umgesetzt, ist aber für die allgemeine Verwendung definiert.
Die entsprechenden Dokumentationen und spezifizierten Schnittstellen finden sich im Downloadbereich.
Im Projekt NetzDatenStrom werden auf Open Source basierende Big-Data-Lösungen an existierende Netzleitsysteme angebunden. Die Auswahl existierender Big-Data-Technologien erfolgte unter Berücksichtigung der Anwendungsfälle aus AP0 sowie den sich aus openKONSEQUENZ ergebenden Anforderungen hinsichtlich Wartbarkeit, Erweiterbarkeit und Open Source. An dieser Stelle wurden bisherige technische Entscheidungen aus openKONSEQUENZ teilweise bewusst in Frage gestellt und neue Erkenntnisse aus der Entwicklung von openKONSEQUENZ-Modulen und den NDS-Anwendungsfällen berücksichtigt.
Gemäß dieser Anforderungen wurde für NDS für die Big-Data-Archivierung von Daten die Open Source Datenbank Cassandra ermittelt. Für die Datenstromkomponente wird das Datenstrommanagementsystem Odysseus und für die Integration heterogener Daten der JValue Open Data Service verwendet.
Eine Referenzarchitektur für die technologische Zusammensetzung innerhalb von Modulen wurde zugunsten des Microservice-Paradigma nicht in einer Detailtiefe festgelegt, wie es aktuell openKONSEQUENZ für seine Modulentwicklungen in den entsprechenden Handbüchern tut. Dies dient dazu, insbesondere zukünftigen Modulentwicklern die Auswahl dann aktueller Technologien zu erlauben und die langfristige Wartbarkeit einzelner Module durch Entkopplung der Wartungszyklen voneinander zu vereinfachen. Die Kommunikation zwischen Modulen muss jedoch unabhängig von diesen inneren Technologien festgelegt werden – und stabil bleiben, um ein reibungsloses ineinandergreifen von Modulen sowohl zeitlich als auch örtlich unterschiedlicher Systemlandschaften zu ermöglichen. Für eine erleichterte Inbetriebnahme neuer Module soll Containerisierung eingesetzt werden.
Die Verwendung der aktuellen Version des Common Information Model wurde für Schnittstellendaten bestätigt. Für Anfragen an das Big-Data-Archiv soll eine generische Anfragesprache für Messdaten anstelle von dedizierten Schnittstellen entwickelt werden. Dies erfolgt insbesondere Hinsichtlich der Erweiterbarkeit und des Modularitätsgedankens von openKONSEQUENZ: Eine generische Anfragesprache erlaubt es, für neue Module neue Anfragen zu entwickeln und neue Auswertungen auf existierenden Daten durchzuführen, ohne eine Veränderung von Quellen des Big-Data-Archivs vornehmen zu müssen. Dadurch wird insbesondere die Wartbarkeit der Systemlandschaft vereinfacht – Compiling, Integrationstests und Produktivitätssetzung auf Seiten des Big-Data-Archivs sowie Seiteneffekte auf bisherige Module entfallen.
Die Kommunikation erfolgt für Client-Server-Verbindungen mittels RESTful Webservices und für Ereignis-getriebene Kommunikation (Publish-Subscribe) mittels RabbitMQ. Eine zentrale Vermittlung zwischen Services wird auch auf Grund des Microservice-Gedanken im Projekt NDS nicht mehr vorgesehen – bleibt aber möglich. Für NDS sollen sogenannte lokale Proxies Verwendung finden, die eine direkte Kommunikation zwischen den Modulen erlauben. Diese Proxies erlauben des Weiteren eine Konfiguration von Verbindungsparametern während des Betriebes und sichern die gewünschte Eigenschaft, Anpassungen des Quellcodes von Modulen bei einer Systemlandschaftsänderung zu vermeiden. Weiterhin wurde festgestellt, dass die Art der Serialisierung von Nachrichten zum Bespiel mittels XML, JSON (oder weitere) erfolgen kann und im Wesentlichen nur einmal festgelegt werden muss. Hier wird auf Ergebnisse von ersten Testläufen im Projekt NDS gewartet, um eine geeignete Festlegung auch im Hinblick auf die Verarbeitung und den Versand der großen Datenmengen aus den Anwendungsfällen zu treffen.
Nicht nur auf Seiten der Modul-zu-Modul-Kommunikation ist eine Festlegung sinnvoll. Um die Benutzungsschnittstellen herstellerübergreifender Module konsistent zu gestalten, wird ein kontextspezifischer Styleguide entwickelt. Mehr dazu lesen Sie im nachfolgenden Beitrag.
Im Projekt NetzDatenStrom werden auf Open Source basierende Big-Data-Lösungen an existierende Netzleitsysteme angebunden. Um die Benutzungsschnittstellen herstellerübergreifender Module konsistent zu gestalten, wird ein
kontextspezifischer Styleguide entwickelt. Dies soll gewährleisten, dass ein modulares System aus Sicht der Nutzenden ein konsistentes und erwartungskonformes Bedienkonzept aufweist.
Als Grundlage des Styleguides wird auf dem aktuellen Styleguide von openKONSEQUENZ aufgebaut, welcher als PDF und Online in Form eines Wikis verfügbar ist. Das Wiki ist durch die Möglichkeit, den Styleguide aktuell zu halten, der reinen PDF-Version überlegen. Unser Ansatz bietet gegenüber dem Wiki den Vorteil, dass die Funktionalitäten der einzelnen Komponenten interaktiv im Styleguide erlebt werden können sowie speziell für Styleguides entwickelte Plugins zur Erweiterung bereitstehen.
Zur Realisierung des Styleguides verwenden wir „SourceJS“, eine skalierbare und quelloffene Plattform zur Erstellung dynamischer Styleguides. Diese Anwendung ist modular aufgebaut und unterstützt die Entwicklung und Integration benutzerdefinierter Plugins. Die Plattform erlaubt es eine große Anzahl an Plugins und Middlewares zu verbinden. Der Fokus von SourceJS liegt dabei nicht auf einer spezifischen Technologie, so dass sich der Workflow von SourceJS in eine existierende Codebasis integrieren lässt. Existierende, wiederverwendbare und neu entwickelte Front-End-Komponenten lassen sich zentral innerhalb von SourceJS dokumentieren, testen und verwalten.
Die im Projekt verwendete Lösung soll kein rein CSS-fokussiertes Tool sein, welches ausschließlich den HTML-Markup und Webdesign-Aspekt beinhaltet. Vielmehr soll die Lösung eine Plattform mit einer erweiterbaren und großen Anzahl an Funktionen umfassen. In der unmodifizierten Version von SourceJS kann der Anwender sich für Style-Spezifikationen (wie z.B. Buttons) bereits den nötigen HTML-Code anzeigen lassen. Die Anzeige des Codes umfasst in der erweiterten Projekt-Version weitere Ansichten, mit denen der Entwickler auch den Code der zugehörigen CSS- und JS-Codeblöcke abrufen kann. Zudem befindet sich aktuell eine Benutzerverwaltung in Entwicklung. Dabei soll die Möglichkeit geboten werden verschiedenen Nutzern optimierte Ansichten zu präsentieren sowie Zugriffsrechte zu definieren (z.B. nur Lesen des quelloffenen Styleguides oder Schreibzugriffe für Entwickler). Bereits geplante Weiterentwicklungen sollen die Arbeitsprozesse mit dem Styleguide optimieren, indem sie Entwickler, Designer und Projektleiter im gesamten Entwicklungszyklus unterstützen.
Für das AP6: Universität zu Lübeck, Institut für Multimediale und Interaktive Systeme (IMIS)
Im Projekt NetzDatenStrom werden auf Open-Source basierende Big-Data-Lösungen an existierende Netzleitsysteme angebunden. Da in Forschungs- und Entwicklungsprojekten oder bei Integrationstests von Netzleitsystemen keine Kommunikation mit Transformatoren, Windparks und anderen Mittelspannungsanlagen gemäß des Standards IEC 60870-5-104 (IEC 104) existiert, muss für den Test von Netzleitsystemen und ergänzender Module stattdessen eine Infrastruktur aufgebaut werden, in der ein Mittelspannungsnetz über eine Simulation nachgebildet wird. Bereits existierende und kommerziell verfügbare IEC 104 Protokollsimulatoren sind für diesen Zweck unzureichend, da nur einzelne Pakete versendet werden können und damit kein kontinuierlicher Datenstrom realisiert werden kann, der ein reales Mittelspannungsnetz nachbildet.
In NetzDatenStrom wurde aus diesem Grund ein Mittelspannungsnetz-Nachrichtenabspieler entwickelt, der kontinuierliche Datenströme aus konformen IEC 104er Nachrichten erzeugt. Er liest einen echten IEC 104er Nachrichtenmittschnitt ein, der mittels Wireshark im PCAP Format mitgeschnitten wurde. Der Abspieler extrahiert daraus IEC 104er Nachrichten, setzt Zeitstempel neu und generiert aktuelle und konforme Telegramme in Echtzeit, die an Leitsysteme versendet werden können. Auf diese Art und Weise kann ein mitgeschnittener Datenverkehr in identischer Weise nachgebildet werden und Leitsysteme können unter Realbedingungen im Labor getestet werden. Als weitere Features bietet die Software die Möglichkeit zeitliche Differenzen zwischen aufeinanderfolgende Telegramme anzupassen um eine Be- oder Entschleunigung der Datenströme zu ermöglichen.
Mittschnitt von Daten aus der Mittelspannung wird in Odysseus manipuliert und gemäß des Zeitstempels als Nachrichten an ein Netzleitsystem versendet.
Der Abspieler wurde auf Basis vom Datenstrommanagementsystem Odysseus entwickelt und steht demnächst als Open-Source-Lösung auch für zukünftige Testumgebungen und Modultests zur Verfügung.
Im Projekt „NetzDatenStrom“ werden auf OpenSource basierende Big-Data-Lösungen an existierende Netzleitsysteme angebunden. Im Zuge der Entwicklung ist es nötig eine geeignete Evaluationsumgebung aufzubauen, in der die Big-Data-Komponenten mit einer ausreichend großen Datenmenge konfrontiert werden können, um die Herausforderungen, die mit Big-Data einhergehen, adäquat nachzustellen. Da ein flächendeckendes Rollout von Smart Meter Gateways (SMGW) und daran angeschlossenen Smart Metern noch nicht stattgefunden hat und damit verbundene echte Zählerdaten noch nicht verfügbar sind, bildet die Simulation des Niederspannungsnetzes einen zentralen Teil der Evaluationsumgebung.
Zur Umsetzung dieser Simulation wird in NetzDatenStrom das Co-Simulations-Framework „mosaik“ verwendet, mit dessen Hilfe großskalige Szenarien zusammenzusetzt werden können. Dabei koppelt mosaik dedizierte Simulatoren für jedes SMGW, jedes Smart Meter sowie für die Kommunikation der Zählerdaten und koordiniert den Austausch zwischen den Simulatoren. Darüber hinaus existieren eigene Simulatoren um das Verhalten der eigentlichen Verbraucher und Erzeuger im Niederspannungsnetz wiederzugeben. Für jede Art von Verbraucher ist dabei ein Standardlastprofil hinterlegt. Für PV-Erzeugungsanlagen werden neben den Stammdaten der Anlagen auch Wetterdaten genutzt werden um Erzeugungsprofile zu generieren.
Die Gesamtsimulation liefert dadurch realistische Zählerstandsdaten im COSEM-Protokoll entsprechend der technischen Richtlinie TR-03109 vom BSI. Die folgende Abbildung zeigt, auf welche Weise die Simulatoren miteinander verbunden werden. Als Kommunikationsmethode wurde ein Webservice gewählt, weil es in der technischen Richtlinie vorgegeben ist.
Beispiel für die Verbindungen zwischen den Simulatoren
Ein Szenario für die Simulation lässt sich sowohl manuell erstellen als auch parametrisiert generieren. Dadurch ist es möglich auch besonders große Szenarien zu erstellen, beispielsweise die Simulation für einen ganzen Landkreis. Die Netztopologie wird dabei anhand von beispielhaften aber realistischen Angaben eines Netzbetreibers nachgebildet und beinhaltet Angaben für Geo-Koordinaten der Messstellen, Angaben zur Anzahl und Verteilung verschiedener Verbraucher, der Aufteilung zwischen Haushalten, Industrie und PV-Erzeugungsanlagen sowie zur Größe der einzelnen Niederspannungsnetze. In der folgenden Abbildung ist ein Beispiel-Szenario für die Stadt Oldenburg, das anhand der oben genannten Parameter generiert wurde, zu sehen. Jede der Flächen bildet ein Niederspannungsnetz mit durchschnittlich 100 Anschlüssen.
Beispiel-Szenario für die Stadt Oldenburg; Erstellt auf Basis von OpenStreetMap
[http://www.openstreetmap.org/copyright]
Die Nutzung der Niederspannungssimulation muss nicht auf das Projekt „NetzDatenStrom“ beschränkt sein. Zukünftig ist es denkbar die Simulation auch in weiteren Projekten als Lieferant für Zählerstandsdaten zu nutzen.
In einem ersten abgeschlossenen Arbeitspaket des Projekts wurden Anwendungsfälle definiert, in denen die von den beteiligten Herstellern eingebrachten Netzleitsysteme sowie die neu zu entwickelnden quelloffenen Big-Data-Komponenten in verschiedenen Konstellationen integriert und im Rahmen eines Laboraufbaus getestet werden sollen. Ein besonderer Fokus lag bei der Spezifikation auf einer vollständigen Abdeckung aller Module (3 Netzleitsysteme, Datenstrom-Verarbeitungsmodul, quelloffenes und –geschlossenes Langzeitarchiv sowie heterogenes Datenintegrationsmodul), deren Integration in aktuelle und zukünftig relevante Szenarien sowie die Verfügbarkeit von Daten für den angestrebten Laboraufbau.
Als Vorgehensweise zur Erhebung von Anwendungsfällen wurde im Rahmen des Projektes die IEC 62559 Use Case-Methodik verfolgt. Dazu wurde ein Use Case Management Repository für das Projekt instanziiert, welches die gemeinsame und gleichzeitige Erarbeitung von Anwendungsfällen und der daraus resultierenden Anforderungen ermöglicht. Nach einer Brainstorming-Phase in der eine Sammlung und Kurzerfassung von Anwendungsfällen erfolgte, wurden diese im Anschluss priorisiert, detailliert erfasst und im Konsortium konsolidiert. Die IEC 62559 Use Case-Methodik sowie die toolgestützte Erfassung unterstützten dabei insbesondere in Hinblick auf die Nomenklatur und Konsistenz.
Es ergaben sich insgesamt sechs Anwendungsfälle, welche im Projektkontext verfolgt und umgesetzt werden:
- Rohdatenspeicherung aller Mittelspannungs-Signale im Langzeitarchiv
Dieses Nutzungsszenario betrachtet die Rohdatenspeicherung von Signalen aus dem Mittelspannungsnetz, die von EWE Netz bereitgestellt werden und die vom Netzleitsystem interpretiert und ans Langzeitarchiv weitergeführt werden. Dabei handelt es sich zum einen um Signale von EEG-Erzeugungsanlagen die als IEC 60870-5-104 (IEC104) Signale in einen zentralen Proxy eingehen, der die Signale plausibilisiert, qualitätssichert und ebenfalls als IEC104 Nachricht weiter an das Netzleitsystem schickt. Zudem empfängt das Netzleitsystem (ebenfalls als IEC104) weitere Signale zur Fernwirktechnik und zur Automatisierung der Mittelspannungsebene von betriebseigenen Anlagen die kein 1-zu-1 Mapping und keine Qualitätssicherung im Proxy durchlaufen. - Aggregation von Niederspannungs-Smart Meter Daten durch das Datenstrom-Managementsystem (DSMS)
Dieses Nutzungsszenario betrachtet eine Aggregation von Niederspannungs-Smart Meter Daten (beispielsweise Verbrauchswerte oder PV-Einspeisemesswerte) zu Summenwerte je Trafostation. Aus dem Niederspannungsbereich werden Smart Meter-Daten mittels Simulation generiert die als COSEM-Nachricht in das Datenstrom-Managementsystem gehen und dort aggregiert werden. Per IEC104 werden die aggregierten Daten zudem in die Netzleitsysteme weitergegeben und dort angezeigt. - Aggregation und Rohdatenspeicherung (bzw. der interpretierten Daten) von Niederspannungs-Smart Meter Daten
Dieses Nutzungsszenario stellt eine Erweiterung vom Nutzungsszenario „Aggregation von Niederspannungs-Smart Meter Daten durch das Datenstrom-Managementsystem“ dar und betrachtet neben der Aggregation von Smart Meter insbesondere die Speicherung aller Niederspannungs-Rohdaten im Langzeitarchiv. - Störungslokalisierung im Niederspannungs-Netz
Dieses Nutzungsszenario betrachtet eine Störungslokalisierung im Niederspannungsnetz. Als Erweiterung des vorangegangenen Anwendungsfalls wird dabei zunächst auf Basis der Ausbleibens von Smart Meter Daten erkannt, dass ein Fehler vorliegt und eine Lokalisierung in der Niederspannungs-Netztopologie durchgeführt. - Plausibilisierung von Erzeugungsdaten aus Nieder- und Mittelspannungs-Ebene mittels historischer Erzeugerdaten
Dieses Nutzungsszenario betrachtet eine Plausibilisierung von Erzeugungsdaten aus Niederspannungs- und Mittelspannungs-Ebene mittels historischer Erzeugerdaten. Die Plausibilisierung an sich wird im Datenstrom-Managementsystem (DSMS) durchgeführt und gleicht die Echtzeitdaten mit historischen Erzeugungsdaten ab, die aus dem Langzeitarchiv geladen werden. - Plausibilisierung von Erzeugungsdaten aus Nieder- und Mittelspannungs-Ebene mittels frei zugänglicher Wetterdaten
Dieses Nutzungsszenario stellt realisiert eine alternative Plausibilitätsprüfung. Im Unterschied zum vorangegangenen Anwendungsfall findet hier ein Abgleich der Echtzeit-Erzeugungsdaten aus Niederspannungs- und Mittelspannungs-Ebene mittels frei zugänglichen Wetterdaten statt. Die Plausibilisierung an sich wird dabei ebenfalls im DSMS durchgeführt.
Ausgangssituation
Das Forschungsprojekt NetzDatenStrom untersucht begleitend zu openKONSEQUENZ die standardkonforme Integration von Big-Data-Lösungen in existierende Netzleitsysteme. Netzbetreiber nutzen in immer größerem Umfang Prognoseverfahren, um die heute weitgehend von dezentralen Energieerzeugungsanlagen geprägten Netze zu steuern. Steuerungs- und Messdaten für technische Anlagen sowie Energiemessdaten der Kunden erzeugen ein stetig wachsendes Datenvolumen. Für die Netzbetreiber entsteht die große Herausforderung, diese Daten effizient zu managen und dabei höchste Sicherheitsstandards zu gewährleisten. Für größere Verteilnetzbetreiber wird die Energiewende die Situation sogar noch verschärfen, da sie zusätzliche Messwerte aus der Mittel- und Niederspannungsebene erforderlich macht. Das steigende Datenvolumen macht es zudem notwendig, schnell auf diese Daten zugreifen zu können, um Verarbeitungsschritte für den operativen Netzbetrieb daraus abzuleiten. Die Handhabung der Daten wird somit zunehmend zu einer Herausforderung.
Das Projekt
In einem vom Bundesministerium für Wirtschaft und Energie im Rahmen des 6. Energieforschungsprogramms geförderten Projekt namens „NetzDatenStrom“ arbeiten Experten aus Forschung und Entwicklung, Hersteller von Netzleitstellensoftware, Netzbetreiber sowie auf Energiewirtschaft spezialisierte IT-Experten an einer Lösung. Das Projekt ist auf drei Jahre angelegt. Am Projekt „NetzDatenStrom“ ist ein Konsortium aus den Netzleitsystemherstellern PSI AG und KISTERS AG, dem Netzbetreiber EWE NETZ GmbH, den F&E-Partnern OFFIS – Institut für Informatik (Konsortialleiter) , Friedrich-Alexander-Universität Erlangen-Nürnberg sowie dem Institut für Multimediale und Interaktive Systeme der Universität zu Lübeck zusammen mit dem Konsortium „openKONSEQUENZ“ beteiligt.
Das Projekt „NetzDatenStrom“ wird untersuchen und erproben, wie die immens großen Datenmengen künftig effizienter verarbeitet und genutzt werden können. Dazu werden vorhandene Archiv- und Datenbanklösungen kommerzieller Leitsystemlösungen um eine Big-Data-Komponente erweitert, die große Datenmengen speichert und verarbeitet. Die Big-Data-Komponente wird durch ein System ergänzt, mit dem Mess- und Sensordaten in Echtzeit ausgewertet und (vor-)verarbeitet werden können. Die Erweiterung vorhandener Datenarchive um solche Big-Data-Lösungen schafft die Voraussetzungen dafür, die immer umfangreichere und steigende Menge an Mess-, Sensor- und Ereignisdaten reibungslos in die Netzbetriebsführung zu integrieren.
Dies lässt sich mit klassischen Datenbanktechnologien von kommerziell verfügbaren Leitsystemlösungen bislang nicht oder nur stark eingeschränkt realisieren. In der Netzführung sind Systeme mit einem solchen Leistungsumfang bisher weitgehend unbekannt. Das Ergänzen der Leitsysteme durch echtzeitfähige Datenstromtechnologien wird es ermöglichen, auf Basis der im Leitsystem ankommenden Datenmengen neuartige Verfahren für automatisiertes Netz-Monitoring und Betriebsführung für Netzbetreiber zu erproben.
Der openKONSEQUENZ-Gedanke
Das Zusammenspiel von existierenden und neuen Systemen hat dabei eine zentrale Bedeutung. Hier werden Chancen und Vorteile eines standardisierten Referenzarchitekturkonzeptes für Netzleitsysteme durch die modulare Entwicklung von flexiblen und konsortial entwickelten, quelloffenen Komponenten und deren Kopplung an kommerzielle, geschlossene Leitsysteme erforscht und exemplarisch demonstriert. Ein besonderer Schwerpunkt soll dabei auf der Gebrauchstauglichkeit von Benutzungsschnittstellen für das Leitwarten- und Servicepersonal liegen.
Darüber hinaus soll im Projekt untersucht werden, wie sich Open-Source-Governance-Prozesse zur Qualitätssicherung einer quelloffenen Referenzarchitektur sowie der entwickelten Open-Source-Module für sicherheitskritische Anwendungen übertragen lassen und wie Verwertungsmodelle für konsortial entwickelte Leitsystemkomponenten aussehen können. Als Initiator von NetzDatenStrom erwartet openKONSEQUENZ wichtige Beiträge zur modularen openKONSEQUENZ-Plattform.
Kick-Off
Das Projekt wurde am 27.10.2016 durch einen Kick-Off-Workshop der Projektpartner mit Vertretern von openKONSEQUENZ erfolgreich in den Räumlichkeiten des OFFIS (siehe Foto) gestartet. Die erste Aufgabe, die Big-Data-Anwendungsfälle genau zu spezifizieren, ist erledigt. Ein Übersicht über die Anwendungsfälle finden Sie weiter unten. Nun werden Technologien zur Umsetzung ausgewählt, welche die sich aus den Anwendungsfällen ergebenen Anforderungen erfüllen.
