Dockentwässerung: ML-optimierte Pumpensequenz

Das echte Ausmaß des Problems

Die Dockentwässerung eines großen Trockendocks ist einer der sicherheitskritischsten Vorgänge im gesamten Schiffbau. Das Schiff schwimmt zunächst auf dem Dockspiegel, senkt sich dann mit fallendem Wasserstand, und muss am Ende zentimetergenau und lastgleichmäßig auf den Kielblöcken aufsetzen.

Was schiefgehen kann, ist gut dokumentiert:

• Ungleichmäßige Abstützung durch falsche Pumpsequenz erzeugt Biegemomente im Rumpf, die Spantschäden oder Risse im Außenhautblech verursachen, selbst bei unbeschädigten Kielblöcken
• Zu hohe Pumprate in kritischen Phasen führt dazu, dass das Schiff vor dem vollständigen Auffüllen der Hydrostatik „kippt”, es verliert seitliche Stabilität, bevor die Stützkonstruktion greift
• Fehler in der Ventilsequenz bei Pumpen mit hydraulischen Rückschlagventilen kann einen Druckstoß im Docksystem erzeugen, der Torbeschläge schädigt

Ein Totalschaden an einem Trockendock, Torpanzer, Drempelstruktur, Hebewerkzeuge, kostet je nach Größe 10 bis 50 Millionen Euro in Reparatur und Betriebsausfall (Schätzwerte aus Versicherungsanalysen der Schiffbauindustrie). Ein mittelgroßes Fährschiff mit Hüllenschaden an einer kritischen Spantzone: 2 bis 15 Millionen Euro, zuzüglich Ausfalltag des Schiffs im Off-Hire-Betrieb.

Das entscheidende Problem ist dabei nicht die Technik, sondern die Wissenskonzentration: Jede gut geführte Werft hat einen oder zwei Dockmeister mit dem nötigen Erfahrungsschatz. Dieser Schatz ist nicht dokumentiert, nicht übertragbar und nicht ausfallsicher. Krankheit, Ruhestand, Abwanderung zur Konkurrenz, und die Sicherheitsmarge liegt vollständig im Dunkeln.

Hinzu kommt ökonomischer Druck: Die Entwässerung eines großen Trockendocks dauert heute 8 bis 18 Stunden für große Schiffe, 3 bis 6 Stunden für kleinere Fahrzeuge (Werte basierend auf Xylem-Praxisdaten und Werftdokumentation). Jede Stunde gebundene Dockzeit kostet. An einer stark ausgelasteten Werft mit 20+ Dockungen pro Jahr summieren sich selbst moderate Optimierungen auf Millionenbeträge.

Mit vs. ohne KI, ein ehrlicher Vergleich

Die Zahlen zur Zeitersparnis stammen aus vergleichbaren Pump-Sequenz-Optimierungsprojekten im industriellen Umfeld; direkte Veröffentlichungen für Trockendocks mit ML sind noch selten, das Feld ist jung. Die Zahlen sind konservativ geschätzt.

Einschätzung auf einen Blick

Zeitersparnis, gering (2/5) Das System spart reale Dockliegezeit, 15 bis 25 Prozent weniger Entwässerungsdauer ist erreichbar. Das klingt nach viel, ist aber in Relation zur Gesamtliegezeit einer Dockung (typischerweise 14 bis 30 Tage) ein kleiner Hebel. Die Dockentwässerung ist sicherheitskritisch, aber nicht der dominierende Zeitfaktor im Dockzyklus. Im Vergleich zum Predictive Maintenance für Maschinenräume, wo Werkstattzeiten, Ladezeiten und Personalplanung direkt betroffen sind, ist die reine Zeitersparnis hier niedriger.

Kosteneinsparung, gering (2/5) Der primäre Nutzen ist Schadensvermeidung, nicht Kostensenkung im laufenden Betrieb. Die laufenden Betriebskosten des Systems (Hardware-Wartung, Modellupdates, Betrieb) sind nicht trivial. Verglichen mit Anwendungsfällen wie Bunkerverbrauchsoptimierung, die direkt den Kraftstoffverbrauch senken, ist die Kostenersparnis hier weniger direkt messbar und bilanziell schwerer darzustellen, selbst wenn der tatsächliche Schadensschutz viel höher ist.

Schnelle Umsetzung, sehr gering (1/5) Das ist die komplexeste Implementierung im gesamten Schiffbau-Portfolio. 12 bis 24 Monate realistischer Zeitplan, Zertifizierung durch Klassifikationsgesellschaft (DNV, BV, Germanischer Lloyd) obligatorisch für Safety-kritische Eingriffe in den Dockbetrieb, vollständige Sensorintegration, dock-spezifisches Modelltraining, Validierungsläufe. Kein Werft-IT-Team kann das alleine stemmen. Kein Out-of-the-Box-Produkt existiert dafür.

ROI-Sicherheit, sehr hoch (5/5) Das ist die überzeugendste Kennzahl: Ein einziger verhinderte Totalschaden amortisiert 20 bis 30 Systeminstallationen. Das Risiko-Nutzenverhältnis ist mathematisch eindeutig, kein anderer Anwendungsfall in dieser Kategorie hat eine vergleichbar klare Rechnung. Wenn das System nur einmal in zehn Jahren einen Dockschaden verhindert, ist es 50 Mal refinanziert.

Skalierbarkeit, gering (2/5) Das Modell, das für Dock A trainiert wurde, funktioniert nicht in Dock B. Jede Dockgeometrie, jeder Pumpensatz, jede Schleusenkonstruktion ergibt eine neue Datenbasis und ein neues Modell. Das ist kein Fehler der Methode, es ist die physikalische Realität. Werften mit mehreren Docks müssen pro Dock denselben Aufwand treiben.

Richtwerte, stark abhängig von Dockgröße, Pumpenkonfiguration und vorhandener Sensorinfrastruktur.

Was das System konkret macht

Die technische Architektur besteht aus drei Schichten, die alle gleichzeitig laufen müssen:

Schicht 1, Sensorik und Datenerfassung Wasserstandsgeber (typisch alle 2–5 Sekunden abgetastet) messen den Pegelstand an mehreren Punkten des Docks. Durchflussmesser an jeder Pumpe erfassen Volumenstrom und Pumpdruck. Neigungssensoren am Schiff selbst, Klinometer oder Inertialsensoren, liefern kontinuierlich den aktuellen Trimm und die Krängung. Lastmesszellen in ausgewählten Kielblöcken registrieren, wann und mit welcher Kraft das Schiff aufsetzt. Alle Daten fließen in einen zentralen Zeitreihenspeicher, typischerweise auf Basis von InfluxDB (on-premise) oder AVEVA PI System als industriellem Historian.

Schicht 2, Hydrostatik-Simulation und Optimierung Ein Machine-Learning-Modell kombiniert die Echtzeit-Sensordaten mit dem schiffsspezifischen Hydrostatikplan (Verdrängungskurve, KG, GM je Tiefgang). Auf dieser Basis berechnet es kontinuierlich: Welche Pumpraten und Ventilpositionen halten die Schiefstellung unter dem kritischen Grenzwert? Wo liegt der nächste kritische Stabilitätspunkt? Kann die aktuelle Phase beschleunigt werden, ohne Sicherheitsmargen zu unterschreiten?

Für die Optimierung haben sich zwei ML-Ansätze als relevant erwiesen: Modellbasierte Prädiktive Regelung (MPC) für vorhersehbare Phasen und Reinforcement Learning für die adaptive Feinsteuerung bei Abweichungen, etwa wenn eine Pumpe unplanmäßig in der Leistung abfällt oder das Schiff langsamer aufsetzt als simuliert.

Schicht 3, Dockmeister-Interface und Override Das System gibt dem Dockmeister Empfehlungen mit konkreten Handlungsanweisungen: „Pumpe 2 auf 60 % reduzieren, Ventil BB-3 öffnen.” In einem konfigurierbaren Grenzwertbereich führt das System die Sequenz autonom aus. Bei Überschreitung voreingestellter Stabilitätsparameter wechselt es in den Alarmmodus: alle Pumpen auf vordefinierten Haltepunkt, Dockmeister entscheidet. Der manuelle Override ist jederzeit aktiv, das System ist ein Unterstützungssystem, kein autonomes Steuerungssystem.

Das ist der entscheidende Unterschied zu industriellen Automatisierungslösungen aus anderen Branchen: Die Klassifikationsgesellschaft genehmigt keine vollautomatische Steuerung ohne menschliche Aufsicht bei sicherheitskritischen Vorgängen dieser Klasse.

Warum jedes Dock seine eigene KI braucht

Das ist keine technische Schwäche, es ist eine physikalische Tatsache, die jeder Werftenentscheider verstehen muss, bevor er über dieses System nachdenkt.

Ein Trockendock ist kein generisches Becken. Die Geometrie des Dockbodens, die Position der Pumpenschächte, die Strömungscharakteristik der Zisternenleitungen, der Abstand zwischen Toranlage und erstem Kielblock-Row, die Undichtigkeit des Tordichtungsprofils unter Last, all das ist pro Dock einzigartig. Das ML-Modell lernt diese Eigenheiten aus Betriebsdaten: Wie verhält sich der Wasserstand an Sensor A, wenn Pumpe 3 auf 80 Prozent läuft und das Torventil halb offen steht? Diese Frage lässt sich nur mit Daten aus diesem Dock beantworten.

Das Trockendock Elbe 17 bei Blohm+Voss in Hamburg ist 351 Meter lang und 59 Meter breit, mit drei Pumpen je 11.000 m³/h Kapazität. Dock II der Lloyd Werft in Bremerhaven hat andere Abmessungen, eine andere Pumpenanzahl, ein anderes Torkonzept. Das Modell, das in Hamburg nach 18 Monaten auf 40 Dockungen kalibriert wurde, kann in Bremerhaven bei der ersten Dockung zu einer komplett falschen Sequenzempfehlung führen.

Das bedeutet konkret: Wer drei Docks betreibt, braucht drei Modelle, drei Trainingsläufe, drei Validierungsphasen, drei Klassifikationsgesellschafts-Freigaben. Die Kosten und der Zeitaufwand skalieren linear, nicht etwa mit Rabatteffekten durch Vorerfahrung. Das erste Modell liefert viel Erfahrung, aber wenig übertragbaren Code.

Für große Werftkomplexe mit einheitlicher Dockarchitektur (gleicher Hersteller, gleiches Baujahr, gleiche Pumpenkonfiguration) gibt es Möglichkeiten zum Transfer Learning, also ein Basismodell mit dock-spezifischer Feinabstimmung. Das setzt allerdings voraus, dass die Grundstruktur wirklich vergleichbar ist, und das ist in der Praxis selten.

Was ihr hardware-seitig braucht

Das ist das Kapitel, das in keinem Angebotsgespräch mit Softwareanbietern angemessen behandelt wird, und das den tatsächlichen Projektaufwand oft verdoppelt.

Wasserstandsgeber, Mindestens vier Messpunkte pro Dock (Backbord-Mitte, Steuerbord-Mitte, jeweils Tor-nah und Heck-nah), besser sechs bis acht für größere Docks. Standard: hydrostatische Tauchsonden oder Ultraschallsensoren, Messintervall ≤ 5 Sekunden. Preis je Sensor: 800 bis 2.500 EUR, Installation und Kalibrierung extra.

Durchflussmesser an allen Pumpen, Magnetisch-induktive Durchflussmesser (MID) für jede aktive Hauptpumpe. Ohne diese Daten ist die Sequenzoptimierung blind. Nachrüstung in bestehende Rohrleitungssysteme ist aufwändig, typischerweise erfordert das ein Pumpenstillstand-Fenster von drei bis fünf Tagen.

Neigungssensoren am Schiff, Das Schiff bringt idealerweise selbst Inertialsensoren mit (AIS-Kopplung) oder temporäre Klinometer werden für die Dockung angebracht. Permanente Sensorinstallation ist nur bei Eigentümer-Rückkehrschiffen sinnvoll.

Lastmesszellen (optional, aber empfohlen), In fünf bis zehn ausgewählten Kielblöcken eingebaut, messen sie die tatsächliche Auflagerkraft beim Aufsetzen. Das liefert Validierungsdaten für das Modell und erlaubt eine genaue Stabilitätsaussage.

Gateway und Edge-Hardware, Alle Sensordaten müssen in Echtzeit in den Historiker fließen. Eine robuste Edge-Lösung (z.B. Siemens Industrial Edge) in einem schützenden Schaltschrank vor Ort ist unerlässlich. Dockhallen sind raue Umgebungen: Feuchtigkeit, Salznebel, mechanische Erschütterungen.

SCADA-Integration, Die bestehende Pumpensteuerung (häufig auf Basis von Siemens TIA Portal oder vergleichbaren SPS-Systemen) muss mit dem Optimierungssystem kommunizieren. Das erfordert entweder OPC-UA-Schnittstellen oder direkte SPS-Anbindung, und damit Eingriff in bestehende Sicherheitssteuerungen.

Gesamtinvestition Hardware (ohne Software): 200.000 bis 800.000 EUR je nach Zustand der bestehenden Infrastruktur und Dockgröße. Wer ein modernes Dock mit bereits vorhandenen Messstellen hat, ist am unteren Ende. Wer ein Dock aus den 1970ern nachrüstet: rechne mit dem oberen Ende plus 20 Prozent Puffer für bauliche Überraschungen.

Zulassung durch die Klassifikationsgesellschaft

Kein anderes Thema in diesem Anwendungsfall ist wichtiger, und keines wird häufiger unterschätzt.

Ein System, das die Pumpensequenz eines Trockendocks beeinflusst, greift in einen sicherheitskritischen Prozess ein. In der deutschen Schiffbauszene bedeutet das: Vor dem produktiven Betrieb braucht ihr eine Freigabe durch die zuständige Klassifikationsgesellschaft, DNV (Det Norske Veritas), Bureau Veritas oder Lloyd’s Register, je nach Werftbindung.

Was das konkret bedeutet:

Dokumentation vor der Inbetriebnahme, Das System muss in einer Sicherheitsanalyse (FMEA oder HAZOP) bewertet werden: Was passiert bei Sensorausfall? Was passiert bei Kommunikationsunterbrechung zwischen Edge-Hardware und Steuerung? Was passiert bei einem ML-Modell-Fehler? Alle Szenarien brauchen definierte Fallback-Verhalten.

Validierungsläufe unter Aufsicht, Typischerweise 10 bis 20 Dockungen unter paralleler Beobachtung: das ML-System läuft, der Dockmeister handelt nach bisheriger Praxis, Nachher-Vergleich findet statt. Erst wenn die Güte der Empfehlungen ausreichend dokumentiert ist, darf das System in den „Assistenzmodus” wechseln.

Softwareentwicklungsstandards, Je nach Risikoklassifizierung fordert die Gesellschaft möglicherweise IEC 61508-konforme Software-Entwicklung (funktionale Sicherheit). Das ist kein Hexenwerk, aber es bedeutet: mehr Dokumentation, mehr Tests, mehr Prüfzyklen im Entwicklungsprozess.

Laufende Überprüfung, Die Freigabe gilt nicht dauerhaft und unbedingt. Bei wesentlichen Änderungen (neuer Pumpensatz, andere Dockgeometrie durch Umbau, Wechsel der ML-Plattform) ist eine erneute Prüfung erforderlich.

Erfahrungswert aus vergleichbaren maritimen Safety-Systemen: Der Zulassungsprozess allein dauert 6 bis 12 Monate und kostet 50.000 bis 200.000 EUR in Beratungs- und Zertifizierungsgebühren. Das ist kein versteckter Kostenfaktor, es ist kalkulierbar. Aber es muss von Anfang an im Projektbudget stehen.

Konkrete Werkzeuge, was wann passt

Es gibt kein fertiges Produkt „ML-Pumpsequenz-Optimierung für Trockendocks”. Was es gibt: bewährte Industriekomponenten, die ihr zu einem werftspezifischen System zusammenbauen müsst.

Datenschicht, Zeitreihen und Historian

InfluxDB (Open Source, on-premise) ist die pragmatische Wahl für Werften, die Datensouveränität priorisieren und keine Serverraum-Infrastruktur für kommerzielle Historian-Lösungen haben. Die schreib-intensive Sensorlast (alle 2–5 Sekunden von 20–30 Messpunkten) ist für InfluxDB eine typische Anwendung. Self-Hosting auf einem lokalen Linux-Server, keine Lizenzkosten, gute Python-Integration. Einschränkung: kein deutscher Support, Skalierung auf Multi-Node erfordert eigenes Ops-Know-how.

AVEVA PI System ist der industrielle Standard für Werften, die bereits SCADA-Infrastruktur betreiben und ihren Historian in das bestehende IT/OT-Ökosystem integrieren müssen. PI bietet fertige Schnittstellen zu nahezu allen Leitsystemen und ist in regulierten Industrien klassifikationsgesellschaftlich gut etabliert. Kosten: fünf- bis sechsstellig pro Jahr je nach Tag-Volumen. Lohnt sich, wenn die Werft ohnehin plant, Anlagendaten zentral zu historisieren.

Steuerungsschicht, SPS-Integration

Siemens TIA Portal ist in deutschen Werften die dominierende SPS-Plattform. Die Integration des ML-Optimierungssystems über OPC-UA-Schnittstellen in eine bestehende TIA-Umgebung ist technisch gut dokumentiert, aber sie erfordert zwingend einen zertifizierten Siemens-Integrator und Eingriff in die Sicherheitssteuerung mit anschließender Validierung. Kein DIY-Projekt.

ML-Entwicklung und Modellbetrieb

Python mit scikit-learn, Stable-Baselines3 (für Reinforcement Learning) und dem Optimierungsframework GEKKO (für MPC-Implementierung) ist der de-facto-Standard für diesen Entwicklungsansatz. Kostenlos, hervorragend dokumentiert, große Community, aber ausschließlich für Teams mit ML-Engineering-Kompetenz. Kein Out-of-the-Box-Produkt für Werft-IT-Teams.

Azure Machine Learning kann sinnvoll sein, wenn die Werft bereits in die Azure-Cloud investiert hat und das Modelltraining auf GPU-Hardware extern skalieren will. EU-Rechenzentren (Frankfurt) sind verfügbar. Für den produktiven Echtzeitbetrieb wird das Modell typischerweise lokal auf Edge-Hardware eingesetzt, Azure ist dann der Trainingscluster, nicht die Produktionsumgebung.

Monitoring und Dashboard

Grafana (Open Source, on-premise) ist die pragmatische Wahl für das Echtzeit-Dashboard am Leitstand. InfluxDB-Integration ist nativ vorhanden, alarmbasierte Eskalation konfigurierbar, läuft auf Standard-Hardware. Der Dockmeister sieht: Wasserstand-Verlauf, Trimm, Pumprate, Grenzwert-Abstand, alles auf einem Bildschirm.

Zusammenfassung: Wann welcher Stack

• Werft mit existierender Siemens-SCADA-Infrastruktur → TIA Portal + PI System + Azure ML (Training) + Grafana (Dashboard)
• Werft ohne bestehende Historian-Infrastruktur → InfluxDB + Python + Grafana (günstiger Einstieg, mehr Eigenentwicklung)
• Beide Szenarien: Python für ML-Entwicklung, Grafana für Visualisierung

Datenschutz und Datenhaltung

Die gute Nachricht: Die Sensordaten des Trockendocks enthalten keine personenbezogenen Daten im Sinne der DSGVO. Wasserstand, Pumpraten, Trimmwerte, Kielblock-Auflagerkräfte, das sind Maschinendaten. Ein Auftragsverarbeitungsvertrag (AVV) ist nicht zwingend erforderlich, solange keine personenbezogenen Daten wie Dockmeister-Logbücher oder Schichtpläne in das System einfließen.

Dennoch gibt es relevante Datenschutzfragen:

Betriebsgeheimnis und Schiffsdaten, Die Hydrostatik-Pläne, Gewichtsverteilungen und Stabilitätsparameter der Schiffe, die das Dock durchlaufen, sind oft vertraulich. Sie dürfen nicht an Cloud-Dienste übermittelt werden, ohne dass der Schiffseigentümer zugestimmt hat. Das ist ein gewichtiges Argument für lokale Einführung aller Systemkomponenten auf der Werft.

Kritische Infrastruktur, Werften mit militärischen Aufträgen oder Arbeit an Schiffen der Bundeswehr unterliegen zusätzlichen Sicherheitsanforderungen (VSA, Geheimschutz). Ein Cloud-basiertes System scheidet in diesen Szenarien komplett aus.

Datenhosting-Empfehlung: On-premise auf der Werft, idealerweise in einem abgeschlossenen OT-Netzwerk (Air-Gap gegenüber dem Unternehmens-IT-Netz). Verbindungen zum Internet nur für Modellupdates und Monitoring, und ausschließlich über ausgehende, nicht eingehende Verbindungen.

Was es kostet, realistisch gerechnet

Investition (einmalig)

Das ist keine Schaufenster-Zahl, es ist die realistische Bandbreite für ein erstes Dock-System bei einer mittelgroßen deutschen Werft. Das zweite Dock (gleiches Konzept, neue Kalibrierung) kostet typischerweise 40 bis 60 Prozent weniger, weil Entwicklungskosten wegfallen.

Laufende Kosten (jährlich)

• Hardware-Wartung und Sensorwechsel: 15.000–40.000 EUR
• Modell-Retraining und Qualitätssicherung: 20.000–60.000 EUR
• Softwarewartung und Sicherheitsupdates: 10.000–30.000 EUR
• Gesamt laufend: ca. 45.000–130.000 EUR/Jahr

Gegenrechnung, wann rechnet sich das?

Ein einziger verhinderter Dockschaden der mittleren Kategorie (Spantschäden an einem Fährschiff): 2 bis 8 Millionen EUR in Reparatur, Reederei-Schadensersatz und Reputationskosten. Selbst bei der teuersten Systeminstallation: Einmaliger Schaden = Mehrfaches der Gesamtinvestition.

Die rechnerisch konservativere Perspektive: 20 Dockungen pro Jahr, Zeitersparnis 2 Stunden pro Dockung, Dockauslastungswert 3.000 EUR/Stunde (Mietäquivalent). Ergibt: 120.000 EUR/Jahr Mehrertrag durch höhere Dockverfügbarkeit, das deckt die laufenden Kosten und amortisiert bei einem günstigen System in 5–8 Jahren.

Die ROI-Logik ist für diese Investition ungewöhnlich klar: Wer ein Dock betreibt und einen einzigen schweren Schaden verhindert, hat das System 3 bis 10 Mal refinanziert.

Drei typische Einstiegsfehler

1. Mit der Software anfangen, ohne die Sensor-Grundlage zu haben. Das ist der häufigste Fehler, und er kostet im besten Fall sechs Monate, im schlechtesten das gesamte Projekt. Ein ML-Modell für Pumpensequenz-Optimierung braucht als erstes eines: saubere, vollständige, synchronisierte Sensordaten über mindestens 20 bis 40 Dockungszyklen. Wer noch keine Wasserstandsgeber, keine Durchflussmessungen, keine Trimmdaten hat, fängt nicht mit dem ML an. Er fängt mit der Sensorik an. Das dauert 6 bis 12 Monate, und das ist der Wert, nicht das Problem.

2. Die Klassifikationsgesellschaft als letzten Schritt behandeln. Typischerweise wird die Zulassung erst nach der Entwicklung gedacht: „Wenn das System fertig ist, holen wir die Genehmigung.” Das ist ein sicheres Rezept für zwei Runden von Nachentwicklungen und 6 bis 12 Monate Verzögerung. DNV und Bureau Veritas haben Anforderungen an die Dokumentation, die Sicherheitsarchitektur und die Testprotokolle, Anforderungen, die die Systemarchitektur von Anfang an prägen sollten. Das Gespräch mit der Klassifikationsgesellschaft gehört in den ersten Monat, nicht in den letzten.

3. Das Modell nach dem Go-Live nicht weiter betreuen. Dieser Fehler passiert leise und mit Zeitverzögerung. Das System wird eingeführt, die ersten Dockungen laufen gut, der externe Dienstleister schließt das Projekt ab. Ein Jahr später hat die Werft zwei neue Pumpen eingebaut, der Torflügel wurde saniert, die Dichtprofile wurden gewechselt, das Dock verhält sich physikalisch anders. Das Modell weiß davon nichts. Es gibt weiterhin Empfehlungen, die auf einer Realität basieren, die nicht mehr existiert. Ein Retraining-Prozess muss vor dem Go-Live definiert sein: wer ist verantwortlich, was löst einen Retrainingzyklus aus, wer validiert das neue Modell?

Was mit der Einführung wirklich passiert, und was nicht

Die größte Widerstands-Dynamik bei diesem System ist subtiler als bei anderen Digitalisierungsvorhaben: Der Dockmeister wird das System nicht ablehnen, weil er keinen Sinn darin sieht. Er wird es ablehnen, weil es sein Wissen infrage stellt.

Ein erfahrener Dockmeister mit 20 Jahren Praxis hat gelernt, in welchem Moment er die Pumpen drosseln muss. Dieses Wissen ist sicher, bewährt, und es trägt seinen Namen. Ein System, das eine andere Sequenz empfiehlt, stellt nicht nur seine Methode infrage, es stellt implizit seine Expertise infrage. Auch wenn das nicht die Absicht ist, so ist es oft die Wirkung.

Was in der Praxis hilft:

• Das System früh als Lernwerkzeug einführen, nicht als Korrekturinstrument. In der Validierungsphase läuft es parallel, der Dockmeister handelt wie immer, das System protokolliert und vergleicht. Nach 10 Dockungen ist das Gespräch über Unterschiede ein fachlicher Dialog auf Augenhöhe, kein Kontrollgespräch.
• Den Dockmeister in die Modellvalidierung einbinden. Wer die Kriterien mit definiert hat, nach denen das Modell beurteilt wird, verteidigt das Modell, statt es zu umgehen.
• Transparent kommunizieren: Das Override bleibt. Das System gibt nie eine Empfehlung, die der Dockmeister nicht übersteuern kann. Die finale Entscheidungshoheit liegt immer beim Menschen. Das muss nicht nur im System verankert sein, es muss auch gelebt werden.

Ein Widerstandsmuster, das bei diesem System nicht vorkommt, aber oft erwartet wird: Angst vor Jobverlust. Erfahrene Dockmeister sind nicht ersetzbar. Das System macht keine Dockmeister überflüssig, es macht sie unabhängiger von Bedingungen (Nachtschicht, Zeitdruck, körperliche Erschöpfung), die Entscheidungsqualität beeinflussen.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

„Wir haben das immer ohne System gemacht. Warum jetzt?” Die Antwort ist ehrlich und unangenehm: Weil die Fachkräfte, die das konnten, nicht ewig verfügbar sind. Jeder erfahrene Dockmeister, der in Rente geht, nimmt sein implizites Wissen mit. Das System macht dieses Wissen explizit, nicht um Menschen zu ersetzen, sondern um Kompetenz zu konservieren. Das ist eine Investition in die Zukunftsfähigkeit der Werft, keine Kritik an der Vergangenheit.

„Das kann man doch nicht zertifizieren, KI im sicherheitskritischen Bereich.” Doch, man kann. DNV hat seit 2021 Recommended Practices für KI in maritimen Systemen veröffentlicht (DNV-RP-0601 und Folgeversionen). ABS und Bureau Veritas haben ähnliche Frameworks. Der Weg ist klar, wenn auch aufwändig. Entscheidend: Das System muss als Unterstützungssystem mit permanentem Human-Override klassifiziert sein, nicht als autonomes Steuerungssystem. Diese Unterscheidung vereinfacht die Zertifizierung erheblich.

„Die Anschaffungskosten sind zu hoch.” Der Vergleich ist falsch formuliert. Die Frage ist nicht: „Können wir uns 800.000 EUR leisten?” Die Frage ist: „Können wir uns einen Dockschaden von 5 bis 15 Millionen EUR leisten?” Für Werften, die mehr als 10 Dockungen pro Jahr durchführen, ist das kein Budget-Argument, es ist ein Risikomanagement-Argument. Versicherungsgesellschaften erkennen das zunehmend an: Zertifizierte digitale Überwachungssysteme können die Versicherungsprämie für Dockhaftpflicht messbar senken.

Woran du merkst, dass das zu dir passt

Das System passt, wenn:

• Deine Werft betreibt mindestens ein Trockendock mit mehr als 10 Dockungen pro Jahr, darunter ist das ROI-Fenster zu eng
• Du hast bereits eine SCADA-Grundstruktur im Dock, auch wenn sie nicht modernisiert ist, vorhandene Messpunkte reduzieren den Sensorinstallationsaufwand erheblich
• Du betreibst Schiffe eines wiederkehrenden Typs oder Reederei, Hydrostatikpläne, die im System bereits hinterlegt sind, beschleunigen das Modelltraining
• Die Werft hat oder plant ein dediziertes OT-IT-Team, das langfristig für den Systembetrieb verantwortlich ist

Drei harte Ausschlusskriterien:

1. Unter 8 bis 10 Dockoperationen pro Jahr, der Aufwand für 12 bis 24 Monate Implementierung, Zertifizierung und Betrieb rechnet sich schlicht nicht. Die Amortisation würde 15 bis 25 Jahre dauern. Kleinere Werften profitieren mehr von verbesserten SOPs und strukturierten Einarbeitungsprogrammen für Dockmeister als von einem ML-System.

2. Keine bestehende digitale Sensorinfrastruktur im Dock, wenn ihr von null anfangt (keine Wasserstandsgeber, keine Durchflussmessung, keine digitale Pumpensteuerung), verdoppelt sich der Projektaufwand. In diesem Fall: erst die Sensorinfrastruktur als eigenständiges Projekt implementieren, validieren, betreiben. Dann in drei bis fünf Jahren das ML-System darauf aufbauen. Beide Schritte gleichzeitig sind organisatorisch und budgetär überfordernd.

3. Kein Zugang zu einem ML-Engineering-Team, es gibt kein Standardprodukt für diesen Anwendungsfall. Wer kein internes Team hat und keinen spezialisierten maritimen OT-Systemintegrator mandatieren kann, produziert mit diesem Vorhaben ein wertloses Pilot-Projekt. Der Systemintegrator muss Erfahrung in OT-Security, SPS-Integration und ML-Systemeinführung gleichzeitig mitbringen. Diese Kombination ist selten und teuer.

Das kannst du heute noch tun

Der sinnvollste erste Schritt ist kein Software-Kauf, es ist eine Bestandsaufnahme.

Erstelle eine Karte aller vorhandenen Messpunkte in deinem Trockendock: Wo habt ihr bereits Wasserstandsgeber? Wo bereits Durchflussmessung? Welche Daten werden bereits digital erfasst, und in welchem Format? Diese Karte zeigt dir, wie weit ihr vom Mindest-Daten-Fundament entfernt seid, und ob ein System dieser Art in einem Drei-Jahres-Horizont realistisch ist oder nicht.

Wenn die Antwort positiv ausfällt, ist der zweite Schritt das Gespräch mit DNV oder Bureau Veritas über die Grundanforderungen für ein Assistenzsystem dieser Kategorie in eurer spezifischen Dockklasse. Dieses Gespräch kostet nichts außer Vorbereitung, und es zeigt euch den Zertifizierungspfad, bevor ihr einen Cent in Entwicklung investiert.

Für ein erstes Verständnis der Systemarchitektur hilft dieser strukturierte Überblick:

Quellen & Methodik

• ML für Ballastpumpen-Predictive-Maintenance: Reddy et al. (2020), „Predictive maintenance for ballast pumps on ship repair yards via machine learning”, Transportation Engineering, Elsevier. Die Studie nutzt MATLAB-basiertes ML zur Analyse von Betriebsparametern von Docksystemen, methodisch verwandt mit dem hier beschriebenen Ansatz für Pumpensequenz-Optimierung. (DOI: 10.1016/j.treng.2020.100020)
• Suomenlinna-Werft Fallstudie: Xylem/Flygt, „Finland’s oldest and still operational shipyard gets high-tech pumping solution” (xylem.com/making-waves). Konkretes Beispiel für Flygt N3171-Pumpen mit SmartRun Variable Frequency Drives und Drucksensoren im Trockendock-Betrieb, ein Hinweis auf den Stand der Pumpentechnologie in kleinen bis mittelgroßen Werften.
• Dewatering-Zeitwerte: Erfahrungswerte aus Xylem Dry Dock Drainage Solutions (xylem.com) und SFLC Standard Specification 8634 (U.S. Coast Guard, 2018) für Pumpenkapazitäten und Entwässerungsdauer nach Schiffsgröße.
• Dry-Dock Schaden- und Off-Hire-Kosten: ShipFinex, „Maintenance & Dry-Docking: How Downtime Affects Operations” (shipfinex.com/blog) und marineinsight.com, „How Cost Estimation is done for Ship’s Dry Dock?”, Orientierungswerte für typische Kostenrahmen je Dockungsklasse.
• DNV AI in Safety-Critical Maritime Systems: DNV, „Artificial Intelligence in safety-critical industries” (dnv.com), Grundlage für Einschätzung des Zertifizierungspfads; DNV-RP-0601 als Referenz für Recommended Practices zu KI in maritimen Systemen.
• Blohm+Voss Trockendock Elbe 17: Wikipedia-Artikel „Trockendock Elbe 17”, Primärquelle für Dockgeometrie (351 × 59 m, 3 Pumpen à 11.000 m³/h) als Referenz für die Größenklasse.
• RL für Pump Scheduling: Kurniawan et al. (2023), „Real-Time Scheduling of Pumps in Water Distribution Systems Based on Exploration-Enhanced Deep Reinforcement Learning”, MDPI Systems, Methodischer Hintergrund für den RL-Ansatz in Pumpensystemen; nicht direkt Trockendock, aber auf den Anwendungsfall übertragbare Grundlage.
• Kostenschätzwerte: Eigene Schätzwerte auf Basis von OT-Integrationsprojekten mit vergleichbarer Sensor-/SCADA-Komplexität und öffentlich verfügbaren Projektbeschreibungen aus dem maritimen Umfeld. Keine Primärerhebung, Pufferzuschlag von 20% empfohlen.

Du willst wissen, ob sich dieses System für dein spezifisches Dock und eure Dockungsfrequenz rechnet? Meld dich, wir klären das gemeinsam in einem kurzen Gespräch, ohne Verkaufsgespräch.