Fachhochschule AachenFachbereich 9 - Medizintechnik und Technomathematik

SEMINARARBEIT IM STUDIENGANG „SCIENTIFIC PROGRAMMING“

EXTRAKTION UND VISUALISIERUNG DER

TOPOLOGIE EINES ENERGIENETZES AUS DATEN IM

CGMES-FORMAT

Eingereicht von

Jan Grünenwald

Matrikel-Nummer:

3119768

1. Prüfer: Prof. Dr.-Ing. Klaus Drechsler2. Prüfer: Arne Bernhardt Aachen, 29. Januar 2019

Eidesstattliche Erklärung

Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema „Extraktion undVisualisierung der Topologie eines Energienetzes aus Daten im CGMES-Format“selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfs-mittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinn-gemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oderähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war.Ich verpflichte mich, ein Exemplar der Seminararbeit fünf Jahre aufzubewahren undauf Verlangen dem Prüfungsamt des Fachbereiches Medizintechnik und Techno-mathematik auszuhändigen.

Name: Jan Grünenwald

Aachen, den 29. Januar 2019

Unterschrift des Studenten

2

INHALTSVERZEICHNIS

1 Einleitung und Motivation 4

2 Ausgangssituation 52.1 RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 CGMES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Anforderungen 103.1 Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Länge der Linienwege . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Umsetzung 124.1 Technische Überlegungen . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1.1 Einliniendiagramme . . . . . . . . . . . . . . . . . . . . . . . 124.1.2 Technisches Zeichnen . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Implementierung des Algorithmus . . . . . . . . . . . . . . . . . . . 144.2.1 Zuordnung von Daten zu Schaltanlagen . . . . . . . . . . . . 144.2.2 Erstellen des DiagramLayout-Profils . . . . . . . . . . . . . . 15

5 Fazit und Ausblick 19

Literaturverzeichnis 19

Listenverzeichnis 24

3

KAPITEL 1

EINLEITUNG UND MOTIVATION

Energienetze sind das Rückgrat der Wirtschaft jeder modernen Industrienation.Ohne sie stehen Fabriken still, Züge fahren nicht und Computer funktionieren nicht.Mit der zunehmenden Digitalisierung der Gesellschaft werden auch außerhalb derIndustrie die Abhängigkeiten vom elektrischen Netz immer größer. Selbst Kranken-häuser sind inzwischen völlig von Computern in ihren administrativen Strukturenabhängig. Ohne sie fallen Geräte und Datenverwaltung aus.

Die Stabilität dieser Netze zu gewährleisten, wird sowohl durch ihre wachsendeKomplexität als auch durch die Energiewende immer schwieriger. Der vermehrteEinsatz von sogenannten dezentralen Erzeugungsanlagen führt zunehmend dazu,dass der Fokus der Energieerzeugung weg von einzelnen und leistungsstarken hinzu weit verteilten kleinen Erzeugern geht. Diese müssen alle separat an das Netzangebunden werden.[6]

Aufgrund der beschriebenen Anforderungen ist es somit von Seiten der Netzbe-treiber nötig, die Netze zu überwachen. Bei erkennbaren akuten oder voraussicht-lichen Überbelastungen sollen sie Maßnahmen einleiten, um die Stabilität des Net-zes zu gewährleisten. Dabei helfen die Anbieter von Software - der komplexe Auf-bau eines Netzes mit seiner Vielzahl an Komponenten mit unterschiedlichen Be-lastungsgrenzen kann durch Software zur Visualisierung auf diejenigen Aspekteherunter gebrochen werden, die zu dem jeweiligen Zeitpunkt für den Beobachtervon Interesse sind. Ein Algorithmus, der dies ermöglicht, soll im Rahmen dieserArbeit implementiert werden, sodass mit Fertigstellung der Seminararbeit einzelneSchaltanlage visualisiert werden können.

4

KAPITEL 2

AUSGANGSSITUATION

2.1 RDF

Resource Description Framework (RDF) bezeichnet ein Framework zur Beschrei-bung von Ressourcen.[9] Relationen zwischen Objekten und Zustandsbeschrei-bungen folgen dabei stets dem simplen grammatikalischen Schema Subjekt →Prädikat → Objekt. Hauptgrund für den Gebrauch von Graphendarstellungen istdabei die hohe Ähnlichkeit, die ein reales Energienetz zu seiner Darstellung in ei-ner Graphendatenbank bietet.

Im Kontext des Projekts findet RDF Verwendung in Form von Apache Jena, wel-ches eine Schnittstelle bietet, um auf einem Apache Jena Fuseki[1] Server Da-ten aus RDF-Graphen (auch Triplestores genannt) abzufragen. Dabei ermöglichtApache Jena Abfragen auf der Datenbank mit enorm guter Zeitkomplexität, da dieDaten in der internen Verwaltung mit hoher Redundanz vorliegen. Das bringt alsNachteil mit sich, dass Daten ein Vielfaches des Speicherbedarfs haben, den siein Darstellung in Form einer relationalen Datenbank hätten. Der Speicherbedarf istdadurch zwar massiv erhöht, aber da die Anwendung auf einem dedizierten Serverläuft und die Laufzeit in der Praxis das deutlich größere Problem darstellt, führt diesnicht weiter zu Komplikationen. Als Abfragesprache nutzt Apache Jena das speziellfür RDF-Graphen entwickelte SPARQL Protocol and RDF Query Language (SPAR-QL)[10].

5

KAPITEL 2. AUSGANGSSITUATION

Subjekt Prädikat ObjektX X XX XX XX

X XX

X

Tabelle 2.1: Schematische Darstellung der In-Memory-Ablage von Daten in ApacheJena Fuseki.

2.2 CGMES

Die im Rahmen dieser Seminararbeit zu verarbeitenden Daten liegen im CommonGrid Model Exchange Specification- (CGMES)-Format in Form von .xml-Dateienvor. Dieses Format wurde durch die European Network of Transmission SystemOperators for Electricity (ENTSOE) spezifiziert und implementiert den StandardCommon Information Model (CIM), um so die Kommunikation der europäischenNetzbetreiber untereinander zu vereinfachen. Die Daten liegen in dieser Spezifika-tion im RDF-Schema vor und nutzen die im CIM beschriebenen objektorientiertenKlassen.

Ein gegebener CGMES-Datensatz besteht aus einer Menge von Profilen. Unter-schieden werden dabei neun Standardprofile. Von denen finden aber im Kontextdieser Arbeit nur die für die Lastflusssimulation notwendigen Profile Verwendung.Diese sind die Profile EQ, SV, SSH und TP sowie das GL-Profil zur relativen Positio-nierung der Schaltanlagen zueinander. Sie sollen im Rahmen dieser Arbeit genutztwerden, um aus ihnen ein DiagramLayout-Profil zu generieren. Nachfolgend wer-den die Profile aufgelistet und kurz erläutert:[3]

• ’EQ’: Equipment; die (teilweise abstrahierten) Ausrüstungs- und Container-objekte des Datensatzes.

• ’TP ’: Topological; Schaltzustand eines Netzes mit der resultierenden elektri-schen Topologie.

• ’SSH ’: Steady State Hypothesis; enthält Informationen über den angenom-

6

KAPITEL 2. AUSGANGSSITUATION

menen Netzzustand.

• ’SV ’: State Variables; Ergebnisse der Lastflussberechnungen des Systems.

• ’DL’: Diagram Layout; Zeichenanweisungen für ein Diagramm für diesen Da-tensatz.

• ’GL’: Geolocation; gibt die Breiten- und Längengrade von Equipment an.

Die Klassen gemäß CIM repräsentieren reale und abstrahierte Objekte mit eini-gen Vererbungshierarchien. So handelt es sich zum Beispiel bei jeder Solaranlageum eine Strom erzeugende Einheit. In den RDF-Strukturen erbt die Klasse Solar-GeneratingUnit daher sämtliche Eigenschaften der GeneratingUnit. Grundsätzlichwird unterschieden zwischen Equipment- und Containerobjekten. Bei Containernhandelt es sich um Objekte wie Spannungsebenen oder Schaltanlagen, währendEquipmentobjekte reale Ausrüstungsgegenstände wie beispielsweise Spannungs-transformatoren oder Leitungen repräsentieren.

7

KAPITEL 2. AUSGANGSSITUATION

Abbildung 2.1: UML-Klassendiagramm der Container im CIM.

Da im CIM Abstraktionen auf verschiedenen Ebenen getroffen werden, zeichnetsich das Modell jedoch durch einige Besonderheiten aus. So existiert zwischenzwei verbundenen Equipmentobjekten immer ein Terminalobjekt, für welches nocheinmal eigene Relationen spezifiziert sind. Bei einem Terminal handelt es sichum einen elektrischen Verbindungspunkt an einem ConductingEquipment, also ei-nem Strom leitenden Ausrüstungsgegenstand. Des Weiteren bietet CGMES unter-schiedliche Formen der Energienetz-Modellierung. In der Praxis relevant sind dabeidie beiden Modelle Bus Branch und Node Breaker.

8

KAPITEL 2. AUSGANGSSITUATION

Beide beschreiben ein Netz in seinen Strukturen, aber im Bus Branch ist die Dar-stellung auf eine Knoten-Zweig-Abbildung herunter gebrochen, um so die Infor-mationsdichte zu reduzieren. Im Node Breaker werden dabei die Informationendargestellt, indem jedes Terminalobjekt mit einem ConnectivityNode verbunden ist.Dieser ConnectivityNode beschreibt einen Punkt, an dem Terminals von Wech-selstrom leitenden Ausrüstungsgegenständen quasi impedanzlos miteinander ver-bunden sind und verfügt über eigene Assoziationen, so wie beispielsweise einenContainer, in dem der Punkt liegt.

Im Gegenzug enthält ein Datensatz im Bus Branch-Format keine Connectivity-Nodes. Stattdessen werden dort die Informationen über Assoziationen zu den To-pologicalNodes im TP-Profil abgebildet. Ein solcher TopologicalNode ist eine Ab-straktion und fasst eine Menge von ConnectivityNodes zusammen, welche im ge-genwärtigen Schaltzustand miteinander verbunden sind (damit ändern sich also beieiner Änderung des Schaltzustandes auch die TopologicalNodes).

9

KAPITEL 3

ANFORDERUNGEN

3.1 Laufzeit

Der zu implementierende Algorithmus soll auf einem Server in einer Anwendungausgeführt werden, welche die Darstellung einer Vielzahl von Schaltanlagen er-möglicht. Beim Start der Anwendung wird ein gegebener Datensatz geladen. ImBackend soll dann der Algorithmus ausgeführt werden, um für den gesamten Da-tensatz ein Diagrammlayout zu erzeugen, welches vom Frontend des ausführendenBenutzers auf Anforderung genutzt werden kann, um das beschriebene Diagramm-layout umzusetzen und zu zeichnen.

Wichtig ist dabei, dass der Arbeitsschritt der Erkennung von einzelnen Schaltan-lagen nicht zu lange dauert. Da das Ergebnis der Seminararbeit in ein größeresProjekt eingebunden werden soll, in dessen Rahmen mehrere Schaltanlagen verar-beitet und visualisiert werden sollen, muss besonders auf die Laufzeit der Abfragengeachtet werden, da es in der Praxis möglich sein muss, enorm große Datensät-ze mit Informationen zu mehreren Hundert bis Tausend Schaltanlagen einzulesen.Gesetzte Bedingung ist dabei, dass ein Datensatz mit bis zu 10’000 Schaltanla-gen in unter zehn Sekunden verarbeitet werden können sollte. Außerdem soll dasZeichnen einer beliebig großen Schaltanlage nicht mehr als ein bis zwei Sekun-den in Anspruch nehmen. Hierbei hilft besonders die Verwendung des Apache Je-na Frameworks zusammen mit dem Fuseki Server. Die enorm großen Datensätzestrapazieren zwar den Speicher des Servers, belasten ihn aber nach bisherigenBeobachtungen nicht zu sehr.

10

KAPITEL 3. ANFORDERUNGEN

3.2 Darstellung

3.2.1 Länge der Linienwege

Das fertige Liniendiagramm besteht aus einer Menge von Knoten, die miteinanderverbunden sind und eine Schaltanlage bilden. Beim Laden eines Datensatzes istnoch nicht klar, wie die topologische Struktur des Netzes aussieht. Der Algorith-mus muss daher auch im Rahmen der Weiterverwendung für das Zeichnen ganzerNetze in jeder Situation ein optisch ansprechendes und hilfreiches Diagramm er-zeugen. Ein wichtiges Kriterium dafür ist die Länge der Linienwege.

Diese sollten so kurz wie möglich sein, was impliziert, dass miteinander verbundeneSchaltanlagen näher beieinander liegen als solche, die nicht miteinander verbun-den sind. Da hier ein Konflikt zu dem Wunsch vorliegt, benachbarte Schaltanlagenauch im Diagramm nah beieinander zu zeichnen, kann dies bei großen Datensät-zen dazu führen, dass hinsichtlich der Linienlänge priorisiert werden muss, welcherder beiden Faktoren wichtiger ist.

3.2.2 Erweiterbarkeit

Während im Kontext der Seminararbeit nur ein Algorithmus zur Anordnung einereinzelnen Schaltanlage entwickelt wird, soll darauf geachtet werden, diesen er-weiterbar für zu Beginn geäußerte Wünsche zu gestalten. Dazu gehören vor allemLayering sowie die Handhabung von Linienüberschneidungen:

• Layering der visualisierten Informationen: bei gezieltem Blick auf einen klei-nen Teil des Gesamtnetzes ist es wichtig, alle relevanten Informationen überdie zu visualisierenden Komponenten sehen zu können. Bei weiträumigeremBlick über ein großes Teilnetz würde das Diagramm durch zu viele Informa-tionen überladen und so die Detaildichte reduziert werden.

• Handhabung von Linienkreuzungen: Kreuzungen von Linien werden zunächstnicht gesondert behandelt, da sie für die Visualisierung einzelner Schaltan-lagen keine Rolle spielen. Bei der Darstellung ganzer Netze sollten sie aberalgorithmisch behandelt und ihre Anzahl minimiert werden.

11

KAPITEL 4

UMSETZUNG

4.1 Technische Überlegungen

4.1.1 Einliniendiagramme

Bei einem Einliniendiagramm (auch Single-line diagram) handelt es sich um einDiagramm zur vereinfachten Darstellung eines 3-phasigen Stromnetzes. Dabei sindalle für den Kontext der Anwendung relevanten Komponenten über eine einzige Li-nie verbunden, die so den Aufbau des Netzes visualisiert.[7]

4.1.2 Technisches Zeichnen

Die zu zeichnenden Einliniendiagramme sollen Energienetze darstellen, die eineVielzahl von Komponenten enthalten. Da diese von jedem Elektroingenieur gele-sen werden können müssen, sollte man sich dabei an die standardisierten Symbo-le für Komponenten im technischen Zeichnen halten. Diese sind in der DIN-Norm40900 Teil 6, Schaltzeichen für die Erzeugung und Umwandlung elektrischer Ener-gie, festgehalten[4]. Bei den zu zeichnenden Bauteilen handelt es sich um Lasten,Erzeuger, Transformatoren, Leitungen, Sammelschienen, Trenner, Leistungsschal-ter sowie Spannungs- und Leistungsflussangaben.

12

KAPITEL 4. UMSETZUNG

Abbildung 4.1: Simples Einliniendiagramm mit Datenstrukturen des CIM.

Quelle: Alan McMorran B.Eng. Ph.D., CIM Network Model

Außerhalb dieser Normen können weitere Möglichkeiten der gezielteren Visualisie-rung von Details gewählt werden. So ist es beispielsweise möglich, die Linien jederSpannungsebene mit einer eigenen Farbe zu zeichnen.

13

KAPITEL 4. UMSETZUNG

4.2 Implementierung des Algorithmus

4.2.1 Zuordnung von Daten zu Schaltanlagen

Zunächst müssen die im RDF-Format vorhandenen Daten zu sinnvollen Struktu-ren verarbeitet werden. Ein geladener Datensatz kann beliebig viele Schaltanlagenenthalten, daher muss zur Visualisierung des Datensatzes zunächst ermittelt wer-den, welche Schaltanlagen welcher Größe mit welchen Verbindungen existieren.

Das erweist sich aufgrund der verschiedenen Formen der Datensatz-Modellierungenjedoch als komplexe Aufgabe, da der Algorithmus sowohl auf dem Busbranch- alsauch auf dem Nodebreaker-Modell arbeiten können muss. Da beide Modelle einensehr unterschiedlichen Aufbau aufweisen, muss der Algorithmus daher zweigeteiltimplementiert werden. Abhängig davon, ob die Daten im Node Breaker - oder BusBranch-Modell vorliegen (erkennbar daran, ob das EQ-Profil ConnectivityNodesenthält) weist der Algorithmus die Schaltanlagenelemente dann unterschiedlich zu.

Die Handhabung des Node Breaker -Modells ist dabei deutlich einfacher. Aufgrundder klaren Assoziation Equipment - Terminal - ConnectivityNode können in die-sem Modell sehr leicht zueinander gehörige Ausrüstungsgegenstände identifiziertwerden. Wenn sie nicht direkt als Attribute des Objektes gegeben sind, können Ei-genschaften oder direkte Verbindungen (beispielsweise der zugehörige Container)an dem zugehörigen Terminal oder an dessen verbundenem ConnectivityNode ab-gelesen werden.

Hier können Schaltanlagen zugewiesen werden, indem beliebige Ausrüstungsge-genstände als Startpunkte individueller Schaltanlagen angenommen und mit all ih-ren mittelbaren Nachbarn (ausgenommen ACLineSegmente, da diese immer eineVerbindung zweier Schaltanlagen darstellen) verbunden werden. Sobald ein Aus-rüstungsgegenstand oder Container in zwei angenommenen Schaltanlagen vor-kommt, welcher sich aber nur in einer befinden kann, werden die beiden Schaltan-lagen zusammengefügt und der Prozess wird nach dem gleichen Schema weiter-geführt, bis alle Objekte des Datensatzes eingetragen sind.

Datensätze im Bus Branch-Modell können ähnlich gehandhabt werden. Dort wer-den die Informationen nicht mehr aus der Relation Equipment - Terminal - Connec-

14

KAPITEL 4. UMSETZUNG

tivityNode entnommen, sondern aus den TopologicalNodes, auf die einzelne Ter-minals zeigen. Da diese TopologicalNodes die ConnectivityNodes des Node Brea-ker -Modells zusammenfassen und ersetzen, ist hier das Schema, nach welchemdie Schaltanlagen zugewiesen werden, ansonsten weitgehend unverändert.

4.2.2 Erstellen des DiagramLayout-Profils

Sobald aus dem Gesamtdatensatz die vorhandenen Schaltanlagen entnommenund zugeordnet wurden, muss das Schema aufgebaut werden, mit dem darzustel-lenden Elemente gezeichnet werden können. Dies geschieht in der letztlich vor-handenen Implementation in vier Schritten:

1. Es wird ein Baum aufgebaut, in den die Elemente des Diagramms Schrittfür Schritt eingebaut werden, um so die zu zeichnenden Verbindungen zunotieren. Dafür wird der Baum mit einem leeren Element als Wurzel instan-tiiert. Als erstes Kind wird die Sammelschiene mit der höchsten Spannunggewählt. Das können auch mehrere sein, wenn mehrere Sammelschienenmit der gleichen Spannung existieren. Dann wird von diesen Elementen aus-gehend Schritt für Schritt durch die Schaltanlage gelaufen und die zu ver-bindenden Elemente eingeordnet. Für diesen Zweck wurden zwei Klassenkonzeptioniert und implementiert:

• NodeObject : Repräsentiert die Objekte des Datensatzes innerhalb desGraphen. Diese Datenstruktur beinhaltet Informationen zu Informationenwie der benötigten Größe, der Position oder der Orientierung des Dia-grammelements, das durch sie repräsentiert wird. Es enthält außerdemAngaben darüber, welche Arten von Objekten mit einem NodeObjectverbunden sind, um so den Zeichenprozess in späteren Schritten zu er-leichtern.

• SortedMutableGraph: Eine Erweiterung der Klasse MutableGraph ausdem Paket Guava von Google. Die Elemente dieses Graphen imple-mentieren alle das Interface Comparable und sorgen so dafür, dass denElementen des Graphen ähnlich einem sortierten Baum eine klare Rei-henfolge zugewiesen werden kann. Zudem handelt es sich um eine ver-änderliche Datenstruktur, sodass der Graph Schritt für Schritt aufgebautwerden kann.

15

KAPITEL 4. UMSETZUNG

Der Graph wird dabei von oben nach unten gezeichnet, und bei den gezeich-neten Linien handelt es sich um die verbindenden Terminals zwischen einzel-nen Objekten.

2. Der Graph wird von der Wurzel bis zu jedem Blatt durchlaufen und auf denNodeObjects werden Attribute gesetzt, die in dem nächsten Schritt dazu die-nen, den Platzbedarf und die Position der Elemente zu bestimmen. Es wirddabei für jedes Objekt gesetzt, ob dieses bis zur nächsten Sammelschienemit Ausrüstungsgegenständen wie einem Transformator oder einer stromer-zeugenden Einheit verbunden sind. Außerdem wird bei von Dreifachwicklernausgehenden Pfaden gesetzt, ob diese horizontal gezeichnet werden müs-sen.

3. Es wird die Größe der Elemente und ihr Platzbedarf in Berücksichtigung ihrergesamten Umgebung innerhalb des Graphen betrachtet. Für jedes Elementwerden dabei seine Nachfolger und Vorgänger auf ihren Platzbedarf unter-sucht und das Element dementsprechend eingeordnet und skaliert. Die Sor-tierung geschieht dabei über die Implementation der compareTo()-Methodeder NodeObject-Klasse. Als Wurzelknoten wird die Sammelschiene mit demhöchsten Spannungslevel gewählt, woraufhin die Knoten nach folgendem Sche-ma sortiert werden:

(a) Trenner, die Mehrfachsammelschienen verbinden

(b) Objekte, die mit einem Transformator verbunden sind

(c) Objekte, die mit einem Erzeuger verbunden sind

(d) Objekte, die mit einer Last verbunden sind

(e) Objekte, die mit einer Leitung verbunden sind

(f) Objekte, die mit einem Parallelkompensator verbunden sind

4. Zuletzt wird anhand der Struktur der Schaltanlagen und der Größe ihrer zuzeichnenden Elemente bestimmt, wo sie positioniert werden. Dies geschiehtwieder über iteratives Durchlaufen des Graphen. Dabei wird für jede Sam-melschiene, an der andere Knoten hängen, die Menge und Größe ihrer Vor-gänger und Nachfolger betrachtet und zu ihrer Summe die aufsummiertenAbstände addiert, die zwischen den einzelnen Knoten existieren müssen.

16

KAPITEL 4. UMSETZUNG

Abbildung 4.2: Ein Musterbild, das aus einem kleinen Datensatz generiert wurde(mit Platzhaltericons).

Die so aufgestellte Datenstruktur kann nun serialisiert und beispielsweise im CGMES-Format als .xml-Datei geschrieben werden. Dieses Format besteht aus den Klas-sen Diagram, DiagramObject und DiagramObjectPoint, welche über ihre Verknüp-fungen ein eindeutiges zu zeichnendes Bild beschreiben.

1 <cim:DiagramObject r d f : I D =" _15638084−e047−7b07−f847−ef105282ae25 ">

2 < c i m : I d e n t i f i e d O b j e c t . name>L3_b< / c i m : I d e n t i f i e d O b j e c t . name>

3 <cim:DiagramObject . r o t a t i o n >0< / cim:DiagramObject . r o t a t i o n >4 <cim:DiagramObject . I d e n t i f i e d O b j e c t r d f : r e s o u r c e =" #

_05597934−b248−491e−803a−68ce6290f502 " / >5 <cim:DiagramObject . Diagram r d f : r e s o u r c e =" #_e410e806−f410

−3450−b721−4a38b5d75314 " / >6 <cim:DiagramObject . DiagramObjectSty le r d f : r e s o u r c e =" #

_4eaf50bb−c04b−89f2−05f5−e56e744eec7a " / >

17

KAPITEL 4. UMSETZUNG

7 < / cim:DiagramObject>8 <cim:DiagramObjectPoint r d f : I D =" _c12e265b−0c51−a8d4−7f3a−

bde1f6403f8a ">9 <cim:DiagramObjectPoint . sequenceNumber>1< /

c im:DiagramObjectPoint . sequenceNumber>10 <cim:DiagramObjectPoint . xPos i t i on >150.20282< /

c im:DiagramObjectPoint . xPos i t i on >11 <cim:DiagramObjectPoint . yPos i t i on >113.906876< /

c im:DiagramObjectPoint . yPos i t i on >12 <cim:DiagramObjectPoint . DiagramObject r d f : r e s o u r c e =" #

_15638084−e047−7b07−f847−ef105282ae25 " / >13 < / c im:DiagramObjectPoint>14 <cim:Diagram r d f : I D =" _e410e806−f410−3450−b721−4a38b5d75314 ">15 < c i m : I d e n t i f i e d O b j e c t . name>Diagram< / c i m : I d e n t i f i e d O b j e c t .

name>16 <cim:Diagram . o r i e n t a t i o n r d f : r e s o u r c e =" h t t p : / / i ec . ch / TC57

/2013/CIM−schema−cim16# Or ien ta t i onK ind . negat ive " / >17 < / cim:Diagram>

Listing 4.1: Ausschnitt eines beispielhaft generierten DL-Profils

18

KAPITEL 5

FAZIT UND AUSBLICK

Zu Beginn der Seminararbeit bestand der Wunsch, Datensätze zu beliebigen Net-zen im CGMES-Format einlesen, als DL Profil schreiben und auf eine spezifizierteArt darstellen zu können. Dies sollte unabhängig von konkreteren Feinheiten inden gegebenen Daten möglich sein, da verschiedene Kunden der SOPTIM un-terschiedliche Daten in ihren Datensätzen festhalten. Diesem Wunsch konnte vollentsprochen werden. Zum Ende der Seminararbeit steht ein Algorithmus zur Ver-fügung, der alle getesteten Datensätze im Node Breaker - und Bus Branch-Formatlesen und zeichnen kann.

Zukünftig kann also die vorhandene Basis genutzt werden, um nicht nur eine einzel-ne Schaltanlage, sondern ein gesamtes Netz zu zeichnen, mit allen Verbindungenseiner einzelnen Schaltanlagen untereinander. Dafür wird der verwendete Algorith-mus angepasst werden müssen, da die optimale Darstellung der Linienwege ineiner isolierten Schaltanlage in vielen Fällen nicht mehr optimal sein wird, sobalddas Szenario um viele miteinander verbundene Schaltanlagen erweitert wird.

Desweiteren kann der implementierte Algorithmus zusätzlich erweitert werden -schließlich ist die gesamte elektrische Topologie des Netzes für den Nutzer vonInteresse. An dieser Stelle ist das in 3.2.2 erwähnte Layering relevant - dem Benut-zer kann die Möglichkeit geboten werden, eine “Schicht“ auszuwählen, woraufhinzusätzlich zu dem sichtbaren Netz alle Informationen dieser Schicht gezeichnetwerden.

19

LITERATUR

[1] Apache Jena Fuseki. url: https : / / jena . apache . org / documentation /

fuseki2/ (besucht am 24. 01. 2019).

[2] Common Grid Model Exchange Standard (CGMES) Version 2.4. ENTSOE.Mai 2014. url: https://docstore.entsoe.eu/Documents/CIM_documents/Grid_Model_CIM/140528_ENTSOE_CGMES_v2.4.14.pdf (besucht am 19. 12. 2018).

[3] Common Information Model (CIM) for Grid Models Exchange. ENTSOE. url:https://www.entsoe.eu/digital/common-information-model/cim-for-

grid-models-exchange/ (besucht am 19. 12. 2018).

[4] DIN-40900-6, Graphische Symbole für Schaltungsunterlagen; Schaltzeichen fürdie Erzeugung und Umwandlung elektrischer Energie. url: https://www.din.de/de/mitwirken/normenausschuesse/fsf/normen/wdc- beuth:din21:

3094104 (besucht am 24. 01. 2019).

[5] DKE - CIM Informationsveranstaltung. Siemens. Okt. 2015. url: https://www.dke.de/resource/blob/780546/d2e7505437e45cb4e344b58baa3319fb/

04-was-ist-cim-ruediger-data.pdf (besucht am 19. 12. 2018).

[6] Cluster EnergieForschung.NRW und Cluster Informations- und Kommunikati-onstechnologie.NRW. Intelligente Energienetze. https://broschueren.nordrheinwestfalendirekt.de/herunterladen/der/datei/cef- ikt- 2014- pdf/von/intelligente-

energienetze-forschungsfelder-und-akteure-aus-nordrhein-westfalen/

vom/energieagentur/1818. 2014.

[7] T. McAvinew und R. Mulley. Control System Documentation. ISA, 2004. isbn:1-55617-896-4.

20

LITERATUR

[8] Alan McMorran B.Eng. Ph.D. CIM Network Model. 2014. url: https://cimug.ucaiug.org/Meetings/Oslo2014/Presentations/CIM%20University/

Track%202/CIM%20UG%202014%20Network%20Modelling.pdf.

[9] RDF. W3C. url: https://www.w3.org/RDF/ (besucht am 24. 01. 2019).

[10] SPARQL Query Language for RDF. url: https://www.w3.org/TR/rdf-sparql-query/ (besucht am 24. 01. 2019).

21

TABELLENVERZEICHNIS

2.1 Schematische Darstellung der In-Memory-Ablage von Daten in Apa-che Jena Fuseki. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Tabellenverzeichnis 22

22

ABBILDUNGSVERZEICHNIS

2.1 UML-Klassendiagramm der Container im CIM. . . . . . . . . . . . . 8

4.1 Simples Einliniendiagramm mit Datenstrukturen des CIM. . . . . . . 134.2 Ein Musterbild, das aus einem kleinen Datensatz generiert wurde

(mit Platzhaltericons). . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Abbildungsverzeichnis 23

23

LISTENVERZEICHNIS

4.1 Ausschnitt eines beispielhaft generierten DL-Profils . . . . . . . . . . 17

24