Schneller oder langsamer — eine Echtzeit-Empfehlung im Cockpit
Im Flugbetrieb steht der Captain ständig vor Speed-Trade-offs: Verspätung reinholen, Slot treffen, Fuel sparen, Curfew einhalten. Ein Echtzeit-Empfehlungs-System quantifiziert die Optionen — Kosten gegen Kosten — und liefert eine konkrete Empfehlung an das Cockpit, mit Audit-Trail.
Schneller oder langsamer? Eine Antwort, bevor der Flug rollt. Im Flugbetrieb gibt es ständig Trade-offs zwischen Zeit und Treibstoff: Verspätung reinholen, weil Anschlüsse gefährdet sind. Bewusst langsamer fliegen, weil das Slot am Zielort eng ist. Curfew-Risiko entschärfen. Sustainability-Window halten. Bisher waren diese Entscheidungen verteilt, qualitativ, oft Bauchgefühl. Heute kommt eine quantifizierte Empfehlung als Telex-Nachricht ins Cockpit — in Echtzeit, mit Audit-Trail.
Das ist ein produktiver Speed-Up / Slow-Down Recommender in einem 24/7-Flugbetrieb. Mehrere Datenströme, ein Empfehlungs-Kern, kontextspezifische Empfehlungen. Hier ist, wie er funktioniert.
Was das System liefert
Sechs Datenströme in derselben Sekunde. Live-Position und Fuel-Stand des Flugzeugs. Operativer Flugplan mit geplantem Restverbrauch. Tagesaktuelle Treibstoffpreise. ATC-Restzeit bis Ziel. Slot- und Curfew-Constraints am Zielort. Kontext-Daten zum Trigger — bei Misconnect-Risiko z.B. Liste der Umsteiger plus per-Passenger-Kosten, bei Slot-Compliance die Slot-Toleranzen am Ziel.
Eine Berechnung pro Trigger-Kontext. Misconnect-Risiko ist ein Trigger — der erste, der produktiv lief, weil dort der Pain am direktesten war. Weitere Trigger im selben System:
- Schedule Recovery — Verspätung gegen Treibstoff bei Standard-Buchungs-Risiken
- Slot Compliance — bewusst langsamer, um Ankunftszeitfenster am Zielort zu treffen
- Curfew Compliance — schneller, um Lärm-Fenster vor Schließung zu erreichen
- Crew Duty Time — Geschwindigkeit anpassen, um Duty-Limits einzuhalten
- Sustainability — Fuel sparen, wenn Zeit-Reserve es erlaubt
- Connecting Passengers — Anschluss-Schutz mit per-Passenger-Kostenabwägung
Jeder Trigger nutzt dieselbe Datenbasis und denselben Empfehlungs-Kern. Was sich unterscheidet, sind die Kosten-Modelle und Schwellwerte — als Konfiguration zur Laufzeit gepflegt, ohne Code-Deploy pro neuem Trigger.
Die Empfehlung als Telex. Kosten gegen Kosten, in Klartext für den Captain:
„Sie können bis zu X kg zusätzlichen Treibstoff verbrauchen, um Y Minuten Zeit gutzumachen — Schadensvermeidung Z €."
Oder: „Sparen Sie bis zu X kg, wenn Sie W Minuten später ankommen — Slot bleibt im Toleranzfenster."
Die Entscheidung trifft der Pilot. Das System liefert die quantifizierte Grundlage — nicht für nur einen Trade-off, sondern für jeden, der im Flugbetrieb auftaucht.
Warum die Datenbasis das möglich macht
Was das System in wenigen Sekunden antworten lässt, ist nicht das System selbst — sondern die Plattform darunter. Alle Datenströme sind bereits integriert. Eine vollständig historisierte Vault-Schicht macht die Werte abrufbar, ohne in der heißen Entscheidungsschleife fremde Quellsysteme zu fragen. Die Kosten-Logiken sind als deklaratives, low-code-konfigurierbares Regelwerk hinterlegt — von Business Analysts wartbar, ohne Engineer-Ticket.
Was eine isolierte Punkt-Lösung Wochen kostet, wird über die Plattform-Basis zur Konfigurationsfrage. Ein neuer Trigger wird auf vorhandenen Datenströmen aufgesetzt, mit derselben Audit-Strecke und denselben Deployment-Pipelines wie alle anderen Services.
Was sich operativ ändert
Aus Bauchgefühl wird ein dokumentierter Trade-off. Jede Speed-Empfehlung ist nachvollziehbar — wer hat wann auf welcher Datengrundlage welche Empfehlung erhalten und welche Entscheidung getroffen. Operativ wertvoll. Revisionsfest gegenüber internen Audits und Behörden.
Die Entscheidung bleibt beim Piloten — wo sie hingehört. Was sich ändert, ist die Qualität der Grundlage. Aus „fühlt sich richtig an" wird „X kg, Y Minuten, Z €".
Neue Trigger werden zur Konfigurations-Aufgabe. Sustainability als Trigger, Wetterausweichung als Trigger, kommerzielle Anschluss-Erhaltung als Trigger — das sind Konfigurationen auf einer bestehenden Plattform, keine separaten Software-Projekte.
Operative Speed-Trade-offs gibt es in jedem 24/7-Flugbetrieb. Die Datenströme dafür liegen vor — selten in einer Plattform integriert, noch seltener mit einem konfigurierbaren Empfehlungs-Kern darüber. Wenn dieser Hebel bei Ihnen schlummert, lohnt sich ein Gespräch im Tactical Assessment.