PG Mate MAritime Test und Experimentierplattform

329 Pages·2017·3.15 MB·German

CarlvonOssietzkyUniversitätOldenburg
AbteilungSystemanalyseund-optimierung
OFFIS–InstitutfürInformatik
Projektgruppe – Maritime Test- und Experimentierplattform
Abschlussdokumentation
Teilnehmer: LucaGatterdam
AdrianJagusch
HendrikKahlen
SergejKidrowski
ThorbenKloppe
BerislawKock
PhilippMudra
MarkOtten
SebastianSchmidt
MaximilianWappler
TimWiechmann
Betreuer: Prof.Dr.-Ing.AxelHahn
Ing.MohamedAbdelaal
M.Sc.MariusBrinkmann
Dipl.-Ing.ArneStasch
M.Sc.PeterTank
Oldenburg,3.Oktober2017
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Projektvorgehen 4
2.1 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 InfrastrukturundWerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . 14
3 MaritimeGrundlagen 25
3.1 MaritimeStandards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 SchiffssensorenundNavigations-Assistenz-Systeme . . . . . . . . . . . 28
4 Projektumfeld 35
4.1 Organisatorisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 eMaritimeReferencePlatform . . . . . . . . . . . . . . . . . . . . . . . 36
5 Anforderungsanalyse 37
5.1 Stakeholderanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Anforderungserhebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6 Systementwurf 71
6.1 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 PolymorpheSchnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3 Verteilungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.4 Kontrollplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.5 Pfadplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.6 RTZ-Programmbibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.7 Regelungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.8 Notfallsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
I
Inhaltsverzeichnis
7 Umsetzung 131
7.1 NMEA2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7.2 PolymorpheSchnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3 Verteilungsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.4 Kontrollplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.5 Pfadplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.6 RTZ-Programmbibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.7 Regelungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.8 Notfallsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8 Test 188
8.1 Testprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.2 Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.3 Integrationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.4 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8.5 Akzeptanztest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9 Evaluation 206
9.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
9.2 Projektvorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
10 ZusammenfassungundAusblick 223
10.1 ZusammenfassungundZielerreichung . . . . . . . . . . . . . . . . . . . 223
10.2 AusblickundFazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
A Anhang 226
A.1 Handbücher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
A.2 TestdrehbuchTDB_001_Notfallsteuerung . . . . . . . . . . . . . . . . . 275
A.3 TestdrehbuchTDB_002_EPD_Shore . . . . . . . . . . . . . . . . . . . . 283
A.4 SensorenimTestbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
A.5 Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
A.6 NMEA2000XMLBeschreibung . . . . . . . . . . . . . . . . . . . . . . 296
A.7 KonfigurationsdateiderVerteilungsplattform . . . . . . . . . . . . . . . 297
A.8 EPDVesselConnectionConstants.java . . . . . . . . . . . . . . . . . . . 304
II
Inhaltsverzeichnis
Glossar 306
Abkürzungen 310
Abbildungen 312
Tabellen 315
Quellcode 317
Literatur 318
III
Abstract: Die vorliegende Abschlussdokumentation fasst die Ergebnisse der
Projektgruppe „MaritimeTest- undExperimentierplattform“ (kurz: PGMA-
TE) zusammen. Die PG MATE hat sich mit der Entwicklung und den Tests
einesganzheitlichenKonzeptsfüreinautonomfahrendesSchiffbeschäftigt.
Die entwickelte Plattform verfügt über eine komplexe Systemarchitektur mit
küsten- und schiffsseitigen Komponenten. Die Plattform wurde in eine vor-
handeneSystemarchitektureingebettet.Diesebestehtunteranderemausdem
Forschungsschiff Zuse und dem virtuellen Testbed LABSKAUS im Rahmen
der eMIR-Initiative. Das Produkt soll im Rahmen weiterer Forschungspro-
jekte im maritimen Bereich an der Universität Oldenburg und im OFFIS ge-
nutztwerden.DieEntwicklungunddieTestsfandenmitHilfedesForschungs-
schiffsZusestatt.DiePlattformwurdejedochsoentwickelt,dasssieübereine
Schnittstelle, über die Daten im NMEA2000-Standard ausgetauscht werden,
auchaufanderenSchiffeneingesetztwerdenkönnte.
GeplantwardieSchaffungeinesautonomfahrendenSchiffsindreiaufeinan-
der aufbauenden Schritten. Der erste Schritt befasst sich mit der Fernsteue-
rungeinesSchiffs.Diesewurdeerfolgreichumgesetzt.DerzweiteSchrittsah
das automatische Abfahren einer vorgegebenen Route durch das Schiff vor.
Dieserwurdeweitestgehendumgesetzt.DerdritteundletzteSchritthattedas
vollständig autonom fahrende Schiff zum Ziel, dass dynamisch auf diverse
Umwelteinflüsse, wie Hindernisse im Wasser oder andere Schiffe auf Kollisi-
onskurs,reagierenkann.DieserSchrittwurdenichtumgesetzt.
1.1 Motivation 1 Einleitung
1 Einleitung
DieEntwicklungautonomfahrenderAutosistschonweitvorangeschrittenundeinwichti-
gesThema,dasnichtnurdieAutomobilindustrie,sondernauchdieGesellschaftimAllge-
meinenbeschäftigt.MedialnichtganzsopräsentsindVersucheundFortschritteautonom
fahrender Schiffe. Aber auch in dieser Branche hat das Rennen um das erste kommer-
ziell einsetzbare Fahrzeug begonnen. Rolls-Royce rief zum Beispiel 2016 eine Initiative
namens „Advanced Autonomous Waterborne Applications“ (Aawa) ins Leben und testet
derzeitanderfinnischenKüsteKonzeptefürdasautonomeSchiff.
Die Projektgruppe „Maritime Test- und Experimentierplattform“ (kurz PG MATE)
soll sich mit der Schaffung eines Produkts beschäftigen, welches als Plattform für ver-
schiedene Forschungsprojekte im maritimen Bereich und insbesondere im Bereich des
autonomenFahrensgenutztwerdenkann.DiePGMATEreihtsichdabeiineineVielzahl
anderer Projektgruppen der Universität Oldenburg ein, die mit ähnlichen Projektaufga-
ben im maritimen Bereich beschäftigt waren. Ein Beispiel dafür sind die Projektgruppen
MOPSIbisIV.
1.1 Motivation
Die Interessen und Ziele für den Einsatz autonom fahrender Schiffe in der Schifffahrt
sind, wie autonom fahrende Autos im Straßenverkehr, vielfältig. Zu den Bedeutendsten
zählt die Erhöhung der Verkehrssicherheit und die damit verbundene Reduzierung der
Unfallzahlen. Durch eine effizientere Fahrweise und optimierte Routen entstehen zudem
ökologische und ökonomische Vorteile. Außerdem kann auf diese Weise die notwendige
Schiffsbesatzungverkleinertbzw.entlastetwerden.
DieUniversität Oldenburg arbeitetanverschiedenen Projekten immaritimenBereich
undhateinInteressedaran,diehiergewonnenenErkenntnissezuvertiefen.DiePGMA-
TEundihreMitgliedermöchtendurchdieProjektgruppenarbeitunteranderemdieArbeit
ineinergroßenArbeitsgruppeerlernenunddieKenntnisseinverschiedenenTechnologien
und Arbeitsweisen vertiefen. Eine detailliertere Analyse der Motivation der Projektgrup-
penmitgliederundweitererStakeholderwirdinAbschnitt5.1gegeben.
1
1.4 Zielsetzung 1 Einleitung
1.2 Einordnung
Die zu entwickelnde Plattform soll im Rahmen von Forschungstätigkeiten im Projekt
LABSKAUS verwendet werden, um unter anderem das Testen von Konzepten und Soft-
ware-Systemen im Projekt „eMaritime Integrated Reference Platform (eMIR)“ durch
die Nutzung eines physischen Forschungsboots zu unterstützen. Die Projektarbeit fin-
det in Zusammenarbeit mit Mitarbeitern der Abteilung „Systemanalyse und -optimie-
rung (SOA)“ des Departments für Informatik an der Carl von Ossietzky Universität Ol-
denburgunddesOFFIS,einemAn-InstitutderUniversitätOldenburg,statt.Diesebeiden
ForschungsstättenarbeitenzusammenanverschiedenenProjektenimmaritimenBereich.
DetailliertereInformationenzurEinordnungdesProjektsfindensichinAbschnitt4.
Bei möglichen zukünftigen Produkteinsätzen der Plattform ist die sogenannte Zivil-
klauselderGrundordnungderUniversitätOldenburginBezugaufdiereinnichtmilitäri-
scheNutzungzubeachten.
1.3 Problemstellung
Aus der Aufgabenstellung der Projektgruppenbetreuer und der zuvor beschriebenen Mo-
tivationergibtsichfolgendezentralewissenschaftlicheFragestellungderPGMATE:
„WiemusseinemaritimeTest-undExperimentierplattformaussehen,aufderimRah-
menderForschunganderUniversitätOldenburgunddemOFFISKonzepteundSysteme
zumautonomenFahrenvonSchiffengetestetundweiterentwickeltwerdenkönnen?“
1.4 Zielsetzung
AusderwissenschaftlichenFragestellung,denVorgabenderProjektgruppenbetreuerund
dem eigenen Anspruch der Projektgruppenmitglieder ergibt sich die Zielsetzung der PG
MATE:
– Es soll ein ganzheitliches Konzept für das autonom fahrende Schiff entwickelt und
getestetwerden.
– Das zu entwickelnde Produkt soll als Plattform entwickelt werden, welche wei-
testgehendunabhängigvomForschungsschiffZuseistundmitmöglichstgeringem
Aufwand auch auf andere Schiffe übertragen werden können soll. Dafür ist es not-
wendig,dasdiePGMATEsichbeiderEntwicklunganinderSchifffahrtverbreitete
StandardsundKonzeptehält.
2
1.4 Zielsetzung 1 Einleitung
– Bei der Entwicklungsarbeit soll darauf geachtet werden, drei von den Projektgrup-
penbetreuern vorgegebenen Entwicklungsstufen nacheinander abzuarbeiten. Diese
Entwicklungsstufensind:
1.FernsteuerungeinesSchiffs
2.DasautomatischeAbfahrenvonvorgebendenRouten
3.DasvollkommenautonomeFahrenunddynamischesReagierenaufUmwelt-
bedingungen
– Das zu entwickelnde Produkt soll aus einer küsten- und einer schiffsseitigen Platt-
formbestehen,diesichgegenseitigergänzen.
– DaszuentwickelndeProduktsollnurfürForschungszweckeeingesetztwerden.Die
SchaffungeinesverkaufsfähigenProduktssollnichtangestrebtwerden.Essolleine
Grundlage für weitere Forschungsarbeiten auf den beschriebenen Themengebieten
erarbeitetwerden.
– Das zu entwickelnde Produkt soll als Grundlage für weitere Forschungen im mari-
timenBereichgenutztwerdenundsollentsprechendindiebereitsvorhandenePro-
jekt-undSystemumgebungderUniversitätOldenburgunddesOFFISeingegliedert
werden. Dies kann zum Beispiel bereits vorhandene allgemeine Projektstrukturen,
GUI-KomponentenundRegelungssystemeumfassen.
– Das Ergebnis der PG MATE soll von anderen Projektgruppen im maritimen Be-
reich bzw. möglichen direkten Folgeprojektgruppen genutzt und weiterentwickelt
werden. Deshalb ist auf eine ordentliche Dokumentation der Entwicklung und Er-
gebnissezuachten.
– Das zu entwickelnde Produkt soll methodisch und umfangreich getestet werden,
umeinehoheSoftwarequalitätzuerhalten.
3
2.1 Organisation 2 Projektvorgehen
2 Projektvorgehen
In diesem Abschnitt soll kurz das allgemeine Projektvorgehen der PG MATE vorgestellt
werden.DiesumfasstdieBeschreibungdesVorgehensmodells,dieBeschreibungderPro-
jektplanungsowieeingesetzteMethodenundWerkzeuge.
2.1 Organisation
In diesem Kapitel werden die Struktur und die Elemente der Projektgruppenorganisation
vorgestellt und beschrieben. Dies umfasst die Beschreibung des Auswahlprozesses eines
Vorgehensmodells, die Beschreibung des gewählten Vorgehensmodells, die Vorstellung
des internen und externen Projektplans sowie die Beschreibung und Aufteilung fester
RolleninderProjektplanung.
2.1.1 Vorgehensmodell
Ein Vorgehensmodell soll im Allgemeinen den Projektverlauf in strukturierte Abläufe
einteilen. Den sich daraus ergebenden strukturierten Abschnitte werden entsprechende
MethodenundTechnikenzugeordnet.OhneeingeeignetesVorgehensmodelldrohenPro-
jekte oft zu scheitern. Mit einem Vorgehensmodell können verschiedene ähnlich aufge-
baute Projekte in der Softwareentwicklung umgesetzt werden (vgl. [BPK15], S. 3 f.). Im
FolgendenwirdkurzaufdieAnforderungenaneinVorgehensmodelldurchdiegegebenen
RahmenbedingungenfürdiePGMATEeingegangen.ImAnschlusswerdenverschiedene
Vorgehensmodelle aufgeführt und die Wahl eines dieser für die Projektgruppe begründe-
tet.DiesesVorgehensmodellwirdimAnschlussdetailliertervorgestellt.
ErmittlungeinespassendenVorgehensmodells
Die zentrale Anforderung an ein Vorgehensmodell für die PG MATE ist die Unterstüt-
zungderArbeitmiteinerGruppevonbiszu12Personen.ZudemmussdasgewählteVor-
gehensmodell über einen längeren Zeitraum von einem Jahr standhalten. Auch muss das
VorgehensmodellschnelleReaktionenineinemkomplexenSoftwaresystemermöglichen.
Dabeimussden,durchdenEinsatzimSchiffsverkehr,erhöhtensicherheitskritischenAn-
forderungenSorgegetragenwerden.NebendemklassischenWasserfallmodellähnlichen
VorgehensmodellensindinderPraxisagileMethodenweitverbreitet.
4
2.1 Organisation 2 Projektvorgehen
KlassischeModellesinddabeiinmehrerePhasenunterteilt,dieaufeinanderaufbauen
undnacheinanderineinerfestgelegtenReihenfolgeabgearbeitetwerdenmüssen.Wichtig
ist hierbei die konsequente Durchführung einer einzelnen vorher geplanten Phase. In ei-
nervorherigenPhasegetroffeneEntscheidungenkönnennurschwerrückgängiggemacht
werden. Der Vorteil klassischer Modelle liegt in der hohen Planungssicherheit durch die
strikte Einhaltung der einzelnen Phasen. Diese ist jedoch nur bei über den Projektverlauf
konstantenAnforderungengegeben.InderKonzeptionsphaseentstandeneFehlerkönnen
in klassischen Modellen nur schwierig behoben werden und zusätzliche oder veränderte
Anforderungennurschwerumgesetzt.
AgileVorgehensmodelleweiseneinenhöherenGradanFlexibilitätauf.Einbekanntes
und etabliertes agiles Vorgehensmodell ist das Scrum-Modell. Bei agilen Modellen wird
inderRegelkeinlangfristigerPlanbiszumEndedesProjektserstellt.Stattdessenwirdder
gesamteBearbeitungszeitrauminmehrereBearbeitungszykleneingeteilt,indenenjeweils
einer oder mehrere Themenbereiche bearbeitet, getestet und abgeschlossen werden. Im
AllgemeinendauerndieseBearbeitungszyklen(Sprints)zwischeneinerundvierWochen.
Auf diese Weise kann flexibler auf sich ändernde Anforderungen reagiert werden und
Fehler in der Konzeption können besser korrigiert werden. Allerdings geht dadurch die
PlanungssicherheitderklassischenModelleverloren(vgl.[Jak15],S.125-127und134).
GewähltesVorgehensmodell
Für die Organisation der Projektgruppe wurde ein modifiziertes Vorgehensmodell auf
Basis des V-Modells gewählt. Dabei wurde das V-Modell verschlankt und auf zentrale
Elemente reduziert. Zudem wird mit einer iterativen Vorgehensweise gearbeitet. In den
einzelnenIterationenwirdnachdemV-Modellentwickelt.
5