Fahrwerk-Hydraulik: Predictive Maintenance nach harten Landungen
Federbein-Dichtungen im Fahrwerk lecken unvorhersehbar, womöglich früher nach harten Landungen. ML korreliert Landebelastungen mit Leckage-Ereignissen und hilft, Tauschaktionen in geplante Bodenzeiten zu legen, statt auf das Leck an einer Außenstation zu warten.
Mit KI-Agenten recherchiert und geschrieben, verantwortlich: Redaktion KI-Syndikat. So arbeiten wir Fehler melden
- Problem
- Fahrwerksdichtungen werden je nach Instandhaltungsprogramm nach Intervall, bei der Fahrwerksüberholung oder erst getauscht, wenn ein Leck die Grenzen im AMM überschreitet. Das Leck fällt beim Walkaround oder Daily Check auf, dort, wo das Flugzeug gerade steht. Liegt keine Ersatzdichtung am Standort, bleibt es am Boden. Ob harte Landungen die Dichtungen messbar schneller verschleißen, muss der eigene Datensatz zeigen.
- KI-Lösung
- Cox Proportional Hazards Modell (Überlebenszeitanalyse) auf QAR-Daten (Quick Access Recorder): vertikale Beschleunigung je Landung, Sink Rate, Crosswind-Komponente. Berechnet einen kumulativen Belastungsindex pro Fahrwerksbein und schätzt das Leckrisiko der Dichtungen auf Basis historischer Leckage-Ereignisse.
- Typischer Nutzen
- Dichtungstausch in eine geplante Bodenzeit legen, bevor das Leck an der falschen Station auffällt. Wie viele Lecks das Modell rechtzeitig sieht, zeigt erst ein Back-Test auf euren Daten. Früher tauschen dürft ihr jederzeit, ein festes Intervall strecken nur mit genehmigter Änderung des Instandhaltungsprogramms.
- Setup-Zeit
- 6–12 Monate bis Produktivbetrieb
- Kosteneinschätzung
- 50.000–150.000 € Einrichtung, 1.500–5.000 €/Monat laufend
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 Leasingrate läuft ohnehin weiter, teuer sind die ausgefallenen Umläufe: Umbuchungen, Hotels, ein Ersatzflugzeug, falls es eines gibt.
Die Dichtung kostet 18 Euro. Die nächste liegt in Hamburg. Das Flugzeug steht bis morgen um zehn.
Für Unternehmen
Nicht nur lesen, umsetzen.
Wir setzen Anwendungsfälle wie diesen mit euch um oder trainieren euer Team darauf. Das Erstgespräch kostet nichts.
Das echte Ausmaß des Problems
Fahrwerksdichtungen 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) belastet das Fahrwerk deutlich stärker als eine normale Landung, und nach einer gemeldeten harten Landung schreibt das AMM ohnehin eine Inspektion vor. Bei Metallteilen wächst der Ermüdungsschaden überproportional mit der Last. Wie stark das bei den Elastomerdichtungen eines Federbeins durchschlägt, ist nicht belegt, das muss dein Datensatz zeigen.
Wie die Dichtungen heute getauscht werden, steht in eurem Instandhaltungsprogramm: nach festem Intervall, bei der Fahrwerksüberholung oder nach Zustand, wenn ein Leck die Grenzen im AMM überschreitet. Einen Branchenwert dafür, wie viele Dichtungen zu früh getauscht werden, haben wir nicht gefunden.
Das Problem: Niemand weiß, wann eine einzelne Dichtung lecken wird, bis sie leckt. Ein sichtbares Leck fällt beim Walkaround vor dem Flug oder beim Daily Check auf, und zwar dort, wo das Flugzeug gerade steht. Liegt das an einer Außenstation ohne Ersatzdichtung und ohne passendes Werkzeug, wird aus einem kleinen Leck ein Tag am Boden oder mehr.
Die Szene oben hat dabei eine unbequeme Pointe: Das Flugzeug steht nicht, weil niemand das Leck vorhergesagt hat, sondern weil eine 18-Euro-Dichtung nicht am Standort lag. Bevor du ein Modell baust, prüf deinen Dichtungsbestand an den Stationen. Das ist billiger als jedes Modell und verkürzt genau diese Art von AOG-Zeit.
Die Zahlen:
- AOG-Kosten: Branchenrechnungen nennen für Schmalrumpfflugzeuge 50.000 bis 150.000 US-Dollar am Tag (eways-aviation.com, Simple Flying), für Langstreckenflugzeuge wie B787 und A350 eher mehr
- Wie oft Fahrwerkslecks in deiner Flotte ein Flugzeug am Boden halten, zeigt nur deine eigene Historie. Veröffentlichte Branchenwerte je Flotte haben wir nicht gefunden
- Wie lange ein solcher Fall dauert, hängt vor allem an Ersatzteil und Werkzeug am Standort: in der Szene oben ein Tag, an einer entlegenen Station mehrere
Mit vs. ohne KI, ein ehrlicher Vergleich
| Kennzahl | Ohne Predictive Maintenance | Mit QAR-basiertem ML-Modell |
|---|---|---|
| Zeitpunkt Leckage-Erkennung | Beim Walkaround oder Daily Check, dort, wo das Flugzeug gerade steht | Risikohinweis vorher, wie viel vorher, zeigt der Back-Test |
| Dichtungstausch | Nach Instandhaltungsprogramm oder nach Leck | Zusätzlich vorgezogen bei hohem Risiko; Intervalle strecken nur mit genehmigter Programmänderung |
| AOG-Risiko durch das Fahrwerk | Unvorhersehbar, Häufigkeit aus eigener Historie | Ein Teil der Fälle rückt in geplante Bodenzeiten, nicht alle |
| Lagerhaltung für Dichtungen | Sicherheitsbestand, oft nicht an jeder Station | Gezielter Bestand dort, wo das Modell Risiko sieht |
| Planung der Bodenzeiten | Reaktiv (Defekt → sofort einbauen) | Proaktiv, soweit die Prognose trägt |
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 eine Einschätzung. Die Gesamtarbeitszeit für Wartung sinkt aber nicht, ein Dichtungstausch dauert geplant so lange wie ungeplant. Der eigentliche Zeitgewinn liegt in der Planung, nicht in der Ausführung. Große Flotten (200+ Flugzeuge) merken das deutlicher als kleine.
Kosteneinsparung, mittel (3/5)
Hier liegt der Hebel, wenn Lecks bei euch tatsächlich Bodenzeit kosten. Ein vermiedener AOG-Tag zählt, aber das Modell vermeidet ihn nur, wenn es das Leck rechtzeitig kommen sieht und ihr dann auch tauscht. Jeder vorgezogene Tausch kostet selbst Arbeit und Bodenzeit, auch bei den Fehlalarmen. Ob es sich rechnet, hängt an der Zahl der Ereignisse, siehe Rechnung unten. Und der billigste Hebel steht davor: Ersatzdichtungen an den Stationen.
Schnelle Umsetzung, mittel (3/5)
6–12 Monate sind realistisch. QAR-Daten (Quick Access Recorder) sind bei großen Verkehrsflugzeugen fast immer vorhanden, Airlines nutzen sie vor allem für ihr Flugdatenmonitoring. 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, mittel (3/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?” Mit einem Dutzend Leckfällen in fünf Jahren ist so ein Back-Test allerdings dünn: Er zeigt, ob das Modell grob funktioniert, nicht wie gut. Deshalb 3 und nicht 4.
Skalierbarkeit, 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, ein verbreitetes Modell dafür ist das Cox Proportional Hazards Model. 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 zeichnet Flugdaten auf, die ein Betreiber leicht auslesen kann, bei großen Verkehrsflugzeugen vor allem für das Flugdatenmonitoring. Welche Parameter er enthält, legt die Konfiguration je Muster und Betreiber fest, typisch sind:
- Vertikale G-Belastung bei jeder Landung
- Sinkgeschwindigkeit (Sink Rate) beim Aufsetzen
- Querkräfte (Crosswind-Komponenten)
- Fahrwerksbezogene Parameter, soweit das Muster sie aufzeichnet
- 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 deutlich mehr, denn bei Metallen wächst der Ermüdungsschaden nach einem Potenzgesetz mit der Last (Wöhlerlinie). Welche Gewichtung für eure Dichtungen passt, ist offen, die schätzt das Modell aus den Daten.
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 ausgelesen und dem Modell übergeben. Das System berechnet die aktualisierten Lastindizes für die drei Federbeine, Bugfahrwerk und die beiden Hauptfahrwerke. Zwei davon zeigen jetzt 68 und 72 Prozent Leckrisiko in den nächsten 1.000 Flugstunden, das dritte 22 Prozent.
Das System markiert die beiden risikohöheren Federbeine für die nächste planbare Bodenzeit, sechs Wochen entfernt. Die Wartungsplanung sieht sofort: „Wir müssen zwei Dichtungssätze bestellen und die Bodenzeit für den Austausch einplanen.” Geplant, bevor irgendwas leckt. Das Flugzeug fliegt weiter, die Sichtprüfungen beim Walkaround bleiben.
Ohne Modell: Das Federbein leckt nach drei Wochen. Ein Techniker sieht es beim Daily Check. Liegt keine Dichtung am Standort, kommt sie per Luftfracht, und das Flugzeug steht einen Tag. Mit Modell kann das trotzdem passieren: 70 Prozent Risiko heißt auch, dass manche markierten Dichtungen ohne Tausch noch lange gehalten hätten und manche unmarkierten lecken.
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 cloudfähige Alternative, als Cloud-Dienst von TRAX oder in eigener Infrastruktur. TRAX positioniert sich als MRO-ERP, eigene KI- oder Predictive-Maintenance-Funktionen sind vom Hersteller nicht belegt. Das Modell baut ihr also selbst und bindet es über Schnittstellen an, etwa aus einer ML-Plattform wie Azure ML oder AWS SageMaker. Nachteil: der deutschsprachige Support ist dünn.
Ramco Aviation Suite , die Lösung der Global Player, mit eingebauten AI/ML-Funktionen für Predictive Maintenance und Komponentenzuverlässigkeit. Nachteil: sehr komplex, lange Einführung, und das ML braucht saubere Historiendaten. Vorteil: Das System bringt KI-Abläufe von Haus aus mit.
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 (lifelines oder scikit-survival) 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): Einzelne kleinere Anbieter bieten White-Label-Lösungen an. Prüf vor allem, ob sie Referenzen aus Part-145- oder CAMO-Umgebungen haben, wie lange sie Support zusagen und ob eure Daten bei euch bleiben. Nachteil: klein, keine Garantie auf zehn Jahre Support. Vorteil: günstiger als Eigenbau.
Wann welcher Ansatz passt
- Große Airline mit AMOS und IT-Team → AMOS mit eigener Anpassung
- Große Airline mit Cloud-Ambition → TRAX mit eigenem Modell, Ramco als Alternative
- 50+ Flugzeuge, mehrere Kundenflotten → Ramco mit eingebautem AI/ML-Modul
- Kleine bis mittlere MRO ohne großes Budget → White-Label-Anbieter mit Luftfahrt-Referenzen
- Kleinst-MRO oder Betrieb der Allgemeinen Luftfahrt → Eigenbau in Python mit Open Source
Datenschutz und Datenhaltung
QAR-Daten enthalten Flugzeug-Betriebsdaten, keine Passagierdaten, aber Seriennummern, Betriebsstunden und Reparaturhistorien sind für Linienfluggesellschaften sensibel. Und sie enthalten etwas Heikleres: wer wie hart gelandet ist.
Flugdaten und Crew:
- Personenbezug: Eine harte Landung lässt sich über Flugnummer und Dienstplan einer Crew zuordnen. Damit sind QAR-Daten personenbezogen. Das Flugdatenmonitoring einer Airline ist nach EU-Luftfahrtrecht nicht strafend angelegt und muss die Datenquelle schützen. Ein Wartungsmodell darf dieses Vertrauen nicht untergraben: Für das Modell reichen Flugzeug, Federbein und Last, Crew-Kennungen entfernt ihr vor der Übergabe. Die Personalvertretung der Crews gehört früh an den Tisch.
- 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 am besten in der EU verarbeiten. AMOS lässt sich in der EU betreiben, TRAX als Cloud-Dienst oder in eurer eigenen Infrastruktur, den Standort legt ihr im Vertrag fest. 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: Wie lange QAR-Rohdaten vorgehalten werden, regeln Betreiber sehr unterschiedlich. Für das Modell braucht ihr mindestens drei Jahre, klärt früh, ob sie noch da sind. 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):
- 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: 1.500–5.000 € pro Monat, also 18.000–60.000 € im Jahr
- Die Lizenz eures MRO-Systems (AMOS, TRAX, Ramco) zahlt ihr ohnehin, sie gehört nicht in diese Rechnung
ROI-Berechnung mit offenen Annahmen:
Flottengröße: 50 Flugzeuge (gemischte B787, A350)
Annahmen, die du durch deine eigenen Zahlen ersetzt:
- 5 Fahrwerkslecks pro Jahr, die ein Flugzeug am Boden halten
- Durchschnittlich 1 Tag AOG pro Ereignis wie in der Szene oben; drei Tage sind der Ausnahmefall an einer entlegenen Station
- AOG-Kosten: 75.000 € pro Tag (Annahme für Langstreckenflugzeuge)
- Das Modell sieht 40 % der Lecks rechtzeitig kommen, und ihr tauscht jedes Mal vorher: 2 vermiedene AOG-Tage, also 2 mal 75.000 € = 150.000 €
- Dagegen die vorgezogenen Tauschaktionen: Kommt auf jeden Treffer ein Fehlalarm, sind es 4 statt 2 Tauschaktionen, je rund 3.000 € für Arbeit, Material und Bodenzeit (Annahme), also 12.000 €
Ertrag pro Jahr: 150.000 € minus 12.000 €, rund 138.000 €
Kosten Jahr 1: 50.000–150.000 € Einrichtung plus 18.000–60.000 € laufend
Netto Jahr 1: zwischen minus 72.000 € und plus 70.000 €
Netto ab Jahr 2: 78.000–120.000 € jährlich
Wichtig: Das rechnet sich, wenn die Annahmen halten. Drei davon wiegen schwer:
- Liegt an jeder Station eine Ersatzdichtung, schrumpft der AOG-Tag auf die Tauschzeit, und mit ihm der Ertrag des Modells. Erst den Bestand prüfen, dann rechnen
- 40 % Trefferquote ist eine Annahme. Ein Concordance-Index aus dem Back-Test sagt, wie gut das Modell Dichtungen nach Risiko sortiert, nicht wie viele Lecks es rechtzeitig findet
- Bei nur zwei Ereignissen im Jahr fängt das Modell rechnerisch 0,8 davon ab. 0,8 mal 75.000 € sind 60.000 €, und das frisst der laufende Betrieb fast ganz auf
Klingt das nach eurem Alltag? Ob sich dieser Use Case bei euch rechnet, klären wir im Erstgespräch: 30 Minuten, kostenlos.
Erstgespräch anfragenDrei 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, und dann hat das Modell Geld gekostet, ohne je einen Tausch auszulösen. Was hilft: Das Modell vor dem Produktivbetrieb gemeinsam mit dem Wartungsteam auf historischen Daten validieren. Zeigt Fälle, in denen das Modell recht hatte. Macht die Vorhersage nicht zur Blackbox, ein Konfidenzwert mit Erklärung (“hohe Last durch drei Landungen über 2,0 G”) wirkt überzeugender als eine nackte Prozentangabe.
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 drei 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 „tauschen, wenn es leckt oder das Intervall erreicht ist” heißt es zusätzlich: „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, die Wartung nach Programm 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 lifelines trainieren. Kreuzvalidierung durchführen. Schwellenwert für die Warnung festlegen. | Concordance-Index unter 0,6 (brauchbar wäre 0,7 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: rund sechs Monate bis zum Produktivbetrieb auf dem ersten Muster, bis zu zwölf Monate für alle Muster. 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: ARINC 717 legt das Aufzeichnungsformat fest, und mit der Parameterbeschreibung des jeweiligen Musters lassen sich die Daten normalisieren. Welcher Parameter wo im Datenrahmen steht, ist allerdings je Muster und Betreiber verschieden. 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 unserem Instandhaltungsprogramm im Griff.”
Möglich. Die Frage ist nicht, ob die Dichtungen sicher getauscht werden, das regelt das Programm. Die Frage ist, wie oft ein Leck zur falschen Zeit an der falschen Station auftaucht. Zähl die Fälle der letzten drei Jahre, dann weißt du, ob es sich lohnt.
„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. Es darf Tauschaktionen vorziehen, aber kein festes Intervall verlängern und keine vorgeschriebene Prüfung ersetzen: Das wäre eine Änderung des genehmigten Instandhaltungsprogramms, und die genehmigt die Behörde, 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 Fahrwerkslecks kosten regelmäßig Bodenzeit (fünf oder mehr Fälle im Jahr)
- Du hast AOG-Erfahrung und kennst die Kosten, eure eigenen Kosten je AOG-Tag liegen der Geschäftsführung vor
- Deine QAR-Daten sind systematisch archiviert, nicht fragmentiert, mindestens 3 Jahre Historie
- Dein Wartungsteam ist datenaffin, nicht jeder Betrieb hat das
- Du willst Tauschaktionen in geplante Bodenzeiten legen 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 20 Flugzeugen oder weniger als fünf Lecks im Jahr, die Bodenzeit kosten. Dann frisst der laufende Betrieb den Ertrag auf, siehe Rechnung. Warte, bis die Flotte wächst, und sorg bis dahin für Ersatzdichtungen an den Stationen.
-
QAR-Daten sind fragmentiert, reichen keine drei Jahre zurück oder sind 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, Station und wie lange das Flugzeug stand. 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? Und stand das Flugzeug wegen des Lecks oder wegen der fehlenden Dichtung?
Das ist die Frage, die über Wirtschaftlichkeit entscheidet. Bei ein bis zwei Ereignissen im Jahr lohnt sich das Modell nicht. Ab etwa fünf im Jahr lohnt die Rechnung, und zuerst der Blick auf den Dichtungsbestand an den Stationen.
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. Lade dafür keine Rohdaten mit Flugnummern oder Crew-Kennungen in einen Chat-Dienst: Beschreib Struktur und Umfang deiner Daten, oder aggregiere vorher auf Flugzeug, Federbein und Landelast.
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- AOG-Kosten Narrowbody: Simple Flying (2024), “How Much Do Aircraft Groundings Cost Airlines & Manufacturers?”; Eways Aviation (2023) “How Much Does It Cost To Have An Aircraft On Ground?”; Branchenrahmen 50.000–150.000 US-Dollar je Tag. Die 75.000 Euro je Tag in der Rechnung sind eine Annahme für Langstreckenflugzeuge.
- Leckfälle je Flotte, Trefferquote des Modells, Kosten je vorgezogenem Tausch: Annahmen für die Rechnung, keine veröffentlichten Branchenwerte. Ersetze sie durch deine eigene Historie.
- Stanton et al. “Data augmentation for predictive maintenance: Synthesising aircraft landing gear datasets” (2024), Engineering Reports, Wiley: Forschung zu ML-basierter Predictive Maintenance für Fahrwerke mit synthetischen Datensätzen.
- MDPI “Quantifying Operational Uncertainty in Landing Gear Fatigue” (2024): Hybrider Physik-Daten-Ansatz zur Restlebensdauer von Fahrwerksstrukturen.
- TRAX eMRO und Ramco Aviation Suite: Funktionsumfang laut unseren Toolseiten, Stand Juli 2026.