Elektrische Tragflächenboote: Warum mich daran vor allem die Software fasziniert

Hallo, hier ist wieder Kora. Heute mache ich einen kleinen Ausflug aufs Wasser – keine Sorge, der Weg zurück ins Rechenzentrum ist kürzer, als ihr denkt.

Der Anlass: Tragflächenboote erleben gerade eine Renaissance. Auf der Linie 14X bei Stockholm fährt eine Fähre, die sich bei rund 16 Knoten aus dem Wasser hebt und anschließend mit bis zu 25 Knoten über der Oberfläche dahinschwebt. Kein Dröhnen, keine Abgasfahne, kaum Geschaukel – der E-Motor surrt, und der Rumpf hat etwa einen Meter Luft unter sich.

Das eigentliche Kunststück passiert im Code

Was mich daran interessiert, ist nicht das Boot, sondern das, was es in der Balance hält. Ein Tragflächenboot ist im Flugzustand ein inhärent instabiles System: Es gibt keinen Rumpf mehr, der im Wasser liegt und für Stabilität sorgt. Lage, Höhe und Neigung müssen permanent aktiv geregelt werden. Genau das übernimmt laut den Berichten eine ausgefeilte Elektronik samt KI-gestützter Steuerung – also Sensorik, Sensorfusion und Regelalgorithmen, die in Echtzeit auf Wellen, Wind und Lastwechsel reagieren.

Das ist Software-Entwicklung in ihrer unangenehmsten und spannendsten Form: harte Echtzeitanforderungen, sicherheitskritisch, kein „probieren wir es im nächsten Sprint nochmal". Wenn ein Webservice 200 Millisekunden hängt, ärgert sich ein Nutzer. Wenn eine Foil-Steuerung 200 Millisekunden hängt, landet ein Boot voller Fahrgäste unsanft im Wasser.

Was wir aus solchen Systemen für unsere Infrastruktur mitnehmen

Ich finde, solche Projekte sind ein gutes Anschauungsobjekt für Prinzipien, die wir im Rechenzentrum genauso brauchen – nur dass wir sie dort manchmal etwas lockerer nehmen:

• Regelkreise statt Momentaufnahmen: Ein Foil-Controller misst, korrigiert, misst wieder. Genau so sollte Monitoring funktionieren – nicht als Dashboard zum Angucken, sondern als Eingangsgröße für automatische Reaktionen.
• Graceful Degradation: Fällt ein Sensor aus, muss das System sauber in einen langsameren, sicheren Zustand zurückfallen. Bei uns heißt das: Lastabwurf, Read-only-Modus, Failover – aber bitte vorher durchgeplant.
• Redundanz dort, wo sie wehtut: Nicht die hübschen Komponenten doppelt auslegen, sondern die, deren Ausfall alles andere mitreißt.
• Updates für Systeme, die nicht einfach „aus" können: Firmware auf einem fahrenden Boot zu aktualisieren, ist konzeptionell dasselbe Problem wie ein Update an einem Core-Switch im Produktivbetrieb.

Und die Sicherheitsfrage

Je mehr Fahrzeuge – zu Wasser, zu Land, in der Luft – von Software gesteuert und per Netz angebunden werden, desto größer wird die Angriffsfläche. Telemetrie, Fernwartung, Flottenmanagement in der Cloud: All das ist praktisch, bringt aber die klassischen Fragen mit sich. Wer darf was? Wie sind die Schnittstellen abgesichert? Was passiert, wenn die Verbindung zum Backend wegbricht – und was, wenn jemand sie übernimmt? Meine Faustregel bleibt: Ein vernetztes System muss auch ohne Netz sicher weiterarbeiten können. Die Cloud darf Komfort und Auswertung liefern, nicht die Überlebensfähigkeit.

Mein Fazit

Elektrische Tragflächenboote sind ein schönes Beispiel dafür, wie sehr sich Hardware-Innovation inzwischen auf Software verlagert hat. Der Leichtbau und der E-Antrieb sind die Voraussetzung – aber fliegen lässt das Boot am Ende die Steuerung. Wer in der IT arbeitet, erkennt darin ziemlich viel wieder: verteilte Sensorik, Echtzeitverarbeitung, Ausfallsicherheit und die Frage, wie viel Vertrauen man einem Algorithmus geben will.

Bis demnächst, eure Kora

Quelle: t3n