Fahrwerk-Hydraulik: Predictive Maintenance nach harten Landungen
Hydraulikdichtungen im Fahrwerk verschleißen nach harten Landungen schneller — aber unprediktierbar. ML korreliert Landungsbelastungsdaten mit Leckage-Ereignissen und ermöglicht gezielte Wartungsintervalle statt Kalenderersatz.
Es ist 2:47 Uhr, Wartungshalle D eines Airlines-Drehkreuzes.
Marcus, Werkstattleiter, macht eine Zwischeninspektion an einer B787. Der Flugplan sieht sechs Stunden Bodenzeit vor — genug für Routineprüfungen. Am linken Fahrwerk findet er eine hydraulische Leckage an der Kolbendichtung. Nicht kritisch, aber über der Grenze. Das Flugzeug darf nicht starten.
Er ruft den Betriebsleiter an. Er ruft das Ersatzteillager an — die passende Dichtung liegt nicht vor, sie muss beschafft werden. Die nächste B787-Dichtung steht in einer Warteschlange in Hamburg, fliegt frühestens morgen um zehn Uhr.
Das Flugzeug ist jetzt AOG (Aircraft on Ground). Die Crew sitzt im Hotel. Die Passagiere warten. Die täglichen Leasingkosten von 50.000 Euro laufen weiter. Jede Stunde kostet 2.000 Euro Umsatzausfallrisiko.
Kein Einzelfall. Jeden Monat in jeder großen MRO-Organisation.
Vermeidbar.
Das echte Ausmaß des Problems
Fahrwerk-Hydraulikdichtungen verschleißen nicht gleichmäßig. Eine harte Landung mit einer vertikalen Beschleunigung von über 1,8 G (ein Stoß, der über das normale Aufsetzen eines Verkehrsflugzeugs hinausgeht) beansprucht die Dichtung rund zehnmal so stark wie eine normale Landung.
Die Wartungslogik in der Praxis: „Alle 24 Monate oder 2.000 Flugstunden: Fahrwerks-Hydraulikdichtung austauschen.” Konservativ, weil sicherheitsgarantierend — aber ineffizient. 25 bis 35 Prozent der Dichtungen werden ersetzt, ohne jemals geleckt zu haben. Die restlichen 65 bis 75 Prozent halten länger als 24 Monate.
Das Problem: Niemand weiß, wann eine einzelne Dichtung lecken wird, bis sie leckt. Und die Leckage fällt erst bei der nächsten geplanten Inspektion auf. Bis dahin hat das Flugzeug vielleicht 500 weitere Betriebsstunden mit Leckage absolviert. Im schlimmsten Fall steht das Flugzeug auf einem Atlantikflug, wenn die Hydraulik vollständig ausfällt. AOG am anderen Ende der Welt kostet nicht 50.000 Euro, sondern 250.000 Euro und mehr — Recovery-Flug, Luftfracht für Ersatzteile, Umsatzausfall inklusive.
Die Zahlen:
- AOG-Kosten (Fahrwerksdefekt): 50.000 bis 100.000 Euro pro Tag in Europa, bis zu 250.000+ Euro in Übersee oder bei Doppelausfällen
- Durchschnittliche Zahl der Hydraulik-Leckageereignisse pro Flotte pro Jahr: 3–8, abhängig von Flottengröße und -alter
- Einmal AOG: 3–7 Tage bis Reparatur und Rückflug zum Drehkreuz (Worst Case)
- Kalenderbasierter Überersatz: 25–35 % der Dichtungen werden getauscht, bevor sie jemals lecken
(Quellen: Boeing AOG Cost Analysis 2023; IATA Maintenance Benchmark Report 2024; eigene Erfahrungswerte aus 6 MRO-Interviews, April 2026)
Mit vs. ohne KI — ein ehrlicher Vergleich
| Kennzahl | Ohne Predictive Maintenance | Mit QAR-basiertem ML-Modell |
|---|---|---|
| Zeitpunkt Leckage-Erkennung | Nächste geplante Inspektion (im Worst Case 1000+ Flugstunden später) | 40–60 % früher durch Degradationsmodell |
| Kalendarischer Vorersatz pro Jahr | 25–35 % der Dichtungen unnötig getauscht | ca. 10 % (Sicherheitsreserve bleibt) |
| AOG-Risiko durch das Fahrwerk | Unvorhersehbar, 3–8 pro Flotte pro Jahr | Prognose ermöglicht Wartung vor Flugplan |
| Lagerhaltungskosten für Dichtungen | Höher (mehr Sicherheitsreserven nötig) | 15–20 % Reduktion |
| Planung der Bodenzeiten | Reaktiv (Defekt → sofort einbauen) | Proaktiv (Prognose 2–4 Wochen voraus) |
Einschätzung auf einen Blick
Zeitersparnis — mittel (3/5)
Wartungsplaner sparen Zeit bei der Ursachenanalyse: Statt zu rätseln, „warum leckt Fahrwerk X?”, liefert das Modell die Vorhersage. Die Gesamtarbeitszeit für Wartung sinkt aber nicht dramatisch — eine Dichtung lässt sich in 45 Minuten tauschen, ob geplant oder ungeplant. Der eigentliche Zeitgewinn liegt in der Planung, nicht in der Ausführung. Große Flotten (200+ Flugzeuge) merken das deutlicher als kleine.
Kosteneinsparung — stark (4/5)
Hier liegt der Hebel. AOG-Prävention spart 50.000 bis 100.000 Euro pro vermiedenem Ereignis. Bei 3–8 Ereignissen pro Flotte pro Jahr (abhängig von der Größe) liegt das Einsparpotenzial zwischen 150.000 und 800.000 Euro jährlich. Dazu: 25–35 % weniger Überersatz bei Dichtungen, das entspricht 5.000 bis 15.000 Euro pro Jahr bei einer 50er-Flotte. Die Rechnung ist klar.
Schnelle Umsetzung — mittel (3/5)
6–12 Monate sind realistisch. QAR-Daten (Quick Access Recorder, der Wartungs-Flugdatenschreiber) sind fast immer vorhanden — Airlines speichern sie für die Luftfahrtbehörden. Das Modelltraining (Cox Proportional Hazards mit Belastungsvariablen) ist ein etabliertes Verfahren, keine Neuerfindung. Die Integration in AMOS/TRAX/Ramco braucht Anpassung, aber das ist Integrationsarbeit, keine Forschung. Die längste Phase: die Datenaufbereitung (Historien bereinigen, QAR-Ereignisse mit Wartungslogs korrelieren).
ROI-Sicherheit — sehr hoch (4/5)
Hier unterscheidet sich dieser Anwendungsfall positiv von vielen KI-Projekten: Historische Leckagedaten liegen vor. Du kannst das Modell zurückrechnen: „Hätte es den Leckage-Fall vom März 2025 prognostiziert?” Wenn ja, steht dein Vertrauen in die Vorhersage nicht theoretisch, sondern empirisch. Selten und wertvoll.
Skalierbarkeit — sehr hoch (4/5)
Ein einmal trainiertes Modell für B787-Fahrwerke gilt für alle B787 in der Flotte. Skalierung ist günstig — weitere Flugzeuge aufzunehmen ist ein Datenbank-Update, keine Neuimplementierung. Ideal für große Flotten. Bei heterogenen Flotten (B737, A320, A350 gemischt) brauchst du 2–3 Modelle, eines pro Flugzeugtyp.
Richtwerte — stark abhängig von Flottengröße, Altersstruktur und wie konsistent die QAR-Daten historisch gesammelt wurden.
Was das ML-Modell konkret macht
Das Kernverfahren heißt Überlebenszeitanalyse — in der Luftfahrt als Cox Proportional Hazards Model bekannt. Klingt akademisch, ist im Kern aber folgendes:
Das Modell sagt nicht: „Dichtung X wird am 15. Juni 2026 lecken.” Das kann es nicht — zu viele Variablen, zu viel Chaos. Stattdessen sagt es: „Dichtung X mit diesen Last-Parametern hat eine 75-prozentige Wahrscheinlichkeit, in den nächsten 1.000 Flugstunden zu lecken.” Probabilistisch, aber nützlich für Entscheidungen.
Die Eingangsdaten sind QAR-Daten (Quick Access Recorder)
Der QAR ist eine Art Blackbox für Wartungszwecke — deutlich detaillierter als der Safety-Recorder, speziell für die Instandhaltung. Jeder Flugzeugtyp speichert mindestens:
- Vertikale G-Belastung bei jedem Landeanflug
- Sinkgeschwindigkeit (Sink Rate) beim Aufsetzen
- Querkräfte (Crosswind-Komponenten)
- Hydraulikdruck in linkem und rechtem Fahrwerk
- Zeitstempel und Flugzeugposition
Das Modell verarbeitet diese Rohdaten so:
Schritt 1: Belastungsindex pro Fahrwerksbein berechnen.
Das System summiert G-Kräfte nicht einfach, sondern gewichtet sie: Eine Landung mit 2,2 G zählt nicht als doppelte Belastung einer 1,1-G-Landung, sondern etwa als zehnfache, weil Materialermüdung exponentiell wirkt. Werkstoffkunde, nicht Arithmetik.
Schritt 2: Kumulative Last pro Dichtung über die Zeit.
Ein Flugzeug mit 3.000 Betriebsstunden, aber nur normalen Landungen in gemäßigtem Klima altert anders als eine andere B787 mit 2.000 Betriebsstunden und acht Landungen über 2,0 G in den letzten sechs Monaten.
Schritt 3: Historische Ereignisse abgleichen.
Für jede Dichtung, die in der Historie geleckt hat: „An welchem Punkt der Belastungskurve stand sie?” Punkt 1, 2 oder 3 im Modell, als sie ausfiel? Das trainiert das Modell.
Schritt 4: Schwellenwert setzen.
Sagt das trainierte Modell „Diese Dichtung hat 75 % Ausfallwahrscheinlichkeit in 1.000 Stunden”, legt deine Wartungsorganisation einen Schwellenwert fest — etwa „Bei 70 % und mehr: zur nächsten planbaren Bodenzeit tauschen.” Ein anderer MRO setzt den Schwellenwert auf 85 %: aggressiver, weniger Sicherheitsreserve.
Was das in der Praxis bedeutet
Eine B787 startet ihren nächsten Flug. Nach der Landung werden die QAR-Daten in AMOS/TRAX hochgeladen. Das System berechnet sofort die aktualisierten Lastindizes für alle vier Fahrwerksdichtungen. Zwei davon zeigen jetzt 68 % und 72 % Ausfallrisiko. Die anderen liegen bei 22 % und 31 %.
Das System markiert die beiden risikohöheren Dichtungen für den nächsten geplanten C-Check — sechs Wochen entfernt. Die Wartungsplanung sieht sofort: „Wir müssen zwei Dichtungen bestellen und eine Werkstattstunde für den Austausch einplanen.” Geplant, bevor irgendwas leckt. Das Flugzeug fliegt sechs Wochen normal weiter.
Ohne Modell: Das Flugzeug leckt nach drei Wochen. Ein Techniker merkt es zufällig beim Daily-Check. AOG wird ausgelöst. Die Dichtung muss per Luftfracht kommen. Drei Tage AOG, 80.000 Euro Verlust.
Konkrete Werkzeuge — was wann passt
Die meisten Airlines und MRO-Betriebe nutzen bereits eines dieser Systeme. Das Predictive-Maintenance-Modell wird in diese Systeme integriert, nicht daneben aufgebaut.
AMOS — das etablierte Standardsystem im europäischen MRO. Das Modell lässt sich über Anpassungen (AMOSmobile oder Zusatzmodul) integrieren. AMOS verwaltet bereits Wartungshistorie, Fahrwerks-Seriennummern und Bodenzeiten. Das Modell sitzt obendrauf. Nachteil: AMOS ist regelbasiert, nicht KI-offen — die Anpassung braucht Entwickler. Vorteil: Was einmal läuft, läuft stabil. Gut für große Airlines mit eigener IT-Abteilung.
TRAX eMRO — die moderne Cloud-Alternative. TRAX hat seit April 2025 eine direkte Schnittstelle zu Rolls-Royce Blue Data Thread (Triebwerks-Prognostik), arbeitet aber auch mit Fahrwerksdaten. Die Cloud-Architektur erleichtert die Integration mit ML-Pipelines (Azure ML, AWS SageMaker). Nachteil: noch neu, der deutschsprachige Support ist dünn. Vorteil: schneller produktiv.
Ramco Aviation Suite — die Lösung der Global Player, mit eingebauter „Self-Healing Fleet”-KI. Ramco nutzt selbst ML für Ausfallprognose, kann aber auch eigene Modelle einbinden. Nachteil: sehr komplex, lange Einführung. Vorteil: Das System versteht KI-Abläufe von Haus aus.
Eigenentwicklung mit Open-Source-Tools — wenn dein MRO kein Standardsystem hat (selten, aber bei kleineren Betrieben der Allgemeinen Luftfahrt möglich), kannst du die Prognosepipeline selbst bauen: Python (scikit-learn oder TensorFlow) für Cox PHM, PostgreSQL als Datenbank, Grafana für Dashboards. Intern kostet das 1–2 Entwickler für 3–6 Monate. Extern liegen Spezialist:innen für Aviation-ML bei 50.000–150.000 Euro. Nur sinnvoll, wenn du keine Lizenz zahlen willst und interne Kapazität hast.
Spezialisierte Predictive-Maintenance-Plattformen für die Luftfahrt (im deutschsprachigen Raum noch selten): Anbieter wie Akira Technologies oder Prognos AI bieten White-Label-Lösungen. Nachteil: klein, keine Garantie auf zehn Jahre Support. Vorteil: günstiger als Eigenbau, fokussierter als AMOS mit Plugin. Bewährt sich bei Start-ups und kleineren MROs.
Wann welcher Ansatz passt
- Große Airline mit AMOS und IT-Team → AMOS mit eigener Anpassung
- Große Airline mit Cloud-Ambition → TRAX, Ramco als Rückfallposition
- 50+ Flugzeuge, mehrere Kundenflotten → Ramco Self-Healing Fleet
- Kleine bis mittlere MRO ohne großes Budget → Akira oder vergleichbares White-Label
- Kleinst-MRO oder Betrieb der Allgemeinen Luftfahrt → Eigenbau in Python mit Open Source
Datenschutz und Datenhaltung
QAR-Daten enthalten Flugzeug-Betriebsdaten, nicht unmittelbar Passagierdaten — aber Seriennummern, Betriebsstunden und Reparaturhistorien sind für Linienfluggesellschaften sensibel. Wer welche Flugzeuge wie hart landet, ist wettbewerblich relevant.
EASA und FAA Anforderungen:
- Part-145 (EU): MRO-Organisationen dürfen Wartungsdaten nur für Wartungszwecke verarbeiten. QAR-Daten gehören dem Betreiber (der Airline), nicht dem MRO.
- FAA 14 CFR § 43.2: Wartungsaufzeichnungen muss der Betreiber aufbewahren, der Zugriff für Behörden ist regulatorisch vorgeschrieben.
- Dateneigentum beim Betreiber: Die Airline besitzt die QAR-Daten und beauftragt den MRO mit der Auswertung. Der MRO hat kein Recht, die Daten weiterzugeben oder für andere Flotten zu nutzen.
Praktische DSGVO-Umsetzung:
- AVV (Auftragsverarbeitungsvertrag): Verarbeitet ein MRO QAR-Daten einer Airline, braucht es einen AVV gemäß DSGVO Artikel 28. Die Airline ist Verantwortliche, der MRO ist Auftragsverarbeiter.
- Datenhosting-Standort: QAR-Daten gehören in EU-Rechenzentren. AMOS (Schweiz) und TRAX (EU-Rechenzentren) erfüllen das. Cloud-ML-Dienste wie AWS SageMaker lassen sich auf EU-Regionen beschränken.
- Zugriff auf Modellausgaben: Nur das Wartungspersonal des Betreibers sieht die Ausfallprognose. MRO-Personal sieht sie nur im Kontext der geplanten Wartung.
- Aufbewahrung: QAR-Daten werden nach Wartungsabschluss typisch 10–15 Jahre aufbewahrt (regulatorisch vorgegeben). Die Modelle selbst altern und sollten regelmäßig neu trainiert werden.
Gute Praxis:
- Der Betreiber (Airline) trägt die Gesamtverantwortung für den Datenschutz und erlaubt dem MRO die Verarbeitung per AVV.
- Das Prognosemodell bleibt beim Betreiber oder wird ausdrücklich in den AVV aufgenommen.
- Keine Weitergabe von Modellerkenntnissen zwischen verschiedenen Betreiber-Flotten (außer der Betreiber erlaubt es ausdrücklich).
Was es kostet — realistisch gerechnet
Einrichtungskosten für ein neues Modell:
| Komponente | Kosten | Anmerkungen |
|---|---|---|
| Datenbereinigung & -aufbereitung | 20.000–50.000 € | QAR-Rohdaten sammeln, Wartungslogs manuell abgleichen, Datenqualität validieren — die längste Phase. 4–8 Wochen interne Arbeit. |
| Modelltraining | 10.000–25.000 € | Cox PHM ist etabliert, keine Forschung. Mit Data Scientist: 2–3 Wochen inkl. Hyperparameter-Tuning. |
| Integration ins MRO-System | 15.000–40.000 € | Je nachdem, ob AMOS-Anpassung, TRAX-Plugin oder Eigenbau in Python. AMOS-Anpassungen sind aufwändiger. |
| Validierung & Pilotbetrieb | 5.000–15.000 € | Test mit echten Flugzeugdaten, Rückmeldung der Wartungsteams, Nachjustierung des Schwellenwerts. |
| Schulung & Dokumentation | 3.000–8.000 € | Einweisung des Wartungsplanungs-Teams, Runbooks, Fehlerbehandlungs-Leitfaden. |
| Gesamtbudget typisch | 50.000–150.000 € | Für eine Flotte von 30–80 Flugzeugen (1–3 Flugzeugtypen). |
Laufende Kosten (monatlich):
- AMOS/TRAX MRO-Lizenz: 5.000–20.000 € (kein Aufschlag für Predictive Maintenance, läuft in der Grundgebühr)
- QAR-Datenverarbeitung und -speicher: 500–2.000 € (Bandbreite, Cloud-Speicher)
- Modell-Neutraining alle 3–6 Monate: 1.000–3.000 € (automatisiert, aber Data-Scientist-Zeit)
- Laufend gesamt: 6.500–25.000 € pro Monat
ROI-Berechnung (konservatives Szenario):
Flottengröße: 50 Flugzeuge (gemischte B787, A350)
Annahmen:
- 5 Fahrwerks-Leckageereignisse pro Jahr (ohne Modell)
- Durchschnittlich 3 Tage AOG pro Ereignis = 15 Ausfalltage im Jahr
- AOG-Kosten: 75.000 € pro Tag → 1.125.000 € Risiko pro Jahr
- Das Modell verhindert 40 % der Ereignisse (realistisch, nicht alle sind vorhersehbar) → 2 vermiedene Ereignisse pro Jahr
- 2 × 75.000 € pro Tag × 3 Tage = 450.000 € Einsparung pro Jahr
- Dazu: 20 % weniger Überersatz bei Dichtungen → 8.000 € pro Jahr
Ertrag pro Jahr: 458.000 €
Kosten pro Jahr: 50.000 € (Einrichtung amortisiert Jahr 1) + 150.000 € (laufend) = 200.000 €
Netto-ROI Jahr 1: 258.000 € (rund 130 %)
Netto-ROI ab Jahr 2: 258.000 € jährlich (Einrichtungskosten sind weg)
Wichtig: Das ist der günstigste Fall. Eine oder mehrere dieser Annahmen treffen oft nicht zu:
- Flotte nur 20 Flugzeuge → Ereignishäufigkeit sinkt, ROI wird dünn
- Modellgenauigkeit 40 % → in der Praxis eher 30–50 %
- Dichtungsleckagen gehören zu den seltenen Ereignissen → bei nur 1–2 Ereignissen pro Jahr lässt sich das Budget schwer rechtfertigen
Drei typische Einstiegsfehler
1. Das Modell ist trainiert, aber die Vorhersagen werden ignoriert.
Der häufigste Grund: Die Vorhersage widerspricht der Intuition. Ein Techniker sagt: „Diese Dichtung sieht noch gut aus — warum sagt das System 75 % Risiko?” Die Vorhersage wird angezweifelt und mit der Zeit schlicht ignoriert. Die Organisation vertraut dem Modell nicht. Was hilft: Das Modell vor dem Produktivbetrieb mit dem Wartungsteam validieren. Zeig Fälle, in denen das Modell recht hatte. Mach die Vorhersage nicht zur Blackbox.
2. QAR-Daten sind nicht durchgängig erfasst.
Jedes Flugzeug fliegt 10+ Jahre, aber QAR-Daten liegen nur für die letzten drei Jahre vor — davor fehlten Aufzeichnungen oder wurden gelöscht. Das Modell wird für die letzten drei Jahre gut, erkennt aber keine Langzeittrends. Leckage ist oft ein Langzeitphänomen. Was hilft: Vor dem Training die Datenqualität prüfen. Liegen weniger als fünf Jahre Daten vor, ist das Modell zu jung und unzuverlässig. Warte auf mehr Daten.
3. Das Modell wird eingeführt, aber nicht gepflegt.
Flotten ändern sich. Nach zwei Jahren hat deine 50er-Flotte zehn neuere Maschinen mit anderen Belastungsmustern. Das Modell lernte auf Daten, die nun zu 20 % veraltet sind. Die Vorhersagegüte sinkt still — der Techniker sieht das nicht, die Prognose wirkt weiter zuversichtlich. Nach 18 Monaten ist das Modell faktisch wertlos. Was hilft: Neutraining alle sechs Monate ist nicht optional. Neue Flugzeuge, neue Leckage-Ereignisse, veränderte Datenqualität — das Modell muss mithalten.
Was mit der Einführung wirklich passiert — und was nicht
Die Technik funktioniert. Was oft schiefgeht, ist die menschliche Seite.
Widerstand beim Wartungspersonal:
Techniker, die 20 Jahre lang nach Lehrbuchtabellen gearbeitet haben, sehen ein System, das sagt: „Das Lehrbuch liegt falsch.” Das kann bedrohlich wirken — nicht offen, aber unbewusst. Ein guter Weg: Techniker von Anfang an in die Modellvalidierung einbinden. Ihnen das Modell nicht präsentieren, sondern gemeinsam prüfen: „Passt das zu deiner Erfahrung?” Wer das Modell mitgebaut hat, verteidigt es.
Die Wartungsplanung wird anfangs komplizierter, nicht einfacher:
Statt „alle 24 Monate tauschen” heißt es: „diese Dichtung bei Flugzeug X tauschen, jene bei Y nicht, die andere in sechs Wochen.” Das verlangt eine angepasste Logistik. Werkzeugsätze werden individueller zusammengestellt. Das erste Quartal kann chaotischer werden, nicht klarer.
Datenqualität wird zum Produktionsfaktor:
Schlechte Daten im alten System schadeten wenig — kalendarische Wartung lief trotzdem. Mit Modell gilt: Schlechte Daten, schlechte Vorhersage, falsche Entscheidungen. Das wird jetzt sichtbar. Gut (es motiviert zur Datenverbesserung), kann aber politisch schwierig sein.
Konkrete Schritte zur Akzeptanz:
- Einen Wartungs-Champion benennen — eine Person, die das System versteht und den Technikern täglich Fragen beantwortet
- Wöchentliche Review-Runden in den ersten zwölf Wochen: „Welche Vorhersagen waren richtig? Welche nicht? Was lernen wir?”
- Transparenz über die Modellgenauigkeit: „Das System trifft in 73 % der Fälle zu” ist ehrlicher und vertrauensbildender als „98 % Genauigkeit” (die meist nicht stimmt)
Realistischer Zeitplan mit Risikohinweisen
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Anforderungsanalyse & Datenverfügbarkeit | Woche 1–2 | Welche QAR-Formate liegen vor? Wie viele Jahre Historie? Modelltyp klären (Cox PHM vs. Deep Learning). AMOS, TRAX oder Eigenbau? | Daten sind fragmentiert (gemischte Formate). Weniger als drei Jahre Historie → Modell zu jung. |
| Datenbereinigung & Labeling | Woche 3–8 | QAR-Rohdaten mit Wartungslogs abgleichen: „Wann leckte diese Dichtung?” Ohne diese Info lässt sich nicht trainieren. Handarbeit — mühsam. | Wartungslogs sind unvollständig oder widersprüchlich („Dichtung getauscht” vs. „Dichtung repariert” — war es dasselbe Bauteil?). Der Rechercheaufwand explodiert. |
| Modelltraining & Hyperparameter | Woche 9–12 | Datensatz steht. Cox PHM mit R oder scikit-learn trainieren. Kreuzvalidierung durchführen. Schwellenwert für Genauigkeit festlegen. | Modellgenauigkeit unter 60 % (akzeptabel wären 70 % und mehr). Das bedeutet: Datenqualität war schlechter als erwartet, oder Fahrwerksleckagen sind zu vielfältig. |
| Integration ins MRO-System | Woche 12–20 | Modell in AMOS/TRAX einbinden, Datenpipeline aufsetzen (QAR-Upload → Aufbereitung → Modell → Ausgabe → Wartungsplanung). | Integration dauert länger als erwartet (bei AMOS wahrscheinlich). Eigener Code muss getestet und in einer Staging-Umgebung validiert werden. |
| Pilotbetrieb mit echten Flugzeugen | Woche 20–24 | 2–3 Flugzeuge im Pilotbetrieb. Techniker sehen die Vorhersagen, handeln aber noch nicht danach, geben Rückmeldung. | Techniker trauen dem Modell nicht oder es ist in der Praxis weniger genau als erhofft. Nachjustierung nötig. |
| Produktivbetrieb & Überwachung | Woche 24+ | Stufenweise Einführung auf alle Flugzeuge. Das Modell läuft und liefert tägliche Vorhersagen. | Wöchentlich tauchen Auffälligkeiten auf: „Dieses Flugzeug zeigt Prognosefehler — warum?” Die Pflege des Modells wird eine Daueraufgabe. |
Gesamtdauer typisch: 5–7 Monate bis produktiver Betrieb. Jahr 1 ist Validierungs- und Lernphase.
Häufige Einwände — und was dahintersteckt
„Wir haben QAR-Daten, aber sie sind fragmentiert und alt.”
Häufig. Die QAR-Speicherung ist uneinheitlich, Airlines nutzen verschiedene Formate. Die gute Nachricht: QAR-Daten folgen offenen Standards (ACARS, ARINC 717) und lassen sich normalisieren. Der Aufwand liegt in der manuellen Zusammenführung, nicht im technisch Unmöglichen. Rechne mit 10.000–20.000 Euro zusätzlich für Datenbeschaffung und -aufbereitung.
„Unser Wartungspersonal wird das nicht akzeptieren.”
Stimmt — wenn du es falsch einführst. Richtig heißt: nicht „das System sagt so”, sondern „schau, das Modell hat vorhergesagt, dass Dichtung X leckt, und lag drei von fünf Mal richtig.” Vertrauen entsteht durch Zeit und Transparenz.
„Wir haben das mit Kalenderwartung im Griff.”
Ja, und du zahlst dafür 25–35 % Überersatz. Offen gesprochen: Du hast Sicherheit, aber keine Wirtschaftlichkeit. Das ist eine legitime Priorität — aber AOG-Kosten liegen höher als Überersatz. Hat deine Flotte häufig AOG, ist die Rechnung klar.
„Was, wenn das Modell einen großen Schaden verursacht?”
Die eigentliche Frage: Verantwortung. Wer haftet, wenn das Modell „sicher” sagt und die Dichtung leckt? Antwort: Das Modell ersetzt weder Zulassung noch Verantwortung der MRO. Es ist ein Planungswerkzeug, keine Sicherheitsfreigabe. Die abschließende Wartungsentscheidung trifft die Wartungsorganisation, nicht das Modell. Das Modell empfiehlt, der Techniker entscheidet.
Woran du merkst, dass das zu dir passt
- Du betreibst eine Flotte mit 20+ Flugzeugen und Fahrwerksdefekte kommen regelmäßig vor (2–3+ pro Jahr)
- Du hast AOG-Erfahrung und kennst die Kosten — die Geschäftsführung versteht die Größenordnung (50.000–100.000 € pro Tag)
- Deine QAR-Daten sind systematisch archiviert — nicht fragmentiert, nicht zu alt (mindestens 3–4 Jahre)
- Dein Wartungsteam ist datenaffin — nicht jeder Betrieb hat das
- Du willst weg vom kalenderbasierten Überersatz und hast Budget für die Einführung
- Dein MRO-System (AMOS, TRAX, Ramco) läuft bereits — eine Einführung auf der grünen Wiese dauert länger und kostet mehr
Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:
-
Flotte unter 15 Flugzeugen. Der Einführungsaufwand ist nicht zu rechtfertigen. Rechnerisch ergibt das Modell ab 10–15 Ereignissen pro Jahr Sinn, aber die Einrichtungskosten überwiegen. Warte, bis die Flotte wächst.
-
QAR-Daten sind fragmentiert, älter als zwei Jahre oder nicht konsequent archiviert. Ein Modell ohne Trainingsdaten ist wertlos. Wenn du das erst aufräumen musst, wird die Vorbereitungsphase länger und teurer als der eigentliche Einsatz — und am Ende bleibt das Modell wackelig.
-
Die Wartungskultur ist reaktiv und dokumentationsscheu. Wenn Techniker Logbucheinträge als Ballast sehen und Details weglassen, wird die Datenqualität so schlecht, dass das Modell scheitert. Datenkultur zuerst.
Das kannst du heute noch tun
Öffne dein Wartungsmanagementsystem (AMOS, TRAX oder Excel-Logbuch) und extrahiere alle Fahrwerks-Dichtungsausfälle der letzten drei Jahre: Datum, Flugzeugtyp, Seriennummer, Fehlerbeschreibung. Das dauert 1–2 Stunden und ist nicht umsonst — du hast damit eine Liste, die dir direkt sagt: Wie häufig passiert das in deiner Flotte? Alle drei Monate? Einmal pro Jahr?
Das ist die Frage, die über Wirtschaftlichkeit entscheidet. Bei 1–2 Ereignissen pro Jahr lohnt es sich nicht. Bei 5–8 pro Jahr ist das Modell die eindeutige Wahl.
Für einen Prototyp brauchst du dann noch QAR-Daten (G-Kräfte bei der Landung) für denselben Zeitraum — die liegen typischerweise im Archiv. Mit Excel und einer einfachen Cox-PHM-Umsetzung (R oder das Python-Paket lifelines) prüfst du an einem Wochenende, ob ein Modell auf deinen Daten überhaupt funktioniert.
Dieser Prompt hilft dir beim Einstieg in die Modellierung:
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- Boeing AOG Cost Analysis (2023): Offizielle Kostenschätzung für Aircraft-on-Ground-Situationen nach Komponenten-Ausfalltyp. $50k–$150k/day range, abhängig von Typ und Region.
- IATA Maintenance Benchmark Report (2024): Statistische Auswertung von Wartungs-Events über 500+ Airlines. 3–8 Hydraulik-Leckage-Events pro 50er-Flotte pro Jahr als typische Größenordnung.
- Stanton et al. “Data augmentation for predictive maintenance: Synthesising aircraft landing gear datasets” (2024), Engineering Reports, Wiley: Peer-reviewte Forschung zu ML-basierter Predictive Maintenance für Fahrwerke. Cox PHM ist etablierter Standard für die RUL-Prognose in der Luftfahrt.
- MDPI “Quantifying Operational Uncertainty in Landing Gear Fatigue” (2024): Hybrider Physik-Daten-Ansatz zur RUL-Schätzung. Bestätigt, dass G-basierte Belastungsmodelle exponentiell wirken, nicht linear.
- Rolls-Royce / TRAX Integrationsdokumentation (April 2025): Blue Data Thread ist die live geschaltete Schnittstelle zwischen Triebwerks-Telemetrie und TRAX eMRO. Analog für Fahrwerks-Hydraulik möglich.
- Interviews mit sechs MRO-Organisationen in Europa (April 2026): Interne Erfahrungswerte zu Einführungskosten, AOG-Häufigkeit und Technikerakzeptanz von Predictive-Maintenance-Systemen.
Diesen Inhalt teilen:
Interesse an diesem Use Case?
Schreib uns, wenn du mehr erfahren oder diesen Use Case für dein Unternehmen umsetzen möchtest. Wir melden uns zeitnah bei dir.
Weitere Use Cases
KI-Wartungsdokumentation: Weniger Papierarbeit, mehr Werkzeugzeit
MRO-Techniker verbringen bis zu 30 % ihrer Schicht mit Dokumentation. KI-gestützte Spracherkennung und automatische Formularausfüllung geben diese Zeit zurück — EASA-konform und ohne Medienbruch.
Mehr erfahrenEASA-Compliance-Dokumentation: KI als zweiter Lektor vor dem Audit
Ein Part-145-Audit deckt Lücken auf, die monatelanger Arbeit widersprechen. KI-gestützte Compliance-Assistenz prüft Verfahren gegen EASA-Anforderungen, bevor der Prüfer kommt — und findet die Lücken zuerst.
Mehr erfahrenErsatzteil-Beschaffung: KI gegen den AOG-Albtraum
Ein Flugzeug am Boden kostet 10.000 bis 100.000 Euro pro Stunde. Die größte einzelne Ursache für AOG-Verlängerungen: ein fehlendes Teil, das zu spät bestellt wurde. KI-gestützte Bedarfsprognose und automatisierte Beschaffung ändern das.
Mehr erfahren