Die Projektdokumentation ist im Rahmen des Masterstudiums an ...

Die Projektdokumentation ist im Rahmen des Masterstudiums an der
Carl von Ossietzky Universität Oldenburg, Abteilung Business Engineering entstanden
Projektauftrag:
Projektträger:
Vorgelegt von:
apl. Prof. Dr.-Ing. Jürgen Sauer
Dipl.-Inform. Jan-Hinrich Kämper
Nashida Barakat
Georg Berendt
Carsten Buschmann
Khisrav Evazov
Shimal Ibrahim
Raphaël François Kaiser
Svetlana Kapitonova
Christian Menne
André Wolter
Stefan Wunderlich
Projektabgabe: 30. September 2013

Abstract der Studenten
In den zukünftig zahlreichen Offshore-Windenergieparks Deutschlands wird die Planung
der Wartungseinsätze gerade bei steigender Anzahl der Windenergieanlagen zu einer
immer größeren Herausforderung. Die bisher fast ausschließlich zu Forschungszwecken
installierte Leistung muss, falls die Energiewende erfolgreich sein soll, in einen geregelten
Modus von Betrieb und Instandsetzung übergehen. Die Nordsee mit ihrem fast konstant
über das Jahr verfügbaren Windaufkommen verspricht zwar eine wesentlich höhere
Stromproduktion als an Land, bietet jedoch durch die erschwerten Umweltbedingungen
auch größere Planungsunsicherheiten als in Onshore-Windenergieparks.
Eben diese Unsicherheiten zu verringern, ist das Ziel der im Rahmen von SCOWS
(Simulation-based Coordination of Offshore Windpark servicing) entwickelten Software.
Die im Programm enthaltene Optimierungskomponente verringert sowohl die Personalals
auch die Transportkosten soweit wie möglich, um den Betreiber des Windenergieparks
finanziell zu entlasten und die Rentabilität der Investitionen in die Windtechnologie
insgesamt zu steigern.
Den theoretischen Hintergrund für die vorliegende Arbeit bilden bereits bei anderen,
ähnlichen Problemen zum Einsatz gekommene Verfahren, die neu kombiniert und auf ihre
Qualität hin evaluiert wurden. Es traten in der Erarbeitung des Themas einige Fragen
zu Tage, die unter Umständen nicht allgemein vorab für alle denkbaren Anwender der
Softwarelösung beantwortet werden können.
So gibt es durchaus Optimierungsziele, die sich gegenseitig widersprechen; zum Beispiel
die Minimierung der Transportzeiten bei gleichzeitiger Minimierung der Wartezeiten. Soll
der Mitarbeiter auch einmal warten oder muss er sofort abgeholt werden, auch wenn sich
dies gerade transportwirtschaftlich nicht lohnt?
Um realistische Erwartungen der Zielgruppe an eine Offshore-Einsatzplanung erfüllen
zu können, führte die Projektgruppe mehrere Interviews mit Branchenvertretern; darunter
Reedereien, Betriebsbüros sowie IT-Dienstleister für Windenergieparks.
Als Ergebnis kann die Projektgruppe eine Softwarelösung vorweisen, die sowohl aus
einer vom Planer vorgegebenen Menge an Jobs und Transportmittel einen Plan generieren,
als auch diesen visuell verständlich simulieren kann. Bei der Optimierung besteht
die Wahl aus zwei unterschiedlichen Ansätzen, die jeweils für sich ihre Vorzüge besitzen
und in dem Bericht der Projektgruppe beschrieben sind. Die sich an die Optimierung
anschließende Simulation berücksichtigt zudem noch die Umwelteinflüsse, insbesondere
die Strömung und den Wellengang, die an dem jeweilig zu planenden Tag vorherrschen.
Aufbauend auf den gesammelten Erkenntnissen sowie des implementierten Prototyps
kann zukünftig ein Softwareprodukt entstehen, das den Ausbau der Offshore-Windenergieparks
durch verringerte Wartungskosten beschleunigt und dadurch die Energiewende
in Deutschland wirksam vorantreibt.

Abstract der Dozenten
Der strategische Ausbau der regenerativen Energiequellen in Deutschland sieht eine gewichtige
Rolle der Offshore-Windenergie vor. Die Stromerzeugung aus Wind auf See soll
danach in wenigen Jahrzehnten einen großen Anteil des Energiemixes ausmachen; von
bis zu 25 Gigawatt bis zum Jahre 2030 ist hier die Rede. Wie die ökonomische Umsetzung
dieses politischen Willens gelingen wird, hängt ganz entscheidend von der Wirtschaftlichkeit
des Geschäftes für die beteiligten Unternehmen ab. Darunter fallen neben den
großen Energiekonzernen die Erbauer und Betreiber der Windenergieparks sowie ihre
Zulieferer. Die Mammutprojekte müssen sich rechnen, damit die Offshore-Windenergie
sich auch dauerhaft als ein Grundpfeiler der hiesigen Energieversorgung etablieren kann.
Neben den immensen Problemen des Netzausbaus und technischen Herausforderungen
auf See, denen schon jetzt durch Netzpauschalen und andere Subventionen begegnet
wird, spielen dabei die Kosten für Errichtung, Betrieb, Repowering und Abbau der Windenergieparks
eine entscheidende Rolle. Eine Kostenreduktion in jeder dieser Phasen hat
damit höchste Priorität für alle involvierten Partner.
Betriebskosten machen dabei - auf den Lebenszyklus eines Windenergieparks gerechnet
- bis zu ein Viertel der Gesamtkosten aus. Gleichzeitig besteht hier ein erhebliches
Potential für Einsparungen. Nicht nur durch technische Verbesserungen der Anlagen,
der Ausrüstung und der Transportmittel lassen sich Abläufe effizienter gestalten, sondern
auch auf der planerischen Ebene ist noch viel Raum zur Optimierung.
In diesem Kontext ist das Projekt Simulation-based Coordination of Offshore Windpark
Servicing, im Weiteren als SCOWS bezeichnet, angesiedelt. Die Projektgruppe, bestehend
aus 10 Masterstudenten, arbeitete dabei über den Zeitraum von zwei Semestern
an der Konzeption und Entwicklung einer Software zur Entscheidungsunterstützung in
der Planung von Versorgungsfahrten zu Offshore-Windenergieparks. Leitvision für diese
Software war es, durch eine ganzheitliche Betrachtung der Wartungsabläufe und der Umwelt,
in die sie eingebettet sind, eine globale Prozesssicht zu erlangen und die Prozesse
unter unterschiedlichen Kostengesichtspunkten zu optimieren. Den methodischen Kernansatz
dafür bildete die Kombination einer dezentral ablaufenden Simulation mit Verfahren
aus der kombinatorischen Optimierung und anderen Bereichen, sodass Aspekte
der statischen Planung mit einer Berücksichtigung von Wettereinflüssen ergänzt werden
können.
Hinsichtlich des Vorgehens war die Projektarbeit in drei unterschiedliche Phasen gegliedert.
Zu Beginn wurden Anforderungen an die entstehende Software aus diversen Perspektiven
von den einzelnen Teilnehmern in Seminarform erfasst. Daran schlossen sich
die Modellbildung, Findung der zu nutzenden Verfahren sowie Konzeption der Software
an. Den abschließenden Schritt bildete die Implementierung. Insbesondere die zweite
Phase stellte sich als langwierig heraus, da sich die Projektgruppe auf ein Terrain begeben
hat, das in Forschung und Praxis bisher noch kaum Beachtung gefunden hat.
Intelligente Planungsverfahren für dieses spezifische Problem wurden bis dato nicht ansatzweise
entwickelt. Der State of the Art in den Betriebsbüros beruht auf individuellen
Entscheidungen von menschlichen Planern auf Grundlage ihres Erfahrungsschatzes und
3

den aktuellen meteorologischen Begebenheiten. IT-Unterstützung hierbei, insbesondere
durch ein simulationsbasiertes Optimierungsmodell, ist neu und daher bestand ein
Großteil der Aufgabe zunächst darin, geeignete existierende Methoden zu identifizieren
und auf diesen Anwendungskontext zu übertragen. Dieses Vorhaben ist gelungen und die
entstandene Software sowie ihre Entwicklung soll in diesem Bericht vorgestellt werden.
4

Vorwort
Vorwort
Vorwort
Die Projektdokumentation ist im Rahmen des Masterstudiums an der Carl von Ossietzky
Universität Oldenburg in der Abteilung Business Engineering verfasst worden. Anhand
der Dokumentation ist ersichtlich, wie der Entwicklungsprozess bis hin zum Projektergebnisses
verlief. Allgemein dient es der Bewertungsgrundlage der Projektauftraggeber
und -betreuer Apl. Prof. Dr.-Ing. Jürgen Sauer und Dipl.-Inform. Jan-Hinrich Kämper.
Das Projekt ist auf ein Jahr, folglich zwei Semestern beschränkt und soll einer Anzahl
von Studierenden die Arbeitsweise, Kooperation und fast freie Vorgehensweise in Softwareprojekten
näher bringen.
Die Entwicklung des Prototypen richtet sich dabei an keine bestimmte Unternehmung,
sondern ist vielmehr als Forschungsgebiet des noch recht unbekannten Terrains
“Offshore-Windenergie“, insbesondere der Wartung von ”
Offshore-Windenergieparks“
zu sehen. Die Aufgabe besteht darin, einen Prototypen zu entwickeln, der eine Entscheidungsunterstützung
für einen Planer von Servicearbeiten dient. Ziel ist es, dass
dies anhand von Anforderungen und Kriterien durch den Windenergiepark-Betreiber,
dem Betriebsbüro sowie nationalen und internationalen Richtlinien und Gesetzen und
weiteren Bereichen erfolgt.
An der Dokumentation und Durchführung des studentischen Projektes Simulation
based Coordination of Offshore Wind Parks Servicing sind Nashida Barakat, Georg Berendt,
Carsten Buschmann, Khisrav Evazov, Shimal Ibrahim, Raphaël Françios Kaiser,
Svetlana Kapitanova, Christian Menne, André Wolter und Stefan Wunderlich beteiligt.
An dieser Stelle bedankt sich das Team bei den Experten für die Gespräche, Präsentationen,
Diskussionen und den Interviews, die dieses Projekt mit ihrem Wissen und Know-
How unterstützt und bereichert haben. Zu nennen sind da die AG Reederei Norden-
Frisia, BTC AG, HTM Helicopter Travel Munich GmbH und Overspeed GmbH & Co.
KG. Des Weiteren das Forschungsprojekt SystOp Offshore Wind, vorgestellt von M.Sc.
Saskia Greiner und Dipl.-Ing (TFH) Susanne Appel und den Informationsaustausch.
Darüber hinaus beim Bundesamt für Seeschifffahrt und Hydrographie (BSH) für die Bereitstellung
von Daten und den Datenzugriff auf diese. Außerdem noch Alexander Rott
für die Vorstellung seiner Masterarbeit in diesem Themenbereich.
Das Projektteam ist bestrebt sich weiterzuentwickeln, zu lernen, über den Tellerrand zu
schauen und ihren Horizont zu erweitern. Für Diskussionen, Kritik und Meinung sind
wir offen und freuen uns nicht nur sondern erwarten auch Feedback.
Oktober 2013 - SCOWS-Projektteam
I

Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis
Vorwort
Abbildungsverzeichnis
Abkürzungsverzeichnis
Glossar
Tabellenverzeichnis
I
IX
X
XIII
XVII
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Projektziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Struktur der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Projektteam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1 Projektbetreuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2 Studentische Projektmitglieder . . . . . . . . . . . . . . . . . . . . 7
2 Projektplanung 14
2.1 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 LaTeX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.4 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Projektphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Grundlagen des Projektes 20
3.1 Offshore-Windfarmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Errichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3 Wartung und Reparatur an OWA . . . . . . . . . . . . . . . . . . . 22
3.1.4 Umweltverträglichkeitsprüfung . . . . . . . . . . . . . . . . . . . . 22
3.1.5 Entwicklung weltweit . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 HSE-Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 HSE Richtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3 Standards des BSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4 Wiederkehrende Prüfungen . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5 Bewertungskriterien für die wiederkehrenden Prüfungen . . . . . . 24
3.2.6 Unterlagen der zu prüfenden Offshore-Windenergeiparks . . . . . . 24
II

Inhaltsverzeichnis
Inhaltsverzeichnis
3.2.7 Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.8 Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.9 Havariekommando des Bundes . . . . . . . . . . . . . . . . . . . . 26
3.3 Infrastruktur und Logistik . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.2 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Logistik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Reederei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.2 Definition des Begriffs Reederei“ . . . . . . . . . . . . . . . . . . . 36
”
3.4.3 Schiffs- und Wartungsbedarf . . . . . . . . . . . . . . . . . . . . . 36
3.4.4 Schiffstypen in der Betriebsphase . . . . . . . . . . . . . . . . . . . 38
3.4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Wetterdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.1 Definition des Begriffs Wetter“ . . . . . . . . . . . . . . . . . . . . 40
”
3.5.2 Einschränkung des betrachteten Gebietes . . . . . . . . . . . . . . 40
3.5.3 Erhebung von Wetterdaten . . . . . . . . . . . . . . . . . . . . . . 40
3.5.4 Notwendigkeit von Vorhersagen . . . . . . . . . . . . . . . . . . . . 42
3.5.5 Klärung von WRF, NOAA und GFS . . . . . . . . . . . . . . . . . 43
3.6 Navigationsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.1 Einleitung und Grundlagen . . . . . . . . . . . . . . . . . . . . . . 46
3.6.2 Navigationshilfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.3 Navigationshilfe Beispiel . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.4 Rechtsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.5 Organisationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.6 Regeln und Gesetze . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.7 Automatic Identification System . . . . . . . . . . . . . . . . . . . 50
3.6.8 Elektronische Seekarte . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7 Entwurfsmethoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.7.2 Definition des Begriffs Scrum“ . . . . . . . . . . . . . . . . . . . . 53
”
3.7.3 Bestandteile von Scrum . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.8 Simulationstechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.8.2 Was ist Simulation? . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.8.3 Warum keine analytischen Verfahren? . . . . . . . . . . . . . . . . 58
3.8.4 Welche Simulationsmodelle gibt es? . . . . . . . . . . . . . . . . . 59
3.8.5 Mutliagentensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.8.6 System Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.8.7 Welche Simulationsphasen gibt es? . . . . . . . . . . . . . . . . . . 63
3.8.8 Vorgehen zur Werkzeugauswahl . . . . . . . . . . . . . . . . . . . . 63
III

Inhaltsverzeichnis
Inhaltsverzeichnis
3.8.9 Werkzeuge (Auswahl) . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.8.10 Stolperfallen bei Simulationsstudien . . . . . . . . . . . . . . . . . 64
3.9 Optimierungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.9.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.9.2 Klassifikation von Optimierungsproblemen . . . . . . . . . . . . . . 74
3.9.3 Beispielproblem: Traveling Salesman . . . . . . . . . . . . . . . . . 75
3.9.4 Bibliotheken zur Optimierung . . . . . . . . . . . . . . . . . . . . . 76
3.10 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.10.2 Definition eines Projektes . . . . . . . . . . . . . . . . . . . . . . . 79
3.10.3 Schwierigkeiten und Probleme . . . . . . . . . . . . . . . . . . . . . 80
3.10.4 Bedingungen für erfolgreiche Projekte . . . . . . . . . . . . . . . . 81
3.11 Expertengespräche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4 Allgemeine Problemdefinition 85
4.1 Hauptszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.1 Offshore-Windenergiepark und Hafen . . . . . . . . . . . . . . . . . 85
4.1.2 Offshore-Windenergieanlagen und Jobs . . . . . . . . . . . . . . . . 85
4.1.3 Transportmittel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.4 Arbeizeitfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.5 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.6 Masterdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5 Anforderungsanalyse 87
5.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.1.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . 87
5.1.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . 90
6 Konzepte 91
6.1 GUI-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2 Scheduling-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3 Optimierungskonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.2 Annahmen und Voraussetzungen . . . . . . . . . . . . . . . . . . . 97
6.3.3 Optimierungsansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.3.4 Bewertung der Pläne . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4 Simulationskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.1 Die Idee - Ablaufplan . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.2 Akteure der Simulation . . . . . . . . . . . . . . . . . . . . . . . . 113
6.4.3 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.5 Schnittstellenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.5.1 GUI als Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.5.2 Datenübermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.5.3 Schnittstelle zwischen dem Scheduling und der Optimierung . . . . 120
IV

Inhaltsverzeichnis
Inhaltsverzeichnis
6.5.4 Schnittstelle zwischen der Optimierung und Simulation . . . . . . 124
6.5.5 Schnittstelle zwischen der Simulation und Evaluation . . . . . . . . 126
7 Beschreibung der Software SCOWS 128
7.1 Programmstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.2 Planungsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.3 Optimierungsvorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.3.1 Heuristisches Verfahren [RS-Algo] . . . . . . . . . . . . . . . . . . 135
7.3.2 Sequenzielle Abarbeitung mit Clustering [SG-Algo] . . . . . . . . . 145
7.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7.5 Visualisierung des Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.6 Installationsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
8 Testszenarien, Validierung und Evaluation 155
8.1 Testdokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.1.1 Modultests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
8.1.2 Testfälle für Modultests (exemplarisch) . . . . . . . . . . . . . . . 156
8.2 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
8.2.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8.2.2 Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.2.3 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
8.4.1 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8.4.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
9 Zusammenfassung 167
9.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Literaturverzeichnis 173
Stichwortverzeichnis 175
A Anhang 179
A.1 Sitzungsprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.2 Interviews mit den Experten . . . . . . . . . . . . . . . . . . . . . . . . . 262
B Pflichtenheft 274
B.1 Zielbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
B.1.1 Pflichtanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 274
B.1.2 Optionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 275
B.1.3 Abgrenzungskriterien . . . . . . . . . . . . . . . . . . . . . . . . . 275
B.2 Produkteinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
B.2.1 Anwendungsbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . 277
V

Inhaltsverzeichnis
Inhaltsverzeichnis
B.2.2 Zielgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
B.2.3 Betriebsbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 277
B.3 Produktumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
B.3.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
B.3.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
B.3.3 Orgware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
B.4 Produktfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
B.4.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
B.4.2 Wartungsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
B.5 Benutzungsoberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
B.6 Qualitätszielbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . 286
B.7 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.1 Serverbetriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.2 Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.3 Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.4 Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.5 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
B.7.6 Serverapplikation SCOWS Backend“ ”
. . . . . . . . . . . . . . . . 287
VI

Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildungsverzeichnis
1 Gemeinsames Projektgruppenfoto . . . . . . . . . . . . . . . . . . . . . . . 6
2 Profilbild: Jan-Hinrich Kämper . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Profilbild:Nashida Barakat . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Profilbild: Georg Berendt . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5 Profilbild: Carsten Buschmann . . . . . . . . . . . . . . . . . . . . . . . . 8
6 Profilbild: Khisrav Evazov . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7 Profilbild: Shimal Ibrahim . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8 Profilbild: Raphaël François Kaiser . . . . . . . . . . . . . . . . . . . . . . 10
9 Profilbild: Christian Menne . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10 Profilbild: André Wolter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11 Profilbild: Stefan Wunderlich . . . . . . . . . . . . . . . . . . . . . . . . . 13
12 Die Ansicht von Sprint 0.0.1 alpha in Redmine . . . . . . . . . . . . . . . 15
13 Schadenstoff- und Schiffsunfallbekämpfung Küste . . . . . . . . . . . . . . 29
14 Logistik - Betroffene Bereiche der Logistik . . . . . . . . . . . . . . . . . . 31
15 Anlaufhäfen in Deutschland . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16 Passives und aktives Übersteigesystem . . . . . . . . . . . . . . . . . . . . 33
17 Helgoland als Servicestützpunkt für Offshore-Windparks . . . . . . . . . . 34
18 On- und Offshore- Logistik . . . . . . . . . . . . . . . . . . . . . . . . . . 35
19 Schiffsbedarf von OWP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
20 Die deutschen Offshore-Windenergieparks im Betrieb . . . . . . . . . . . . 41
21 Längen- und Breitengrade auf dem Erdball . . . . . . . . . . . . . . . . . 41
22 Karte zur besseren geographischen Einordnung . . . . . . . . . . . . . . . 42
23 Messstationen werden im Meer versenkt . . . . . . . . . . . . . . . . . . . 43
24 Navigationshilfe mittels Echolot . . . . . . . . . . . . . . . . . . . . . . . . 47
25 Rechtsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
26 Ausschließlichen Wirtschaftszone . . . . . . . . . . . . . . . . . . . . . . . 49
27 Scrum-Tag-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
28 Srum im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
29 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
30 Scrum in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
31 System, Modell und Anwendung . . . . . . . . . . . . . . . . . . . . . . . 65
32 Modellklassifikation nach Werten der Zustandsvariablen . . . . . . . . . . 65
33 Grundlegende Agentenarchitektur . . . . . . . . . . . . . . . . . . . . . . . 66
34 Mehrschichtiges neuronales Netz zur Agentenkontrolle . . . . . . . . . . . 66
35 Minenroboter als reaktiver Agent . . . . . . . . . . . . . . . . . . . . . . . 67
36 Schema eines BDI-Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . 68
37 Komponenten multiagentenbasierter Modelle . . . . . . . . . . . . . . . . 69
38 Phasen im Simulationsmodellierungszyklus . . . . . . . . . . . . . . . . . 70
39 Kriteriengruppen zur Auswahl von Simuations-Software . . . . . . . . . . 71
40 Vorgehensweise im Auswahlverfahren . . . . . . . . . . . . . . . . . . . . . 72
VII

Abbildungsverzeichnis
Abbildungsverzeichnis
41 Der Zielfunktionsgraph mit lokalem Optimum B im Bereich N und globalem
Optimum A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
42 TSP - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
43 Projektmanagement-Ursachen des Scheiterns . . . . . . . . . . . . . . . . 78
44 Projektmanagement - Schaukel . . . . . . . . . . . . . . . . . . . . . . . . 79
45 Projektmanagement - Phasen . . . . . . . . . . . . . . . . . . . . . . . . . 82
46 Aufbau des Scheduling/Darstellung von Drag&Drop . . . . . . . . . . . . 94
47 Zur Verfügung stehende Transportmittel . . . . . . . . . . . . . . . . . . . 95
48 Schematische Darstellung eines Windparks . . . . . . . . . . . . . . . . . . 103
49 Durchführung von Service-Arbeiten pro Offshore-Windenergieanlage . . . 104
50 Gegenüberstellung von parallelisierter und sequenzieller Jobabarbeitung . 105
51 Schematische Darstellung der kombinatorischen Abarbeitung von Jobs . . 106
52 Graph mit ungerichteten und ungewichteten Kanten . . . . . . . . . . . . 107
53 Auswahl eines Knotens und die resultierende Gewichtung der Kanten . . . 108
54 Bestimmung der Nachfolgerknoten . . . . . . . . . . . . . . . . . . . . . . 109
55 Aufteilung der Jobkombinationen . . . . . . . . . . . . . . . . . . . . . . . 109
56 Aufteilung der Jobkombinationen . . . . . . . . . . . . . . . . . . . . . . . 111
57 Kommunikationsablauf der Simulation . . . . . . . . . . . . . . . . . . . . 112
58 Darstellung der einzelnen Module in diesem Projekt . . . . . . . . . . . . 115
59 Allgemeine Benutzerinteraktion mit dem Scheduling . . . . . . . . . . . . 116
60 Darstellung der graphischen Benutzerschnittstelle des Simulation controls 116
61 Planungsprozess vom Scheduling bis zur Optimierung . . . . . . . . . . . 122
62 Planungsprozess zwischen dem Scheduling und der Optimierung . . . . . . 124
63 Übergabe des Plans von der Optimierung zur Simulation . . . . . . . . . . 126
64 Ausgabe der Evaluationsparameter für den Benutzer . . . . . . . . . . . . 127
65 Initiales Hauptfenster des Clients . . . . . . . . . . . . . . . . . . . . . . . 128
66 Menüleiste des Hauptfensters . . . . . . . . . . . . . . . . . . . . . . . . . 130
67 Deaktivierte Simulationskontrolle . . . . . . . . . . . . . . . . . . . . . . . 130
68 Kartenkontrollwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
69 Initiales Planungsfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
70 Kopf der Planungstafel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
71 Transportmittellabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
72 Joblabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
73 Werkzeugleiste der Planungsansicht . . . . . . . . . . . . . . . . . . . . . . 132
74 Auswahl von Transportmittel/Jobs . . . . . . . . . . . . . . . . . . . . . . 133
75 Bestätigungsdialog zur Optimierung . . . . . . . . . . . . . . . . . . . . . 135
76 Kleiner Offshore-Wartungseinsatz . . . . . . . . . . . . . . . . . . . . . . . 137
77 Personenstunden pro Schiff . . . . . . . . . . . . . . . . . . . . . . . . . . 139
78 Iterationsschritte des Clusterings . . . . . . . . . . . . . . . . . . . . . . . 141
79 Einfügeindizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
80 Einfügekonflikt des Hol-Slots H4 . . . . . . . . . . . . . . . . . . . . . . . 143
81 Job 4 wurde erfolgreich eingefügt . . . . . . . . . . . . . . . . . . . . . . . 144
82 Herstellen der Durchführbarkeit undurchführbarer Cluster . . . . . . . . . 145
VIII

Abbildungsverzeichnis
Abbildungsverzeichnis
83 Ablauf des zweiten Optimierungsverfahren . . . . . . . . . . . . . . . . . . 146
84 Darstellung einer Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 149
85 Darstellung des Simulationsergebnisses . . . . . . . . . . . . . . . . . . . . 151
86 Heuristik Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 154
87 Verlauf der Testabdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
88 Klassendiagramm von Cluster.java . . . . . . . . . . . . . . . . . . . . . . 157
89 Testfälle für Cluster.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
90 Erfolgreicher JUnit-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
91 Klassendiagramm von Clustering.java . . . . . . . . . . . . . . . . . . . . 158
92 Testfälle für Clustering.java . . . . . . . . . . . . . . . . . . . . . . . . . . 158
93 Klassendiagramm von Estimator.java . . . . . . . . . . . . . . . . . . . . . 159
94 Testfälle für Estimator.java . . . . . . . . . . . . . . . . . . . . . . . . . . 160
95 Kosten pro Schiff (RS-Algo) . . . . . . . . . . . . . . . . . . . . . . . . . . 163
96 Kosten pro Anlage (RS-Algo) . . . . . . . . . . . . . . . . . . . . . . . . . 163
97 Gantt-Chart (RS-Algo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
98 Gantt-Chart (SG-Algo) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
99 Klassendiagramm der Optimierung (RS-Algo) . . . . . . . . . . . . . . . . 179
100 Start Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
101 Einsatzplan erstellen Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . 282
102 Ereignis erstellen Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
103 Simulation Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
104 Optimierung Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
IX

Abkürzungsverzeichnis
Abkürzungsverzeichnis
Abkürzungsverzeichnis
ACL Agent Communication Language 62
AFWA Air Force Weather Agency 44
AIS Automatic Identification System XIII, 47, 50
AWZ Ausschließlichen Wirtschaftszone 47, 49, 102
BinSchStrO Binnenschifffahrtsstraßen-Ordnung 49
BMU
Bundesministerium für Umwelt, Naturschutz und
Reaktorsicherheit 21
BSH Bundesamt für Seeschifffahrt und Hydrographie 22,
23, 36, 49, 90, 102
COIREGs Convention on the International Regulations for Preventing
Collisions at Sea 49
CTV Crew Transfer Vessel 37, 38
DWD Deutscher Wetterdienst 40
ECDIS Electronic Chart Display and Information System 50,
51
EEG Erneuerbare-Energien-Gesetz 1
EmsSchO Schifffahrtsordnung Emsmündung 49
ENC Electronic Navigational Chart 50
FAA Federal Aviation Administration 44
FAZ Frühester Anfangszeitpunkt 89, 93
FEZ Frühester Endzeitpunkt 93
FIPA Foundation for Intelligent Physical Agents 62
FSL Forecast Systems Laboratory 44
GFS Global Forecast System 45
GPM
Deutsche Gesellschaft für Projektmanagement e.V.
78
GPS Global Positioning System XIII, 47, 50
GUI Graphical User Interface 4, 9–11, 91, 115, 117, 158,
168, 172
HC Hard Constraint 94, 99, 102, 168
HSE Health, Savety and Environment 23, 34, 85, 99, 101,
103, 168
X

Abkürzungsverzeichnis
Abkürzungsverzeichnis
IALA International Association of Marine Aids to Navigation
and Lighthouse Authorities 48
IDE Intergrierte Entwicklungsumgebung 17, 18
ILO International Labour Organization 48
IMO International Maritime Organization 48
IWES
Institut für Windenergie und Energiesystemtechnik
42
JDT Java Development Tools 18
kn Knoten 136, 162
kW Kilowatt 123
kWh Kilowattstunde 123, 125
Lat Latitude 46, 96, 123
Long Longitude 46, 96, 123
LRIT Long Range Identification and Tracking XIV, 47
MABS Multi-Agent Based Simulation 62, 63
Map Karte 148, 150
MAS Multiagentensysteme 59, 60, 62
MSZ Maritimen Sicherheitszentrums 26
MTZ Maritime Lagezentrum 27
MW Megawatt 96, 97
MWh Megawattstunden 21, 22, 97
NCAR National Center for Atmospheric Research 44
NCEP National Centers for Environmental Prediction 44
NOAA National Oceanic and Atmospheric Administration
44, 45
OSV Offshore Service Vessels 38
OWA Offshore-Windenergieanlage XVII, 18, 21, 22, 24, 30,
31, 36–39, 85, 90, 91, 94, 96–106, 110, 119, 121–127,
135–138, 140, 141, 143–145, 147, 148, 151, 161, 165,
167, 168, 170, 172
OWP Offshore-Windenergiepark 1–3, 21–24, 31, 36–40, 42,
85, 87, 88, 90, 91, 93, 94, 98, 100–102, 107, 111, 119,
121–123, 126, 136, 137, 139, 141, 142, 144, 145, 147,
157, 161, 165, 167, 168, 171, 172
PG Projektgruppe 1–4, 87, 128, 155
PM Projektmanagement 78–80
XI

Abkürzungsverzeichnis
Abkürzungsverzeichnis
RHIB Rigid Hull Inflatable Boat XV
RIB Rigid Inflatable Boat XV, 38
SAZ Spätester Anfangszeitpunkt 89, 93
SC Soft Constraint 99, 102
SCOWS
Simulation based Coordination of Offshore Wind
Parks Servicing 1–3, 5, 9, 10, 16, 40, 87, 128, 153,
155, 168, 169
SeeAufgG Seeaufgabengesetz 49
SeeSchStrO Seeschifffahrtsstraßen-Ordnung 49
SEZ Spätester Endzeitpunkt 93
SOLAS International Convention for the Safety of Life at Sea
49
StromStG Stromsteuergesetz XV
SWATH Small Waterplane Area Twin Hulls XVI, 38
TSP Traveling Salesman Problem 76
UNCLOS UN Conventions on the Law of the Sea 49
VKZ Verkehrszentrale 47, 49
WEA Windenergieanlage XVI, 21, 22, 24, 25, 27, 32, 33,
37, 38, 85, 88, 90, 96–98, 101–103, 105–108, 110, 111,
113, 119, 121, 123, 125–127, 135–137, 139–141, 145,
148, 150–152, 161–163, 167, 172
WKP Wiederkehrenden Prüfungen 24, 25, 36
WRF Weather Research and Forecasting Model 44, 45
WSA Wasser- und Schifffahrtsämter 49
WSD Wasser- und Schifffahrtsdirektionen 49
WSV Wasser- und Schifffahrtsverwaltung des Bundes 49
XII

Glossar
Glossar
Glossar
A
Automatic Identification System Der Begriff Automatic Identification System (AIS)
(AIS; zu Deutsch: Automatisches Identifikationssystem) oder Universal Automatic
Identification System (UAIS) bezeichnet ein Funksystem, das durch den
Austausch von Navigations- und anderen Schiffsdaten die Sicherheit und die
Lenkung des Schiffsverkehrs verbessert. Es wurde am 6. Dezember 2000 von der
Internationalen Seeschifffahrts-Organisation (IMO) als verbindlicher Standard
angenommen. 47
E
Echolot Das Echolot ist ein in der Schifffahrt verwendetes Gerät zur elektrostatischen
Messung von Wassertiefen (Lotung). Gemessen wird die Zeit, die zwischen
der Aussendung eines Schallimpulses (Wasserschall) und der Ankunft der vom
Gewässerboden reflektierten Schallwellen verstreicht. 47, 50
G
Getriebe Das Übersetzungsgetriebe dient dazu, die niedrige Rotordrehzahl auf eine
für schnelllaufende Generatoren nötiges Niveau zu übersetzen. Obwohl Getriebe
technisch nicht zwingend notwendig für Windkraftanlagen sind, stellen Anlagenkonzepte
mit Getriebe weiterhin die Standardbauweise dar. 25
Global Positioning System Global Positioning System (GPS), offiziell NAVSTAR
GPS, ist ein globales Navigationssatellitensystem zur Positionsbestimmung und
Zeitmessung. GPS hat sich als das weltweit wichtigste Ortungsverfahren etabliert
und wird in Navigationssystemen weitverbreitet genutzt. 47
Gondel das Maschinenhaus für die auf Masten montierten Generatoren von Windkraftanlagen
27, 38
H
Hoisting Der Einsatz von Helikoptern zum Transport von Arbeitskräften vom Festland
auf eine Offshore-Windenergieanlage macht es notwendig, dass das Personal
auf die jeweilige Windenergieanlage abgeseilt werden inklusive dem benötigten
Werkzeugen. Diese Operation auf offener See wird unter dem Begriff Hoisting
bzw. Offshore- Hoist Operations zusammengefasst. Dazu muss sowohl das
Hubschrauberpersonal hochqualifiziert sein, als auch die Arbeitscrew für die
Offshore-Windenergieanlagen einer intensiven Schulung unterzogen werden. 98
Hubinsel Eine Hubinsel ist eine mobile Plattform im Wasser, die mit Hilfe von absenkbaren
Standbeinen auf dem Meeresboden stehen kann. Sie hat im Gegensatz
zu den Schiffen, die zur Errichtung eingesetzt werden, keinen eigenen Antrieb,
sondern wird mit Hilfe von Schleppern an neue Standorte gezogen. 2
XIII

Glossar
Glossar
I
Infrastruktur Es sind die wachstums-, integrations- und versorgungsnotwendigen Basisfunktionen
für weitere Ablaufprozesse. Dies beinhaltet ebenfalls Gesamtheit
aller Anlagen, Ausrüstungen und Betriebsmittel, die für die Ausführung eines
festgelegten Ablaufes unabdingbar sind. 1, 8, 9, 30, 31, 34, 35
Intraparklogistik Die Teildisziplin der Logistik, die die Zuteilung von Ressourcen beinhaltet
und befasst sich mit der Koordinierung innerhalb von Windparks. Dabei
ist die Abhängigkeit zum Umfang, der zu erbringenden Leistung und den
benötigten Bedarfsmaterialien, entscheidend. 32, 34, 98, 123
J
Jack-up-Schiff Es handelt sich um sogenannte Hubschiffe, auch Jack-up-Schiffe genannt,
die sich mit Hilfe von vier bis sechs hydraulisch oder elektrisch betriebenen
Beinen (sogenannte Jack-up-Legs) an einer festen Position im Meer aufstellen
können. Nur in der Anfangszeit kamen Schiffe in Halbtaucher- oder SWATH-
Bauweise zum Einsatz, da diese weniger stabil im Wasser liegen. 38
L
Logge Ein Log (auch Logge) ist in der seemännischen Navigation ein Messgerät zur
Bestimmung der Fahrt, der Geschwindigkeit von Wasserfahrzeugen. Es zeigt
die im Wasser zurückgelegte Strecke an. Ein Log kann meist nur die Relativgeschwindigkeit
zum umgebenden Wasser ermitteln. Zur Bestimmung der absoluten
Schiffsgeschwindigkeit war man daher früher auf (Mess- und) Erfahrungswerte
der jeweiligen Fluss- bzw. Meeresströmungen angewiesen. Heutige Verfahren
mittels Funk- und Satellitennavigation ergeben weitaus präzisere Ortsbestimmungen,
so dass Messungen mit dem Log meist nur noch informativen
Charakter haben oder per Differenz zu den Werten aus der Satellitennavigation
Aufschluss über die Wasserströmungen geben. 46
Logistik Die Logistik befasst sich mit Organisation, Steuerung, Bereitstellung und Optimierung
von Prozessen der Güter-, Informations-, Energie-, Geld- und Personenströme
entlang der Wertschöpfungskette sowie der Lieferkette. Im Offshore
Bereich bezieht sich Logistik auf folgende Aspekte: Produktions- und Beschaffungslogistik,
Lagerlogistik zur Produktion und Verschiffung, Vormontage direkt
an der Kaje / Offshore Hafen, Service-Logistik. 8, 9, 30–32, 34, 35
Long range identification and tracking Long Range Identification and Tracking
(LRIT), ins Deutsche übersetzt lautet es soviel wie: System zur Identifizierung
und Verfolgung über große Entfernungen, ist eine Vorschrift für Schiffe, Identifikationsdaten
über eine größere Entfernung als bisher auf Abfrage auszustrahlen.
LRIT schreibt vor, folgende Identifikationsdaten auszustrahlen, die weltweit abgefragt
werden können: Schiffsidentifikation, Position, Zeitpunkt. 47
N
XIV

Glossar
Glossar
Nennleistung Als Nennleistung wird die vom Hersteller angegebene Leistung eines
Geräts, einer Anlage, mit hin eines elektrischen Verbrauchers oder eines anderen
Energiewandlers (Generator, Hydraulikmotor, Wärmekraftmaschine) bezeichnet,
die diese umsetzen (aufnehmen) oder generieren (abgeben) können.
Die Nennleistung Stromsteuergesetz (StromStG) einer Anlage zur Erzeugung
von Strom ist die Dauerleistung, für die sie gemäß den Liefervereinbarungen bestellt
ist. Die Dauerleistung einer Anlage ist die höchste Leistung, die bei einem
bestimmungsgemäßen Betrieb ohne zeitliche Einschränkung erbracht wird und
ihre Lebensdauer und Sicherheit nicht beeinträchtigt. 21
R
Radar Radar ist die Abkürzung für Radio Detection and Ranging (frei übersetzt: Funkortung
und -abstandsmessung), ursprünglich Radio Aircraft Detection and
Ranging (frei übersetzt: funkbasierte Flugzeugortung und -abstandsmessung)
und ist die Bezeichnung für verschiedene Erkennungs- und Ortungsverfahren
und -geräte auf der Basis elektromagnetischer Wellen im Radiofrequenzbereich
(Funkwellen). 47, 50
Reederei Eine Reederei ist ein Transport- und Schifffahrtsunternehmen im Bereich der
See- und Binnenschifffahrt. Die Reederei beschäftigt sich in erster Linie mit
der Ausrüstung, Bemannung, Unterhaltung und dem Einsatz ihres Schiffes bzw.
ihrer Schiffe. 30, 31, 36, 39
Rigid Inflatable Boat Ein Festrumpfschlauchboot Rigid Inflatable Boat (RIB)/Rigid
Hull Inflatable Boat (RHIB) ist ein Schlauchboot mit einem statischem Rumpf.
Es verfügt deshalb über bessere Fahr- und Auftriebseigenschaften als gewöhnliche
Schlauchboote und ist für Offshore-Anwendungen tauglich. 38
Rotor Ein Rotor (lateinisch rotare = kreisen) ist der sich drehende (rotierende) Teil
einer Maschine oder eines Aggregates. 31, 32
Rotorblatt Die Rotorblätter sind elementarer und prägender Bestandteil einer Windkraftanlage.
Mit ihnen wird die Windenergie der Luft entnommen und dem
Generator zugeführt. Moderne Rotorblätter bestehen in der Regel aus glasfaserverstärktem
Kunststoff und werden in Halbschalen-Sandwichbauweise mit
Versteifungsholmen oder -stegen im Inneren hergestellt. Vermehrt kommen bei
langen Rotorblättern auch Kohlenstofffasern zum Einsatz, vor allem bei hohen
Belastungen ausgesetzten Starkwind- und Offshore-Anlagen, aber ebenfalls bei
Schwachwindanlagen mit großen Rotordurchmessern. 25, 38
S
Seezeichen Schifffahrtszeichen (im Küstenbereich vor allem früher auch Seezeichen)
sind hör- oder sichtbare Markierungen, die als Navigationshilfen in der Schifffahrt
dienen. Zusammen mit den Seekarten im Küstenbereich, sowie den Elektronischen
Navigationskarten für Binnenschifffahrtsstraßen (IENC) im Binnenbereich
ermöglichen sie sicheres Navigieren. Typische Schifffahrtszeichen sind
Tonnen, Baken und Leuchttürme. 46
XV

Glossar
Glossar
SWATH-Schiff Die engl. Bezeichnung Small Waterplane Area Twin Hulls (SWATH),
zu deutsch etwa Doppelrumpf mit geringer Wasserlinienfläche bezeichnet eine
spezielle Rumpfform von Schiffen, die besonders unempfindlich gegen Seegang
ist. Bei ihr befinden sich zwei torpedoförmige Auftriebskörper unter der Wasseroberfläche,
und eine über Wasser angeordnete Plattform ruht darauf mit
beispielsweise vier Stützen, die eine minimale Wasserlinienfläche bilden. Schiffe,
die nach diesem Bauprinzip konstruiert sind, werden als SWATH bezeichnet. 38
T
Tonnenstrich Als Tonnenstrich wird eine angeordnete Reihe von mehreren gekennzeichnete
Tonnen im Fahrwasser verstanden, die die Fahrstrecke vorgeben und
aufzeigen, wo die Gefahr von Flachwasser minimal sein sollte. Die Tonnen sind
farblich markiert mit rot und grün. Die roten Tonnen stellen die Backboard- und
die grünen Tonnen die Steuerboard-Seite im Fahrwasser dar. Fährt ein Schiff
entlang des Tonnenstrichs und quert diesen nicht, so hat dieses Schiff Vorrang
entsprechend den Fahrzeugen außerhalb des Tonnenstrichs und nicht querend.
98
U
Umspannplattform Eine Umspannplattform ist eine Umspannstation bzw. ein Umspannwerk,
das auf einer Offshore-Plattform im offenen Meer installiert ist. Diese
Bauwerke sind vor allem bei Offshore-Windparks gebräuchlich, könnten zukünftig
aber auch in Verbindung mit anderen Meereskraftwerken in küstenferner
Lage zum Einsatz kommen. 38
W
Windenergieanlage Eine Windenergieanlage (WEA) erntet mit ihrem Rotor die Energie
des Windes, wandelt sie in elektrische Energie um und speist sie in das
Stromnetz ein. 21, 22, 32, 38
Windfarm Unter einer Windfarm versteht sich im Allgemeinen ein Park aus Windenergieanlagen.
2, 7
XVI

Tabellenverzeichnis
Tabellenverzeichnis
Tabellenverzeichnis
1 Gegenstände der wiederkehrenden Prüfungen . . . . . . . . . . . . . . . . 25
2 Risikomatrix mit Risikoprioritätszahlen . . . . . . . . . . . . . . . . . . . 26
3 Konsequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Simulationstechniken: Werkzeuge (Auswahl) . . . . . . . . . . . . . . . . . 63
5 Datenfelder eines Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6 Datenfelder eines Transportmittels . . . . . . . . . . . . . . . . . . . . . . 120
7 Datenfelder des Zeitfensters . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8 Datenfelder einer Offshore-Windenergieanlage (OWA) . . . . . . . . . . . 121
9 Datenfelder zum Anlegen von Häfen . . . . . . . . . . . . . . . . . . . . . 121
10 Datenfelder zur Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . 122
11 Datenfelder von Offshore-Windenergieparks . . . . . . . . . . . . . . . . . 122
12 Durchlaufzeiten der Optimierungen im Vergleich . . . . . . . . . . . . . . 165
XVII

1 EINLEITUNG
1 Einleitung
In diesem Kapitel wird ein übergreifender Überblick über die Projektgruppe (PG)-
Simulation based Coordination of Offshore Wind Parks Servicing (SCOWS) gegeben,
die im Rahmen des Masterstudiengangs Wirtschaftsinformatik an der Carl von Ossietzky
Universität Oldenburg stattgefunden hat. Das Projekt läuft über einen Zeitraum von
zwei Semestern: Wintersemester 2012/2013 und Sommersemester 2013.
1.1 Motivation
Die erneuerbaren Energien haben in den letzten Jahren immer mehr an Bedeutung gewonnen.
Dabei spielt die Offshore-Windenergie eine große Rolle und beträgt den großen
Teil der Produktion von erneuerbaren Energien in einigen Gebieten. Hinsichtlich umweltbewusster
Energiegewinnung ist es ein wesentlicher Beitrag zum Umweltschutz.
Immer mehr Offshore-Windenergiepark (OWP)s werden in Nord- und Ostsee geplant.
8000 Anlagen in mehr als 50 Parks sollen in den kommenden Jahren in Nord- und
Ostsee entstehen, wobei auch Parks mit 100 Anlagen auf Arealen von 40 km 2 und größer
gebaut werden. Eine Fläche von insgesamt 100 Quadratkilometern soll für die OWPs
bereitgestellt werden.
Als Motivation können auch gesetzliche Normen dienen. Das Erneuerbare-Energien-
Gesetz (EEG) ”
für den Vorrang Erneuerbarer Energien“ wurde im Jahr 2000 beschlossen.
Das EEG wird seither als zentraler Grund für den erfolgreichen Ausbau der erneuerbaren
Energien in Deutschland betrachtet, die zu Beginn des Jahres 2012 bereits einen Anteil
von 20 Prozent am Stromverbrauch stellen.
Einspeisevergütungsmodelle nach dem Vorbild des deutschen EEG wurden inzwischen
in zahlreichen Ländern implementiert, um den Ausbau von erneuerbaren Energien zu
fördern.“ 1
Darüber hinaus wird die Aktualität der Offshore-Windenergie durch die Energiepolitik
der Bundesregierung in Deutschland verstärkt. Kurz nach dem Beginn der Nuklearkatastrophe
von Fukushima verkündete die Bundesregierung zunächst ein dreimonatiges
Atom-Moratorium für die sieben ältesten deutschen Atomkraftwerke und weiter führte
die Atompolithik in die Richtung des Atomausstiegs. Am 6. Juni 2011 beschloss das Kabinett
Merkel II das Aus für acht Kernkraftwerke und einen stufenweisen Atomausstieg
bis 2022 2 .
Der aktuelle Stand der Offshore-Windenergie stellt viel mehr wirtschaftliche Herausforderungen
als die Onshore-Systeme dar. Die Turbine verursacht ein Drittel bis zu einer
Hälfte der Kosten in Offshore-Projekten, die übrigen Kosten werden durch Infrastruktur
und Wartung verursacht. Größere Turbinen mit größeren Kapazitäten sind wirtschaftlicher
wegen der komplexeren Infrastruktur in OWPs. Zusätzlich gibt es zurzeit keine
allgemeingültigen Simulationsmodelle von Umwelteffekten auf OWPs. Das verursacht
1 Recht & Zuständigkeiten: Rechtsnormen, offshore-windenergie.net, Bundesministerium für Umwelt,
Naturschutz und Reaktorsicherheit,
http://www.offshore-windenergie.net/politik-2/recht-zustaendigkeiten/rechtsnormen, 25.05.2013
2 sueddeutsche.de: Kabinett beschließt Atomausstieg bis 2022, 06.06.2011
1

1.2 Problemstellung 1 EINLEITUNG
Schwierigkeiten, die Leistungen und produzierbaren Energiemengen genau vorauszusagen.
Um die Kosten zu senken und OWPs wirtschaftlich effizienter zu machen, werden
Konzepte aus der Wirtschaftsmodellierung benötigt, die Optimierung von Kosten des
gesamten Windfarm-Systems, einschließlich der Installation und Wartung, sowie auch
Service-Methodiken.
1.2 Problemstellung
Bei OWPs besteht ein hoher Wartungsbedarf der Anlagen und der Netzinfrastruktur.
Negative Auswirkungen der schwierigen Bedingungen auf See verschärfen das Problem.
Wartungseinsätze sind durch das Terrain erschwert: Wellengang, Tide, Temperaturen,
Wind und Sichtverhältnisse sind einige der Einflussgrößen, die bei der Wartung von
OWPs zu berücksichtigen sind.
Turbinen sind weniger zugänglich, wenn sie sich entfernt von der Küste befinden.
Dies macht Wartungsschiffe für den alltäglichen Zugang oder ein Jackup-Hubinsel für
kompliziertere Wartung, wie beispielsweise Ersatz von Schwerkomponenten, notwendig.
Die Zuverlässigkeit ist dabei wichtiger als für Onshore-Turbinen. Der Zugang zu Turbinen
ist durch Hubschrauber oder Wartungsschiffe möglich. Einige Windfarmen befinden sich
weit weg von möglichen Onshore-Lagern und haben Dienstmannschaften, die vor Ort in
Offshore-Hotelschiffen leben.
Aufgrund der Entfernung von der Küste werden Prognose- und Kontrollsysteme für
Offshore-Turbinen notwendig. Sie würden bessere Planung und rechtzeitige Wartung
ermöglichen, und dadurch die Service- und Wartungskosten reduzieren. Die Analyse
sollte terrainspezifische Bedingungen wie Wind, Wellengang und Strömung berücksichtigen.
OWPs sind stark von Umweltbedingungen abhängig. Wegen der genannten Faktoren
ist eine der größten Schwierigkeiten, die Auslastungen von OWPs vorherzusagen und
zu planen. Daher könnte eine Simulations- und Planungssoftware zur Koordinierung der
Wartungseinsätze hilfreich sein. Eine solche Software kann einen bedeutenden Beitrag
leisten, einen optimalen Service unter Berücksichtigung von Umwelteinflüssen und anderen
Bedingungen zu gewährleisten.
Im Rahmen der Projektgruppe (PG-SCOWS) wird eine solche Simulations- und Planungssoftware
zur Koordinierung der Wartungseinsätze entwickelt, wobei ein Planungshorizont
von einem Tag vorgesehen ist. Dieses Werkzeug soll bei der Planung, Koordinierung
und Optimierung von Wartungseinsätzen an Offshore-Windenergieanlagen entscheidungsunterstützend
wirken. Es soll dem Planer solcher Einsatzszenarios somit als
Entscheidungsunterstütznugssystem zur Verfügung stehen.
1.3 Projektziele
Das Ziel dieser PG ist es ein flexibles Werkzeug für eine simulationsbasierte Koordinierung
der Service(-fahrten) an Offshore-Windparks zu realisieren. Das Simulationswerkzeug
verfügt zudem über eine grafische Benutzeroberfläche, die eine intuitive Bedienbar-
2

1.4 Struktur der Arbeit 1 EINLEITUNG
keit ermöglicht. Das Simulationswerkzeug soll zu einem Entscheidungs- und Planungssystem
für Akteure von OWP-Servicing werden.
Daneben sollen zur Realisierung als notwendige Bedingung möglichst realitätsnahe
Einflussfaktoren verwendet werden. Das bedeutet, dass der Versuch unternommen
wird, bei der Entwicklung auf ”
echte“ Daten zurückzugreifen, wie beispielsweise Meeresströmung,
Wetterlage, Umweltdaten oder Verkehrslage. Darüber hinaus werden gesetzliche
Rahmenbedingungen, Sicherheitsaspekte und Störungsdaten sowie Navigation,
Wartung und logistische Prozesse ebenfalls berücksichtigt.
Mit Hilfe dieses Werkzeugs soll es möglich sein, heterogene und realitätsnahe Szenarien
des OWP-Servicing zu modellieren und zu simulieren, sodass Optimierungspotentiale in
diesem Bereich identifiziert werden und entsprechend auf echte Szenarien abgebildet
werden können.
Ergebnis sollte die Optimierung der Windparkversorgung sein, die durch eine graphische
Simulation visualisiert werden kann. Als Merkmale können die folgenden Punkte
genannt werden:
• Optimierung der Einsatzszenarios bei gegebenen Parametern, wie Schiffsanzahl,
Anzahl von Maßnahmen an Anlagen etc.
• Evaluation von Strategien durch Verwendung eines agentenbasierten Simulationsframeworks
• Dynamische Visualisierung der Ergebnisse
Es wird also das Ziel verfolgt, eine Software zu entwickeln, die dabei hilft, Prozesse und
Charakteristika eines Offshore-Windparks in Bezug auf die Wartungseinsätze zu modellieren
und verschiedene Szenarien mit unterschiedlichen Parametern durchzuspielen. Um
ein hohes Maß an Usability zu gewährleisten, ist weiterhin eine graphische Benutzungsoberfläche
vorgesehen.
1.4 Struktur der Arbeit
Die Projektarbeit der PG-SCOWS ist hauptsächlich in zwei Phasen aufgeteilt. Zum einen
die Hinführung an die Thematik zur Realisierung einer Software. Aus diesem Grund
gliedert sich die Projektdokumentation in drei Teilbereiche auf:
1. Einführung in das Projekt
2. Grundlagenkapitel
3. Visionsrealisierung
Die Einführung in das Projekt befasst sich zum einen mit der Vorstellung - Einleitung. Im
ersten Teil wird beschrieben, welche Motivation zur Bearbeitung dieses Themas zugrunde
liegt. Anhand dieser Informationen wird die allgemeine Problemstellung erläutert, um
das Projektziel - die Vision für das Projektergebnis bzw. Produkt zu entwickeln. Aus
3

1.4 Struktur der Arbeit 1 EINLEITUNG
dieser inhaltlichen Entwicklung ergibt sich die Struktur der Projektarbeit. Abgeschlossen
wird die Einleitung mit der Vorstellung des PG-Teams und eines kurzen Profils jedes
einzelnen Projektmitglieds.
Der nächstfolgende Schritt ist die Projektorganisation. Im Kapitel 2 Projektplanung
wird beschrieben, nach welchem allgemeinen Vorgehensmodell die Produktentwicklung
vorangetrieben werden soll. Des Weiteren ist der Einsatz von den zu nutzenden Werkzeugen
im Projekt zur Projektkommunikation, Produktentwicklung, Dokumentation usw.
definiert und offengelegt. Im Abschnitt der Projektphasen wird detailliert beschrieben,
welche einzelnen Phasen durchlaufen und abgearbeitet werden müssen. Hierbei geht es
insbesondere darum erkenntlich zu machen, wie im Projekt vorgegangen wurde.
Das Grundlagenkapitel ist sehr umfangreich. Jedes einzelne Thema wird von einem
Projektteammitglied intensive aufgearbeitet. Damit die Grundlagen allen eingängig sind,
ist in der Seminarphase ebenfalls ein Vortrag zu halten über 30 Minuten zu halten. Außerdem
sind die Seminararbeiten zu verschriftlichen und dokumentieren. Die Inhalte
werden aus wissenschaftlicher Sicht als aktueller Forschungsstand betrachtet und behalten
über diese Zeit die Gültigkeit. Hinzukommt, dass der Autor der Seminararbeiten
als Ansprechpartner für den weiteren Projektverlauf gilt, auch wenn das Teammitglied
nicht weiter in diesem Schwerpunktbereich forschen sollte. In der Seminarphase werden
parallel Interviews geführt, Vorträge besucht und an Workshops teilgenommen. Diese
werden zu den Grundlagen gezählt und im Kapitel 3.11 Expertengespräche beschrieben.
Anhand der bisher bearbeiteten Grundlagen, wird das Problem und die Ausgangssituation
genauer aufgearbeitet und anhand der erarbeiteten Informationen ein Hauptszenario,
welches als Orientierung im Projekt dient, vorgestellt.
Im darauffolgenden Kapitel werden die Anforderungen an die Software erhoben und
analysiert. Diese sind teilweise aus dem Pflichtenheft, welches in Zusammenarbeit mit
den Projektauftraggebern der Lehre und Forschung entstanden ist, zu entnehmen. Durch
die Expertengespräche wurden weitere Aspekte hinzugewonnen und andere verworfen,
um ein in sich konsistentes Softwareprodukt zu entwerfen.
Entsprechend den Anforderungen wurden einzelne Module für die Software angedacht
und theoretisch in Konzeptionen verdeutlicht und vertieft. Insgesamt sind im Kapitel
6 Konzepte vier verschiedene vorgestellt. Zum einen die graphische Oberflächengestaltung
(kurz Graphical User Interface (GUI)), die Scheduling-Ebene, der Optimierung
und Simulation. Die Optimierung wird unter drei verschiedenen Ansätzen betrachtet.
Das Kapitel wird mit einem Schnittstellenplan abgeschlossen, damit jeder weiß, wie die
Module untereinander arbeiten sollen mit welchen Daten.
Als nächste wird die entwickelte Software im einzelnen beschrieben. Erhebliche Abweichungen
von den einzelnen Konzepten werden hier insbesondere noch einmal beschrieben
und wieso es zu diesen Veränderungen gekommen ist. Dabei wurde berücksichtigt, dass
die Anwendung auch installierbar ist und wie diese installiert wird.
Die entwickelte Anwendung soll möglichst einwandfrei funktionieren, keine Fehler enthalten
und entsprechend der Anforderungsanalyse umgesetzt sein. Es sollte demnach
nicht zu unschönen Abstürzen oder unerklärlichen Phänomenen kommen. Deswegen
wurden verschiedene Tests durchgeführt und die Software validiert. Außerdem werden
4

1.5 Projektteam 1 EINLEITUNG
die umgesetzten Optimierungsverfahren evaluiert, um daraus Rückschlüsse ziehen zu
können.
Abgerundet wird die Projektarbeit mit einer Zusammenfassung des gesamten Projekts.
Dazugehört sowohl ein Fazit über das Ergebnis bzw. Endprodukt, aber auch eine kritische
Auseinandersetzung mit dem Projektverlauf. Vollendet wird die Dokumentation mit
einem Ausblick auf angrenzende Themenbereiche, wo noch Potenziale zu erkennen sind
und welche Thematik sich für anschließende Projekte, Master- bzw. Bachelorarbeiten
eignen könnte. Im Anschluss ist die verwendete Literatur aufgelistet, ein Stichwortverzeichnis
und weitere Dokumenten spezifischen Inhalte, wie die Anhänge (Pflichtenheft,
Protokolle der Sitzungen etc.).
Unter den römischen Ziffern sind Verzeichnisse enthalten, die der Orientierung dienen.
Darüber hinaus wurde ein Glossar erstellt, um verwendete Begrifflichkeiten nachschlagen
zu können. Häufig sind diese auch in Verbindung mit Abkürzungen zu finden sowie
auch im Stichwortverzeichnis. Wie bekannt ist, helfen Abbildungen und Tabellen zur
Erklärung von komplexen Themenzusammenhängen.
1.5 Projektteam
Das Team SCOWS setzt sich aus zehn studentischen Projektmitgliedern und zwei Projektbetreuern
der Carl von Ossietzky Universität Oldenburg zusammen (die Forschungsgruppe
ist in Abbildung 1: 1 dargestellt). Zu Beginn des Projekts haben wir uns entschieden,
dass es eine organisatorische Projektleitung gibt, die für die Verteilung und Koordinierung
der Aufgaben zuständig ist. Des Weiteren wurde festgelegt, dass SCRUM als
Vorgehensmodell in angepasster Form genutzt wird, um möglichst flexibel Änderungen
vornehmen zu können. SCRUM beinhaltet einen SCRUM-Master, der den SCRUM-
Prozess überwacht und steuert.
Dies soll eine Gleichberechtigung im Projektteam fördern und den Entwicklungsprozess
dynamisch halten. Des Weiteren ist ein regelmäßige wöchentliche Projekttreffen,
genannt Scrum-Weekly, festgelegt worden. Diese Zeit wird genutzt, um Probleme zu besprechen,
zu berichten, was abgearbeitet wurde und das Projekt überwachen und steuern
zu können.
Innerhalb des Projektteams wurden kleinere Arbeitsgruppen gebildet, die sich an die
zu entwickelnden Module ausrichten. Bei Fertigstellung von Modulen können die frei
werdenden Mitarbeiter sich neuen Modulen widmen oder einer anderen Arbeitsgruppe
anschließen.
1.5.1 Projektbetreuer
Das Projekt wird von apl. Prof. Dr.-Ing Jürgen Sauer und Dipl.-Inform. Jan-Hinrich
Kämper betreut. Diese unterstützen den Fortschritt des Projektes, sodass ein nützliches
Ergebnis herauskommt. Die Betreuer stellen sich kurz vor und die Erwartung an das
Projekt.
5

1.5 Projektteam 1 EINLEITUNG
Abb. 1: Gemeinsames Projektgruppenfoto - Hintere Reihe von links: Christian Menne,
Raphaël François Kaiser, Jan-Hinrich Kämper, Carsten Buschmann und André
Wolter; vordere Reihe von links: Georg Berendt, Stefan Wunderlich, Shimal
Ibrahim und Khisrav Evazov; es fehlten: Nashida Barakat, apl. Prof. Dr.-Ing
Jürgen Sauer und Svetlana Kapitanova
1.5.1.1 Jan-Hinrich Kämper
Abb. 2: J.-H. Kämper
Als Betreuer dieser Projektarbeit möchte ich den
Teilnehmern die Möglichkeit einer spannenden Projektarbeit
in einem aktuellen Forschungsfeld der
Abteilung bieten. Neben anwendungsorientierten
Inhalten, die die Offshore Branche und damit
verbundene Logistikaspekte betreffen, sollen auch
grundlegende Inhalte in den Bereichen Simulation
und Optimierung vermittelt werden. Durch
die selbständige Organisation der Projektmitglieder
und das Projektmanagement können bereits
Fähigkeiten geübt werden, die im Berufsumfeld
später ausgeprägter in Erscheinung treten. Dass
dieser Spagat zwischen wissenschaftlicher Arbeit
und der Arbeitsweise angelehnt an die Software-
6

1.5 Projektteam 1 EINLEITUNG
produktentwicklung gelingt, ist mein Anliegen als
Betreuer der Gruppe. Zielvorstellung dabei ist es, den Teilnehmern dem Prinzip der
forschungsorientierten Lehre folgend hohe Schaffensfreiheit zu gewähren, um Ergebnisse
zu erhalten, die tatsächlich auf den eigenständigen Recherchen und Untersuchungen der
Gruppe basieren.
Persönlich bin ich sehr an den Ergebnissen der Projektarbeit interessiert und erhoffe
mir darauf weitgehend neue Erkenntnisse, die die Praxis der Planung von Offshore
Services verbessern. Das in diesem Bereich liegende Optimierungspotential wurde in
der Branche bisher kaum berücksichtigt und es bedarf neuer Innovation, um es auszuschöpfen,
auch und vorallem aus dem universitären Umfeld.
1.5.2 Studentische Projektmitglieder
In diesem Kapitel stellt sich jede Mitglied vor. Einführend wird etwas persönliches
festgehalten, wie zum Beispiel der Studiengang, das Studiensemester zu Projektbeginn
und weiteres nach persönlichem Empfinden. Ergänzt wird dieser Abschnitt mit
der Erwähnung des Vertiefungsschwerpunkts und die Aufgaben im Projekt.
Darauf folgend wird die Erwartungshaltung an das Projekt und das Projektteam beschrieben
und zusätzlich die Zusammenarbeit des Teams, besondere Ereignisse, Erfahrungen
und jegliches Erwähnenswertes.
1.5.2.1 Nashida Barakat
Mein Name ist Nashida Barakat und ich studiere
Wirtschaftsinformatik an der Carl von Ossietzky
Universität Oldenburg im 3. Mastersemester.
Am Anfang des Projektes habe ich mich für den
Schwerpunkt Offshore Windfarmen “ entschieden.
”
Ich erarbeite die Anforderungen, welche von der zu
implementierenden Software erfüllt werden sollen.
In diesem Projekt arbeite ich als Reporter, der
letztendlich die Ergebnisse dieses Projektes zusammenfasst.
Die Projektmitglieder waren stets offen
und hilfsbereit, wenn ich ein Problem hatte. Ich
kann sagen, dass ich viel gelernt habe, insbesondere
wie in einem Team gearbeitet wird. Darüber hinaus
Abb. 3: N. Barakat habe ich Strategien kennen gelernt, Projektarbeit
zu delegieren.
An das Projekt habe ich folgende Erwartungen: Neues Fachwissen gewinnen zu können,
das später für einen Beruf von großer Notwendigkeit ist, besonders in neuen aktuellen
Bereichen wie Offshore-Windenergieparks und Erneuerbare Energien.
7

1.5 Projektteam 1 EINLEITUNG
1.5.2.2 Georg Berendt
Ich heiße Georg Berendt und habe das Studium der
Informatik an der Carl von Ossietzky Universität
Oldenburg aufgenommen. Der gewählte Schwerpunkt
in diesem Projekt ist Wetterdaten“ zur Simulation
des Offshore-Klimas. Des Weiteren über-
”
nehme ich Aufgaben der Softwareadministration/-
architektur sowie die Optimierungsaufgabe, die
zusätzlich den Kern der Softwarelösung darstellt.
An das Projekt habe ich die Erwartung, dass ich
durch die Zusammenarbeit an einem derzeit aktuellen
Forschungsthema meine Kenntnisse in der Softwarekonzeption
und -entwicklung erweitern bzw.
Abb. 4: G. Berendt vertiefen und mir durch die Projektarbeit auch
neues Fachwissen aneignen kann. Mit dem Hintergrund
einiger Erfahrungen im Bereich der regenerativen Energien erhoffe ich mir zudem,
einen tieferen Einblick in diesem Arbeitsumfeld gewinnen zu können.
Kein Projekt verläuft hundertprozentig geplant und linear, genauso wenig dieses. Die
Atmosphäre im Team war nicht immer sachlich und lösungsorientiert. Trotz allem konnten
sich die Teammitglieder bei der letztendlichen Problemlösung aufeinander verlassen.
1.5.2.3 Carsten Buschmann
Ich werde mit dem Name Carsten Buschmann angesprochen
und studiere Wirtschaftsinformatik an
der Carl von Ossietzky Universität Oldenburg im 2.
Mastersemester. Der gewählte Schwerpunkt in diesem
Projekt ist Logistik und Infrastruktur “ zur
”
Koordinierung von Prozessabläufen. Des Weiteren
übernehme ich Aufgaben der Projektleitung/-
koordinierung sowie die Dokumentationsaufgabe,
die zusätzlich für die Qualitätssicherung verantwortlich
ist.
An das Projekt habe ich folgende Erwartungen:
Zusammenarbeit an einem jungen Forschungsthema
zur Vertiefung sowohl meiner Kenntnisse durch
Abb. 5: C. Buschmann die Projektarbeit als auch Aneignung neuen Fachwissens.
Durch ein verstärktes Interesse an regenerativen
Energien erhoffe ich mir einen tieferen Einblick in diesem Arbeitsumfeld gewinnen
zu können.
Die Arbeitsatmosphäre im Projekt war manch einmal angespannt und stressig, aber es
war dennoch eine hervorragende Teamdynamik zu erkennen. Sind Probleme aufgetreten,
konnte auf die Unterstützung der Teammitglieder zurückgegriffen werden. Dabei wurden
interessante Lösungen, Ideen und Konzepte gefunden und entwickelt.
8

1.5 Projektteam 1 EINLEITUNG
1.5.2.4 Khisrav Evazov
Mein Name ist Khisrav Evazov und ich studiere
Wirtschaftsinformatik an der Carl von Ossietzky
Universität Oldenburg im 4. Mastersemester.
Der gewählte Schwerpunkt in diesem Projekt sind
die HSE Aspekte“ zur Koordinierung von Prozessabläufen.
Ich habe mich weiterhin mit der GUI,
”
dem Scheduling und der Simulation beschäftigt.
An das Projekt habe ich folgende Erwartungen:
Verstärkung der Kenntnisse im Bereich der Windenergie
und die Weiterentwickelung meiner eigenen
Fähigkeiten in der Planung und Programmierung
sowie dem erwerben von Soft Skills. Da der Bedarf
an erneuerbaren Energiequellen weltweit steigend
Abb. 6: K. Evazov ist, vertiefe ich meine Kenntnis in diesem Bereich.
Die Arbeitsatmosphäre in der Projektgruppe
war sehr angenehm als auch hilfsbereit. Gab es Probleme und Schwierigkeiten konnten
diese besprochen werden und wurden in der Gruppe behandelt. Soweit möglich, wurden
die Aufgaben mit der Hilfe von Gruppenmitglieder und der Projektleitung gelöst.
1.5.2.5 Shimal Ibrahim
Abb. 7: S. Ibrahim
Zurzeit studiere ich an der Carl von Ossietzky
Universität Oldenburg im Masterstudiengang
Wirtschaftsinformatik im 2. Semester. Das Projekt
SCOWS wird im Rahmen des Studienplans durchgeführt.
Das Projekt wird in den Bereichen Logistik und
Infrastruktur eingeordnet.
Der Schwerpunkt des Projektes liegt bei der Koordinierung
von Prozessabläufen in den Bereichen
Logistik und Infrastruktur “. Hierbei werden die
”
Aktivitäten (Jobs) der Offshore-Betreiber simuliert
und ein möglichst optimales Verhalten vorgeschlagen.
In meiner Rolle als Projektleiter (mit Unterstützung
durch Carsten als Wachablöse, wenn ich
verhindert sein sollte) bin ich für das Management und die effiziente Abarbeitung von
Prozessen verantwortlich. In diesem Rahmen versuche ich in der Gruppe eine gute Arbeitsatmosphäre
zu schaffen und Schwierigkeiten zu beseitigen. Auch wenn Schwierigkeiten
und Probleme auftauchen, so versuche ich mit der Gruppe durch interessante Lösungen,
Ideen und Konzepte diese zu überwinden. Probleme zwischen den Teammitglieder
konnte ich mit Unterstützung von Carsten stets durch erfolgreiches Konfliktmanagement
lösen.
9

1.5 Projektteam 1 EINLEITUNG
Im Weiteren bin ich im Simulationsmodul tätig und übernehme zudem die Verantwortung
für die gesamte GUI.
An das Projekt habe ich folgende Erwartungen: Gewinnung und Vertiefung von Kenntnisse
über neue Forschungsgebiete. Das Projekt ist praxisorientiert, jedoch braucht es
viele theoretische Grundlagen. Aus diesem Grund hoffe ich mein Fachwissen im Projekt
anwenden zu können. Weiterhin erwarte ich eine gute Zusammenarbeit mit allen
Teammitglieder sowie einen erfolgreichen Abschluss des Projektes.
1.5.2.6 Raphaël François Kaiser
Ich bin Student der Informatik mit der Vertiefungsrichtung
IT in der Energiewirtschaft. In der Projektgruppe
habe ich das Thema Simulation vorgestellt
und arbeite an der Konzeption der Optimierung
im Optimierungsteam. Außerdem bin ich für
Teile der Webseite verantwortlich und pflege den
Twitter-Kanal des SCOWS Projekts.
Durch dieses Projekt erhoffe ich mir ein besseres
Verständnis für die in der Öffentlichkeit kontrovers
diskutierten Offshore-Windparks erlangen.
Das Problem der Optimierung der Koordination
von Offshore-Wartungseinsätzen stellt eine Herausforderung
dar und ist eine Chance, Fachwissen
Abb. 8: R. Kaiser
anhand einer praxisrelevanten Problemstellung zu
sammeln.
Besonders interessant fand ich den Kontakt zu externen Experten aus unterschiedlichen
Unternehmen und Projekten, wie z. B. der Overspeed GmbH, der BTC AG oder dem
SystOp Projekt.
1.5.2.7 Svetlana Kapitonova
Mein Name ist Svetlana Kapitonova und ich studiere Wirtschaftsinformatik an der Carl
von Ossietzky Universität Oldenburg im 2. Mastersemester. Am Anfang des Projekts
habe ich mich für den Schwerpunkt ”
Reederei “ entschieden. Des Weiteren habe ich an
der Anforderungsdefinition gearbeitet und Aufgaben im Bereich Projektdokumentation
übernommen.
An das Projekt habe ich folgende Erwartungen: Meine Kenntnisse im aktuellen Themenbereich
der Offshore-Windenergie zu vertiefen, sowie meine Fähigkeiten zu erweitern
und neue Erfahrungen zu sammeln, die mir im weiteren Berufsleben nützlich sein können.
Durch die Projektarbeit hoffe ich, einen tieferen Einblick in das Feld der erneuerbaren
Energien zu gewinnen und neues Fachwissen aneignen zu können.
Die Arbeitsatmosphäre im Projekt war sehr motiviert und ergebnisgerichtet. Die entstehenden
Schwierigkeiten konnten immer durch Teamarbeit gelöst werden. Die Aufgaben
waren spannend und nicht trivial und erforderten neue Ideen und Lösungen. Durch
die gemeinsame Forschungsarbeit im Rahmen des Projekts konnten viele neue Kennt-
10

1.5 Projektteam 1 EINLEITUNG
nisse und Erfahrungen erworben werden.
1.5.2.8 Christian Menne
Ich heiße Christian Menne, studiere Informatik mit
der Vertiefungsrichtung Energieinformatik und bin
im 5. Mastersemester. Am Anfang des Projektes
habe ich mich für den Schwerpunkt ”Optimierung”
entschieden, da ich mich schon in der Vorbereitung
auf die Masterarbeit mit dem Thema der kombinatorischen
Optimierungsprobleme auseinandergesetzt
habe. Zwar arbeite ich hauptsächlich an der
Simulationskomponente und helfe bei der Implementierung
der GUI, aber ich versuche, mein gesammeltes
Wissen als Schnittstelle zwischen Simulation
und Optimierung einzubringen.
Meine große Erwartung an das Projekt ist, das
Abb. 9: C. Menne im Studium angesammelte Wissen auf ein aktuelles
Thema im Bereich der erneuerbaren Energieerzeugung
anwenden zu können, und somit Erfahrungen zu sammeln, die mir im späteren
Berufsleben nützlich sein können. Zudem hoffe ich, mit dem gesamten Projektteam ein
Ergebnis zu erzielen, auf das wir alle am Ende der Projektgruppe stolz sein können.
Vor allem die Anfangszeit der Projektgruppe verlief relativ zäh, und es kam nicht
selten vor, das Themen heiß und lang diskutiert wurden, ohne am Ende ein wirkliches
Ergebnis zu erzielen. Doch mit unserer wachsenden Vorstellung des Zielproduktes, wurde
auch die Zusammenarbeit besser und die Arbeit in Kleingruppen verlief sehr produktiv.
Ist doch einmal ein Problem aufgetreten, das innerhalb der Gruppe nicht geklärt werde
konnte, war auf die Hilfe aus den anderen Gruppen verlass.
11

1.5 Projektteam 1 EINLEITUNG
1.5.2.9 André Wolter
Ich heiße André Wolter, bin 37 Jahre alt und wohne
in Oldenburg. Zurzeit studiere ich im Masterstudiengang
Wirtschaftsinformatik an der Universität
Oldenburg.
Im Rahmen dieser Projektgruppe habe ich das
Thema Navigation erarbeitet. Zusätzlich war ich
für das Thema Optimierung tätig.
Bei dem Thema Navigation wurde untersucht,
inwieweit bei der Wartung eines Windparks die
grundsätzlichen Gesetze, Richtlinien und Verordnungen
eine Rolle spielen und wie diese das Ziel der
Projektgruppe bei Entscheidungen beeinflussen.
Für die Optimierung wurden diverse Ansätze
Abb. 10: A. Wolter untersucht und in mehreren Sitzungen des Optimierungsteams
verglichen und diskutiert. Einige
Ansätze beruhten dabei auf genetischen Algorithmen und andere auf reinen Heuristiken.
Um dem jeweiligen Optimierungsziel näher zu kommen fiel die Entscheidung auf
eine heuristische Suche.
Zu Beginn des Projektes galt mein Interesse dem Einbringen meiner nautischen Kenntnisse.
Im Verlauf wanderte es in Richtung der Optimierung. Dieses teilweise sehr weite
und unspezifische Thema machte mich sehr neugierig. Die Projektgruppe hat damit dazu
beigetragen, dass ich heute über ein grundsätzliche Kenntnisse in dem Bereich der
Optimierung verfüge.
Die Arbeitshaltung in der Projektgruppe war insgesamt sehr motiviert. Teilweise fanden
hitzige Diskussionen über richtige Strategien und Ansätze statt. Dies förderte sowohl
die Bearbeitung der Themen als auch die Widerstandskraft von Argumentationen.
Zurückblickend kann gesagt werden, dass die Diskussionen allesamt sehr konstruktiv
waren und somit die Teams gut vorankamen.
12

1.5 Projektteam 1 EINLEITUNG
1.5.2.10 Stefan Wunderlich
Ich heiße Stefan Wunderlich und studiere Wirtschaftsinformatik
an der Universität Oldenburg im
3. Mastersemester. Mein gewählter Schwerpunkt
in diesem Projekt ist Entwurfsmethoden“. Meine
Hauptaufgabe ist jedoch im Bereich Optimie-
”
”
rung“ zu finden. Im Rahmen eines kleinen Teams
mit Raphael und André erarbeiten wir das Optimierungskonzept
der Servicefahrten hinsichtlich
Kosten, Zeit und weiteren Zielgrößen. Darüber hinaus
zählt die Implementierung dieses Konzepts zu
meinen Aufgaben. Zudem übernehme ich einzelne
Aufgaben im Bereich der Projektdokumentation.
An das Projekt habe ich folgende Erwartungen:
Abb. 11: S. Wunderlich Erarbeitung eines recht neuen Forschungsthemas in
einem Team engagierter und kompetenter Mitglieder.
Wie in vielen Projekten ist nicht immer alles gut gelaufen, es gab an verschiedenen
Stellen Reibungspunkte und manch einmal hitzige Diskussionen. Dennoch wurde meist
zielführend und effizient gearbeitet, alle Projektgruppenmitglieder haben stets an einem
Strang gezogen und sich im Rahmen ihrer Fähigkeiten voll eingebracht.
13

2 PROJEKTPLANUNG
2 Projektplanung
Dieses Kapitel beschreibt die Projektorganisation der Projektgruppe, welche einen wichtigen
Teil im Rahmen des Projekts, das über die Dauer von zwei Semestern läuft, darstellt.
Im ersten Abschnitt wird das Vorgehensmodell der Projektgruppe beschrieben. Im
zweiten Abschnitt werden die Werkzeuge vorgestellt, die im Rahmen der Projektgruppe
benutzt wurden. Der Abschnitt ”
Projektphasen“ zeigt die einzelnen Phasen auf, die im
Zeitraum des Projekts durchlaufen wurden.
2.1 Vorgehensmodell
Zu Beginn des Projekts wurde entschieden, dass Scrum als (agile) Vorgehensweise genutzt
werden soll. Scrum wird ausführlich im Kapitel Seminararbeiten 3.7 Entwurfsmethoden
vorgestellt. Im Laufe des Projekts ist allerdings zusätzlich auch das Wasserfallmodell
zu erkennen, indem einzelne Projektphasen festgelegt und definiert wurden. Das
Projekt ist fließend durch diese Phasen verlaufen, wobei die erreichten Ergebnisse am
Ende jeder Phase in die Entwicklung der nächsten Phase eingegangen sind.
Das Wasserfallmodell ist insbesondere für die Projekte geeignet, bei denen sich die Anforderungen
relativ präzise beschreiben lassen. Daher ist oftmals ein hoher Aufwand in
der Analyse- und Ideenphase betrieben. Scrum sorgt zusätzlich für eine dynamische und
flexible Entwicklung und Entfaltung des Projekts. Es ist ein zyklisches Vorgehensmodell,
das durch kurze Entwicklungsphasen und reguläre Treffen eine besonders effiziente
und agile Vorgehensweise darstellt. Die beiden Vorgehensmodelle haben Vor- sowie auch
Nachteile. Jedoch lassen sie sich gut mit einander kombinieren und ergänzen einander.
Dadurch ist ein effektiver Verlauf des Projekts zu erwarten.
Die Arbeit im Projekt wurde wie folgt organisiert. Es wurde ein regelmäßiges Treffen,
einmal pro Woche, festgelegt, bei denen alle Mitglieder anwesend sein sollten. Bei jedem
Treffen wurden ergebnisorientierte Protokolle erstellt und es gab einen Moderator.
Die Rollen von Protokollant und Moderator wurden von den Mitgliedern in alphabetischer
Reihenfolge der Nachnamen durchgeführt. So wurden die Ergebnisse der regulären
wöchentlichen Sitzungen dokumentiert. Die Protokolle befinden sich im Anhang dieses
Dokuments. Der Moderator sorgte dafür, dass die Tagesordnung eingehalten und die
Diskussionen effizient und konstruktiv durchgeführt werden. Die Tagesordnung wurde
kurz vor der Sitzung per E-Mail an allen Mitgliedern verschickt, damit jeder sich für
die genannten zu besprechenden Punkte vorbereiten konnten und das Treffen dadurch
effizienter abgearbeitet werden können.
Das regelmäßige Projekttreffen diente zur Besprechung der Ergebnisse und der Probleme,
zum Informationsaustausch und Koordinierung des Projekts. Hier wurden die
Aufgaben und Arbeitspakete erstellt und verteilt. Darüber hinaus wurde das Treffen als
Schnittstelle zwischen den Betreuern des Projekts und der Projektgruppe genutzt.
Die Bearbeitung von Arbeitspakete erfolgte weiter in Kleingruppen, teilweise gab es
aber auch Einzelaufgaben. Für jede Kleingruppe wurde jeweils ein wöchentliches Treffen
festgelegt. Die Ergebnisse wurden beim Projekttreffen erläutert. Dadurch konnte eine
bessere Kommunikation zwischen den einzelnen Gruppen erreicht werden.
14

2.1 Vorgehensmodell 2 PROJEKTPLANUNG
Die Aufgaben wurden in Form von Tickets in Redmine angelegt. Die Tickets mussten
dann dem jeweiligen Sprint zugeordnet werden. Die folgende Abbildung zeigt die Ansicht
von Sprint 0.0.1 alpha in Redmine.
Abb. 12: Die Ansicht von Sprint 0.0.1 alpha in Redmine
Es wurden die folgenden Sprints festgelegt:
• 0.0.1 alpha (31.05.2013)
In dieser Phase werden die Grundlagen aufbereitet, einzelne Bausteine und Basisfunktionen
implementiert.
• 0.0.5 alpha (13.06.2013)
In dieser Phase werden die einzelnen Module fertiggestellt und die Beziehungen
zueinander implementiert. Gegebenenfalls wird alpha 0.0.1 mit optionalen Features
ergänzt.
15

2.2 Werkzeuge 2 PROJEKTPLANUNG
• 0.0.9 alpha (27.06.2013)
In dieser Phase werden die einzelnen Module zusammengefügt und auf Kompatibilität
geprüft.
• 0.1.0 beta (11.07.2013)
In der ersten Betaphase werden Testfälle entwickelt und die ersten Unit-Tests
durchgeführt.
• 0.5.0 beta (25.07.2013)
In der Beta-Phase 0.5.0 werden weitere Testfälle ergänzt. Des Weiteren die vorherigen
Fehler behoben und es werden User-Tests durchgeführt.
• 0.9.0 beta (16.08.2013)
In dieser Version werden alle kleineren und größeren Fehler behoben.
• 1.0.0 final (31.08.2013)
Das Projekt SCOWS wird mit der Projektabgabe, der Präsentation und Projektdokumentation
abgeschlossen.
2.2 Werkzeuge
Im Rahmen des Projekts wurden verschiedene Werkzeuge genutzt, um die Entwicklung
und Ablauf des Projekts zu unterstützen. In diesem Abschnitt werden die relevanten für
das Projekt Werkzeuge kurz vorgestellt.
2.2.1 Redmine
Redmine ist ein webbasiertes Projektmanagement-Tool. Es kann für die Benutzer- und
Projektverwaltung, für Diskussionsforen, Wikis, zur Ticketverwaltung oder Dokumentenablage
genutzt werden 3 . Im Rahmen des Projekts wurde Redmine als Tool zur Verteilung
der Aufgaben und Überwachung des Projektzustands eingesetzt. Zudem diente es
als Austauschplattform von Dateien und Dokumenten, die im Projektarchiv hinterlegt
werden können. Die Aufgaben wurden in Redmine in Form von Tickets dokumentiert.
Jedes Mitglied hat eine eigene Sammlung von Tickets innerhalb der Sprints. Im Zusammenhang
mit Scrum erweist sich Redmine als sehr effizient, um die Teamarbeit zu
organisieren.
Redmine bietet folgende Funktionen an:
• Verwalten von Aktivitäten: To-Do-Listen, Ziele, offene Punkte und Deadlines,
Zuordnung von Zuständigkeiten, Erfassungsmöglichkeit für den Fortschritt beziehungsweise
offene und gefällte Entscheidungen
• Hinterlegen von Dateien zur Dokumentation der verschiedenen Projektschritte
3 http://de.wikipedia.org/wiki/Redmine, abgerufen am 02.06.2013
16

2.2 Werkzeuge 2 PROJEKTPLANUNG
• Projektbezogenes Wiki zur gemeinsamen Bearbeitung von Dokumenten
• News-Bereich zur zentralen Verteilung von Neuigkeiten im Projekt
• Diskussionsforum
• Projektzeiterfassung
Im Projekt wird Redmine eingesetzt werden. In der Seminarphase sind des Weiteren alle
Seminararbeiten im Wiki erfasst, um einen Überblick über relevante Thematiken für
alle Mitglieder zu ermöglichen. In der Entwicklungsphase sind in Redmine alle Sprints
mit den zugeordneten Tickets erfasst, was eine effizientere Zeitplannung des Projekts
ermöglicht.
2.2.2 Git
Git ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die ursprünglich
für die Quellcode-Verwaltung des Linux-Kernels entwickelt wurde 4 . Bei der Softwareentwicklung
wird Git als ein verteiltes Versionsverwaltungs- und Quellcode-Managementsystem
angewendet.
Jedes Git-Arbeitsverzeichnis ist ein Repository mit der gesamten Geschichte und den
vollen VersionsverfolgungsFähigkeiten, die vom Netzzugang oder einem Hauptserver unabhängig
sind.
Im Rahmen des Projekts kann Git erfolgreich zur Versionsverwaltung sowie als Werkzeug
zur Entwicklung des Software-Tools benutzt werden.
2.2.3 LaTeX
Für die Dokumentation der Ergebnisse und Erstellung des Abschlussberichtes wird L A TEX
hinzugezogen. L A TEX ist verhältnismäßig effizientes Werkzeug zur Erstellung von wissenschaftlichen
Texten. Der Einsatz von L A TEX vereinfacht die technische Seite der Textverfassung.
Durch das Fokussieren auf Inhalt und logischer Struktur eines Textes ist ein
Produktivitätsgewinn erreichbar. Im Rahmen der Projektgruppe können die Arbeit an
der Dokumentation mittels L A TEX optimiert werden. L A TEX stellt eine Möglichkeit bereit,
die Dokumentation durch mehrere Benutzer gleichzeitig zu bearbeiten und ändern, indem
durch die Bearbeitung von den jeweiligen Dateien in einer extra angefertigten TeX-Datei
erfolgt, die sich dann in eine ansprechende Form übersetzen lassen. Jedes TeX-Dokument
kann entweder per ”
include“, einer neuen Seite im Dokument hinzugefügt oder durch
” input“, fortsetzend im LA TEX-Dokument integriert werden.
2.2.4 Eclipse
Eclipse ist ein quelloffenes Programmierwerkzeug zur Entwicklung von Software verschiedenster
Art. Ursprünglich wurde Eclipse als Intergrierte Entwicklungsumgebung (IDE)
4 http://de.wikipedia.org/wiki/Git, aufgerufen am 06.07.2013
17

2.3 Projektphasen 2 PROJEKTPLANUNG
für die Programmiersprache Java genutzt, aber mittlerweile wird es wegen seiner Erweiterbarkeit
auch für viele andere Entwicklungsaufgaben eingesetzt. Für Eclipse gibt
es eine Vielzahl sowohl quelloffener als auch kommerzieller Erweiterungen. 5
Im Rahmen des Projekts wird Eclipse für die Entwicklung der zu entwickelnden
Software in Java eingesetzt. Das Eclipse-Framework stellt umfangreiche Möglichkeiten
zur Verfügung, die auf Grund zahlreicher Erweiterungsmöglichkeiten mittels Plug-Ins
möglich sind. Eine Plug-In basierte Plattform zur Entwicklung der Software ist besonders
vorteilhaft, da durch Plug-Ins neue Funktionalität bereitgestellt werden können,
ohne die gesamte Software neu ausliefern zu müssen.
So kann die Eclipse-Plattform beispielsweise durch das Java Development Tools (JDT)
erweitert werden – das Ergebnis ist die Java-IDE des Eclipse-Projektes. Das JDT ist eine
Sammlung von Plug-Ins, die sich in die Plattform einhängen und neue Features wie zum
Beispiel einen Editor mit Syntax-Highlighting für Java, Refactoring-Tools oder einen
Debugger einbinden lassen.
Zudem beinhaltet das Workspace-Plug-In die Ressourcen-Verwaltung, das heißt es
stellt ein Zugriff auf das Dateisystem bereit. Es gibt den Benutzern die Möglichkeit,
Daten in Dateien zu speichern und Dateien zu laden.
2.3 Projektphasen
Der Zeitraum der Projektgruppe gliedert sich in mehreren Phasen. Diese werden im
Folgenden kurz beschrieben.
Zunächst wird das Ziel verfolgt, verschiedene Aspekte des Betriebs und der Wartung
von OWA zu untersuchen. Am Anfang des Projekts erfolgte zunächst eine Seminarphase,
in welcher relevante Themen, die für das Projekt interessant sein könnten, in
Form von Vorträgen und schriftlichen Ausarbeitungen, vorgestellt und bearbeitet wurden.
Darüber hinaus werden mehrere Interviews mit unterschiedlichen Partnern geführt.
Mit Hilfe der Interviews sollen relevante und detaillierte Informationen über das Projektthema
zusammengetragen und ergänzt werden, um die Anforderungen des Projekts
und die Zielsetzung genauer definieren zu können. Zur Vorbereitung der Interviews ist
ein Fragenkatalog zur einheitlichen Durchführung der Interviews erstellt worden. Die
geführten Interviews werden textuell aufbereitet und ebenfalls schriftlich dokumentiert,
um diese jederzeit einsehen und sich daran orientieren zu können.
Nach der Seminarphase und der Durchführung der Experteninterviews sind die gesammelten
Daten und Informationen verarbeitet, anhand der Ergebnisse wird daraufhin
die Anforderungsanalyse erstellt. Darin sind die funktionalen und nicht-funktionalen
Anforderungen an die zu entwickelnde Software erhoben und spezifiziert. Diese sind in
dem angehängten Pflichtenheft dokumentiert. Gemäß der Anforderungsdefinition wird in
der folgenden Phase des Projekts das Produkt selbst entwickelt. Die Entwicklungsphase
beinhaltet die Umsetzung eines oder mehrerer Optimierungsverfahren, einer Simulationskomponente
und einer grafischen Benutzungsoberfläche. Das Produkt ist darüber
hinaus als Client-Server-Applikation konzipiert.
5 http://de.wikipedia.org/wiki/Eclipse (IDE), abgerufen am 02.06.2013
18

2.3 Projektphasen 2 PROJEKTPLANUNG
In der Endphase des Projekts werden letzte Probleme behoben, sowie abschließend die
während aller Projektphasen geführte Dokumentation überarbeitet. Weiterhin wird in
dieser Phase neben dem Projektabschlussbericht die Projektpräsentation fertiggestellt.
19

3 GRUNDLAGEN DES PROJEKTES
3 Grundlagen des Projektes
In diesem Abschnitt werden die Grundlagen für das Projekt aufbereitet. Dieses Kapitel
beinhalten unterschiedliche Themengebiete, die gleichzeitig den Vertiefungsschwerpunkt
jedes einzelnen Teammitglieds im Projekt setzt. Es ist zwar nicht zwingend erforderlich,
dass an diesem Schwerpunkt weiterhin gearbeitet wird, aber das Projektmitglied steht
als Ansprechpartner für diesen Themenkomplex zur Verfügung.
Des Weiteren gibt es somit Spezialisten für die jeweiligen Teildisziplinen im Projekt,
sodass im weiteren Verlauf des Studiums sich ein besseres Verständnis entwickeln kann.
Außerdem hat so jeder ein Forschungsgebiet, indem beispielsweise eine Abschlussarbeit
anschließen kann.
Folgende Schwerpunkte sind im Projekt gesetzt worden:
• Offshore-Windfarmen
• HSE-Aspekte
• Infrastruktur und Logistik
• Reederei
• Wetterdaten
• Navigationsaspekte
• Entwurfsmethoden
• Simulationstechnik
• Optimierungsverfahren
• Projektmanagement
20

3.1 Offshore-Windfarmen 3 GRUNDLAGEN DES PROJEKTES
3.1 Offshore-Windfarmen
In diesen Abschnitt werden die Grundlagen der OWA erläutert werden. Hierzu wird ein
kurzer Überblick über die Entwicklung von Offshore-Windparks anhand eines Beispiels
aufgeführt. Des Weiteren wird die Thematik mit Begriffsdefinition eingeleitet, um diese
komplexe Materie vertiefen zu können.
3.1.1 Einleitung
Zu Beginn wird eine Begriffsdefinition vorgestellt, die zum Verständnis dieser Ausarbeitung
notwendig ist.
3.1.1.1 Definition des Begriffes ”
Windenergiepark“
Ein Windenergiepark bezeichnet einen Park aus mehreren WEAs an Land oder im offenen
Meer. Windenergieparks können im Binnenland (onshore), an der Küste (nearshore)
oder in erheblichem Abstand von der Küste auf See (offshore) gebaut werden.
3.1.1.2 Definition des Begriffes ”
Offshore-Windenergieparks“
Die Bezeichnung ”
Offshore-Windenergiepark“ wird für einen Verbund von mehreren
WEAs verwendet, deren Fundamente in der See stehen. Dort soll der Wind genutzt
werden, der auf See kontinuierlicher und etwas stärker als an Land bläst. 6
Als Vorzeigeprojekt ist Alpha Ventus anzuführen. Dies ist ein gemeinsames Projekt
der Energieversorgungsunternehmen EWE, E.ON und Vattenfall und wurde als erster
deutscher Offshore-Windenergiepark im April 2010 in Betrieb genommen. Dieses Projekt
wird mit 30 Millionen Euro vom Bundesministerium für Umwelt, Naturschutz und
Reaktorsicherheit (BMU) gefördert. Die reine Bauphase betrug nur ein Jahr, eine Pionierleistung
bei einer Wassertiefe von rund 30 Metern und einer Küstenentfernung von
60 Kilometern. Der Park wird aus der Betriebszentrale in der Stadt Norden gesteuert.
Als Testanlagen werden im OWP Alpha Ventus zwei Typen von Windenergieanlagen
eingesetzt, die auf zwei unterschiedlichen Fundamenten errichtet werden.
Die Nennleistung des Windenergieparks beträgt 60 Megawattstunden (MWh). 7
3.1.2 Errichtung
Die Windenergieanlagen müssen sicher auf dem Boden gegründet werden. Bei Gründung
der OWA spielt die Wassertiefe und die Abstand von der Küste eine große Rolle, dafür
gibt es verschiedene Gründungsmöglichkeiten:
• Flachgründung mit und ohne Schürzen
• Monopile-Gründung (Pfahl) Erde in flaches Wasser, Dänemark und England benutzt
6 http://de.wikipedia.org/wiki/Offshore-Windpark abgerufen am 02.06.2013
7 http://www.alpha-ventus.de/fileadmin/user upload/av Factsheet de Dez2012 2.pdf
21

3.1 Offshore-Windfarmen 3 GRUNDLAGEN DES PROJEKTES
• Tripod-(3 Pfähle) und Jacket-Gründungen (4 Pfähle) kommen für tiefer Bereiche,
bis zu einer Wassertiefe von 50m, in Deutschland zum Einsatz
• Schwerkraft-Fundamente ohne Tiefengründung werden in Zukunft zum Einsatz
kommen
Die Energie wird über Seekabel von dem OWP an die Küste übertragen. An der Küste
wird die Energie dann in das allgemeine Stromnetz eingespeist.
3.1.3 Wartung und Reparatur an OWA
Die Wartungsarbeiten pro OWA betragen bis zu 450 Wartungsstunden im Jahr. Die
planmäßige Jahres-Wartung der WEA erfolgt im Frühling und Sommer, wenn die Wetterbedingungen
die Anfahrt mit Wartungsschiffen möglich sind. Zu den Arbeiten zählen
Korrosionsschutzmaßnahmen, die Überprüfung von Sicherheitseinrichtungen und der
Austausch von defekten Komponenten.
3.1.4 Umweltverträglichkeitsprüfung
Das Bundesamt für Seeschifffahrt und Hydrographie (BSH) führt bei Windenergieparks
”
ab 20 Anlagen eine Umweltverträglichkeitsprüfung durch und prüft, ob die einzelnen
Schutzgüter der Meeresumwelt (z.B. Vögel, Fische, Meeressäuger, Benthos, Boden und
Wasser) durch das Projekt gefährdet werden. Zu diesem Zweck muss der Antragsteller
die Meeresumwelt in dem geplanten Gebiet untersuchen und die Auswirkungen des
Vorhabens prognostizieren.“ 8
Das BSH hat hierzu ein Regelwerk herausgegeben, dass den Antragstellern für den
grundsätzlich erforderlich gehaltenen Untersuchungsumfang der einzelnen Schutzgüter
vorgibt.
3.1.5 Entwicklung weltweit
Europa ist weltweit führend in der Entwicklung von OWAs. Die gesamte Energieerzeugungsleistung
von Windenergieanlage auf dem Meer liegt in Europa aktuell (stand
29.01.2013) bei 5000 MWh. Dabei entfällt 60% der Gesamtkapazität auf Großbritannien,
18% auf Dänemark, 8% auf Belgien und nur 6% auf Deutschland.
China betreibt zwei OWPs mit einer Gesamterzeugungsleistung von rund 252MWh.
Außerhalb von Europa sind ebenfalls mehrere OWPs anderer Länder geplant. Zum Beispiel
von den Ländern USA und Japan. 9
8 http://www.erneuerbare-energien-niedersachsen.de/rechtsrahmen/ aufgerufen am 17.01.2013
9 http://de.wikipedia.org/wiki/Offshore-Windpark abgerufen am 22.06.2013
22

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
3.2 HSE-Aspekte
Zu Beginn wird eine Begriffs Definitionen vorgestellt, die zum Verständnis dieser Ausarbeitung
notwendig ist. Des Weiteren wird oberflächlich darauf eingegangen, warum
Health, Savety and Environment (HSE) so wichtig ist und von welchem Hintergrund
dies entstanden ist.
3.2.1 Einleitung
HSE bedeutet übersetzt folgendes:
• Health – Gesundheitsschutz
• Safety - Arbeitssicherheit
• Environment – Umweltmanagement
3.2.2 HSE Richtlinien
International Finance corporation 1988 Richtlinien:
• Environmental (Energie- Wassererhaltung)
• Occupational Health and Safety (Physische-Biologische-Radiologische Gefahren)
• Community Health and Safety (Wasser Qualität und Verfügbarkeit)
• Construction and Decommissioning Umweltmanagement (Umwelt)
3.2.3 Standards des BSH
Das BSH steht für die Bundesamt für Seeschifffahrt und Hydrographie 10 Standard dient
der Rechts- und Planungssicherheit bei der Entwicklung, Konstruktion, Ausführung,
dem Betrieb und Rückbau von OWPs im Geltungsbereich der Seeanlagenverordnung.
• Teil A: Allgemeines
• Teil B: Nachweise und Genehmigungserfordernisse
• Teil C: Zeitliche Abfolge
10 www.bsh.de aufgerufen 12.06.2013
23

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
3.2.4 Wiederkehrende Prüfungen
Bei der Wiederkehrenden Prüfungen (WKP) ist die Gesamtanlage (Turbine und Tragstruktur)
eingehend zu überprüfen. Für die Überprüfung ist mittels der technischen
Unterlagen eine objekt- und standortspezifische Checkliste zu erstellen, die auch die Bewertungskriterien
enthält. Das Intervall für eine wiederkehrende Überprüfung einer WEA
ist zu definieren und festzulegen. Zu den WKPs werden jährlich Prüfungen an WEAs
verstanden, die an 25% aller Offshore-OWA eines OWPs durchzuführen sind. Nach vier
Jahren sollten alle OWAs inspiziert worden sein. Zentrale Bestandteile eines Windenergieparks,
wie die Umspannstation, sind jährlich zu inspizieren. Bei anderen singulären
Bauwerken kann von der jährlichen Inspektion abgewichen werden. Die Prüfung erfolgt
durch geeignete Sachverständige.
3.2.5 Bewertungskriterien für die wiederkehrenden Prüfungen
Die Bewertungskriterien der WKP sind als objekt- und standortbezogene Kriterien festzulegen.
Die Tabelle 1: Gegenstände der wiederkehrenden Prüfungen listet eine Aufstellung
dieser Kriterien auf.
3.2.6 Unterlagen der zu prüfenden Offshore-Windenergeiparks
Für die ”
Wiederkehrende Prüfung“ sind mindestens die folgenden Unterlagen einzusehen:
• Prüfberichte oder Zertifizierungsberichte mit allen Anhängen und Nachträgen
• Baugenehmigung
• Betriebserlaubnis
• Bedienungsanleitung
• Inbetriebnahmeprotokoll
• ausgefülltes Wartungspflichtenheft für die OWA einschließlich Tragstruktur und
Kolkschutz (Wartungsprotokolle)
• Berichte früherer ”
Wiederkehrender Prüfungen“ oder Zustandsbesichtigungen
• Nachweis der Ölqualität
• Dokumentation von Änderungen/Reparaturen an der Anlage und ggf. Genehmigungen
24

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
Baugruppe
Rotorblatt
Triebstrang
Maschinenhaus und kraftund
momentübertragende
Komponenten
Pneumatiksystem,
Hydrauliksystem
Tragestruktur (Gründung,
Konstruktion im Wasser,
Turm)
Bremssysteme und Messstellen,
Sicherheitseinrichtungen
Anlagensteuerung und E-
Technik inkl. Transformatorstation
und Schaltanlage
Unterlagen
Prüfgegenstand
Beschädigung der Oberfläche, Risse, Strukturunstetigkeiten
des Blattkörpers, [Inspektion von einer Hub- oder
Steigeinrichtung aus: Visuelle Begutachtung und Untersuchung
der Struktur mit geeigneten Verfahren (z. B.
Klopfen, Ultraschall)], Vorspannung der Schraubenverbindungen,
Beschädigung der Blitzschutzeinrichtungen
Dichtigkeit, ungewöhnliche Geräusche, Schmierzustand,
Korrosionsschutzzustand, Vorspannung der Schraubenverbindungen,
Zustand des Getriebes (ggf. Ölprobe)
Korrosion, Risse, ungewöhnliche Geräusche, Schmierzustand,
Vorspannung der Schraubenverbindungen
Beschädigung, Dichtigkeit, Korrosion, Funktion
Korrosion, Risse, Vorspannung der Schraubenverbindungen,
unzulässige Kolke, Lage
Funktionskontrollen, Beschädigung, Verschleiß, Einhalten
der Grenzwerte
Anschlüsse, Befestigung, Verschmutzung, Funktion, Korrosion
Vollständigkeit, Einhaltung der Auflagen, regelmäßige
Durchführung der Wartung, Ausführung, Prüfungsunterlagen,
ggf. Ausführung von Änderungen/Reparaturen
gemäß Genehmigung.
Tbl. 1: Gegenstände der wiederkehrenden Prüfungen (WKP) (Vgl. Bundesamt für Seeschifffahrt
und Hydrographie unter Mitwirkung von Prof. Dipl.-Ing. Horst Bellmer
et all, 2007, S. 32)
3.2.7 Risikoanalyse
Eine Risikoanalyse zur Ermittlung der Eintrittswahrscheinlichkeit einer Kollision eines
Schiffes mit einer WEA, einschließlich einer exemplarischen Betrachtung der Konsequenzen
eines etwaigen Schadstoffaustritts, ist im Rahmen der Basisuntersuchungen nach dem
25

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
Stand der Technik anzufertigen und vorzulegen.
In einer quantitative Risikoanalyse werden die Gefahren nach ihrer Eintrittswahrscheinlichkeit
und nach Ausmaß der Schäden bewertet, in diesem Fall kommt die sicherheitsanalytische
Methode, Risikoanalyse zum Einsatz.
3.2.7.1 Risikomatrix
Die Tabelle 2 Risikomatrix mit Risikoprioritätszahlen stellt eine Risikomatrix mit den
eingeräumten Risikoprioritätszahlen dar.
Katastrophal 4 5 6 7
Schwerwiegend 3 4 5 6
Beträchtlich 2 3 4 5
Unbedeutend 1 2 3 4
Konsequenz, Eintrittshäufigkeit äußerst selten selten gelegentlich häufig
Tbl. 2: Risikomatrix mit Risikoprioritätszahlen
3.2.8 Konsequenzen
Die ermittelten Gefahren sind den Eintrittswahrscheinlichkeit gegenübergestellt. Dabei
wurden diese anhand eine Risikomatrix erstellt, in der kategorisierte Eintrittswahrscheinlichkeit
den Konsequenz gegenübergestellt wurden. Die Entsprechung der Eintrittswahrscheinlichkeit
und der Konsequenzen sind in die Tabelle 3 Konsequenzen definiert.
3.2.9 Havariekommando des Bundes
Das Havariekommando ist eine gemeinsame Einrichtung des Bundes und der fünf Küstenländer,
um bei Unfällen im Bereich der Nord- und Ostsee ein koordiniertes und gemeinsames
Unfallmanagement zu gewährleisten. Das Havariekommando bündelt die Verantwortung
für die Planung, Vorbereitung, Übung und Durchführung von Maßnahmen zur
Verletztenversorgung, zur Schadstoffunfallbekämpfung, zur Brandbekämpfung, zur Hilfeleistung
und zur Gefahrenabwehr bezogenen Bergung bei komplexen Schadenslagen
auf See sowie einer strukturierten Öffentlichkeitsarbeit.
3.2.9.1 Organisationsstruktur des Havariekommando
Das Havariekommando ist ein Partner des Maritimen Sicherheitszentrums (MSZ), das
am 1. Januar 2007 die Arbeit aufgenommen hat. Leiter des Havariekommandos ist die
Stabsstelle Öffentlichkeitsarbeit, das Sekretariat und vier weitere Fachbereiche:
• Maritimes Lagezentrum
• Schiffs- und Schadenstoffunfallbekämpfung See
26

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
Qualitative
Unbedeutend
Offshore-
WEA/Schiff
Der fortlaufend Betrieb
von der Offshore-WEA
kann gewährleistet werden
(ggf. durch umfangreiche
Reparaturen)
Umwelt
Keine oder geringfügige
Umweltverschmutzung
Beträchtlich Offshore-WEA defekt Deutlich erhöhte Umweltverschmutzung:
Betriebsstoffe entweichen
aus Seitentanks
oder dem Doppelboden
ins Wasser (kein
Durchschlag der Doppelhülle
und des Doppelbodens)
Schwerwiegend Offshore-WEA zerstört Eine erhebliche Umweltverschmutzung:
Immense Ladetankbeschädigung/en;
Verlust der geladenen
Stoffe (Doppelhülle/-
boden durchschlagen)
Katastrophal
Ein Wartungsschiff ist
durch eine Gondel bzw.
durch ein oder mehrere
Teil/e einer Gondel
beschädigt
Schiff bricht auseinander/Schiff
sinkt
Sicherheit
keine Verletzten
wenige verletzte
übermäßig hohe
Anzahl an Verunglückten,
aber
in der Regel nur
Schwerverletzte
hohe Anzahl an
Toten und viele
Verletzte
Tbl. 3: Konsequenzen
• Schadenstoffunfallbekämpfung Küste
• Brandbekämpfung und Verletztenversorgung
Maritimes Lagezentrum
Das Maritime Lagezentrum (MTZ) ist im 24-Stunden Dienstbetrieb mit erfahrenen Nautikern
besetzt. Im Maritimen Lagezentrum wird ständig ein aktuelles, maritimes Lagebild
vom deutschen Hoheitsgebiet in Nord- und Ostsee erstellt, wobei auch Mitteilungen
der Nord- und Ostseeanrainerstaaten einfließen. Dabei werden alle Informationen über
Umstände, die für die Bekämpfung einer komplexen Schadenslage erheblich sein können,
gesammelt, aufbereitet, bewertet und gesteuert, erforderlichenfalls Alarmierungen aus-
27

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
gelöst und Sofortmaßnahmen eingeleitet.
In den Fachbereichen Schadstoffunfallbekämpfung See und Küste, Brandbekämpfung
und Verletztenversorgung werden die jeweils möglichen Teilaspekte einer Havarie konzeptionell
bearbeitet und für den Einsatzfall Taktiken und Vorgehensweisen erstellt. Die
Stabsstelle Presse- und Öffentlichkeitsarbeit ist für die Außendarstellung des Havariekommandos
und für die Koordinierung der Öffentlichkeitsarbeit während einer komplexen
Schadenslage zuständig.
Schadstoff- und Schiffsunfallbekämpfung auf See
Schiffs- und Schadstoffunfallbekämpfung See ist ein Fachbereich des Havariekommandos.
Dieses ist für alle internationalen Aufgaben im Zusammenarbeit mit der seeseitigen
Aufklärung und Bekämpfung von Meeresverschmutzungen zuständig und vertritt die
Bundesrepublik Deutschland in verschiedenen internationalen Fachgremien.
Diese entwickeln Strategien und Techniken für das Unfallmanagement auf See, koordinieren
inhaltlich Trainings, Übungen und Ausbildung für die Einsatzkräfte.
Schadstoffunfallbekämpfung an der Küste
Um Gefahren durch wassergefährdende Stoffe im niedersächsischen Küstengewässer und
in den Unterläufen von Elbe, Ems und Weser abzuwehren, sind an verschiedenen Standorten
Ölwehrstützpunkte eingerichtet, in denen Spezialgeräte für die Schadstoffunfallbekämpfung
an Stränden und Ufern stationiert sind (Vgl. Abbildung 13 Schadenstoffund
Schiffsunfallbekämpfung Küste). Hinzu kommen die stationierten Spezialschiffe mit
moderner Ausrüstung zur Schadstoffunfallbekämpfung entlang der niedersächsischen
Küste in mehreren Häfen.
28

3.2 HSE-Aspekte 3 GRUNDLAGEN DES PROJEKTES
Abb. 13: Schadenstoff- und Schiffsunfallbekämpfung Küste
29

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
3.3 Infrastruktur und Logistik
Dieser Schwerpunkt gliedert sich folgendermaßen: Einleitung in die Thematik mit Begriffsdefinition
als Überleitung zur Vertiefung. Des Weiteren wird das Thema motiviert.
Abschließend wird es inhaltlich zusammengefasst.
3.3.1 Einleitung
Zu Beginn wird eine Begriffsdefinition vorgestellt, die in diesem Zusammenhang für den
weiteren Verlauf der Ausarbeitung Gültigkeit behält. Diese stellen die Grundlage für den
fortlaufenden Prozess der Projektarbeit dar, um über den gleichen Sachverhalt sprechen
zu können und eine einheitliche Sprache zu erlangen.
3.3.1.1 Definition des Begriffes ”
Infrastruktur“
Es sind die wachstums-, integrations- und versorgungsnotwendigen Basisfunktionen für
weitere Ablaufprozesse. Dies beinhaltet ebenfalls die Gesamtheit aller Anlagen, Ausrüstungen
und Betriebsmittel, die für die Ausführung eines festgelegten Ablaufes unabdingbar
sind.
3.3.1.2 Definition des Begriffes ”
Logistik“
Der Begriff ”
Logistik“ wird mit vier Einflussfaktoren verbunden. Zum einen die Planung,
was sowohl die Entwicklung eines Prozesses umfasst als auch die Kenntnis verschiedener
Prozesse und Prozessketten, die für einen optimalen Ablauf nützlich sind.
Als nächstes wird die Koordination von den einzelnen Prozessen/Prozessketten erwähnt.
Eine durchdachte Planung gibt vor, wie ein oder mehrere Prozess/e aussehen
soll/en. Die Koordinierung ist jedoch komplex und mit Problemen behaftet und müssen
gegebenenfalls zeitnah angepasst werden.
Die Durchführung ist eine weitere Funktion der Logistik. Es ist der ausführende Aspekt
zur Umsetzung, der aus der Planung entstandenen Prozesse, die durch die Koordination
eingeleitet und delegiert wird.
Abschließend gilt, dass der/die Prozess/e überwacht werden. Dies wird mit der Kontrolle
der Güterflüsse erreicht, sodass nachvollziehbar bleibt, ob alles wie in Planung,
Koordinierung und Durchführung veranschlagt, erfolgt.
Die Abbildung 14 Logistik - Betroffene Bereiche der Logistik veranschaulicht, weshalb
die zuvor genannten Phasen wichtig sind.
Die Logistik beeinflusst viele Bereiche. Unter anderem sind davon die Häfen, Reedereien
und OWAs sowie die Betriebsmittel wie Versorgungsschiffe und Helikopter beeinträchtigt.
3.3.1.3 Motivation für die Thematik
Es ist ein relativ unbekanntes und neues Arbeitsumfeld, indem es kaum Vergleichsmodelle
gibt. Auch ist die Adaption von der Industrie nur schwer zu realisieren, da die gesamte
Prozesskette deutlich komplexer ist als bei herkömmlichen Prozessen. Aus diesem Grund
30

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
Abb. 14: Logistik - Betroffene Bereiche der Logistik (Gabler, 2013)
ist es erforderlich, dass neue Ideen herangezogen werden, innerhalb dessen der Prozesse
improvisiert werden muss und neuartige speziell auf dieses Anwendungsgebiet angepasste
Umfeld ausgerichtet wird. Mit der Zeit werden die Prozesse optimiert, wenn denn erst
einmal solide Vergleichsdaten vorliegen.
Dabei werden einem immer wieder folgende Fragestellungen begegnen: Wie kann die
Versorgung organisiert und garantiert werden? Inwieweit unterscheidet sich die klassische
Infrastruktur und Logistik zu OWPs? Welche Prozessketten sind zu organisieren?
3.3.2 Infrastruktur
Laut der oben aufgeführten Definition sind alle Basisfunktionen für die Durchführung eines
Prozesses wichtig. D.h. in diesem Fall, dass es mindestens einen Windenergiepark mit
zwei oder mehr OWAs geben muss. Häfen und Reedereien stellen die Ausrüstung und Betriebsmittel
zur Verfügung. Im Klartext bedeutet dies: Fehlt eines dieser Basisfunktionen
ist der Betriebsablauf gestört und die Infrastruktur nicht vollständig. Eine Basisfunktion
kann zum Beispiel beeinflusst sein, wenn der gewünschte Hafen nicht alle notwendigen
Funktionsbereiche erfüllen kann. Der Hafen kann bestimmte Schiffe nicht beladen, die für
den Transport von Großbauteilen wie dem Rotor vorhanden sein müssten. Der Hafen hat
weitere Funktionen, wie die Produktion von Komponenten und Ersatzteilen. Klassisch
ist auch die Zwischenlagerung von Teilen als auch Teilmontage.
In der nächsten Abbildung ist ein kurzer Auszug, der für OWPs geeigneten Häfen
aufgelistet.
Ist eine durchdachte Infrastruktur vorhanden, so können Prozesse optimiert werden.
Wenn nicht, dann muss erst einmal eine Infrastruktur geschaffen werden, die häufig aber
noch auf die Bedürfnisse einzelner Gruppen angepasst werden müssen, um effizient zu
sein bzw. werden zu können.
31

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
Abb. 15: Anlaufhäfen in Deutschland (dena, 2012)
3.3.3 Logistik
Die Logistik wird in drei funktionell unterschiedliche Teilaspekte unterteilt. Zum einen
wird die Intraparklogistik für beispielsweise Off- sowie Onshore Windenergieparks genannt.
Diese Teildisziplin befasst sich mit der Koordinierung innerhalb von Offshore-
Windenergieparks. Die Maritime Logistik sorgt für die Versorgung um und auf dem
Wasser für die Abwicklung der Prozesse. In der klassischen Logistik wird häufig von
Hinterland- bzw. Landlogistik gesprochen. Diese ist weniger komplex als die anderen Bereiche,
da es schon sehr viele Vergleichsmodelle gibt, weshalb dieser Teil vernachlässigt
werden kann.
3.3.3.1 Intraparklogistik
Die Teildisziplin der Logistik beinhaltet die Zuteilung von Ressourcen. Dabei ist die
Abhängigkeit zum Umfang, der zu erbringenden Leistung und den benötigten Bedarfsmaterialien,
entscheidend. Die Lagerung der Ressourcen wie Betriebsmittel und Humankapital
sollte entsprechend der Notwendigkeit erfolgen. Der Lagerungsort und die Größe
des benötigten Materials oder die jeweiligen Fachkräften beeinflussen weitreichend den
optimalen logistischen Aufwand. Muss beispielsweise ein Sensor für eine WEA schnell
ausgetauscht werden, um die Anlage weiter betreiben zu können, ist der Aufwand für
den Transport und Austausch im Verhältnis zum Transport und Austausch von einem
Rotor relativ gering, da der Transport schnell und unkompliziert durchgeführt werden
kann.
Die Intraparklogistik schneidet sich mit der “Maritimen Logistik“, da einige Bedingungen
sowohl zum einen Bereich zugeordnet werden können als auch zu dem anderen.
Als Besonderheit ist bei der Intraparklogistik die Übersteigemöglichkeit vom Transportmittel
auf die Windkraftanlage auf hoher See zu erwähnen.
Auf einer Windenergieanlage können ca. 10 bis 12 Fachkräfte tätig sein, wobei die jeweiligen
Tätigkeitsfelder von Wartungsort an der Anlage beeinträchtigt wird. Der Wartungsaufwand
von einer solchen Windenergieanlage können bis zu 2000 Stunden pro
32

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
(a) Passives Übersteigesystem
(b) Aktives Übersteigesystem
Abb. 16: Passives (a) und aktives (b) Übersteigesystem
Monat betragen. Um das ständige Übersteigen vom Wartungsschiff auf die Anlage und
zurück zu erleichtern, gibt es Übersteigesysteme. Entscheidend ist, dass die Sicherheit
für das Fachpersonal gewährleistet wird. Es gibt zwei verschiedene Übersteigesysteme.
Zum einen passive Systeme, die fest an der WEA installiert sind und zum anderen aktive
Übersteigesysteme, die vom Schiffstyp gesteuert werden. Die Abbildungen 16a und 16b
zeigen ein passives und ein aktives Übersteigesystem.
Weitere Aspekte, die beachtet werden müssen:
• Wetter
• Schiffstyp
• Geschultes Fachpersonal
• Strecke
• ...
Anmerkung: Das Fachpersonal muss immer geschützt werden. Laut den gesetzlichen
Regelungen in Deutschland muss der Arbeitgeber/Auftraggeber für die Sicherheit des
Personals sorgen.
3.3.3.2 Maritime Logistik
Alle Transportfahrten vom Hafen bis zum Windenergiepark werden unter dem Begriff
der ”
Maritime Logistik“. Die Entfernung vom Verladeort bis zum Empfängerort kann den
reibungslosen Betrieb erheblich beeinflussen. Dabei ist zu beachten, ob die Lagerung auf
Wartungsschiffen, dem Lagerungsort wie Insel bzw. Festland oder sonstige Möglichkeiten
die Verfügbarkeit erhöhen. Für die Transportfahrten vom Lagerort bis zum Empfängerort,
also zum Beispiel vom Hafen zu einem Offshore-Windenergiepark, müssen ebenfalls
die Seeverkehrsregelungen beachtet werden.
33

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
Abb. 17: Helgoland als Servicestützpunkt für Offshore-Windparks (dpa, 2012)
In der Regel werden Transporte häufig mit speziellen Schiffstypen durchgeführt. Jedoch
muss beachtet werden, dass die effektive Arbeitszeit je weiter entfernten Kilometer
mit einem Schiff exponentiell abnimmt. Helikopter sind hierbei eine gute Alternative.
Allerdings kann dieser nicht viel transportieren wie mit dem Schiff transportiert werden
kann. Aus diesem Grund macht der Einsatz beispielsweise bei Personaleinsätzen ohne
großen Ersatzteilbedarf Sinn, da diese schnell zum Zielort verfrachtet werden und weit
entferntere Strecken deutlich schneller überwinden können. Dadurch wird der Einsatz
eines Helikopters sehr schnell rentabel. Trotzdem birgt dieser ein höheres Unfallrisiko,
was aus HSE-Sicht eine größere Problematik darstellt.
Eine weitere Überlegung ist der Einsatz von kleineren Inseln, um eine kürzere Strecke
zurücklegen zu müssen. Hierbei ist zum Beispiel Helgoland ein Vorreiter. Jedoch muss
nach wie vor bedacht werden, dass Inseln auch nur ein begrenztes Volumen aufbringen
kann und auch die Hafeninfrastruktur vorliegen muss. Wenn dies nicht der Fall sein sollte,
dann muss notwendigerweise die Infrastruktur an die Bedürfnisse angepasst werden, was
Investitionen bedarf. Die Abbildung 17 zeigt eine Luftaufnahme der Insel Helgoland.
3.3.4 Zusammenfassung
Der logistische Aufwand zur sinnvollen Zusammensetzung von Wartungen/ Wartungsplänen
ist sehr komplex. Wie vorangegangen zu erkennen, teilt sich der Bereich Logistik
in drei Teildisziplinen auf. Die Intraparklogistik und Maritime Logistik sind hierbei entscheidend.
Während die Hinter-/Landlogistik den klassischen Part der Logistik vertritt.
An dieser Stelle gibt es schon viele Vergleichsmodelle, auf die zurückgegriffen werden
kann, weshalb dieser Aspekt weniger relevant ist.
34

3.3 Infrastruktur und Logistik 3 GRUNDLAGEN DES PROJEKTES
Abb. 18: On- und Offshore- Logistik (Prof. Dr.-Ing. Henning Albers u. Greiner, 2012)
Um sinnvoll logistisch Handeln, Prozesse entwickeln und optimieren zu können, muss
eine Infrastruktur vorliegen. Wenn dies nicht der Fall ist, muss dies direkt Hand in
Hand gehen. Noch sind die zu erwartenden Kosten nicht einschätzbar. Eins ist jedoch
gewiss: Es muss viel investiert werden, um kreativen Ideen und Lösungen zu finden. Die
abschließende Abbildung 18 zeigt noch einmal auf, welche Bereiche betroffen sind und
wo angesetzt werden muss.
35

3.4 Reederei 3 GRUNDLAGEN DES PROJEKTES
3.4 Reederei
In diesem Kapitel werden die Grundlagen zum Thema ”
Reederei “ in Hinsicht auf die
Wartung von Offshore-Windenergieparks vorgestellt. Zunächst wird die Definition des
Begriffs erläutert. Danach werden die Daten zum Schiffs- und Wartungsbedarf dargestellt
sowie die Schiffstypen kurz beschrieben, anschließend folgt die Zusammenfassung.
3.4.1 Einleitung
Für die Wirtschaftlichkeit von OWA sind zuverlässige Transportmittel entscheidend.
Neben regelmäßige Wartung bestehen auch zusätzliche Wartungseinsätze im Störfall.
Wegen die eingeschränkte Erreichbarkeit auf der See werden verschiedene Typen von
Schiffen sowie auch Spezialtechnik benötigt, die für die Gewährleistung der vollständigen
Wartung zur Verfügung stehen sollen. Die Bereitstellung von der damit verbundenen
Dienstleistungen ist durch die Reederei zu erfüllen.
3.4.2 Definition des Begriffs ”
Reederei“
Eine Reederei ist ein Transport- und Schifffahrtsunternehmen im Bereich der See- und
Binnenschifffahrt. Die Reederei beschäftigt sich in erster Linie mit der Ausrüstung, Bemannung,
Unterhaltung und dem Einsatz ihres Schiffes bzw. ihrer Schiffe. Diese zur
Bereederung gehörenden Aufgaben können auch an ein anderes Unternehmen, dem sog.
Vertragsreeder, abgegeben werden.
Neben der Bereederung kann sich die Reederei auch mit der Befrachtung beschäftigen.
Dies kann auch durch einen beauftragten Schiffsmakler erledigt werden. 11
3.4.3 Schiffs- und Wartungsbedarf
Das BSH schreibt ausdrücklich regelmäßige Sichtwartungen, also eine Wartung vor Ort,
vor. Bei den sogenannten WKP müssen jährlich mindestens 25 Prozent der Anlagen
eines Windenergieparks vor Ort gewartet werden, sodass nach spätestens 4 Jahren alle
Anlagen eines Windenergieparks auf Sicht inspiziert worden sind. Die Standards dienen
als Grundlage für die Zertifizierung von Offshore-Projekten durch externe Dienstleister. 12
Daher erfordert die Wartung von Offshore-Windenergieanlagen den kontinuierlichen
Einsatz von Wartungsschiffen, um eine entsprechende Wartung durchführen zu können,
was eine der wichtigsten Herausforderungen bei deren Betrieb darstellt.
Die Abbildung 19 Schiffsbedarf von OWP stellt den Schiffsbedarf von OWPs dar.
Nach den Erfahrungen des Betriebs von Alpha Ventus können die folgenden Punkte
zur Statistik bezüglich die Verfügbarkeit der Transportmittel genannt werden:
• Service-Schiffe können nur an rund 20 Prozent der Tage im Jahr ohne Gefahr nah
genug an die Windenergieanlagen heranfahren
11 http://de.wikipedia.org/wiki/Reederei, Reederei, abgerufen am 01.06.2013
12 http://www.offshore-windenergie.net/technik-2/wartung, Überblick über die Wartungsarbeiten im
Rahmen von Offshore-Windenergie-Projekten, abgerufen am 01.06.2013
36

3.4 Reederei 3 GRUNDLAGEN DES PROJEKTES
Abb. 19: Schiffsbedarf von OWP KPMG
• Helikoptertransport ist zusätzlich zum Schiffstransport an etwa rund 60 Prozent
der Tage im Jahr möglich
• An den restlichen rund 20 Prozent der Tage im Jahr ist kein Transport von Personal
und Ersatzmaterialien zu den OWA möglich
Das Basisszenario von KPMG bietet folgende Annahmen an, die eine Vorstellung über
den Umfang von benötigten Transportressourcen und Arbeitszeiten, die der Wartung
von OWP vermitteln können:
• Benötigte Wartungszeit pro Anlage und Jahr von 260 Stunden inklusive Sondereinsätzen
• Zugangsmöglichkeit über Crew Transfer Vessel (CTV)s 68 Prozent (Wellenhöhe,
sonstige Witterungsbedingungen)
• Besetzung der CTVs mit acht Monteuren
• Nettoarbeitszeit je Mitarbeiter acht Stunden am Tag
• Wartungseinsätze mittels CTVs werden nur bis zu einer Entfernung von maximal
60 Kilometern durchgeführt
• Bei über 60 Kilometer Küstenentfernung wird für jeweils 80 WEAs ein CTV
benötigt, um den Crew-Austausch vorzunehmen oder leichte Ersatzteillieferungen
zu gewährleisten
13
13 http://www.kpmg.de/docs/offshore wind copyright 230511.pdf, Offshore-Wind – Potenziale für die
deutsche Schiffbauindustrie, abgerufen am 01.06.2013
37

3.4 Reederei 3 GRUNDLAGEN DES PROJEKTES
3.4.4 Schiffstypen in der Betriebsphase
In diesem Abschnitt wird ein Überblick über verschiedene Schiffstypen gegeben, die in
der Betriebsphase von OWA benötigt werden.
3.4.4.1 Wartungs- und Serviceschiffe
Versorgungs- und Serviceschiffe für Wartungsarbeiten Offshore Service Vessels (OSV)
bzw. zur Personenbeförderung CTV müssen beim Andocken an die Windenergieanlagen
besonders ruhig im Wasser liegen. Bevorzugt werden Katamarane oder SWATH-Schiffe
(SWATH ).
3.4.4.2 Reparaturschiffe
Reparaturschiffe werden benötigt, um defekte Offshore-Komponenten auszutauschen.
Dazu werden kleinere Jack-up-Schiffe verwendet.
Der Bedarf bei diesen Schiffen ist vor allem davon abhängig, welche Betriebskonzepte
sich zukünftig durchsetzen werden. Wesentliche Parameter für die Entscheidung über
das Betriebskonzept sind die Küstenentfernung und die Anzahl von Windenergieanlagen
in einem OWP.
3.4.4.3 Wartungs-/Wohnschiffe
Küstennahe Offshore-Windenergieparks werden aufgrund der kurzen Fahrtzeiten über
eine Onshore-Basis versorgt. Die Versorgungseinsätze werden primär mit CTVs und nur
in Ausnahmefällen mit Helikoptern erfolgen. Bei größeren Küstenentfernungen gibt es
verschiedene Konzepte. Neben einer Offshore-Basis sind auch kombinierte On-/Offshore-
Varianten möglich. Die Konzepte variieren hinsichtlich des Helikopter und Schiffseinsatzes
deutlich. Die Offshore-Basis ist die Umspannplattform (oder eine separate Wohnplattform)
mit Rigid Inflatable Boat (RIB) und Helikopterplattform. Alternativ gibt es
auch Konzepte mit einem Reparaturschiff, das gleichzeitig als Unterkunft für die Monteure
dient.
Es verfügt entweder zusätzlich über ein Zugangssystem für die WEAs (zum Beispiel
Ampelmann) oder es werden für das Übersetzen zusätzliche CTVs/RIBs eingesetzt.
3.4.4.4 Crew Transfer Vessels
Bei küstennahen Windenergieparks werden Wartungseinsätze in wesentlichen Teilen
mit CTVs erfolgen. Bei Offshore-Windenergieparks mit größerer Entfernung erfolgt der
Einsatz dagegen vorwiegend zum Austausch der Mannschaft und für leichte Material-
/Ersatzteiltransporte.
3.4.4.5 Reparaturschiffe
Neben den Wartungsschiffen wird es auch einen Bedarf an Reparaturschiffen geben, die
für den Austausch von Komponenten benötigt werden (vor allem Gondeln, Rotorblätter).
38

3.4 Reederei 3 GRUNDLAGEN DES PROJEKTES
3.4.5 Zusammenfassung
Die Aufgaben der Reederei im Rahmen des Betriebs der Offshore-Windenergieparks ist
sehr wichtig und soll nicht unterschätzt werden. Daher ist die Auswahl von zuverlässiger
Reederei entscheidend für die effektive und effiziente Wartung der Offshore-Windenergieanlagen.
Die Reederei unterstützt die Betreiber der OWPs bei der Reparatur- und Wartungseinsätze
und gewährleistet einen robusten Betrieb und stetige Erreichbarkeit von
OWAs.
39

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
3.5 Wetterdaten
Dieses Kapitel beinhaltet eine Transkription des Vortrags ”
Wetterdaten für Offshore-
Windenergieparks“ im Rahmen der Projektgruppe SCOWS im Department für Informatik
an der Carl von Ossietzky Universität Oldenburg.
3.5.1 Definition des Begriffs ”
Wetter“
Laut Duden bezeichnet der Begriff den ”
Zustand der Atmosphäre zu einem bestimmten
Zeitpunkt an einem bestimmten Ort“. Weitgehende Synonyme hierzu seien ”
Witterung“
oder ”
Klima“ 14 . Da der Zustand der Atmosphäre der Kern der Definition ist, wird im
Folgenden von diesem Aspekt ausgegangen.
3.5.2 Einschränkung des betrachteten Gebietes
Bei der Betrachtung des Wetters in OWPs ist im Gegensatz zur vorigen Definition nicht
die gesamte Erdatmosphäre von Bedeutung, sondern lediglich ein relativ kleiner Bereich
hiervon, in dem die deutschen bzw. europäischen Offshore-Windenergieparks angesiedelt
sind. Wie in der nachstehenden abgebildeten Tabelle 20: Die deutschen Offshore-
Windenergieparks im Betrieb zu sehen, liegen die meisten OWPs zwischen dem 53. und
54. Längengrad und dem 5. und 12. Breitengrad 15 .
Zur Veranschaulichung der Ortsbestimmung auf der Erde seien hier noch nachstehend
zwei Abbildungen 21: Längen- und Breitengrade auf dem Erdball zum Längen- und
Breitengrad angebracht 16 .
Auf der folgenden Karte 22: Karte zur besseren geographischen Einordnung sind diese
Windenergieparks, die im Zentrum der Betrachtung stehen, einmal zusammen mit der
Universität Oldenburg eingezeichnet 17 .
Es werden nur für diese Punkte bzw. für deren Umkreise Wetterdaten benötigt, um
Aussagen über die Wartungseinsätze in den dort angesiedelten OWPs treffen zu können.
3.5.3 Erhebung von Wetterdaten
Es gibt zahlreiche Wetterstationen an unterschiedlichen Orten mit verschiedenen Datenmodellen.
Abgesehen von den lokalen Wetterstationen z.B. des Deutscher Wetterdienst
(DWD), welche überall auf dem Binnenland verteilt sind und ihre Daten für die Wettervorhersage
der nächsten drei Tage liefern, befinden sich auch andere Wetterdatenquellen
im Einsatz.
Wettersatelliten wie z.B. diejenigen aus der ”
Meteosat“-Familie (siehe Fußnote 18 ) liefern
hochauflösende Karten des aktuellen Wolkenaufkommens und lassen somit Schlüsse
auf die lokal vorherrschenden Hoch- und Tiefgebiete zu. Windenergieparkbetreiber wie
14 http://www.duden.de, Begriff Wetter“, abgerufen am 23.11.2012
”
15 http://en.wikipedia.org, diverse Begriffe, abgerufen am 23.11.2012
16 http://en.wikipedia.org, diverse Begriffe, abgerufen am 23.11.2012
17 http://maps.google.com, Ausschnitt aus Nordeuropa, abgerufen am 23.11.2012
18 http://www.eumetsat.int/Home/index.htm, abgerufen am 23.11.2012
40

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
Abb. 20: Die deutschen Offshore-Windenergieparks im Betrieb
Abb. 21: Längen- und Breitengrade auf dem Erdball
41

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
Abb. 22: Karte zur besseren geographischen Einordnung
die RWE messen zudem kontinuierlich mit auf dem Wasser treibenden Bojen zahlreiche
Werte, wie bspw. die aktuelle Windgeschwindigkeit und Sonneneinstrahlung (siehe
Fußnote 19 ).
Über die atmosphärischen Daten hinaus werden in OWPs auch noch hydrologische
Messdaten wie z.B. die aktuelle Strömungsrichtung und -geschwindigkeit erfasst. Die
dafür nötigen Messstationen werden beispielsweise wie die Modelle namens ”
Aquadopp“
des norwegischen Herstellers ”
Nortek AS“ auf dem Meeresboden versenkt (siehe Fußnote
20 ).
Auf der Abbildung 23: Messstationen werden im Meer versenkt ist die Ausbringung
solcher Messgeräte zu sehen. Insbesondere das Fraunhofer Institut für Windenergie und
Energiesystemtechnik (IWES) ist in diesem Gebiet der Messung aktiv (siehe Fußnote
21 ).
3.5.4 Notwendigkeit von Vorhersagen
Um die Notwendigkeit von Wettervorhersagen für Offshore-Windenergieparks zu verstehen,
sei die Situation einmal veranschaulicht. Der Windenergieparkbetreiber erfasst an
24 Stunden, 7 Tage die Woche kontinuierlich zahlreiche meteorologische und hydrologische
Messdaten. Gleichzeitig müssen die Offshore-Windenergieanlagen in regelmäßigen
Zeitabständen sowie bei Ausfall einzelner Teile gewartet werden. Ein Wartungseinsatz
muss aufgrund seiner Dauer, welche nicht nur die Fahrtzeit, sondern auch eventuelle
19 Die Pressemitteilung kann auf nachfolgender Internetquelle http://www.rwe.com/web/cms/de/
86182/rwe-innogy/presse-news/pressemitteilung/?pmid=4008380 eingesehen werden, abgerufen am
23.11.2012
20 http://www.nortekusa.com/en/products/CurrentMeter/aquadopp-3d-current-meter, abgerufen am
23.11.2012
21 Weitere Informationen http://www.iwes.fraunhofer.de/de/highlights20112012/highlights20102011
/seegangs- und stroemungsmessung.html, abgerufen am 23.11.2012
42

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
Abb. 23: Messstationen werden im Meer versenkt
Zeitverschiebungen aufgrund von plötzlich auftretenden Problemen umfasst, hinreichend
geplant werden.
Das Problem entsteht nun aus dem Umstand, dass die erhobenen Live-Offshore-
Wetterdaten ungeeignet für diese Einsatzplanung sind. So könnte bis zur Ankunft des
Wartungsschiffes zum Beispiel ein Sturm aufziehen, obwohl die momentan oder auch
gestrig gemessene Wetterlage dies nicht vermuten lässt. Die Lösung besteht in der Nutzung
eines Wettermodells, welches mit den gemessenen Daten ”
gefüttert“ wird und daraufhin
wissenschaftlich fundierte Wettervorhersagen liefert. Mit heutigen verlässlichen
Vorhersagen bis etwa 3 Tage vor dem Wartungseinsatz lässt sich dieser besser planen
und durchführen.
3.5.5 Klärung von WRF, NOAA und GFS
Die Komplexität eines solchen Wettermodells ist nicht zu unterschätzen. Schließlich spielen
in der Erdatmosphäre viele Faktoren zusammen, die in einem eigenen Fachgebiet
(nämlich der Meteorologie) erforscht werden. So wäre eine einfache lineare Extrapolation
viel zu simpel, um den Verlauf zum Beispiel einer Temperaturkurve zu prognostizieren.
43

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
3.5.5.1 WRF
Ein bereits existierendes Modell ist das amerikanische Weather Research and Forecasting
Model (WRF) (Weather Research & Forecasting Model), welches ein numerisches
Wettervorhersage-System darstellt. Es wurde entwickelt für die operationelle Vorhersage
und die Atmosphären-Forschung. Es kann sowohl mit realen Messdaten als auch
mit idealisierten Konfigurationen betrieben werden (siehe Fußnote 22 ) und basiert auf
einer breiten Gemeinschaft und Partnerschaft aus den folgenden Organisationen bzw.
Institutionen:
• National Center for Atmospheric Research (NCAR)
• National Oceanic and Atmospheric Administration (NOAA)
• National Centers for Environmental Prediction (NCEP)
• Forecast Systems Laboratory (FSL) & Naval Research Laboratory
• Air Force Weather Agency (AFWA)
• University of Oklahoma
• Federal Aviation Administration (FAA) indexFederal Aviation Administration
Das Projekt rund um das WRF gibt dies freie Software heraus, die einen Computer
mit x86-Prozessor von AMD oder Intel und das Betriebssystem Linux in 32- oder 64-
Bit voraussetzt. Datensätze lassen sich damit in Auflösungen von 10 ◦ , 5 ◦ , 2 ◦ oder 0.5 ◦
produzieren. Atmosphärische Bedingungen lassen sich sowohl für vergangene Zeiträume,
als auch für die Zukunft simulieren. Zudem lässt sich das Modell (da Open-Source) an
die eigenen Bedürfnisse anpassen (siehe Fußnote 23 ). So wird das WRF zum Beispiel von
der Firma METEOTEST aus der Schweiz eingesetzt, um dort lokal Wettervorhersagen
berechnen zu können (siehe Fußnote 24 ).
3.5.5.2 NOAA
Die NOAA ist die nationale Wetterforschungsbehörde der USA und wurde im Oktober
1970 in der Hauptstadt Washington, D.C gegründet. Diese Institution betreibt das
POES“-Projekt, welches 19 Wetterbeobachtungssatelliten umfasst, die schon seit vielen
”
Jahren produktiv und deren Bilder für private Zwecke und zu Lehr- und Forschungszwecken
freigegeben sind. Durch eine polare Umlaufbahn ist die Auflösung wesentlich besser
als zum Beispiel beim schon erwähnten europäischen Pendant Meteosat“, sodass die
”
höhere Auflösung zu einem zuverlässigen Vorhersage-Intervall von etwa 5 Tagen führt
(siehe Fußnote 25 ).
22 http://www.wrf-model.org/index.php, abgerufen am 23.11.2012
23 http://www.wrf-model.org/index.php, abgerufen am 23.11.2012
24 http://www.meteotest.ch/en/footernavi/climatology/wrf modeling/, abgerufen am 23.11.2012
25 http://www.noaa.gov/, abgerufen am 23.11.2012
44

3.5 Wetterdaten 3 GRUNDLAGEN DES PROJEKTES
3.5.5.3 GFS
Das Global Forecast System (GFS) ist das von der NOAA betriebene System für die
mittelfristige numerische Wettervorhersage und damit die Umsetzung des WRF-Modells.
Viermal am Tag werden für jeweils sechs Stunden-Blöcke alle Berechnungen des Modells
für den gesamten Globus durchgeführt. Die hierbei entstehenden Vorhersagen erstrecken
sich auf bis zu 16 Tage, wobei die Werte über einen Zeitraum von 7 Tagen hinaus als nicht
sehr akkurat angesehen werden. Das GFS stellt das einzige globale Model dar, dessen
gesamte Ergebnisse frei verfügbar, das heißt ”
Public Domain“, sind (siehe Fußnote 26 ).
26 http://www.emc.ncep.noaa.gov/index.php?branch=GFS, abgerufen am 23.11.2012
45

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
3.6 Navigationsaspekte
In diesem Kapitel werden die wichtigsten Fachbegriffe dargestellt sowie eine kurze Einführung
in die Seefahrt gegeben. Diese Aspekte sollten über das laufende Projekt bekannt
sein und Berücksichtigung finden.
3.6.1 Einleitung und Grundlagen
Breite [Latitude (Lat)]
• horizontale Schnitte
• Äquator Großkreis
• Nördliche/Südliche Hemisphäre
• 180 ◦ gesamt
• 90 ◦ Nord / 90 ◦ Süd
Länge [Longitude (Long)]
• Vertikale Schnitte
• 360 ◦ gesamt
• 180 ◦ West /180 ◦ Ost
3.6.2 Navigationshilfen
Sortiert nach Entdeckung bzw. Einführung
• Schallsignal
• Kompass
• Seezeichen
• Logge
• Fernrohr
• Seekarte
• Schiffsuhr
• Morsecode
• Sextant
• Lotse
46

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
• Funk
• Echolot
• Radar
• Automatic Identification System (AIS)
• Global Positioning System (GPS)
• Long range identification and tracking (LRIT)
• Verkehrszentrale (VKZ)
3.6.3 Navigationshilfe Beispiel
Abb. 24: Navigationshilfe mittels Echolot
3.6.4 Rechtsgebiete
Hohe See
• internationales Recht
• Teilweise rechtsfreier Raum
Ausschließlichen Wirtschaftszone (AWZ)
• Deutsches Recht stark eingeschränkt anwendbar
47

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
Anschlusszone
• Deutsches Recht eingeschränkt anwendbar
Küstenmeer(Hoheitsgewässer)
• Deutsches Recht uneingeschränkt anwendbar
Festland
• Deutsches Recht uneingeschränkt anwendbar
Die Abbildung 25: Rechtsgebiete stellt die Seezonen dar. Hieran wird verdeutlicht, wo
welches Recht gilt. In der Abbildung 26: Ausschließlichen Wirtschaftszone ist ersichtlich,
dass...?
Abb. 25: Rechtsgebiet
3.6.5 Organisationen
• Deutsches Recht uneingeschränkt anwendbar
• International Maritime Organization (IMO)
• International Association of Marine Aids to Navigation and Lighthouse Authorities
(IALA)
• International Labour Organization (ILO)
48

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
Abb. 26: Ausschließlichen Wirtschaftszone (AWZ)
• Bundesamt für Seeschifffahrt und Hydrographie (BSH)
• Wasser- und Schifffahrtsverwaltung des Bundes (WSV)
• Wasser- und Schifffahrtsdirektionen (WSD)
• Wasser- und Schifffahrtsämter (WSA)
• Verkehrszentrale (VKZ)
3.6.6 Regeln und Gesetze
• Convention on the International Regulations for Preventing Collisions at Sea (CO-
IREGs)
• International Convention for the Safety of Life at Sea (SOLAS)
• UN Conventions on the Law of the Sea (UNCLOS)
• Seeschifffahrtsstraßen-Ordnung (SeeSchStrO)
• Schifffahrtsordnung Emsmündung (EmsSchO)
• Binnenschifffahrtsstraßen-Ordnung (BinSchStrO)
• Seeaufgabengesetz (SeeAufgG)
• Schiffsausrüstungsrichtlinie (Richtlinie 95/98/EG)
49

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
3.6.7 Automatic Identification System
• übermittelt Positions-, Schiffs- und Routendaten an Landstationen und andere
Schiffe
• Ist kein Radar-Verfahren
• Nachrichtentypen
– Positionsmeldung
– Schiffs- und Reisedaten
– Sicherheitsmeldungen (adressiert/an alle)
– AtoN-Positionsmeldung (Aids to Navigation)
• Statische Schiffsdaten
– IMO-Nummer
– Schiffsname
– MMSI/Rufname
• Dynamische Schiffsdaten
– Nav-Status
– Position(WGS 84) inklusive Zeit
– COG/SOG/HDG/Rot
• Reisedaten
– Aktueller statischer Tiefgang in dm
• Wartung von mögliche Kollisionen
3.6.8 Elektronische Seekarte
Electronic Chart Display and Information System (ECDIS)
Es reichert die Darstellung einer elektronische Seekarte [Electronic Navigational Chart
(ENC)] mit weiteren Informationen an, zum Beispiel mit Daten vom GPS, Radar,
Funk und Echolot. Objekte, wie andere Schiffe, können auf der Karte mit zusätzlichen
AIS-Informationen versehen werden. Eine Identifizierung und damit Einschätzung einer
möglichen Gefahr ist somit für den Schiffsführer wesentlich einfacher.
Die Karten liegen grundsätzlich immer in einem Vektorformat vor. Dies bedingt eine
entsprechende Rechengeschwindigkeit seitens der Hardware, um im Fall eines schnellen
Zooms die Darstellung unverzüglich zu gewährleisten. Bei den Formaten ist eines
vorgeschrieben und ein anderes üblich:
50

3.6 Navigationsaspekte 3 GRUNDLAGEN DES PROJEKTES
• System-ENC (SENC) - als internes binäres Format
• Format S-57-als genormtes Austauschformat
Die Daten einer elektronischen Seekarte werden sehr oft aktualisiert, dies bedingt, dass
wöchentlich neue Updates eingespielt werden müssen. Über die Aktualisierung ist ein
Nachweis zu führen. Sind mindestens zwei ECDIS Geräte an Bord, entfällt die Pflicht
zur Mitführung von Papierkarten. Dies gilt sowohl für die Berufs- als auch für die Sportschifffahrt.
51

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
3.7 Entwurfsmethoden
In diesem Kapitel werden die Grundlagen von ”
Scrum“ beschrieben und erläutert. Es
wird vorgestellt, wie ”
Scrum“ im Rahmen eines Projekts als Vorgehensmodell benutzt
werden kann. Zunächst wird es eine Definition des Begriffs gegeben. Weiter folgt die
Beschreibung der wichtigsten Bestandteile von Scrum. Anschließend wird das Thema
zusammengefasst.
3.7.1 Einleitung
” Entwurfsmethoden“ ist falsch. ” Scrum“ oder Entwicklungsmethode“ wäre richtig.
”
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
Es stehen neben technischen Probleme auch soziale Probleme und Fragestellungen im
Fokus.
Abb. 27: Scrum-Tag-Cloud
52

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
3.7.2 Definition des Begriffs ”
Scrum“
Scrum ist ein agiles Projektmanagement-Framework, das aus wenigen, dafür aber klar
definierten und einzuhaltenden Regeln besteht. Es ist ein empirischer, iterativer und
inkrementeller Ansatz. Entwicklungsphasen werden als ”
Sprint“ bezeichnet.
Abb. 28: Srum im Überblick
3.7.3 Bestandteile von Scrum
Im Scrum-Prozess gibt es für die teilnehmenden Personen unterschiedliche Rollen: Scrum
Master, Product Owner und das Entwicklungsteam. Zudem wird in verschiedene Teamtreffen
unterscheiden: Daily Scrum, Sprint Planung, Sprint Review und Sprint Retrospective.
Daneben wird zwischen den (wichtigsten) Artefakten Product Backlog, Sprint
Backlog und Burndown Chart unterschieden.
3.7.3.1 Rollen
Der Product Owner repräsentiert intern die Bedürfnisse des Kunden und ist somit für
das zu entwickelnde Produkt hauptverantwortlich. Er ist zudem verantwortlich für die
im Product Backlog festgehaltenen Anforderungen. Er ist für User, Kunden und Management
der Ansprechpartner, zudem kann er Produktfeatures formulieren und priorisieren.
Außerdem nimmt dieser die Ergebnisse nach jedem Sprint ab. Er ist jedoch kein ”
Chef“
oder Moderator.
Der Scrum Master ist für die Einhaltung des Scrum-Prozesses verantwortlich. Er
behebt Ereignisse, die den Scrum-Prozess behindern und hinterfragt den Scrum-Prozess,
um Optimierungen vornehmen zu können. Er benötigt ausgeprägte Soft Skills, da er als
53

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
Motivator des Teams auftritt, er ist jedoch kein Projektmanager.
Das Entwicklungsteam ist eine selbstorganisierte, räumlich nicht getrennte, 5-9-
köpfige Gruppe von Entwicklern, die das Produkt implementiert. Ein ständiger Informationsaustausch
findet via ”
Daily Scrum“ statt.
3.7.3.2 Treffen
Das Daily Scrum ist eine tägliche Besprechung aller Teammitglieder. Sie wird unter
den Leitfragen geführt:
• Was habe ich seit dem letzten Meeting geschafft?
• Was will ich bis zum nächsten Meeting schaffen?
• Welche Hindernisse sind hierbei in meinem Weg?
In diesem Treffen werden die Tasks an Gruppenmitglieder verteilt und mögliche Hindernisse
schriftlich festgehalten.
Das Sprint Planning besteht auf 2 Phasen: Sprint Definition und anschließender
Planung.
1. Sprint-Definition
• Analyse und Auswertung des Product Backlog
• Sprint-Ziel festlegen
2. Sprint-Planung
• Festlegen, wie das Sprint-Ziel erreicht werden kann
• Sprint Backlog (Tasks) aus Product Backlog (User Stories) erstellen
• Sprint Backlog in Stunden abschätzen (Bildet die Grundlage für das Burndown-Chart)
Das Sprint Review beginnt mit einer Präsentation der Ergebnisse des vorangegangenen
Sprints. Der Product Owner bewertet anschließend den Fortschritt des Produkts, jedoch
haben alle Teammitglieder das Recht, ihre Meinung zu äußern. Die Leistungen sollen
kritisch hinterfragt werden, um Verbesserungen erzielen zu können. Erkenntnisse dieser
Diskussionen gehen jeweils in die Planungen der folgenden Sprints ein.
Die Sprint Retrospective findet i.d.R. im Anschluss an das Sprint Review statt. Es
dient zur Reflektion des vorangegangenen Sprints. Positive und negative Vorkommnisse
werden angesprochen und diskutiert: Was war gut? Was war schlecht? Wie war die
Zuteilung der Tasks? usw. Die Leitung dieser Sitzung übernimmt naturgemäß der Scrum
Master. Für die Retrospective gibt es definierte Vorgehensmodelle, wie beispielsweise
Sechs Schritte der Retrospective“, jedoch bleibt es dem Team überlassen, wie dabei
”
vorgegangen wird.
54

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
Abb. 29: Burndown Chart
3.7.3.3 Artefakte
Im Folgenden sind nur die wichtigsten Artefakte aufgeführt.
Im Product Backlog werden alle User Stories (Software-Anforderungen) schriftlich
festgehalten. Die Anforderungen werden nach ihrem Geschäftswert gelistet, wobei diese
Priorisierung die Aufgabe des Product Owners ist. Die wichtigsten Kriterien hierbei sind:
Mehrwert, Risiko und Kosten. Das Dokument ist dynamisch und kann nach jedem Sprint
verändert oder aktualisiert werden.
Im Sprint Backlog werden alle für den aktuellen Sprint relevanten User Stories
schriftlich festgehalten und mit nicht-funktionalen Anforderungen versehen. Die User
Stories werden weiterhin in Arbeitspakete zerschnitten und als ”
Tickets“ in die Projektmanagement-Software
eingepflegt. Jeder Entwickler kann sich anschließend die zu bearbeitenden
Tickets selbst auswählen.
Der Burndown Chart ist ein Diagramm, das das Verhältnis von zu absolvierenden
Arbeitsstunden mit geleisteten Arbeitsstunden unter Berücksichtigung des Projektfortschritts
abbildet.
3.7.4 Zusammenfassung
Zusammengefasst kann gesagt werden, dass Scrum ein Vorgehensmodell für komplexe
Projekte ist. Scrum beinhaltet einfache Regeln und steuert den Ablauf des Projekts.
Dazu dienen die Sprints, in denen die abgestimmten Ziele umgesetzt werden. Scrum
hilft bei der Planung des Projekts, wobei die Entwicklungslinien und Anforderungen
55

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
Abb. 30: Scrum in Detail
56

3.7 Entwurfsmethoden 3 GRUNDLAGEN DES PROJEKTES
immer angepasst werden können.
57

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
3.8 Simulationstechnik
Die Grundlagen der Simulationstechnik werden in diesem Abschnitt veranschaulicht.
Aufgeteilt in einen einleitenden Text. Darauffolgend werden die Fragen beantwortet ”
Was
ist Simulation?“, ”
Warum keine analytischen Verfahren?“ und ”
Welche Simulationsmodelle
gibt es?“. Danach wird erläutert, was es mit Multiagentensystemen auf sich hat.
Des Weiteren werden die typischen Stolperfallen bei Simulationsstudien erwähnt.
3.8.1 Einleitung
Die Seminararbeit hat den Schwerpunkt Simulation und deren Technik. Die Literatur von
Page u. Kreutzer (2005) wird als Grundlage herangezogen. Die Informationen stammen,
wenn nicht anders angegeben, aus dem Buch ”
The Java Simulation Handbook“.
3.8.2 Was ist Simulation?
Je nach Kontext sind unterschiedliche Definitionen des Begriffs Simulation sinnvoll. Die
folgende Definition bezieht sich auf Computersimulationen, bei denen der Parameter
Zeit eine wichtige Rolle spielt.
[...], we define simulation as the modelling of dynamic processes in real
”
systems, based on real data, and seeking predictions for a real system’s behaviour
by tracing a system’s changes of state over time (starting from some
initial state).“
Simulation ist also eine Art des Modellierens: Ein reelles System wird abstrahiert, idealisiert
und auf ein Simulationsmodell abgebildet. Dieses stellt eine Repräsentation des Systems
dar. Aus dem Verhalten des Simulationsmodells kann ein Beobachter Rückschlüsse
auf das Verhalten des reellen System ziehen (siehe Abbildung 31 System, Modell und
Anwendung).
3.8.3 Warum keine analytischen Verfahren?
Analytische Verfahren basieren auf einer Menge von Gleichungen, für die geschlossene
Lösungen 27 gefunden werden können. Beispiele sind:
• Analytische Warteschlangenmodelle 28
• Optimierungsmodelle 29 für die Maximierung/Minimierung von Zielfunktionen unter
bestimmten Rand- und Nebenbedingungen
27 http://www.wachtler.de/informatik 2/node27.html, abgerufen am 20.12.2012
28 Weiterführendes Dokument mit hilfreichen Informationen über diese Thematik ist unter der Adresse
http://www.ivh.uni-hannover.de/optiv/Methoden/WarteMet/WarteMet.pdf einsehbar, abgerufen
am 17.12.2012
29 PDF-Dokument abrufbar unter http://www.diss.fu-berlin.de/diss/servlets/MCRFileNodeServlet
/FUDISS derivate 000000003169/03 Kap3.pdf, abgerufen am 19.12.2012
58

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Dagegen berechnen Simulationen schrittweise die Werte von Zustandsvariablen in einem
Zustandsraum. Dabei kann nicht garantiert werden, dass eine optimale Lösung gefunden
wird. Simulationen sollen daher nur dann benutzt werden, wenn mathematische Modelle
nicht alle relevanten Aspekte eines komplexen Systems erfassen können. Dafür brauchen
Simulationen nicht auf Linearitätsannahmen, linearen Abhängigkeiten und Verteilungen
basieren, aber können komplexe Interaktionsmuster erfassen und dabei helfen, Modelle
in unterschiedlichen Detaillierungsgraden zu untersuchen.
Page u. Kreutzer (2005) bringen es wie folgt auf den Punkt: ”
Whenever a problem’s
solution require a model too complex for mathematical optimization, simulation should
be the tool of choice.“
3.8.4 Welche Simulationsmodelle gibt es?
In diesem Abschnitt werden verschiedene Arten von Simulationsmodellen unterschieden.
In dynamischen Modellen spielt, im Gegensatz zu statischen Modellen, die Zeit als dynamische
Größe eine wichtige Rolle. Beispielsweise sind Modelle von Baukonstruktionen
in der Regel statisch. Logistikprozesse können dagegen dynamisch modelliert werden.
Dynamische Modelle können kontinuierlich oder diskret sein.
Bei der Simulation von kontinuierlichen Modellen verändern sich die Werte der Zustandsvariablen
stetig mit der Zeit. Kontinuierliche Modelle enthalten Differentialgleichungen,
welche mittels numerischer Integration gelöst werden können. Regelkreise und
biologische Prozesse, wie die Räuber-Beute-Beziehung 30 können so simuliert werden.
Bei diskreten Modellen ändern sich während einer Simulation die Werte der Zustandsvariablen
zu bestimmten Zeitpunkten. Es wird von zeitgesteuerter Simulation gesprochen,
wenn die Werte der Variablen in regelmäßigen Zeitabständen neu berechnet werden.
Es ist dann von ereignisgesteuerter Simulation die Rede, wenn die Werte nur dann
neu berechnet werden, wenn gewisse Ereignisse in der Simulation auftreten.
Als Mischform können hybride Modelle sowohl kontinuierliche, als auch diskrete Modellbestandteile
enthalten.
Schließlich werden stochastische und deterministische Modelle unterschieden. Erstere
nutzen Zufallszahlen, die auf Wahrscheinlichkeitsverteilungen basieren. Diese Verteilungen
können ausgehend von existierenden Messdatenreihen durch statistische Analyse
ermittelt werden. Mit so ermittelten Wahrscheinlichkeitsverteilungen können realistische
Folgen von Zufallszahlen erzeugt werden, sodass mit einem stochastischen Modell
zufälliges, aber dennoch realistisches Verhalten simuliert werden kann.
3.8.5 Mutliagentensysteme
Nach Page u. Kreutzer (2005) sind Multiagentensysteme (MAS) Systeme, welche zielorientiert
und interagierende autonome Entitäten (Agenten) in einer gemeinsamen Umgebung
aggregieren. Das Systemverhalten wird durch die dezentralen Entscheidungen
und Interaktionen der Agenten bestimmt. MAS können genutzt werden, um in einer
30 http://www.leinweb.com/snackbar/wator/, abgerufen am 19.12.2012
59

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Umgebung emergente Phänomene zu untersuchen, die ihre Ursache in dezentralen Entscheidungen
haben. MAS unterscheiden sich in:
• der Anzahl an Agenten,
• der Art der Kommunikation zwischen den Agenten,
• der Heterogenität der Agenten (komplexe oder einfache Agenten),
• den Interaktionsmustern und
• der Kompexität der Umgebung.
3.8.5.1 Agenteneigenschaften und -architekturen
Agentensysteme kommen in unterschiedlichen wissenschaftlichen Disziplinen vor, z. B.
in Wirtschaft, Soziologie und Informatik. Eine eindeutige Definition des Begriffs ”
Agent“
gibt es bisher nicht. Trotzdem sind folgende Eigenschaften typisch für Agenten:
• autonom: Ein Agent kann Aufgaben in seiner Umgebung selbstständig ausführen
• situiert: Ein Agent befindet sich in einer Umgebung, die er wahrnehmen und in
der er agieren kann.
• reaktiv: Ein Agent kann auf Umgebungsänderungen innerhalb eines angemessenen
Zeitraums erwidern.
• zielorientiert: Ein Agent kann Ziele verfolgen und seine Umgebung proaktiv entsprechend
verändern sowie Pläne ausführen.
• sozial: Um seine Ziele erreichen kann ein Agent mit anderen Agenten kooperieren
oder konkurrieren.
• adaptiv: Ein Agent kann lernen und sein Verhalten anpassen, wenn ein an den Tag
gelegtes Verhalten nicht zielführend war.
• mobil: Ein Agent kann seine Position innerhalb seiner Umgebung verändern.
Während fast jeder Agent die ersten drei Eigenschaften besitzt, sind die anderen Eigenschaften
häufig nicht alle gleichzeitig in einem Agent implementiert. So kann es stationäre
Agenten geben, die sich nicht in der Umgebung bewegen und somit nicht mobil sind oder
nicht-adaptive Agenten, die ihr Verhalten nicht verändern können.
Im Allgemeinen besteht ein Agent aus:
• Sensoren, um seine Umgebung wahrzunehmen
• Aktoren, um seine Umgebung zu verändern
• Fähigkeiten, um Informationen zu verarbeiten und Entscheidungen zu treffen.
Agenten können unterschiedlich klassifiziert werden. Im Folgenden werden drei verschiedene
Agentenklassen beschrieben.
60

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Subsymbolische Agenten
Das Verhalten subsymbolischer Agenten wird nicht durch mathematische Operationen
oder Kalküle bestimmt, sondern konnektionistische z. B. durch neuronale Netze. Ein
Agent kann aus mehreren künstlichen Neuronen bestehen, welche in mehreren Schichten
angeordnet werden können (siehe Abbildung 34). Über die Sensoren erhält die erste
Neuronen-Schicht Eingabewerte. Jedes einzelne Neuron gewichtet seine erhaltenen Eingaben
und ”
feuert“ gegebenenfalls, d. h. überträgt Informationen zu benachbarten Neuronen.
Die letzte Neuronen-Schicht steuert die Aktoren des Agenten. Das Verhalten des
Agenten wird durch die Verbindungen der Neuronen und seine interne Gewichtung bestimmt.
Falls das Verhalten des Agenten nicht zum gewünschten Effekt führt, kann er die
interne Gewichtung der Eingabewerte anpassen und damit sein zukünftiges Verhalten
verändern: Der Agent ist also lernfähig.
Subkognitive Agenten (auch: Reaktive Agenten)
Subkognitive Agenten enthalten pro Verhaltensmuster, das sie beherrschen, ein Modul,
indem das Verhaltensmuster implementiert ist. Je nachdem welche Umgebungswerte
durch die Sensoren geliefert werden, werden unterschiedliche Verhalten im Agenten aktiviert.
Die Auswahl kann anhand hinterlegter Prioritäten erfolgen. Der selbstständige
Minenroboter (siehe Abbildung 35 Minenroboter als reaktiver Agent) hat beispielsweise
sechs Verhalten: erkunden, kartieren, fördern, Route optimieren, auftanken und Kollision
vermeiden. Die Verhalten, welche die Funktionstüchtigkeit des Roboters erhalten,
wie Kollision vermeiden und auftanken, haben eine höhere Priorität als das zielorientierte
Fördern von Erzen oder das Suche neuer Lagerstätten. Wenn der Agent also über
einen Sensor feststellt, dass der Treibstoff-Füllstand gering ist, wird er sich zur nächsten
Tankstelle bewegen, anstatt weiteres Erz zu fördern.
Abwägende Architekturen
Diese Agentenarchitektur berücksichtigt mentale Konzepte. Ein Beispiel ist der BDI-
Agent (BDI: beliefs, desires, intentions), dessen Zustand von Komponenten bestimmt
wird.
• Annahmen des Agenten über sich selbst und seine Umgebung (engl. beliefs)
• Wissen über seine Zielzustände, wobei es zu Zielkonflikten kommen kann (engl.
desires)
• Absicht, bzw. eine Menge an Zielen, die sich nicht widersprechen (engl. intentions)
Mittels der Sensoren aktualisiert der Agent regelmäßig seine Annahmen über die Umgebung.
Aus diesen Informationen und seinen bisherigen Absichten kann der Agent alle
möglichen Zielzustände ableiten, die er anstreben kann. Aus dieser Menge an Zielen,
die hierarchisch in Teilziele verfeinert werden können, kann der Agent dann Ziele herausfiltern,
die sich nicht widersprechen. Zu jedem ausgewählten Ziel (Absicht) besitzt
61

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
der Agent einen Ausführungsplan. Der Agent kann einen solchen Plan ausführen und
verbessern oder ihn abbrechen, falls das Ziel nicht mehr verfolgt werden soll.
3.8.5.2 Multi-Agent Based Simulation
Bei der auf MAS basierten Simulation werden sogenannte emergente Phänomene untersucht,
die in Systemen mit vielen Agenten auftreten können. Zu solchen Phänomenen
gehört zum Beispiel neuartiges, unvorhergesehenes Verhalten des Gesamtsystems.
Multi-Agent Based Simulation (MABS) sind diskrete Simulationen, sie können also
entweder zeitgesteuert oder ereignisgesteuert sein. Für Modelle mit wenigen komplexen
Agenten eignet sich die eventgetriebene Variante besser, für Modelle mit vielen gleichartigen
Agenten, bei denen der Zustand jedes Agenten in jedem Simulationsschritt neu
berechnet wird, ist eine zeitgesteuerte Simulation meistens die bessere Wahl.
Die Kommunikation zwischen den Agenten kann entweder direkt erfolgen, indem ein
Agent einem anderen eine Nachricht schickt, oder indem ein Agent Veränderungen an der
Umwelt vornimmt, die ein anderer Agent daraufhin mittels seiner Sensoren wahrnimmt.
Zur Standardisierung von Agentkommunikation wurde das Standardisierungsgremium
Foundation for Intelligent Physical Agents (FIPA) eingerichtet, welches unter anderem
eine Standardsprache für Agenten (Agent Communication Language (ACL)) definiert
hat.
Die Simulationsumgebung kann entweder nur aus Agenten bestehen oder auch passive
Komponenten enthalten. Diese Komponenten können zwar selbst auch als ”
Umgebungsagenten“
modelliert werden, was jedoch laut Page & Kreuzner nicht zu eleganten
Lösungen führt. Sie empfehlen klare Schnittstellen zwischen Agenten und Umgebungskomponenten.
Wichtige Vor- und Nachteile von MABS
Vorteile:
• Ein intuitives Modellieren wird ermöglicht, da die Agenteneigenschaften relativ einfach
auf viele autonome Bestandteile der echten Welt übertragen werden können.
• Erweiterung der objektorientierten Simulation um KI-Methoden, wie lernen und
planen
Nachteile:
• Es ist schwierig das beste Abstraktionslevel für das Agentendesign zu finden. Systeme
mit komplexen Agenten sind schwer zu validieren. Systeme mit einfachen
Agenten können zu abstrakt für nützliche Ergebnisse sein.
• Es werden viele ”
echte“ Daten zur Konstruktion valider Agenten benötigt. Andere
Simulationstypen als die MABS benötigen auch Daten zur Validierung, jedoch nur
auf der Makroebene des Gesamtsystems.
62

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Schließlich noch zwei MABS, welche die vorgestellten Konzepte veranschaulichen:
• Field Service Agent based Model 31
• The Three Modeling Methods 32
3.8.6 System Dynamics
Auf diese Methodik wird hier nicht genauer eingegangen. Der Vollständigkeit halber
darf System Dynamics jedoch in der Dokumentation zu Simulationstechnik nicht fehlen.
Daher hier ein Link zum Gabeler Wirtschaftslexikon 33 , das einen guten Überblick über
diese Methodik liefert.
3.8.7 Welche Simulationsphasen gibt es?
Die Abbildung 38 stellt die Phasen des Simulierungsmodellierungszyklus dar.
3.8.8 Vorgehen zur Werkzeugauswahl
Die Kriteriengruppe zur Auswahl von Simulationssoftware wird in der Abbildung 39
Kriteriengruppen zur Auswahl von Simuations-Software verdeutlicht.
3.8.9 Werkzeuge (Auswahl)
Die Tabelle 4 Simulationstechniken: Werkzeuge (Auswahl) zeigt eine kleine Auswahl an
Werkzeugen.
Diskrete Simulation MABS System Dynamics
Plant Simulation AnyLogic AnyLogic
DESMO-J Insightmaker Insightmaker
Tortuga
Mason
PlaSMA
Repast
MASS
usw.
Tbl. 4: Simulationstechniken: Werkzeuge (Auswahl)
31 http://www.runthemodel.com/models/run.php?popup=1&id=719, abgerufen am 20.12.2012
32 http://www.runthemodel.com/models/347/?ID=347, abgerufen am 20.12.2012
33 http://wirtschaftslexikon.gabler.de/Definition/system-dynamics.html, abgerufen am 19.12.2012
63

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
3.8.10 Stolperfallen bei Simulationsstudien
• Bedürfnisse/Anforderungen der Nutzer ignoriert
• Kommunikation zw. Simulations- und Domainexperten ist mangelhaft
• Simulationsziel und -umfang bei der Modellierung vernachlässigt
• Allmähliche Zielabweichung nicht bemerkt
• Schlechte Qualität vorliegender echter“ Daten
”
• Zu hohe Modellkomplexität? Probleme bei Implementierung und Datensammlung
64

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 31: System, Modell und Anwendung (Page u. Kreutzer, 2005)
Abb. 32: Modellklassifikation nach Werten der Zustandsvariablen (Page u. Kreutzer,
2005)
65

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 33: Grundlegende Agentenarchitektur (Page u. Kreutzer, 2005)
Abb. 34: Mehrschichtiges neuronales Netz zur Agentenkontrolle (Page u. Kreutzer, 2005)
66

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 35: Minenroboter als reaktiver Agent (Page u. Kreutzer, 2005)
67

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 36: Schema eines BDI-Agenten (Page u. Kreutzer, 2005)
68

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 37: Komponenten multiagentenbasierter Modelle (Page u. Kreutzer, 2005)
69

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 38: Phasen im Simulationsmodellierungszyklus (Page u. Kreutzer, 2005)
70

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 39: Kriteriengruppen zur Auswahl von Simuations-Software (Prof. Dr.-Ing. Willibald
A. Günthner u. Dipl.-Ing. Martin Haller, 1997)
71

3.8 Simulationstechnik 3 GRUNDLAGEN DES PROJEKTES
Abb. 40: Vorgehensweise im Auswahlverfahren (Prof. Dr.-Ing. Willibald A. Günthner u.
Dipl.-Ing. Martin Haller, 1997)
72

3.9 Optimierungsverfahren 3 GRUNDLAGEN DES PROJEKTES
3.9 Optimierungsverfahren
Unter dem Begriff der Optimierung versteht sich im Allgemeinen der Versuch, die bestmögliche
Einstellung oder Menge an Parametern im Hinblick auf ein gesetztes Ziel zu
finden (Papadimitriou u. Steiglitz, 1998). Ein Beispiel wäre die Suche nach einem optimalen
Verhältnis zwischen Rohstoffpreisen und Produktqualität, sodass ein maximaler
Profit erreicht werden kann. Diese Optimierungsprobleme finden sich in vielen Bereichen
der Wirtschaft und der Naturwissenschaften wieder. Die angewandte Mathematik befasst
sich mit der Lösung solcher Optimierungsprobleme und stellt für verschiedene Klassen
von Problemen Methoden zur Verfügung, um den optimalen Zustand eines Systems zu
finden bzw. sich diesem anzunähern.
3.9.1 Definition
Nach Papadimitriou u. Steiglitz (1998) besteht eine Instanz für ein Optimierungsproblem
aus einem Paar (F, c) wobei F die Menge aller gültigen Zusammenstellungen von
Parameterwerten (Lösungen) eines Systems und c eine Kostenfunktion ist, die einer bestimmten
Zusammenstellung einen f ∈ F Wert zuweist:
c : F → R 1
Zu unterscheiden ist die Menge aller möglichen Lösungen und die Menge aller gültigen
Lösungen. Bestimmte Parameter können in ihrem Wertebereich durch Nebenbedingungen
eingeschränkt werden. Erfüllt eine Lösung alle gegebenen Nebenbedingungen, werden
sie als gültig bezeichnet. Zur Lösung des Problems muss nun ein f ∈ F gefunden werden,
für das gilt:
c(f) ≤ c(y), für alle y ∈ F
In diesem Fall ist f die optimale (minimale) Lösung und wird auch als globales Optimum
bezeichnet. Soll die Zielfunktion maximiert werden, so muss die Bedingung c(f) ≥ c(y)
lauten (Papadimitriou u. Steiglitz, 1998).
Neben einem globalem Optimum gibt es noch den Begriff des lokalen Optimums.
Dieser beschreibt ein Optimum für einen bestimmten Wertebereich. Abbildung 41 Der
Zielfunktionsgraph mit lokalem Optimum B im Bereich N und globalem Optimum A
zeigt den Graphen einer Zielfunktion c. Wird der gesamte Graph betrachtet, so ist festzustellen,
dass der Punkt A das globale Optimum (in diesem Fall Minimum) ist. Die
Betrachtung des gesamten Graphen nennt sich auch globale Optimierung und ist gerade
bei komplexeren Funktionen oftmals sehr Zeitaufwändig. In manchen Situationen bietet
es sich daher an, nur einen Teilbereich der Menge F zu betrachten. Würde man nur den
Bereich N mit N ⊂ F betrachten, so ist der Punkt B das Optimum. Man nennt dieses
Vorgehen lokale Optimierung und B ist ein lokales Optimum der Zielfunktion c. Auch
der Punkt A ist ein lokales Optimum und zwar für jeden Bereich N ′ ⊆ F mitA ∈ N ′ .
73

3.9 Optimierungsverfahren 3 GRUNDLAGEN DES PROJEKTES
Abb. 41: Der Zielfunktionsgraph mit lokalem Optimum B im Bereich N und globalem
Optimum A
3.9.2 Klassifikation von Optimierungsproblemen
Jedes Optimierungsproblem lässt sich anhand der folgenden Kriterien in Problemklassen
(Sauer, 2003) einteilen:
• Das erste Kriterium bezieht sich auf den Funktionstyp der Zielfunktion. Lässt
sie sich in der Form f(x) = ax + b darstellen, so wird von einem linearen Optimierungsproblem
gesprochen. Kann diese als quadratische Gleichung der Form
f(x) = ax 2 + bx + c ausgedrückt, so handelt es sich um ein quadratisches Problem,
ansonsten nichtlinear.
• Verfügt ein Problem über mehrere Zielfunktionen, so wird es als multikriterielles
Optimierungsproblem bezeichnet. Hierbei können die Zielfunktionen unter Umständen
auch widersprechen. Ist es nicht möglich den Wert einer Zielfunktion positiv
zu verändern, ohne dass ein anderes Ziel negativ verändert wird, handelt es
sich um ein Pareto-Optimierungsproblem.
• Das dritte Kriterium unterscheidet nach der Größe des Parameterraumes. Ist die
Anzahl der möglichen Lösungen unendlich, zum Beispiel F = R oder F = Q ,
wird ein kontinuierliches Optimierungsproblem untersucht. Ist der Parameterraum
allerdings endlich, z.B. einer Menge von Orten, so handelt es sich um ein diskretes
Optimierungsproblem. Hierbei ist anzumerken, dass es auch Mischformen geben
kann, bei denen die Zielfunktion von einigen Parametern kontinuierlich und von
anderen diskret abhängig ist.
74

3.9 Optimierungsverfahren 3 GRUNDLAGEN DES PROJEKTES
• Das vierte Kriterium unterscheidet, ob der Parameterraum weiter durch Nebenbedingungen
eingeschränkt wird oder nicht. Auch hier kann es zu Mischformen
kommen, bei denen manche Parameter weiter eingeschränkt werden und andere
nicht.
Die Einteilung in Problemklassen hilft dabei, die geeigneten Methoden, die sich zum
Lösen einer bestimmten Problemsorte bewährt haben, auszuwählen. Bekannte Verfahren
für (ganzzahlige) lineare Optimierungsprobleme sind beispielsweise der Simplex-
Algorithmus oder das Branch-and-Bound-Verfahren (Papadimitriou u. Steiglitz, 1998).
Diese Verfahren werden auch exakte Verfahren genannt, da sie die genaue optimale
Lösung eines Problems finden oder feststellen, dass es unlösbar ist, solange die jeweiligen
Algorithmen lange genug laufen. Neben den exakten Verfahren existieren aber auch
die heuristischen Verfahren. Diese sind meist speziell an ein Problem angepasst und
haben die Eigenschaft, dass sie in einer begrenzten Zeit eine gute Lösung (lokales Optimum)
finden. Zum Beispiel werden nur Teilmenge alle möglichen Lösungen bei der
Bestimmung der optimalen Lösung berücksichtigt. Es kann aber keine Aussage darüber
getroffen werden, wie gut die Lösung im Vergleich zur optimalen Lösung (globales Optimum)
ist. Zudem bedeutet der Fehlschlag einer Heuristik (es wird keine gültige Lösung
gefunden) nicht, dass das Optimierungsproblem nicht doch eine gültige Lösung besitzt.
Beispiele für heuristische Verfahren sind intelligente Suchverfahren, wie Tabu-Search
oder schwarmbasierte Verfahren, die sich an der Natur orientieren, wie der Ameisenalgorithmus
(engl.: ant colony optimization). (Dorigo u. Stützle, 2004)
Ein Ansatz, um die Laufzeit zur exakten Lösung von Optimierungsproblemen zu verringern,
ist die dynamische Programmierung. Sie kann immer genau dann angewendet
werden, wenn sich das Ausgangsproblem in mehrere Teilprobleme aufteilen lässt und
sich deren exakte Teillösungen zur exakten Gesamtlösung aggregieren lässt. Durch das
Aufteilen in Teilprobleme ist es möglich, diese, sofern sie unabhängig voneinander sind,
parallel zu lösen. Zudem lassen sich Teillösungen auch für andere Teilprobleme verwenden,
wodurch unnötige wiederholte Berechnungen umgangen werden. (Bellmann, 1957)
Auch die agentenbasierte Optimierung nutzt diese Idee. Ein Agentensystem besteht
aus einer Vielzahl an Agenten. Ein Hauptagent bekommt ein Optimierungsproblem übergeben,
merkt, dass er das Problem nicht lösen kann und teilt dieses dann ich Teilprobleme
auf. Diese Teilprobleme werden dann zu Bearbeitung ausgeschrieben. Andere Agenten
schätzen nun ein, ob und wie gut sie ein Teilproblem lösen können und geben ein Gebot
für dieses ab. Der Hauptagent vergleicht die Angebote und weißt den Agenten daraufhin
die Aufgaben zu. Sobald er die Lösungen erhält, aggregiert er diese zur Lösung des Ausgangsproblem.
In der gerade beschriebenen Vorgehensweise kommunizieren die Agenten
nach dem Contract Net Protokoll. (Tröschel, 2010)
3.9.3 Beispielproblem: Traveling Salesman
Ein bekanntes kombinatorisches Optimierungsproblem ist das Problem des Handlungsreisenden
(engl.: Traveling Salesman Problem). Es gibt eine endliche Menge n > 0 an
Orten und für jeden Ort ist die Entfernung d {ij} mit i, j ∈ {1, ..., n} zu allen anderen
75

3.9 Optimierungsverfahren 3 GRUNDLAGEN DES PROJEKTES
Abb. 42: Ein Beispiel für ein TSP. Gegeben sind die Orte A bis D und die Längen jeder
Verbindung zwischen zwei Städten
Orten bekannt. Gesucht ist die kürzeste Route, die alle Orte miteinander verbindet und
zum Ausgangsort zurückführt. Ein Beispiel für ein Traveling Salesman Problem (TSP)
wird in Abbildung 42 TSP - Beispiel dargestellt.
Allgemein werden die Probleme, die in die Sparte der kombinatorischen Optimierung
fallen als NP-complete eingestuft. Dies bedeutet, dass der Rechenaufwand aller
zur Lösung bekannten Algorithmen exponentiell zur Anzahl der Parameter ansteigt und
somit nicht in angemessener Zeit exakt lösbar sind. Außerdem wird angenommen, dass
keine weiteren Lösungsverfahren gefunden werden können, die das Problem effizienter
lösen können. Ein Verfahren, nach dem diese Optimierungsprobleme exakt gelöst werden
können, ist z.B. der Branch-and-Bound-Algorithmus. (Papadimitriou u. Steiglitz, 1998)
3.9.4 Bibliotheken zur Optimierung
Auflistung beispielhafter Bibliotheken für Optimierungsprobleme:
• OptimJ - Java-based Modeling Language for Optimization (Java):
http://www.ateji.com/optimj/index.html
• Lpsolve - Lösung von Linearer (Ganzzahl) Optimierung (C, Java, Python,...):
http://lpsolve.sourceforge.net/5.5/
• Drools Planner - Heuristiken und Metaheuristiken, Multikriterielle Optimierung
und weiteres (Java):
http://www.jboss.org/drools/drools-planner.html
• Pyomo - Python Optimization Modeling Objects (Python)
https://software.sandia.gov/trac/coopr/wiki/Pyomo
76

3.9 Optimierungsverfahren 3 GRUNDLAGEN DES PROJEKTES
Neben diesen Bibliotheken gibt es noch eine Menge anderer Bibliotheken, auch für andere
Programmiersprachen.
77

3.10 Projektmanagement 3 GRUNDLAGEN DES PROJEKTES
3.10 Projektmanagement
In diesem Kapitel ist die Seminararbeit ”
Projektmanagement“ aufbereitet. Zunächst
wird das Thema eingeleitet und motiviert, welche Aufgaben die Projektleitung hat, was
zu beachten ist und eine allgemeingültige Definition gegeben. Anschließend die Schwierigkeiten
und Probleme skizziert. Zusammenfassend und abschließend werden die Bedingungen
für eine erfolgreich Projektdurchführung festgehalten.
3.10.1 Einleitung
Das Projektmanagement (PM) ist eine große und sehr wichtige Aufgabe für jedes Projekt.
Es ist oft die Ursache für den Projekterfolg bzw. –misserfolg. So scheitern viele
Projekte wegen eines schlechten PMs. In diesem Rahmen hat eine Studie der PA Consulting
Group in Kooperation mit der Deutsche Gesellschaft für Projektmanagement e.V.
(GPM) die häufigsten Gründe für das Scheitern von Projekten dargestellt (OpenAdvice
IT Services GmbH, 2012). Nachfolgenden die Antworten der befragten Unternehmen:
Abb. 43: Projektmanagement-Ursachen des Scheiterns (OpenAdvice IT Services GmbH,
2012)
Aus den Antworten lässt sich entnehmen, dass beinah alle Gründe für das Scheitern von
Projekten in erste Stelle mit PM in Beziehung stehen. So wurde ”
unklare Anforderungen
und Ziele“ und ”
fehlende PM-Erfahrung auf Leitebene“ am häufigsten genannt. Weitere
Gründe, die im Aufgabenbereich des Projektmanagers fallen, sind:
• Unzureichende Projektplanung
• Schlechte Kommunikation
• Mangel an qualifizierten Mitarbeitern
78

3.10 Projektmanagement 3 GRUNDLAGEN DES PROJEKTES
Abb. 44: Projektmanagement - Schaukel (Bue, 2012)
• Fehlende PM-Methodik
• Mangelhaftes Stakeholder Management
• Technische Anforderungen zu hoch
In diesem Rahmen ist die Wichtigkeit des PMs zu erwähnen. So müssen alle Rollen
und Aufgaben klar definiert sein und strukturiert dargestellt werden können. In diesem
Zusammenhang ist der Projektmanager für das gesamte Projekt verantwortlich und soll
deshalb alle Gründe für den Erfolg eines Projektes schaffen. Es ist daher von großer
Bedeutung einen erfahrenen und kompetenten Projektmanager zu fördern, der die Managementaufgabe
erfolgreich bewältigt kann und somit die Soll-Ziele erreicht.
3.10.2 Definition eines Projektes
Der Vorgang eines Projektes ist strukturiert und besteht aus mehreren Phasen. Die
Phasen sind:
• Vorbereitungen:
79

3.10 Projektmanagement 3 GRUNDLAGEN DES PROJEKTES
Dabei wird das Projekt initialisiert und das Ziel definiert. (Dr. Achim Schmidtmann,
2012)
• Planung:
Hierbei geht es um die Planung der gesamten Projektdurchführung in der festgelegten
Zeit. (Dr. Achim Schmidtmann, 2012)
• Durchführung:
In dieser Phase werden die geplanten Aufgaben durchgeführt. (Dr. Achim Schmidtmann,
2012)
• Kontrolle & Steuerung:
Die Umsetzung der Projektvorgaben wird überwacht und bei Abweichungen korrigiert.
(Dr. Achim Schmidtmann, 2012)
• Abschluss:
Das Projekt wird in dieser Phase abgeschlossen und das Projekt wird abgegeben
und schließlich evaluiert. (Dr. Achim Schmidtmann, 2012)
3.10.3 Schwierigkeiten und Probleme
In der Einleitung wurde beschrieben, dass Projekte häufig am Projektmanagement scheitern.
Jedoch auch erfolgreiche Projekte laufen häufig durch Probleme und haben oft
Schwierigkeiten bis das Endziel erreicht wird. Zu diesen Schwierigkeiten gehören ebenfalls,
dass...
• 50% der IT-Projekte die Termin- und Kostenvorgaben nicht einhalten können (TE-
SIS PLMware GmbH, 2013)
• 30% der IT-Projekte ohne jegliches Ergebnisse abgebrochen werden (TESIS PLMware
GmbH, 2013)
Des Weiteren können weitere Probleme des PMs nach Phasen des Projektes klassifiziert
werden (Albrecht, 2008):
3.10.3.1 Schwierigkeiten in der Projektdurchführung
• Mangelhafte Planung
Problematisch in der Planung ist die Setzung der unklaren und unrealistischen
Ziele, wozu die Planungsinstrumente fehlen
• Einmaligkeit von (IT-)Projekten
Durch die Einmaligkeit der Projekte werden Dinge oft fehleingeschätzt, da keine
Erfahrungen vorhanden sind.
80

3.10 Projektmanagement 3 GRUNDLAGEN DES PROJEKTES
• Viele Lösungsmöglichkeiten
Die Tatsache, dass ein Projekt von einem Team durchgeführt wird, führt dazu, dass
mehrere Lösungsmöglichkeiten vorgeschlagen werden, ohne dass die Komplexität
des Lösungsverfahren erkannt werden
3.10.3.2 Schwierigkeiten während der Entwicklung
• Individualismus
Programmierer sind meist Individualisten mit großen Unterschieden im Können
”
und Wissen, daher ist es für die Projektleitung schwierig, den Personalaufwand
abzuschätzen.“
• Technologie
Die raschen technologischen Veränderungen von Hardware und Software erfordern
”
oft Änderungen an der Planung während des Projektes.“ Dazu kommt noch, dass
die neuen Technologien oft von Nutzern nicht beherrscht werden.
• Standards
Weitere Gründe für Misserfolge sind die Nichteinhaltung von Standards und die
Entstehung von Eigenentwicklungen.
3.10.3.3 Schwierigkeiten in der Projektkontrolle
Software ist immateriell und der Projektfortschritt ist daher für lange Zeit nicht nachvollziehbar.
Der Entwicklungsstand ist daher kaum erkennbar. Dies alles erschwert die
Planung.
3.10.4 Bedingungen für erfolgreiche Projekte
Um Projekte erfolgreich abschließen zu können und die im vorherigen Kapitel genannten
Schwierigkeiten beseitigen zu können einige Bedingungen erfüllt werden. Diese bestehen
aus einer klaren Definition, welche tatsächlich realisierbar und messbar sind. Zudem ist
eine gute Projektplanung eine wichtige Bedingung für erfolgreiche Projekte. Des Weiteren
bestehen die Aufgabe des Projektmanagers richtige und situationsgerechte Methoden
einzusetzen bzw. vorzuschlagen. Dazu kommen noch Voraussetzungen an das Team,
wie Teamgeist, Motivation, Engagement, Kompetenzen der Projektmitglieder und des
Projektleiters, gerechte Aufgabenverteilung und direkte und ununterbrochene Kommunikation.
81

3.10 Projektmanagement 3 GRUNDLAGEN DES PROJEKTES
Abb. 45: Projektmanagement-Phasen; Quelle: Eigendarstellung in Anlehnung an ”
Projektmanagementzitate“
82

3.11 Expertengespräche 3 GRUNDLAGEN DES PROJEKTES
3.11 Expertengespräche
Im Laufe des Projektes wurden mehrere Interviews mit unterschiedlichen Interviewpartnern
durchgeführt. Zur Vorbereitung der Interviews wird ein Fragenkatalog erstellt,
in welchem die Fragen an die Interviewpartner in verschiedene Themenbereiche strukturiert
und aufgeteilt sind. Dadurch konnten die Interviews effizient und konstruktiv
durchgeführt werden.
Die Interviews werden parallel zur Projektfortentwicklung gehalten, um die relevanten
Themen für das Projekt mit außenstehenden Partnern, die im Bereich von Offshore-
Windenergie tätig sind, zu besprechen und deren Wissen und Erfahrungen in das Projekt
einfließen zu lassen. Aus den geführten Interviews werden die zusätzlichen Anforderungen
an das Projekt und die Zielsetzung definiert, was zu Beginn der Projektgruppe noch nicht
vollständig möglich war.
Die Interviews waren ein wichtiger Teil des Projekts über dessen gesamte Dauer hinweg,
sowohl in der Anfangsphase, um die vollständige und detaillierte Vorstellung von
dem zu entwickelnden Produkt zu ermitteln und relevante Informationen und Daten zu
sammeln, als auch in der Entwicklungsphase, um die entstehenden Fragen zu klären und
die Entwicklungsrichtung besser definieren zu können.
Der Kontakt zu außenstehenden Partnern ist besonders wichtig und hilfreich im Hinblick
auf das Thema des Projekts, in dessen Bereich es noch keine festen Regelungen
sowie ausreichende Erfahrungen gibt. Durch die Interviews können die fehlenden Daten
und Informationen ermittelt werden, die durch andere Quellen nicht zu ermitteln sind.
Alle Interviews werden textuell aufgearbeitet und sind im Anhang zur Projektdokumentation
enthalten. Folgend ist eine Liste von durchgeführten Interviews:
• 11.02.2013 Interview mit Overspeed
• 11.03.2013 Telefon - Interview mit Tomas Russy (Head of Operations Development),
AREVA Wind GmbH
• 19.03.2013 Interview mit BTC AG
• 07.05.2013 Telefonat mit Frisia
• 12.06.2013 Telefonat mit HTM (Helicopter Travel Munich GmbH)
Zu den Expertengesprächen können auch die Gastvorträge von Masterarbeitsschreibenden
gezählt werden, die verwandte Thematiken für die Projektgruppe vorgestellt haben:
• 01.11.2012 Simulation von intermodalen Transportszenarien mit Plant Simulation,
Alain Marcel Nguefack Temgoua, B.Eng.;
• 05.12.2012 Optimierung der Einsatzplanung für Offshore - Windenergieparks, Andreas
Rott.
83

3.11 Expertengespräche 3 GRUNDLAGEN DES PROJEKTES
Im Rahmen des Projekts sind auch Kontakt zu der Projektgruppe Cube Runner aufgenommen
worden, um Erfahrungen und Informationen auszutauschen. Ebenso nahmen
Mitglieder der Projektgruppe an Workshops und Konferenzen teil. Im Anhang befindet
sich das Output vom Workshop ”
Towards the Hansa Energy Transition Campus“,
8.März 2013 an der Universität Oldenburg und Workshop ”
Modelling material supply
during the life cycle of wind energy plants“ 13.Februar 2013 an der Universität Oldenburg,
die bei dem Zentrum COAST (Center for Environment and Sustainability) an
der Universität Oldenburg in Kooperation mit Hansa Energy Corridor (hec) organisiert
wurden (siehe Anhang: WorkshopsCOASTuHEC). Insbesondere erwähnenswert ist auch
das Projekt SystOp für die Entwicklung eines Planungs- und Optimierungswerkzeugs
zur System umfassenden Optimierung des Leistungssystems Offshore-Windenergiepark.
84

4 ALLGEMEINE PROBLEMDEFINITION
4 Allgemeine Problemdefinition
Problem: Verteile n Jobs auf m Transportmittel in einem Zeitraum von j Stunden,
sodass ...
1. alle Jobs aus der Menge der Jobs N abgearbeitet werden
2. sich ein Transportmittel zu einem Zeitpunkt nur an genau einem Ort befindet
3. ein Job nur genau einem Transportmittel zugeordnet ist
4. zwischen zwei OWAs genügend Zeit für den Überstieg bleibt
5. das Zeitfenster des Arbeitstages nicht überschritten wird
6. die Kapazitäten der Transportmittel nicht überschritten werden
und
7. die Summe der fixen und variablen Kosten der Transportmittel
möglichst optimal sind.
4.1 Hauptszenario
Zur Ausführung der Software wird ein Hauptszenario beschrieben, in dessen Rahmen
sich alle anderen Szenarien bewegen werden. In diesem Zusammenhang wird zunächst
beschrieben, welche Grundlagen erfüllt werden müssen, damit das Hauptszenario und
alle weiteren Szenarien ausgeführt werden können.
4.1.1 Offshore-Windenergiepark und Hafen
Es wird zunächst vorausgesetzt, dass ein OWP existiert, welche aus zwölf WEA besteht.
Zudem muss mindestens ein Hafen existieren, von dem die Transportmittel starten.
Die Routen zwischen dem Hafen und das OWP sollen bestehen, da somit die erlaubte
Geschwindigkeit ermittelt werden kann.
4.1.2 Offshore-Windenergieanlagen und Jobs
Ein Hafen soll über mindestens zwei OWA verfügen, an denen jeweils ein oder mehrere
Jobs ausgeführt werden müssen. In diesem Rahmen soll beachtet werden, dass die gesamte
Dauer aller auszuführenden Jobs nicht das festgelegte Zeitfenster überschreitet.
Des Weiteren soll bei der Planung der Mitarbeiteranzahl die HSE-Aspekte berücksichtigt
werden, d.h. beispielsweise es müssen sich mindestens drei Mitarbeiter auf einer WEA
befinden, falls dort ein Job ausgeführt werden müssen.
Die Anzahl der zu planenden Jobs kann in Abhängigkeit der Arbeitszeitfenster und
Transportmittelkapazität variieren. So kann eine beliebige Zahl an Jobs geplant werden.
85

4.1 Hauptszenario 4 ALLGEMEINE PROBLEMDEFINITION
4.1.3 Transportmittel
Zur Ausführung der Jobs bedarf es ein Transportmittel. In der vorliegenden Software ist
es erlaubt Transportmitteln zu wählen, die zu einem der folgenden Typen gehören:
• Schiff
• Helikopter
Zur Ausführung der Jobs müssen mindestens zwei Transportmittel des Typs Schiff
gewählt werden. Welche Voraussetzungen ein Transportmittel im Allgemeinen erfüllen
muss, wurde in diesem Dokument bereits beschrieben.
4.1.4 Arbeizeitfenster
Ein zu optimierenden Plan benötigt eine Arbeitszeit. Diese soll während der Planungsphase
(Scheduling) festgelegt werden. Es wird empfohlen eine Zeitfenster von acht oder
mehr Stunden zu planen.
4.1.5 Algorithmus
Im Rahmen dieses Projektes soll die Optimierungsproblematik anhand von drei Algorithmen
gelöst werden. Während der Planung soll dann ein Algorithmus ausgewählt werden.
Im Allgemeinen setzen die Algorithmen die gleichen Bedingungen voraus. Die Optimierungsschritte
sind jedoch unterschiedlich. Mehr zu diesem Thema kann im Kapitel 6.3
Optimierungskonzepte gelesen werden.
4.1.6 Masterdaten
In der Optimierung muss mit verschiedene Kennzahlen gearbeitet werden. Diese Kennzahlen
sind vom Benutzer festzulegen, da diese nur teilweise über einen bestimmten
Zeitraum konstant gleichbleibend sind, wie beispielsweise die Treibstoffkosten. Die Festlegung
der Masterdaten ist essentiell für Ausführung der Optimierungsalgorithmen.
86

5 ANFORDERUNGSANALYSE
5 Anforderungsanalyse
Im Rahmen der Projektgruppe (PG-SCOWS) wird ein Softwaretool zur Planung und Simulation
der Wartungsarbeiten von OWPs implementiert. Das Ziel dieser Projektgruppe
ist ein flexibles Werkzeug für eine simulationsbasierte Koordinierung der Servicefahrten
an OWPs zu realisieren.
Das Simulationswerkzeug soll zudem über eine grafische Benutzeroberfläche verfügen,
die eine intuitive Bedienbarkeit ermöglichen. Das Simulationswerkzeug soll zu einem
Entscheidungs- und Planungssystem für Planer von OWP-Servicing werden.
5.1 Funktionale und nicht-funktionale Anforderungen
In diesem Zusammenhang hat die PG eine Reihe von Anforderungen definiert, welche
von der zu implementierende Software erfüllt werden müssen. Im Folgenden werden diese
in funktionale und nicht-funktionale Anforderungen gegliedert:
5.1.1 Funktionale Anforderungen
Hier werden die funktionalen Anforderungen je nach Thema zugeordnet:
5.1.1.1 Simulation:
• Das System soll die Abläufe eines Einsatzplans simulieren
• Ein Hauptszenario sollte anpassbar sein
• Das System soll während der Simulation den Einsatzplan anzeigen
• Das System soll durch die Simulation die (kosten- und/oder zeit-) effizienteste
Fahrzeugalternative überprüfen können
• Eine Simulation sollte einen Start- und Endpunkt (z.B. von und bis Zentralhafen)
haben
• Die Simulation soll dynamisch sein
• Die Simulation soll die Seerouten einhalten
• Die Simulation soll alle wichtigen Verkehrsrichtlinien berücksichtigen
• Die Simulation soll die Wetterlage berücksichtigen
• Eine Simulation soll gestartet werden können
• Eine Simulation soll unterbrochen werden können
• Eine Simulation soll beendet werden können
• Das System soll die gesamte Wartungszeit anzeigen
87

5.1 Anforderungen 5 ANFORDERUNGSANALYSE
• Das System soll die Zeit für einzelne Wartungsarbeiten anzeigen
• Das System soll die Fahrzeit darstellen
• Das System soll den Startpunkt darstellen
• Das System soll die Wartungsroute darstellen
• Das System soll die zur Wartung benötigten Ressourcen darstellen
• Das System soll das Wartungsfahrzeug darstellen
• Das System soll den OWP darstellen
• Das System soll die einzelnen WEA eines OWPs darstellen
• Das System soll die Wetterbedingungen darstellen
• Das System soll Störungen darstellen können
• Das System soll durch die Planung die (kosten- und/oder zeit-) effizienteste Fahrzeugalternative
für die Wartungsarbeit erkennen und vorschlagen können
• Die Simulation soll von dem eingeplanten Wartungshafen gestartet und beendet
werden
5.1.1.2 Wartung:
• Das System soll mit einer menschlichen Interaktion eine Wartung planen können
• Ein Wartungsplan basiert auf einem Szenario
• Es muss ein Hauptszenario geben, das als Basis für alle weiteren Szenarien gilt
• Das System soll die Vorbereitungszeiten der Ressourcen für den Wartungsplan
berücksichtigen
• Eine Wartungsplanung sollte mindestens zwei Wartungsfahrzeugtypen (z.B. Schiff,
Helikopter) unterscheiden
• Das System sollte das Vorhandensein der Ressourcen (Personal, Plattformen, Schiffe,
Transporter, Helikopter, etc.) und deren Kapazitäten berücksichtigen
5.1.1.3 Einsatzplan:
• Die Simulation eines Einsatzplans kann mittels einer Kartendarstellung dynamisch
visualisiert werden
• Es soll mindestens ein Hauptwartungsszenario entwickelt/erstellt werden
• Es soll ein zentraler Hafen für den Einsatz geplant werden
88

5.1 Anforderungen 5 ANFORDERUNGSANALYSE
• Ein Einsatzplan soll neben der Simulationsvisualisierung einsehbar sein
• Probleme, die im Laufe der Simulation eines Plans aufgedeckt werden, müssen für
den Nutzer einsehbar sein
• Ein Einsatz soll simuliert werden können
• Die Optimierungskomponente soll einen Einsatzplan hinsichtlich verschiedener Kriterien
optimieren
• Die Ausgabe der Optimierung besteht aus einem optimierten Einsatzplan
• Zuvor erzeugte Modellobjektdateien müssen über eine Eingabeschnittstelle einlesbar
sein
• Ein vorliegender Plan muss vom System eingelesen werden können
• Daten, die sich nicht ändern, wie historische Wetterdaten oder Seerouten, sollen
persistent abgespeichert werden
• Erzeugte Einsatzpläne müssen vom System persistent gespeichert werden können
5.1.1.4 Scheduling
• Im Scheduling sollen alle Jobs für den aktuellen Tag zwischen dem Frühester Anfangszeitpunkt
(FAZ) und Spätester Anfangszeitpunkt (SAZ) entsprechend der
vorhanden Jobs angezeigt werden
• Der Nutzer soll die Möglichkeit haben ”
Must-Do“-Jobs zu definieren.
• Dem Nutzer soll ein Zeitfenster für die Definition von Arbeitszeiten zur Verfügung
gestellt werden
• Der Nutzer soll die Möglichkeit haben über das Scheduling die Transportmittel,
die an die Optimierung weitergegeben werden, zu definieren.
• Die Verfügbarkeit der Transportmittel im Scheduling ist abhängig von den Wetterbedingungen
• Im Scheduling soll es möglich sein neue Jobs zu erstellen.
• Im Scheduling soll es möglich sein neue Transportmittel zu erstellen.
• Im Scheduling soll die Möglichkeit geben sein Pläne zu speichern und bei Bedarf
zur Verfügung zu stellen
89

5.1 Anforderungen 5 ANFORDERUNGSANALYSE
5.1.1.5 Optimierung
• Die Optimierung soll einen hinsichtlich einer bestimmten Zielgröße optimierten
Einsatzplan zurückliefern
• Sämtliche von der Optimierung berechneten Pläne müssen den Constraints entsprechen
– Das definierte Zeitfenster darf nicht überschritten werden
– Die maximale Anzahl der zu transportierenden Mitarbeiter pro Transportmittel
darf nicht überschritten werden
– Die Menge der Cluster entspricht der Menge der Transportmittel
• Es sollen mehrere Optimierungsverfahren zur Verfügung stehen
• Das Optimierungsmodul soll serverseitig implementiert sein
• Die Laufzeit der Optimierung soll die Usability der Anwendung nicht beeinträchtigen
5.1.2 Nicht-funktionale Anforderungen
Die Windenergie leistet heute in vielen Ländern einen wichtigen Beitrag zur Stromversorgung.
Sicherheit, Qualität und die Einhaltung geltender Normen und Vorschriften
spielen daher für Betreiber, Hersteller und Investoren eine entscheidende Rolle. Im folgenden
Abschnitt werden die Gesetze und Normen festgehalten, die mindestens einzuhalten
sind:
Bei OWA spielen Normen eine wichtige Rolle: Von der persönlichen Schutzausrüstung
der Mitarbeiter einer Plattform über den Korrosionsschutz der OWA bis hin zur Offshore-
Kabelverlegung. Wolfram Braasch kam zu dem Schluss, dass standardisierte Prozesse,
Bauteile und Systeme die Risiken, die auf einer WEA möglich sind, deutlich minimieren
können.
• In der Zulassungsphase ist jedes Bundesland für den OWP innerhalb der 12 Meilenzone
zuständig, aber in der ausschließlichen Wirtschaftszone ist das Bundesamt
für Seeschifffahrt und Hydrographie BSH zuständig
• Wasser- und Schifffahrtsdirektion prüft Auswirkungen auf den Schiffsverkehr und
erteilt Zustimmung
• Jeder OWP ist auf 25 Jahre befristet, danach ist eine erneute Genehmigung erforderlich
• Bei Wartungsarbeiten einer WEA muss beachtet werden, dass während der Wartung
diese abgeschaltet werden muss und somit während der Überholung kein
Energie aus dem potenziell starken Wind erzeugt werden kann
90

6 KONZEPTE
6 Konzepte
In den nachfolgenden Kapiteln werden die einzelnen Konzepte der zu modellierenden
Module beschrieben. Diese müssen nicht unbedingt 100% übereinstimmend sein, aber es
wird zum einen der Entwicklungsprozess und die gedankliche Auseinandersetzung mit
dem Thema deutlich.
Des Weiteren kann im späteren Verlauf auf die Probleme und Schwierigkeiten näher
erläutert und eingegangen werden sowie die daraus resultierenden Lösungsansätze der
Software.
6.1 GUI-Konzept
Die zu entwickelnde grafische Benutzerschnittstelle (Graphical User Interface, kurz GUI)
soll aus genau einem Fenster bestehen. Das Fenster wird im folgenden als Hauptfenster
bezeichnet und soll eine klassische Menüleiste besitzen. Innerhalb des Hauptfensters
können verschiedene Ansichten (View) dargestellt werden. Die Menüleiste soll im Kontext
zur jeweils dargestellten Ansicht stehen. Zusätzlich zur Menüleiste kann die jeweilige
Ansicht bei Bedarf eine Werkzeugleiste einblenden.
Eingabe- und Bestätigungsdialoge sollen durch einen modalen Dialog dargestellt werden.
Die Eingabe-Dialoge dienen dabei zum Speichern von Daten in einer zentralen
Datenbank. Jeder Dialog muss sicherstellen, dass vor dem Senden der Daten eine Konsistenzprüfung
stattgefunden hat. Geprüft werden sollen dabei sowohl die zugelassenen
Werte je Feld, als auch deren Wertebereich. Erst nach einer erfolgreichen Prüfung soll
die Möglichkeit zum Speichern angeboten werden.
Im Hauptfenster werden mindestens die folgenden Ansichten benötigt:
1. Simulationsansicht
2. Planungsansicht
3. Auswertungsansicht
Zu den oben genannten Ansichten sollen noch die Eingabe-Dialoge für die folgenden
Entitäten entstehen:
4. Transportmittel erstellen
5. Jobs erstellen
6. Hafen erstellen
7. OWA erstellen
8. OWP erstellen
Allgemeingültige Daten sollen in einem Stammdaten-Dialog bearbeitet werden können.
Hierzu sollte mindestens der folgende Dialog eingeführt werden:
91

6.1 GUI-Konzept 6 KONZEPTE
9. Stammdaten-Verwaltung
Hauptfenster Das Hauptfenster soll im Wesentlichen aus einem Rahmen und einem
klassischen Menü bestehen. Ein Menü gehört klassischerweise an den oberen Rand des
Fensters. Die Menüeinträge sind durch Separatoren gruppiert und können sowohl mit
der Maus als auch mit der Tastatur bedient werden.
Simulationsansicht Um den Schwerpunkt der Anwendung hervorzuheben, soll die Simulation
bzw. Optimierung als initiale Ansicht dienen. Die Simulationsansicht soll aus
den folgenden Komponenten bestehen:
Werkzeugleiste Auf der Werkzeugleiste sollen Steuerelemente für die Simulation untergebracht
werden. Ebenso werden Schaltflächen und Schieberegler
zur Steuerung der Karte bereitgestellt.
Baumansicht
Karte
Im linken Teil der Ansicht sollen die Akteure der Simulation in einer
Baumansicht aufgelistet werden.
Im Hauptanteil der Ansicht soll die Karte angezeigt werden. Über ein
Menü soll das angezeigte Kartenmaterial gewählt werden können.
Planungsansicht
Die Planungsansicht soll zur Erstellung eines neues Plans dienen. Hierzu soll sie die
planbaren Entitäten (Fahrzeuge, Aufgaben) darstellen. Sobald der Benutzer den Plan
erstellt hat, soll er an die Optimierung übergeben werden. Während der Optimierung
muss die Oberfläche eine Warteanzeige einblenden und sämtliche Benutzeraktivität verhindern.
Die Planung soll sich in der ersten Version grundsätzlich nur auf einen Tag
beziehen. Eine mehrtägige Planung ist für zukünftige Versionen durchführbar.
Die Bedienung der Software soll hauptsächlich mit einer Maus bedient werden können.
Dabei soll darauf geachtet werden, dass die Benutzerführung einfach und intuitiv bleibt.
Buttons werden beispielsweise per Klick dazu gebracht etwas zu tun, aber auch ”
Drag &
Drop“ wird zur Verfügung gestellt. Beim Letzteren sollten zum Beispiel Jobs aus einer
Liste in die Tageseinsatzplanung gezogen werden können. Des Weiteren sollten Eingaben
mit Hilfe der Tastatur erfolgen, um beispielsweise ein Transportmittel anlegen zu können.
Das Wechseln zwischen den einzelnen Views sollte auf der nächst höheren Ebene erfolgen,
indem auf die nächste Planungsebene zugegriffen wird. Das heißt, es wird aus
dem Menü die Planung gestartet (start scheduling), woraufhin die View des Scheduling
geöffnet wird. In dieser Ansicht gibt es drei Spalten geben. Zum einen die zur Verfügung
stehenden Transportmittel (means of transport), die mittlere Spalte besteht aus den
geplanten Jobs (day planned maintenance jobs) der Tageseinsatzplanung und auf der
rechten Seite die vorhanden Jobs (planned jobs). Den Button für das Arbeitszeitfenster
(working hours) für den jeweiligen Arbeitstag kann definiert werden. Zusätzlich soll
Zum Zurückkehren aus der Scheduling-Ansicht zur Hauptansicht muss die Planung abgebrochen
(cancel) werden, wodurch die Startview wieder angezeigt wird. Um den Tageseinsatzplan
zu optimieren, wird auf ”
Starte Optimierung“ (start optimisation) geklickt.
Nach dem Starten der Optimierung, soll eine Ladezustandsanzeige auftauchen und bei
92

6.2 Scheduling-Konzept 6 KONZEPTE
Beendigung verschwinden, sodass erkennbar ist, dass im Backend die Optimierung durchlaufen
wird. Im Scheduling ist demnach sofort ersichtlich, was geschieht. Außerdem hat
der Benutzer einen gewissen Einfluss auf die durchzuführenden Aktionen und kann unmittelbar
seine Aktionen verfolgen. Zum Beispiel beim Planen von Jobs für den aktuellen
Tageseinsatzplan mittels Drag & Drop. Erfolgte dies, so ist einem Transportmittel ein
oder mehrere Jobs zugewiesen und dem Planer sichtbar im entsprechendem Feld angezeigt.
6.2 Scheduling-Konzept
Das Scheduling unterstützt im Allgemeinen bei der Vorbereitung von Entscheidungen in
der Planung, wie man Ressourcen bei einer Vielfalt von möglichen Aufgaben verteilen
kann. Dabei können die Termine fest oder als ein Teil einer Reihenfolge von Ereignissen
schwimmend sein.
Ein ”
Schedule“ ist ein Fahrplan, der die Ereignissen und Ressourcen berücksichtigt.
Die Ressourcen sind nur in bestimmten Zeiten verfügbar und die Ereignisse werden
während dieser Zeiten geplant. Der Prozess zur Erstellung eines Fahrplans wird Scheduling
genannt. Abhängig von den Betriebsbedingungen kann das Scheduling durch den
Manager oder durch die Benutzer mittels eine Reihe von vorgeschriebenen Regeln erstellt
werden.
Das Scheduling spielt eine wichtige Rolle bei der Wartung von OWPs zur effizienten
Verteilung von begrenzten Ressourcen und die Planung von Jobs, die auszuführen sind.
Im Rahmen des Projekts wurde eigens ein Scheduling-Konzept erstellt. Dieses Konzept
wurde zum Basismodul, auf den alle nachfolgenden Module (Optimierung, Simulation)
aufbauen. Die Abbildung 46: Aufbau des Scheduling/Darstellung von Drag&Drop zeigt
exemplarisch den Aufbau der Scheduling-Moduls. Zwischen der mittleren und rechten
Spalte sollten per Drag & Drop ein vorhandener Jobs in die Liste für die ”
geplanten
auszuführenden Jobs“ gezogen werden können.
Das Scheduling-Modul übergibt an das Optimierungsmodul ”
Must-Do-Jobs ”
und zusätzlich
alle noch ausführbaren Jobs. Somit werden folgende Kategorien von Jobs unterschieden:
Korrektive Jobs (Must-Do-Jobs) und präventive Jobs (Can-Do-Jobs). Jeder
Job hat FAZ und SAZ sowie Frühester Endzeitpunkt (FEZ) und Spätester Endzeitpunkt
(SEZ). Außerdem werden dem Job die Priorität und die benötigten Ressourcen
(z.B. Helikopter oder bestimmtes Schiff oder Arbeitskraft) zugewiesen.
Dazu werden noch die Anzahl, der zur Verfügung stehenden Transportmittel mit dem
jeweiligen Typ an die Optimierung übergeben. Auch die Arbeitszeiten werden vom Scheduling-Modul
festgelegt. In der Abbildung 47: Zur Verfügung stehende Transportmittel
werden die zur Verfügung stehenden Transportmittel entsprechend dem Planer in der
linken Spalte der Scheduling-View dargestellt.
Dabei bekommt der Benutzer folgende Funktionalitäten:
• Der Benutzer (Planer) kann aus eine Liste von Jobs die Must-Do-Jobs auswählen.
• Der Benutzer (Planer) legt die Arbeitszeit, also das Zeitfenster fest.
93

6.2 Scheduling-Konzept 6 KONZEPTE
Abb. 46: Aufbau des Scheduling/Darstellung von Drag&Drop (Quelle Eigendarstellung)
• Der Benutzer (Planer) legt die Anzahl und Typen der zur Verfügung stehenden
Transportmittel fest. Die Transportmittel, dazugehörigen Informationen und Daten
werden aus der Datenbank geladen.
Das Scheduling-Modul übernimmt weiter folgende Aufgaben. Zunächst werden die Hard
Constraint (HC)s, wie beispielsweise das Wetter insbesondere des Wellengangs geprüft.
Falls diese einen Tageseinsatz zulassen, wird der Vorgang der Planung fortgeführt. Das
Scheduling-Modul holt sich alle vorhanden Jobs und zusätzliche alle verfügbaren Transportmittel
aus der Datenbank. Die Jobs haben eine Priorität, was bedeutet, dass defekte
OWAs einen Gewinnausfall haben und diese dadurch möglichst schnell wieder in Stand
gesetzt werden sollten. Der Planer entscheidet jedoch selbst, welche Jobs an dem Tag
erfüllt werden sollen.
Des Weiteren kann der Benutzer die Arbeitszeit des Tages festlegen. Dabei sollte beachtet
werden, dass der Zeitpunkt gilt, wo die Mitarbeiter das jeweilige Transportmittel
betreten bzw. deren Schicht beginnt. Das Zeitfenster gibt darüber hinaus mögliche Arbeitszeit
im OWP an. Diese Informationen kann z.B. beim Umstieg der Sommer- zur
94

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 47: Zur Verfügung stehende Transportmittel (Quelle Eigendarstellung)
Winterzeit oder umgekehrt genutzt werden. Aber auch, wenn die Wetterdaten nahelegen,
dass nur beispielsweise bis 15:00h nachmittags deutscher Zeit gearbeitet werden kann.
Durch drücken des Buttons kann die Zeit intern festgelegt und gespeichert. Diese wird
dann auch von der Optimierung und allen anderen Modulen genutzt.
Als Ergebnis wird eine Liste von Jobs und den zur Verfügung stehenden Ressourcen
zurückgeliefert. Durch die Weitergabe der Daten an das Optimierungsmodul werden
diese weiterverarbeitet und annähernd Kosten minimierend verteilt.
6.3 Optimierungskonzepte
Dieses Kapitel behandelt die Umsetzung eines Optimierungskonzeptes, deren Schwierigkeiten
und Probleme, die zu bewältigen sind und wie die allgemeine Vorgehensweise ist.
Dazu gehört die Unterteilung der einzelnen Probleme in kleinere Teilprobleme, um die
Komplexität zu vermindern und jeweils nach einem bestimmten Kriterium vorrangig zu
optimieren.
6.3.1 Problemstellung
Das Modul der Optimierung benötigt vom Scheduling drei Listen. Davon sind zwei Listen
mit Jobs und eine Liste mit Transportmittel. Die Listen der Jobs teilen sich auf in
vorhandene Jobs und in selektierte Jobs. Mit der Liste der Transportmittel wird die
Information übergeben, was für Transportmittel an dem zu planenden Tag zur Verfügung
stehen.
Die übergebenen Daten müssen mindestens die folgenden Informationen enthalten:
• Job-Liste:
Die Job-Liste enthält die bevorzugten Jobs der Planers; zum Beispiel durch den
Gewinnausfall (vom Planer eingeschätzt) oder priorisierten bzw. favorisierten Jobs
des Planers.
• Transportmittel-Liste:
95

6.3 Optimierungskonzepte 6 KONZEPTE
Es werden die zur Verfügung stehenden Transportmittel für die Erfüllung der Jobs
übermittelt. Die Liste setzen sich aus den unterschiedlichen Schiffstypen und Helikoptern
zusammen.
• Zeitfenster:
Zusätzlich wird das Zeitfenster der Arbeitstages vorgegeben, sodass unterschieden
werden kann, wann beispielsweise frühestens rausgefahren werden kann oder bis
zu welchem Zeitpunkt längstens unterwegs sein kann.
• Treibstoffkosten:
Zur Bestimmung des geringsten Kosten für das Transportmittel können die tagesaktuellen
(manuell festgelegten) Preise eingegeben/abgefragt werden, sodass mittels
dieser die anfallenden Kosten abgeschätzt werden können und anhand dessen
das kostengünstigste Transportmittel gewählt werden.
6.3.1.1 Informationsgehalt der Job-Liste
Ein Job aus der Job-Liste sollte mindestens die folgenden Informationen bereitstellen,
damit die Optimierung eine annähernd optimale Lösung in angemessener Zeit finden
kann:
• Auf welcher OWA soll der Job ausgeführt werden (Geographische Daten)
• Ein Job erfordert eine gewisse Anzahl an Mitarbeitern zur Erfüllung der tatsächlich
auszuführenden Arbeiten. Eine Vorbedingung ist, dass auf einer WEA mindestens
drei Mitarbeiter tätig sind. Da es aber keine direkte zu Ordnung von Personen zu
einem Job gibt, setzt sich ein Job aus mindestens drei Fachkräften zusammen. Des
Weiteren sollen alle Mitarbeiter, zur Vereinfachung dieses Modells, den gleichen
festgelegten Stundensatz (Währungseinheit/Stunde).
• Pro Job muss die Durchführungsdauer festgehalten sein (Angaben werden in Stunden
angegeben, aber in Minuten im System verarbeitet).
• Die Jobs sind priorisiert nach ”
hoch“, ”
mittel“ und ”
niedrig“.
Die im jeweiligen Job enthaltene OWA sollte dabei mindestens die folgenden Informationen
bereitstellen:
• Standort (Lat/Long) – kann auch über eine Nummer ausgedrückt werden bei einem
rechteckigen Windpark. Die Zählung würde dann bei eins in der linken unteren
(südwestlichsten) Ecke beginnen und entsprechend hoch zählen. Das Modell sieht
zur Zeit einen 8 x 8 Windpark aus (64 OWAs) mit einem Rasterabstand von 500
Metern.
• Technische Daten der WEA, wie die maximale Leistung in Megawatt (MW) sowie
der aktuelle Status der jeweiligen WEA (aktiv, inaktiv, defekt). Der Zustand ”
aktiv“
steht für den normalen Betriebszustand, eine WEA gilt als ” ìnaktiv“, wenn
96

6.3 Optimierungskonzepte 6 KONZEPTE
Wartungsarbeiten durchgeführt werden oder die OWA einen Stromüberschuss erzeugt.
Eine WEA wird mit ”
defekt“ deklariert, wenn diese einen Ausfall bzw.
Schaden zu verzeichnen hat und dadurch keine elektrische Energie erzeugen kann.
• Um den zu erwartenden Gewinnausfall kalkulieren zu können, werden Informationen
über die Investitionskosten (Millionen Euro/MW, die Betriebskosten (Euro/MWh)
und den Erlös (Euro/MWh) benötigt. Aus diesen Daten sollte dann der
Gewinnausfall für jede Stunde Inaktivität errechnet werden können.
• Während einer Inaktivität von einer OWA sollten Zeitpunkt abhängige Daten vorliegen.
Diese sollten angeben, wie viele Fachkräfte zu einem bestimmten Zeitpunkt
t x frei sind und beispielsweise abgeholt werden können. Berücksichtigt werden
muss, dass nur komplette Teams abgeholt werden können und diese vom gleichen
Transportmittel abgeholt werden, wie zuvor auf die WEA gebracht.
Ein Transportmittel sollte folgende Daten beinhalten, um die Transportkosten oder die
Fahrzeiten berechnen zu können:
• Ein Transportmittel sollte die maximale Geschwindigkeit zur Verfügung stellen,
um anhand dieser beispielsweise die ”
normale“ Fahrgeschwindigkeit zu ermitteln.
Die vorgegebene Fahrgeschwindigkeit vom Betriebsbüro kann zum Beispiel mit
80% der Maximalgeschwindigkeit oder individuell festgelegt werden.
• Zusätzlich zu der Besatzung eines Schiffes beziehungsweise eines Helikopters sollte
bekannt sein, wie die Passagieranzahl für das jeweilige Transportmittel ist
• Zur Berechnung der Kosten und damit auch zur Ermittlung des günstigsten Transportmittels
sind Angaben wie der durchschnittliche Verbrauch pro Stunde oder
pro Kilometer (variable Kosten) notwendig, außerdem die aktuellen Charterkosten
(Fixkosten).
• Optional sollte die Kapazität zur Ermittlung des Gewichts vorliegen. Mittels dieser
Information sollte beispielsweise die maximale Gesamttransportlast eines Helikopters
berechnet werden können.
Aus diesen Informationen sollen guten Pläne generiert werden, die nach bestimmten
Kriterien möglichst optimal sind. Generell wird erst einmal nur ein guter optimierter
Plan weitergegeben, aber es könnten theoretisch auch mehrere Pläne an die Simulation
übergeben werden.
6.3.2 Annahmen und Voraussetzungen
Das Ermittlung eines guten Plans setzt die Lösbarkeit der vorangegangenen Informationen
voraus.
Um möglichst optimale Pläne zu finden, müssen verschiedene Kombinationen der
unterschiedlichen Kriterien in Beziehung gesetzt werden. Zur Betrachtung werden die
97

6.3 Optimierungskonzepte 6 KONZEPTE
Kosten für Fahrzeuge, Mitarbeiter (konstanter Stundensatz für alle Fachgruppen) und
Fahrstrecke berechnet oder eben der Gewinnausfall je WEA ermittelt.
Die zu verarbeitenden Informationen stellen die Ausgangsliste für alle durchzuführenden
Arbeitsaufträge an einem zu planenden Arbeitstag dar. Zu bedenken ist, dass es sich
hierbei um eine ausschließlich statische Planung handelt, da keine Daten in Echtzeit auf
die Optimierung Einfluss nehmen und dadurch nicht darauf reagiert werden muss.
6.3.2.1 Generelle Annahmen für die Optimierung
Die nachfolgenden Annahmen werden als allgemeingültig für dieses Projekt angesehen
und unterstreichen den Charakter der statischen Planungsebene:
Die Übersteigezeit von einem Transportmittel auf eine OWA bzw. von einer OWA
zurück auf einer Transportmittel beträgt in der Regel um die 20 Minuten. Dies ist eine
wichtige feste Größe, die im Mittel stimmig ist. Die reale Übersteigezeit ist zum Beispiel
von der Wetterlage abhängig, wird aber von dieser nicht in der Optimierung beeinflusst.
Um von einer WEA zur nächsten WEA zu gelangen, werden 10 Fahrminuten benötigt,
sodass zwischen den zwei Übersteigungen insgesamt eine Zeit von 30 Minuten angenommen
werden sollten. Diese Annahmen betreffen die ausschließlich die IntraparklogistikIntraparklogistik.
Des Weiteren wird die Fahrstrecke vom Hafen bis zum Park in mehrere Abschnitte
unterteilt. Das heißt, es gibt die Fahrt auf dem offenen Meer, die von der letzten Tonnen
des Tonnenstrichs vor der Küsten bis zum jeweiligen OWP auf dem möglichst direkten
Weg unter Einhaltung der Vorschriften. Des Weiteren die Fahrstrecke vom Hafen bis
zur letzten Tonne des Tonnenstrich. Diese Strecke sollte extra berechnet werden, da hier
bestimmte Bestimmungen gelten können, wie zum Beispiel vorgegebene Geschwindigkeiten,
wenn durch ein Naturschutzgebiet gefahren wird.
Die Fahrzeit ist außerdem von den verschiedenen Transportmitteln abhängig. Zum
einen hängt die Fahrzeit von der Geschwindigkeit und der Strömung des Schiffstyp oder
beim Helikopter eben von der Windstärke und -richtung ab.
Dies bedeutet, dass die Transportzeit von der Arbeitszeit abgezogen werden muss.
Wenn jetzt nun 12 Stunden reine Arbeitszeit angerechnet werden, die Hinfahrt zwei
Stunden dauert, für die Rückfahrt drei Stunden veranschlagt werden und zum Übersteigen
jeweils 30 Minuten benötigt werden, so bleiben zum Arbeiten auf einer OWA effektiv
nur noch sechs Stunden übrig.
Zu den bisher genannten festen Faktoren wie die Übersteigezeit, die Fahrzeit von einer
zur nächsten OWA, den vom Transportmittel gegebenen technischen Voraussetzungen
wie Geschwindigkeit und dem Zeitfenster gehören ebenfalls die zu Beginn vom Planer
eingetragenen Preise für die Transportmittel benötigten Treibstoffkosten, festen Wetterbedingungen,
um überprüfen zu können, ob es überhaupt im Rahmen der Planung
möglich ist diese einzuhalten. Ist beispielsweise der Wellengang zu hoch, dann kann ein
Schiff nicht mehr eingesetzt werden. Beim Helikopter spielt die Windstärke eine erhebliche
Rolle. Besonders in dem Fall, wenn das Unfallrisiko für das Hoisting auf eine OWA
für das Arbeitspersonal zu hoch ist. Grundsätzlich könnte der Einfluss von Wetter mit
98

6.3 Optimierungskonzepte 6 KONZEPTE
einbezogen werden, allerdings nimmt die Komplexität sehr stark zu. Dies liegt zum einen
der Verarbeitung der Vielzahl an Wetterinformationen und zum anderen an den daran
anknüpfenden rechtlichen Bedingungen. Es wird auf diese Parameter verzichtet, da davon
ausgegangen wird, dass diese dem Planer bekannt sind und von ihm berücksichtigt
werden. Die für die Ermittlung relevanten Informationen können vom Benutzer, wenn
diese vom Standardwert abweichen, individuell angepasst werden.
Weitere Einschränkungen sind durch eine maximale Transportkapazität des Fachpersonal
gegeben. Helikopter transportieren in der Regel maximal fünf Mitarbeiter mit
Werkzeug, wobei es natürlich abhängig ist vom jeweiligen Helikoptertyp (als Maßstab
wurde der Typ EC 135 genommen) und dem Gesamtgewicht von Personal inklusive
Werkzeug. Der Schiffstyp Wind Force 1 transportiert maximal 24 Mitarbeiter zum Einsatzort
plus deren Werkzeug. Jedes Transportmittel, was die gesetzlichen Anforderungen
und für den Einsatzzweck notwendige Bedürfnisse erfüllt, ist denkbar.
Für die Optimierung sind Constraints zu erfüllen, um letztendlich einen Plan für ein
Tag zu finden, der bestimmte Kriterien erfüllt. Es gibt zwei Typen von Constraints.
Ein HC stellt die zu erfüllenden Bedingung dar, die in jedem Fall erfüllt werden muss.
Während ein Soft Constraint (SC) zwar generell beachtet und nach Möglichkeit ebenfalls
erfüllt werden sollte, aber in Sonderfällen unerfüllt bleiben kann, wenn dieser im
Widerspruch zu HCs und anderen SCs steht oder das Problem dadurch unlösbar wird.
Folgend ist eine Liste aufgeführt, die einen Ausschnitt von HCs und SCs widerspiegelt:
• Die kritischen Jobs mit dem höchsten Gewinnausfall und der höchsten Priorität
von OWAs gelten HCs.
• Die Wetterbedingungen, insbesondere der Wellengang und die Windstärke gelten
zu den HCs, da diese ausschlaggebend sind, ob überhaupt auf See gearbeitet werden
kann. Ist der Wellengang zu hoch kann und darf nicht angelegt werden bzw. kein
Übersteigen stattfinden, hauptsächlich aus HSE-Aspekten sowie bei zu starkem
Wind darf der Helikopter aus dem gleichen Grund nicht eingesetzt werden.
• Als weiterer HC gilt das Zeitfenster zur Erledigung aller angesetzten Jobs. Es muss
eine passende Verteilung für die zu erfüllenden Jobs gefunden werden, ansonsten
ist der Einsatzplan ungültig.
• Die eingesetzten Transportmittel sollen möglichst ausgelastet sein, aber ist keine
Notwendigkeit und daher ein SC.
• Die Kosten des Tageseinsatzplans sollte möglichst minimal sein und ist damit ein
SC. Außerdem ist dies eines der Schwerpunkt aus betriebswirtschaftlicher Sicht,
warum der Tageseinsatzplan optimiert wird.
• Damit die Kosten möglichst minimal sind, sollten die Routen jedes Transportmittels
optimal sein. Es kann sein, dass die Routen nicht optimal gelegt werden
können, daher ist dies ein SC.
99

6.3 Optimierungskonzepte 6 KONZEPTE
6.3.3 Optimierungsansätze
Im Folgenden werden drei verschiedene Lösungsansätze vorgestellt. Nach Möglichkeit
werden alle drei Ansätze umgesetzt, sodass zwischen diesen im zu entwickelnden Werkzeug
später gewählt werden könnte. Konzepte und Ansätze die zu keinen guten bzw.
deutlich schlechteren Ergebnissen führen als die anderen oder sind ni0cht realisierbar,
so gibt es dennoch weitere Lösungen. Mindestens eines der aufgeführten Konzepte wird
entsprechend umgesetzt wie beschrieben.
6.3.3.1 Heuristischer Ansatz
Dieser Ansatz verläuft in zwei Phasen und einer optionalen Phase, wenn der Einsatz von
Helikoptern unumgänglich ist.
1. Ermittlung der effizientesten und günstigsten Transportmittelkombinationen mittels
der Anzahl an benötigtem Personal, die wiederum von Schiffen zu den OWAs
transportiert werden sollen. Das Zeitfenster gibt die maximale Arbeitszeit pro Arbeitstag
an. In der Arbeitszeit inbegriffen ist die Transporzeit zum OWP und
zurück. Auf Grund dieses Informationsgehalts kann die maximale Anzahl der Personenstunden
der jeweiligen Jobs abgeschätzt werden, sodass diese Arbeitsaufträge
auch im OWP erledigt werden können.
Basierend auf dem Schätzwert und der Tagescharterkosten für einen bestimmten
Schiffstyp wird die effizienteste und günstigste Transportmittelkombination errechnet.
2. Als erstes wird k (eine Anzahl an Clustern), die Jobliste und die möglichen Transportmittelkombinationen,
die vorher berechnet worden sind, an die Clustering-
Funktion übergeben.
Die geographisch voneinander entferntesten Jobs werden zunächst als Cluster-
Zentren festgelegt.
Der nächste Schritt des Clusterings beinhaltet das iterative Vorgehen. Über den
euklidischen Abstand, auch bekannt unter dem Namen Distanzfunktion, werden
nun die einzelnen Jobs zueinander geclustert. 34
In jedem Iterationsschritt wird in jedem Cluster das Cluster-Zentrum neu berechnet.
Es wird jedoch darauf geachtet, dass die bestimmten Constraints Personenstunden
und Zeitfenster eingehalten werden. Das Clustering durchläuft solange
einen weiteren Iterationsschritt bis alle Jobs aus der Job-Liste einem Cluster eindeutig
zugeordnet werden konnte. Somit entspricht jedes Cluster eine durchführbare
Job-Liste pro Transportmittel unter Berücksichtigung der Constraints. Die
neu zusammengestellte Job-Liste für ein Transportmittel wurde jedoch nur auf die
34 Euklidischer Abstand: ”
Der Euklidische Abstand ist die Mathematische Definition des normalen
Abstands“, Formel-Sammlung.de, http://www.formel-sammlung.de/ld-Euklidischer-Abstand-
540.html, 10.08.2013
100

6.3 Optimierungskonzepte 6 KONZEPTE
Einhaltung des Zeitfensters hin geprüft. Das heißt, die einzelnen Jobs werden jetzt
zeitlich je Transportmittel optimiert.
3. Die optionale Phase ist der Einsatz von Helikoptern. Dieser kommt nur dann zum
Einsatz, wenn der Gewinnausfall der betroffenen OWA so bedeutend groß ist, dass
die zeitliche Ersparnis durch den Einsatz von einem Helikopter gerechtfertigt ist.
Zu bedenken ist, dass mit einem Helikopter nur eine geringe Anzahl von Personen
transportiert werden können, wodurch der Einsatz in der Regel als sehr unrentabel
gilt. Des Weiteren sind die Charterkosten für einen Helikopter sehr hoch und das
Personal muss aufgrund der HSE-Aspekte besonders geschult sein.
Helikopter werden nur dann eingesetzt, wenn die WEA unzugänglich ist mit einem
Schiff. Die Zugänglichkeit kann beispielsweise stark beeinflusst sein durch das Wetter.
Ein anhaltend hoher Wellengang macht das Übersteigen von Schiff zur OWA
und andersherum unmöglich. Im Gegensatz zu dem Transportmittel ”
Schiff“ ist
eine Optimierung der Job unnötig, da nur ein Job pro Helikopter pro WEA ausgeführt
werden können.
Hinweis zur Bewertung: Für jedes Cluster kann ein Teilplan erstellt werden. Die Strecke
zwischen den Anlagen kann zum Beispiel die euklidische Distanz in die Fahrzeit zwischen
den Anlagen umgerechnet werden (siehe Clustering). So kann errechnet werden, wann
genau das Schiff welche Anlage anfährt.
Für jeden Teilplan können die jeweiligen Kosten ermittelt werden. Feststehen die fixen
Kosten für das Chartern der Transportmittel, dieses sind Tagescharterkosten.
Für das Cluster wurde festgelegt in welchem Zeitfenster das angesetzte Transportmittel
welche Anlage anfährt. Aus diesen Informationen kann die gefahrene Strecke im OWA
ermittelt werden. Daraus können die variablen Kosten für den Transport basierend auf
dem Spritkosten berechnet werden.
Für jedes Cluster wird der Gewinnausfall berechnet, der entsteht wenn die Anlagen
nicht im Betrieb sind und keinen Umsatz generieren können. Dabei wird berücksichtigt,
dass keine aktiven WEA abgeschaltet werden. Der Gewinnausfall bezieht sich demnach
nur auf die jeweils defekten OWAs. Die Ausfallzeiten zur Durchführung eines ”
preventive
maintenance“-Jobs während der Service-Arbeiten werden nicht zum Gewinnausfall
hinzugezogen, da die jeweiligen WEA auf Grund der Arbeiten immer aus HSE-Aspekten
abgeschaltet werden müssen und daher sich negativ auswirken.
Die Lohnkosten der Service-Techniker werden zunächst nicht im Speziellen verrechnet,
da davon ausgegangen wird, dass die Angestellten unabhängig von den geleisteten
Stunden im OWP bezahlt werden. Trotz alledem könnten die Lohnkosten pro Clustereinheit
mittels der Einsatzdauer und Anzahl der eingesetzten Service-Techniker errechnet
werden.
Jeder einzelne Clusterplan fügt sich in dem Gesamtplan zusammen, sodass eben aus
allen Teilplänen die Kosten für den gesamten Plan ergeben
101

6.3 Optimierungskonzepte 6 KONZEPTE
6.3.3.2 Graphenansatz
Dieser Ansatz beruht auf der Problemlösung mittels eines graphischen Ansatzes. In erster
Instanz wird das Problem im Ganzen auf kleinere Teilprobleme reduziert, um die
Komplexität zu vereinfachen und des Weiteren kann sich auf das jeweilige zu optimierende
Kriterium beschränkt werden. Insgesamt werden hierbei konkret drei Teilprobleme
abgearbeitet:
1. Wahl der zur Verfügung stehenden Transportmittel
2. Notwendiger Einsatz von Mitarbeitern für die Service-Arbeiten
3. Reihenfolge der abzuarbeitenden Jobs im OWP und auf den OWA
Teilproblem: Bestimmung der Transportmittel
Als erstes findet die Auswahl des benötigten Transportmittel sowie die Anzahl statt. Für
einen zu planenden Tag können mehrere unterschiedliche Typen von Schiffen oder auch
Helikoptern denkbar sein, allerdings stehen nur diejenigen zur Auswahl, die auch wirklich
verfügbar sind. Zusätzlich bestimmt der Einsatzzweck das Transportmittel die Auswahl.
Mittels einer heuristischen Herangehensweise und den festgelegten Constraints, seien es
HCs oder SCs, wird eine Auswahl ermittelt.
Als generelle Einschränkung sind vorrangig die Kapazität und die Geschwindigkeit des
Transportmittels entscheidend. Die Kapazität verdeutlicht die Problematik recht differenziert.
Mit einem Helikopter kann beispielsweise nur eine geringe Anzahl von Personal
inklusive Werkzeug zum OWP im Gegensatz zum Schiff transportiert werden. Der Helikopter
hat jedoch eine deutlich kürzere Transportzeit und kann dann sinnvoll eingesetzt
werden, wenn die Wetterlage den Einsatz von Schiffen unmöglich macht und die Kosten
für einen solchen Einsatz geringer sind als der Gewinnausfall über den gleichen Zeitraum.
Außerdem ist es manch einmal ein notwendiges Mittel zur Einhaltung des vorgegebenen
Zeitfensters. Generell gilt, dass ein Helikopter sowohl höhere Fixkosten als auch höhere
variable Kosten vorzuweisen hat als ein Schiff. Dennoch ist dieses Transportmittel
flexibler und auch bei schlechterer Wetterlage einsetzbar.
Die Lösbarkeit beziehungsweise Unlösbarkeit des jeweiligen Einsatztages und der zu
erfüllenden Jobs sollte in jedem Fall frühzeitig erkannt werden, damit der Planer Anpassungen
an der Tagesplanung vornehmen kann.
Ein Offshore-Windenergiepark besteht in Deutschland immer aus einer Menge von
Windenergieanlagen, welche in einem Raster angeordnet werden. Die gesetzlichen Vorschriften
und Regeln zur Erstellung eines solchen OWP wird vom BSH überwacht sowie
von den zuständigen Wasser- und Schifffahrtsveraltungen. In einem in deutschen AWZ
gelegenen OWP haben die OWA einen fest definierten Mindestabstand von 500 Metern
oder mehr. Die Abbildung 48: Schematische Darstellung eines Windparks stellt exemplarisch
einen solchen Aufbau eines OWP dar.
Die Idee zur Lösung des Problem ist, dass die flache Listenstruktur der Jobs entsprechend
auf den WEAs zugeordnet werden. Durch die Abfrage des Status einer WEA
102

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 48: Schematische Darstellung eines Windparks (Quelle Eigendarstellung)
kann die Priorität angepasst werden, sodass die auszuführenden Service-Arbeiten an dieser
höher gestuft werden können und damit die Dringlichkeit verstärkt. Ist der Status
einer OWA im Status als ”
defekt“ deklariert, wird die Variable Gewinnausfall eingeführt.
Der Gewinnausfall ist definiert als Differenz zwischen dem Erlös und die Kosten. Ist eine
Anlage als ”
defekt“ zu vermelden, dann fällt bis zur Instandsetzung der Gewinn aus.
Es werden keine vergangenheitsbezogenen Berechnungen angestellt, sondern nur für die
jeweilige Tagesplanung bis zum Zeitpunkt der Behebung. Zur Veranschaulichung zeigt
die Abbildung 49: Durchführung von Service-Arbeiten pro Offshore-Windenergieanlage
wie sich die Jobs verteilen könnten.
Anzahl des notwendigen Service-Personals
Je mehr verschiedene Transportmittel und Transportmitteltypen mit unterschiedlichen
Kapazitäten und Höchstgeschwindigkeiten zur Problemlösung genutzt werden sollen, desto
höher ist die Komplexität zur Findung einer Lösung. Darüber hinaus werden sich
auch die Charterkosten erheblich unterscheiden. Für spätere Überlegungen und als optionale
Komponente kann zusätzlich das Gewicht eines Transportmittels bzw. des mitzunehmenden
Werkzeugs zur Wiederherstellung des optimalen Zustands der zu wartenden
OWA.
Die Zuordnung von Jobs zu WEA berücksichtigt, dass auf einer WEA auch mehrere
Service-Aufträge parallel oder zeitversetzt erledigt werden können. Jeder Job macht
jedoch einen unterschiedliche Teamgröße (Mitarbeiteranzahl) erforderlich und notwendigerweise
auch eine gewisse Zeit zur Abarbeitung. Zu bedenken ist, dass pro WEA
mindestens drei Service-Techniker aus HSE-Aspekten an dieser anwesend sein müssen.
Um die Komplexität zu reduzieren wird jeder Auftrag mit mindestens drei Mitarbeitern
oder aber mehr definiert. Des Weiteren gilt, dass maximal neun Personen gleichzeitig
auf einer OWA arbeiten dürfen bzw. können. Dies unterscheidet sich jedoch von OWA
103

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 49: Durchführung von Service-Arbeiten pro OWA (Quelle Eigendarstellung)
zu OWA, wobei momentan eben die größte Anzahl mit maximal neun Mitarbeiter festgelegt
ist. Die Jobs müssen folglich entsprechend abgearbeitet, unter der Restriktion,
dass die minimale und maximale Personenanzahl pro OWA eingehalten werden. Dabei
gibt es zwei generelle Vorgehensweisen: Die Jobs können sequenziell oder parallel abgearbeitet.
Optional sollte betrachtet werden, ob Jobs mit weniger als drei Mitarbeitern
unter den vorangestellten Constraints erledigt werden können, sodass hier ebenfalls die
Personalkosten reduziert werden können.
Zur Abarbeitung von Jobs wird in der Abbildung 50: Gegenüberstellung von parallelisierter
und sequenzieller Jobabarbeitung ein Veranschaulichung des Problems dargestellt.
In der Abbildung sind fünf auszuführende Service-Aufträge aufgeführt. Anhand
der Abbildung wird deutlich, dass bei einer durchgängigen Parallelisierung die maximale
Mitarbeiteranzahl pro OWA mit einer notwendigen Anzahl von 18 Service-Technikern,
womit das Kriterium der maximalen Mitarbeiteranzahl pro Anlage verletzt wird. Sollten
alle Jobs sequenziell abgearbeitet werden, wird hierbei das vorgegebene Zeitfenster mit
einer Stunde überschritten. Folglich muss die Möglichkeit einer beliebigen Kombination
aus paralleler und sequenzieller Abarbeitung zum Ziel führen können. Das heißt, die
Anzahl des Service-Personals soll so gering wie nötig sein und dabei das Zeitfenster eingehalten
werden. In der Abbildung sind die Jobs absteigend nach der Mitarbeiterzahl pro
Auftrag auszuführen. Auch hier ist zu überlegen, ob nicht auch andere Kriterien möglich
wären, wie zum Beispiel die Durchführungszeit. Grundlegend sollte dies entweder zur
Verfügung stehen oder zumindest optional angedacht werden.
In der Abbildung 51: Schematische Darstellung der kombinatorischen Abarbeitung von
Jobs ist ersichtlich, dass die fünf Jobs in zwei sequenzielle Zeilen aufgeteilt wurden. Die
beiden ersten Jobs zum Zeitpunkt t 0 können parallelisiert werden, da dies im Rahmen
der maximalen Personenbelegung einer OWA zugelassen ist. Dementsprechend kann mit
weiteren Jobs verfahren werden, solange diese nicht gegen die Restriktion der mini-
104

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 50: Schematische Gegenüberstellung zur parallelisierten und sequenziellen Abarbeitung
der Jobs (Quelle Eigendarstellung)
malen beziehungsweise maximalen Belegung verstößt. In diesem Fall würde sich somit
die Mitarbeiterzahl auf neun Personen reduzieren und die Arbeitszeit auf sechs Stunden
belaufen. Durch weitere Kombinationen können sowohl bessere als auch schlechtere
Tageseinsatzpläne entstehen. Gewinnausfalljobs werden im Gegensatz zu Wartungsaufträgen
mit höherer Priorität behandelt, wodurch die Reihenfolge sich erheblich verändern
könnte.
Festzuhalten bleibt, dass nur eine sinnvolle Kombinatorik der abzuarbeitenden Jobs
auf einer WEA zum Ziel einer guten bis optimalen Reihenfolge führen kann. Beachtet
werden sollte die Priorität der Jobs und jegliche Constraints. Ist es nicht mögliche eine
sinnvolle Kombination für die Jobs zu finden, müssen entweder die Constraints angepasst
oder der Planer informiert werden, dass die Jobplanung unter diesen Voraussetzungen
nicht lösbar ist.
Reihenfolge der Abarbeitung an den Windenergieanlage
In der vorangegangen Phase wurden die abzuarbeitenden Jobs auf die dazugehörigen
OWA verteilt. Diese heuristische Vorgehensweise sieht dabei jedoch nur die Planung
auf Windenergieanlagenebene vor. Unberücksichtigt bleiben die Transporte zwischen
den einzelnen WEAs. Analog zum oben dargestellten Vorgehen, können die Transporte
parallel und sequenziell durchgeführt werden.
Welche WEA wann angefahren wird, wird von unterschiedlichen Faktoren bestimmt
105

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 51: Schematische Darstellung der kombinatorischen Abarbeitung (sequenziell und
parallel) von Jobs (Quelle Eigendarstellung)
und beeinflusst. Beispielweise werden OWA mit einem Defekt in der Regel vorrangig
behandelt, da dem Gewinnausfall eine höhere Priorität beigemessen wird und aktive
WEAs in der Zeit noch Gewinne hervorbringen. Insgesamt handelt es sich um ein kombinatorisches
Problem, da mehrere Variablen zur gleichen Zeit berücksichtigt werden
müssen.
Zur Problemlösung kann ein Graph herangezogen werden. Jeder Knoten im Graphen
steht synonym für einen OWA, eine Kante stellt den Abstand zwischen zwei Knoten
(WEAs) dar, weshalb diese gewichtet und gerichtet sein sollten. Das auf einer Kante
liegende Gewicht wird durch eine Metrik dargestellt, da ein geographisches Maß oder
der Kostenfaktor nicht die vollständigen Umstände der Kombinatorik mit einbeziehen
können.
In der Abbildung 52: Graph mit ungerichteten und ungewichteten Kanten ist ein
solche ungerichteter und -gewichteter Graph dargestellt. Zur Komplexitätsverminderung
und der Übersichtlichkeit geschuldet, werden nicht alle Kanten abgebildet. Im weiteren
Verlauf ist dieser Graph die Grundlage für die weitere Vorgehensweise und Darstellung.
Die weitere Vorgehensweise baut darauf auf.
Die darauf folgende Abbildung 53: Auswahl eines Knotens und die resultierende Gewichtung
der Kanten zeichnet die Vorgehensweise auf, bei der ein Knoten genau einem
106

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 52: Graph mit ungerichteten und ungewichteten Kanten (Quelle Eigendarstellung)
Zeitpunkt als Quellknoten dient. Darüber hinaus werden auch alle Möglichkeiten ausgehend
von den Kanten zu jedem anderen Knoten hin betrachtet. Des Weiteren werden
die Unterschiede zu einer Metrik als Kantengewicht und einer einzelnen Kennzahl ersichtlich.
Eine geographische Entfernung erzeugt sowohl eine andere als auch mitunter
schlechtere Lösung. Zu Beginn, also dem Zeitpunkt t 0 gibt es noch keine vordefinierte
Distanzmatrix, sodass diese im ersten Durchlauf erzeugt wird. Dadurch wirkt die Route
annähernd dynamisch.
Als initialer Knoten wird die WEA, repräsentiert durch einen Knoten mit dem geringsten
Kantenwert aus dem Gebilde der einzelnen Knoten ausgewählt. Alle Knoten
im Raster ergeben den gesamten OWP. Wie in Abbildung 54: Bestimmung der Nachfolgerknoten
ersichtlich, verläuft die nächste Kante mit der geringsten Gewichtung zum
Knotenpunkt 3. Dieser wird als Nachfolger des Knotenpunktes 1 behandelt.
Der Prozess wird solange durchgeführt bis eines der Constraints erfüllt wird. In diesem
speziell vorgestellten Fall wird der Vorgang beendet, wenn entweder das Zeitfenster oder
die Kapazitätsgrenze des Transportmittels erreicht ist. Grundsätzlich kann sofort mit allen
zur Verfügung stehenden Transportmittel begonnen werden. Dies führt dazu, dass die
Gewinnausfalljobs nach Möglichkeit auf je ein einzelnes Transportmittel aufgeteilt und
abgearbeitet wird. Sobald ein Transportmittel einem Knoten zugeordnet werden konnte,
wird dieser Knoten aus der abzuarbeitenden Job-Liste entfernt. Nachdem der Prozess
beendet werden konnte, erfolgt eine Auswertung des Plans in der Bewertungsfunktion.
107

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 53: Auswahl eines Knotens und die resultierende Gewichtung der Kanten (Quelle
Eigendarstellung)
6.3.3.3 Sequenzielle Abarbeitung mit Clustering
In diesem Ansatz wird eine sequenzielle Abarbeitung durchgeführt, um eine möglichst
optimale Verteilung von Jobs zu erreichen bei minimaler Transportmittelnutzung bzw.
maximaler Transportmittelauslastung unter der Berücksichtigung vom festgelegten Zeitfenster
des Planers.
Ermittlung der Jobkombinationen
Um einen optimierten Plan erstellen zu können, bedarf es zunächst der Ermittlung aller
möglichen Kombinationen von Jobs. Dabei wird beachtet, dass Jobs mit hoher Priorität
zuerst bearbeitet werden, da die betroffenen WEAs hohe Kosten durch ihren weiteren
Stillstand verursachen. Des Weiteren wird die Distanz zwischen den wichtigsten und dem
jeweils nächsten Job beachtet. Zudem werden aus Gründen der Effizienz die Jobs pro
WEA gruppiert.
Ermittlung eines Plans
Um möglichst viele Jobs mit möglichst wenigen Transportmitteln auszuführen, werden
Jobkombinationen geclustert. Das heißt, im Rahmen des vorgegebenen Zeitfensters werden
Gruppen von Jobkombinationen erstellt, die berücksichtigen, dass Jobs mit hoher
Priorität zuerst bearbeitet und die Distanzen beachtet werden. Hierbei werden die
Cluster (oder Jobgruppen), unter Berücksichtigung der Distanz, parallel und sequenziell
ausgeführt. Die Abbildung 55 Aufteilung der Jobkombinationen zeigt, wie die Kombi-
108

6.3 Optimierungskonzepte 6 KONZEPTE
Abb. 54: Bestimmung der Nachfolgerknoten (Quelle Eigendarstellung)
nationen und Cluster erstellt und sortiert werden.
Die genannte Abbildung zeigt rechts eine Menge von Jobs, die gruppiert 35 geclustert
sind. Dabei sind insgesamt sechs Cluster zu erkennen, die parallel als auch sequenziell
geplant werden.
Abb. 55: Aufteilung der Jobkombinationen (Quelle Eigendarstellung)
35 Gruppiert bedeutet in diesem Zusammenhang, dass sie gleichzeitig ausgeführt werden könnten.
109

6.3 Optimierungskonzepte 6 KONZEPTE
Ermittlung des/der Transportmittel(s/n)
Um das passende Transportmittel auszuwählen zu können, werden zunächst alle ungeeigneten
Kombinationen aussortiert. Das heißt, es wird geprüft, wie viele Mitarbeiter
maximal notwendig sind, um alle Servicearbeiten zu bearbeiten. Darauf basierend werden
die Transportmittel oder Transportmittel-Kombinationen gewählt, die die genannte
Bedingung erfüllen. Nachdem die jeweiligen Transportmittel bzw. Transportmittel-
Kombinationen festgelegt wurden, werden die Kosten betrachtet. Die Kosten bestehen
aus fixen und variablen Kosten.
Basierend auf den zusammengefassten Kosten, wird die beste bzw. günstige und effizienteste
Alternative für den Tageseinsatzplan ausgewählt.
Verteilung der Jobs auf den Transportmitteln
Nachdem die Cluster gebildet und die entsprechenden Transportmittel bzw. -kombinationen
ausgewählt wurden, werden die Jobcluster auf die Transportmittel verteilt. Dies
bedeutet jedoch nicht, dass pro Cluster ein Transportmittel geplant werden, denn es ist
möglich, dass es günstiger ist, mehrere Cluster auf nur ein Transportmittel zu verteilen.
In dieser Schritt wird der Plan noch einmal angepasst und optimiert. Die Anpassung
ist notwendig, da in den vorherigen Schritten keine Transport-, Anweisungs- und Ausstiegszeiten
berücksichtigt wurden. Durch die Anpassung und Optimierung werden die
Jobanfangs- und -endzeiten festgelegt.
In der Abbildung 56 Aufteilung der Jobkombinationen kann erkannt werden, dass
für die vorhandenen Jobs in der entsprechenden Arbeitszeit eine Kombination von zwei
Schiffen (rot = ”
Gode Wind“ und blau = ”
WindForce II“) gewählt wurde. Es ist auch
erkennbar, dass die Anzahl der Cluster sich reduziert haben, da die Auswahl der Transportmittel
eine bessere Optimierung ermöglicht.
6.3.4 Bewertung der Pläne
Die aus den drei Ansätzen hervorgebrachten Tageseinsatzpläne müssen in letzter Instanz
bewertet werden. Die Bewertungsfunktion beinhaltet das Vergleichen einzelner
Pläne untereinander, sodass der beste ermittelte Plan an die Simulation zur Verarbeitung
weitergegeben werden kann.
Die Bewertungsfunktion der Optimierung teilt sich in drei Phasen auf:
Teilbereich A ist zur Berechnung der Schiffskosten bestehend aus den Charterkosten
und den Treibstoffkosten zuständig. Um letzteres ermitteln zu können, muss die Zeit
berechnet werden, die das Transportmittel zur theoretischen Ausführung (ohne Wettereinflüsse)
des Plans benötigt. Diese wird dann zuerst mit dem Treibstoffverbrauch
und danach mit dem Treibstoffpreis verrechnet. Zum Schluss werden die Kosten aller
Transportmittel aufsummiert.
Der zweite Teil, Teilbereich B bezieht sich auf den Gewinnausfall einer oder mehrerer
OWA. Der Gewinnausfall einer WEA besteht generell vom Startzeitpunkt bis zum
Zeitpunkt an dem jegliches Service-Personal die jeweilige WEA verlassen haben und
selbstredend diese wieder in Stand gesetzt haben. Bei OWAs mit einem ”
aktiven“ Sta-
110

6.4 Simulationskonzept 6 KONZEPTE
Abb. 56: Aufteilung der Jobkombinationen (Quelle Eigendarstellung)
tus gilt der Gewinnausfall ab dem Zeitpunkt des Abschaltens der WEA, in der Regel ab
dem Zeitpunkt des Andockvorgangs, bis zum Beenden des Abholvorgangs. Beide Zeiten
werden jeweils mit der festgelegten Vergütung verrechnet und dann aufsummiert.
Im letzten Teil C fließen die Personalkosten ein. Hier wird die Zeit vom Start des Transportmittels
ab einem Hafen bis zur Rückkehr zum Starthafen angerechnet. Entsprechend
mit der Personenanzahl des Transportmittels und anschließend mit dem Gehalt multipliziert,
wobei letzteres zur Vereinfachung für alle gleichermaßen ist. Zum Schluss werden
die Personalkosten für alle Transportmittel aufsummiert.
Am Ende sind die Gesamtkosten für den Tageseinsatzplan gegeben und dieser kann
dann entsprechend mit weiteren Plänen verglichen werden.
6.4 Simulationskonzept
Das Konzept der Simulation zur Umsetzung des zu entwickelnden Werkzeugs zur Planung
von Tageseinsätzen in OWPs wird in diesem Abschnitt beschrieben. Zu Beginn
wird der Grundgedanke, wie die Simulation ablaufen könnte, dargestellt. Anhand dieser
Idee wird das Konzept entwickelt und graphisch aufbereitet.
6.4.1 Die Idee - Ablaufplan
Generell ist die Überlegung die Simulation in drei Phasen einzuteilen. In der ersten Phase
soll die zur Durchführung eines Einsatzplans benötigte Simulationsumgebung mitsamt
aller Akteure erzeugt werden. Darauf folgend sollen die gesammelten Daten der Simulationsumgebung
und des Plans in der zweiten Phase überführt und die Simulation gestartet
werden. Nach Abschluss der Simulation erfolgt in der dritten Phase die Aufbereitung der
Simulationsergebnisse und eine abschließende Bewertung des Plans.
111

6.4 Simulationskonzept 6 KONZEPTE
Abb. 57: Dieses Sequenzdiagramm beschreibt den Kommunikationsablauf zwischen den
Agenten während der Durchführung eines Simulationslaufs (Quelle: Eigendarstellung
112

6.4 Simulationskonzept 6 KONZEPTE
6.4.2 Akteure der Simulation
Die Simulation basiert auf der Anwendung von recht autonom agierenden Akteuren. Diese
Akteure verständigen sich, um sowohl ihre Zustände als auch der anderen zu erfahren.
Dies erleichtert die Simulation zu visualisieren, da jeder Akteur weiß was er macht, wo
er sich aufhält und wie sein Zustand ist. Zum anderen kann festgestellt werden, welchen
Einfluss zum Beispiel das Wetter auf einen Akteur hat oder wann äußere Einflüsse den
Zustand eines Akteurs verändern. Die Umgebung und dessen Akteure sind folgendermaßen
angedacht:
• Simulation:
Stellt die Einsatzumgebung der Simulation dar, worüber jegliche weitere Akteure
agieren
• ControlStation:
Organisiert die nachfolgenden Akteure, bearbeitet deren Nachrichten und sorgt für
das anstoßen der Visualisierung. Die ControlStation muss ein Akteur sein, damit
diese nicht nur Nachrichten schicken kann, sondern auch eingehende Nachrichten
verarbeiten kann
• MaintenanceShip:
Hierbei handelt es sich um Akteure auf dem Wasser und vertreten damit die verschiedenen
Schiffstypen
• TransportHelicopter:
Hierbei handelt es sich um Akteure der Luft, die unter dem Begriff der Helikopter
zusammengefasst werden
• Windenergieanlagen (WEA:)
Die einzelnen WEAs sollen ebenfalls von jeweils einem Akteur vertreten sein, die
den Zustand über sich wiedergeben können, das Andocken verzeichnen und anhand
der Dauer von Jobs Informationen über die Kosten liefern kann
• MapPanel:
Die MapPanel beinhaltet die visuelle Darstellung der einzelnen Akteure auf einer
Karte.
6.4.3 Beschreibung
Die Abbildung 57: Kommunikationsablauf der Simulation stellt die Kommunikation zwischen
den Akteuren dar. Neben einer Instanz der Klasse Simulation ist am Ablauf des
Simulationsablaufs eine ControlStation, eine endliche Menge an MaintenanceShip- und
TranportHelicopter-Akteuren und ein MapPanel-Objekt beteiligt.
113

6.5 Schnittstellenplan 6 KONZEPTE
Bevor ein Einsatzplan simuliert werden kann, muss ein zugehöriges Simulation-Objekt
erzeugt werden. Diese initiiert wiederum die Simulationsumgebung, indem sie eine ControlStation
und die zur Durchführung benötigten MaintenanceShip- und TransportHelicopter-Akteure
startet. Anschließend folgt die erste Phase der Simulation.
In dieser soll sichergestellt werden, dass alle Akteure vollständig erzeugt und für den
Nachrichtenaustausch bereit sind. Hierzu sendet die Simulation einen StatusRequest an
die ControlStation. Diese leitet die Anfrage an die anderen Akteure weiter und wartet,
bis sie von jedem einen StatusResponse erhalten hat. Ist dies der Fall meldet sich die
ControlStation ebenfalls mit einer StatusResponse bei der Simulation zurück. Diese ruft
wiederum ihre private start()-Methode auf und wechselt in die reelle Simulationsphase.
Die zweite Phase beginnt mittels des Versendens einer StartRequest-Nachricht an die
ControlStation. Diese sendet nun kontinuierlich PositionRequest-Anfragen an die anderen
Agenten und wartet auf deren Antworten. Ein Akteur, z.B. ein MaintenanceShip,
berechnet nun seine aktuelle Position anhand der in der Anfrage enthaltenen Zeit, seiner
Geschwindigkeit und dem aktuellen Wetter und schickt diese als Antwort in einer
PositionResponse zurück. Zudem speichert er wichtige Ereignisse in der hierfür vorgesehenen
Liste. Die Controlstation verarbeitet die Antworten und speichert die Positionen
in einer Liste. Sind alle Antworten ausgewertet, wird die repaint()-Methode des MapPanel-Objekts
aufgerufen, wodurch die Visualisierung des Simulationsfortschritts verändert
wird. Anschließend schickt die ControlStation ein NextIntervalRequest an sich selbst, um
eine neue Positionsbestimmung anzustoßen. Dieser Vorgang wiederholt sich so lange,
bis das Limit der Simulationszeit (gegeben durch die max. Arbeitszeit pro Tag + eine
Toleranz) erreicht wurde oder jeder Akteur durch eine FinishedSimulation-Nachricht signalisiert
hat, dass er alle seine Aufgaben erledigt hat. In beiden Fällen meldet sich die
ControlStation mit einer FinishedSimulation-Nachritcht bei der Simulation zurück, die
durch Aufruf der Methode evaluate() die abschließende Phase, die Evaluation beginnt.
In der Evaluation soll der Simulationsablauf aus der vorangegangenen Phase analysiert
und bewertet werden. Hierzu wird ein EvaluationRequest an die ControlStation
verschickt, die dann an die weiteren Akteure weitergeleitet wird. Die EvaluationResponse
der Akteure enthält die Liste der Simulationsereignisse, die zusammengefasst an das
Simulations-Objekt weitergegeben werden. Diese wertet die Ereignisse unter Berücksichtigung
des Ausgangsplans aus und gibt die wichtigsten Erkenntnisse an den Nutzer
zurück. Die Bewertung des Plans wird zwar indirekt, aber entsprechend zwangsläufig in
der Optimierung schon durchgeführt. Jedoch mittels der Simulation konkretisiert, sodass
diese eine detailliertere Auswertung zurückliefern kann.
6.5 Schnittstellenplan
Die einzelnen Konzepte bzw. Module sind vorangegangen beschrieben und zum Teil
graphisch dargestellt worden. In diesem Abschnitt ist zu den Konzepten ein Schnittstellenplan
erarbeitet worden, um sowohl die Eingabe- als auch Ausgabeparameter zu
definieren und im weiteren Verlauf des Projektes nachvollziehen zu können. Außerdem
können darüber hinaus Gruppen sich besser verständigen, da die Informationen allen
offen vorliegen und einsehbar sind und über die gleichen Inhalte gesprochen werden
114

6.5 Schnittstellenplan 6 KONZEPTE
Abb. 58: Darstellung der einzelnen Module in diesem Projekt (Quelle Eigendarstellung)
kann. Zusätzlich macht ein Schnittstellenplan die Arbeit an einem bestimmten Modul
einfacher, da klar ist, welche Daten als Input zur Verfügung stehen und welcher Output
vorausgesetzt wird.
Auf interaktiver und technischer Ebene müssen der Anwender mit dem Programm
sowie auch die einzelnen Module untereinander Daten austauschen können, um ein sinnvolles
Ergebnis zurückliefern zu können. Dies bedeutet beispielsweise, dass nicht in einem
Fall ein Wahrheitswert weitergegeben wird, sondern die geforderte Geschwindigkeit eines
Transportmittels.
Der grundsätzliche Ablaufprozess einer Tageseinsatzplanung ist in der Abbildung 58
Darstellung der einzelnen Module in diesem Projekt dargestellt. Ersichtlich sind hierbei
sowohl die vor- als auch die nachgelagerten Module des Ablaufprozesses.
6.5.1 GUI als Schnittstelle
Die GUI stellt generell die Schnittstelle zwischen dem Benutzer des Programms und dem
Programm selbst bereit. Dieser kann zum Beispiel die weniger dynamischen Variablen
im sogenannte Stammdatenmenü (Edit Master Data) eintragen, die dann in die Datenbank
übertragen werden. In der Regel sind dies Informationen, die sich nicht jeden Tag
ändern und trotzdem in gewissen Abständen angepasst werden müssen. Es ist erfolgt
in erster Instanz eine wirkliche Interaktion, wenn der Benutzer eine Tageseinsatzplanung
vornimmt. Die Abbildung 59 Allgemeine Benutzerinteraktion mit dem Scheduling
verdeutlicht den Prozessschritt.
Auch führt der Benutzer bestimmte Interaktionen mit dem Programm aus. Das kann
zum Beispiel die Anpassung der Simualtionsgeschwindigkeit (Change speed). Vergleiche
hierzu die Abbildung 60: Darstellung der graphischen Benutzerschnittstelle des Simulation
controls. Wie im Kapitel 6.1 GUI-Konzept beschrieben, bestehen die Ansichten aus
vier Hauptkomponenten und einigen Dialogen.
Weitere interaktive Schnittstellen bietet:
• Menü in allen Views:
115

6.5 Schnittstellenplan 6 KONZEPTE
Abb. 59: Allgemeine Benutzerinteraktion mit dem Scheduling (Quelle Eigendarstellung)
Abb. 60: Darstellung der graphischen Benutzerschnittstelle des Simulation controls
(Quelle Eigendarstellung)
Durchführung der Tageseinsatzplanung; Auswahl einer bestimmten Koordinate;
Verlassen des Programms; Einträge von Transportmittel, Windenergieanlagen, Hafen,
Job und Windenergiepark in die Datenbank; ändern der Stammdaten; Ansichtsoptionen
der Kartendarstellung
• Steuereinheiten auf dem Startbildschirm bzw. der Simulationsansicht:
Elemente der Simulationskontrolle (Fortsetzen, Anhalten, Stoppen, Simulationsgeschwindigkeit);
Elemente der Kartensteuerung (Verschiebung des Kartenausschnitts
mittels der Pfeilbuttons, Zoom)
• Auflistung der Transportmittel auf dem Startbildschirm bzw. der Simulationsansicht:
Darstellung der zur Verfügung stehenden Transportmittel
• Buttons für die Ausführung auf der Planungsebene:
Hier wird ein Dialog zur Bestimmung des Arbeitszeitfensters, zum Starten des
Optimierungsvorgangs und Abbruch der Planungsprozesses.
• Spalten zur Auswahl des Transportmittel, geplante Jobs und zu erfüllende
Jobs:
Die erste Spalte stellt die Transportmittel zur Verfügung. In der zweiten Spalte
können per Drag & Drop die zu planenden Jobs aus der zu erfüllenden Jobs gezogen
werden.
116

6.5 Schnittstellenplan 6 KONZEPTE
Die GUI versteht sich im Allgemeinen als die Schnittstelle zum Benutzer. Dieser soll interaktiv
und intuitiv die Steuerung des Programmes nachvollziehen und benutzen können
ohne größere Erklärungen. Dadurch soll die Tageseinsatzplanung deutlich einfacher gestaltet
werden können und Lösungen gefunden werden, die effizienter und/oder Kosten
minimierend sind.
Natürlich erfolgen auch noch weitere Aktionen vom Benutzer, z.B. während der Simulation
oder bei der Ergebnisauswertung. Die GUI hat generell daher eine besondere
Stellung im Gegensatz zu den rein technisch untereinander kooperierenden Modulen.
6.5.2 Datenübermittlung
Die Datenübertragung wird wie folgt definiert und muss unbedingt von allen Modulen
beachtet und eingehalten:
In erster Instanz ist es ein REST 36 -Service. Das bedeutet, dass die Optimierung auf
Serverseite (dem Tomcat in diesem Fall) läuft und zur Bereitstellung von Services dient.
Bei der Implementierung des Services ist zu berücksichtigen, dass es sich um konsumierende
Webservices handelt und deshalb die Annotationen @PUT und @Consumes
Anwendung finden. Als MediaType sollte MediaType.APPLICATION JSON zum Einsatz
kommen.
Darüber hinaus gilt, dass der Service bei korrekter Übermittlung der Daten eine Rückmeldung
(Request) bekommt und dadurch die Bestätigung erhält.
6.5.2.1 Zeichensatz
Als Zeichensatz ist UTF-8 zu verwenden. Der Zeichensatz sollte explizit gesetzt werden,
z.B. mit response.setCharacterEncoding(UTF-8).
6.5.2.2 Regelungen für die Datenübermittlung
Es sind stets die folgenden Daten zu übergeben, auch wenn diese gegebenenfalls leer
beziehungsweise nicht initialisiert sind:
Für das Scheduling gilt:
1. Liste aller Jobs
2. Liste der zur Verfügung stehenden Transportmittel
Für die Optimierung gilt:
36 REST: Ein Architekturstil ist eine Reihe von Einschränkungen, die beim Erstellen angewendet
werden können. Mit einem Softwarearchitekturstil werden die Features beschrieben, mit denen
eine Anleitung für die Implementierung eines Softwaresystems bereitgestellt werden kann.
REST ist ein Architekturstil, mit dem Software erstellt werden kann, in der Clients (Benutzer-
Agents) Anforderungen von Diensten (Endpunkten) durchführen können. REST ist eine Möglichkeit,
einen Client-Server-Architekturstil zu implementieren. Es baut sogar ausdrücklich auf diesem Stil
auf. Jon Flanders - Eine Einführung in REST-Dienste mit WCF, http://msdn.microsoft.com/dede/magazine/dd315413.aspx,
aufgerufen am 22.09.2013
117

6.5 Schnittstellenplan 6 KONZEPTE
1. Liste der geplanten Jobs
2. Liste der zur Verfügung stehenden Transportmittel
3. Das TimeWindow (Zeitfenster)
Für die Simulation gilt:
1. Ermittelten optimalen Tageseinsatzplan der Optimierung mit den Jobs und Transportmitteln
2. Das TimeWindow (Zeitfenster)
Eine Übergabe gilt als erfolgreich, wenn der Server mit dem booleschen Wert ”
true“
antwortet oder als gescheitert, wenn der Server mit ”
false“ antwortet. Zu beachten ist,
dass in der aufgelisteten Reihenfolge die Daten übermittelt werden sollen/müssen.
6.5.2.3 Zu nutzende Datentypen
Im Anschluss sind die Datenformate für die Datenfelder festgelegt:
String(n) - Zeichenkette mit n Zeichen (max. Integer.MAX VALUE)
Integer - Ganze Zahlen im Bereich von -2.147.483.648 bis 2.147.483.647
Long - Ganze Zahlen von -9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807
Double - Gleitkommazahlen im Bereich von 2-1074 bis (2-2-52)·21023
Double - Gleitkommazahlen mit kaufmännischer Rundung auf 2 Nachkommastellen
Date - tt.mm.jjjj (z.B. 15.08.2013)
Time - hh:mm (z.B. 14:25)
Boolean - false/true
In der Tabelle 5 Datenfelder eines Jobs sind die Datenfelder, Datentypen und Werte
bzw. Hinweise für die Jobs beschrieben, an denen sich orientiert und gehalten werden
muss.
Die nächste Tabelle 6 Datenfelder eines Transportmittels beschreibt die Datenfelder,
Datentypen und Werte bzw. Hinweise für die Transportmittel, wie diese in der Datenbanktabelle
gespeichert sind.
Die Tabelle 7 Datenfelder des Zeitfensters beschreibt die Datenfelder, Datentypen und
Werte bzw. Hinweise für das Zeitfenster des Arbeitstages.
118

6.5 Schnittstellenplan 6 KONZEPTE
Datentyp Datenfeld Wert bzw. Hinweis
Long id Primärschlüssel für die eindeutige Identifikation
eines Jobdatensatzes in der Datenbank mit
Annotation @ID
String name Nicht genauer spezifiziert (frei wählbar entsprechend
dem UTF-8“-Zeichensatz)
”
String description Nicht genauer spezifiziert (frei wählbar entsprechend
dem UTF-8“-Zeichensatz)
”
int priority 0 = High, 1 = Normal, 2 = Low
int duration Die Dauer der Ausführung in Minuten
int status 1 = offen, 2 = In Bearbeitung, 3 = Geschlossen
Date earliestStartExecDate Früheste Anfangszeit (FAZ)
Date latestStartExecDate Späteste Anfangszeit (SAZ)
int staffNum Anzahl an Personal
Windmill windmill Die WEA an welcher der Job durchzuführen
ist, wird als Objekt übergeben
Tbl. 5: Datenfelder eines Jobs
In der nachfolgenden Tabelle 8 Datenfelder einer OWA werden die Datenfelder, Datentypen
und Werte bzw. Hinweise für eine OWA beschrieben. Diese Daten werden zur
Erfüllung eines Jobs benötigt.
Abschließend sind die Datentypen, Datenfelder und Werte bzw. Hinweise vom Hafen
in der Tabelle 9 Datenfelder zum Anlegen von Häfen zu entnehmen. Die Daten eines
Hafens sind zur Festlegung des Starthafens für jeweils ein bestimmtes Transportmittels
angedacht.
Die Positionsdaten zur Bestimmung der Lage von geographischen Objekten, wie dem
Hafen, eines Transportmittels, einer OWA oder eines OWPs werden in der Tabelle 10
Datenfelder zur Positionsbestimmung dargestellt.
In der nachstehenden Tabelle 11 Datenfelder von Offshore-Windenergieparks sind die
Entitäten für einen OWP enthalten.
Die aufgeführten Tabellen bilden nun die notwendigen Datenfelder der verschiedene
Bereiche ab, sodass anhand dieser deutlich ist, wer welche Daten in welcher Form zur
Verfügung gestellt bekommt.
119

6.5 Schnittstellenplan 6 KONZEPTE
Datentyp Datenfeld Wert bzw. Hinweis
Long id Ein Primärschlüssel für die eindeutige Identifikation
eines Transportmitteldatensatzes in der Datenbank
mit Annotation @ID
int type 0 = Schiff, 1 = Helikopter
Port port Start- und Zielhafen des Transportmittels wird als
Objekt übergeben
double maxSpeed Höchstgeschwindigkeit in Knoten
int maxCapacity Die maximale Anzahl des zu transportierenden
Fachpersonal (Service-Techniker)
String name Nicht genauer spezifiziert (frei wählbar entsprechend
dem UTF-8“-Zeichensatz)
”
double charterCosts Fixe Kosten für eine Tagescharter des Transportmittels
double fuelConsumption Der Verbrauch bei maximaler Geschwindigkeit
Tbl. 6: Datenfelder eines Transportmittels
Datentyp Datenfeld Wert bzw. Hinweis
int startTime Zeitpunkt in Minuten des Tages ab Arbeitsbeginn/Beginn
des Zeitfensters
int endTime Zeitpunkt in Minuten des Tages bis Arbeitstagende/Ende
des Zeitfensters
Tbl. 7: Datenfelder des Zeitfensters
6.5.3 Schnittstelle zwischen dem Scheduling und der Optimierung
In diesem Kapitel wird spezifiziert, welche Daten vom Scheduling an die Optimierung
übermittelt werden. Die Parameter des Scheduling bezieht sich insbesondere auf die
vorherigen Eingaben des Benutzers und dessen Eingaben. Innerhalb der Scheduling-
View muss darauf geachtet werden, dass die Eingaben nicht willkürlich sind, sondern
bestimmte Voraussetzungen erfüllen.
Die in diesem Abschnitt betrachtete Schnittstelle verbindet die Module Scheduling
und Optimierung über eine Netzwerkschnittstelle (Server/Client). Eingesetzt wird JAX-
RS, Tomcat-Server und der Aufruf über den MIME-Typen JSON. Die Schnittstelle ist
120

6.5 Schnittstellenplan 6 KONZEPTE
Datentyp Datenfeld Wert bzw. Hinweis
Long id Ein Primärschlüssel für die eindeutige Identifikation eine
WEA in der Datenbank mit Annotation @ID
Position position Information zur geographischen Lagebestimmung
Windfarm windfarm Zuordnung der OWA zu einem OWP
String name Nicht genauer spezifiziert (frei wählbar entsprechend dem
” UTF-8“-Zeichensatz)
int perfomance Leistung in kW
boolean status Zustandsausgabe, ob eine eine OWA in Betrieb ist oder
abgeschaltet
Tbl. 8: Datenfelder einer OWA
Datentyp Datenfeld Wert bzw. Hinweis
Long id Ein Primärschlüssel für die eindeutige Identifikation eines
Hafens in der Datenbank mit Annotation @ID
Position position Information zur geographischen Lagebestimmung
List route Information zur geographischen Bestimmung des Tonnenstrichs
String name Nicht genauer spezifiziert (frei wählbar entsprechend
dem UTF-8“-Zeichensatz)
”
int regionSpeed Vorgegebene Geschwindigkeitsbeschränkung im Hafen
Tbl. 9: Datenfelder zum Anlegen von Häfen
in der folgenden Abbildung 61 Planungsprozess vom Scheduling bis zur Optimierung
ersichtlich.
An die Optimierung müssen vom Scheduling folgende Daten übermittelt und von dieser
verarbeitet werden können.
• Job:
Unter Jobs werden alle Daten zu allen Servicearbeiten erfasst, die eben zur Abwicklung
von einem oder mehreren Serviceaufträgen notwendig sind. Ein Job enthält
eben die Job-Bezeichnung, -Beschreibung, -Priorität und -Dauer. Außerdem das
121

6.5 Schnittstellenplan 6 KONZEPTE
Datentyp Datenfeld Wert bzw. Hinweis
double latitude Positionsbreitengrad
double latitude Positionslängengrad
Tbl. 10: Datenfelder zur Positionsbestimmung
Datentyp Datenfeld Wert bzw. Hinweis
Long id Ein Primärschlüssel für die eindeutige Identifikation eines
Windenergieparks in der Datenbank mit Annotation
@ID
Position position Daten zur geographischen Lagebestimmung des OWPs
String name Nicht genauer spezifiziert (frei wählbar entsprechend
dem UTF-8“-Zeichensatz)
”
int regionSpeed Vorhandene Geschwindigkeitsbeschränkung im OWP
Tbl. 11: Datenfelder von Offshore-Windenergieparks
Abb. 61: Planungsprozess vom Scheduling zur Optimierung (Quelle Eigendarstellung)
frühestes Anfangsdatum und den spätesten Ausführungszeitpunkt zur Abwicklung
des Jobs sowie die benötigte Anzahl an Fachkräften. Abschließend die logische Zuweisung
zu der jeweiligen OWA. Die Optimierung bekommt die gesamte Job-Liste
der geplanten Servicearbeiten für den angedachten Tag übergeben.
Sollte es zeitlich möglich sein, wird eine sinnvolle Umsetzung für erfüllte Jobs
hinterlegt. Hierbei gibt es die Schwierigkeit, dass ein geplanter Serviceauftrag nicht
122

6.5 Schnittstellenplan 6 KONZEPTE
unbedingt abgearbeitet wurde. Zum Beispiel auf Grund der Tatsache, dass die
Wetterverhältnisse dies nicht zulassen. Vorerst wird deshlab vom Benutzer der
Software verlangt, dass dieser Einsicht in die vollständige Planung hat und erfüllte
Aufträge selbstständig entfernt bzw. bei nicht Umsetzung der Tagesplanung diesen
wieder der Job-Liste hinzufügt.
• TimeWindow:
Das ”
TimeWindow“ (deutschsprachig: Zeitfenster) entspricht den am zu planenden
Arbeitstag zur Verfügung stehende Arbeitszeitraum. Dieser beinhaltet zum einen
die Anfahrtszeit zum OWP als auch zurück, die Übersteigezeiten vom Transportmittel
auf eine WEA und zurück, die Intraparklogistik sowie die reine Arbeitszeit
der Servicearbeiten.
• Vehicle:
In der Regel gibt es verschiedene Transportmittel und -typen, von denen allerdings
immer gewisse Daten zur Verfügung stehen müssen. Ein Transportmittel
wird mit einer Bezeichnung versehen, der Namenskennung. Des Weiteren ist die
Höchstgeschwindigkeit interessant, da anhand dieser die Kosten- und Zeitersparnis
berechnet wird. Ebenfalls muss die mögliche Anzahl der zu transportierenden Fachkräfte
pro Transportmitteln bekannt sein. Diese ist sehr stark von dem jeweiligen
Transportmitteltyp abhängig. Zur Kostenermittlung sind die Verbrauchsmengen
an Kraftstoff und die Charterkosten von Bedeutung. Unterschieden wird auch das
Transportmittel anhand des Typs, wobei generell nur Schiffe und Helikopter infrage
kommen. Der Zuordnung wegen wird ein fester Heimathafen angenommen.
Wie beim Job auch, wird der Optimierung eine Liste der zur Verfügung stehenden
Transportmittel übergeben.
• WindTurbine:
Eine OWA hat einen Standort und ist über eine Position (Lat/Long) aufzufinden.
Zu jeder WEA muss darüber hinaus die maximale Leistung zur Energieerzeugung
der Anlage bekannt sein. Angegeben wird die maximale Leistung in Kilowatt
(kW). Hinzukommt der Status (aktiv bzw. inaktiv = Wartungszustand, WEA
vom Stromnetz genommen oder defekt). Notwendigerweise müssen auch betriebswirtschaftliche
Daten pro OWA für die Bewertung der Optimierung herangezogen
werden. Diese sind durch die Betriebskosten von Euro pro Kilowattstunde (kWh),
der zu erwartende Erlös in Euro pro kWh und die eingesetzten Investitionen von
Millionen Euro pro kW. Diese bilden die Grundlage für den Gewinnausfall, der
von der Optimierung besonders berücksichtigt werden soll. Außerdem muss der
Optimierung bekannt sein, zu welchen Zeiten sich wie viele Fachkräfte auf einer
WEA aufhalten, damit diese weder unterbesetzt noch überbesetzt wird.
123

6.5 Schnittstellenplan 6 KONZEPTE
6.5.4 Schnittstelle zwischen der Optimierung und Simulation
Die Optimierung verschickt an die Simulation einen guten, möglichst optimalen Plan,
der anhand der Bewertungsfunktion der Optimierung ermittelt werden konnte (vergleiche
die Abbildung 62 Planungsprozess zwischen dem Scheduling und der Optimierung. Wenn
der Fall eintreten sollte, dass gar kein Plan erzeugt werden konnte, wird abgebrochen. Es
muss dann jedoch eine Meldung an den Planer zurückgegeben werden, weshalb denn kein
Plan an die Simulation übergeben werden konnte. Nachfolgende wird beschrieben, welche
Informationen beziehungsweise Daten von der Optimierung der Simulation bereitgestellt
werden müssen:
Abb. 62: Planungsprozess zwischen dem Scheduling und der Optimierung (Quelle Eigendarstellung)
• Transportmittel-Liste:
Die in der Optimierung verwendeten und zuvor selektierten Transportmittel, sowohl
die Schiffe als auch Helikopter, sind Bestandteil der zu simulierenden Akteure
• Job-Liste:
Jegliche in der Optimierung zugeteilten und geplanten Jobs werden gesammelt in
einer Job-Liste weitergegeben. Diese Jobs sind auf den Transportmitteln verteilt
und werden mit einem Start- als auch Endezeitpunkt versehen.
Der erzeugte Plan wird in Form einer Map übergeben.
Ein PlannedVehicle ist ein Transportmittel, dass um die Anzahl der Arbeitskräfte
erweitert wurde, die zum Ausführen der Jobs an den Anlagen benötigt werden. Die Map
weißt jedem PlannedVehicle eine Liste von PlannedJobs zu. Diese ist eine Erweiterung
der Job-Klasse und enthält zum einen die Zeit, an der ein Schiff an einer OWA andocken
soll, um das Personal für einen Job abzusetzen und zum anderen die Andockzeit für das
Abholen des Personals.
Die Simulation bekommt insgesamt drei Parameter als Eingabe. Der erste Parameter
ist die oben beschriebene Map, die den Ablaufplan vorgibt. Zusätzlich bekommt sie eine
124

6.5 Schnittstellenplan 6 KONZEPTE
Zeit (Datentyp: int) in Minuten, die angibt, wie lange die Simulation laufen soll bis ein
Abbruch erfolgt. Der dritte Parameter ist dann das MapPanel (die Karte), auf dem die
Akteure gezeichnet werden. Während der Simulation werden dann zusätzlich folgende
Werte beachtet:
• Simulationsgeschwindigkeit:
Diese lässt sich in der MapView ändern (zum Beispiel 1:60 bedeutet in einer realen
Sekunde vergehen 60 Simulationssekunden). Eine Änderung der Geschwindigkeit
wird immer dann von der Simulation beachtet, wenn das aktuelle Intervall aus PositionRequest
und -Response beendet wurde und das nächste Intervall angestoßen
wird.
• DockingTime:
Die Zeit, die ein Schiff zum Andocken an eine WEA braucht (Datentyp: int (in
Minuten)). Die DockingTime setzt sich aus der Briefingzeit (BriefingTime) und
der Übersteigezeit (AboardTime) zusammen, die der Nutzer in den Stammdaten
(Masterdata) ändern kann.
• OpenSeaSpeedRatio:
Der Prozentsatz der Geschwindigkeit, die ein Schiff auf offener See fährt. Der Wertebereich
liegt zwischen 0,00 (0%) und 1,00 (100%).
Nachdem die Simulation des Plan durchlaufen wurde, beginnt die Evaluation der Simulationsergebnisse.
Hierbei werden folgende Daten aus den Stammdaten ausgelesen:
• fuelCostShip:
Die Kosten, die für den Treibstoffverbrauch eines Schiffes anfallen. (Angabe in
Euro pro Liter)
• fuelCostHeli:
Die Kosten, die für den Treibstoffverbrauch eines Helikopters anfallen. (Angabe in
Euro pro Liter)
• staffCostPerHour:
Die Kosten, die für eine Arbeitskraft pro Stunde anfallen. (Angabe in Euro pro
Stunde)
• feedInCompensation:
Die Vergütung, die eine OWA durch Einspeisung von erzeugtem Strom in das Netz
verursacht“ (Angabe in Euro pro kWh)
”
125

6.5 Schnittstellenplan 6 KONZEPTE
6.5.5 Schnittstelle zwischen der Simulation und Evaluation
Das letzte Modul auf technischer Kommunikationsebene zwischen den Modulen wird
durch die von der Simulation zur Evaluation realisierten Schnittstelle repräsentiert. Die
EvaluationView ist allerdings deutlich enger mit der Simulation verbunden als die anderen
technischen Module untereinander. Die Abbildung 63 Übergabe des Plans von der
Optimierung zur Simulation visualisiert den nächsten Prozessschritt.
Abb. 63: Übergabe des möglichst optimalen Plans von der Optimierung zur Simulation
(Quelle Eigendarstellung)
Das Resultat der Evaluation bildet die Mapund List,
die den aktualisierten Plan enthält (es werden die von der Simulation berechneten Zeitpunkte
für die Andockmanöver in die Jobs eingetragen), eine Map, die die Kosten für jedes Transportmittel beinhaltet (Charterkosten + Treibstoffkosten
+ Personalkosten) und eine Map, die die Kosten für
jede WEA bereitstellt.
Diese Daten werden dann an die EvaluationsView übergeben, die diese in entsprechender
Form textuell und grafisch darstellt. Die beiden Listen für die Kosten der Akteure
werden in einer Tabelle aufgeführt, die in der ersten Spalte den Namen und in der zweiten
Spalte die Kosten in Euro enthält. Am Ende der Tabelle werden dann die Gesamtkosten
angezeigt. Die grafische Darstellung findet in 7 verschiedenen Diagrammen statt (siehe
auch Anhang):
JOB PLAN: Optimierter Plan
PERSONS WORKING: Umgerechnet Arbeitsstunden der Mitarbeiter
STAFF PER MILL: Mitarbeiter pro OWA (Summe als Zahl)
STAFF PER WINDPARK: Mitarbeiter pro OWP (Summe als Zahl)
WORK PER GROUP: Umgerechnet die Arbeitsstunden pro Transportmittel (Summe
als Zahl für alle Jobs * Mitarbeiter pro Job)
126

6.5 Schnittstellenplan 6 KONZEPTE
WORK PER WINDMILL: Umgerechnet Arbeitsstunden pro WEA (Summe als Zahl
für alle Jobs * Mitarbeiter pro Job)
WORK PER WINDPARK: Umgerechnet Arbeitsstunden pro OWA (Summe als Zahl
für alle Jobs * Mitarbeiter pro Job)
Der letzte logische Schritt ist dann wieder die Rückmeldung für den Benutzer, in dieser
Anwendung also dem Planer. Zum einen sind es die oben aufgeführten Informationen,
aber die essentiell wichtigste Rückmeldung ist, ob ein guter Plan zustande gekommen
ist. Der Planer kann dann entsprechend reagieren. Das Kapitel wird mit der Abbildung
64 Ausgabe der Evaluationsparameter für den Benutzer als letzten Prozessschritt abgeschlossen
bevor es wieder von Neuem beginnen kann.
Abb. 64: Ausgabe der Evaluationsparameter für den Benutzer, um einen guten Tageseinsatzplan
zu finden(Quelle Eigendarstellung)
127

7 BESCHREIBUNG DER SOFTWARE SCOWS
7 Beschreibung der Software SCOWS
In diesem Kapitel wird der entwickelte Prototyp der PG-SCOWS umfänglich und detailliert
beschrieben.
Dabei wird die Software nach dem Programmstart erläutert, die ausführbaren Interaktionen
der Planungsphase, die Optimierung des zusammengestellten Tageseinsatzplans,
die Simulation dessen und abschließend die Evaluation dem Anwender zurückgeliefert.
Außerdem wird beschrieben, wie die beiden implementierten Algorithmen der Optimierung
im speziellen funktionieren und worin diese sich unterscheiden.
Bevor das Ergebnis dann ausgegeben wird, prüft die Simulation den übergebenen
besten Tageseinsatzplan zusätzlich anhand von äußeren Einflussfaktoren (Wetter), wie
der Strömung.
Konnten alle Stufen erfolgreich durchlaufen werden, so wird diese evaluiert und dem
Anwender veranschaulicht. Dabei werden die Kosten wie auch der Plan dargestellt.
7.1 Programmstart
Nach dem Start der Anwendung wird das Hauptfenster mit der Simulationsansicht (siehe
Abbildung 65 Initiales Hauptfenster des Clients) dargestellt.
Abb. 65: Initiales Hauptfenster des Clients (Quelle: Eigendarstellung)
Im Quelltext Programmstart wird ein Auszug der Umsetzung von Codezeile 269 bis 314
gezeigt, in der die Client-Anwendung gestartet wird. Zuvor wird jedoch überprüft, ob
die Anwendung schon gestartet wurde und noch nicht auf dem Client arbeitet. Diese
Funktion wird dadurch realisiert, dass eine Datei geschrieben und erst nach Beendigung
der Anwendung wieder gelöscht wird. Sollte also die Datei noch existieren, läuft die
Anwendung offensichtlich noch. Dann reagiert die Anwendung mit einem Dialog, in dem
128

7.1 Programmstart 7 BESCHREIBUNG DER SOFTWARE SCOWS
der Hinweis zu der schon laufenden Anwendung gegeben wird.
Läuft noch keine Instanz der Anwendung, wird mit der statischen Methode SwingUtilities.invokeLater()
und einer Anonymen Klasse Runnable() ein neuer Thread im Java
Swing Event Dispatch Thread (kurz EDT) eingereit und aufgerufen sobald dieser bereit
dazu ist. Dies verhindert, dass die Benutzeroberfläche nicht mehr reagiert.
Bei der Zeile MainFrame.getInstance() handelt es sich ebenfalls um einen statischen
Methodenaufruf. Die Klasse MainFrame erstellt hierdurch ein Singleton-Objekt und verwaltet
dieses intern. Der Konstruktor der Klasse ist privat, wodurch die direkte Erzeugung
eines Objektes ebenfalls nicht möglich ist.
262 /∗∗
263 ∗ Main S t a r t e r f o r the C l i e n t A p p l i c a t i o n . No args expected
264 ∗
265 ∗ @param args
266 ∗/
267
268
269 @SuppressWarnings ( ” r e s o u r c e ” )
270 p u b l i c s t a t i c void main ( S t r i n g [ ] args ) {
271 try {
272 f = new F i l e ( ”app . l o c k ” ) ;
273
274 i f ( f . e x i s t s ( ) ) {
275 f . d e l e t e ( ) ;
276 }
277
278 channel = new RandomAccessFile ( f ,
”rw” ) . getChannel ( ) ;
279 l o c k = channel . tryLock ( ) ;
280
281 i f ( l o c k == n u l l ) {
282 channel . c l o s e ( ) ;
283 JOptionPane . showMessageDialog ( null ,
”Only one i n s t a n c e o f t h i s app can be
run at the same time . ” , ” S t i l l
running ” ,
JOptionPane .INFORMATION MESSAGE) ;
284 System . e x i t ( 1 ) ;
285 }
286
287 // Add shutdown hook to r e l e a s e l o c k when
a p p l i c a t i o n shutdown
288 Thread shutdown = new Thread (new Runnable ( ) {
289 @Override
290 p u b l i c void run ( ) {
291 u n l o c k F i l e ( ) ;
292 }
293 }) ;
129

7.1 Programmstart 7 BESCHREIBUNG DER SOFTWARE SCOWS
294
295 // R e g i s t e r Hook
296 Runtime . getRuntime ( ) . addShutdownHook ( shutdown ) ;
297
298 // Call the app
299 S w i n g U t i l i t i e s . invokeLater (new Runnable ( ) {
300 @Override
301 p u b l i c void run ( ) {
302 MainFrame . g e t I n s t a n c e ( ) ;
303 }
304 }) ;
305
306 } catch ( IOException ex ) {
307 throw new RuntimeException ( ”Could not s t a r t
p r o c e s s ” , ex ) ;
308 }
309 }
Sorce Code 1: Ausschnitt der Implementierung des Programmstarts
Zusätzlich zu einer Werkzeugleiste befindet sich am oberen Fensterrand eine Menüleiste
(siehe Abbildung 66 Menüleiste des Hauptfensters). Die in jeder Ansicht verfügbare
Menüleiste ermöglicht die Auswahl von globalen Funktionen. Zu den Funktionen zählen
insbesondere das Anlegen von Datenbankeinträgen als auch die Auswahl der Kartengrundlage
sowie die Verwaltung von Stammdaten.
Im Menü Datei [File] kann die Planung gestartet, zu einem Punkt auf der Karte gesprungen
oder die Anwendung beendet werden. Die Bedienung erfolgt entweder über die
Maus als auch über die Tastatur. Zum Anlegen von neuen Einträgen bietet das Menü Datenbank
[Database] die entsprechenden Dialoge. Im Menü Stammdaten (Masterdata)
können die Daten der Anwendung geändert werden. Das dargestellte Kartenmaterial
lässt sich über das Menü Karte [Map] ändern bzw. um ein Koordinatengitter erweitern.
Eine Anzeige über Anwendung erhält der Benutzer über das Menü Hilfe [Help].
Abb. 66: Menüleiste des Hauptfensters (Quelle: Eigendarstellung)
Zu diesem Zeitpunkt sind die Elemente im Werkzeugleistenabschnitt Simulationskontrolle
(siehe Abbildung 67 Deaktivierte Simulationskontrolle) deaktiviert. Erst nach Durchführung
einer Planung mit der anschließenden Optimierung stehen diese Bedienelemente
zur Verfügung.
Abb. 67: Deaktivierte Simulationskontrolle (Quelle: Eigendarstellung)
130

7.2 Planungsphase 7 BESCHREIBUNG DER SOFTWARE SCOWS
Ebenfalls auf der Werkzeugleiste befindet sich der Kartenkontrollabschnitt (siehe Abbildung
68 Kartenkontrollwerkzeuge. Die Werkzeuge in diesem Abschnitt sind sofort
bedienbar. Einerseits kann der sichtbare Kartenausschnitt verschoben werden, andererseits
kann er vergrößert oder verkleinert werden.
Abb. 68: Kartenkontrollwerkzeuge (Quelle: Eigendarstellung)
7.2 Planungsphase
Wie im vorhergehenden Kapitel erläutert, startet die Planungsansicht durch die Auswahl
des Menüeintrags Starte Planung [Start scheduling] (siehe Abbildung 69 Initiales
Planungsfenster).
Abb. 69: Initiales Planungsfenster (Quelle: Eigendarstellung)
Sobald der Menüpunkt ausgewählt wurde, werden im Hintergrund Jobs und Transportmittel
aus der Datenbank geladen, dieses wird durch eine Statusanzeige in der Werkzeugleiste
verdeutlicht. Noch vor der grafischen Darstellung der Daten, werden die Jobs
so gefiltert, dass deren frühester bzw. spätester Starttermin innerhalb des zu planenden
Tages liegt. Der jeweilige Tageseinsatzplan wird im Kopf der Planungstafel dargestellt
(siehe Abbildung 70 Kopf der Planungstafel).
Die geladenen Daten werden anschließend grafisch aufbereitet und als Rechteck dargestellt
(siehe Abbildung 71 Transportmittellabel und Abbildung 72 Joblabel). Eine
dynamische Anpassung der Bezeichner (englisch Label) findet bei jeder Größenanpas-
131

7.2 Planungsphase 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 70: Kopf der Planungstafel (Quelle: Eigendarstellung)
sung des umgebenden Fensters statt. Dadurch wird immer nur soviel Text angezeigt, wie
die Breite des Bildschirms zulässt. In der aufgeführten Abbildung sind die Label in ihrer
maximalen Größe dargestellt.
Abb. 71: Transportmittellabel (Quelle:
Eigendarstellung)
Abb. 72: Das abzuarbeitende Joblabel
(Quelle: Eigendarstellung)
In der Werkzeugleiste sind neben dem Optimieren [Optimize] und Exit-Button [Exit]
zwei weitere Bereiche definiert (siehe Abbildung 73 Werkzeugleiste der Planungsansicht).
Im Bereich Setzen der Arbeitszeit [Set Work Time] kann die für den zu planenden
Tag verfügbare Zeitspanne eingestellt werden. Die tägliche Arbeitszeit kann zurzeit im
Bereich von 4 Uhr bis 21 Uhr liegen. Bei der Auswahl des Algorithmus kann der Benutzer
zwischen zwei verschiedenen Ansätzen zur Optimierung wählen. Der RS-Algorithmus
[RS-Algo] ist ein heuristisches Verfahren und der SG-Algorithmus [SG-Algo] ist ein selbst
konzipiertes Verfahren zur Optimierung.
Abb. 73: Werkzeugleiste der Planungsansicht (Quelle: Eigendarstellung)
Der Optimieren-Button [Optimize] ist so lange deaktiviert, bis die nötigen Daten für die
132

7.2 Planungsphase 7 BESCHREIBUNG DER SOFTWARE SCOWS
Optimierung ausgewählt wurden. Hierzu zählen die Arbeitszeiten, der Algorithmus und
die Auswahl von Transportmittel und Jobs.
Transportmittel und Jobs können aus den jeweiligen Spalten in ihre Auswahlspalten
gezogen werden. Dies geschieht durch das so genannte Drag&Drop. Hierzu klickt
man mit der linken Maustaste auf ein Transportmittel oder einen Job und während die
Maustaste gedrückt gehalten wird, wird das Label auf einen freien Bereich in die jeweilige
Auswahlspalte gezogen (siehe Abbildung 74 Auswahl von Transportmittel/Jobs).
Abb. 74: Auswahl von Transportmittel/Jobs (Quelle: Eigendarstellung)
Ein Zurückziehen der ausgewählten Elemente ist jederzeit möglich. Die Auswahlspalten
haben genauso wie die Quellspalten eine vorgegebene Sortierung. Aufträge werden
ihrer Priorität entsprechend absteigend und Transportmittel ihrem Typ nach sortiert.
Sobald alle Daten ausgewählt wurden, ist der Optimieren-Button [Optimize] aktiviert.
Ein Klick auf den Button zeigt ein Bestätigungsfenster mit einer Zusammenfassung der
ausgewählten Daten (siehe Abbildung 75 Bestätigungsdialog zur Optimierung).
Die Methode zum Verschieben eines Transportmittel-Labels ist exemplarische aus dem
Quellcode der Planungsphase von Code-Zeile 785 bis 812 entnommen. Aufgerufen wird
diese Methode aus der Drag&Drop-Funktion. Dieser wird das Zielpanel und das zu verschiebende
Label übergeben. Je nachdem in welche Richtung das Label verschoben wird,
ist das Ziel entweder die Liste mit allen Transportmitteln oder die selektierten Transportmittel.
Gleichzeitig werden die List-Objekte konsistent gehalten. Nach dem eigentlichen
Verschieben werden die Listen sortiert (mit Comparator) und über den Aufruf der Methode
relayout() neu geordnet.
Da die Label dynamisch ihre Größe ändern können und hiermit auch die enthaltene
Information entweder mehr oder weniger wird, ist eine Größenanpassung unumgänglich.
133

7.2 Planungsphase 7 BESCHREIBUNG DER SOFTWARE SCOWS
Diese Funktion übernimmt die Methode updateLabelWidths(). Zum Abschluss der Methode
wird überprüft, ob der Optimieren-Button [Optimize] aktiviert oder deaktiviert
werden muss.
777 /∗∗
778 ∗ Move the l a b e l to the t a r g e t and removes i t out o f old l i s t .
After that ,
779 ∗ i t r e l a y o u t s both
780 ∗
781 ∗ @param t a r g e t P a n e l
782 ∗ @param droppedLabel
783 ∗/
784
785 p u b l i c void moveVehicleLabel ( JPanel target , VehicleLabel
l a b e l ) {
786 i f ( t a r g e t . e q u a l s ( s e l e c t e d V e h i c l e s P a n e l ) &&
! s e l e c t e d V e h i c l e L a b e l s . c o n t a i n s ( l a b e l ) ) {
787 s e l e c t e d V e h i c l e L a b e l s . add ( l a b e l ) ;
788 v e h i c l e L a b e l s . remove ( l a b e l ) ;
789 }
790
791 i f ( t a r g e t . e q u a l s ( v e h i c l e s P a n e l ) &&
! v e h i c l e L a b e l s . c o n t a i n s ( l a b e l ) ) {
792 v e h i c l e L a b e l s . add ( l a b e l ) ;
793 s e l e c t e d V e h i c l e L a b e l s . remove ( l a b e l ) ;
794 }
795
796 // Sort them
797 C o l l e c t i o n s . s o r t ( s e l e c t e d V e h i c l e L a b e l s , new
VehicleTypeComparator ( ) ) ;
798 C o l l e c t i o n s . s o r t ( v e h i c l e L a b e l s , new
VehicleTypeComparator ( ) ) ;
799
800 // layout
801 r e l a y o u t ( s e l e c t e d V e h i c l e s P a n e l , s e l e c t e d V e h i c l e L a b e l s ) ;
802 r e l a y o u t ( v e h i c l e s P a n e l , v e h i c l e L a b e l s ) ;
803
804 // update the Label widths
805 updateLabelWidths ( ) ;
806
807 // check button
808 checkEnableOptimizeButton ( ) ;
809 }
Sorce Code 2: Ausschnitt der SchedulingView2
Wird der Dialog bestätigt [Confirm], werden die ausgewählten Daten an den Server
gesendet. Auf dem Server findet die Optimierung des ausgewählten besten Plans statt.
134

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 75: Bestätigungsdialog zur Optimierung (Quelle: Eigendarstellung)
7.3 Optimierungsvorgang
Generell stehen zwei verschiedene Optimierungs-Algorithmen im Scheduling zur Auswahl
([RS-Algo] und [SG-Algo]). Es wird nur derjenige ausgeführt, der auch ausgewählt wurde.
Die Auswahl wird im Bestätigungsdialog (siehe Abbildung 75 Bestätigungsdialog zur
Optimierung) noch einmal angezeigt, bevor die Optimierung mittels [Confirm] gestartet
wird.
7.3.1 Heuristisches Verfahren [RS-Algo]
Die Heuristik verfolgt das Ziel, möglichst günstige Pläne für die Offshore-Wartungseinsätze
zu finden. Sie soll Antworten auf die Fragen liefern, welche der verfügbaren Schiffe
eingesetzt werden sollen, welches Schiff welche OWA wann anfahren soll und wie viele
Mitarbeiter jedes Schiff transportieren muss. Der Ansatz der Heuristik besteht darin, die
vier großen Kostenpunkte Charter-, Treibstoff-, Personal- und Gewinnausfallkosten auf
vier Schritte zu reduzieren:
1. Die Charterkosten sollen gering gehalten werden, indem günstige Schiffskombinationen
ermittelt werden, welche das Job-Volumen bewältigen können.
2. Die zu erledigenden Jobs bezüglich der geographischen Distanz zwischen den betroffenen
WEAs sollen geclustert und Schiffen zugeordnet werden. Durch das Clustern
soll erreicht werden, dass die Fahrzeit, die ein Schiff zwischen den OWAs
zurücklegen muss, nicht zu lange dauert und somit Treibstoff gespart werden kann.
3. Nicht durchführbare Job-Cluster werden korrigiert. Für jedes einzelne Cluster werden
durchführbare Anordnungen der Jobs auf dem jeweiligen Schiff ermittelt. Jede
dieser Anordnung wird hinsichtlich Personal-, Gewinnausfall und Treibstoffkosten
bewertet. Die besten Cluster-Anordnungen bilden zusammen einen Einsatzplan.
4. Mehrere Pläne werden miteinander verglichen, bei denen günstige Schiffskombinationen
zugrunde liegen und der kostengünstigste unter ihnen wird der Simulation
zur Verfügung gestellt. Die Heuristik kann nur eine Teilmenge aller theoretisch
135

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
möglichen Pläne untersuchen und garantiert nicht das Auffinden des bestmöglichen
und damit optimalen Plan.
7.3.1.1 Annahmen
In der Heuristik wird die für Schiffseinsätze zur Verfügung stehende Zeit, die ein Schiff
im OWP verbringt, in 30 Minuten-Slots (Zeitschlitze) eingeteilt. Dies vereinfacht die
Abschätzung günstiger Transportmittelkombinationen und die Anordnung der Jobs auf
einem Transportmittel. Auch die Dauer, die ein Job benötigt, wird als ein Vielfaches von
30 Minuten angegeben. Zur Veranschaulichung ist in Abbildung 76 Kleiner Offshore-
Wartungseinsatz ein kleiner Offshore-Wartungseinsatz dargestellt. Das Schiff benötigt
für den Überstieg der Teams, also für das Absetzen und Abholen der Mannschaften,
jeweils 20 Minuten, wie in (QUELLE: SystOp-Dokument) dargestellt. Für die Fahrzeit
zwischen den WEA wurde eine durchschnittliche Fahrzeit von zehn Minuten geschätzt.
In zehn Minuten kann ein Schiff, dass beispielsweise 12 Knoten (kn) im OWP fährt,
eine Distanz von 3,7 km zurücklegen. Da die Jobs eines Jobs-Cluster geographisch nahe
beieinander liegen, sollte diese Distanz im Mittel ausreichen. (Vergleiche hierzu die im
Kapitel 6.3 Optimierungskonzepte beschriebenen Annahmen)
Die Slot-Interpretation ist nicht ganz genau. Wenn z. B. ein Schiff neben einer OWA
wartet, um das abgesetzte Team als nächstes wieder abzuholen, werden beispielsweise
zehn Minuten gespart. Trotz dieser Ungenauigkeiten überwiegen die Vorteile der Slot-
Darstellung in den Heuristik-Schritten 1 und 3.
Für einen Job wird ein Slot für das Absetzen und einer für das Holen des Teams
eingeplant, also insgesamt eine Stunde. Für jede Stunde, die ein Schiff im OWP verbringt,
kann somit höchstens ein Job erledigt werden. Damit ein Job ausgeführt werden kann,
sollten das kleinste Zeitfenster im OWP nicht weniger als 1,5 Stunden betragen.
Dabei müssen Constraints eingehalten werden: Das Zeitfenster im OWP sollte eingehalten,
sonst können die Mitarbeiter gegebenenfalls aufgrund von sich verschlechternder
Wetterbedingungen nicht mehr rechtzeitig auf ihr Transportmittel übersteigen oder verstoßen
gegebenenfalls gegen bestehendes Arbeitsrecht. Die maximale Personenzahl, die
ein Schiff transportieren kann, darf nicht überschritten werden.
7.3.1.2 Einschränkungen
Die Heuristik soll nur die Einsatzplanung eines Einsatztages verbessern. Dazu müssen die
Jobs feststehen, die am aktuellen Tag ausgeführt werden sollen. Diese können zuvor durch
eine übergeordnete rollierende Planung, die täglich Wetter und Ertragsbedingungen der
folgenden Tage berechnet, festgelegt werden.
Außerdem sollen die Service-Techniker mit demselben Schiff den OWP wieder verlassen,
mit dem sie ihn erreicht haben, sodass das Risiko verringert wird, dass ein Team im
OWP vergessen wird.
Die Heuristik setzt voraus, dass die Schiffe im spezifizierten Zeitfenster die OWAs
anfahren können, also dass die Wetter- und Wellenverhältnisse dies zulassen. Es werden
sonst keine weiteren Umwelteinflüsse in der Einsatzplanung berücksichtigt. Für die
Berechnung der Gewinnausfälle ausgefallener WEAs wird mit einem konstanten Wert
136

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 76: Kleiner Offshore-Wartungseinsatz (Quelle: Eigendarstellung)
gerechnet, der der jeweiligen Nennleistung entspricht.
Helikoptereinsätze werden durch die diese Heuristik nicht berücksichtigt. Helikopter
können höchstens einen Job im OWP ausführen lassen, da häufig aus Gewichtsgründen
maximal vier bis fünf Personen mit ihrer Ausrüstung mitgenommen werden können
(Quelle: 12.06.2013 Telefonat mit HTM (Helicopter Travel Munich GmbH)). Es wurde
festgestellt, dass die Entscheidung, ob ein Schiff oder ein Helikopter für diesen einzigen
Job das günstigere Transportmittel ist, sich einfach berechnen lässt und keiner Heuristik
bedarf.
Die Heuristik berücksichtigt außerdem nicht die unterschiedlichen Qualifikationen, welche
die Service-Techniker erfüllen müssen. Es wird vereinfachend davon ausgegangen,
dass entsprechend ausgebildete Mitarbeiter zur Verfügung stehen.
Die Heuristik nutzt das Optimierungspotential, das sich ergibt, wenn mehrere Jobs
an der gleichen OWA anfallen, nicht aus. Die maximale Anzahl an Mitarbeitern, die
auf einer WEA arbeiten können, wird bei mehreren Jobs an einer WEA nicht berücksichtigt.
Es wird empfohlen, Jobs, die an der gleichen OWA stattfinden zu einem Job
137

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
zusammenzufassen.
7.3.1.3 Schritt 1: Günstige Transportmittelkombinationen abschätzen
Der erste Schritt der Heuristik wird von einem Estimator-Objekt durchgeführt, wie im
Sequenzdiagramm (siehe Abbildung 86 Heuristik Sequenzdiagramm) zu sehen ist. Die
Aufgabe des Estimators ist es, möglichst günstige Schiffskombinationen abzuschätzen,
welche die gegebenen Jobs durchführen können. Dazu wird für jedes Schiff berechnet,
wie viele Personenstunden es ausführen lassen kann. Diese Zahl entspricht in Abbildung
77 Personenstunden pro Schiff der Fläche C. Diese Personenstunden lassen sich wie folgt
berechnen: Zunächst wird die Anzahl der Sitzplätze des Schiffs mit dem zur Verfügung
stehenden Zeitfenster multipliziert . Diese Personenstundenzahl ist noch zu groß. Nun
werden die Personenstunden abgezogen, die bei der Fahrt zum OWA und auf der Rückfahrt
ungenutzt bleiben. Die Zahl errechnet sich, indem die Fahrtzeit zum OWA, die sich
aus Geschwindigkeit und Wegstrecke des Schiffs ergibt, mit der Zahl der Sitzplätze multipliziert
wird. Anschließend müssen noch die Personenstunden abgezogen werden, die
ungenutzt bleiben, weil Service-Techniker auf dem Schiff warten, während die anderen
Mitarbeiter auf das Schiff abgesetzt werden (Fläche A) bzw. während andere Kollegen
wieder auf das Schiff geholt werden (Fläche B). Um diese Flächen zu berechnen wird die
Ladezeit Y benötigt, die sich aus der maximaler Anzahl Mitarbeiter des Schiffs geteilt
durch die durchschnittliche Anzahl der Mitarbeiter pro Job ergibt. Zusammengefasst
lässt sich die gesuchte Personenstundenzahl C eines Schiffs aus der maximalen Anzahl
der Mitarbeiter pro Schiff X, der Ladezeit Y und dem Zeitfenster im OWA Z berechnen.
Die Formel für C lautet:
C = X · (Z − Y )
Die benötigten Personenstunden der gegebenen Jobs lassen sich ermitteln, indem für
jeden Job die Dauer plus Übersteigezeit (jeweils 2 Slots = 1 Stunde) mit der Anzahl an
Mitarbeitern multipliziert und die Ergebnisse aufsummiert. Diese Personenstundenzahl
muss von den Schiffen erledigt werden können.
Da das Estimator-Objekt für jedes Schiff die Personenstundenzahl berechnen kann,
kann er diese auch für beliebige Schiffskombinationen berechnen, indem er die Personenstundenzahlen
jedes Schiffs der Kombination addiert. Die Anzahl an möglichen Schiffskombinationen
wird durch folgende Formel bestimmt:
n∑
( ) n
i
i=1
Für zehn Schiffe sind somit 1023 Schiffskombinationen möglich. Für 20 Schiffe sind es
schon 1.048.575 Möglichkeiten. Für 20 oder weniger Schiffe lassen sich die Personenstunden
der Schiffskombinationen problemlos berechnen. Es werden alle Schiffskombinationen
verworfen, deren Personenstundenzahl kleiner ist, als die Personenstundenzahl, die durch
die Jobs vorgegeben wird. Die restlichen Schiffskombinationen werden nach ihren Char-
138

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 77: Personenstunden pro Schiff (Quelle: Eigendarstellung)
terkosten aufsteigend sortiert. Die erhaltene Liste enthält also alle Schiffskombinationen,
welche voraussichtlich alle Jobs erledigen können, sortiert nach ihren Charterkosten. Diese
Liste wird dem nächsten Heuristik-Schritt, dem Clustering, zur Verfügung gestellt.
Sollte die Liste leer sein, weil keine Schiffskombination mit ausreichend Personenstunden
gefunden werden konnte, kann kein Einsatzplan erzeugt werden.
7.3.1.4 Schritt 2: Job-Cluster erstellen
Im Rahmen der Optimierung wird nach der Abschätzung möglicher Transportmittel(-
kombinationen) ein Clustering der einzelnen Maßnahmen an den WEAs durchgeführt.
Dies betrifft Anzahl und Art der Transportmittel. Das Clustering erfolgt in Abhängigkeit
der geografischen Distanz zwischen den einzelnen Maßnahmen. Dies ist sinnvoll, da vor
allem in großen OWPs mit vielen WEAs (bspw. 100 oder mehr), die Fahrtzeiten zwischen
einzelnen WEAs sehr lang und daher weder zeit-, noch kosteneffizient wäre. Das Clustering
dient also zur Zusammenführung geografisch nah beieinander liegender Maßnahmen
im OWP . Das zum Erzeugen der Cluster verwendete Verfahren ist ein klassisches Verfahren
aus dem Bereich des Data Minings, das so genannte K-Means-Clustering. (Han
u. a., 2006)
139

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Hierbei wird zunächst die Anzahl der Cluster k festgelegt, wobei diese aus der Abschätzung
der Transportmittel hervorgeht. Dabei gilt, dass ein Transportmittel sämtliche
Maßnahmen innerhalb eines Clusters bedient. Das heißt, die sich an Bord befindlichen
Mitarbeiter werden zu den OWAs transportiert und auch wieder abholt.
Formal betrachtet, ist das Ziel des K-Means-Algorithmus einen Datensatz so in k-
Partitionen zu unterteilen, dass die Summe aller quadrierten Abweichungen von den
Cluster-Zentren minimal ist. Die Distanz zwischen einzelnen WEAs wird über den euklidischen
Abstand berechnet. Dieser wird hier weiterhin als Distanzfunktion bezeichnet.
d(x, y) = |x − y| = √ ∑
(x 1 + y 1 ) 2 + ... + (x n + y n ) 2 = √ n (x i − y i ) 2
Zur Berechnung der Cluster-Zentren wird der Mittelwert aller zum Cluster zugehöriger
Windenergieanlagenpositionen berechnet. Auf eine Standardisierung wird auf Grund der
verhältnismäßig geringen Datenmengen verzichtet, außerdem ist die Distanz das einzige
Vergleichsmaß.
X mittel = (x 1 + x 2 + x 3 + ... + x n )
N
Mithilfe eines iterativen Verfahrens wird in jedem Iterationsschritt eine Maßnahme einem
Cluster gemäß der Distanzfunktion hinzugefügt. Anschließend wird für jedes Cluster das
Zentrum anhand des Mittelwertes neu berechnet. Das Clustering ist dann abgeschlossen,
wenn die Cluster sich nicht mehr ändern, das im Rahmen des Clustering-Verfahrens
gefundene Optimum also erreicht ist.
Für eine gegebene Schiffskombination wird das Clustering-Verfahren mehrmals durchgeführt,
bei dem die initialen Cluster-Zentren zufällig gewählt werden. Für jedes erhaltene
Ergebnis des Clusterings wird die Summe der quadrierten euklidischen Distanzen
berechnet und das Ergebnis mit der niedrigsten Summe enthält die kompaktesten gefundenen
Cluster. Jedem Cluster des Ergebnisses wird ein Schiff zugewiesen. Es steht jedoch
noch nicht fest, ob jedes Schiff die zugewiesenen Jobs überhaupt durchführen kann. Eine
Prüfung und Korrektur von möglicherweise nicht durchführbaren Clustern erfolgt im
nächsten Heuristik-Schritt. In der Abbildung 78 Iterationsschritte des Clusterings ist der
iterative Ablauf des Clusterings einmal graphisch aufbereitet.
7.3.1.5 Schritt 3: Günstige durchführbare Ablaufpläne erstellen
In diesem Abschnitt wird zuerst erklärt, wie die Jobs eines Job-Clusters im Zeitfenster
des zugeordneten Schiffs angeordnet werden können. Anschließend wird dargestellt, wie
die Durchführbarkeit von Job-Clustern geprüft und gegebenenfalls hergestellt werden
kann. Schließlich wird erklärt, wie eine günstige Job-Anordnung für ein Cluster gefunden
werden kann.
i=1
140

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 78: Iterationsschritte des Clusterings (Quelle: Eigendarstellung)
Anordnen von Jobs
Gegeben sei ein Zeitfenster eines Schiffs im OWP, in dem schon einige Jobs eingeplant
sind. Abbildung 79 Einfügeindizes zeigt ein 5 1/2 stündiges Zeitfenster mit elf Slots.
Sechs Slots sind bereits reserviert, davon drei zum Absetzen von Mitarbeitern (A1, A2,
A3) und drei zum Abholen der Teams (H1, H2, H3). Das Diagramm über den Zeitslots
gibt an, wie viele Service-Techniker das Schiff bereits abgesetzt hat bzw. wie viele
Servicetechniker des Schiffs sich auf OWAs befinden. In das Zeitfenster soll ein vierter
Job eingefügt werden, welcher drei Mitarbeiter benötigt und 1,5 h dauert. Insgesamt
wird sich der neue Job jedoch mindestens über 2,5 h, das heißt fünf Slots erstrecken,
da die Zeiten zum Absetzen und Abholen der Techniker berücksichtigt werden müssen.
Zunächst muss der Absetz-Slot des neuen Jobs im neuen Zeitfenster platziert werden.
Dazu werden Einfügeindizes ermittelt, die in Abbildung 79 Einfügeindizes durch rote
Pfeile gekennzeichnet sind. Sie markieren Slots, die auf Hol-Slots folgen (hier: Index 2
und 3) sowie frühsten ungenutzten Zeit-Slot (hier: Index 3). Die Einfügereihenfolge, welche
durch die Indizes vorgegeben wird dient dazu, die maximale Zahl der Mitarbeiter
möglichst gering zu halten. Zunächst wird für Index 1 geprüft, ob genug Zeit ab dieser
Indexstelle für den neuen Job zur Verfügung steht. Dies ist nicht der Fall, da Index 1 der
letzte Slot des Zeitfensters ist. Auch Index zwei eignet sich nicht. Schließlich kann Job
4 an der Indexposition 3 eingefügt werden. Die Mitarbeiterzahl im Diagramm wird für
den dritten, vierte, fünften und sechsten Slot aktualisiert. Nun muss noch der Hol-Slot
des neuen Jobs gesetzt werden. Doch im siebten Slot wird schon das Team von Job
1 abgeholt, siehe Abbildung 80 Einfügekonflikt des Hol-Slots H4. Um diesen Konflikt
aufzulösen, muss entschieden werden, welcher der Hol-Jobs rekursiv eine Slot-Position
weiter in die Zukunft geschoben wird. Da eine OWAs in unserem Simulationsmodell
Gewinnausfälle verursacht, solange sich ein Team auf ihr befindet, wird derjenige Hol-
Job verschoben, dessen WEA den geringeren Gewinnausfall hat. In unserem Fall soll
die WEA des neuen Jobs einen geringeren Gewinnausfall verursachen. Der Hol-Job wird
um zwei Positionen auf den nächsten ungenutzten Slot verschoben und die Anzahl an
Mitarbeitern wird im aktualisiert, wie im Diagramm von Abbildung 81 Job 4 wurde
erfolgreich eingefügt veranschaulicht.
141

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 79: Einfügeindizes (Quelle: Eigendarstellung)
Ein Job kann nicht in ein Zeitfenster eingefügt werden, wenn das Einfügen an jeder
Indexstelle eine Constraint-Verletzung bedeuten würde, also wenn das Zeitfenster oder
die maximale Zahl an Mitarbeitern, die das Schiff transportieren kann, überschritten
würden. Das Einfügen der Jobs in der gewählten Reihenfolge ist dann nicht möglich.
Durchführbarkeit von Job-Clustern
Nicht jedes Cluster, das durch das Clustering berechnet wurde, ist durchführbar. Es
kann sein, dass ein Cluster zu viele Jobs enthält oder sich die Jobs nicht im Zeitfenster
des zugehörigen Schiffs anordnen lassen. Das Reviser-Objekt (vergleiche Abbildung 86
Heuristik Sequenzdiagramm) soll prüfen, ob Cluster durchführbar sind oder nicht und
gegebenenfalls die Durchführbarkeit aller Cluster herstellen. Erstellt pro Cluster alle
möglichen Job-Permutationen. Bei acht Jobs wären dies 8! = 40.320 Permutationen, bei
neun Jobs schon 9! = 362.880. Damit die Laufzeit der Optimierung nicht unakzeptabel
durch die vielen Berechnungen steigt, wurde die maximale Job-Anzahl eines Clusters auf
9 Jobs beschränkt. Auch bei Zeitfenstern im OWP von mehr als 9 Stunden, kann ein
Cluster höchstens 9 Jobs enthalten. Dies stellt eine Grenze dieser Heuristik dar.
Sobald sich eine Job-Permutation eines Cluster im Zeitfenster des zugehörigen Schiffs
anordnen lässt, ist das Cluster durchführbar. Dazu werden für jede Job-Permutation die
Jobs sukzessive im Zeitfenster platziert, wie im vorangegangenen Abschnitt beschrieben.
142

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 80: Einfügekonflikt des Hol-Slots H4 (Quelle: Eigendarstellung)
Stellt der Reviser fest, dass manche Cluster nicht durchführbar sind, also für keine
Permutation eine durchführbare Anordnung existiert, erstellt er eine Liste aller Jobs aus
undurchführbaren Clustern und sortiert die Jobs nach ihrer Dauer. Dann versuchte es
der Reviser die Jobs aus den nicht durchführbaren Clustern in durchführbare zu verschieben,
angefangen mit dem längsten Job der Liste. Lässt sich ein Job in ein bisher
durchführbares Cluster verschieben und bleibt dieses Cluster dann noch durchführbar,
dann war die Aktion erfolgreich. Möglicherweise ist dadurch das bisher nicht durchführbare
Cluster ebenfalls Cluster durchführbar geworden. Dieser Vorgang wird wiederholt
bis alle Cluster durchführbar sind.
Falls es überhaupt nicht möglich, ist einen Job eines nicht durchführbaren Clusters,
einem durchführbaren Cluster zuzuordnen und dieses durchführbar bleibt, kann kein
Plan aus diesen Clustern erstellt werden.
In Abbildung 82 Herstellen der Durchführbarkeit undurchführbarer Cluster werden
durchführbare (rot) und undurchführbare Job-Cluster dargestellt. Sei der Job an OWA
A der längste Job eines nicht durchführbaren Clusters, so wird zunächst versucht, diesen
dem geografisch nächstgelegenen Cluster zuzuordnen, wie durch den Pfeil angedeutet.
Funktioniert dies nicht, wird es versucht, ihn dem nächsten durchführbaren Cluster zuzuordnen.
Wenn auch dies nicht funktioniert, wird das gleiche mit den nächst-längsten
Job des Clusters versucht usw.
143

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 81: Job 4 wurde erfolgreich eingefügt (Quelle: Eigendarstellung)
Wenn alle Cluster durchführbar sind, das heißt, es gibt für jedes Cluster mindestens eine
Job-Anordnung, die sich unter Berücksichtigung der Constraints im Zeitfenster anordnen
lässt, können im nächsten Teilschritt günstige Anordnungen gesucht werden.
Finden günstiger Job-Anordnungen
Das JobScheduler-Objekt, welches für das Finden günstiger Job-Anordnungen für die
Cluster verantwortlich ist, erhält als Input durchführbare Cluster (vergleiche Abbildung
86 Heuristik Sequenzdiagramm) mit jeweils maximal 9 Jobs. Für jedes durchführbare
Cluster werden alle Job-Permutationen (maximal 9!) erzeugt und zunächst auf
Durchführbarkeit überprüft. Das heißt, es wird versucht alle Job-Permutationen eines
Clusters im Zeitfenster des zugehörigen Schiffs und allen kleineren Zeitfenstern, für die
mindestens eine durchführbare Anordnung existiert, anzuordnen. Alle durchführbaren
Anordnungen werden anschließend dem Evaluator-Objekt übergeben, welches die vermutlichen
Kosten wie folgt berechnet: Die Charterkosten werden durch das Schiff des
Clusters festgelegt. Die Lohnkosten ergeben sich durch die Anzahl der mitgenommenen
Mitarbeiter und der Länge des gesamten Einsatzes. Für jedes Cluster steht fest, in welchem
Zeitslot das Schiff welche OWA anfahren muss. So können die gefahrene Strecke im
OWP und die Transportkosten ermittelt werden. Treibstoffkosten lassen sich berechnen,
indem die Strecke des Schiffs zum OWP und zurück und zwischen den entsprechen-
144

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 82: Herstellen der Durchführbarkeit undurchführbarer Cluster (Quelle: Eigendarstellung)
den WEAs (euklidische Distanz) addiert werden und mit den Treibstoffpreis und dem
durchschnittlichen Treibstoffverbrauch des Schiffs verrechnet werden. Die voraussichtlichen
Gewinnausfallkosten lassen sich ebenfalls berechnen, da durch die Job-Anordnung
definiert wird, wann welche WEA wieder instandgesetzt wurde und wann welche OWA
nicht läuft, weil sich Service-Techniker auf ihr befinden.
Die Job-Anordnungen, deren Instandsetzungsjobs möglichst früh ausgeführt werden,
die relativ wenige Mitarbeiter benötigen, schnell durchgeführt werden und bei denen die
Fahrzeit zwischen den OWPs relativ klein ist, erhalten so günstige Bewertungen. Die
günstigsten gefundenen Jobs-Anordnungen aller Cluster ergeben einen Einsatzplan.
7.3.1.6 Schritt 4: Den günstigsten Gesamtplan bestimmen
Dieser Schritt sammelt mehrere Pläne, die durch die Schritte 1-3 für mehrere günstige
Schiffskombinationen ermittelt werden. Ein Plan enthält für jedes seiner Cluster ein
Transportmittel für das fest steht, wie viele Mitarbeiter dieses mitnehmen muss sowie
eine Job-Liste deren Jobs mit Bring- und Abholzeiten versehen sind.
Da durch das Evaluator-Objekt Kosten für jedes Cluster berechnet werden, lassen sich
damit auch die Kosten jedes Plans ermitteln. Der beste Plan wird dann an die Simulation
übergeben.
7.3.2 Sequenzielle Abarbeitung mit Clustering [SG-Algo]
Das Verfahren der ”
sequenziellen Abarbeitung mit Clustering“ verfolgt ebenfalls das
Ziel, möglichst beste Pläne für Offshore-Wartungseinsätze zu finden. Bei diesem Verfahren
werden jedoch alle verfügbaren Transportmittel bzw. Transportmitteltypen eingesetzt.
In erster Linie werden vermutlich auch Schiffe zum Einsatz kommen, aber denkbar
145

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
wäre auch der Einsatz von Helikopter. Diese werden nicht von vornherein kategorisch
ausgeschlossen, weil der Einsatz von Helikoptern generell als zu unrentabel angenommen
werden. Dies ermöglicht auch bei ungünstigeren Verhältnissen die Software zum Einsatz
zu bringen. Diese Optimierung wurde zum Großteil nach der im Konzept vorgestellten
Methode implementiert.
Das Verfahren durchläuft ebenfalls in vier Phasen, die logisch voneinander abhängig
sind und so zu der Zielgröße ”
bester Plan“:
1. Parameterprüfung
2. Gruppierung der Jobs
3. Zusammenfassen der Jobgruppen
4. Transportmittelverteilung
Die einzelnen Phasen werden mit deren darunter organisierten Aufgaben in der Abbildung
83 Ablauf des zweiten Optimierungsverfahren veranschaulicht:
Abb. 83: Ablauf der Optimierung nach dem [SG-Algo] (Quelle: Eigendarstellung)
146

7.3 Optimierungsvorgang 7 BESCHREIBUNG DER SOFTWARE SCOWS
7.3.2.1 Parameterprüfung
In erster Instanz werden jegliche Parameter geprüft. Das bedeutet, es werden die notwendigen
Constraints entsprechend des Inputs aufgearbeitet, sodass keine Verletzung
dieser erfolgt.
Der Algorithmus bestimmt zuerst die Netto-Arbeitszeit. Dies beinhaltet zu berechnen,
wie die reine Arbeitszeit für jeden Job im OWP beträgt. Die Gesamtsumme aller
Arbeitsaufträge ergibt dann die gesamte Netto-Arbeitszeit. Der nächste untergeordnete
Schritt ist die Ermittlung der Worst-Case-Jobgruppen. Der Hintergrund ist zu ermitteln,
wie viel Zeit benötigt wird, wenn alle Jobs direkt sequenziell hintereinander abgearbeitet
werden. Darauf folgt die Bestimmung des möglichen Arbeitsanfangs sowie der
notwendige Arbeitstagesendezeitpunkt. Diese Zeitspanne ist die effektive Arbeitszeit im
OWP. Anschließend werden die Jobs nach der jeweiligen festgehaltenen Priorität und die
dafür benötigten Mitarbeiter sortiert, damit diese im weiteren Verlauf so sortiert werden
können, dass ein günstig optimierter Tageseinsatzplan herauskommt. Der letzte Aspekt
der Parameterprüfung ist die Gruppierung der Jobs entsprechend der zugehörigen OWA.
7.3.2.2 Gruppierung der Jobs
Es sind im ersten Schritt alle notwendigen Input-Parameter überprüft und zugeteilt
worden, sodass mit der zweiten Phase begonnen werden kann.
Zu Beginn wird die ersten Jobgruppe gemäß der vorangegangenen Gruppierung erstellt,
die sich an die Zuordnung zu den OWAs orientiert. Nachfolgend werden alle verbleibenden
Jobs miteinander in Verbindung gesetzt und mögliche sinnvolle Paarungen
ermittelt. Des Weiteren wird eine Matrix aller OWAs aufgrund der geographischen Position
erstellt. Daraus resultierend kann nun anhand der Matrix eingeschätzt werden, welche
Jobpaarungen in Abhängigkeit zum zeitlichen Aufwand und der unabdingbaren Mitarbeiter
zusammen abgearbeitet werden können. Dadurch kann dann eine Reduzierung
der Mitarbeiter erfolgen, da alle Paarungen, die zueinander passen, zusammengefasst
werden. Jobs, die nicht zugeteilt bzw. verteilt und zugewiesen werden können, werden
zu einer eigenen gemeinsamen Gruppe von Jobs zusammengefügt in der Hoffnung diese
sinnvoll erfüllen zu können.
7.3.2.3 Zusammenfassen der Jobgruppen
Die vorletzte Phase bezieht sich hauptsächlich auf das Zusammenfassen von Jobs. Die
erste Zusammenfassung von Jobs oder auch Jobgruppen ist bestimmt durch die Priorität
sowie Entfernung voneinander. Darauf aufbauend werden diese aufgrund des einzusetzenden
Fachpersonals zusammengefasst. Danach kann endgültig festgestellt werden, wie die
maximal aufzubringende Anzahl von Mitarbeitern aller jeweils ermittelten Jobgruppen
aussieht.
7.3.2.4 Transportmittelverteilung
Im letzten Schritt wird die passende Anzahl an Transportmittel ermittelt. Aus den Jobgruppen
und den einzelnen Jobs kann die minimal und maximal benötigte Transport-
147

7.4 Simulation 7 BESCHREIBUNG DER SOFTWARE SCOWS
struktur berechnet werden sowie auch die dazugehörigen Kosten. Anhand der gegebenen
Informationen werden Transportmittelkombinationen erzeugt und zu jeder Variante
die Kosten aufgestellt. Die günstigste bzw. günstigsten Transportmittelkombination/en
wird/werden den Jobgruppen zugeteilt. Abgeschlossen wird diese Phase mit dem Übergeben
des besten Ergebnisses an die Simulation, was den komplett zusammengestellten
Tageseinsatzplan beinhaltet.
7.4 Simulation
Die Simulation eine Plans wird in der MapView (siehe Abbildung 84 Darstellung einer
Simulation) durchgeführt. Diese erzeugt bei ihrem Aufruf eine neue Simulation für den
von der Optimierung berechneten Plan. Es wird das Akka-Framework gestartet und alle
Akteure initialisiert, die zur erfolgreichen Simulation benötigt werden. Hierzu zählen zum
einen alle OWAs, die sich in der Datenbank befinden, sowie jedes Transportmittel, das im
Plan enthalten ist. Die Transportmittel werden automatisch über die Jobs informiert, die
diese zu erledigen haben, während jede WEA eine Liste mit der Reihenfolge bekommt, in
der die Transportmittel diese ansteuern. Sind alle Akteure korrekt initialisiert worden,
werden die Akteure an ihrer entsprechenden Position in die Karte (Map) gezeichnet.
Zusätzlich wird die Akteur-Liste am linken Rand der View aktualisiert. Anschließend
wird der Start-Button in der Kontrollleiste oberhalb der Map aktiviert.
Nachdem die Simulation über den Start-Button gestartet worden ist, wird die Map
einmal in der Sekunde mit den aktualisierten Positionen der Akteure neu gezeichnet. Die
Simulation kann jederzeit durch das Klicken des Pause-Buttons angehalten und erneutes
klicken fortgesetzt werden. Zudem ist es möglich, die Simulation über den Abbruch-
Button jederzeit in ihre Ausgangsposition zurückzuversetzen. Neben den gerade erklärten
Buttons gibt es noch eine ComboBox, die anzeigt mit welcher Geschwindigkeit die Simulation
abläuft. Es lassen sich 8 verschiedene Ausdrücke der Form 1:x wählen, wobei x
beschreibt, wie viele Sekunden die Simulation in einer Sekunde voranschreiten soll. Der
Standardwert liegt bei 10 Sekunden.
Um auf der Map navigieren zu können, bieten sich dem Nutzer zwei Möglichkeiten.
Er kann die Map direkt mit der Maus in eine gewünschte Richtung ziehen, indem er
mit dem Cursor auf diese bewegt und diesen bei gedrückter Taste bewegt. Eine weitere
Möglichkeit ist, die Map über die Pfeil-Buttons zu bewegen, die sich in der oberen
Kontrollleiste unter dem Bezeichner Map controls befinden. Diese verschieben die Map
immer um 256 Pixel in die gewünschte Richtung. Eine weitere Funktion der Map controls
ist das Zoomen der Map über einen Slider. Hierbei gilt, dass je weiter der Slider nach
links verschoben wird, desto weiter wird aus der Map herausgezoomt.
Möchte der Benutzer wissen, wo sich ein bestimmter Akteur während der Simulation
aufhält, so kann er diese einfach in der Akteur-Liste auswählen und die Map zentriert
automatisch auf den ausgewählten Akteur. Ein Doppelklick auf einen Transportmittel-
Akteur bewirkt, dass die ungefähre Route auf der Map verzeichnet wird, die der Akteur
während der Simulation zurücklegen muss. Hierbei geben Nummern an den Wegstrecken
an, in welcher Reihenfolge diese abgefahren werden. Sollte der Nutzer sich die Routen
mehrerer Schiffe anzeigen lassen wollen, so kann er über den Rechtsklick auf einen Akteur
148

7.4 Simulation 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 84: Die Abbildung zeigt einen Ausschnitt aus der Simulation eines Plans (Quelle:
Eigendarstellung)
149

7.4 Simulation 7 BESCHREIBUNG DER SOFTWARE SCOWS
in der Liste eine Farbauswahl aufrufen und die Farbe auswählen, in der die Route des
Akteurs in die Map gezeichnet werden soll.
Ein weiteres Feature der Map ist die Auswahl mehrerer Kartenebenen. Standardmäßig
wird beim Zeichnen der Map Kartenmaterial von OpenStreetMaps verwendet. Darüber
wird eine weitere Ebene gelegt, die für die Schifffahrt wichtige Punkte wie z.B. Bojen,
Leuchttürme und Schifffahrtsstraßen enthält. Die Daten hierfür stammen von OpenSea-
Maps. Über das Fenstermenü können die Ebenen über den Punkt Map je nach Wunsch
hinzugefügt oder entfernt werden. Eine zusätzliche Ebene, die beim Aufrufen der Map-
View deaktiviert ist, ist die Grid-Ebene, die ein Raster auf die Map legt. Hierbei hat
jeden Feld die Größe 256 x 256 Pixel.
Die Simulation des Plans wird so lange laufen, bis eine von zwei Abbruchbedingungen
erfüllt ist:
1. Transportmittel-Akteure sind nach der Abarbeitung ihrer Jobs erfolgreich im Ausgangshafen
angekommen
2. Das geplante Zeitfenster wurde um 2 Stunden überschritten und mindestens ein
Transportmittel ist noch nicht im Ausgangshafen angekommen
436 p r i v a t e void handleNextIntervalMessage ( NextIntervalMessage
message ) {
437 i f ( message . getVehicleTurn ( ) ) {
438 i f ( s t a t u s == Status .RUNNING) {
439 t h i s . lastUpdate = System . c u r r e n t T i m e M i l l i s ( ) ;
440 f o r ( ActorRef r e f : t h i s . runningVehicleActors ) {
441 r e f . t e l l (new PositionRequest ( ControlPanel .SPEED,
weather [ weatherIndex ] ) , g e t S e l f ( ) ) ;
442 }
443 }
444 } e l s e {
445 f o r ( ActorRef r e f : t h i s . windmills ) {
446 r e f . t e l l (new PositionRequest ( ControlPanel .SPEED,
weather [ weatherIndex ] ) , g e t S e l f ( ) ) ;
447 }
448 }
449 }
Sorce Code 3: Ausschnitt zur Aktualisierung der Position von Akteuren
Der Code-Ausschnitt Simulation zeigt, wie die verschiedenen Akteure um eine Aktualisierung
ihrer Position gebeten werden. Im ersten Schritt wird, solange die Simulation
nicht pausiert wurde, die Zeit vor den Aktualisierungen gesichert, um später die Zeit
zu berechnen, die die Simulation warten muss bis das nächste Intervall gestartet wird.
Anschließend wird an jedes Transportmittel ein Anfrage der neuen Position hinsichtlich
der Simulationsgeschwindigkeit und des Wetters geschickt. Haben alle Transportmittel
geantwortet, so beginnt der zweite Schritt, in dem die WEAs dazu aufgerufen werden
den Status ihrer Jobs und ihre Ausfallzeiten neu zu berechnen.
150

7.5 Visualisierung des Plans 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 85: Die Abbildung zeigt die Darstellung der Kosten und den zeitlichen Ablauf des
Plans (Quelle: Eigendarstellung)
Im ersten Fall ist die Simulation des Plans erfolgreich abgeschlossen worden, sodass
dann die Bewertung der Kosten vorgenommen wird. Hierzu berechnet jeder Akteur die
für ihn angefallenen Kosten und gibt diese zurück. Zusätzlich wird eine aktualisierte
Version des Plans erzeugt, in dem die von der Optimierung vorgeschlagenen Start- und
Endzeitpunkte der Jobs durch die Simulationszeitpunkte ersetzt werden.
Im zweiten Fall konnte die Simulation des Plans nicht abgeschlossen werden. In dieser
Situation wird der Nutzer auf diesen Umstand über eine Fehlermeldung hingewiesen.
Unabhängig vom erfolgreichen Abschluss der Simulation folgt im Anschluss der Bewertung
die Darstellung der Bewertungsergebnisse, die im nächsten Abschnitt beschrieben
werden.
7.5 Visualisierung des Plans
Nach einem Simulationslauf und der anschließenden Bewertung wird das Resultat in der
EvaluationView (siehe Abbildung 85 Darstellung des Simulationsergebnisses) angezeigt.
Diese besteht aus zwei Teilen: Der Kostenübersicht und einer Darstellung verschiedener
Diagramme, die den Ablauf des Plans über die Zeit darstellen.
In der Kostenübersicht wird jeder Akteur seine während der Simulation erzeugten Kosten
zusammengeführt und gegenübergestellt. Hierbei ist zu beachten, dass die Kosten
eines Transportmittels zum einen aus den Charter- und Treibstoffkosten und zum anderen
aus den Personalkosten der Mitarbeiter, die diesem Schiff zugeteilt worden sind. Die
Kosten einer OWA berechnen sich aus dem Gewinnausfall, der Eintritt sobald die WEA
stillsteht. Der Gewinnausfall von defekten OWA, für die kein Job in der Planungsphase
151

7.5 Visualisierung des Plans 7 BESCHREIBUNG DER SOFTWARE SCOWS
vorgesehen wurde, werden bei der Kostenberechnung ignoriert, da diese unabhängig vor
erzeugten Plan anfallen. Am Ende der Kostenübersicht wird die Summe der Gesamtkosten
angezeigt.
Auf der rechten Seite der EvaluationView kann sich ein Nutzer verschiedene Diagramm
zum Plan anzeigen lassen. Die Auswahl findet über eine ComboBox am oberen Rand
statt. Zur Auswahl stehen folgende Diagramme:
SERVICE PLAN Dieses Diagramm zeigt die Abfolge der verschiedenen Jobs über den
Arbeitstag zeitlich hinweg an. Hierbei sind die Jobs farblich dem Transportmittel
zugeordnet, dem sie zugeteilt wurden. Jeder Job kann aus bis zu vier Abschnitten
bestehen. Die erste Phase zeigt die Zeit, die das Andocken an die WEA
und das übersetzen der Mitarbeiter in Anspruch nimmt. Phase zwei zeigt die
Durchführungszeit des Jobs. Die dritte Phase ist optional und taucht immer dann
auf, wenn wenn die Mitarbeiter untätig auf einer Anlage sind, also die Wartezeit.
Am Schluss folgt dann noch die Zeit, die für das erneute Andocken und aufnehmen
der Mitarbeiter anfällt.
JOB PLAN: Dieses Diagramm ist ähnlich dem ”
SERVICE PLAN ”
’-Diagramm nur werden
hier ausschließlich die Durchführungszeiten der Jobs dargestellt.
PERSONS WORKING: In diesem Diagramm wird gezeigt, wie viele Personen über die
Zeit am Durchführen eines Jobs beschäftigt sind. Die Zeitlinie fängt beim Start
des ersten Jobs an und hört mit beenden des letzten Jobs auf.
STAFF PER MILL: Hier wird angezeigt, wie viele Personen insgesamt für Jobs während
der Simulation auf einer Anlage waren.
STAFF PER WINDFARM: Ähnlich wie das vorherige Diagramm, nur werden die Anzahl
der Personen im ganzen Windpark dargestellt.
WORK PER VEHICLE: Dieses Diagramm veranschaulicht, hoch die Dauer aller Jobs
war, die auf ein Fahrzeug verteilt worden sind.
WORK PER WINDMILL: In diesem Diagramm wird ähnlich wie beim vorherigen Diagramm
die summierte Länge aller Jobs gezeigt, die auf einer Windkraftanlage
durchgeführt wurden.
WORK PER WINDFARM: Analog zu den vorherigen beiden Diagrammen, nur wird
hier die Summe der Jobdauern pro Windpark visualisiert.
Zum Verlassen der EvaluationView muss der entsprechende Button in der oberen rechten
Ecke geklickt werden, wodurch wieder auf die MapView zurückgekehrt wird und die
Simulation erneut gestartet oder eine neue Planung durchgeführt werden kann.
152

7.6 Installationsanleitung 7 BESCHREIBUNG DER SOFTWARE SCOWS
7.6 Installationsanleitung
Nachstehend wird beschrieben, wie die SCOWS-Software auf einem beliebigen Computer
installiert werden kann. Für allgemeine Probleme stehen Ihnen die Onlinedokumentationen
von Hibernate, MySQL oder Apache Tomcat zur Verfügung. Spezifische Nachfragen
wird Ihnen das Supportteam gerne nach Abschluss eines SLA (Service Level Agreement)
beantworten.
Client:
1. Es muss sichergestellt sein, dass ein aktuelles Betriebssystem (Linux, Mac OS X,
Microsoft Windows etc.) benutzen wird, welches eine generelle Verbindung zum
Internet herstellen kann.
2. Java 6 oder 7 muss bereits installiert sein
3. Die aktuelle Version des SCOWS-JSC herunterladen
4. Die JAR-Datei per Doppelklick ausführen
Server:
1. Ein Serverbetriebssystem entsprechend der Vorlieben (siehe Punkt 1 des Clients)
wählen und verwenden
2. Java 6 oder 7 installieren
3. Einen Java-Applikationsserver wie zum Beispiel Apache Tomcat bereitstellen (ab
Version 7)
4. Eine Datenbank wie zum Beispiel MySQL ab Version 5.5 einrichten
5. Die SCOWS-Backend-WAR-Datei in den Ordner des Applikationsservers kopieren
und warten bis diese entpackt wurde (oder manuell entpacken)
6. Gegebenenfalls die Konfigurationsdatei von Hibernate anpassen
7. Nach einem Neustart des Applikationsservers steht die Anwendung für den ersten
Einsatz bereit.
8. Allen Benutzern eine entsprechend angepasste Version der Applikationskonfiguration
vorlegen
153

7.6 Installationsanleitung 7 BESCHREIBUNG DER SOFTWARE SCOWS
Abb. 86: Heuristik Sequenzdiagramm (Quelle: Eigendarstellung)
154

8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
8 Testszenarien, Validierung und Evaluation
Generell treten bei der Softwareentwicklung Fehler auf, die in sich in Form von Bedienungsproblemen,
Abstürzen oder Einfrieren des Programms bemerkbar machen. Um
eine vollständige Fehlervermeidung zu erreichen, muss getestet und Fehlerquellen beseitigt
werden. Diese Aussage trifft auch auf die Softwareentwicklung der PG-SCOWS zu.
Um die Richtigkeit der Softwarefunktionalitäten zu gewährleisten, wurde die Software
getestet und durch User-Tests abgeglichen. Die Teststrategien werden von den Softwareentwickler
festgelegt, um eine möglichst hohe Funktionsabdeckung zu gewährleisten,
wurden verschiedene Testläufe erstellt und genutzt.
8.1 Testdokumentation
Der folgende Abschnitt behandelt die am Produkt durchgeführten Tests. Im Wesentlichen
wird hierbei zwischen Modul- und Systemtest unterschieden. Integrationstests wurden
nicht gesondert dokumentiert, sondern sind Bestandteil des Systemtests. Im Rahmen
der Modultests werden vor allem einzelne Klassen und Methoden hinsichtlich ihrer zu liefernden
Ergebnisse getestet. Im Rahmen des Systemtests wird das Produkt hinsichtlich
der vorab definierten Anforderungen getestet. Anschließend wird der Grad der Zielerreichung
ermittelt und evaluiert, ob das Ziel, sämtliche Anforderungen zu implementieren,
erreicht wurde.
8.1.1 Modultests
Sämtliche Modultests (sprich: Tests von Klassen und Methoden) wurden mithilfe der
Testumgebung ”
JUnit“ 37 durchgeführt. Bei JUnit handelt es sich um ein Framework,
welches wiederholbare Modultests für Java-Programme ermöglicht. JUnit erzeugt immer
nur zwei mögliche Testergebnisse: Entweder schlägt der Test fehl, oder er schlägt nicht
fehl. Bei fehlschlagenden Tests handelt es sich entweder um Fehler (Errors) oder falsche
Ergebnisse (Failures), die jeweils durch eine Exception mitgeteilt werden. Durchläufe
ohne Fehler werden als ”
Runs“ bezeichnet.
Sämtliche serverseitigen Modultests befinden sich im Verzeichnis scows-backend/test,
die clientseitigen Tests befinden sich im Verzeichnis scows-utils/test. Die Testergebnisse,
der Verlauf der Testabdeckung usw. sind darüber hinaus in der Integrationsumgebung
Jenkins festgehalten und nachprüfbar.
Die Grafik 87 Verlauf der Testabdeckung zeigt den Verlauf der Modultestabdeckung,
wobei deutlich wird, dass nicht testgetrieben entwickelt wurde, sondern die Tests erst
nach Entwicklung der Software geschrieben wurden (Whitebox-Tests). Diese Methode
gewährte zunächst größere Freiheiten beim Development, weshalb die Entscheidung
dahingehend fiel. Die Modultests waren, nach einigen Fehlerkorrekturen, abschließend
sämtlich erfolgreich, sodass von funktionierenden Modulen ausgegangen werden kann.
37 http://JUnit.org/
155

8.1 Testdokumentation8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 87: Verlauf der Testabdeckung (Quelle: Eigendarstellung)
8.1.2 Testfälle für Modultests (exemplarisch)
Im folgenden Abschnitt werden einige durchgeführte Testfälle exemplarisch beschrieben.
Der erste Test wird ausführlicher beschrieben, um die Vorgehensweise nachvollziehbar
zu gestalten.
8.1.2.1 Test für scows-backend/src/org/scows/backend/heuristic/Cluster.java
Die Klasse Cluster hält einen Cluster mit Job-Liste, Zeitfenster, Clusterzentrum und dem
jeweiligen Transportmittel. Zudem verfügt sie über eine Methode das Clusterzentrum
zu berechnen sowie diverse Get- und Set-Methoden. Die Klasse ist in Abbildung 88
Klassendiagramm von Cluster.java als Klassendiagramm dargestellt.
Der Test für die Methode zur Neuberechnung des Clusterzentrums sieht wie folgt
aus. Als Vorbedingung werden zunächst Testdaten initialisiert (Annotation: @Before).
Daraufhin werden nun innerhalb einer Test-Methode folgende Fälle mittels den von
JUnit zur Verfügung stehenden assert*-Methode überprüft:
JUnit bildet das Ergebnis des Tests in den Entwicklungsumgebung Eclipse wie folgt
ab:
Sämtliche weiteren Tests sind analog durchgeführt worden. Auf eine Darstellung der
JUnit-Ausgaben wird daher verzichtet. Es werden lediglich Testfälle, Erwartungswerte
und Ergebnisse dargestellt.
8.1.2.2 Tests: scows-backend/src/org/scows/backend/heuristic/Clustering.java
Die Klasse Clustering.java dient zur Erstellung der geographischen Cluster. Sie ordnet
die geographisch nah beieinander liegenden Jobs einem Cluster zu. Dies erfolgt in
Abhängigkeit der Menge der zur Verfügung stehenden Transportmittel.
156

8.1 Testdokumentation8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 88: Klassendiagramm von Cluster.java
Abb. 89: Testfälle für Cluster.java
Abb. 90: Erfolgreicher JUnit-Test (Quelle: Eigendarstellung)
8.1.2.3 Tests: scows-backend/src/org/scows/backend/heuristic/Estimator.java
Die Estimator-Klasse dient zur Berechnung möglicher ”
Transportmittelkombinationen“
zur Durchführung einer Menge von Jobs in einem OWP. Sie erhält eine Job-Liste, eine
Transportmittel-Liste, das Zeitfenster und weitere Parameter, um mögliche Kombinationen
zu berechnen.
157

8.2 Systemtest 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 91: Klassendiagramm von Clustering.java
Abb. 92: Testfälle für Clustering.java
8.2 Systemtest
Der Systemtest wird anhand der entwickelten GUI durchgeführt. Sämtliche Anforderungen
und Anwendungsfälle werden hierbei geprüft. Es werden sowohl Regelfälle (korrekte
und vollständige Dateneingabe), sowie Grenzfälle (keine oder unvollständige Dateneingabe)
geprüft. Im Rahmen dieses Tests soll sichergestellt werden, dass sämtliche in der
Anforderungsdefinition (Kapitel 5 Anforderungsanalyse) aufgeführten Bestandteile implementiert
wurden.
158

8.2 Systemtest 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 93: Klassendiagramm von Estimator.java
8.2.1 Simulation
Die Simulationskomponente erwartet von der Optimierungskomponente einen Einsatzplan.
Dieser Einsatzplan wird daraufhin hinsichtlich seiner Machbarkeit geprüft. Somit
ist einziger Eingabeparameter für die Simulation ein Einsatzplan von der Simulationskomponente.
Dieser wird durch einen REST-Webservice von der serverseitigen Optimierungskomponente
an die clientseitige Simulationskomponente übertragen. Darüber hinaus
dient die Simulationskomponente zur Visualisierung der ermittelten Einsatzpläne.
Einige der für die Simulation definierten Anforderungen haben sich im Laufe der Entwicklung
des Produkts als obsolet erwiesen, da sie entweder keinen Mehrwert boten oder
weil sie von anderen Komponenten des Produkts übernommen wurden. So ist in den Anforderungen
vorgesehen, dass der Einsatzplan während der Simulation angezeigt werden
kann, die für die Wartung benötigten Ressourcen und die Dauer der Wartungsarbeiten
sollten ebenfalls visualisiert werden. Dies wurde so allerdings nicht implementiert, da der
Einsatzplan erst nach erfolgreicher Simulation dargestellt wird, dazu zählt auch Ressourceneinsatz
und Dauer einzelner Wartungsjobs, sowie deren Anordnung usw. Hierfür stehen
verschiedene Visualisierungswerkzeuge zur Verfügung, wie beispielsweise Diagramme
und Tabellen. Darüber hinaus wurde festgelegt, dass die Simulation die kosten- und
159

8.2 Systemtest 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 94: Testfälle für Estimator.java
zeiteffizienteste Transportmittelalternative ermitteln solle. Im Produkt ist dies Bestandteil
der Optimierungskomponente. Die Simulation legt keinerlei Transportmittel oder
ähnliches fest. Außerdem war zunächst vorgesehen, Wetterbedingungen visualisieren zu
können. Dies umzusetzen war nicht möglich, da die Simulation auf Basis einer Seekarte
dargestellt wird. Wettereinflüsse sind auf einfachen Karten nicht sinnvoll darstellbar.
Sämtliche weiteren aufgeführten Anforderungen wurden erfolgreich implementiert.
8.2.2 Optimierung
Im Rahmen der Entwicklung der Optimierung war Anforderung, dass verschiedene Verfahren
zur Verfügung stünden. Da zwei Verfahren implementiert wurden, gilt diese Anforderung
als erfüllt. Die Details zu den jeweiligen Verfahren sind in den vorangegangenen
Kapiteln aufgeführt. Die Optimierungskomponente sollte darüber hinaus hinsichtlich
bestimmter Zielgrößen optimieren. Hierbei hat sich die Zielgröße Kosten als die
aus betriebswirtschaftlicher Sicht wichtigste und sinnvollste Größe herausgestellt, da
sie sowohl Effizienz der Arbeit, als auch Zeit indirekt abbildet. Entsprechend optimieren
beide Verfahren (RS und SG) hinsichtlich der Zielgröße Kosten. Sämtliche Pläne
entsprechen zudem immer den Constraints, da fehlerhafte Einsatzpläne bereits bei der
Berechnung eben jener ausgeschlossen werden. Die Laufzeit der Optimierungskomponenten
ist darüber hinaus in einem kurzen zeitliche Rahmen gehalten, so dass keine langen
Wartezeiten entstehen, die Optimierungskomponente ist serverseitig entwickelt worden
und kann auf einem Webserver (Tomcat, Jetty etc.) deployed werden.
Als Parameter erwartet die Optimierungskomponente Daten aus der Scheduling-View,
also derjenigen View, in welcher der Tageseinsatz geplant wird. Dabei werden Transportmittel,
Jobs, Zeitfenster und alle weiteren notwendigen Daten übergeben. Dies wird
160

8.3 Validierung 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
ebenfalls durch einen REST-Webservice implementiert. Der Aufruf der Optimierung ist
erst möglich, sobald sämtliche Daten korrekt und vollständig eingegeben wurden. Ein
fehlerhafter Aufruf mit unvollständigen oder nicht korrekten Daten ist daher abgefangen
und damit ausgeschlossen.
8.2.3 Scheduling
Die Scheduling-Komponente dient dem Anwender des Produkts zur Zusammenstellung
der Tagesplanung der Servicefahrten. Hier werden Schiffe, Jobs, Zeitfenster etc. geplant.
Sie ist der Optimierungskomponente vorgeschaltet und dient als Ausgangspunkt der
Planung.
Die hauptsächlichen Funktionalitäten des Scheduling sind im Wesentlichen durch die
Drag&Drop-Implementierungen gelöst. Eine Anforderung war es, die Scheduling-View
gemäß unterschiedlicher Usability-Aspekte möglichst intuitiv bedienbar zu gestalten.
Demnach wurde die Oberfläche insgesamt auf das Wesentliche beschränkt und durch
einfache, dem Nutzer wahrscheinlich schon bekannten Bedienelementen (Drag&Drop,
Dropdown-Menüs, Checkboxen, usw.) umgesetzt.
8.3 Validierung
In Kapitel 5 Anforderungsanalyse sind sämtliche Anforderungen an das Produkt festgehalten.
Die Anforderungen an die Optimierung sind ebenfalls in diesem Kapitel zu
finden. Die wichtigsten an den Algorithmus gestellten Anforderungen lauten:
• Optimierung hinsichtlich einer definierten Zielgröße,
• Einhaltung der in Kapitel 5 Anforderungsanalyse definierten Constraints,
• Kurze Laufzeit, um Usability-Einschränkungen zu vermeiden.
Der Algorithmus berechnet in mehreren Teilschritten, welche in vorangegangenen Abschnitten
bereits beschrieben wurden, einen optimalen Plan bei gegebenen Daten (Menge
der Transportmittel, Menge der Jobs, Transportmittelgeschwindigkeit, Treibstoffkosten,
fixe Kosten etc.). Der Algorithmus berechnet eine Annäherung an das Optimum hinsichtlich
der Zielgröße Kosten. Die Constraints werden darüber hinaus bei der Berechnung
der Pläne on the fly eingehalten. Ungültige Pläne werden somit von vorn herein vermieden.
Die Laufzeit hat sich in mehreren Testläufen stets linear verhalten. Die Laufzeit ist
auch bei größeren Datenmengen (100 Jobs, 10 Schiffe) stabil bei unter fünf Sekunden.
8.4 Evaluation
Beide Algorithmen werden anhand eines vorgegebenen Szenarios evaluiert. Dieses beinhaltet
vier unterschiedliche Schiffe, wobei drei in Norddeich liegen und eines in Wilhelmshaven.
Darüber hinaus beinhaltet dieses Szenario neun unterschiedliche Jobs an unterschiedlichen
OWAs. Der OWP (SCOWS Array) ist ein fiktiver OWP mit 100 WEAs,
161

8.4 Evaluation 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
der bei Alpha Ventus in der Nordsee positioniert wurde. Es wird darüber hinaus ein
Zeitfenster von 06:00 Uhr morgens bis 18:00 abends vorgegeben. Ziel ist es, sämtliche
Jobs durchzuführen, aber gleichzeitig die Gesamtkosten für diesen Einsatz so niedrig wie
möglich zu halten.
8.4.1 Szenario
Grunddaten:
• Benzinpreis: 1,39 Euro pro Liter
• Stundensatz für Arbeiter: 100 Euro
• Übersteigezeit: 20 Minuten
• Feed-in Compensation: 0,13 Euro pro glsMW
• Auf See wird 80% der Maximalgeschwindigkeit gefahren
Schiffe
• Eval Ship 1 (Passagiere: 24, Geschwindigkeit 24 kn, Charterkosten 4500, Hafen
Norddeich, Treibstoffkosten: 110 kg/h)
• Eval Ship 2 (Passagiere: 12, Geschwindigkeit 25 kn, Charterkosten 3500, Hafen:
Wilhelmshaven, Treibstoffkosten: 130 kg/h)
• Eval Ship 3 (Passagiere: 28, Geschwindigkeit 18 kn, Charterkosten 4500, Hafen:
Norddeich, Treibstoffkosten: 130 kg/h)
• Eval Ship 4 (Passagiere: 22, Geschwindigkeit 22 kn, Charterkosten 3000, Hafen:
Norddeich, Treibstoffkosten: 120 kg/h)
Jobs
• Eval 15 (Dauer: 210 Minuten, Mitarbeiter: 3, WEA T15)
• Eval 29 (Dauer: 30 Minuten, Mitarbeiter: 3, WEA T17)
• Eval 21 (Dauer: 360 Minuten, Mitarbeiter: 4, WEA T19)
• Eval 27 (Dauer: 180 Minuten, Mitarbeiter: 5, WEA T27)
• Eval 31 (Dauer: 120 Minuten, Mitarbeiter: 5, WEA T29)
• Eval 39 (Dauer: 270 Minuten, Mitarbeiter: 3, WEA T37)
• Eval 66 (Dauer: 390 Minuten, Mitarbeiter: 5, WEA T66)
• Eval 82 (Dauer: 420 Minuten, Mitarbeiter: 5, WEA T82)
• Eval 99 (Dauer: 420 Minuten, Mitarbeiter 3, WEA T97)
162

8.4 Evaluation 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
8.4.2 Ergebnisse
In diesem Abschnitt werden die Ergebnisse der jeweiligen Algorithmen dargestellt, wobei
zwischen Kosten pro WEA und Kosten pro Schiff aufgeschlüsselt wird. Darüber hinaus
werden die jeweils durchgeführten Jobs als Gantt-Chart dargestellt.
8.4.2.1 RS-Algo
Der [RS-Algo] berechnet für das oben beschriebene Szenario Gesamtkosten von 57318
Euro. Hierin enthalten sind Gewinnausfallkosten, Charterkosten, Lohnkosten und Treibstoffkosten.
Der Algorithmus wählt die Schiffe Eval Ship 1 (19 Mitarbeiter an Bord) und
Eval Ship 4 (14 Mitarbeiter an Bord) zur Durchführung des Szenarios aus.
Kosten pro Schiff:
Kosten pro WEA:
Abb. 95: Kosten pro Schiff [RS-Algo]
Abb. 96: Kosten pro Anlage [RS-Algo] (Quelle: Eigendarstellung)
163

8.4 Evaluation 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Gantt-Chart:
Abb. 97: Gantt-Chart [RS-Algo] (Quelle: Eigendarstellung)
164

8.4 Evaluation 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
8.4.2.2 SG-Algo
Im Folgenden werden die Ergebnisse des Tests [SG-Algo] visualisiert. In dem Test werden
insgesamt neun Jobs geplant, wofür laut der Optimierung ein Schiff mit 25 Passagieren
benötigt wird. Die Planung und Verteilung der Jobs geschieht im Rahmen der vorgegebenen
Arbeitszeit (Zeitfensters). Es ist zu erkennen, dass manche Jobs quasi ”
parallel“
ausgeführt werden und manche ”
sequenziell“. Durch diese Vorgehensweise, die in dem
[SG-Algo] umgesetzt wird, wird sichergestellt, dass ein Transportmittel soweit ausgelastet
wird, wie es möglich ist.
Das ”
Eval Ship 3“ hat eine Kapazität von 28 Passagieren. Alle Arbeiten an den OWAs
benötigen jedoch nur 25 Mitarbeiter. Durch die Ermittlung aller möglichen Kombinationen,
wird noch geprüft, welche Transportmittelkombinationen günstig sind. Das günstigste
wird dementsprechend dann gewählt. Die Abbildung 98 Gantt-Chart (SG-Algo)
stellt das Ergebnis dar.
8.4.2.3 Vergleich beider Algorithmen
Wenn die Ergebnisse der Ausführung dieses Testfalls mit den beiden Algorithmen ausgewertet
werden, so kann erkannt werden, dass der [SG-Algo] in diesem Fall einen besseren
Plan zeigt, da hier, wie bereits beschrieben, nur ein Schiff und lediglich 25 Mitarbeiter
benötigt werden. Das führt dementsprechend zu geringeren Kosten für die OWP-
Betreiber. Es ist jedoch nicht vorherzusagen, welcher Algorithmus in welchem Fall das
bessere Ergebnis zurückliefert, weshalb im Projekt und in dem Prototypen beide Algorithmen
zur Verfügung stehen.
Zudem haben wir aber deutliche Unterschiede bei der Optimierungszeit zu verzeichnen.
Es ist jedoch anzumerken, dass es nicht unbedingt der optimale Plan gefunden wird,
sondern ein guter Plan. Die Tabelle 12 Durchlaufzeiten der Optimierungen im Vergleich
veranschaulicht diese noch einmal. Die erste beiden Spalten geben den verwendeten Algorithmus
und Namen des Tests an. Die dritter und letzte Spalte zeigen die Durchlaufzeit
und ob der Algorithmus einen Plan liefern konnte.
Verwendeter Algorithmus Testname Durchlaufzeit Status
[RS-Algo] testOutOfTimeCaseH 7.8 sec Passed
[SG-Algo] testOutOfTimeCaseR 67 ms Passed
[RS-Algo] testStandardCaseH 0.1 sec Passed
[SG-Algo] testStandardCaseR 8 ms Passed
[RS-Algo] testStefansCaseH 0.31 sec Passed
[SG-Algo] testStefansCaseR 9 ms Passed
Tbl. 12: Durchlaufzeiten der Optimierungen im Vergleich (Quelle: Eigendarstellung)
165

8.4 Evaluation 8 TESTSZENARIEN, VALIDIERUNG UND EVALUATION
Abb. 98: Gantt-Chart [SG-Algo] (Quelle: Eigendarstellung)
166

9 ZUSAMMENFASSUNG
9 Zusammenfassung
Die Projektarbeit wurde mit dem Ziel durchgeführt sich in das neue und noch recht unbekannte
Forschungsgebiet der Offshore-Windenergie einzuarbeiten. Die Probleme, die zur
Zeit vorherrschen, betreffen zum einen die Wartungen der OWAs aber auch schon vorher
ist eine intensive Auseinandersetzung mit der Planungsphase nicht zu unterschätzen.
Anders als ”
onshore“ können Wartungsarbeiten nicht einfach und unkompliziert an den
WEAs durchgeführt werden. Wie in Grundlagenkapiteln der Seminararbeiten folgerichtig
erschlossen werden konnte, gibt es einige unumgängliche Faktoren, die einem die
Instandsetzung und Wartung erschweren. Eine kurze Auflistung der gewonnen Erkenntnisse
lautet:
• Die OWAs sind nicht frei zugänglich, da diese logischerweise auf dem offenen Meer
stehen. Dementsprechend kann keine der einzelnen WEAs ohne ein spezielles Transportmittel
erreicht werden.
• Spezielle Transportmitteltypen können nur zum Einsatz kommen. Unterschieden
wird generell in Schiff und Helikopter. Diese können dann auch wieder verschieden
in ihrer Kategorie sein, zum Beispiel in der Transportkapazität, Geschwindigkeit
und dergleichen.
• Des Weiteren gelten für die unterschiedlichen Transportmitteltypen auch unterschiedliche
Sicherheitsaspekte. Es wird deutlich, dass die Vorschriften bei einem
Helikoptereinsatz immens hoch für das Fachpersonal und die Piloten sind.
• In der Auseinandersetzung mit den Transportmitteln wird schnell deutlich, dass
Helikopter im erheblichen Maße teurer sind als Schiffe, was den Einsatz von diesen
in der Regel sehr schnell unrentabel macht.
• Allerdings kann mit einem Schiff nicht bei jeder Wettersituation ein Wartungsjob
durchgeführt werden. Handelt es sich nun um dringende Aufträge oder ist der
Gewinnausfall einer OWA deutlich über den kalkulierten Kosten für einen Helikoptereinsatz,
dann kommen diese zum Tragen.
• Ein positiver Nebeneffekt ist, dass der Transport mit einem Helikopter wesentlich
schneller (abhängig von der Entfernung des Starts) zum OWP gelangt.
• Neben den zeitlichen Aspekten erfordert ein Schiff einen erhöhten Navigationsaufwand,
auch wenn ähnliches für Helikopter gilt.
• Ein OWP umfasst eine unbestimmte Menge n an WEAs. Je größer dieser wird,
desto höher ist der logistische Aufwand diesen in Betrieb zu halten, zu warten oder
Instand zusetzen.
• Es gibt generell drei verschiedene Möglichkeiten OWPs anzulaufen bzw. Service-
Arbeiten ausführen zu lassen. Im Moment bietet die Infrastruktur hauptsächlich in
167

9 ZUSAMMENFASSUNG
der Nähe von deutschen Gewässern das Durchführen der Jobs durch die Versorgung
über die deutschen Häfen an der Nord- sowie Ostseeküste. Bei entfernteren OWPs
bieten sich für kleinere Wohn- und Wartungsinseln an, die jedoch auch versorgt
werden müssen. Ausgebaut werden zur Zeit Inselstützpunkte wie Helgoland, die
sich besonders für Wartungszwecke einsetzen lassen.
Im Rahmen der Projektgruppe musste festgelegt werden, worauf der Schwerpunkt dieses
Forschungsprojektes liegen soll. Dies hat sich schon teilweise während der Seminarphase
aufgetan, aber wirklich verschärft hatte es sich in den Experteninterviews mit den
Branchenkennern. Eine langfristige Planungsphase ist sicherlich auch interessant, jedoch
konzentrierten wir uns im Projekt SCOWS auf die kurzfristige Planungsphase. Entwickelt
wurde daher ein Prototyp für die Tageseinsatzplanung.
Die Kernbereiche der umzusetzenden Software bezogen sich deshalb insbesondere auf
die Aspekte:
• Simulationsplanungswerkzeug
• Identifizierung von Jobs für die Tagesplanung
• Optimierung von Kosten, Ressourcen und Zeit
• Unter den Randbedingungen wie die Einhaltung von HSE-Aspekten, Arbeitszeiten,
harten Wetterbedingungen, Transportmitteln und weitere.
Um eine Software zu entwickeln, die es in diesem Umfang noch nicht gibt, wurden verschiedene
Konzepte entworfen. Aus den Kernbereichen haben sich vier Module ergeben.
Ein Teilbereich wird durch die graphischen Benutzerführung, der GUI bestimmt, die
eine besondere Rolle spielt. Über diese interagiert der Planer mit dem Programm und
übermittelt seine ”
Wünsche“. Gemeint ist damit, welche Transportmittel zur Verfügung
stehen, welche Jobs verplant werden sollen und wie das Zeitfenster für den Arbeitstag
aussieht.
Als weiteres Modul hat sich die Planungsebene, näher bezeichnet als Scheduling herauskristallisiert.
Diese dient dazu, dass der Planer die Tageseinsatzplanung einfach und
unkompliziert gestalten kann. Ergänzt wird dieses Modul durch eine Datenverwaltung.
Die Datenbank enthält jegliche Daten, um einen Tageseinsatzplan aufstellen zu können.
Hierbei handelt es sich zum Beisiel um Daten über OWPs, OWAs, Transportmittel,
Häfen und den dazugehörigen Tonnenstrich, Jobs, Mitarbeiter usw. Diese Modul ist eng
mit dem Modul GUI verknüpft und mussten aufeinander abgestimmt und angepasst
werden.
Anhand der übergebenen Daten vom Scheduling nach dem Starten der Optimierung
wird ein möglichst guter Plan erstellt, der sowohl die Kosten minimiert als auch die HC
einhält. Konnte ein Plan erstellt werden, so wird der Plan der Simulation übergeben, die
nun überprüft, ob der Plan auch unter dem Einfluss vom Wetter und Andockmanövern
und dergleichen durchzuführen ist. Das Simulationsmodul visualisiert dem Benutzer den
168

9.1 Fazit 9 ZUSAMMENFASSUNG
Tageseinsatzplan. Ist der erzeugte Plan gültig und durchführbar, wird das Ergebnis dem
Planer ausgegeben, ansonsten wird eine Meldung zurückgeliefert.
Das Ergebnis wird in Diagrammen und Grafiken dargestellt und die Kosten werden
aufgeschlüsselt. Dadurch erhält der Planer eine Einsicht, wie viel beispielsweise der Einsatz
eines Schiffes kostet, aufgeteilt in die zu erwartenden Charter- und Treibstoffkosten
und wie lange die Mitarbeiter aktiv wo arbeiten werden.
Der implementierte Prototyp SCOWS deckt genau diese identifizierten Kernbereiche
ab. Wie zu jedem Softwareprojekt gehören neben der Entwicklung auch das Testen, Validieren
und Evaluieren. Erst nach dem die einzelnen Module zusammengefügt wurden,
sind Testszenarien entwickelt worden. Vorher waren die Entwicklerteams eigenverantwortlich.
Außerdem ist zum Ende hin das Projekt anhand der erhobenen Anforderungen
geprüft worden. Eine deutlich schwierigere Angelegenheit ist die Evaluierung der
Optimierung, da weder von den Betriebsbüros ein kompletter und ausführlicher Tageseinsatzplan
zur Verfügung gestellt werden kann noch Vergleichsmodelle zu finden sind.
Aus diesem Grund sind die beiden Optimierungsverfahren [RS-Algo] und [SG-Algo] gegenübergestellt
worden. Es kann jedoch nicht ermittelt werden, welcher der beiden Algorithmen
besser ist, da in manchen Fällen der eine Algorithmus einen günstigeren und
effizienteren Tageseinsatzplan hervorbringt und mal der andere.
9.1 Fazit
In diesem Projekt wurde viel Wert darauf gelegt, dass die Entwickler flexibel und damit
äußerst agil arbeiten und mitwirken können. Um diesem Vorgehen gerecht zu werden,
wurde das Projekt mit einer Mischform vom Wasserfallmodell und Scrum durchgeführt.
Dadurch kann der Projektleitung etwas Arbeit abgenommen bzw. auf andere aufgeteilt
werden und jeder muss Verantwortung mittragen. Das heißt, die Projektleitung bekommt
zum Großteil organisatorische Aufgaben, wie der Organisation der Projektmeetings. Die
Überwachung des Projektes obliegt zwar auch der Projektführung, wird aber durch jedes
Projektmitglied mitgetragen. Die Aufgabenverteilung ist in der Regel weniger hierarchisch
delegiert, sondern viel mehr der projektspezifischen und persönlichen Entwicklung
unterlegen. Aus diesem Grund kann die Projektleitung über die organisatorische Funktion
hinaus auch selber im Projekt verwirklichen.
Der Ablauf der Projektmeetings ist anfangs, also während der Seminarphase durch die
Seminarthemen bestimmt gewesen. Jedes Teammitglied hat sich einem Schwerpunktthema
nach eigenen Vorstellungen gewidmet. Die Grundlagen wurden von jedem zusammengetragen,
präsentiert und verschriftlicht. Bei umfassenderen Themenbereichen ist in
Rücksprache mit den Projektbetreuern der Schwerpunkt näher spezifiziert worden. Zum
Beispiel wurde das Thema ”
Entwurfsmethoden“ angeboten, im Endeffekt wurde aber nur
SCRUM vorgestellt und anderen Entwurfsmethoden gegenübergestellt und mit Vorteilen
bzw. Nachteilen verglichen. Die Vorträge wurden entsprechend der chronologisch Reihenfolge
gehalten. An einem Projektmeeting von ca. 1 1/2 Stunden bis 2 Stunden konnten
zwei oder drei Präsentation durchgeführt werden mit je 20 bis 30 Minuten für den Referenten
plus Diskussionsbedarf, der teilweise noch einmal genauso viel zeit in Anspruch
genommen hat. Nebenbei sind Experteninterviews geführt worden. Die Seminarphase ist
169

9.1 Fazit 9 ZUSAMMENFASSUNG
mit der Problemdefinition und Anforderungserhebung abgeschlossen worden. Aus diesen
ergaben sich einzelne Module, die umgesetzt werden sollen. Jedes Projektmitglied hat
einen Schwerpunktthema gewählt, aber nicht jedes Thema kann umfassend im Projekt
Beachtung finden. Das Team teilt sich auf die einzelnen Modulen auf, wodurch kleinere
Projektteams innerhalb des Projektes gegründet wurden. Ab diesem Zeitpunkt verliefen
die Projektmeetings nach anderen Regeln. Ein typische Ablauf ist dabei:
1. Begrüßung und Organisation
• Protokollant nimmt seine Arbeit auf (alphabetische Reihenfolge)
• Moderation und Zeitnehmer ist der vorherige Protokollant
• Termine besprochen; Nutzung von Projektmanagementtools usw.
2. Kurze Berichte der einzelnen Modulteams
• Status
• Letztes Arbeitsergebnis beschrieben
• Weiteres Vorgehen
3. Größere Teilprojekte besprochen
• Visualisierung des aktuellen Zustands
• Probleme erläutern; unter Umständen können diese schnell gelöst werden, ansonsten
setzt sich dann ein zeitlich freieres Projektmitglied damit auseinander
4. Neue Arbeitspakete zusammengestellt
5. Sonstiges
Dadurch, dass jeder im Projekt seine Sicht der Dinge bei größeren Problemen offerieren
konnte, ist nicht immer alles Zielgerichtet gelaufen, musste vertagt werden oder es wurden
gar zwei verschiedene Lösungswege verfolgt. Dies wiederum führt unweigerlich dazu, dass
andere Bereiche erst später aufgearbeitet werden können. Außerdem ist es ungünstig,
wenn es zwei vollkommen unterschiedliche Auffassungen gibt. In dieser Hinsicht wäre
es sinnvoll gewesen, wenn es ein stärker hierarchisch ausgebildetes Projektmanagement
gegeben hätte.
Der implementierte Prototyp setzt viele Anforderungen gut und sinnvoll um und ist
in mancher Hinsicht interessant und elegant gelöst. Die Optimierung ist jedoch noch
ausbaufähig, da noch nicht alle Aspekte bis zum Ende richtig umgesetzt sind, da hier
Erfahrungswerte fehlen. Außerdem wird in der Simulation nicht jede Seefahrt den Seerouten
entsprechend beachtet. Zwar wurde in den Expertengesprächen gesagt, dass der
Kapitän eines Schiffes oder eben der Pilot eines Helikopters entscheidet wie zum Ziel
gelangt wird, aber dies sollte trotzdem noch einmal durchdacht werden. In diesem Projekt
ist als Kernbereich die Simulation von Servicearbeiten im Bezug zur OWA und den
zur Verfügung stehenden Transportmitteln gesetzt worden. Vernachlässigt wurden daher
170

9.2 Ausblick 9 ZUSAMMENFASSUNG
die Aspekte der Mitarbeiterqualifikation und die damit unterschiedlichen Personalkosten.
Mit dieser Software wird die Entscheidungsfindung eines Tageseinsatzplan deutlich
erleichtert werden können. Vor allem wenn die Komplexität der OWPs sehr viel größer
werden. Dann ist es für den Planer nicht mehr einfach einen effizienten und möglichst
kostengünstigen Tageseinsatzplan zu erstellen. Des Weiteren werden Jobs für einen Zeitraum
in die Datenbank übertragen. Zur Zeit wird davon ausgegangen, dass der Benutzer
der Software weiß, was er oder sie da tut. Das heißt, wenn ein Job verplant wurde, wird
dies entsprechend deklariert. Aber sollte der Job nun nicht durchgeführt werden, durch
plötzliche und unerwartet Wettereinflüsse, ein vorhergehender Job konnte nicht bzw. nur
mit erheblicher Verspätung erledigt werden und dadurch konnten andere Jobs ebenfalls
nicht durchgeführt werden, müssen diese wieder in das System aufgenommen werden.
Was jedoch mit diesem Projekt bestätigt werden kann, dass eine Software als Entscheidungsunterstützendes-System
sehr viel Potenzial bietet. Zum einen kann die Aufstellung
eines Tageseinsatzplans deutlich erleichtert werden und außerdem effizienter bzw. Kosten
minimierend eingesetzt werden. Es gibt zur Zeit jedoch keine Referenzmodelle für
solch eine Software. Der nächster offene Punkt steht nun an zu prüfen, inwieweit und
wie viel damit eingespart bzw. optimiert werden kann.
Wie in vielen studentischen (Forschungs-)Projekten gibt es auch in diesem Projekt
Hürden zu überwinden. Einige haben sich voll in die Aufgaben reingehängt und andere
sahen dies als unfreiwillige dafür aber lästige Pflichtveranstaltung an. Was definitiv
sehr ungünstig für den Projektverlauf war, ist die Tatsache, dass einige frühzeitig nicht
mehr richtig am Projekt teilnehmen konnten, beispielsweise aufgrund eines Auslandssemesters.
Trotzdem ist es an dieser stelle erwähnenswert, dass auch aus dem Ausland
versucht wurde, weitere Aufgabenpakete zu erledigen. Manches war durch Abspracheproblemen
und zeitlichen Unterschieden sicherlich nicht einfach. Eine weitere Sache, die
kritisch zu äußern ist, bezieht sich auf die Bewältigung von Aufgaben. Es gibt Aufgaben,
die Hilfe von anderen Projektmitgliedern, von außen oder sonst woher notwendig sind.
Aber damit geholfen werden kann, muss dies kommuniziert werden. Aufgabenpakete als
erledigt zu sehen, die offensichtlich nicht erledigt sind oder über Monate hinweg nicht
gelöst werden konnten, ist teilweise sehr unfair gegenüber denen, die das Projekt ernst
nehmen. Ein weiteres Problem ist, dass der Umgang untereinander zum Teil äußerst
feindselig war. Natürlich ist es wichtig unterschiedlicher Meinungen zu sein, aber niemand
darf persönlich angegriffen oder hintergangen werden. Letztendlich kann aber von
einem sehenswerten Ergebnis gesprochen werden. Jeder hat seine Erfahrungen über diese
eine Jahr mit der Projektgruppe gemacht, sowohl im negativen als auch positiven Sinne.
Wir sind uns jedoch einig, dass jeder was dazugelernt hat. Der eine mehr als der andere,
aber so ist das in Projekten nun einmal.
9.2 Ausblick
Das entwickelte Produkt ist als solches keineswegs als eine fertige Software zu betrachten,
die bereits sinnvoll eingesetzt werden kann. Vielmehr handelt es sich um einen ersten
Versuch, die Planung von Servicefahrten an OWPs algorithmisch zu lösen und hinsichtlich
Validität der Planungsergebnisse zu simulieren. Ziel war es hierbei, für menschliche
171

9.2 Ausblick 9 ZUSAMMENFASSUNG
Planer von Servicefahrten ein Entscheidungsunterstützungssystem zu liefern, welches die
Serviceplanung, vor allem in den immer größer werdenden OWPs, erleichtert. In kleinen
OWAs mit beispielsweise 10 bis 20 OWAs ist die Serviceplanung unter Umständen noch
trivial, da die Anzahl der WEA zu gering ist, um tatsächliche größere Planungsprobleme
zu verursachen. Wird die Anzahl jedoch größer, also 100 oder auch mehr WEAs,
so wird eine manuelle kosteneffiziente Planung zu komplex. Der Trend geht zu immer
größeren OWPs und daher auch zu immer komplexeren Planungsszenarien. Aus diesem
Grund wird es in Zukunft von wachsender Bedeutung sein, die planerische Gestaltung
der Servicefahrten durch technologische Unterstützungssysteme zu untermauern.
Im Laufe der Entwicklung hat es sich als sinnvoll herausgestellt, eigene Verfahren zur
Optimierung von Serviceplänen zu entwickeln, da sich bekannte Optimierungsverfahren
als nicht oder nur teilweise sinnvoll einsetzbar erwiesen haben. Zur Berechnung der Servicepläne
wurden im Produkt entsprechende Verfahren entwickelt, welche teilweise bereits
bekannte Verfahren beinhalten. So wäre es an dieser Stelle sinnvoll, diese Verfahren
exakt zu analysieren und zu evaluieren, hinsichtlich der Fragestellung, ob die gelieferten
Ergebnisse tatsächlich optimal sind bzw. sich nah an einem planerischen Optimum
befinden. Dies kann zurzeit nicht mit Sicherheit bestimmt werden.
In diesem Zusammenhang bietet das Produkt Potenzial, als Ausgangspunkt für weiterer
wissenschaftliche Arbeiten zu dienen. So bieten die genannten Optimierungsverfahren
die Möglichkeit, einer umfassenden Evaluation unterzogen zu werden. Im Rahmen der
Projektgruppe fehlte schlussendlich die Zeit, eine solche Evaluation durchzuführen. Daneben
könnten weitere, unter Umständen bessere, Verfahren implementiert, oder die
bestehenden verbessert werden.
Darüber hinaus bietet die Simulationskomponente ebenfalls Potenzial für anschließende
Arbeiten. So könnte die Visualisierung des Ablaufplans besser dargestellt werden, wie
beispielsweise durch die Implementierung einer 3D-Darstellung oder ähnlichem. Zudem
könnte die Scheduling-GUI einem Facelift unterzogen werden, da diese nur zu Testzwecken
implementiert wurde. Es gibt weitere Ansatzpunkte, die sich aus dem Kontext der
Arbeit ergeben können.
Darüber hinaus besitzt das Produkt lediglich einen Planungshorizont von einem Tag.
Es wäre in Zukunft sinnvoll, diesen Planungshorizont um längere Zeiträume zu erweitern.
So könnte eine längerfristige Planung über Monate, vor allem für regelmäßig wiederkehrende
Wartungseinsätze, für planerische Sicherheit beim Betreiber eines OWPs dienen.
Hierbei könnten regelmäßige Kosten exakter als je zuvor vorausgeplant und -berechnet
werden, da die Komponente der Tagesplanung sehr exakte Aussagen über die Kosten der
Servicefahrten im Einzelnen zulässt. Zudem können Kapazitäten hinsichtlich Ressourcen
und Transportmittel frühzeitig verplant werden.
172

Literaturverzeichnis
Literaturverzeichnis
Literaturverzeichnis
Das Literaturverzeichnis ist Bestandteil jeder wissenschaftlichen. Präzise und aussagekräftige
Angaben erleichtern die Recherche für spätere Leser. Die Verwendung von Zitaten
oder Ideen aus anderen Arbeiten oder aus sonstigen Quellen ohne deutlichen Hinweis
auf deren Ursprung stellt eines der schwersten akademischen Vergehen dar. Eine
wissenschaftliche in der dieser Fehler wiederholt gemacht wird, wird zu Recht als Plagiat
bezeichnet.
[Bue 2012] Bildquelle - Ursachen für das Scheitern. http://www.buena-la-vista.de.
Version: Dezember 2012, Abruf: 21.01.2013
Projektmanagement-Unterstützung für Projekt-
[Albrecht 2008] Albrecht, Melanie:
gruppen im Informatikstudium. 2008
[Bellmann 1957] Bellmann, R.: Dynamic Programming. Princeton University Press,
1957
[Bundesamt für Seeschifffahrt und Hydrographie unter Mitwirkung von Prof. Dipl.-Ing.
Horst Bellmer et all 2007] Bundesamt für Seeschifffahrt und Hydrographie
unter Mitwirkung von Prof. Dipl.-Ing. Horst Bellmer et all: Standard -
Konstruktive Ausführung von Offshore-Windenergieanlagen. Juli 2007
[dena 2012] dena: Bildquelle Häfen - Infrastruktur für Offshore-Windparks. In: Energiesysteme
und Energiedienstleistungen (2012). http://www.stromeffizienz.de, Abruf:
27.05.2013
[Dorigo u. Stützle 2004] Dorigo, Marco ; Stützle, Thomas: Ant Colony Optimization.
Mit Press, 2004 http://books.google.de/books/about/Ant_Colony_
Optimization.html?hl=de&id=_aefcpY8GiEC
[dpa 2012] dpa: Bildquelle Helgoland wird Offshore-Servicehafen. http://www.haz.de.
Version: April 2012, Abruf: 27.05.2013
[Dr. Achim Schmidtmann 2012] Dr. Achim Schmidtmann: Projektphasen. http://
www.projektmanagementzitate.de/project_phases.php. Version: Dezember 2012,
Abruf: 21.01.2013
[Gabler 2013] Gabler, Wirtschaftslexikon: Bildquelle Logistik - Teildisziplinen der Logistik.
http://wirtschaftslexikon.gabler.de. Version: Dezember 2013, Abruf:
26.05.2013
[Han u. a. 2006] Han, J. ; Kamber, M. ; Pei, J.: Data Mining, Second Edition: Concepts
and Techniques. Elsevier Science, 2006 (The Morgan Kaufmann Series in Data Management
Systems). http://books.google.de/books?id=AfL0t-YzOrEC. – ISBN
9780080475585
173

Literaturverzeichnis
Literaturverzeichnis
[OpenAdvice IT Services GmbH 2012] OpenAdvice IT Services GmbH: Bildquelle
- Projekte scheitern nicht am Geld. http://www.openadvice.de. Version: Dezember
2012, Abruf: 21.01.2013
[Page u. Kreutzer 2005] Page, Bernd ; Kreutzer, Wolfgang: The Java Simulation
Handbook: Simulating Discrete Event Systems with UML and Java. 1. Auflage. Aachen,
Shaker Verlag, 2005 (978-3832237714)
[Papadimitriou u. Steiglitz 1998] Papadimitriou, Christos H. ; Steiglitz, Kenneth:
Combinatorial Optimization: Algorithms and Complexity. 2. 31 East 2nd Street,
Mineola, N.Y. 11501 : Dover Publications, Inc, 1998
[Prof. Dr.-Ing. Henning Albers u. Greiner 2012] Prof. Dr.-Ing. Henning Albers
; Greiner, Saskia: Bildquelle Onshore und Offshore Logistik. https://www.
hs-bremen.de. Version: Dezember 2012, Abruf: 26.05.2013
[Prof. Dr.-Ing. Willibald A. Günthner u. Dipl.-Ing. Martin Haller 1997] Prof. Dr.-
Ing. Willibald A. Günthner, Dipl.-Ing. Alexander Kumpf ; Dipl.-Ing. Martin
Haller: Auswahl von Simulations-Software: Auf den Verwendungszweck kommt
es an. Technische Universiät München, Lehrstuhl Fördertechnik Materialfluss Logistik.
http://www.fml.mw.tum.de/fml/images/Publikationen/LogSpect9703_
SimSoftAuswahl.pdf. Version: 1997
[Sauer 2003] Sauer, Tomas: Einführung in die Optimierung für Hörer aller Fachbereiche.
http://www.uni-giessen.de/tomas.sauer/Skripten/HaFOptimierung.pdf.
Version: 2003, Abruf: 13.01.2013
[TESIS PLMware GmbH 2013] TESIS PLMware GmbH: Kennen Sie die ungenutzten
Potenziale in Ihrer Produktentstehung? http://plmware.tesis.de/.
Version: Dezember 2013, Abruf: 21.01.2013
[Tröschel 2010] Tröschel, Martin: Aktive Einsatzplanung in holonischen Virtuellen
Kraftwerken. Rudolf-Kinau-Str. 54, 26188 Edewecht : Oldenburger Verlag für Wirtschaft,
Informatik und Recht, 2010
174

Stichwortverzeichnis
A
Agent Communication Language . . . . 62
Air Force Weather Agency . . . . . . . . . . 44
Akteur . . . . . . . . . . . . . . . . . . . . . . 148, 150 f.
Akteur-Liste . . . . . . . . . . . . . . . . . . . . . . . 148
Ausschließlichen Wirtschaftszone . . 47 ff.
Automatic Identification System . 47, 50
B
Betriebsbüro . . . . . . . . . . . . . . . . . . . 97, 169
Binnenschifffahrtsstraßen-Ordnung . . 49
Bundesamt für die Seeschifffahrt und der
Hydrographie . . 22 f., 36, 49, 90
Bundesministerium für Umwelt, Naturschutz
und Reaktorsicherheit 21
C
Charterkosten . . . . . . . . . . . 97, 100 f., 103,
110, 120, 126, 135, 139, 144, 151,
162 f., 169
Cluster . . . . . . 100 f., 108 ff., 135 f., 139 f.,
142 ff., 156
Constraint . . . 99 f., 102, 104 f., 107, 136,
142, 144, 147
ControllStation . . . . . . . . . . . . . . . . . . . 113 f.
ControlStation . . . . . . . . . . . . . . . . . . . . . 114
Convention on the International Regulations
for Preventing Collisions
at Sea. . . . . . . . . . . . . . . . . . . . . . .49
Crew Transfer Vessel . . . . . . . . . . . . . . 37 f.
D
Deutsche Gesellschaft für Projektmanagement
e.V. . . . . . . . . . . . . . . . . . 78
Deutscher Wetterdienst. . . . . . . . . . . . . .40
DockingTime. . . . . . . . . . . . . . . . . . . . . . .125
Drag&Drop . . . . . . . . . . . . . . . . . . . 133, 161
E
Echolot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Electronic Chart Display and Information
System. . . . . . . . . . . . . . . . .50 f.
Electronic Navigational Chart . . . . . 50 f.
Erneuerbare-Energien-Gesetz . . . . . . . . . 1
evaluate()-Methode . . . . . . . . . . . . . . . . 114
Evaluation. . . . . . . . . . . . . . . . . . .125 f., 172
EvaluationRequest . . . . . . . . . . . . . . . . . 114
EvaluationResponse . . . . . . . . . . . . . . . . 114
EvaluationView. . . . . . . . . . . . . .126, 151 f.
F
Fahrzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
FinishedSimulation . . . . . . . . . . . . . . . . . 114
Forecast Systems Laboratory . . . . . . . . 44
Foundation for the Intelligent Physical
Agents . . . . . . . . . . . . . . . . . . . . . . 62
Frühester Anfangszeitpunkt . . . . . . . . . 93
Frühester Endzeitpunkt . . . . . . . . . . . . . 93
Framework . . . . . . . . . . . . . . . . . . . . 148, 155
G
Getriebe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Gewinnausfall . . . . . . . . . . . . . . . . . . . . . . 95,
97 ff., 101 ff., 105 ff., 110, 135 f.,
141, 145, 151, 163, 167
Global Forecast System . . . . . . . . . . 43, 45
Global Positioning System . . . . . . . 47, 50
Gondel . . . . . . . . . . . . . . . . . . . . . . . . . . 27, 38
Graphical User Interface4, 9, 11, 87, 91,
115, 117, 129, 158, 168, 172
H
Hafen 85, 88, 91, 98, 111, 119, 121, 150,
162, 168
Hard-Constraint . . . . . . . . . . . 99, 102, 168
Health, Safety and Environment. .9, 20,
23
Helikopter . . . . . . . . . . . . . . . . . 34, 37 f., 86,
88, 93, 96 ff., 101 f., 120, 123 ff.,
137, 146, 167, 170
Hoisting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Hubinsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
175

Stichwortverzeichnis
Stichwortverzeichnis
I
Infrastruktur . . 1, 8 f., 20, 30 f., 34 f., 167
Institut für Windenergie und Energiesystemtechnik
. . . . . . . . . . . . . . . 42
Intergrierte Entwicklungsumgebung 17 f.
International Association of Marine Aids
to Navigation and Lighthouse
Authorities . . . . . . . . . . . . . . . 48
International Convention for the Safety
of Life at Sea . . . . . . . . . . . . . . . 49
International Labour Organization. . .48
International Maritime Organization 48,
50
Intraparklogistik . . . . . . . . 32, 34, 98, 123
J
Jack-up-Schiff . . . . . . . . . . . . . . . . . . . . . . . 38
Java Development Tools . . . . . . . . . . . . . 18
Job . 85 f., 89, 91 ff., 99 ff., 108 ff., 116 ff.,
121 f., 124, 126 f., 131 ff., 135 ff.,
150 ff., 156 f., 159 ff., 165, 167 f.,
171
Job-Liste . . . . 95 f., 100, 107, 122 ff., 145,
156 f.
JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 ff.
K
Kilowatt . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Kilowattstunde . . . . . . . . . . . . . . . . 123, 125
Knoten. . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
L
Latitude . . . . . . . . . . . . . . . . . . . . 46, 96, 123
Logge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Logistik . . . . . . . 6, 8 f., 20, 30 ff., 34 f., 59
Long range identification and tracking47
Longitude. . . . . . . . . . . . . . . . . . .46, 96, 123
M
MaintenanceShip . . . . . . . . . . . . . . . . . 113 f.
Map. . . . . . . . . . . . . . . . . . . . . . . . . . .148, 150
MapPanel-Objekt . . . . . . . . . . . . . . . . 113 f.
MapView . . . . . . . . . . . . . . . . . 148, 150, 152
Maritime Logistik . . . . . . . . . . . . . . . . . 32 ff.
Maritimen Sicherheitszentrums . . . . . . 26
Maritimes Lagezentrum . . . . . . . . . . . . . 27
Masterdata. . . . . . . . . . . . . . . . . . . . . . . . .125
Megawatt . . . . . . . . . . . . . . . . . . . . . . 96, 162
Megawattstunden. . . . . . . . . . . . . . . . . .21 f.
Mitarbeiter . . . . . . . . . . . . . . . . . . 85, 126 f.,
135 ff., 140 ff., 144 f., 147, 151 f.,
162 f., 165, 169, 171
Multi-Agent Based Simulation . 62 f., 69
Multiagentensysteme . . . . . . . . . . . 59 f., 62
N
National Center for Atmospheric Research
. . . . . . . . . . . . . . . . . . . . . . . . 44
National Centers for Environmental Prediction
. . . . . . . . . . . . . . . . . . . . . 44
National Oceanic and Atmospheric Administration
. . . . . . . . . . . . . . 43 ff.
Nennleistung . . . . . . . . . . . . . . . . . . . . . . . . 21
NextIntervalRequest . . . . . . . . . . . . . . . 114
O
Offshore Service Vessels . . . . . . . . . . . . . 38
Offshore-Windenergie . . . . . . . . . . . . 1, 167
Offshore-Windenergieanlage . . . . . . . 21 f.,
24, 30 f., 36 ff., 42, 85, 90 f., 96 ff.,
101 ff., 110, 119, 121 ff., 135 ff.,
141, 143 ff., 147 f., 151, 161, 165,
167, 170, 172
Offshore-Windenergiepark 1 f., 18, 21 ff.,
31 ff., 36 ff., 85, 87 f., 90 f., 93,
98, 101 f., 107, 119, 121 ff., 126 f.,
136 ff., 141 f., 144, 147, 161, 165,
167, 171 f.
Optimierung . . . . . . . . . . 4 f., 73, 75 f., 86,
90, 92 f., 95 f., 98 ff., 110, 116 ff.,
120 ff., 126, 128, 130, 132 ff., 139,
142, 146, 148, 151, 159 ff., 165,
168 ff., 172
Optimierungen . . . . . . . . . . . . . . . . . . . . . 165
Optimierungsproblem . . . . . . . . . . . . . 73 ff.
P
Plan. . . . . . . . . . . . . . . . . . . .86, 97, 99, 101,
107 f., 110 f., 124 ff., 131, 134 ff.,
176

Stichwortverzeichnis
Stichwortverzeichnis
139 f., 143, 145 f., 148 ff., 159 ff.,
165, 168 f., 171 f.
Position . . . . . . . . . . 119, 140 f., 147 f., 150
PositionRequest . . . . . . . . . . . . . . . 114, 125
PositionResponse . . . . . . . . . . . . . . 114, 125
Projektgruppe. . . . . . . . . . . . . . . . . . . . . . .87
Projektmanagement . . . . . . . . . . . 78 ff., 82
ptimierung . . . . . . . . . . . . . . . . . . . . . . . . . 159
R
Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . 47, 50
Reederei . . . . . . . . . . . . 10, 20, 30 f., 36, 39
repaint()-Methode. . . . . . . . . . . . . . . . . .114
Rigid Inflatable Boat . . . . . . . . . . . . . . . . 38
Rotor . . . . . . . . . . . . . . . . . . . . . . 25, 31 f., 38
Rotorblatt . . . . . . . . . . . . . . . . . . . . . . . 25, 38
Route . . . . . . . . . . . . . . . . . . . . . . . . . 148, 150
S
Scheduling . . . . . . 4, 9, 86, 89, 92 ff., 117,
120 ff., 124, 135, 160 f., 168
Schiff . . . . . . . . . . . 2, 23, 25 ff., 33 f., 36 ff.,
43, 50 f., 86, 88, 93, 96 ff., 120,
123 ff., 135 ff., 144 f., 148, 150 f.,
161 ff., 165, 167, 169 f.
Schiffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Schifffahrtsordnung Emsmündung . . . 49
Seeaufgabengesetz . . . . . . . . . . . . . . . . . . . 49
Seeschifffahrtsstraßen-Ordnung . . . . . . 49
Seezeichen. . . . . . . . . . . . . . . . . . . . . . . . . . .46
Simualtion . . . . . . . . . . . . . . . . . 91, 126, 148
Simulation . . . . 4, 9, 58 f., 62 f., 87 ff., 92,
97, 110, 113 f., 117, 124 ff., 128,
130, 135, 141, 145, 148 ff., 159 f.,
168, 170, 172
Simulation based Coordination of Offshore
Wind Parks Servicing 1 ff.,
5, 9 f., 16, 40, 87, 128, 168 f.
Soft-Constraint . . . . . . . . . . . . . . . . . 99, 102
Software. . . . . . . . . . . . . . . . . . . . .3 f., 86, 92
Spätester Anfangszeitpunkt. . . . . . . . . .93
Spätester Endzeitpunkt. . . . . . . . . . . . . .93
start()-Methode . . . . . . . . . . . . . . . . . . . . 114
StartRequest . . . . . . . . . . . . . . . . . . . . . . . 114
StatusRequest. . . . . . . . . . . . . . . . . . . . . .114
SWATH-Schiff. . . . . . . . . . . . . . . . . . . . . . .38
T
Tageseinsatzplan . . . . . . . . . . . . . . . . . . . 110
Tonnenstrich . . . . . . . . . . . . . . . . . . . . . . . . 98
TransportHelicopter . . . . . . . . . . . . . . 113 f.
Transportmittel. . . . . . . . . . . .36, 85 f., 89,
91 ff., 107 f., 110 f., 115 ff., 123 f.,
126, 131 ff., 136 f., 139 f., 145 ff.,
150 ff., 156 f., 160 f., 165, 167 f.,
170, 172
Transportmittel-Liste . . . . . . 95, 124, 157
Treibstoffkosten. . . . . . . . . . . . . . . . . .96, 98
U
Übersteigesystem . . . . . . . . . . . . . . . . . . . . 33
Übersteigezeit . . . . 98, 123, 125, 138, 162
Umspannplattform . . . . . . . . . . . . . . . . . . 38
UN Conventions on the Law of the Sea
49
V
Verkehrszentrale . . . . . . . . . . . . . . . . . 47, 49
View . . . . . . . . . . . . . . 91 f., 125 f., 148, 160
W
Wasser- und Schifffahrtsämter . . . . . . . 49
Wasser- und Schifffahrtsdirektionen. .49
Wasser- und Schifffahrtsverwaltung des
Bundes . . . . . . . . . . . . . . . . . . . . . 49
Weather Research and Forecasting Model
. . . . . . . . . . . . . . . . . . . . . . . 43 ff.
Wetterbedingungen. . . . . . . . . . . . . . . . . .98
Wiederkehrende Prüfung . . . . . . . 24 f., 36
Windenergieanlage. . . . . . . . . . .21 f., 24 f.,
27, 32 f., 37 f., 85, 88, 90, 96 ff.,
101 ff., 105 ff., 110, 113, 116, 119,
121, 123, 125 ff., 135 ff., 139 ff.,
145, 148, 150 ff., 161 ff., 167 f.,
172
Windenergiepark. . . . . . . .24, 31 ff., 167 f.
Windfarm . . . . . . . . . . . . . . . . . . . . 2, 7, 20 f.
177

Stichwortverzeichnis
Stichwortverzeichnis
Z
Zeitfenster . . . . . . . . . . . 85 f., 89, 92 ff., 96,
98 ff., 104, 107 f., 116, 118, 120,
123, 132, 136, 138, 140 ff., 144,
150, 156 f., 160 ff., 165, 168
178

A
ANHANG
A Anhang
Weitere Informationen werden im Anhang abgedruckt, wie zum Beispiel das Klassendiagramm
der Optimierung.
Abb. 99: Klassendiagramm der Optimierung [RS-Algo] (Quelle: Eigendarstellung)
179

A.1 Sitzungsprotokolle A ANHANG
A.1 Sitzungsprotokolle
Jegliche Protokolle aller Sitzungen über die gesamte Projektphase.
180

1. Aufstellung und Vergabe von Posten:
Webseite: Raphael, Shimal, Svetlana, Khishrav
Projektmanagement: Shimal, Carsten
Geräte u. Ausflüge (Axel fragen wegen Budget?): Stefan
Qualitätssicherung: Christian, Nashida, Andre
Aussenkontakt: Georg
2. Verhaltenssegeln/Kodex:
Vorschläge bis Freitag an die Mailiste und Stefan stellt Katalog zusammen zu nächster Woche
3. Agendapunkte/Todos:
Wöchentlich an Projektmanager berichten, dieser strukturiert damit die Statustreffen Montags
4. Protokolle:
Projektmanager kümmern sich um rotierendes Verfahren zum Protokollverantwortlichen
5. Teamabend:
Stephan (stimmt?) sammelt Ideen für Teamabend
6. Vortrag von Shimal zu theoretischen Aspekten des Projektmanagements

Protokoll Nr. 1
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.45 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Shimal Ibrahim
Protokollführung:
Carsten Buschmann
Abwesende: Nashida B.
Georg B.
Carsten B.
Khisrav E.
Shimal I.
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W.
1 Zusammenarbeit BTC
Diskussion: Außenkontakt, insbesondere zur BTC
Ergebnisse: Bevor etwas abgesprochen wird, Rücksprache mit Prof. Dr. Jürgen Sauer oder Dipl.-Inform. Jan-Hinrich Kämper
Andreas Rott?! Berichtet über seine Erkenntnisse am 19.11.2012
Aufgaben: Verantwortliche: Deadline:
Präsentation etc. Alle Keiner
keine
Prof. Dr. Jürgen Sauer
2 Präsentation der Projektmanagement-Tools
Diskussion: Projektmanagement-Tools
Ergebnisse: Steht noch aus; Erkenntnisse bisher: Kalender à StudIp, Exchange
Dateiverwaltung/ Codeverwaltung à git, SVN
Gantt à Redmine, TRAC
Forum à StudIp
Website
Ticketsystem à gitlab, TRAC
Wiki à nicht notwendig
Aufgaben: Verantwortliche: Deadline:
Präsentation/ Vortrag Alle Keiner
12. November 2012
hauptsächlich jedoch Shimal I.
3 Besprechung der Konventionen
Diskussion: Regeln
Ergebnisse: verschoben auf den 12. November 2012, nächste Sitzung

2
Aufgaben: Verantwortliche: Deadline:
Besprechen der Regeln Alle Keiner
Hauptverantwortlicher Stefan W.
4 Protokollführung und Moderation der Sitzungen
Diskussion: Wer führt wann das Protokoll und wer moderiert
Ergebnisse:
- Protokoll wird in alphabetischer Reihenfolge abwechselnd geschrieben
- Moderation führt der vorherige Protokollführer einer jeden Sitzung
Aufgaben: Verantwortliche: Deadline:
Festlegung Protokollführung und Moderation Alle Keiner
05.11.2012
Shimal I.

Protokoll Nr. 2
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
Khisrav Evazov
Abwesende: Nashida B.
Carsten B.
Khisrav E
Shimal I.
Georg B.
Raphaël F.K.
Christian M.
André W.
Stefan W
Swetlana K.
1 Social: Kennenlerntreffen organisieren, wann und wo?
Diskussion: Wo und wann treffen wir uns?
Ergebnisse:
Wir treffen uns am Freitag 30.11.2012 um 19Uhr in Loft Restorant
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Besprechung der Konventionen
Diskussion: Präsentation von Stefan W. „PG COWS - Konventionen“
Ergebnisse: die Treffen finden montags von 15.30 bis 17.30Uhr. Jedes treffen wird protokolliert und das Protokoll steht
allen Mitglieder 1 Tag später 20.00 Uhr zur Verfügung. Moderator macht die Sitzung (ca 15min). Jede macht 1 mal
Moderation
Email-Verkehr: beginnen mit COWS .
Weitere Kommunikationskanäle: Telefon, Skype, ICQ, Jabber
Protokoll und Agenda
Protokoll muss MS Word Vorlage und PDF sein. Der Protokollant ist der Moderator der Folgesitzung
Die Agenda für Gruppensitzung wird immer vom Projektmanagement in Zusammenarbeit mit dem Moderator erstellt.
Vorschläge zur Gestaltung der Agenda sind bis Freitagabend 18.00Uhr entweder zu Carsten M. Und Shimal I. zu schicken.
Die Agenda wird für alle montags 12.00 als MS Word/PDF hochladen.
Dateiformate/Code: UTF-8 codiert abzuspeichern
Beschlussfähigkeit: wenn mindestens 7 Teilnehmer anwesend sind
Fehlen: Für alle zur folgenden Gruppensitzung Süßigkeiten mitbringen
Urlaub: Frühzeitig ankündigen
Aufgaben: Verantwortliche: Deadline:

Alle
Keiner
2
3 Bericht über die einzelnen Projektmanagement-Tools (Studip, Trac, GitLab,
Redmine)
Diskussion: über Projektmanagement-Tools
Ergebnisse: Als Projektmanagement-Tools ist „Redmine“ gewallt, weil einige Teilnehmer mit Redmine Erfahrung haben.
Redmine kann man für Kalender, Daten/Verwaltung, Ticketsystem, Website, etc. benutzen.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner

Protokoll Nr. 3
Montag, 19.11.12
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation: Khisrav E.
Protokollführung: Shimal I.
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Server und SVN
Ergebnisse:
Eine Maschine ist bereits eingerichtet. Zu erledigen ist noch die Einrichtung des SVN. Die bisherigen Login Daten lauten:
Maschine: Cows
Server: 134.106.12.81
Login: cows
Passwort: wind
Aufgaben: Verantwortliche: Deadline:
Server und Redmine einrichten Alle Keiner
23.11.12
Jan
2 Scrum
Ergebnisse:
Stefan präsentiert der Gruppe etwas über Scrum. Mehr zu dem Thema kann aus den Präsentationsfolien entnommen
werden.
Aufgaben: Verantwortliche: Deadline:
--- Alle Keiner
---
Vorgestellt von Stefan
3 „Optimierung der Einsatzplanung für Offshore-Windparks“
Ergebnisse:
Andreas Rott, Mathe-Student, arbeitet bei BTC und schreibt seine Diplomarbeit über das Thema „Optimierung der
Einsatzplanung für Offshore-Windparks“. Folgende Punkte sind die Ergebnisse seiner Präsentation
• Arbeitsvorgänge automatisieren und optimieren.
• Verfügbarkeit der Transportmittel, evtl. Probleme beseitigen bzw. automatisch lösen
• Probleme Verfügbarkeit der Einsatzkräfte, evtl. Probleme beseitigen bzw. automatisch lösen
• Arbeitszeit von Einsatzkräfte, evtl. Probleme beseitigen bzw. automatisch lösen
• Bedingungen von Maßnahmen
• Wetterbedingungen berücksichtigen

2
• Optimierung
o Kosten durch Ausfallzeiten, wann ist günstig eine Maßnahme auszuführen?
o Kosten durch Transporte
• Abgrenzungen:
o Verfügbarkeit der Transportmittel
o Verfügbarkeit der Einsatzkräfte
Aufstellen eines geeigneten Modells
• Diskrete lineare Programmierung
• Simplex-Methode
• Definition der Mengen und Variablen (z.B. Anzahl der Tage, der Teams, der Anlagen, der Maßnehmen, etc.)
• Restriktionen (Hinweis: eine Maßnahme dabei ist das was in einem Tag passiert. Alle Maßnahmen betreffen hierbei
nur eine Anlage)
è
o
o
o
o
o
o
Jede Maßnahme findet genau einmal statt
Jede Maßnahme besitzt zeitliche Beschränkungen
Ein Transport findet statt, wenn mindestens eine Maßnahme geplant ist
Jedes Tema kann pro Tag nur eine gewisse Anzahl an Stunden arbeiten
An jeder Anlage kann pro Tag nur eine gewisse Anzahl an Stunden gearbeitet werden
Die Zeit, die eine Anlage ausfällt hängt von den geplanten Maßnahmen ab
Mit Hilfe der Restriktionen wird schließlich eine Zielfunktion erstellt
Aufgaben: Verantwortliche: Deadline:
--- Alle Keiner
---
Vorgestellt von Andreas Rott
4 Code Konvention
Ergebnisse:
Mehr dazu kann aus der folgende Webseite entnommen werden: http://www.clean-code-developer.de/
Jedes Teammitglied soll sich die Konventionen durchlesen. Bei der Programmierung soll jedes Mitglied an die Konventionen
halten.
Aufgaben: Verantwortliche: Deadline:
Konventionen durchlesen Alle Keiner Durchgehend bis Projektende

Protokoll Nr. 4
Montag, 26.11.12
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Shimal
Protokollführung:
Raphael
Abwesende: Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Vorbesprechung
INFO: Die nächsten Vorträge
Am nächsten Treffen (03.12) wird es nur Vorträge zur Simulation geben, von Bastian Wagenfeld (zu Jason), von Marcel
Nguefack (zu Plant Simulation) und von Raphael. Am 10.12.12 tragen dann Carsten, Christian, Khishrav und Nashida ihre
Vorträge vor.
INFO: Erinnerung ans Social
Am Freitag 30.11 findet ab 19:00 Uhr unser Social im Loft (Restaurant) statt: http://bit.ly/10YmocE
Aufgabe: Verantwortliche: Deadline:
Präsentationen hochladen Svetlana, Georg, André 03.12.2012
Aufgabe: Verantwortliche: Deadline:
Rollen in Redmine definieren Shimal 17.12.2012
2 Vorträge von Svetlana (Reederei), Georg (Wetterdaten) und André
(Navigation)

Protokoll Nr. 5
Montag 03.12.12
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Raphaël
Protokollführung:
Svetlana
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Vorträge von Raphaël (Simulation) und Marcel (Plant Simulation)
Aufgabe: Verantwortliche: Deadline:
Präsentation hochladen Raphaël 10.12.2012
2 Rollenverteilung
Ergebnisse:
Rollenverteilung wird über Redmine durchgeführt.
Aufgaben: Verantwortliche: Deadline:
Rollen und ihre Beschreibung in Redmine
hinzufügen
Informationen bezüglich Rollen in Redmine
durchlesen und eigene Präferenzen bestimmen
Shimal ---
Alle Keiner ---
3 Projektname
Diskussion:
Diskussion wird im Redmine Forum durchgeführt
Ergebnisse:
Vorschläge und Meinungen sollen im Redmine Forum ausgedruckt werden; endgültige Entscheidung soll in der letzten
Sitzung des Dezembers (17.12.2012) getroffen werden
Aufgaben: Verantwortliche: Deadline:
über Namenänderung überlegen, an Diskussion im
Redmine Forum teilnehmen
Alle Keiner 17.12.2012
4 Protokollführung
Ergebnisse:
Weiterhin sollen Protokolle sowie Vorträge in die entsprechenden Ordner hochgeladen werden (namens „Protokolle“ bzw.
„Vorträge“); daher sollen die Protokolle weiter nicht über den Verteiler geschickt werden; Protokoll-Dateien sollen wie
folgend genannt werden:
Protokoll_0x_Datum (z.B. Protokoll_05_03.12.12)

2
Aufgaben: Verantwortliche: Deadline:
Protokollführende soll die Protokoll-Datei
entsprechend nennen und in den entsprechenden
Ordner hochladen
Alle Keiner ---

Protokoll Nr. 6
Montag, 10.12.12
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Svetlana
Protokollführung:
Christian
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Vortrag von Nashida zum Thema Offshore Windfarmen
Aufgaben: Verantwortliche: Deadline:
Präsentation hochladen Nashida 17.12.2012
2 Vortrag von Bastian Wagenfeld zum Thema JASON
Aufgaben: Verantwortliche: Deadline:
Präsentation hochladen Shimal 17.12.2012
3 Vortrag von Khisrav zum Thema HSE Aspekte
Aufgaben: Verantwortliche: Deadline:
Präsentation hochladen Khisrav 17.12.2012
4 Vortrag von Carsten zum Thema Infrastruktur und Logistik
Aufgaben: Verantwortliche: Deadline:
Präsentation hochladen Carsten 17.12.2012
5 Vortrag von Christian zum Thema Optimierung
Diskussion & Ergebnisse:
Aus Zeitgründen auf nächstes Treffen (17.12.2012) verschoben.
1

Protokoll Nr. 7
Montag, 17.12.2012
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 12.00 – 14.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Shimal
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Vision erstellt/ Projektinhalte aufbereitet
Diskussion & Ergebnisse: Informationen in einer Mindmap gesammelt; Idee diskutiert; Ergebnis strukturieren;
Aufgaben: Verantwortliche: Deadline:
• Mindmap-Erstellung
• Mindmap graphisch aufbereiten
• Prosatext zur Mindmap
• Modell erstellen
• Webdesign erstellen
- Drei Design
- Andere Websites betrachten
- Struktur
• Forschungsdaten erfragen und aufbereiten
(FINO1)
• TeX-Vorlage erstellen
(siehe Verantwortlichkeit in gelisteter Reihenfolge)
Alle
Raphaël F.K.
Stefan W.
Georg B. & Shimal I.
Keiner
Khisrav E., Svetlana K., Raphaël F. K.
& Shimal I.
Georg B., Shimal I. & Christian M.
Carsten B. & Nashida B.
17.12.2012
05.01.2013
05.01.2013
05.01.2013
05.01.2013
05.01.2013
05.01.2013
2 Anforderungen
Diskussion & Ergebnisse: Anforderungserhebung diskutiert und Termin
Aufgaben: Verantwortliche: Deadline:
Anforderungen und Product-Backlog
Vorgehen zur Anforderungserhebung erstellen
Alle
Carsten
Keiner
21.01.2013
05.01.2013
1

Protokoll Nr. 8
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Christian
Protokollführung:
André Wolter
Abwesende: Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion: Vortrag Optimierungsverfahren Christian M.
Ergebnisse: Bibliotheken für Optimierung: OptimJ, Lpsolve, Drools Planner, Pyomo
Aufgaben: Verantwortliche: Deadline:
- keine Alle Keiner
2 Agendapunkt 2
Diskussion: Smart Wind Control
Ergebnisse: Plattform für ein Wind-Farm Maintenance Management System (proaktiv). Fokus auf die Wartung von Turbinen.
Analyse von Daten mittels SAP HANA.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Agendapunkt 3
Diskussion: Themen sollen noch ausgiebig im Wiki eingestellt werden
Ergebnisse: Jeder Seminarbeitrag sollte umfangreich im Wiki eingestellt werden
Aufgaben: Verantwortliche: Deadline:
Wiki bearbeiten Alle Keiner 21.01.2013

2
4 Agendapunkt 4
Diskussion:
Ergebnisse:
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner

Protokoll Nr. 9
Montag, 07.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Andre
Protokollführung:
Stefan
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Windpark-Modell
Diskussion & Ergebnisse: Vorstellung und Besprechung des Windpark-Modells
Das Windpark-Model liegt in Form eines Klassendiagramms als PDF und PNG im SVN-Ordner „Dokumente“. André merkt an,
dass Rotoren aus Rotorblättern bestehen und diese nur als „Sets“ ausgeliefert werden, dies muss bei der Modellierung
beachtet werden, da hieraus logistische Probleme erwachsen können.
Klasse Personal: Skills des jeweiligen Personals aufführen? Wie granular soll das sein? Reicht ein „Personaltyp“ aus?
Entscheidung zunächst vertagt.
Klasse Komponenten: Verfügbarkeit der Komponenten spielt eine Rolle ggf. Entwicklung eines Fehlerbaums.
Entscheidung vertagt.
Off-Topic: Diskussion über Quellen
Zukünftig wird JabRef zur Verwaltung von Quellen verwendet. Im SVN wird zudem ein Repository bzw. Ordner für Quellen
angelegt.
Aufgaben: Verantwortliche: Deadline:
Windpark-Modell „anschauen“, bei Anmerkungen
Georg oder Christian kontaktieren.
Alle Keiner 14.01.13
JabRef, Quellen-Repo anlegen. (Carsten, Nashida)
2 Vision
Diskussion & Ergebnisse: Vorstellung der Vision
Bis auf Kleinigkeiten als OK befunden.
„webbasiert“ streichen, „Akteure“ Betreiber, „heterogen“ verschieden
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 9
Montag, 07.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
3 Anforderungen definieren etc.
Diskussion & Ergebnisse:
Es soll eine Art Diagramm zum Simulationsablauf entwickelt werden (reaktiv oder iterativ). Jan hat hierzu 2 Beispiele ans
Whiteboard gezeichnet, die einen Denkanstoß liefern sollen.
Daraufhin wurden im Plenum Anforderungen diskutiert und von André in einem Word-Dokument festgehalten. Das Dokument
umfasst etwa eine Seite.
Daten zur Simulation können zudem evtl. von SeaPortal MapClient geholt werden.
Aufgaben: Verantwortliche: Deadline:
Diagramm zum Simulationsablauf erstellen. Alle Keiner
14.01.13
Raphael, Christian, Shimal, Stefan
4 Name der PG
Diskussion & Ergebnisse:
Raphael findet den Namen „COWS“ unpassend. Ein Neuer muss her.
Aufgaben: Verantwortliche: Deadline:
Namen ausdenken. Alle Keiner 14.01.13
2

Protokoll Nr. 10
Montag, 14.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Stefan
Protokollführung:
Nashida
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël
F.K.
Svetlana K.
Christian
M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion & Ergebnisse:Organisatorisches
Aufgaben: Verantwortliche: Deadline:
Trac/Registrierung
PG-Name: Lautet SCOWS lautet: Simulation
based of COWS
Fragenkatalog erstellen und Interweius mit BTC
und Institut Forwind durchführen
Fragebogen der Webseite beantworten und ein
Foto an Svetlana senden
Wiki bearbeite
Alle
Alle
Keiner
Nashida, Svetlana, Carsten und
André
Alle
Alle
15.01.2013
14.01.2013
28.01.2013
20.01.2013
21.01.2013
2 Agendapunkt 2
Diskussion & Ergebnisse:Anforderung
Aufgaben: Verantwortliche: Deadline:
Anforderungen zuerganzen
Alle
Keiner
stefan, Christian, André und
Raphaël
21.01.2013
3 Agendapunkt 3
Diskussion & :Vorstellung des Simulationsablaufs
Ergebnisse: Christian hat die Simulationsablauf vorgestellt, Das Modell der Simulationsablaufs die Simulationsablaufs
ist unter die Uml datei zugreifen
Aufgaben: Verantwortliche: Deadline:
1 1
1
1

Protokoll Nr. 10
Montag, 14.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Keine Alle Keiner Keine
4 Agendapunkt 4
Diskussion:Weitere Anforderungen anhand des Simulationsablauf definieren und formulieren
Ergebnisse: OptinierungKriterein auswal, welche simnulationsart sollen wir nutzen
Aufgaben: Verantwortliche: Deadline:
kombiniert mit den Agendapunkt 2 Alle Keiner
5 Agendapunkt 5
Diskussion: LaTex Vorlage
Ergebnisse:Carsten hat und gezeigt die PG-vorlage
Aufgaben: Verantwortliche: Deadline:
Keine Keiner Keiine
6 Agendapunkt 6
Diskussion & Ergebnisse: usecases bis nächste sitzung
Aufgaben: Verantwortliche: Deadline:
Keine keine Keine
7 Agendapunkt 7
Diskussion:PG-Name
Ergebnisse ist schön im Organisatoriesches erledigt
Aufgaben: Verantwortliche: Deadline:
Keine Keine Keine
2 2
2
2

Protokoll Nr. 11
Montag, 21.01.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
Moderation:
Nashida
Protokollführung:
Georg
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
- Gruppenfoto fällt aus, da Christian fehlt, und wird verschoben auf nächste Woche
- Carsten geht früher, um 16:15
- Jan geht früher, um 16:30
- Erstellung von Tickets & Stories wird nach der Aufgabenliste folgen
Aufgaben: Verantwortliche: Deadline:
Aufgabenliste an Projektleiter (Shimal & Carsten)
schicken
Alle Keiner 23.01.2013
2 Programmiersprache & weitere Technologien
Diskussion & Ergebnisse:
- Aktuelles Redmine mit dem aktuellen VCS verbinden
- Redmine-Wiki wird gewählt für Ausarbeitungen
- Git wird genutzt, die Daten und die Benutzer werden vom SVN übernommen
- Programmiersprache & andere Details werden entschieden, sobald die Suche laut Aufgabe erfolgt ist
Aufgaben: Verantwortliche: Deadline:
Was gibt es für existierende Datenquellen (z.B.
Webservices) & Simulationsframeworks/-tools für
den jeweiligen Fachbereich (siehe z.B. "O&M Cost
Calculator"-Dokument im SVN)?
Alle Keiner 28.01.2013
1

Protokoll Nr. 11
Montag, 21.01.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
3 Anforderungen
Diskussion & Ergebnisse:
- Fragenkatalog für Interviews ist im SVN
- Raphael stellt die derzeit aktuelle Liste vor (zuerst von Raphael & Christian erstellt, später zusätzlich Georg)
- Plenum entscheidet über einzelne Aspekte & spricht die Anforderungen durch
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Aufgabenverteilung
Diskussion & Ergebnisse:
Pflichtenheft
- basierend auf den Anforderungen (inkl. Qualitätsanforderungen)
- enthält die Vision und ein Glossar für die Begriffe
- besteht aus Use Cases
- Welche Soll- und Kann-Kriterien?
Aufgaben: Verantwortliche: Deadline:
Pflichtenheft (inkl. Sequenzdiagramme & Glossar)
erstellen
Alle
Keiner
Shimal, Svetlana, Nashida
28.01.2013
Use Cases erstellen Alle Keiner
28.01.2013
Stefan, Shimal, Andre
Karten finden Alle Keiner
28.01.2013
Khisrav
2

Protokoll Nr. 12
Montag, 28.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Berendt, Georg
Protokollführung:
Buschmann, Carsten
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse: Probleme mit Git-Zugang klären und die Zugänge zu den Computern im PG-Raum
Abstimmung der Klausurtermine/ Urlaubstermine über eine Doodle-Liste
Aufgaben: Verantwortliche: Deadline:
Git-Zugang
Zugang zu den Computern im PG-Raum
Klausur-Termine abstimmen (Liste eintragen)
Alle
Keiner
Georg Berendt, Shimal Ibrahim,
Carsten Buschmann
Shimal Ibrahim
Raphaël François Kaiser
28.01.2013
30.01.2013
2 Interviews
Diskussion & Ergebnisse:
- Termin mit Overspeed abstimmen und denen vorstellen, was das Projekt beinhaltet, welches Ziel wir verfolgen und
wo wir gerade stehen
- Des Weiteren einen kurzer Projekt-Status vorlegen und präsentieren
- Für Fragestellungen wird ein Fragenkatalog erstellt und Fragen gesammelt, um in Interviews vorbereiteter zu sein
- Terminabsprache mit der BTC klären. Wie ist der derzeitige Status? Es gibt ein Gespräch (siehe unten)
Aufgaben: Verantwortliche: Deadline:
Termin mit Overspeed am 11.02.2013 um 15:30h im
Seminarraum A02 3-319
Kurze Präsentation vorbereiten
Fragenkatalog erweitern/ umformulieren
Termin mit BTC am 06.02.2013
Alle
Jan-Heinrich Kämper
Christian Menne
Keiner
Carsten Buschmann, Swetlana
Kapitonova
Prof. Dr. Jürgen Sauer
04.02.2013
04.02.2013
04.02.2013
3 Kartenvergleich
Diskussion & Ergebnisse: Vorstellung von verwendbarem Seekartenmaterial, die das Projekt vorantreiben...
1

Protokoll Nr. 12
Montag, 28.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Ergänzen, in welchen Projekten welches Kartenmaterial schon verwendet wird
Ergänzung durch weiteres Kartenmaterial von der Projektgruppe
Aufgaben: Verantwortliche: Deadline:
Kurzpräsentation
Ergänzung des Materials
Alle
Evazov, Khisrav
Keiner
04.02.3013
4 Use Cases
Diskussion & Ergebnisse: Anwendungsfälle vorgestellt, die das System betrifft, welches umgesetzt werden könnte
Detailierung der Modelle minimieren und auf die wichtigen Mensch-Systeme-Interaktion
Aufgaben: Verantwortliche: Deadline:
Vorstellung der durchdachten Use Cases
Alle
Keiner
Shimal Ibrahim, Stefan Wunderlich,
André Wolter
04.02.2013
5 Architektur für das System/ Sequenzdiagramm/ Aufgaben verteilen/ Sonstiges
Diskussion & Ergebnisse: System erst einmal auf einen „Einplatz“ auslegen
Begründung: Der Planer für die Einsatzplanung ist eine Person, die für die Durchführung der Wartung zuständig ist
Framework zur Nutzung besprochen, die Datenbasis festgelegt
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
Framework JAVA
Datenbank MySQL
28.01.2013
28.01.2013
2

Protokoll Nr. 13
Montag, 04.02.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation: Carsten B.
Protokollführung:
Khisrav E
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse: Kurse Präsentation von Cristian
Aufgaben: Verantwortliche: Deadline:
Erstellung von Sequenzdiagrammen Alle Keiner
11.02.13
Cristian, Andre
2 Diskussion: Verhältnis Simulation und Planung. Auf was wollen wir uns mehr
konzentrieren?
Diskussion & Ergebnisse: Diskussion: Simulation und Plannung
Aufgaben: Verantwortliche: Deadline:
Optimierung und Simulation parallel machen Alle Keiner keine
3 Vorbereitungen für die Implementierung. Wir fangen wir mit der
Implementierung an?
Diskussion & Ergebnisse: Technologie Entscheidung, Karte wählen
1

Aufgaben: Verantwortliche: Deadline:
Welche Technologie und welche Karte (See Karte)
nehmen wir?
Alle Keiner 18.02.13
2
2
2

Protokoll Nr. 9
Montag, 07.01.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
André, Christian, Khisrav
Protokollführung:
Raphaël
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Interview mit Overspeed
Diskussion & Ergebnisse:
André hat die Projektpräsentation vorgetragen. Anschließend haben uns der Geschäftsführer von Overspeed und ein
Mitarbeiter Feedback gegeben und Fragen aus unserem Fragenkatalog beantwortet. Das Ergebnis des Interviews wurde im
Dokument docs/Dokumente/Overspeed_Interview_11.02.13.docx festgehalten.
2 Gruppeneinteilung
Diskussion & Ergebnisse:
Simulationsgruppe: Christian, Georg, Khisrav, Raphaël, Shimal, Stefan
Anforderungsgruppe: André, Carsten, Nashida, Svetlana, Shimal
1

Protokoll Nr. 15
Montag, 18.02.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Raphael
Protokollführung:
Shimal
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Es gibt keine organisatorischen Dinge, die dringend diskutiert werden müssen.
Aufgaben: Verantwortliche: Deadline:
--- Alle Keiner ---
2 Bericht über ein Workshop
Diskussion & Ergebnisse:
Nashida und Raphaël berichten über das Workshop „Modeling material supply during the life cycle of wind energy plants“.
Detaillierte Informationen dazu befinden sich im Anhang dieses Protokolls.
Aufgaben: Verantwortliche: Deadline:
--- Alle Keiner ---
3 Arbeiten mit Maps
Diskussion & Ergebnisse:
Christian stellt zwei Beispiele vor, wie man mit OpenSeaMap und Google Maps arbeiten kann. Er erwähnt, dass die Arbeit
mit OpenSeaMap aufgrund der fehlende API sehr schwer zu integrieren ist. Im Gegensatz dazu kann man gut mit Google
Maps arbeiten, da hierbei eine API vorliegt, die auch es auch ermöglicht Layouts zu erstellen, auf denen man zeichnen
kann.
Aufgaben: Verantwortliche: Deadline:
--- Alle Keiner
Christian
----
1

Protokoll Nr. 15
Montag, 18.02.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
4 Ergebnisse der Kleingruppen – Simulation
Diskussion & Ergebnisse:
Die Gruppe, die sich mit der Simulation beschäftigt hatte, stellt kurz die Ergebnisse ihrer Zusammenarbeit dar. In diesem
Rahmen werden auch einige Unklarheiten geklärt. Basierend auf die Ergebnisse der Gruppe wird diskutiert, ob die Gruppe
ein Simulationstool, wie z.B. Simulation Plant, für die Simulation eines Wartungsplans genommen wird oder, ob ein eigenen
„Simulationstool“ entwickelt werden sollte. Nach einer langen Diskussion hat sich die Gruppe zunächst für einen eigenen
Simulationstool entschieden. Dazu sollen Frameworks gesucht werden, die Simulationsentwickelung erleichtern. Die Gruppe
hat sich zunächst auf zwei Frameworks festgelegt: AKKA und MASON. Damit die Frameworks genutzt werden können,
entscheidet sich die Gruppe, das vorhandene Klassendiagramm zu implementieren.
Aufgaben: Verantwortliche: Deadline:
1) Klassendiagramm in Code umsetzen
2) AKKA Framework
3) MASON Framework
Alle Keiner
1) Christian
2) Georg
3) Shimal +
1) Mittwoch, 20.02.13
2) Montag, 04.03.13
3) Montag, 04.03.13
5 Aufgabenverteilung
Diskussion & Ergebnisse:
Die in der Sitzung generierten Aufgaben werden verteilt. Folgende Aufgaben werden folgenden Personen zugewiesen. Zu
den einzelnen Aufgaben wurden auch bereits Tickets im Redmine-System erstellt.
Aufgaben: Verantwortliche: Deadline:
1) Saskia Grainer bzgl. Dauer von
Wartungsprotessen kontaktieren
2) Projektgruppe Cuberunner bzgl. Avalion-
Statistiken anfragen
3) Berufsgenossenschaften wegen
Qualifikationen der Wartungsmitarbeitern
anschreiben
4) Wartungspläne besorgen von Alpha Ventus
und VWind
Alle Keiner
1) Raphaël
2) Raphaël
3) Raphaël, Shimal
-----
2

Protokoll Nr. 16
Montag, 25.02.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Shimal
Protokollführung:
Christian
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Es wurde festgelegt, dass ein Treffen mit der BTC innerhalb der nächsten 3 Wochen arrangiert wird. Zusätzlich wurde ein
Treffen mit Saskia Grainer am Dienstag den 05.03.2013 organisiert. Diese stellt das Projekt „Systop“ vor. Jeder, der Zeit
hat, sollte an dem Treffen teilnehmen
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Besprechung der Vision
Diskussion & Ergebnisse:
Aufgrund des jüngsten Entwicklungen und dem Interview mit den Verantowortlichen von „Overspeed“ muss die Vision des
Projekts angepasst werden.
Aufgaben: Verantwortliche: Deadline:
Anpassung der Vision Alle Keiner
04.03.2013
Stefan
3 Besprechung der Anforderungen
1

Diskussion & Ergebnisse:
Shimal hat aus den Interviewergebnissen mit „Overspeed“ neue Anforderungen gezogen und schriftlich festgehalten. Bei
der Besprechung wurde festgestellt, dass die Festlegung von bestimmten Begriffen essentiell für das weitere Projekt ist.
Aus diesem Grund wurde im Redmine-Wiki ein Glosar angelegt und erste Begriffe festgehalten. Zudem wurde der
Zusammenhang zwischen Jobs, Wartungsplänen und dem Einsatzplan besprochen.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Kurze Vorstellung des Klassenmodells
Diskussion & Ergebnisse:
Das Klassenmodell, dass für den Test von Simulations-Frameworks genutzt werden soll, wird kurz an die Wand projeziert.
Eine Diskussion fand nicht statt.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
5 Aufgabenverteilung
Diskussion & Ergebnisse:
Aus Zeitgründen wurden die Aufgaben für die nächste Woche nach dem Treffen von Shimal festgelegt. Folgede Aufgaben
wurden verteilt:
1. Informationen zu den Seerouten und Verkehrsrichtlinien für Schiffe im Nordsee-Gebiet
2. Informationen zu den Flugrouten und Verkehrsrichtlinien für Hubschrauber im Nordsee-Gebiet
3. Informationen zu den Wettervorhersagen. Wo kann man die Infos bekommen, welche Format haben die und wie man
diese in Java einbindet
Aufgaben: Verantwortliche: Deadline:
1) Informationen zu Seerouten
2) Informationen zu Flugrouten
3) Informationen zu Wettervorhersagen
Alle
1) André
2) Stefan
3) Khisrav
Keiner
04.02.2013
2

Protokoll Nr. 17
Montag, 04.03.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Christian
Protokollführung:
Svetlana
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Es wurde festgelegt, dass ein Treffen mit der BTC am nächsten Montag, den 11.04.2013 stattfindet. Ein Treffen mit Saskia
Grainer findet am Dienstag, den 05.03.2013 statt.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Zusammenfassung der bisherigen Ergebnisse
Diskussion & Ergebnisse:
Eine kurze Diskussion von bisherigen Ergebnissen wurde durchgeführt. Der aktuelle Stand von allen Aspekten wurde
besprochen (Definition von Einsatz- und Wartungsplan, Frameworks für Simulation, Anforderungen, Dokumentation). Alle
Mitglieder haben darüber berichtet, was sie in der letzten Woche gemacht haben.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Besprechung der Anforderungen
Diskussion & Ergebnisse:
Shimal hat die letzte Version der Anforderungen vorgestellt. Diese wurden besprochen, die Anmerkungen und
Verbesserungen wurden festgehalten.
Es wurde entschieden, dass Begriffe im Glossar auch auf Englisch definiert werden sollen.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 17
Montag, 04.03.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
4 Vorstellung des Klassenmodells
Diskussion & Ergebnisse:
Das Klassenmodell wurde vorgestellt und besprochen. Es wurde entschieden, dass die Klassennamen geändert werden
sollen.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
5 Vorstellung des AKKA-Frameworks von Georg
Diskussion & Ergebnisse:
Georg hat das Akka-Framework vorgestellt.
Detaillierte Informationen kann man in der Präsentation dazu finden: http://de.slideshare.net/jboner/akka-simplerscalability-faulttolerance-concurrency-remoting-through-actors
(Seiten 29 bis 40)
Auswahl von Framework wurde noch nicht vorgenommen, da Shimal sich noch mit Mason Framework beschäftigt
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
6 Aufgabenverteilung
Diskussion & Ergebnisse:
Es gab keine neuen Aufgaben zur Verteilung, alle machen die vorher aufgeteilten Aufgaben weiter.
Im Laufe der Woche werden die Treffen der kleinen Gruppen organisiert, um die Gruppenaufgaben weiter zu bearbeiten.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 18
Montag, 05.03.13
cows
DIENSTAG, 05.03.2013
UHRZEIT: 13.00 – 15.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Raphale François Kaiser
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Begrüßung und Vorstellung
Diskussion & Ergebnisse: Begrüßung unserer Gäste; Vorstellung des Projektes
Fragen von unseren Gästen: Wie kann das Tool der Industrie weiterhelfen? Haben wir Industrie- und Herstellerpartner, da
diese elementar entscheidend sind? Wetterbedingungen sind für Jobs unabdingbar und bilden die Basis für die Einsätze.
Welche Teilbereiche wollen wir abarbeiten? Wartungseinsätze, Instandsetzungen und Inspektionen. Werden Daten
eingebunden?
Realistische Daten muss man sich vom Betriebsbüro beschaffen (EWE OSS à für AlphaVentus, Riffgard; NWB à für Baltik I)
Die Randbedingungen sind wichtig und nur vom Betriebsbüro zu erhalten. Nur um einmal eine Vorstellung zu haben, welche
Randbedingungen es gibt. Zum Beispiel steht im Winter nur ein kurzes Zeitfenster für die Erfüllung der Arbeit zur
Verfügung, da es länger dauert bis es hell ist und früher dunkel wird als im Sommer.
Auf eine Einsatzart beschränken (Empfehlung) oder Planung für Einsätze (im Servicebereich).
Liste an Jobs, die erledigt werden, müssen sinnvoll dokumentiert werden. Kabel/ Umspannwerk usw. berücksichtigen.
Inspektionen sind sehr komplex und nur schwer zu erfassen.
Qualifikationsmatrix öffentlich zugänglich!
Anderes Kriterium für die Vorbereitungszeit hinzuziehen.
Aufgaben: Verantwortliche: Deadline:
13:00h Begrüßung
13:10h Vorstellung unseres Projektes
Alle Keiner -
2 Vortrag Optimierung des Leistungssystems Offshore-Windpark
Diskussion & Ergebnisse: Vortrag von SystOp
Aufgaben: Verantwortliche: Deadline:
14:00h Vortrag von SystOp und anschließende
Diskussion
Alle Keiner -
3 Weitere Notizen
1

Protokoll Nr. 18
Montag, 05.03.13
cows
DIENSTAG, 05.03.2013
UHRZEIT: 13.00 – 15.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Diskussion & Ergebnisse: Notizen von Raphaël
SystOp
-­‐
-­‐
Unsere Präsentation
Fragen
Die Simulation soll die Durchführbarkeit eines Einsatzplans unter bestimmten Umweltbedingungen prüfen – Wetter und
Wellen müssen eigentlich immer berücksichtigt werden.
Ein Beispiel für ein Ergebnis
Wartung macht der Hersteller – Wartungspläne und technische Daten – rücken die Hersteller auch nicht heraus.
Mit Betriebsbüro kooperieren (Alpha Ventus + Riffgat, & Baltic 1 (EnBW))
Herr Dr. Burkhard und Herrn Poppe – nur über Herrn Sauer
Wartung: Ölwechsel
Inspektion:
Unvorhergesehene Wartung: „Instandsetzung“
Im Winter ganz kurzer Zeitfenster – noch keine Nachtarbeiter möglich.
Planung für eingehende Wartungseinsätze
Kabel, Umspannwerk, Konverterstation etc.
Qualifikationsmatrix (öffentlich verfügbar)
-­‐ Präsentation
Uni Hamburg -> Simulation
Aufgaben: Verantwortliche: Deadline:
Keine Alle Keiner Keine
2

Protokoll Nr. 19
Montag, 11.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Svetlana
Protokollführung:
Stefan
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Orga
Diskussion & Ergebnisse:
Raphael ist per Skype zur Sitzung zugeschaltet.
JK und JS unterzeichnen die Nutzungsvereinbarung f. d. SystOp-Sachen.
BTC-Leute kommen (höchstwahrscheinlich) am 19.03.13 12 Uhr, Stefan hält SCOWS-Präsentation dabei.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 "Vorhaben konkretisieren"
Diskussion & Ergebnisse:
Christian stellen die Ergebnisse ihrer Quellenrecherche vor, das Ergebnisdokument (Informationssammlung) ist im Git zu
finden.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Optimierung
Diskussion & Ergebnisse:
Georg stellt eine Möglichkeit vor, in welcher Reihefolge Maßnahmen (Jobs) an Anlagen bewältigt werden können. Das
Verfahren ist an das Travelling-Salesman-Problem angelehnt. Die Verarbeitung der Jobs an den jeweiligen Anlagen ist
abhängig von der Priorität des Jobs und der Entfernung zur nächsten Anlage. Eine Bewertungsfunktion (Simulation eines
menschl. Entscheiders) ist noch nicht implementiert. Dieses Optimierungsverfahren macht eventuell erst bei größeren
Windparks Sinn.
Als weiterer Ansatz wurde hierzu das Vehicle Routing Problem (VRP) angesprochen.
Aufgaben: Verantwortliche: Deadline:
1

Protokoll Nr. 19
Montag, 11.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
VRP anschauen/bewerten/Relevanz für SCOWS
untersuchen
Alle
Christian
Keiner
18.03.13
4 Aufgabenverteilung
Diskussion & Ergebnisse:
Datenmodell in SystOp Offshore Wind: GWPPM – Datenmodell (S.65) untersuchen/bewerten/ggf. erweitern oder kürzen
(Carsten)
Präsentation überarbeiten, Literatur untersuchen (Stefan)
GUI: Shimal, Georg
Quellenrecherche: Svetlana, Nashida
Sitzungsschluss: 17:00 Uhr
Aufgaben: Verantwortliche: Deadline:
Alle Keiner 18.03.13
2

Protokoll Nr.20
Montag, 18.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Shimal
Protokollführung:
Nashida
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion & Ergebnisse: Organisatorisches
BTC bestätigt den Termin bei uns, der Termin findet am 19.03.2013 um 12:00 Uhr statt
Aufgaben: Verantwortliche: Deadline:
Präsentation übernehmet Shimal falls Stefan noch
krank
Alle
Keiner
2 Agendapunkt 2
Diskussion & Ergebnisse: SysTop wissen auf unseren Projekt Übertragen
Wir haben die SysTop Dokument diskutiert , am Ende dieser Diskussion haben wir festgelegt dass wir nur Kurzfristige
Planung ,Simulation und Optimierung machen wollen
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Agendapunkt 3
Diskussion & Ergebnisse: Simulationsausführung
Raphaël hat die Ablauf der Simulationsausführung vorgestellt ( soll im Git)
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Agendapunkt 4
Diskussion & Ergebnisse: Aufgaben
1

Protokoll Nr.20
Montag, 18.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Wir haben viele Aufgaben die verteilt werden müssen aber machen wir nächste Woche
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 21
Montag, 25.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Stefan Wunderlich
Protokollführung:
André Wolter
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion & Ergebnisse: Besprechung (Weekly Scrum) der letzten Tätigkeiten jedes Projektmitglieds.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Agendapunkt 2
Diskussion & Ergebnisse:
Bachelorarbeit bei Jan. Ziel ist die Analyse der von Overspeed genannten Hauptszenarien. Zum Beispiel könnte eine kleine
Simulation stattfinden.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Agendapunkt 3
Diskussion & Ergebnisse: Organisatorisches
Schon etwas von der BTC gehört?
Schon die SystOp-Grafik erhalten?
Zusätzliches Treffen am Mittwoch und Donnerstag ab 14:00 Uhr.
- Am Mittwoch mit 5 Leute
- Am Donnerstag mit 7 Leute
1

Protokoll Nr. 21
Montag, 25.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Mittwochtreffen:
- Design-Konzepte / GUI-Konzepte diskutieren
- Umsetzen der Konzepte
- Vorstellung BDI-Agent
Donnerstagtreffen:
- Orientiert sich an den Ergebnissen von Mittwoch
Termin mit Overspeed für nächste Woche noch weiter in die Zukunft verschieben (Jan), z.B. Anfang Mai.
Montagstermin soll wenn möglich erhalten bleiben, ansonsten frühzeitig mit der Projektleitung klären.
Donnerstag wird eine Doodle-Umfrage für das Treffen in der nächsten Woche gestartet.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Agendapunkt 4
Diskussion & Ergebnisse: Vorstellung eines GUI-Konzeptes zur Erstellung eines initialen Einsatzplans. Der initiale Einsatzplan
wird tagbasiert geplant. Verschiedene Objekte (Jobs, Schiffe, Crew, etc.) können per Drag & Drop auf das Planungsfenster
gezogen werden.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
5 Agendapunkt 5
Diskussion & Ergebnisse: Erstellung einer Dokumentation für das Datenmodell.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 23
Montag, 10.04.2013
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
ALLE
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Terminabklärung:
- Neuer regelmäßiger Termin am Mittwoch von 12:00h bis 16:00h
- Freies Treffen am Dienstag, ab dem 30.04.2013 von 10:00h bis 18:00h
Dokumentation:
- Verwaltung des Abgabedokuments
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
regelmäßig
Dokumentenverwaltung
Carsten und Stefan
2 Wo stehen wir?
Diskussion & Ergebnisse:
- Graphische Benutzeroberfläche (konnte nicht vorgestellt werden, da die Datenbankanbindung nicht funktionierter)
- VERSION VON JAVA UND ECLIPSE festgelegt:
- Eclipse Juno Release 2
- Java Version 1.7
Wie ist der Stand der Website?
Schnittstellenplan:
- wird von André erstellt
Aufgaben: Verantwortliche: Deadline:
- Einen Schnittstellenplan erstellen
- Beispielplan Schiffe
- Qualifikation der Ressourcen
- Datenbank muss funktionieren
- Optimierungsmöglichkeiten überdenken
Alle Keiner
André Wolter
Christian Menne
Stefan Wunderlich
Carsten Buschmann
???
17.04.2013
17.04.2013
24.04.2013
regelmäßig
noch zu klären
1

Protokoll Nr. 23
Montag, 10.04.2013
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
ALLE
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Terminabklärung:
- Neuer regelmäßiger Termin am Mittwoch von 12:00h bis 16:00h
- Freies Treffen am Dienstag, ab dem 30.04.2013 von 10:00h bis 18:00h
Dokumentation:
- Verwaltung des Abgabedokuments
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
regelmäßig
Dokumentenverwaltung
Carsten und Stefan
2 Wo stehen wir?
Diskussion & Ergebnisse:
- Graphische Benutzeroberfläche (konnte nicht vorgestellt werden, da die Datenbankanbindung nicht funktionierter)
- VERSION VON JAVA UND ECLIPSE festgelegt:
- Eclipse Juno Release 2
- Java Version 1.7
Wie ist der Stand der Website?
Schnittstellenplan:
- wird von André erstellt
Aufgaben: Verantwortliche: Deadline:
- Einen Schnittstellenplan erstellen
- Beispielplan Schiffe
- Qualifikation der Ressourcen
- Datenbank muss funktionieren
- Optimierungsmöglichkeiten überdenken
Alle Keiner
André Wolter
Christian Menne
Stefan Wunderlich
Carsten Buschmann
???
17.04.2013
17.04.2013
24.04.2013
regelmäßig
noch zu klären
1

Protokoll Nr. 24
Mittwoch, 17.04.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 12.00 – 16.00 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
Moderation: Carsten B.
Protokollführung: Raphael K.
Abwesende: Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Begrüßung
Diskussion:
Nächsten Mittwoch (24.03.2013) treffen wir uns nach der Sitzung vor Gebäude A14 für ein Teamfoto (spätestens gegen 16
Uhr).
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Organisatorisches (Redmine)
Diskussion:
- Bitte in Redmine einstellen, dass ihr eine E-Mail erhaltet, sobald euch eine Aufgabe zugewiesen wird.
- Vorgehensmodell SCRUM in einem Sprintzeitraum von zwei Wochen. Jeder erhält Aufgaben zugewiesen und
- Falls man ein Problem nicht selber lösen kann, sofort ein Ticket erstellen
- Svetlana wird ab Anfang August ein Auslandsaufenthalt beginnen und übernimmt Struktur und des Finalen
Abgabedokuments und gegebenenfalls ein Grundlagenkapitel.
- Es ist unsicher, ob Khisrav im August noch da sein kann, da sein Visum abläuft.
- Ab Anfang August werden voraussichtlich 3 Personen (Shimal, Svetlana und Khisrav) nicht mehr in Oldenburg an der
PG mitarbeiten können.
- Carsten übernimmt Aufgaben von Shimal und Svetlana.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner

2
3 Simulation
Diskussion:
• Schnittstellenplan wird von André vorgestellt. Dazu siehe „Anwendungsmodule.pdf“ (siehe auch Anhang diese
Protokolls)
• GUI-Entscheidung: Zunächst soll mit mehreren Fenstern gearbeitet werden. Die Endversion des Programms sollte
jedoch komplett über ein Fenster gesteuert und ausgeführt werden.
• Datenbank: Die Datenbank ist eingerichtet und Daten können bereits darin gespeichert werden. Die Technologie und
Code dazu können im Projekt-Code gefunden werden.
• Data Im-/Export Modul: Zum Einlesen z. B. (vorformatierter) Werte (z. B. aus Excel bzw. csv-Datei). Dieses wird durch
die Klasse „Importer“ im „scows-db“ umgesetzt.
• Admin-Modul: Einstellen von Parameter-Werten (ini-Datei / Properties etc.)
• Data Definition Modul: Zum Eingeben neuer Objekte und Daten. Kann man als Import machen oder nach und nach über
die GUI.
• Job Scheduler Modul: Reihenfolge von Jobs manuell definieren können. Ergebnis ist ein Plan, welcher dem
Simulationsmodul übergeben wird.
• Simulationsmodul: Für Simulation verantwortlich. Arbeitet mit fertigen Schedules. Ergebnisse gehen an Job Scheduler.
• Problem: Wo sitzt die Optimierungskomponente? Die ist als ein eigenes Modul definiert. Mehr dazu, siehe Anhang dieses
Protokolls.
• Weitere Informationen zu den Schnittstellen wurde von André festgehalten.
Ergebnisse:
Dateien:
• „Anwendungsmodule.pdf“
• „Zusammenhang der Module und Ablauf.docx“
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Optimierungsrichtung & Bewertungskriterien für Jobs
Diskussion:
Folgende Punkte wurden aus Zeitgründen auf die nächste Sitzung verschoben:
• Welche Richtung soll die Optimierung nehmen?
• Vihecle-Problem
• BackEnd-Optimierung
• Bewertungskriterien für die Jobs
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner

Protokoll Nr. 25
Montag, 24.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation: Raphael K.
Protokollführung:
Shimal I
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Die Gruppe trifft sich Freitag ab 8 Uhr im PG-Raum.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Optimierungsrichtung
Diskussion & Ergebnisse:
Georg und Shimal stellen ein Konzept für die Optimierung vor. Die Gruppe diskutiert die einzelnen Schritte und schlägt
Verbesserungen vor. Das Konzept befindet sich im Anhang dieses Protokolls.
Zu beachten, dass im Algorithmus noch Teilalgorithmen fehlen. Diese sollen von der Optimierungsgruppe vervollständigt
werden.
Eine weitere Anmerkung von Carsten war, was passieren würde, wenn die Jobs mit niedriger Priorität immer nach hinten
verschoben werden? Was, wenn am Ende zu wenige Transportmittel zur Verfügung stehen, sodass die Ausführung aller Jobs
mit niedrige Priorität nicht möglich ist? (Lösung siehe Protokoll Nr. 26)
Aufgaben: Verantwortliche: Deadline:
Alle
Georg, Shimal
Keiner
1

Protokoll Nr. 25
Montag, 24.03.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
3 Aufgabenverteilung
Folgende Aufgaben wurden generiert. Diese sollten bis zu den genannten Daten erledigt werden.
Aufgaben: Verantwortliche: Deadline:
- Optimierungsprozess und –ablauf erweitern
- Ressourcenplan erstellen und in die
Datenbank speichern
- Dokumentation um Optimierungskonzept
erweitern
- Erstellung eines „Simulatinskonzepts“
Alle Keiner
Khisrav, Nashida
Svetlana
Simulationsgruppe
Freitag 26.04.13
Freitag 26.04.13
Mittwoch 01.05.13
Mittwoch 01.05.13
2

Protokoll Nr. 26
Freitag, 26.04.13
cows
AUßERORDENTLICHES TREFFEN
UHRZEIT: 08.15 – 12.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 BackEnd - Optimierung
Diskussion & Ergebnisse: Umsetzung der Optimierung, um möglichst wichtige
- Welche Zielgrößen? 1. Kürzeste(r) Route/Weg; 2. Minimale Kosten; 3. Maximale Auslastung; 4. Job-Wichtigkeit
5. Kürzeste Zeit;
- Zu 1. Kürzester Weg entspricht der Intraparklogistik, die Wege von Anlagen innerhalb eines Windparks
- Zu 2. Minimale Kosten beinhaltet Anlagenkosten, Personalkosten, Transportkosten
- Zu 3. Maximale Auslastung der Ressourcen Transportmittel und Teams in Stunden
- Zu 4. Job-Wichtigkeit ist bestimmt durch die festgelegte Priorität
(- Zu 5. Kürzeste Zeit bedeutet, dass entweder kürzeste(r) Route/Weg, Parallel-Arbeit)
Einflussfaktoren auf die Optimierung
Wetter hat Auswirkungen
- auf die Zeit á
- auf die Kosten á
Schnittstellenplan ergänzt und verbessert
Aufgabenverteilung nach Modulen:
Aufgabenmodule ND GB CB KE SI RK SK CM AW SW
Simulation X (X) X X X X
Scheduling X X X X
Server X X X
Optimierung X (X) (X) X X X
GUI (x) X X X X
Dokumentation X X X (X)
Aufgaben: Verantwortliche: Deadline:
- Siehe Modulverteilung
Alle
Keiner
- Projektendeterminierung
31. August 2013
1

Protokoll Nr. 27
Montag, 08.05.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 16.00 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
Moderation:
Shimal
Protokollführung:
Khisrav
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisch
Diskussion & Ergebnisse: Treffen von Kleingruppen, Redmine und Meilensteine, Gruppenfoto
Scheduling, Simulation und GUI Gruppen treffen Dienstags und Freitags
Optimierung Montag 1 Stunde, Dienstag
Dokumentation haben noch keinen Termin
Redmine. Jede Gruppe muss Zeitpunkt von Aufgaben im Redmine sehen. Aufgaben nach Schließe müssen als Komplet
markiert sein
Gruppenfoto
Montag 13.05 14.00-16.00 A07-HS G findet Abschlusspräsentation der Projektgruppe Cuberunner statt.
Khisrav fährt 01.08 nach Heimat zurück deswegen Visum
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Ergebnissepresaentation
Diskussion & Ergebnisse: Optimierung, Simulation und Scheduling, Dokumentation
Optimierungsgruppe Präsentation (Andre): Mit Frisia telefoniert. Max 24 Leute können im einem Wartungsschiff fahren. Für
Optimierung Generische Algorithmus benutzen
Aufgaben: Verantwortliche: Deadline:
Optimierungsgruppe muss
Informationen(Algorithmus, Ergebnisse) für
Simulationsgruppe vorbereiten
Alle
Keiner
Optimierungsgruppe
14.05.13
3 Probleme klaren
Diskussion & Ergebnisse:
Verbindung von Optimierung und Simulation. Wie funktioniert das? Zuerst Optimierung, nach Ergebnis zu Simulation geben.
Aufgaben: Verantwortliche: Deadline:
Dienstag 14.05.13 die Gruppen treffen sich und Alle Keiner 14.05.13
1

Protokoll Nr. 27
Montag, 08.05.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 16.00 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
besprechen
Optimierung- und
Simulationsgruppe
4 Sonstiges
Diskussion & Ergebnisse:Keine
Aufgaben Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 28
Mittwoch, 15.05.2013
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 16.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Khisrav
Protokollführung:
Svetlana
Abwesende: Nashida B.
Georg B.
Carsten B.
Khisrav E.
Shimal I.
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W.
1 Organisatorisches
Diskussion:
Wann machen wir Gruppenfoto?
Ergebnisse:
Im Juli
Aufgaben: Verantwortliche: Deadline:
Alle Keiner 31.07.2013
2 Ergebnisse von Kleingruppen
Diskussion: Optimierung und Simulation, GUI, Implementierung, Dokumentation
Ergebnisse:
Die Optimierung Gruppe stellt endgültige Ergebnisse bis nächste Sitzung fest, um die weitere Ausarbeitung von Simulation
Gruppe zu ermöglichen. Nachdem die Optimierung Gruppe die Ergebnisse präsentiert, geht es weiter mit Simulation, GUI
und Implementierung
Dokumentation Gruppe verarbeitet die erste Kapiteln (Einleitung, Seminarthemen usw)
Aufgaben: Verantwortliche: Deadline:
Endgültige Ergebnisse feststellen Alle Keiner
22.05.2013
Optimierungsgruppe
3 Sonstiges

Protokoll Nr. 29
Mittwoch, 22.05.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten
Protokollführung:
Christian
Abwesende:
Nashida B.
Carsten B.
Khisrav E
Niemand
Raphaël F.K.
Christian M.
André W.
Shimal
I.
Stefan
W
1 Organisatorisches
Diskussion & Ergebnisse:
Es gab keine organisatorischen Themen, die besprochen werden mussten
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Fortschrittberichte
Diskussion & Ergebnisse:
Ein Vertreter jeder Arbeitsgruppe stellt die Ergebnisse der letzten Woche vor:
Simulation (Christian):
• Simulationsablauf für Aufgabe als Fitnessfunktion für Optimierung angepasst
• Wettereinflüsse werden momentan auf ihre Bedeutung für das Projekt geprüft
Dokumentation (Svetlana):
• Anforderungsanalyse- und Simulationsteil in Arbeit
• für den Optimierungsteil fehlen noch Ergebnisse
Profilbearbeitung (Carsten):
• Vorlage wurde erstellt und wird an alle Mitglieder geschickt.
Scheduling (Khisrav):
1

• Auslagerung der Kontrollmethoden aus den Views und Dialogen
• Datenbankverbindung kann nicht hergestellt werden
Optimierung: siehe Punkt 3 ''Optimierung''
Aufgaben: Verantwortliche: Deadline:
1) Verschicken der Profilvorlagen
2) Ausfüllen der Profilvorlage und beifügen eines
Fotos
1) Carsten
2) Alle
1) 23.05.2013
2) 26.05.2013
3 Optimierung
Diskussion & Ergebnisse:
Die Fortschritte der Optimierungsgruppe werden vorgestellt (André):
• Identifizierung von möglichen Optimierungsverfahren
• GAP (Genetischer Algorithmus und Constraint Programming) als Ansatz
◦ Constraints werden nach jeder Operation genutzt um Gültigkeit der Lösungen sicherzustellen
• Diskussion über Routenproblem bei paralleler Abarbeitung von Job und das Abholen von Personal
• Treffen mit Herrn Sauer (Freitag 14:00)
Aufgaben: Verantwortliche: Deadline:
Validierung, ob das Verfahren für unser Projekt
genutz werden kann
Optimierungsgruppe 29.05.2013
4 Sonstiges
Diskussion & Ergebnisse:
Verteilung von Aufgaben, die sich nicht auf die Arbeitsgruppen beziehen
Aufgaben: Verantwortliche: Deadline:
1) Die Modellklasse 'Vehicle' und die zugehörige
Datenbanktabelle muss um die Charterkosten und
den Treibstoffverbrauch ergänzt werden
2) Umleitung auf die Webseite sicherstellen
1) Georg
2) Raphaël
1) 29.05.2013
2) 29.05.2013
2

Protokoll Nr. 30
Mittwoch, 29.05.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 14.47 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Christian Menne
Protokollführung:
André Wolter
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse: Organisation
Stefan möchte SCRUM stärker einsetzen
o Sprint sollte für 2 Wochen definiert werden
o Es sollte festgelegt werden, was innerhalb des Sprints zu erreichen ist
Vorschlag von Shimal zur Planung der Sitzungszeit
o Die erste Stunde sollte zum präsentieren der Ergebnisse genutzt werden
o Die zweite Stunde sollte zur gemeinsamen Arbeit genutzt werden
Aufgaben: Verantwortliche: Deadline:
Alle Mitglieder sollen Redmine/SCRUM nutzen
Jedes Team sollte seine darin Ziele definieren
Alle Keiner 05.06.2013
1

Protokoll Nr. 30
Mittwoch, 29.05.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 14.47 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
2 Ergebnisse
Diskussion & Ergebnisse:
Simulationsgruppe (Verantwortlicher Carsten):
Das Wetter wird entsprechend den anderen Modulen
Dokumentationsgruppe ():
Profile müssen noch gesendet werden
Es werden noch die Kapitel zur Optimierung benötigt
ZIEL: Es wird immer nur die PDF ins git geladen
Scheduling-Gruppe (Kishrav):
Joblisten sind jetzt … ?
ZIEL: Das Scheduling-Team arbeitet weiter an der Implementierung?
Optimierungsgruppe (Stefan):
Ergebnis des Meetings mit Prof. Sauer
Von Prof. Sauer wurde eine heuristische Herangehensweise präferiert (Metaheuristik)
Das Wetter sollte als Hard-Constraint betrachtet werden
Die Simulation dient der Prüfung der Robustheit
ZIEL: Die ersten Schritt werden die Kosten optimiert
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Optimierungsgruppe mit Bezug zur Simulationsgruppe
Diskussion & Ergebnisse:
Wurde diskutiert unter Punkt 2
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Simulation Wetter
Diskussion & Ergebnisse:
Einflussfaktoren vom Wetter
Einflussfaktoren auf die Geschwindigkeit der Transportmittel
Ausführung nicht möglich wenn
2

Protokoll Nr. 31
Mittwoch, 12. Juni 2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 12.30 – 13.30 UHR
GRUPPENARBEITSRAUM: 4.3, Zentralbibliothek
RAUMERGÄNZUNG: Ebene 4 (Raum 407)
PG-SCOWS@UNI-OLDENBURG.DE
Moderation:
Shimal Ibrahim
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Optimierungsteam
Diskussion & Ergebnisse: Interview mit der HTM (zusätzliche Informationen, die nicht dokumentiert sind)
- Schiffseinsatz : Helikoptereinsatz = 1 : 4 Verhältnis in der Ostsee; 1 : 1 Verhältnis in der Nordsee
- Kosten eines Helikoptereinsatzes kosten 6000,- Euro bis 7000,- Euro
- Trockenanzüge der Mitarbeiter werden auf der Anlage abgelegt, damit sie vernünftig arbeiten können
- Generell wird nur auf den Windenergieanlagen gelandet, aber nicht gestanden
Bedeutung für die Optimierung:
- Helikopter wird nur dann eingesetzt, wenn die Wellenhöhe über 1,5m ist und der Ausfall der Anlage teurer als die
Instandsetzung mit dem Übersetzen des Helikopters
- Normalfall (wichtiger) oder Sonderfall optimieren (neuer Meilenstein)
- Job mit den meisten Mitarbeitern ist in der Regel ausschlaggebend zur Abarbeitung
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
12.06.2013
Interviews geführt
André Wolter
Konzept der Optimierung vorstellen (fertig sein)
Optimierungsteam
19.06.2013
2 Simulationsteam
Diskussion & Ergebnisse:
- Erneute Überarbeitung des Simulationsablaufs mit:
à pro Sekunde wird eine Aktualisierung der Karte vorgenommen (abhängig von der Geschwindigkeit des
Transportmittels)
à sobald alle Akteure fertig sind, wird nächste Aktualisierung gestartet
- Überarbeitung der Karte/ des Kartenhandlings
à zeichnen der Karte über DoubleBuffer
à bewegen der Karte per DragListener
- Sequenzdiagramm vom Simulationsablauf (Akteur-Kommunikation)
1

Protokoll Nr. 31
Mittwoch, 12. Juni 2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 12.30 – 13.30 UHR
GRUPPENARBEITSRAUM: 4.3, Zentralbibliothek
RAUMERGÄNZUNG: Ebene 4 (Raum 407)
PG-SCOWS@UNI-OLDENBURG.DE
Aufgaben: Verantwortliche: Deadline:
Wichtige Aufgaben:
- Simulationsende nach Ablauf des Arbeitstages
- Jobs stärker beachten (Anlegedauer,
Ausführungsdauer, Jobende, Abholung usw.)
- Akteure speichern Ereignisse während der
Simulation à z.B. JobID; Zeit; Ereignistyp; Grund
- Akteure in Listen einfügen
Optional:
- Zoomfunktion überarbeiten (Ausrichtung nach
Bildmitte)
- Routen sichtbar machen (Checkbox in Liste)
-Zentrieren der Karte auf Akteur über Liste
(Doppelklick)
Abgebbare Aufgaben:
- Hafenklasse erzeugen + mögliche Häfen mit
Position identifizieren
- Seetonnenposition identifizieren (à Routen von
Hafen bis Meer)
- Symbole für Akteure anfertigen:
à Schiffe + Helikopter mit Richtung
à Windenergieanlagen + Häfen (WEA vielleicht mit
verschiedenem Status)
- Überarbeitung der Projektstruktur
à 1 Projekt
à Pakete neu strukturieren und Klassen zuweisen
à Klassendiagramm zur Übersicht (ObjectAiD-
PlugIn für Eclipse)
Alle Keiner
Simulationsteam
An alle Projektmitglieder
3 Scheduling-Team
Diskussion & Ergebnisse: Aufgabe ergänzt und erweitert
Aufgaben: Verantwortliche: Deadline:
- Zeitliche Arbeitstag vorgeben:
Sommerzeit/ Winterzeit/ manuelle Eingabe
- Transportmittel anlegen können:
Alle
Khisrav
Keiner
Besprechung am Freitag, den
14.06.2013
Spezifikationen festlegen
2

Protokoll Nr. 32
Mittwoch, 19.06.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten und Stefan
Protokollführung:
Nashida
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse: Organisation
Teilnahme der PG SCOWS beim Projetgruppenfußballturniere: 8 Mitglieder wollen teilnehmen
Mail Bestätigung wurde gesendet
Aufgaben: Verantwortliche: Deadline:
Die Anwesenheit der 8 Mitgliedern, die Teilnehmen
wollen
Alle
Die 8 Mitgleider
Keiner
03.07.2013
2 Zusammenfassung (Dokumentation)
Diskussion & Ergebnisse: Carsten hat erzählt das die Dokumntationsgruppe stätig voran kommt, Svetlana hat die Interweis
gearbeitet, Nashida hat die Anforderungen bearbeitet
Aufgaben: Verantwortliche: Deadline:
Es wird benötigt die Konzepte von Simulation und
Optimierungsgruppen
Schnittstelle zu Scheduling und Optimierung
Alle Keiner
Simulationsgruppe
Optimierungsgruppe
03.07.2013
3 Zusammenfassung (Scheduling)
Diskussion & Ergebnisse: Shimal hat gesagt das keine Problem gibt und die Transportmittel kann erstellt werden falls nicht
vorhanden sind
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 32
Mittwoch, 19.06.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
4 Zusammenfaasung(Simulation)
Diskussion & Ergebnisse:
Die Akture sind in Listen eingefügt
Agenten werden unter einander besser belogen
Nach der Simulation : potentiale Nutzer können Informationen gewinnen
Real Geschwindigkeit unter die Wetterbedingungen wird integriert
Aufgaben: Verantwortliche: Deadline:
Alle Keiner
5 Zusammenfaasung(optimierung)
Diskussion & Ergebnisse: Stefan und Raphaël haben eine Konzepte gearbeitet, in den Bericht steht was wird für die
Optimierung benötigt und in welche Zeitfenster wird gearbeitet
Eine Problem ist aufgetreten und soll die Gruppe am Freitag um diese Problem kümmern und die Ansatz von André
bearbeitet zu können
Statusbericht legt im Git
Aufgaben: Verantwortliche: Deadline:
Optimierung Problem Alle Keiner
21.06.2013
Optimierungsgruppe
6 Zusammenfaasung(Datenbank und Sonstiges)
Diskussion & Ergebnisse:
Datenbanken: Zugriff
- Server url: scows-jsc -> app-config.xml -> backend
- https://duemmer.informatik.uni-oldenburg.de:61294/scows-backend/rest/
- scows-jsc -> org.scows.comm.JobClient :: getAll()
Aufgaben: Verantwortliche: Deadline:
Datenfehlerbehebung fall gibt Alle Keiner
Gerog
2

Protokoll Nr. 34
Mittwoch, 10.07.2013
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten & Shimal
Protokollführung:
Carsten Buschman
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisation
Diskussion & Ergebnisse: Nashida Barakat (unter Umständen ab Ende Juli 2013), Svetlana Kapitanova (25.07.2013), Khisrav
Evazov (25.07.2013) und Shimal Ibrahim (10.08.2013) im Ausland
Aufgaben: Verantwortliche: Deadline:
keine Alle Keiner -
2 Optimierung
Diskussion & Ergebnisse: Überlegung des Konzeptes vorgestellt; Ein Job ist für je eine Anlage;
Problem:
Beschlossen:
Job zusammenfassen, sodass immer mindestens drei Arbeiter an einer Anlage
arbeiten (HSE-Aspekte) entgegen jeden Job für sich betrachten, die aber
gleichzeitig an einer Anlage durchgeführt werden können
Jeder Job wird für sich betrachtet!
Aufgaben: Verantwortliche: Deadline:
Konzept von Raphaël ist akzeptiert und soll von der
Optimierungsgruppe umgesetzt werden
Alle
Optimierungsgruppe
Keiner
24.07.2013 (Prototyp)
Untergruppen haben kurz ihren Status präsentiert und hier sind keine Probleme aufgetaucht. Außerdem sind viele auf das
Konzept der Optimierungsgruppe angewiesen.
Die Deadline für die Optimierungsgruppe muss unbedingt für die Einhaltung des Projektergebnisses einzuhalten!
1

3)
Protokoll Nr. 35
Montag, 17.07.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten
Protokollführung:
Christian
Abwesende:
Nashida B.
Carsten B.
Khisrav E
Niemand
Raphaël F.K.
Christian M.
André W.
Shimal
I.
Stefan
W
1 Organisatorisches
Diskussion & Ergebnisse:
1)Das Gruppenfoto soll am Mittwoch den 24.07. gemacht werden.
2) Die Deadline für für das Projekt bleibt Ende August.
3) Für die Dokumentation der Klassen soll Javadoc verwendet wrden. Für die Doukumentation ist hierbei jeweils der
Verfasser des Codes verantwortlich.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Fortschritte der Gruppen
Diskussion & Ergebnisse:
Dokumentationsgruppe:
• stetiger Fortschritt
• Konzept der Simulation ist in Arbeit
• Indizierung des Dokuments ist in Arbeit
• Für die Dokumentation der Optimierung fehlt das Konzept der Optimierungsgruppe
Simulationsgruppe:
• Yellowpages-Klasse bietet die Möglichkeit Akteure anhand ihrer ID anzusprechen
• Probleme beim zeitlichen Ablauf der Simulation:
1

• WEA muss Zusage für das Andock an der Anlage widerrufen, wenn ein anderes Transportmittel eher ankommt
• Absage muss bis zur ControlStation durchgegeben werden und die entsprechenden Zustände geändert werden
• WEA-Akteur wartet, bis er eine Nachricht über die erfolgreiche Zustandsänderung erhalten hat
Optimierungsgruppe:
• Konzeptideen wurden konkretisiert
• Eine Formel für den Gewinnausfall für eine Anlage wird gesucht
• Anlagen werden beim Betreten durch Personen abgeschaltet, unabhängig vom Job an der Anlage
• Vorerst werden 2 Ansätze umgesetzt (Raphaël, Stefan / André, Georg)
• Vergleich der Ansätze auf Gemeinsamkeiten bezüglich der Umsetzung soll erfolgen
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Deadlines
Diskussion & Ergebnisse:
1) Die Arbeiten an der Simulation soll bis zum 31.07. fertiggestellt sein.
2) Ein Konzept für die GUI wird bis Mittwoch den 24.07. erstellt.
3) Das/Die Optimierungskonzepte sind bis zum 24.07. fertigzustellen.
4) Die Implementierung der Optimierung soll bis zum 18.08. abgeschlossen sein.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 36
Montag, 24.07.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 16.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
André Wolter
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion & Ergebnisse: Organisatorisches
-Deadline für die Gesamtabgabe bleibt bei Ende August
Aufgaben: Verantwortliche: Deadline:
Alle Keiner 31.08.2013
2 Agendapunkt 2
Diskussion & Ergebnisse: Eclipse Projekt Struktur
- Projekte werden erst einmal nicht zusammengefasst
- Evtl. wird zum Schluss ein Gesamtprojekt erstellt oder es wird ein Zusammenfassungsprojekt erstellt
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Agendapunkt 3
Diskussion & Ergebnisse: Status der Optimierung
- Raphael & Stefan verfolgen einen Ansatz mit Clustering und blockweiser Betrachtung der Jobs je Anlage
- André verfolgt einen heuristischen Einsatz zur Verteilung der Transportmittel und einen differenzierten Ansatz der Jobs je
Anlage
- Die Konzepte werden am Montag 29.07.2013 in einer ersten Fassung bereitgestellt
Aufgaben: Verantwortliche: Deadline:
Erstellung der Konzepte Alle Keiner
29.07.2013
Raphael & Stefan
André
1

Protokoll Nr. 36
Montag, 24.07.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 16.00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
4 Agendapunkt 4
Diskussion & Ergebnisse: Konzept für Simulation
- Christian hat das Konzept für die Simulation grundsätzlich fertig gestellt (Dokument)
- Das Dokument liegt Carsten Buschmann vor
Aufgaben: Verantwortliche: Deadline:
Alle
Christian Menne
Keiner
5 Agendapunkt 5
Diskussion & Ergebnisse: Dokument
- Nashida hat ein Dokument für die Anforderungen erstellt
- Das Dokument wird Carsten Buschmann am Freitag (26.07.13) zugestellt
Aufgaben: Verantwortliche: Deadline:
Dokument übermitteln Alle Keiner
26.07.13
Nashida Barakat
2

Protokoll Nr. 37
Montag, 31.07.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
André
Protokollführung:
Stefan
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Jan-Heinrich muss Kuchen mitbringen. Unangekündigtes Fehlen.
Khisrav ist weg. Hat kein Visum mehr. Svetlana ist auch weg. Kommt auch nicht mehr wieder.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Weekly Scrum
Diskussion & Ergebnisse:
Jeder beschreibt seine Tätigkeiten fürs Projekt in der vergangenen Woche.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Fortschritt
Diskussion & Ergebnisse:
Simulation: Fast fertig. Laut Shimal.
GUI/Scheduling: Überarbeitung hinsichtlich Optimierung. Stellgrößen, die sich aus Opt ergeben, fehlen noch.
Doku: Läuft. Nichts Neues.
Opt: André stellt parallel-sequenziellen Ansatz vor. Konzepte wurden an Doku-Gruppe weitergegeben.
Zeitfenster werden mit Start- und Endzeitpunkt übergeben. Klasse TimeWindow(?) Zeiten sind inkl. Fahrtzeit.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 37
Montag, 31.07.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
4 Was brauchen wir von anderen Kleingruppen?
Diskussion & Ergebnisse:
Opt. braucht für jedes TM die Zeit, die es zum Windpark benötigt. Eigentlich brauchen wir nur die Zeit, aber auch wie viel
Benzin das jeweils kostet. Kann man aber auch ausrechnen.
Sollen mehrere/ alternative Pläne ausgegeben werden? Tendenziell nicht, da alle durchsimuliert werden müssen.
Jedes Schiff holt und bringt nur seine „eigenen Leute“
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 38
Mittwoch, 07.08.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Christain
Protokollführung:
Nashida
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Orgaistorisches
Diskussion & Ergebnisse:
Shimal kommt noch
Die PG Prüfung wird von Herr sauer festgestellt.
Keine Unterschrift für die Abgabe der Dokumentation nötig
Aufgaben: Verantwortliche: Deadline:
PG Prüfung Alle Keiner
Herr sauer
2 Kurzer Bericht über den Status
Diskussion & Ergebnisse:
Dokumentation: läuft gut ,Carsten hat die fehlende Informationen bei die HSE und Navigationsaspekte gearbeitet ,für die
Optimierung Konzepte brauchen wir Quellen( Per Mail )
Simulation: läuft auch gut aber mit kleine Problem bei die Akture , die Problem wird bis Sonntag gelöst.(Keine echte Zeit
laufen lassen)
Optimierung:
André : André die Konzepte wird verfeinert, baut noch Klassendiagramm, Schnittstelle zur Simulation und Scheduling wird
bearbeitet,
Stefan und Raphaël: bearbeiten die Heuristik Konzepte und wird alles bis 18.08.2013 abgegeben
GUI: die Visualisierung wird nach Zeit und Pro Transportmittel.(Bildern soll im git)
Aufgaben: Verantwortliche: Deadline:
Optimierung Konzepte Alle Keiner
18.08.2013
Optimierungsgruppe
3 Klärung von Problemen
Diskussion & Ergebnisse:
Wir hätten schön über die gesamte Bild und Struktur unsere Projekt gesprochen
1

Protokoll Nr. 38
Mittwoch, 07.08.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Sonstiges
Diskussion & Ergebnisse:
Keine
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 39
Montag, 14.08.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14:00 – 16:00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Nashida Barakat
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
- Pre-Deadline auf 20.08.2013 verschoben
- Bis zum 19.08.2013 muss auf die Server-Nutzung verzichtet werden
- Shimal hat heute (14.08.2013) die letzte aktive Teilnahme an der Sitzung
- Simulations- und Optimierungsgruppe trifft sich am Dienstag um 10:00h im PG-Raum
- Elektronische Anmeldung beantragt am 12.08.2013; Prüfungsamteintragung bis 30.08.2013
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
- Server neustarten
- Deadline beachten
Georg Berendt 19.08.2013
20.08.2013
2 Kurzberichte der Teilgruppen
Diskussion & Ergebnisse:
- Dokumentationsgruppe hat die einzelne Teilbereiche ergänzt, zusätzlich der Schnittstellenplan für alle Module
erstellt
- Christian arbeitet an der Visualisierung der Simulation
- Optimierungsgruppe:
à Gruppe 1: Arbeitet am Clustering
à Gruppe 2: Setzt die Optimierung im einfachsten Rahmen um
à Gruppe 3: Setzt ein weiteres Optimierungskonzept um
- Zeitfenster stellt den Arbeitstag dar, z.B. von 08:00h bis 15:00h kann man arbeiten
- Konflikt: Die Optimierungsgruppe steht im Konflikt mit dem Optimierungsansatz von Georg; dieser Ansatz wird nicht von
der Optimierungsgruppe anerkannt. Es wird der Einwand erhoben, dass es an Respektlosigkeit grenzt, wenn man die Arbeit
der Optimierungsgruppe nicht anerkennt.
- Weiterer Konflikt: Einheitliche Schnittstelle
Aufgaben: Verantwortliche: Deadline:
Siehe Diskussion & Ergebnisse
Alle
Keiner
1

Protokoll Nr. 39
Montag, 14.08.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14:00 – 16:00 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
- Schnittstellenplan
- Anforderungen
- Restlichen Konzepte
- Visualisierung der Simulation
- Clustering der Optimierung implementieren
- Optimierung im einfachsten Rahmen
- Ein weiteres Optimierungskonzept nach einem
weiteren Clustering
Nashida
Carsten
Christian
Raphaël und Stefan
André
Georg und Shimal
28.08.2013
20.08.2013
21.08.2013
20.08.2013
20.08.2013
20.08.2013
20.08.2013
3 Schnittstellenplan
Diskussion & Ergebnisse:
- Welchen Input und welcher Output ist notwendig
Aufgaben: Verantwortliche: Deadline:
Schnittstellenplan der Optimierung
- Übergabe und Erklärung an Nashida
Schnittstellenplan der Simulation
- Übergabe und Erklärung an Nashida
Schnittstellenplan des Scheduling
- Übergabe und Erklärung an Nashida
Sonstige Schnittstellenplan
Alle
André
Nashida
Christian
Nashida
Shimal
Nashida
???
Keiner
20.08.2013
30.08.2013
20.08.2013
30.08.2013
20.08.2013
30.08.2013
???
4 Sonstiges
Diskussion & Ergebnisse:
- Offenlegung des Optimierungsansatzes am Dienstag, den 20.08.2013 bei dem Treffen von Georg
- Gemeinsamer Plan der Projektgruppe SCOWS
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 40
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten
Protokollführung:
Raphael
Abwesende: Nashida B.
Georg B.
Carsten B.
X Khisrav E
X Shimal I.
Raphaël F.K.
X Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion:
Ergebnisse:
Abgabetermin der Projektgruppe ist spätestens Ende September (digital, auf CD oder USB-Stick)
Abschlusspräsentation soll am 10.10.2013, 14:00 Uhr stattfinden. Wer nicht kann, kann sich per Skype/Hangouts
zuschalten.
Zu Svetlana bestand noch kein Kontakt, seit der Abreise
Shimal hat kurz mit Nashida per Skype Kontakt
Von Kishrav gibt es nichts Neues
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Dokumentation
Diskussion:
Ergebnisse:
„Geht stetig langsam voran“
Optimierungskonzepte werden eingepflegt
Das Simulationskonzept muss noch kurz abgestimmt werden
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Simulation
Diskussion:
Ergebnisse:

2
Schon fast fertig (bis auf kleinere Verbesserungen, die noch durchgeführt werden müssen)
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Optimierung
Diskussion:
Ergebnisse:
Stefan schätzt, dass die endgültige Optimierung erst in 3 Wochen fertig implementiert sein wird, eine erste
lauffähige Version frühestens nächste Woche
André wird bei der Heuristik-Bewertungsfunktion mithelfen
Christian wird ebenfalls der Optimierung insgesamt zugeordnet zur Unterstützung, nachdem er die
Simulationsverbesserungen durchgeführt hat
Der Startpunkt des Zeitfensters, das an die Optimierung übergeben wird, legt den Startzeitpunkt der Schiffe am
Hafen. Die Länge des Zeitfensters gibt an, wie lange die Schiffe maximal unterwegs sein dürfen.
Aufgaben: Verantwortliche: Deadline:
Alle Keiner 28.08.2013
5 Sonstiges
Diskussion:
Ergebnisse:
Bislang sind nur Jobs und OWEAs in der Datenbank vorhanden, Transportmittel fehlen noch
Eine JavaDoc Dokumentation von unserem Code wird erstellt. Daher soll jeder seinen Code mit JavaDoc
Kommentaren versehen.
Unsere Build-Nummer kann unter http://duemmer.informatik.uni-oldenburg.de:61380 eingesehen werden
Georg hat Jenkins eingerichtet, mit dem sich auch der Erfolg von JUnit-Tests visualisieren lässt. Zugang zum
Jenkins kann über http://duemmer.informatik.uni-oldenburg.de:61294 Benutzer: jenkins-user Passwort: test123
Georg stellt einen Nachtrag zu einer Graphik bzgl. einer Clusteroptimerung vor.
Christian fügt zur Vehicle-Klasse das Attribut „Verbrauch pro Stunde“ hinzu, die Geschwindigkeit der Schiffe im
Hafen und Bojen-Bereich wird dem Hafen-Objekt zugeordnet, die Geschwindigkeit im Windpark steht im Windpark
Objekt. Die Strecke von der letzten Boje zum Windpark (und zurück) wird mit 80% der maximalen Geschwindigkeit
zurückgelegt.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner

Protokoll Nr. 41
Mittwoch, 28.08.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten
Protokollführung:
Christian
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
– Raphaël wird dem Gruppentreffen am nächsten Mittwoch (04.09.2013) nicht beiwohnen
– Stefan wird dem Treffen am (11.09.2013) nicht beiwohnen
– André kann erst ab nächsten Mittwoch wieder am Projekt arbeiten (Datenbankpraktikum)
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Fortschritt der Gruppen
Diskussion & Ergebnisse:
Dokumentation:
– Arbeiten an den Konzepten fortgeführt
– Teilweise Probleme, da Konzepte unklar , bzw. nicht mehr aktuell sind
Optimierung 1 (André, Raphaël, Stefan):
– Auswahl der Schiffkombinationen wurde implementiert
– ''Clustering''-Verfahren wird bis Freitag umgesetzt
– Implementierung der Bewertung steht noch aus
Optimierung 2 (Georg, Shimal):
– Es wurde Verbesserungen an der Optimierung vorgenommen
Simulation:
– Funktion zur Bestimmung der wetterabhängigen Geschwindigkeit korrigiert
1

– einige TODOs in den Klassen abgearbeitet
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
3 Probleme
Diskussion & Ergebnisse:
– Einige Variablen sollen vom Nutzer bei bedarf neu gesetzt werden können:
– einzelne Werte (z.B.Strompreis, Geschwindigkeit auf dem offenen Meer,...)
– Daten aus der Datenbank (z.B. Charterkosten der Schiffe, Jobzeiten,...)
– Die Optimierung muss eine Fehlermeldung an den Client senden, wenn Jobs nicht komplett verplant werden
können
– Bevor die gesammelten Wetterdaten in die Datenbank geschrieben werden können, müssen die wichtigen Attribute
identifiziert werden.
– Temperatur
– Windstärke und -richtung
– Strömungsstärke und -richtung
– Wellenhöhe
– Regen und Luftfeuchtigkeit
– Bedeutung der Seetonnen nicht klar
– Schiffe Orientieren sich an grünen Tonnen beim Verlassen des Hafen und an den roten Tonnen bei der Anfahrt
an den Hafen
– Es fehlen noch Dialoge zum erstellen einer Windkraftanlage und eines Windparks
– Javadoc muss für viele Klassen erzeugt, bzw. angepasst werden
– Änderungen am Konzept soll umgehend an die Dokumentationsgruppe weitergeleitet werden, damit die
bestehenden Texte zeitnahe ausgebessert werden können
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 42
Mittwoch, 04.09.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Cristian Menne
Protokollführung:
André Wolter
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Agendapunkt 1
Diskussion & Ergebnisse: Begrüßung + Organisatorisches
- JavaDoc:
o Englische Kommentare
o Beschreibung
o Return-Wert
o Variablen (übergebene Attribute)
o Exceptions wenn nötig
- Offene Punkte Liste
- Optimierung Deadline am 07.09.2013 (Raphaël / Stefan)
- Optimierung Deadline am 11.09.2013 (Georg)
- GUI muss angepasst werden
Aufgaben: Verantwortliche: Deadline:
Alle sollten ihre Methoden/Klassen soweit
dokumentieren wie möglich
Alle Keiner 15.09.2013
2 Agendapunkt 2
Diskussion & Ergebnisse: Kurzberichte
- Dokumentation benötigt noch Konzept für das Clustering, angepasstes GUI-Konzept, Schnittstellenplan
- Optimierung:
o Bewertungsfunktion soweit fertig
o Clustering funktioniert geographisch korrekt
o Innerhalb der Cluster muss noch optimiert werden
o Estimator funktioniert noch nicht vollständig korrekt
o Bewertungsfunktion funktioniert
- Prozess der gesamten Optimierung inkl. GUI muss noch erstellt werden. Wie arbeiten die Schichten zusammen.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 42
Mittwoch, 04.09.13
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
3 Agendapunkt 3
Diskussion & Ergebnisse: Probleme
- Was macht man mit Jobs die länger dauern als ein Arbeitstag? Feld wird in der GUI auf 6h eingeschränkt
- Menü Stammdaten auf dem MainFrame hinzufügen:
o Teilweise Daten aus der app-config.xml im Projekt scows-jsc in einen Dialog überführen
o Neue Datei für die Parameter erstellen (z.B. init.xml)
- Priorität im Job bleibt int
- Kontrolle der Anwendung durch Nashida
- Aufräumen der Klassen (mit Reference) Cristian
- Dialog für den Aufruf der Optimierung aus der Scheduling View
Aufgaben: Verantwortliche: Deadline:
Dialog(e) erstellen (André Deadline Montag
09.09.13)
Alle
Keiner
4 Agendapunkt 4
Diskussion & Ergebnisse:
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 43
Mittwoch, 11.09.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
Georg Berendt
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
- Jan erscheint um 14:07
- Andre wird vom 30.09 bis 09.10. im Urlaub sein, ist allerdings per Mail erreichbar
- Raphael wird vom 03.10. bis 14.10. im Urlaub sein, vielleicht per Skype zugeschaltet
- Carsten wird vom 27.09. bis 29.09. an einem Lehrgang teilnehmen
- Ab heute ist die Anmeldung zur Projektgruppe im StudIP möglich!
- Die Abschlusspräsentation wird am Mittwoch, den 16.10.2013 (mit Prof. Sauer) um 15:00-16:00 stattfinden
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Status
Diskussion & Ergebnisse:
- Raphael & Stefan müssen noch die Integration der Optimierung (Stichwort Integrationstests) durchführen, danach
folgt eine Konzeptanpassung (kleinere Änderungen)
- Bisherige Tests durch Nashida und Christian schlugen fehl; Christian unterstützt Raphael
- Testmanagerin wird Nashida
- Georg & Shimal müssen noch die Vehikelverteilung implementieren, danach folgt eine Konzeptanpassung
- In der Dokumentation muss ein Absatz für die Webseite rein
- Christian behebt Bugs bei der RS-Optimierung
- Andre standardisiert bzw. vereinheitlicht die Dialoge; erstmal wurden die Create-Dialoge überarbeitet;
zwischendurch fotografiert & stichwortisiert er die verschiedenen Aspekte der GUI
- Laut Aussage von Jan liegt der Fokus auf dem Bericht, nicht z.B. auf einer Bedienungsanleitung
Aufgaben: Verantwortliche: Deadline:
Abschluss der Integrationstests
Abschluss des Algorithmus
Schnittstellenplan
Finale Abgabe an Jan
Alle Keiner
Raphael / Stefan
Shimal / Georg
Nashida
Carsten
17.09.
15.09.
20.09.
30.09.
1

Protokoll Nr. 43
Mittwoch, 11.09.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 15.30 – 17.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
3 Testen
Diskussion & Ergebnisse:
- Nashida hat ganz viele Fehler gefunden (liegt im Git)
- Andre hat einen Hafen und eine MasterData-Entität erstellt; vielleicht mit Swingworker den Abruf von
Datenbankdaten asynchron handhaben, damit der Benutzer nicht so lange auf den Dialog warten muss?
- Stefan wird nach dem Ende seiner kurzen Abwesenheit das Testen unterstützen
- Jenkins bietet eine Auswertung der Tests & der Code-Abdeckung und wird empfohlen, um insbesondere die
Optimierung hinreichend testen zu können
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Sonstiges
Diskussion & Ergebnisse:
- Carsten: Wie wird Gewinnausfall bewertet? Wenn ein Job einen gewissen Gewinnausfall hat, und einen Tag später
erst gewartet wird, dann müsste man die Summe des Vortages mit dem heutigen erst entstehenden Schaden
addieren; wir betrachten allerdings nur den zeitabhängigen Ausfall (also etwa € pro Stunde); Zeitpunkt des Ausfalls
beachten?
- Jan wird wohl die Interviewpartner zum Präsentationstermin einladen (Overspeed, BTC, Uni Bremen, …)
- Sitzung wurde beendet um 15:08
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2

Protokoll Nr. 44
Montag, 18.09.13
SCOWS
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
Carsten Buschmann
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Begrüßung/ Organisatorisches
Diskussion & Ergebnisse:
1. Testen vom 23.09.2013 bis 25.09.2013
2. Protokoll der letzten Wochen (11.09.2013) hochladen
3. Schnittstellenplan dringendst fertigstellen!
Aufgaben: Verantwortliche: Deadline:
1. Testen des Programms
2. Protokoll der letzten Sitzung hochladen
3. Schnittstellenplan
Alle Keiner
Nashida und Stefan
Georg/Nashida
Nashida
26.09.2013 10:00h
18.09.2013 23:59h
20.09.2013 23.59h
2 Kurzberichte/ Probleme und Schwierigkeiten
Diskussion & Ergebnisse:
1. Einheitliche Sprache in der Software verwenden: Englisch
2. Optimierung evaluieren untereinander (Raphaël/Stefan vs. Georg)
3. Konzepte anpassen/ Endprodukt detailliert beschreiben
4. Optimierung von Georg
5. GUI anpassen (insbesondere Scheduling), anstoßen der Optimierung (dann muss eine Ladebalken oder dergleichen
angezeigt werden), abbrechen und zurückkehren zum Startbildschirm, Buttons „Neues Vehicle“ und „Job hinzufügen“
entfernen, Zeitfenster-Dialog neugestalten/anpassen, updaten des Scheduling-Frames
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1. Textliche Umsetzung des Programms in Englisch
20.09.2013
1

Protokoll Nr. 44
Montag, 18.09.13
SCOWS
WÖCHENTLICHES TREFFEN
UHRZEIT: 14.00 – 15.30 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
2. Optimierung evaluieren
3. Endprodukt detailliert beschreiben
4. Optimierung in das Backend integrieren und in
die Map schreiben wie die Simulation es braucht
5. GUI anpassen/ Scheduling
Raphaël
Carsten
Georg
André
28.09.2013 23:59h
29.09.2013
22.09.2013 23.59h
22.09.2013 23.59h
2

Protokoll Nr. 45
Montag, 25.09.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 13:30 – 16:00 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
Moderation:
Carsten
Protokollführung:
Raphael
Abwesende:
Nashida B.
Georg B.
Carsten B.
X Khisrav E
X Shimal I.
Niemand
Raphaël F.K.
X Svetlana K.
Christian M.
André W.
Stefan W
1 Organisatorisches
Diskussion & Ergebnisse:
Mittwochssitzung wird beibehalten, für die nächsten drei Wochen
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Statusberichte & Probleme klären
Diskussion & Ergebnisse:
Christian: Handling der Karte verbessert, Zoomfunktion verbessert, Evaluationsview wird erstellt, auch Diagramme sollen
angezeigt werden können.
Raphael: Heuristik wurde getestet. Testabdeckung des Codes 90%. Für die Evaluation der Optimierung und die Vergleiche
der beiden Optimierungsansätze sind noch keine GUI vorhanden. Der JobScheduler ordnet die Jobs im Moment so an, dass
sie so schnell wie möglich ausgeführt werden.
André hat festgestellt: Optimierung wurde nicht korrekt erstellt -> Mann die Optimierungen noch nicht aus der GUI
aufrufen. Aufrufkette der Optimierungen muss geklärt werden!
Die Optimierungsvariante wird noch wählbar gemacht und nach einem Klick auf „Optimize“ werden Vehicle und Job-Listen
an den Server übermittelt. Progressbar kann angezeigt werden. Anschließend wird die MapView angezeigt.
Georg: Hat an seiner und Shimals Optimierung Tests durchgeführt.
Carsten: Ein Großteil des Schnittstellenplans wurde eingearbeitet. Svetlana hat angefangen Korrektur zu lesen. Anpassung
zum Optimierungskonzept wurden von Shimal eingereicht.
Stefan: Ist immer noch an der Testdokumentation.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

Protokoll Nr. 45
Montag, 25.09.2013
scows
WÖCHENTLICHES TREFFEN
UHRZEIT: 13:30 – 16:00 UHR
RAUM: A02 3-319
PG-SCOWS@UNI-OLDENBURG.DE
3 Tests
Diskussion & Ergebnisse:
Stefan: Ist noch an Testdokumentation (JUnit-Tests). Noch keine funktionierende GUI vorhanden, daher konnte noch kein
Systemtest durchgeführt werden.
Raphael: Heuristik wurde getestet. Testabdeckung des Codes der Heuristik > 90%
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
4 Dokumentation
Diskussion & Ergebnisse:
Produktbeschreibungen werden durchgeführt
Aufgaben: Verantwortliche: Deadline:
Heuristik
Programmoberfläche
Simulation
Stefan & Raphael
André
Christian
Sonntag Abend, 29.09.2013
5 Sonstiges
Diskussion & Ergebnisse:
PG Präsentation wird im nächsten Treffen besprochen.
Bewertung der PG: Wir werden uns nicht gegenseitig selbst bewerten. Noten werden von Prof. Sauer und Jan vergeben. Die
Bewertungszettel, die von uns ausgefüllt werden sollen, sind nicht Grundlage der Bewertung, sollen aber gröberen
Fehleinschätzungen vorbeugen.
Präsentation fließt nicht direkt in die Bewertung ein, jedoch spielt es schon eine Rolle, wie das Produkt am Ende aussieht.
(Also: Die Präsentation sollte unser Ergebnis ins richtige Licht rücken)
Aufgaben: Verantwortliche: Deadline:
2

Protokoll Nr. 46
Mittwoch, 02.10.13
cows
WÖCHENTLICHES TREFFEN
UHRZEIT: 13.00 – 14.30 UHR
RAUM: A02 3-319
PG-COWS@UNI-OLDENBURG.DE
Moderation:
Carsten Buschmann
Protokollführung:
Stefan Wunderlich
Abwesende:
Nashida B.
Georg B.
Carsten B.
Khisrav E
Shimal I.
Niemand
Raphaël F.K.
Svetlana K.
Christian M.
André W.
Stefan W
1 Orga
Diskussion & Ergebnisse:
Abstract wurde in Projektbericht eingefügt.
Firmen und Personen für Danksagung: Alexander Rott, Saskia Greiner, Overspeed, BTC, SystOp Projekt, Frisia, Heli
München.
Zum Vortrag:
40 min Folienpräse, 20 Min. Diskussion. Folien pptx. Vorwiegend Problemstellung und Ergebnisse präsentieren. Auch auf
Ablauf eingehen (Lessons Learned). Findet im Seminarraum von BE statt.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
2 Bugs
Diskussion & Ergebnisse:
SG-Algo liefert merkwürdige Ergebnisse. Georg kümmert sich darum.
Aufschlüsselung der Kosten unklar. Es wird nicht klar, wie sich Gesamtkosten zusammensetzen. Christian kümmert sich
darum. Charterkosten, Benzin, Lohnkosten, GA.
Weitere Aufgaben:
Code aufräumen, Evaluierung, Ausblick schreiben -> Stefan
André schreibt GUI-Beschreibung. Raphael macht seine Texte fertig. Georg bearbeitet en Fehler des SG-Algo. Carten
bearbeitet weiter Projektbericht. Nashida macht nen Folienmaster für Abschlusspräse.
Aufgaben: Verantwortliche: Deadline:
Alle
Keiner
1

A.2 Interviews mit den Experten A ANHANG
A.2 Interviews mit den Experten
Auf den folgenden Seiten sind inhaltlichen Zusammenfassung der Interviews.
262

Telefon-Interview mit Tomas Russy (Head of Operations Development), AREVA Wind
GmbH, 11.03.2013
Areva unterscheidet zwei Wartungstypen: Wartung und Entstörung. In den ersten fünf
Jahren ist üblicherweise der Hersteller für Wartung und Entstörung verantwortlich und stellt
alle Ressourcen und Service Teams. Der Betreiber ist in der Zeit hauptsächlich für
Überwachung und Genehmigungen zuständig und übernimmt nach den fünf Jahren Wartung
und Entstörung.
Wartung
Einmal im Jahr findet eine große Jahreswartung statt, meistens im Mai oder an
anderen Sommertagen. Dabei müssen Checklisten abgearbeitet werden. Die Checklisten
unterscheiden sich von Jahr zu Jahr, sodass eine Jahreswartung unterschiedlich lange dauert,
aber meistens zwischen 3-5 Tagen pro Anlage, in 12h-Schichten, ohne Nachtschicht. Dabei
werden u. a. Teile präventiv ausgetauscht, bevor ein Defekt auftritt. Während der
Jahreswartung arbeiten 9 Servicetechniker gleichzeitig auf einer Anlage:
3 Techniker im Turm
3 Techniker in der Gondel
3 Techniker in der Nabe
Entstörung
Eine Entstörung muss stattfinden, wenn eine OWEA stillsteht. Es müssen vertraglich
(zwischen Hersteller und Betreiber) festgelegte Verfügbarkeitsgarantien eingehalten und die
Stillstandszeit minimiert werden. Wenn eine Anlage nachts ausfällt, gilt die Nacht vertraglich
noch nicht als Stillstandszeit, da nachts keine Arbeiten ausgeführt werden dürfen.
Optimalerweise sollten solche Störfälle per Condition Monitoring vorausgesehen
werden. Dies ist aber nicht immer möglich.
Bei Alpha Ventus gibt es ein dreiköpfiges Entstör-Team, welches tagsüber „stand-by“
in einer Servicestation an Land auf Einsätze wartet. Die Entstörung ist sehr Helikopter-
Fokussiert (ca. 70% Helikoptereinsätze, 30% Bootseinsätze). Haupt-Entscheidungskriterium
sind Wellenhöhe (Boot kann nicht mehr an der Anlage andocken) und benötigte Einsatzteile
(die ggf. nur mit dem Schiff transportiert werden können).
Helikopter kommen üblicherweise bei kleinen Einsätzen (ca. 6 h) zum Einsatz. Bei
Wartungen, die lediglich 1 bis 2 h dauern, landet der Helikopter auf den Plattformen der
Umspannwerke, da ein Rückflug unwirtschaftlich wäre – auch wenn die Plattformen
eigentlich nur für Notfälle gedacht sind. Der Helikopter müsste sonst nach 30 Minuten an
Land wieder abheben. Schiffe kommen meistens für längere Einsätze (ca. 12 h) zum Einsatz.

Eine Windenergieanlage von Areva hat ca. 1300 Sensoren und 129 redundante
Komponenten. Wenn solche Teile ausfallen, aber die OWEA weiterläuft, finden keine
Entstörungen statt. Erst wenn die Anlage still steht fliegen die Service-Techniker hinaus.
Es müssen immer mindestens 3 Personen auf der Anlage sein. Wenn für einen kleinen
Einsatz aber nur ein bis zwei Personen notwendig sind, kann der restliche Teil des Service-
Teams ggf. Wartungen der großen Jahreswartung vorziehen (meistens besteht dafür ein
Spielraum von drei Monaten.) oder defekte redundante Teile ausbessern.
Pro Anlage und Jahr kann zurzeit mit 7-10 Entstörungen bei Anlagen 5 MW-Klasse
gerechnet werden. Es wird versucht, diese Zahl immer weiter zu drücken.
Die Dauer von Entstöreinsätzen kann man nicht immer richtig einschätzen, manchmal
dauern sie auch länger als einen Tag.
Bei Windparks mit 80 – 100 Anlagen, werden Serviceteams wahrscheinlich täglich
vor Ort sein müssen, wenn das Wetter es zulässt. – Dann machen Optimierungen Sinn. Beim
Windparks Alpha Ventus mit 6 Areva Anlagen ist der gleichzeitige Ausfall von mehreren
Anlagen sehr unwahrscheinlich, sodass eine Optimierung der Einsatzpläne nicht notwendig
ist.
Im Sommer können Einsätze 14-15 h dauern, im Winter 7-8 h – durch das Wetter sind
die Einsätze im Winter jedoch zusätzlich eingeschränkt.
Zoll: Es gibt vereinfachte Zollverfahren, so dass Ersatzteile, die auf einer bestimmten
Liste stehen, nicht gesondert beim Zoll angemeldet werden müssen und die Wartung nicht
verzögern.
Daten zu Stillstandszeiten etc. können nicht herausgegeben werden.
Bei weiteren Fragen können, wir gerne erneut Kontakt zu Herrn Russy aufbauen. Er
hat betont, dass Areva offen für solche Anfragen ist.

Telefonat mit Frisia, 07.05.2013
Reederei (Frisia) und Betriebsbüro (Alpha Ventus) sind vollständig disjunkt
- Rahmenvertrag zw. Reederei und Betriebsbüro
- Rahmenvertrag legt fest, wieviele Schiffe Betriebsbüro beansprucht
- Max. 24 Passagiere auf "Wartungsschiff" (Nur Arbeiter!)
- Tag-Charter für Schiffe (umfasst auch Versorgung von Arbeitern)
Reederei
- stellt Schiffe (365 Tage im Jahr)
- via Tag-Charter
- beinhaltet Schiff, Besatzung etc.
- beinhaltet nicht Benzin
- exakte Abrechnung des Benzinverbrauchs
- Kapitän holt vor Abfahrt Wetter
- Großes Problem: Wetter (Schnelle Vereisung der Häfen)
- Stammbesatzung muss beim Zoll bekannt sein
- 150-160 Schiffseinsätze pro Jahr im Durchschnitt
- Frisia ist nur gebucht für AV
Betriebsbüro
- Bestimmt Fahrgeschwindigkeit (in Abhängigkeit der Eile)
- Prüfung des Wetters (BB bestimmt, ob rausgefahren wird)
- Wettervorhersage wird eingekauft (Stormgeo Meteogroup [England])
- exakte Wettervorhersage alle 6 Stunden mit exakten Ortsangaben
- teuer
- liefert Liste der Mitfahrer vor der Abfahrt
- Mitfahrer brauchen Befähigungszeugnis
- "Hopping" (Schiff fährt von Anlage zu Anlage und lädt Arbeiter ab)
- Einsatzleiter der aller Maßnahmen bleibt an Bord
- Plant Fahrten

Interview mit Overspeed, 11.02.2013
• Overspeed sieht in unseren Anforderungen nur "Detailanforderungen"
• Es soll die Frage beantwortet werden, was genau bei unserem Produkt
rauskommen soll
• Es soll klar sein, was das Produkt machen soll USP (Unique Selling
Proposition)
• (Simulations-) Szenarien müssen definiert werden
• Abgrenzung von Wartungskonzept (z.B. Shore-Based) und dem Szenario-
Begriff (also der Welt der Simulation -- z.B. ein Nordsee-Windpark wie Riffgat)
• Welche High-Level-Anforderungen und Hauptszenarien wollen wir
unterstützen? Wartung ausgehend mit Schiffen, Hubschraubern, Wohninseln? Wir sollten uns
festlegen und bei den Details einschränken. Wie können weiterführende Szenarien darauf
aufbauen?
• Z. B. kann durch die Simulation erkennbar werden, wann sich ein Einsatz mit
dem Hubschrauber lohnt und wann mit dem Schiff
• Wir sollten mit wenigen Variablen arbeiten. Es sollte vieles „feststehen“. In
diesem Rahmen sollte ein Hauptszenario entwickelt werden, worauf alles aufbaut
d.h. der Benutzer gibt das Wartungskonzept vor, weil ansonsten die Optimierung
herausfinden muss, welches Konzept das Beste wäre (und das wäre zu aufwendig)
• Dinge, die variabel gehalten werden sollten, sollten erst nach dem Festlegen
eines Hauptszenarios ermittelt werden
• Ein Designproblem könnte auftreten, wenn wir die Optimierungskomponente
einerseits in-the-loop mit der Simulationskomponente verwenden wollen, andererseits die
Optimierungskomponente als optionalen "Aufsatz" für die Simulation entwerfen. Es soll
beantwortet werden, wie die Optimierung mit der Simulation verbunden ist, insbesondere was
das Ergebnis der Simulation ist und was deren Eingabe - Stichwort Einsatzplan- und
Wartungsplan-Verwirrung
• Die Simulation ist für Offshore-Betreiber interessant und kann für sie einen
Mehrwert darstellen. / Notiz: Oftmals übernehmen Hersteller der Anlagen auch die Wartung,
so dass auch diese Zielgruppe interessant wäre
• Offshore Betreiber interessieren sich nicht nur für das kurzfristige
Einsparpotential durch einen optimierten Einsatzplan, sondern auch, wie viele Ressourcen sie
über mehrere Jahre durch eine solche Einsatzplanoptimierung sparen können. Daran

anschließend könnte ermittelt werden, welches Wartungskonzept (siehe oben) am
kostengünstigsten ist
• Meilensteine und PM Verbesserung. Es sollte geklärt werden, wozu genau die
Experteninterviews dienen sollen. Notiz: Meilensteine symbolisieren unsere
Wasserfallplanung und deswegen seine Frage nach der eingesetzten Praktik! EIn Meilenstein
darf nicht wie bisher lediglich die Aufgabe benennen, sondern muss einen wirklichen
Fortschritt darstellen und auch terminiert (!) sein. -> Vorschlag: Gantt-Plan, um
Gleichzeitigkeit während Scrum darzustellen (bspw. die Wiederholung der Interviews bzw.
Befragungen)
• Während der Planung soll die Verfügbarkeit von Ressourcen (Person,
Plattformen, Schiffe, Transporter, Hubschrauber, etc.) berücksichtigt werden.
• Kurzzeitplanung ist für die Planung der Wartungsjobs
• Langzeitplanung für z.B. die Jahresplanung aus betriebswirtschaftlicher Sicht
Offshore Windfarmen
• Eine OWEA wird ca. alle 3-6 Monate gewartet. Im Jahr wird eine Anlage 3-4
Mal gewartet.
• Gewartet wird immer nach einer bestimmten Zeit. Es spielen keine weiteren
Faktoren eine Rolle. Keine Faktoren wie Umdrehung oder Windgeschwindigkeit spielen eine
Rolle (die mittlere Windgeschwindigkeit verändert sich weit vor der Küste kaum noch)
• Die Verfügbarkeit von OWEAs wird von Herstellern bei ca. 96% angegeben.
• Bzgl. der Zugangssysteme von Schiffen zu OWEAs gibt es Publikationen.
• Es gibt leider keine einheitliche Beschreibungsnorm für OWEAs. Es gibt
keinen Standard wie IEC 61850, sondern Herstellerabhängig
• Blitzschläge sowie Fertigungsfehler sind Hauptgründe für den Ausfall von
Rotorblättern
• Das BSH plant die OWEAs bei starken Vogelzügen für ein paar Tage im Jahr
abzuschalten
• Wartungspläne und Standard-Wartungszyklen können vom
Hersteller/Betreiber zur Verfügung gestellt werden.
• Einige regelmäßige Wartungsarbeiten sind:
• Inspektionen
• Fundamentprüfungsarbeiten
• Hydraulik
• Öl-Analyse

• Thermenschicht
• Sonstige Zustände werden überwacht und geprüft/gemessen
HSE Aspekte
• Für unterschiedliche Einsätze muss die Besatzung unterschiedliche Zertifikate
mitbringen. "Elektronik"-Zertifikate, Zertifikate für die Rettung bei Hubschraubereinsätzen
etc.
• Berufsgenossenschaften können Liste von Fertigkeiten und
Sicherheitschecklisten und -maßnahmen liefern. Es gibt insbesondere eine Niederlassung hier
in OL
• Vorschriften für das Wartungspersonal können bei BSH nachgefragt werden
bzw. auf deren Webseite gelesen werden.
• Auf einer WEA müssen mindestens drei Leute gleichzeitig arbeiten– nicht nur
zum Skatspielen
Infrastruktur und Logistik
• Die meisten Teile werden an der Küste (im Hafen) gelagert, um Ausfallzeiten
zu minimieren. Auch ein Rotorflügel-Satz. Trafos allerdings nicht, müssten neu gewickelt
werden. Große Installations-/Wartungsschiffe müssen dann aber noch gechartert werden
(Verzögerungen möglich).
• Schiffe werden für die Wartungsarbeiten lieber eingesetzt weil sie risikoärmer
sind als Hubschrauber, da diese in der Nordsee schwer notlanden können.
• Diese sind vor allem bei kurzen Wartungsarbeiten und langen Strecken schon
sehr schnell rentabel
• Ein Hubschrauber gewährleistet eine hohe Verfügbarkeit der
Windenergieanlagen
• Hubschrauber sind bei entfernten Anlagen jedoch vorteilhaft, weil die schneller
sind und der Einsatz weniger lange dauert. Außerdem ist die Besatzung bei der Ankunft
weniger erschöpft oder gelangweilt von der Reise bzw. seekrank. Daher sind
Wohnplattformen auch eine Alternative.
• Für die Wartungen soll ein Zentraler Hafen vorhanden sein. Der Betreiber
sucht sich einen Hafen, von dem aus er am besten mehrere Parks bedienen will - deshalb ist
die Wahl wichtig!
• Es sollen in der Simulation nur die Häfen berücksichtigt werden, die auch die
Bedingungen erfüllen.
• Bedingungen für fähige Häfen für Wartungsarbeiten sind z.B.

• Lagerfläche
• Unterkünfte
• Tiefgang für Schiffe
Wetterdaten
• Es gibt noch mehr Messpunkte in der Nordsee, die interessante Wetterdaten
liefern können.
• Wellen und Wind sind die größten Einflussfaktoren
Navigationsaspekte
• Verkehrsrichtlinien und Seerouten müssen berücksichtig und eingehalten
werden. Hierbei sollte man z.B. eine Schifffahrt Anmeldung bei BSH in berücksichtigen.
• Flüge dauern nicht sehr lange, aber die Vorlaufzeit (Anmeldung des Flugs und
andere Vorbereitungen) sollte nicht vernachlässigt werden (kann sogar länger dauern als der
Hubschrauberflug selbst).
• Ein Hubschrauber kann 96 % des Jahres fliegen und seine Belastungsgrenze
liegt bei einer Windgeschwindigkeit von 20 - 25 m/s
• Die Nutzung von Hubschraubern hängt nicht nur von der Windstärke, sondern
von dem Gesamtzustand des Wetters (Nebel, Bewölkung, Niederschlag) ab
• Die Nordsee „entwickelt“ sich, neue Offshore Windparks müssen umfahren
werden etc.
• Es steht noch nicht fest, ob die Offshore Windparks durch Sportboote oder
Fischereiboote befahren werden dürfen.
• Zur Zeit müssen Sportbote und Fischereiboote geduldet werden
Simulation
• Sensoren sollten nicht einzeln modelliert werden und an echte Condition
Monitoring-Werte werden wir höchstwahrscheinlich nicht kommen. Aber wir können abstrakt
berücksichtigen, wie lange ein potentielles Problem vorhergesehen werden kann, um dann
rechtzeitig eine Reparaturcrew zu schicken, bevor das Problem tatsächlich eintritt.
• Wichtig für die Simulation ist, dass wir wissen, wie lange Wartungsarbeiten
dauern.
• Die Simulation sollte in der Lage sein, auch Dinge (z.B. Störungen), die nicht
im Einsatzplan tauchen, zu erkennen/darzustellen. Oder zumindest sollte dieser Fall von uns
berücksichtigt werden.
• Was für unsere Simulation wichtig ist, sind folgende Punkte
• Dauer der Wartung

• Personalqualifikation
• Werkzeuge
Optimierung
• Zielkriterien bei der Optimierung
• Am wichtigsten sind HSE-Aspekte. Auf keinen Fall sollten Arbeiter eine Nacht
auf einer OWEA verbringen müssen.
• Kosten sind der zweitwichtigste Optimierungspunkt
• Zeit der drittwichtigste
• Je nachdem wer die Anlage wartet, können Wartungszyklen verschoben,
Wartungszeiträume gedehnt werden. Wenn der Betreiber die Wartung übernimmt, kann er
sich nicht viel Flexibilität bei der Einhaltung der Wartungszyklen leisten, denn wenn dann
Aufgrund mangelnder Wartung hohe Schäden entstehen, haftet der Hersteller nicht dafür. Ist
der Hersteller für die Wartung verantwortlich, können Wartungszeiträume etwas flexibler
sein, wenn der Hersteller das verantworten kann.

Projekt Systop (www.systop-wind.de)
Das Projekt beschäftigt sich mit Analyse und Optimierung von Wartungsprozessen,
z. B. wie Inspektionen und Wartungen verknüpft werden können, um Kosten zu sparen?
Kontakt: Masterstudentin Saskia Grainer (https://www.systop-wind.de/index.php?id=67) Sie
kann uns vielleicht weiterhelfen, wenn wir Fragen zu der Dauer der Wartungsprozesse haben.
Availon GmbH: Welche Statistiken stehen auch uns zur Verfügung? (Prof. Sauer
fragen)
Offshore Windparks
Technologiewahl beeinflusst Wartungskosten: Getriebelose OWEAs bestehen aus
weniger Bauteilen die ausfallen könnten, das Getriebe ist ausfallsicherer (behaupten die
Hersteller) als bei OWEAs mit Getriebe. Ein Getriebeausfall kommt selten vor, ein
Getriebeaustausch ist sehr teuer.
Das Problem mit den Daten: Allen, die sich mit O&M beschäftigen fehlen Daten zu
der Zuverlässigkeit von OWEAs und deren Komponenten. Doch selbst wenn wir an Daten
kämen, müssten wir sie auch richtig interpretieren können (zweite Hürde). Dazu wäre
Expertenwissen notwendig. Jede Windturbine hat ihre Eigenarten und man kann nicht so
einfach von den Ausfällen der einen Windturbine auf Schwächen einer anderen Turbine
schließen.
Wetterdaten
Wenn ein Schiff zum Bau oder zur Wartung zu den OWEAs hinausfährt, werden zwei
unabhängige Wettervorhersagen herangezogen.
Das Wetter kann unterschiedlich genau vorhergesagt werden, je nachdem wie stabil
die Wetterlage ist (von wenigen Tagen bis mehreren Wochen).
Optimierung
Nicht traditionelle Optimierungstechniken
Simulated annealing
Ant colony optimization
Genetical algorithms
Particle swarm optimization
Hauptmöglichkeiten um Kosten zu sparen sind
Transporte von Inspektionen („non corrective tasks“) und
Wartungsarbeiten („corrective tasks“) zusammen legen

Stillstandskosten minimieren, d.h. eine Turbine zur Inspektion/Wartung
möglichst dann abschalten, wenn kein Wind weht und sie sowieso nichts produzieren
würde.
Bei der Erstellung von Einsatzplänen gibt es häufig wenig Flexibilität bzw. wenig
Raum zur Optimierung, z. B.:
durch die Zertifikate, die die Mitarbeiter benötigen, steht schon fest,
welche Personen für die Einsätze benötigt werden
Durch Restriktionen sind die Wartungsschiffe an bestimmte Routen
gebunden.
Die Frage ob Hubschraube oder Boot gewählt werden soll stellt sich in
den meisten Fällen nicht, da es meistens schon feststeht. Z. B. wenn Taucher benötigt
werden, braucht man keinen Hubschrauber und wenn schwere Ersatzteile benötigt
werden, braucht man ein Schiff.

Telefoninterview mit der HTM in Emden, 12.06.2013
Grundsätzliche Daten:
Helikopter vom Typ EC 135
Maximale Anzahl Passagiere: 5 (bei AV, bei anderen sogar nur 4 da
manche Betreiber auf einen Co-Piloten bestehen)
Maximale Windgeschwindigkeit: 18m/s ca. 64 km/h (da die Mitarbeiter
noch gehoistet werden)
Anzahl Turbinen: 2 (Für See-Helikopter ist eine redundante
Motorisierung vorgeschrieben, genauso ist für See-Helikopter die Turbine
vorgeschrieben, kolbenbasierte Motoren können aufgrund des
Salzgehaltes nicht eingesetzt werden)
Verbrauch einer Turbine: 75 kg/h
Tankinhalt: 260 kg (Es wird nur soviel getankt, wie nötig)
Geschwindigkeit: ca. 220 km/h
Treibstoffart: "JetA1" ca. 2,20€ / Liter (inkl. 19% Steuer)
Ablauf eines Einsatztages:
Mitarbeiter versammeln sich zur evtl. Kurzschulung (90 Tage regel)
Mitarbeiter werden mit Werkzeug gewogen (Betankung des Helis
entsprechend)
Heli fliegt raus (ca. 30 min)
Heli liefert Werkzeug und Material erst auf Plattform ab um möglichst
wenig Gewicht zu haben (Sicherheit!)
Bringt dann die Mitarbeiter auf die Anlage
Kehrt zur Plattform zurück und holt das Werkzeug
Liefert das Werkzeug
Heli fliegt nach Hause und wartet auf Anruf der Mitarbeiter (Emden)
Ausbildung der Mitarbeiter
Mitarbeiter werden sowohl für das Hoisten als auch für die Sicherheit
durch das Heliunternehmen geschult.
Das Heliunternehmen überwacht die Einhaltung der Schulungsrythmen
Evtl. wird noch vor dem Abflug geschult (Video)

B
PFLICHTENHEFT
B Pflichtenheft
In diesem Kapitel sind die herausgearbeitet Vorgaben in Zusammenarbeit mit den Auftraggebern
aufgeführt.
B.1 Zielbestimmungen
B.1.1 Pflichtanforderungen
Für das Produkt unabdingbare Leistungen, die in jedem Fall erfüllt werden müssen
• Die Simulation eines Einsatzplans kann mittels einer Kartendarstellung dynamisch
visualisiert werden
• Es soll mindestens ein Hauptwartungszenario entwickelt/erstellt werden
• Das System soll die Wartung mit Schiffen und/oder Hubschraubern unterstützen
• Die Simulation soll von dem eingeplanten Wartungshafen gestartet und beendet
werden
• Es soll ein zentraler Hafen für den Einsatz geplant werden
• Ein Einsatzplan soll neben der Simulationsvisualisierung einsehbar sein
• Probleme, die im Laufe der Simulation eines Plans aufgedeckt werden, müssen für
den Nutzer einsehbar sein
• Probleme, die im Laufe der Simulation eines Plans aufgedeckt werden, müssen für
den Nutzer einsehbar sein
• Ein Einsatz soll simuliert werden können
• Die Optimierungskomponente soll einen Einsatzplan hinsichtlich eines Kriteriums
optimieren
• Die Ausgabe der Optimierung besteht aus einem optimierten Einsatzplan
• Zuvor erzeugte Modellobjektdateien müssen über eine Eingabeschnittstelle einlesbar
sein
• Ein vorliegender Plan muss vom System eingelesen werden können
• Daten, die sich nicht ändern, wie historische Wetterdaten oder Seerouten, sollen
persistent abgespeichert werden
• Erzeugte Einsatzpläne müssen vom System persistent gespeichert werden können
274

B.1 Zielbestimmungen B PFLICHTENHEFT
B.1.2 Optionale Anforderungen
Die Erfüllung ist nicht unbedingt notwendig, sollten nur angestrebt werden, falls noch
ausreichend Kapazitäten vorhanden sind
• Die Simulation wird mittels Parametern gesteuert, die über einer Eingabemaske
verändert werden können
• Die Optimierung wird mittels Parametern gesteuert, die über einer Eingabemaske
verändert werden können
• Bei der Simulation muss auf die Einhaltung von Seerouten und Verkehrsrichtlinien
geachtet werden
• Die Ablaufgeschwindigkeit einer visualisierten Simulation soll stufenweise wählbar
sein
• Vor der Simulation eines Plans kann der Nutzer Ereignisse, die den Planablauf
stören, definieren
• Die Anzahl der Optimierungsschritte, die verwendete Heuristik und das Zielkriterium
sollen vor der Optimierung wählbar sein
• Die Optimierungskomponente soll über eine Schnittstelle um weitere Heuristiken
erweiterbar sein
• Das System ermöglicht gemäß vorgegebener Objektklassen die manuelle Erzeugung
von Modellobjekten
• Das System muss die manuelle Erzeugung eines Einsatzplans unterstützen
• Einmal eingegebene Modellobjekte müssen vom Nutzer in einem geeigneten Format
abgespeichert werden können
• Modellobjekte enthalten die Koordinaten einer Analge, die Anzahl der Anlagen,
...
B.1.3 Abgrenzungskriterien
Diese Kriterien sollen bewusst nicht erreicht werden
• Das zu erstellende Tool ist keine Wettersimulation, sondern arbeitet auf extern
berechneten Vorhersagen und historischen Daten
• Das Tool dient lediglich der taktischen Planung (Zeitraum ein Tag) und soll nicht
zur Wartungsstrategiebestimmung eingesetzt werden (Zeitraum Wochen oder Monate)
275

B.1 Zielbestimmungen B PFLICHTENHEFT
• Die Konfiguration der Infrastruktur (Häfen, vorhandene Ressourcen, Fahrwasser)
wird als fest angenommen und soll nicht durch die Software optimiert werden
• Es handelt sich um eine Software die nicht On-Board zur Wegeplanung und Wartungsoptimierung
eingesetzt wird, sondern im Betriebsbüro zur Entscheidungsunterstüzung
für Vorgaben an die Operateure
276

B.2 Produkteinsatz B PFLICHTENHEFT
B.2 Produkteinsatz
B.2.1 Anwendungsbereiche
Das Simulationswerkzeug wird im Bereich von Offshore-Windparks Wartung bzw. deren
Planung und Optimierung eingesetzt. Es kann sowohl zur Unterstützung der Planung
eines Logistikkonzeptes als auch zur Überprüfung eines bereits geplanten Konzeptes
eingesetzt werden. Unter anderen werden folgende Bereiche berücksichtigt: regelmäßige
Inspektionen und Wartung von Fundamenten, Rotorblättern und Kabelanschlüssen sowie
auch Ersatzteil- und Personallogistik. In diesem Zusammenhang wird das Tool für
die Optimierung der bestehenden Wartungspläne bzw. als Entscheidungshilfe beim Vergleich
und Wahl von Service- und Wartungskonzepten für den Windpark verwendet. Im
allgemeinem soll das Tool das Hilfsmittel zur Bereitstellung von effizienter Wartung des
Offshore-Windparks werden. Das beinhaltet Personalverwaltung (Erstellung und Planung
der effizienten Arbeitspläne, Berücksichtigung von HSE Aspekten, Überprüfung
der fachlichen und sicherheitsrelevanten Qualifikationen der Einsatzkräfte), Fahrzeugenverwaltung
(Unterstützung bei der Wahl zwischen Schifffahrt und Helikopter-Transfers,
Berücksichtigung von Wetterbedingungen und Seerouten), Reparaturmanagement (regelmäßige
Inspektionen werden mit den benötigten Reparaturarbeiten vereinigt).
B.2.2 Zielgruppen
Die Zielgruppen sind Offshore-Windpark Betreiber, Entwickler, Hersteller bzw. die Unternehmen,
die in der Wartung von Offshore-Windparks tätig sind. Es können alle beteiligten
Akteure unterstützt werden, die sich in der Wartung der Offshore-Windparks
beschäftigen. Dazu zählen auch Logistikdienstleister, Energieversorger, Reedereien, Hafenbetreiber
usw.
Wissenschaftler und Forscher im Bereich von Offshore-Windenergie werden auch als
potentielle Zielgruppe angesehen für die weitere Entwicklung des Produkts oder Erfahrungsaustausch.
Das Tool ist für den Einsatz im operativen Betrieb im Leitstand (nicht On-Board
zur Wegeplanung und Wartungsoptimierung) der Offshore-Windparks (Betriebsbüros)
vorgesehen und der Entscheidungsunterstützung dient, was bedeutet dass damit lediglich
Empfehlungen gegeben werden, die dann von einem menschlichen Entscheider nochmals
geprüft werden sollen.
B.2.3 Betriebsbedingungen
• Betriebsdauer: täglich, 24 Stunden
• Wartungsfrei
• Die Sicherung der Datenbank
277

B.3 Produktumgebung B PFLICHTENHEFT
B.3 Produktumgebung
Das Produkt ist weitgehend unabhängig vom Betriebssystem, sofern folgende Produktumgebung
vorhanden ist.
B.3.1 Software
• Client
• Server
– Java Runtime Environment (JRE) 1.6
– Datenbank wie z.B. MySQL ab Version 5.5
– Java-Applikationsserver wie z.B. Apache Tomcat ab Version 7
B.3.2 Hardware
• Client
• Server
B.3.3 Orgware
– Internetfähiger Rechner (für aktuelles Kartenmaterial) / Netzwerkanschluss
(für reinen LAN-Betrieb innerhalb einer abgeschlossenen Organisation)
– ausreichend Rechen- und Festplattenkapazität für zahlreiche und tägliche Optimierungsdurchläufe
• Datenbank
• Produktschnittstellen
278

B.4 Produktfunktionen B PFLICHTENHEFT
B.4 Produktfunktionen
B.4.1 Simulation
• Das System soll die Abläufe eines Einsatzplans simulieren.
• Ein Hauptszenario sollte anpassbar sein.
• Das System soll während der Simulation den Einsatzplan anzeigen.
• Das System soll durch die Simulation die (kosten- und/oder zeit-) effizienteste
Fahrzeugalternative überprüfen können.
• Eine Simulation sollte einen Start- und Endpunkt (z.B. von und bis Zentralhafen)
haben.
• Die Simulation soll dynamisch sein.
• Die Simulation soll die Seerouten einhalten.
• Die Simulation soll alle wichtigen Verkehrsrichtlinien berücksichtigen.
• Die Simulation soll die Wetterlage berücksichtigen.
• Eine Simulation soll gestartet werden können.
• Eine Simulation soll unterbrochen werden können.
• Eine Simulation soll beendet werden können.
• Das System soll die gesamte Wartungszeit anzeigen.
• Das System soll die Zeit für einzelne Wartungsarbeiten anzeigen.
• Das System soll die Fahrzeit darstellen.
• Das System soll den Startpunkt darstellen.
• Das System soll die Wartungsroute darstellen.
• Das System soll die zur Wartung benötigten Ressourcen darstellen.
• Das System soll das Wartungsfahrzeug darstellen.
• Das System soll das Offshore-Windpark darstellen.
• Das System soll die einzelnen Energieanlagen eines Windparks darstellen.
• Das System soll die Wetterbedingungen darstellen.
• Das System soll Störungen darstellen können.
279

B.4 Produktfunktionen B PFLICHTENHEFT
B.4.2 Wartungsplan
• Das System soll mit einer menschlichen Interaktion eine Wartung planen können.
• Ein Wartungsplan basiert auf einem Szenario.
• Es muss ein Hauptszenario geben, das als Basis für alle weitere Szenarien gilt.
• Das System soll die Vorbereitungszeiten der Ressourcen für den Wartungsplan
berücksichtigen.
• Das System sollte das Vorhandensein der Ressourcen (Personal, Plattformen, Schiffe,
Transporter, Hubschrauber, etc.) und deren Kapazitäten berücksichtigen.
• Eine Wartungsplanung sollte mindestens zwei Wartungsfahrzeugtypen (z.B. Schiff,
Hubschrauber) unterscheiden.
• Das System sollte in der Lage sein, eine Wartung für eine bestimmte Zeit (1 Woche,
Monat, Jahr, etc.) planen können.
• Das System soll durch die Planung die (kosten- und/oder zeit-) effizienteste Fahrzeugalternative
für die Wartungsarbeit erkennen und vorschlagen können.
280

B.5 Benutzungsoberfläche B PFLICHTENHEFT
Abb. 100: Start
B.5 Benutzungsoberfläche
Die Benutzeroberfläche soll über eines intuitiv begreifbaren und benutzerfreundlichen
Interface verfügen. Der Einsatz beginnt mit der Wahl des Hauptkonzeptes bzw. Eingeben
von bekannten Variablen. Die Simulation wird über die Kartenansicht vorgestellt.
Als Ergebnis bekommt der Benutzer verbesserten Wartungsplan bzw. Empfehlungen
zur dessen Optimierung. Dazu soll ein Reporting- oder Analysefunktion bereitgestellt
werden. Die Analysefunktion stellt die Ergebnisse in der leicht verständlichen für den
Benutzer Form., z.B. als eine Reihe von messbaren Einflussgrößen (verspätete Transporte,
Ausfälle, Wetterbedingungen) oder Abweichungen von geplanten Wartungspläne (die
Verlängerung der zeitlichen Dauer oder die Notwendigkeit der zusätzlichen Ressourcen
wie Transport, Personal, Werkzeuge und Ersatzteile).
Folgend wird ein Mockup für die zu entwickelnde Software dargestellt.
281

B.5 Benutzungsoberfläche B PFLICHTENHEFT
Abb. 101: Einsatzplan
282

B.5 Benutzungsoberfläche B PFLICHTENHEFT
Abb. 102: Ereignis
283

B.5 Benutzungsoberfläche B PFLICHTENHEFT
Abb. 103: Simulation
284

B.5 Benutzungsoberfläche B PFLICHTENHEFT
Abb. 104: Optimierung
285

B.6 Qualitätszielbestimmungen B PFLICHTENHEFT
B.6 Qualitätszielbestimmungen
Robustheit
Zuverlässigkeit
Korrektheit
Benutzungsfreundlichkeit
Effizienz
Portierbarkeit
Kompatibilität
sehr wichtig wichtig weniger wichtig unwichtig
X
X
X
X
X
X
X
Definitionen müssen folgen...
286

B.7 Entwicklungsumgebung B PFLICHTENHEFT
B.7 Entwicklungsumgebung
B.7.1 Serverbetriebssystem
• FreeBSD 9.1-STABLE amd64
B.7.2 Webserver
• Apache Version 2.2.24 (Unix)
B.7.3 Projektmanagement
• Redmine Version 2.2-stable
• Ruby 1.9.2p290 x86 64
B.7.4 Website
• Joomla Version 3.0.2
• PHP 5.4.16
B.7.5 Datenbank
• MySQL Server Version 5.5.31
B.7.6 Serverapplikation SCOWS Backend“
”
• Apache Tomcat 7.0.35
• Java 1.6.0 32-b27 (OpenJDK) x64
287