Im Hafen stehen Energie und Verkehrsfluss im Vordergrund, in der Flotte Zustand und Wartung.
Bei Infrastruktur- und Energiefragen: Landstrom, Netzlasten und Terminalauslastung.
Bei komplexen Energiesystemen und Zustandsprognosen.
Zu breiter Anspruch, unklare Verantwortung oder schwache Datenpflege.
Ein Digital Twin ist kein 3D-Modell. In der technischen Realität besteht er aus drei Schichten: dem physischen Asset mit seinen Sensoren und Datenquellen, dem digitalen Modell das physikalische oder statistische Zusammenhänge abbildet, und der Analyseschicht die Szenarien berechnet oder Abweichungen erkennt.
In der Hafenwelt fokussiert sich die Modellschicht typischerweise auf Energieflüsse. Ein Hafen-Twin kann die Netzlast in Abhängigkeit von Schiffsankünften, Landstromverbindungen und lokaler Erzeugung simulieren. Das ist operativ relevant, weil Hafenbetreiber damit Spitzenlasten vorhersagen und Investitionen in Transformatoren oder Speicher planen können. Die Datengrundlage umfasst AIS-Daten, Fahrpläne, Wetterdaten und Echtzeit-Messwerte aus dem Stromnetz.
In der Flottenwelt ist der Anwendungsfall anders gelagert. Hier geht es primär um den Zustand einzelner Systeme: Hauptmaschine, Hilfsdiesel, Turbolader, Separatoren. Ein Flotten-Twin verbindet Sensordaten (Temperaturen, Drücke, Vibrationen, Drehzahlen) mit einem Modell des erwarteten Verhaltens. Weicht das reale Verhalten signifikant ab, kann das auf einen sich entwickelnden Schaden hindeuten – etwa Fouling am Turbolader oder eine nachlassende Zylinderleistung.
Die technische Herausforderung liegt nicht im Modell selbst, sondern in der Datenverfügbarkeit und -qualität. Viele Bordsensoren liefern Daten in proprietären Formaten, die nicht ohne Weiteres in ein Twin-System integriert werden können. Die Bandbreite für die Datenübertragung ist begrenzt, und die Latenz beträgt oft Stunden statt Sekunden. Ein funktionierender Flotten-Twin muss mit diesen Einschränkungen arbeiten können – das unterscheidet ihn fundamental von Twins in der stationären Industrie.
Ein Digital Twin liefert Wert, wenn er eine konkrete operative Frage beantwortet. Im Hafen: Reicht die Landstromkapazität für die geplanten Anläufe nächste Woche? In der Flotte: Wie entwickelt sich der spezifische Kraftstoffverbrauch der Hauptmaschine über die letzten sechs Monate, und deutet der Trend auf Wartungsbedarf hin?
Keinen Wert liefert ein Twin, der als Visualisierung existiert, ohne dass jemand die Ergebnisse operativ nutzt. Das ist in der Praxis häufiger als man erwarten würde. In etlichen Pilotprojekten wurde ein aufwendiger Twin aufgebaut, die Ergebnisse aber nie in bestehende Entscheidungsprozesse integriert. Der Superintendent schaut weiterhin auf seine bewährten Parameter und ignoriert das Dashboard, weil er dem Modell nicht vertraut oder weil die Daten zu alt sind.
Ein weiterer kritischer Punkt ist die Wartung des Twin selbst. Modelle müssen kalibriert und aktualisiert werden, wenn sich das physische Asset verändert – nach einer Überholung, einem Retrofitting oder einem Wechsel des Brennstofftyps. Ohne diese Pflege driftet das Modell von der Realität ab und produziert Fehlalarme, die das Vertrauen der Nutzer zerstören.
Im Hafensektor sind Digital Twins weiter fortgeschritten als in der Flotte. Das hat praktische Gründe: Häfen sind stationäre Assets mit zuverlässiger Konnektivität und kontrollierbarer Sensorinfrastruktur. Größere europäische Häfen nutzen bereits Twins für die Energieplanung im Kontext der EU-Anforderungen an Landstromversorgung. Rotterdam, Hamburg und Antwerpen haben Pilotprojekte in unterschiedlichen Reifegraden.
Im Flottensegment ist die Situation heterogener. Große Tanker- und Containerreedereien mit homogenen Flotten und hohem Digitalisierungsgrad setzen Twins für Performance-Monitoring und Voyage-Optimierung ein. Kleinere Bulker-Betreiber hingegen kämpfen noch mit grundlegenden Datenqualitätsproblemen, die einen sinnvollen Twin unmöglich machen.
Die Lektion daraus ist klar: Ein Digital Twin ist kein Einstiegswerkzeug. Er setzt voraus, dass die darunter liegenden Daten- und Prozessschichten bereits funktionieren. Wer seine Running Hours nicht zuverlässig erfasst, braucht keinen Twin – sondern zunächst ein funktionierendes PMS.
Drei Fragen entscheiden darüber, ob ein Twin-Projekt sinnvoll ist: 1) Ist die Datenqualität für die relevanten Parameter ausreichend? Das heißt: werden Sensordaten zuverlässig erfasst, übertragen und gespeichert? 2) Gibt es einen konkreten operativen Use Case, der mit den vorhandenen Werkzeugen nicht ausreichend abgedeckt wird? 3) Ist ein operativer Eigentümer benannt, der das Twin-Projekt langfristig betreut?
Wenn auch nur eine dieser Fragen mit Nein beantwortet wird, sollte die Investition in einen Twin zurückgestellt und stattdessen in die Grundlagen investiert werden. Das ist keine Schwäche, sondern ingenieursmäßige Vernunft. Ein Twin auf schwachem Fundament ist teurere Datenvisualisierung – nicht mehr.
Unverbindliches Erstgespräch – wir analysieren Ihre Situation und finden den besten Weg.
Beratung anfragen