Gefahrenzone Atomkraftwerke

28. November 2023

Erarbeitet im Rahmen der Vorlesung „DBS“, während meines Studiums in AI/ML an der Hochschule Luzern

Data Use Case (SI)

Dieses Projekt ist entstanden in Kooperation mit:

Explain context & motivation

Wir wollten ein Projekt machen, welches nachhaltig einen Mehrwert generiert und auf einfachem Wege Leben schützen kann. Da Erdbeben katastrophale Auswirkungen auf nuklear betriebene Reaktoren haben können, fanden wir das Thema nicht nur interessant, sondern sahen auch die Chance einen Nutzen für die Gesellschaft bereitzustellen. Zusätzlich wollten wir, dass die Bewohner gefährdeter Gebiete dem Risiko, dem sie ausgesetzt sind, bewusst werden können. Ausserdem interessierte es uns auch selbst, ob es nahegelegene Reaktoren gibt, die für uns kritisch werden könnten.

Da bereits öffentliche Datenbanken von Erdbeben und auch nuklearen Anlagen zur Verfügung standen, war es sinnvoll diese Idee weiter zu verfolgen.

Define use case & data-based decision support (RW)

Aus zwei verschiedenen Datensets (Erdbeben & Atomkraftwerke) haben wir berechnet, welche Atomkraftwerke am stärksten einer Gefahr durch ein Erdbeben ausgesetzt sind.

Use case

Mithilfe der in der Datenbank verarbeiteten Daten, lässt sich leicht erkennen, an welchen Orten ein Atomkraftwerk demnächst abgeschaltet werden sollte. Weiter kann man mit den generierten Werten, den bereits durchgeführten Berechnungen und Tabellen auch beim Bau von künftigen Atomkraftwerken berechnen, welcher Gefahr diese ausgeliefert sind. Die Berechnungen lassen sich jedoch nicht nur auf Atomkraftwerke anwenden, sondern auch auf andere Bauwerke, die einer hohen Gefahr ausgesetzt sind oder verheerende Schäden anrichten können.

So könnte man beispielsweise bei einer Weiterführung des Projekts noch Staudämme und Ölplattformen miteinbeziehen. Wobei man für die Ölplattformen noch Daten von Tsunamis, als auch Stürmen in die Datenbank importieren könnte, sodass diese stets erweitert wird und die Daten bzw. Gefahren immer genauer abgebildet werden.

Data-Based decision support

Die Daten, welche wir von Kaggle bezogen haben, waren nicht nur quantitativ sehr gut, sondern auch qualitativ. Durch diese sauber angelegten Datensets war es uns möglich, mithilfe eines SQL Scripts, die Distanzen vom Epizentrum des Erdbebens bis zu eines jeden Atomkraftwerks zu berechnen. Mithilfe der Stärken, der einzelnen Erdbeben konnten wir recht gut abschätzen, welche Auswirkungen ein Erdbeben hat und in welchem Radius dieses Einfluss nimmt.

Um bei der Auswertung ein möglichst gutes Ergebnis zu erzielen, hat jedes Gruppenmitglied recherchiert und aufgrund der Erkenntnisse eine SQL Query geschrieben, sodass wir aus den verschiedenen Vorschlägen, die sinnvollsten Ansätze rausnehmen konnten und daraus die Gefahrenwerte generiert haben. Dies scheint auch ganz gut funktioniert zu haben, da Fukushima als dasjenige Kraftwerk eingestuft wurde, welches am stärksten gefährdet gewesen wäre.

Die Werte, die wir erhalten haben, waren zwar rein von den vorausgegangenen mathematischen Schritten sinnvoll, jedoch waren diese wenig aussagekräftig. So haben wir Rücksprache mit Herrn Kaufmann gehalten, welcher uns zur Integration einer “Fuzzy Logic” geraten hat. Aufgrund dieses Gesprächs haben wir die Werte normalisiert, sodass die Stärken der Erdbeben verrechnet mit den Distanzen einen Wert zwischen 1 und 0 ergeben. Dabei haben wir stark darauf geachtet, Werte, welche keinen Einfluss auf die Gefährdung eines Atomkraftwerks haben, zu ignorieren beziehungsweise gleich null zu setzen. Die Summen, die einen Wert grösser Null ergeben haben, haben wir pro Atomkraftwerk aufsummiert. Der daraus resultierende Wert war dann derjenige, welchen wir für das jeweilige Atomkraftwerk erhalten haben.

Select & justify data sources (KM)

Um Daten zu beschaffen, war unser erster Ansatz Kaggle.com. Zuerst mussten wir uns einen groben Überblick darüber verschaffen, welche Daten überhaupt zur Verfügung gestellt wurden. Dazu erforschten wir verschiedenste Datensets, die wir auf Kaggle gefunden haben.

Schon nach kurzer Zeit, fiel uns das Nuclear Powerplants Dataset auf, dass uns mit Informationen wie Name, Nation und den entsprechenden Koordinaten für jedes Atomkraftwerk der Erde versorgt. Zusätzlich waren noch einige Spalten dabei, die wir gar nicht benötigten.

Um eine Aussage über diese Atomkraftwerke machen zu können, suchten wir nach Daten, die mit den Daten der AKWs zusammen verwendet werden könnten. Spezifisch hiess das, wir suchten nach Datensätzen, die auf Geodaten basieren. Zu Beginn war noch offen, was wir genau mit den Atomkraftwerken vergleichen möchten, doch der beste Anwendungsfall ergab sich durch das Abgleichen von Erdbeben mit Kraftwerken. Die Edbeben im Datenset sind über die ganze Welt verteilt und haben mindestens eine Magnitude von 5.5.

In der Tabelle werden die Datensätze kurz miteinaner verglichen.

 AtomkraftwerkeErdbeben
Anzahl Einträge27523’412
Relevante SpaltenLatitude, Longitude, (Name)Latitude, Longitude, Magnitude, type
Quelle:https://www.kaggle.com/lian anapalkova/nuclear-power- plantshttps://www.kaggle.com/usgs/earthq uake-database

Wichtig zu erwähnen ist noch, dass in den Erdbeben-daten auch nukleare explosionen eingetragen sind, diese können aber mit dem type Attribut gefiltert werden.

Select & justify database technology (TS)

Für die Realisierung unseres Projekts haben wir die zwei folgenden Datenbanktechnologien in Betracht gezogen:

MySQL Server

Ein MySQL Server wäre als klassisches, relationales DBMS gut geeignet für unser Projekt. Weiter hatten einige Personen aus unserem Team bereits wenig Erfahrungen mit SQL-Systemen gemacht, was uns den Einstieg in die Arbeit etwas erleichtern würde.

Graphdatenbanken

Eine Graphdatenbank würde sehr gut zu unserer Problemstellung passen, da man die Position von AKWs und Erdbeben als Knoten und die jeweilige Distanz dazwischen als Kante abbilden könnte. Deshalb wäre die Performance möglicherweise besser als mit einem relationalen MySQL Server.

Entscheidung

Da wir überhaupt keine Erfahrung mit Graphdatenbanken mitgebracht haben, tendierten wir klar dazu, einen MySQL Server zu verwenden. Es gab jedoch ein Kriterium, welches für unsere Arbeit essenziell war: Die Möglichkeit eine Distanz zwischen zwei Punkten auf der Erde zu berechnen. Nach einer kurzen Recherche fanden wir heraus, dass dies mithilfe der Funktionen «POINT()» und

«ST_DISTANCE_SPHERE()» möglich ist. Deshalb entschieden wir uns dafür, einen MySQL Server zu verwenden. Im Nachhinein war das eine gute Entscheidung, denn wir konnten die in den ersten Wochen gelernten SQL Techniken direkt in unserem Projekt anwenden.

Hosting

Der nächste offene Punkt war die Frage, ob jeder die Datenbank bei sich lokal hosten soll oder ob wir einen Server beim Enterprise Lab beantragen sollen. Davon bevorzugten wir den EnterpriseLab Server, da so jeder auf die gleichen Datensätze zugreifen kann und Änderungen sofort für alle sichtbar sind. Dies hat die Kollaboration um einiges einfacher gestaltet. Das Beantragen einer Ressource und der Zugriff per VPN und Remotedesktop funktionierten recht flüssig, also entschieden wir uns dafür unseren MySQL Server auf dem Enterprise Lab zu hosten.

Tools

Zum Aufsetzen und Konfigurieren des Servers auf dem Enterprise Lab verwendeten wir die MySQL Workbench. Mit PulseSecure haben wir unsere Rechner Zuhause mit dem Netzwerk der HSLU verbunden. Danach konnten wir uns mit einem lokalen Datenbanktool mit unserem MySQL Server verbinden. Zuerst arbeiteten wir auch lokal mit der MySQL Workbench, wechselten aber später zu DataGrip, da wir bereits mit anderen Produkten von JetBrains vertraut waren und damit besser zurechtkamen.

Data Architecture, System & Migration (KM)


Build the system based on a clear system architecture

Das System läuft auf einem von der HSLU zur Verfügung gestellten Server. Auf jenem läuft ein Betriebssystem (Windows) und der MySQL Server, den wir für das Managen der Daten benötigen.

Auf diesemMySQL Server hat jedes Teammitglied von uns einen Benutzeraccount, mit welchem der jeweilige Benutzer Zugriffe auf das DBMS machen kann. Da der Server nicht im Internet erreichbar ist, muss über das HSLU Netzwerk zugegriffen werden.

Der initiale Datenimport kann über die “import CSV” Funktionalität ausgeführt werden.

Zum Schreiben und Ausführen der Queries wird DataGrip verwendet, da dies etwas intuitiver ist als die MySQL Workbench.

Um den Server initial einzurichten, haben wir windows Remote Desktop verwendet. Da der SQL- Server ab und an abstürzte, mussten wir manchmal über den Windows Remote Desktop einloggen und kurz den Service neu starten.

Define conceptual data model & database schema (SI)

Unser Ziel war es Datensätze zu finden, deren Werte bestimmten Koordinaten zugeordnet werden können. Die Datensets haben je einen Wert für aufgezeichnete Erdbeben und einen weiteren, der die bestehenden Reaktoren enthält. Auf diese Weise konnten wir Distanzen berechenen und die entsprechenden Werte in Relation setzten. Wir suchten auf kaggle.com und fanden zeitnahe geeignete Datensätze mit ausreichend Daten die glücklicherweise in passendem Format zur Verfügung standen. Zum Schluss sollte eine Liste entstehen die die Reaktoren entsprechend Ihrer Gefährdung ausgiebt.

Auf der oben gezeigten Graphik sieht man die einzelnen Attribute, welche für unsere Berrechnungen signifikant waren. Die beinhaltet im Groben die Daten zu den Erdbeben, den Reaktoren und den daraus resultierenden Distanzen.

Migrate existing data into the database (TS)

Datenimport

Die beiden .csv Dateien konnten mithilfe des Table Data Import Wizard der MySQL Workbench importiert werden. Zuerst versuchten wir dies über das Netzwerk in unserer lokalen Workbench. Dies dauerte aber eine gefühlte Ewigkeit (>1h für wenige %), obwohl unsere Datensätze überschaubar waren.

Wir testeten eine andere Herangehensweise, indem wir die Dateien auf unsere Enterprise Lab VM geladen haben und den Import danach per Remotedesktopverbindung von dort aus starteten.

Tatsächlich lief der Import so viel schneller, nach ca. 30min waren beide Tabellen importiert.

Tabellenindexierung

Für den einfacheren Zugriff auf die Tabellen benötigten wir für die einzelnen Einträge einen Index. Bei den AKWs gibt es bereits eine Nummerierung (FID). Bei den Erdbeben musste ein neuer generiert werden. Dies wurde mit folgenden Statements gemacht:

Generierung Distanzen Tabelle

Für die Auswertung der Daten benötigten wir die Distanzen zwischen Erdbeben und Atomkraftwerken. Dies konnten wir mithilfe der jeweiligen Koordinaten und den Funktionen POINT() und ST_DISTANCE_SPHERE() berechnen. Weiter brauchen wir nicht jede Distanz zu jedem AKW, weshalb wir in einem späteren Schritt alle Werte, bei denen die Distanz kleiner als 2000 km ist gelöscht haben, um eine bessere Performance zu erzielen.

Statements zum Generieren der Distanzen Tabelle:

Analyse the system architecture for its security protection (TS)

Systemarchitektur

Unser MySQL Server liegt auf einer Enterprise Lab VM, auf welchen wir mit Pulse Secure über das HSLU VPN zugreifen können. Es werden keine Ports nach aussen weitergeleitet. Dadurch ist sichergestellt, dass keine Verbindungen von ausserhalb des HSLU Netzwerks auf unsere Datenbank zugreifen kann.

Nutzer

Für alle Teammitglieder wurde ein eigener User erstellt, sodass wir nicht stets mit root Privilegien auf die Datenbank zugreifen müssen. Die Nutzer haben aber Lese- und Schreibzugriff, da wir auch neue Werte, wie beispielsweise die berechneten Distanzen, abspeichern möchten.

Verfügbarkeit

Das grösste Risiko für unser Projekt hätte wahrscheinlich darin gelegen, dass wir keinen Zugriff mehr auf die DB haben, weil keine Verbindung mit dem HSLU VPN möglich ist. Meistens funktionierte der Zugriff. Aber es gab vereinzelte Situationen, bei welchen der Zugriff nicht möglich war. Deshalb entschieden wir uns, dass mindestens ein Teammitglied die Datenbank auch lokal gesichert hat.

Fazit

Da der Zugriff auf unsere Daten nur für autorisierte Nutzer möglich ist, gehen wir davon aus, dass die Datensicherheit in unserem Projekt gewährleistet ist. Da es sich nicht um personenbezogene Daten handelt, gibt es in Bezug auf den Datenschutz keine Probleme. Des Weiteren sind unsere Datenquellen öffentlich zugänglich und es handelt sich nicht um heikle Daten.

Data Analysis

Develop a goal-oriented database query or analysis (KM)

Dank der Hilfsdatenbank ‘Distances’ kannten wir für alle Atomkraftwerk-Erdbeben-Paare die entsprechende Distanz, zwischen den Koordinaten des Erdbebens und des Atomkraftwerkes berechnen.

Für jedes dieser Paare, haben wir einen Faktor berechnet, den wir “Schlimmheit” bzw. Im Englischen dann “Severity” benannt haben. In einem ersten Schritt war der Faktor jeweils = 1/(distance**2) was lediglich bedeutet, dass nähere Erdbeben sehr viel schlimmer sind, als solche die weiter entfernt sind.

In einem nächsten Schritt haben wir die Magnitude des entsprechenden Erdbebens noch miteinberechnet. Dazu haben wir die Magnitude als Exponent zur Basis 2 (dies ist falsch, sollte 10 sein) weil das Ausmass des Erdbebens mit dem Aufsteigen um 1 auf der Richterskala um einen Faktor 10 grösser wird. In der zuvor erwähnten Formel wird der Zähler = 10**Magnitude gesetzt. So erhalten wir, dass der Wert der Severity für jeden Eintrag in Distances = (10**Magnitude)/(distance**2) wird.

Über diese Severity können wir nun mit einem “group by” Atomkraftwerk und verschiedenen Aggregatsfunktionen die Werte MAX, MIN, AVG, TOTAL- Severity für jedes Atomkraftwerk ermitteln.

Die Übersicht der Gruppierung mit allen Atomkraftwerken konnten wir jetzt lediglich noch absteigend nach total oder max severity sortieren.

Um bessere Aussagen darüber treffen zu können, wie stark die Gefährdung tatsächlich ist, haben wir uns entschlossen, zusätzlich eine “Fuzzy Logic” zu implementieren.

Dazu haben wir noch die Distances Table verwendet. Zuerst mussten die relevanten Grössen normalisiert werden. Die Distanzen wurden so gemappt, dass eine Distanz von 0 einen Wert von 1 ergibt und eine Distanz von 1000km einen Wert von 0 und Werte dazwischen werden linear gemappt.

Die Erdbebenstärke ist so gemappt, dass eine Erdbebenstärke von 5 einen normalisierten Wert von 0 ergibt, dies aufgrund dessen, dass ein Erdbeben der Stärke 5 keinen Einfluss auf ein Atomkraftwerk haben sollte.

Da Erdbeben schlimm sind wenn sie stark und nahe sind, können wir nach Fuzzy Logic die normalisierten Werte multiplizieren, um ein AND abzubilden. Der erhaltene Wert sagt aus, ob ein Erdbeben eine Grosse Gefahr für ein Kraftwerk darstellt (Wert nahe bei 1) oder nicht (Wert nahe bei 0). Durch das Aufsummieren dieser Gefahrenwerte, gruppiert nach Atomkraftwerken, können wir ein Ranking für die Gefährdung der Kraftwerke erstellen.

Analyse potential for performance optimization (RW)

Gerade als Anfänger, was die Arbeit mit MySQL, den Datenbanken und den zugehörigen Queries betrifft, haben wir viele Fehler gemacht. Entsprechend sind uns im Verlauf des Moduls immer wieder Punkte aufgefallen, die man auf andere, effizientere Weise hätte lösen können.

Da wir die Datenbank auf einem EnterpriseLab Server hosten, wäre die einfachste Variante einen leistungsfähigeren Server anzufordern, wäre aber auch die teuerste, wenn der Server nicht durch die Schule zur Verfügung gestellt werden würde.

Aufgrund dessen wäre die nachhaltigere Lösung die Datenbank gut zu strukturieren und die Queries so zu optimieren, dass diese möglichst schnell durchlaufen können.

Queries

Bei den verschiedenen angewendeten Queries hätte es bestimmt noch einiges an Potenzial gegeben. So beispielsweise bei der Query, bei welcher wir die finalen Stärkegrade in einem standardisierten Wert ausgegeben haben. Dort haben wir einen Index hinzugefügt, obwohl das Ziel war, die Endergebnisse zu erhalten. Da die Daten nicht weiterverwendet werden, hat dies länger gebraucht, als wenn wir ohne Index gearbeitet hätten.

Auch bei der Berechnung der Distanzen hätten wir von Beginn weg Distanzen mit einer Distanz grösser als 1000km weglassen können. Die Query lief bei der ersten Berechnung so, dass Distanzen, welche grösser als 2000km waren nicht beachtet wurden und erst bei einem zweiten Durchlauf wurden Distanzen grösser 1000km gelöscht. Hätte man direkt alle Distanzen grösser 1000km gelöscht, hätte die Query zwar etwas länger gedauert, man hätte aber das erneute Löschen sparen können.

Datenbank

Um Zeit bei der Erstellung der Tabellen einzusparen, hätten wir diese anstatt über den Import Wizard über eine SQL-Query mit dem Befehl “load data” importieren können.

Ebenfalls wichtig bei der Erstellung der Datenbank, wäre gewesen, dass wir den korrekten Datentyp verwenden, so sind viele Spalten im Textformat hinterlegt, obwohl es für diese ein besseres Format gegeben hätte. Beispielsweise haben wir ein Datum hinterlegt, welches als Text und nicht im Datumsformat gespeichert ist.

Dieses Datum wird nicht verwendet, weshalb dies nicht weiter schlimm ist, jedoch wäre die noch bessere Variante gewesen, dieses komplett zu löschen. Obwohl wir schon zu Beginn geschaut haben, welche Spalten wir löschen können, bzw. diejenigen, die Sinn machen würden, zu löschen, sind uns doch einige entgangen, die wir im Nachhinein nicht mehr gelöscht haben. So haben wir ca. drei Spalten, die einfach leer sind. Selbiges gilt für einige Zeilen, die nur die Werte “Null” enthalten und entsprechend auch hätten gelöscht werden können.

Weiter hätte man sich wie bereits im Abschnitt “Queries” erwähnt die eine Indexierung sparen können, da diese nicht weiterverwendet wird.

User-oriented visualization of the results (SI)

Wir wollten eine Library, die es uns ermöglicht, graphisch eine Karte darzustellen und mit entsprechenden Markern zu versehen. Hierfür sind wir auf die Library geopandas gestossen. Leider sind sämliche Windowsnutzer der Gruppe an der Installation gescheiteret. Auf Linux jedoch gelang die Installation und nach einigen Anläufen war es uns möglich die Liste mit den Distanzen auf der Karte darzustellen.

Der oben dargestellte Code zeigt den finalen Code zur visuellen Darstellung in Python. Die Libraries bieten viele intressante Möglichkeiten, so konnten wir nicht nur den Standort, sondern auch die Gefährdung in der gleichen Karte darstellen. (siehe nächste Graphik)

  • Die roten Punkte liegen jeweils auf den Reaktoren die in den Datasets aufgelistet waren.
  • Die Grösse des roten Punktes gibt Auskunft über die Risikogrösse eines betreffenden Reaktors.

Provide contextual decision support based on the data (RW)

Durch die Verwendung von qualitativ als auch quantitativ guten Daten, war es uns möglich diese optimal weiter zu verarbeiten. Resultierend haben wir gute Werte erhalten, welche die Gefahr, ausgehend von Erdbeben für ein bestimmtes Atomkraftwerk abbilden. Jedoch gilt es hier anzumerken, dass bei den Erdbeben nur solche mit einer Stärke von über 5 auf der Richterskala miteinbezogen wurden. Dies hat mitunter den Grund, dass Werte, welche kleiner sind, einem Atomkraftwerk nichts anhaben sollten. Weiter wurde auch der Zustand eines Atomkraftwerks nicht miteinbezogen. So hätte man beispielsweise ein Atomkraftwerk in schlechtem Zustand auch schon mit einem kleineren Wert der Richterskala verrechnen können. Aufgrund dieser fehlenden Informationen kann nicht zuverlässig abgeschätzt werden, wie stark genau dasjenige Atomkraftwerk gefährdet ist. Bei uns wurden alle Atomkraftwerke gleich bewertet, auch die Anzahl Reaktoren haben wir nicht miteinbezogen, was je nach Anzahl, bei einer Beschädigung einen massiv höheren Schaden nach sich ziehen würde.

Die politische Lage in einem Land wäre auch ein Faktor, den man in einem weiteren Schritt miteinbeziehen könnte, jedoch lässt sich dies nur schwer quantifizieren. So könnten Aufstände und Bürgerkriege den Betrieb des Atomkraftwerks beeinflussen und auch Korruption könnte den Bau oder die Abschaltung eines Atomkraftwerks an misslicher Lage behindern oder begünstigen.

Abschliessend lässt sich sagen, dass unsere Werte zwar gut und aussagekräftig sind, was die Gefahren aufgrund eines Erdbebens betrifft, aber dies sollten nicht die einzigen Faktoren sein, welche ausschlaggebend sein sollten, wenn es um die Einstufung der Gefahr eines Atomkraftwerks geht. Es gibt noch viele weitere Faktoren, die ebenso gefährlich oder noch gefährlicher sein könnten, die wir nicht miteinbezogen haben, man aber in weiteren Schritten oder bei einer professionellen Analyse (bspw. bei der Entscheidung, welches Atomkraftwerk abgeschaltet werden soll) nicht ausser Acht lassen sollte.

Reti

Als Webentwickler und begeisterter AI-Student bin ich immer auf der Suche nach neuen Projekten. Ob Websites gestalten, Apps entwickeln oder Algorithmen optimieren, ich bin stets bereit, mich neuen Herausforderungen zu stellen.