Grundlegende technische Modellbeschreibung

Das entwickelte Modell für den Anwendungsfall des Parkhauses wird sowohl in einer deter-ministischen als auch in einer stochastischen Optimierung umgesetzt. Zusätzlich wird eine Monte Carlo Simulation für alle Ansätze angewendet, um die zugrundeliegenden stochasti-schen Profile der PV-Erzeugung, Elektrizitätspreise, Abfahrts- und Ankunftszeiten sowie die vor dem betrachteten Ladeprozess zurückgelegten Fahrdistanzen der E-Pkw abzubilden. Das gesamte Modell ist mit Python 3.6 implementiert. Dabei findet sowohl das Erstellen der Wahr-scheinlichkeitsverteilungen für die Fahrzeugflotten sowie das Einlesen der weiteren Inputpa-rameter und das damit verbundene Datenhandling, als auch die Implementierung der verschie-denen Modellvarianten statt. Das Modell besteht aus verschieverschie-denen hinterlegten Klassen und entsprechend definierten Methoden und Funktionen.

Für die Optimierung wird zum einen auf den Solver Gurobi 7.5 zurückgegriffen und zum an-deren auf einzelne Bibliotheken innerhalb von Python, die eine effiziente Gestaltung und Lös-barkeit des Modells ermöglichen. Der Gurobi Solver ist mit einem MIP Gap von 0,01 einge-stellt. Des Weiteren wurden der Thread und der Seed auf jeweils 1 gesetzt. Ansonsten wurden die meisten Grundeinstellungen des Solvers übernommen. Die Berechnungen wurden mit ei-nem Windows Betriebssystem und zum größten Teil auf eiei-nem Desktoprechner mit Intel i5-2500, 3,3 GHz, sowie 4 Threads durchgeführt. Der Arbeitsspeicher von 16 GB ist dabei schnell ausgelastet, obwohl nur ein Kern für das Multiprozessing vorgesehen wurde. Die Rechenzeiten können reduziert werden, wenn Rechner mit größerem Arbeitsspeicher verwendet werden.

Dieses geschieht aufgrund der Ausnutzung von mehreren Kernen und damit der Möglichkeit des parallelen Rechnens.

Die Output Daten werden in einer dokumentenbasierten NoSQL Datenbank (MongoDB) ge-speichert. Der Vorteil besteht u. a. darin, dass schon während des Schreibprozesses die Daten ausgelesen werden können. Zusätzlich gibt es aufgrund von schnelleren Lese- und Schreibe-zugriffen Geschwindigkeitsvorteile. Zum anderen war die dokumentenbasierte Struktur aber erforderlich, da die Daten nicht nur in Tabellenform, also in zweidimensionaler Form gespei-chert werden können, sondern die Arrays in mehreren Dimensionen vorliegen. Dieses hat zur Folge, dass die Auswertung etwas komplexer ist und die Dokumente entsprechend ausgepackt werden müssen. Des Weiteren ist MongoDB open source und die am weitesten verbreitetste NoSQL Datenbank (vgl. MongoDB, 2018). Als grafische Oberfläche dient die ebenfalls frei verfügbare Robo 3T (ehemals Robomongo), welche es ermöglicht, die sogenannten Collectio-nen (diese Strukturen enthalten die Dokumente) zu sichten und zu bearbeiten.

Zur Visualisierung der in der NoSQL Datenbank (MongoDB) gespeicherten Output Daten werden ebenfalls hauptsächlich verschiedene Bibliotheken von Python (seaborn, matplotlib) verwendet. Ein Teil der genutzten Bibliotheken innerhalb von Python ist in der Tabelle 5.3 dargestellt. Die Grundstruktur des Modells basiert insbesondere auf NumPy, SciPy und

Pan-Tupeln oder Dictionaries, die Modellierung und Implementierung vereinfacht. Ebenfalls eine Spezialbibliothek ist chaospy, die insbesondere für die Konstruktion von abhängigen, multiva-riaten Zufallsvariablen zum Einsatz kommt. Bei der Erstellung der multivamultiva-riaten PDF wird die Rosenblatt Transformation genutzt (vgl. Feinberg und Petter, 2015). Zur weiteren effizienten Umsetzung des Modells wurden z. B. Caches angewendet, um die Daten für die Erstellung der Wahrscheinlichkeitsfunktionen nicht jedes Mal neu einlesen und speichern zu müssen. Wei-terhin wurde ein paralleles Rechnen und die Nutzung von mehreren Kernen ermöglicht, da durch die Durchführung von vielen Simulationen die Parallelisierung gut möglich ist und die Rechenzeiten verkürzt.

Tabelle 5.3: Auszug der benutzten Bibliotheken in Python

Name Funktion

Statsmodels Datenanalyse und Statistik, Verteilungen

Random Zufallszahlenerzeugung

Scikitlearn Clustering, GMM und KDE

Gurobipy Optimierungssolver Schnittstelle

Chaospy LHS, Joint sampling

CVXPY Optimierung

Itertools Effiziente Iterationen

PyDOE Quasirandom sampling

Tinydb Zwischenspeicherung von Daten, Cache

Pymongo Datenbank Schnittstelle

Joblib Multiprocessing

Pickle Serialisierung von Objekten

Jupyter Notebook Browser-basiertes Tool, interaktiver Testbereich

Der Code und die ermittelten Ergebnisse werden mit mehreren Plausibilitätschecks überprüft und validiert. Darunter zählen z. B.:

 Überprüfung der Anzahl bedienter Ladeanfragen und dazugehörig die Einhaltung der gewünschten Mindesterfolgsquote,

 Ermittlung des gesamten Ladebedarfs und Überprüfung, ob identisch mit tatsächlicher eingeplanter Ladeenergie,

 Überprüfung jeder einzelnen Ladeanfrage bzgl. gewünschter Lademenge und erhalte-ner Lademenge,

 Test der Einhaltung von sowohl lokalem Ladelimit als auch globalem Ladelimit sowie

 Überprüfung der Einhaltung der gesetzten Limits des SOC.

Dadurch konnten mögliche Fehlerquellen eliminiert und die Konsistenz des Codes geprüft werden.

Tabelle 5.4: Überblick zu den Modellgrößen anhand der Anzahl der Variablen und durchschnittlichen Re-chenzeiten für die unterschiedlichen Strategien und Kundenanzahl

Anzahl Kunden Ansatz

75 150 225

Unkontrol- liertes Laden

Gleichungen/ Reihen 15.180 29.880 44.580

Stetige Variablen 7.617 14.892 22.242

Nicht-Null Elemente 36.930 73.380 109.830

Binäre Variablen 75 150 225

Lösungszeit, gesamt in Sekunden 0,02 0,05 0,07

MILP - Benchmark

Gleichungen/ Reihen 14.989 29.689 44.389

Stetige Variablen 7.596 14.796 22.146

Nicht-Null Elemente 36.792 73.392 109.992

Binäre Variablen 150 300 450

Lösungszeit, gesamt in Sekunden 1,45 5,55 6,37

MILP –Day- Ahead-Vo- raussicht

Gleichungen/ Reihen 14.989 29.689 44.389

Stetige Variablen 7.596 14.796 22.146

Nicht-Null Elemente 36.792 73.392 109.992

Binäre Variablen 150 300 450

Lösungszeit, gesamt in Sekunden 1,56 5,56 7,18

SMILP

Gleichungen/ Reihen 1.912.339 3.764.389 5.616.439

Stetige Variablen 950.121 1.876.146 2.802.171

Nicht-Null Elemente 4.674.117 9.276.042 13.877.967

Binäre Variablen 9.450 18.900 28.350

Lösungszeit, gesamt in Sekunden 338,44 1276,81 8656,83 Die Tabelle 5.4 stellt ein Beispiel für eine Parametrisierung mit einer Ladeleistung (z. B.

11 kW), einer Anschlussleistung (z. B. 200 kW), nur Sommerpreise sowie 125 SAA Szenarien

dar. Es wird in jedem Modell mit 150 Tagen in den Sommermonaten simuliert² und dement-sprechend vergrößert sich die Anzahl der Variablen sowie die Rechenzeiten linear. Die Mo-dellkomplexität vom SMILP erklärt sich aufgrund der Tatsache, dass im SMILP 125 SAA Szenarien enthalten sind, wodurch ein Vielfaches (Anzahl der SAA Szenarien) an Variablen benötigt wird. Das Verhältnis der Rechenzeiten ändert sich fast proportional zur Anzahl der gewählten Simulationsläufe. So beläuft sich die Rechenzeit beim SMILP Ansatz mit 150 Kun-den für eine Instanz auf ca. 21 Minuten, werKun-den die 150 Durchläufe betrachtet, sind es ca. 53 Stunden. Das sind die Rechenzeiten, wenn nur eine Parametrisierung betrachtet wird. Werden Listen von Parametern abgefragt (z. B. mehrere Anschlussleistungen), erhöht sich die Rechen-zeit entsprechend. Die Anzahl der Variablen steigt ebenfalls mit einer zunehmenden Kunden-anzahl, was für die verschiedenen untersuchten Methoden mit den drei Kundenkonstellationen von 75, 150 und 225 dargestellt wurde.