Hubschrauber-Hauptgetriebe: Adaptives ML erkennt frühe Schäden ohne starre Grenzwerte

Das echte Ausmaß des Problems

Das Hubschrauber-Hauptgetriebe (MGB, Main Gearbox) ist das sicherheitskritischste mechanische Bauteil eines Hubschraubers. Es überträgt die Motordrehzahl (typisch 6.000–30.000 U/min) in die Rotordrehzahl (240–450 U/min) und versorgt dabei Haupt- und Heckrotorsystem gleichzeitig. Ein kompletter Getriebeausfall ist in den meisten Fällen nicht beherrschbar.

Zwei Unfälle zeigen das Muster:

Am 29. April 2016 stürzte ein Airbus H225 der CHC Helikopter Service nahe Turøy, Norwegen, ab. Alle 13 Insassen kamen ums Leben. Die norwegische Unfalluntersuchungsbehörde AIBN stellte fest, dass ein Ermüdungsbruch in einem Planetenrad der zweiten Stufe im Hauptgetriebe der Auslöser war. Entscheidend: Laut AIBN begann der Riss an einer winzigen Pittingstelle an der Oberfläche und wuchs unter der Oberfläche bis zum Bruch, ohne entdeckt zu werden. Im Getriebeöl fanden sich vorher keine Partikel.

Sieben Jahre zuvor, 2009, starben alle 16 Insassen eines AS332 L2 vor Peterhead, Schottland, ebenfalls nach dem Ermüdungsbruch eines Planetenrads im Hauptgetriebe. Dort hatte es vorher ein Signal gegeben: Im Getriebeöl waren vor dem Absturz Metallpartikel gefunden worden, ohne dass daraus die richtigen Schlüsse gezogen wurden.

Beide Unfälle zeigen zwei verschiedene Grenzen. 2016 gab es kein Signal, das eine Überwachung hätte finden können. 2009 gab es eines, und es wurde nicht als Warnung erkannt. An der zweiten Grenze setzt dieser Anwendungsfall an: Klassische HUMS mit fixen Schwellwerten erkennen Abweichungen von einem Flottenmittelwert, aber nicht die individuelle Degradation einer spezifischen Maschine, und wer zu viele Alarme bekommt, übersieht den echten.

Die operative Folge in der Praxis: Viele HUMS-Alarme enden mit „kein Befund”. Eine belastbare Branchenquote dafür haben wir nicht gefunden, deine eigene Alarmhistorie liefert sie an einem Nachmittag (siehe unten). Das Ergebnis ist ein Cry-wolf-Effekt: Techniker lernen systematisch, HUMS-Alarme zu ignorieren, genau dann, wenn einer davon real ist.

Die Größenordnungen:

• Ein Hauptgetriebetausch kostet je nach Muster einen sechs- bis siebenstelligen Betrag, öffentliche Listenpreise gibt es nicht
• Ein ausgefallener Hubschrauber kostet einen Offshore-Betreiber Ersatzmaschine, Crew und womöglich Vertragsstrafen, wie viel, steht in euren Verträgen
• Ein Absturz durch Getriebeversagen kostet Menschenleben. Nach Turøy standen H225-Flotten monatelang am Boden

Mit vs. ohne KI, ein ehrlicher Vergleich

Wichtiger Vorbehalt: Adaptives ML ist kein Allheilmittel gegen Getriebeversagen. Die Unfallursache von Turøy (ein Riss, der unter der Oberfläche wuchs, ohne Partikel im Öl) wäre auch mit ML-basiertem HUMS nicht zuverlässig erkennbar gewesen, das Signal existierte schlicht nicht. Der Mehrwert liegt in der früheren Erkennung von Abnutzungsmustern, die ein Signal erzeugen, und in weniger Fehlalarmen, damit ein echtes Signal wie 2009 nicht im Rauschen untergeht.

Einschätzung auf einen Blick

Zeitersparnis, niedrig (2/5) Der direkte Zeitgewinn ist gering: Kein Wartungsschritt entfällt, keine Checkliste kürzer. Was sich verändert, ist die Qualität der Arbeitszeit von Tobias und seinen Kollegen, weniger “reviewed, no action”-Klicken auf Alarme, die niemand ernst nimmt, dafür konzentriertere Aufmerksamkeit auf die wenigen Signale mit hohem Konfidenzscore. Verglichen mit anderen Anwendungsfällen in dieser Kategorie, etwa der Wartungsdokumentation per KI, ist der Zeiteffekt moderat.

Kosteneinsparung, niedrig (2/5) Ein vermiedener Getriebeschaden ist viel Geld wert, als Erwartungswert aber klein. Getriebebefunde, die ohne Eingriff zum Ausfall geführt hätten, sind selten, und auch ein früh erkanntes Getriebe wird getauscht oder überholt: Gespart wird nur die Differenz aus Folgeschäden und ungeplanter Standzeit. Dazu muss das System den Schaden tatsächlich früher erkennen, und die Organisation muss auf diesen Alarm anders reagieren als auf die bisherigen Fehlalarme. Die Rechnung unten geht über vermiedene Kosten selten auf. Der tragende Grund für dieses System ist Sicherheit.

Schnelle Umsetzung, sehr niedrig (1/5) Das ist einer der aufwendigsten Einstiege in dieser Kategorie. Eine realistische Umsetzung umfasst: Sensor-Nachrüstung mit Ergänzender Musterzulassung (STC), eine Baseline-Lernphase von 50–100 Flugstunden pro Maschine, Abstimmung mit der Behörde, sobald das System Instandhaltungsaufgaben beeinflusst, und Validierung im betrieblichen Alltag. Gesamtzeitraum: 12–18 Monate im optimistischen Fall.

ROI-Sicherheit, niedrig (2/5) Getriebeausfälle sind selten. Sehr selten. Ein Betreiber mit zehn bis fünfzehn Hubschraubern sieht vielleicht einen Getriebebefund im Jahr, und einen Schaden, der ohne Eingriff zum Ausfall geführt hätte, sehr viel seltener. Das bedeutet: Du kannst nicht im eigenen Betrieb statistisch belegen, dass das System funktioniert. Du verlässt dich auf externe Studien, Flottenvergleiche und das Vertrauen in den Algorithmus. Das ist in einem regulierten Luftfahrtumfeld ein erhebliches Akzeptanzproblem.

Skalierbarkeit, mittel (3/5) Einmal entwickelt, skaliert ein adaptives HUMS gut innerhalb einer Flotte desselben Musters. Eine H145-Flotte mit zehn Maschinen profitiert sofort von einem validierten Modell. Die Übertragung auf einen anderen Mustertyp, etwa von der H145 auf eine AS332, ist hingegen kein einfacher “Export-Import”: unterschiedliche Getriebearchitektur, andere Schwingungscharakteristik, neues STC erforderlich.

Richtwerte, stark abhängig von Flottentyp, Betriebsumfeld (Offshore, HEMS, SAR) und bestehendem HUMS-Equipment.

Was das System konkret macht

Das Grundprinzip unterscheidet sich fundamental vom klassischen HUMS. Klassisch: Messwert X überschreitet fixen Grenzwert Y → Alarm. Adaptiv: Messwert X weicht von der persönlichen Baseline dieser Maschine ab → Alarm.

Der technische Ansatz: Machine Learning, konkret Autoencoder-Modelle auf Vibrationszeitreihendaten.

Schritt 1, Baseline lernen: In den ersten 50–100 Flugstunden nach Installation lernt das System die individuelle Vibrationssignatur des Getriebes. Jede Getriebe-Seriennummer hat ihre eigene Mikrosignatur, durch Fertigungstoleranzen, Einlaufverhalten, Schmierstoffadditive, spezifische Rotorkonfiguration. Das Modell lernt diese Signatur im gesunden Zustand.

Schritt 2, Spektralanalyse: Vibrationen werden nicht als Gesamtpegel analysiert, sondern im Frequenzbereich. Das Spektrum wird in Merkmale zerlegt: Zahneingriffsfrequenz (GMFF, Gear Mesh Fundamental Frequency), ihre Harmonischen, Seitenfrequenzen und das sogenannte Narrow-Band-Energieprofil. Diese Merkmale charakterisieren spezifische Schadensformen: Zahnoberflächen-Pitting, Lagerschalen-Verschleiß, Planetenträger-Asymmetrie.

Schritt 3, Anomalie-Score: Der Autoencoder versucht, das aktuelle Spektrum aus der gelernten Baseline zu rekonstruieren. Je schlechter die Rekonstruktion gelingt, desto größer die Abweichung. Dieser Rekonstruktionsfehler wird als Anomalie-Score normiert. Nicht ein einziger Ausschlag, sondern ein kontinuierlicher Trend über mehrere Flüge hinweg löst die Warnung aus.

Was das System nicht kann: Es erkennt keine Ermüdungsrisse unter der Oberfläche, die kein Vibrationssignal erzeugen. Der Unfall von Turøy (2016) wäre mit diesem Ansatz nicht verhindert worden, ein Riss, der unter der Oberfläche wächst, erzeugt bis kurz vor dem Versagen schlicht kein erkennbares Signal. Diese Grenze muss man kennen, bevor man in das System investiert.

Was ihr hardware-seitig braucht

Das ist das meistunterschätzte Kapitel eines HUMS-Projekts. Die Software ist lösbar. Die Hardware ist der Engpass.

Piezoelektrische Beschleunigungssensoren: Für Getriebevibrationsanalyse auf Hubschrauber-Hauptgetrieben werden typisch 3–6 industriell zugelassene Beschleunigungssensoren (Piezo-ICP, IEPE-Typ) mit einem Messbereich von ±50–500 g und einer Bandbreite, die den analysierten Frequenzbereich abdeckt, benötigt. Kritisch ist die Montage: direkt auf dem Getriebegehäuse, vibrationsentkoppelt vom Kabinenrahmen, mit zertifiziertem Klebstoff oder Gewindebefestigung. Jede nicht-standardisierte Befestigung verändert die Frequenzcharakteristik und macht die Baseline unbrauchbar.

Datenerfassungsrate: Für Frequenzanalysen bis 20 kHz braucht es mindestens gut das Doppelte als Abtastrate, üblich sind 51.200 Samples/Sekunde. Ältere HUMS-Installationen tasten oft deutlich langsamer ab, zu wenig für die feinere Spektralanalyse. Prüf die Rate eurer Bestandshardware, bevor ihr plant. Das ist oft der Grund, warum das ML-Modell mit Bestandshardware nicht funktioniert.

Azimut-Referenz (Tachometer): Für die Separation von Zahnradfrequenzen braucht das System eine genaue Winkelreferenz, entweder klassisch über optische Tachometer oder über “Tach-from-vibration”-Algorithmen wie bei GPMS Foresight MX .

Zertifizierung der Hardware: Jede Sensorinstallation ist eine Änderung am Luftfahrzeug. Sie braucht genehmigte Konstruktionsdaten, bei einer Nachrüstung meist ein STC, und wird von einem Instandhaltungsbetrieb nach diesen Daten eingebaut und von freigabeberechtigtem Personal freigegeben.

Rechenkapazität an Bord: Das ML-Modell läuft entweder on-board (Edge-Computing-Box im Hubschrauber) oder in der Bodenstation nach Datentransfer. On-board-Verarbeitung erlaubt Echtzeit-Alerts; Ground-Station-Auswertung erlaubt komplexere Modelle, aber nur nach Flug. Für SAR- und Offshore-Betrieb ist Ground-Station-Auswertung der Standard, Echtzeit-Alarmierung wäre für Missions-Sicherheit kritischer, aber aufwändiger zu zertifizieren.

Zertifizierungspfad und EASA-Regularien

Das ist das Kapitel, das die meisten Projekte unterschätzen, und das viele zum Stillstand bringt.

EASA-Regelwerk: Die Bauvorschriften für Hubschrauber sind CS-27 (kleine) und CS-29 (große Drehflügler). Wer Sensorik oder Rechner nachrüstet, ändert das Luftfahrzeug: Der Musterhalter macht das als Änderung seiner Musterzulassung, jeder andere Entwicklungsbetrieb mit Design Organisation Approval (DOA) als Ergänzende Musterzulassung (Supplemental Type Certificate, STC).

Was das konkret bedeutet: Neue Sensoren an Bord brauchen eine genehmigte Änderung. Ein Modell, das am Boden vorhandene HUMS-Daten zusätzlich auswertet, ist dagegen keine Änderung am Luftfahrzeug, solange es nur Hinweise gibt und keine vorgeschriebene Prüfung ersetzt. Soll es das tun, etwa Prüfintervalle verlängern, muss das ins genehmigte Instandhaltungsprogramm, und die Behörde verlangt Nachweise zu Alarmschwellen, Datenintegrität und Trainingslogik. Die EASA hat 2012 in EASA_REP_RESEA_2012_6 Forschungsgrundlagen für Vibration Health Monitoring gelegt, eine detaillierte AMC (Acceptable Means of Compliance) für ML-basierte HUMS fehlt noch.

Praktische Wege:

• STC über OEM oder HUMS-Anbieter: Der einfachste Weg. Anbieter wie GPMS Foresight MX haben STCs bereits entwickelt. Du übernimmst das STC, keine eigene Zertifizierungsarbeit, aber du bist an den Funktionsumfang des Anbieters gebunden. Ein FAA-STC gilt nicht automatisch in der EU, prüf den EASA-Stand für dein Muster und deinen Eintragungsstaat.
• Eigene STC-Entwicklung: Für Betreiber mit eigenen ML-Entwicklungskapazitäten und spezifischen Flottenanforderungen, zusammen mit einem Entwicklungsbetrieb mit DOA. Für ein noch nicht abgedecktes Muster nennt GPMS 6 bis 18 Monate, als Eigenprojekt ohne STC-Erfahrung eher länger. Öffentliche Kostenangaben gibt es nicht.
• Auswertung am Boden auf vorhandenen Daten: Kein STC nötig, solange keine neue Hardware an Bord kommt und das Modell keine vorgeschriebene Prüfung ersetzt. Der schnellste Einstieg, aber begrenzt durch die Abtastrate der vorhandenen Sensorik.

EASA und ML: Die EASA hat 2021 ein erstes Konzeptpapier zu Machine Learning veröffentlicht und im März 2024 die zweite Fassung (Guidance for Level 1&2 machine learning applications). Level 1 unterstützt den Menschen, Level 2 ist Mensch-KI-Teaming, bei dem die KI unter menschlicher Aufsicht selbst entscheidet. Ein HUMS-Hinweis, den ein Techniker bewertet, ist Level 1. Auch dafür erwartet EASA Transparenz der Modelllogik, Robustheitsnachweise und menschliche Aufsicht. Explainability ist kein akademisches Feature, sondern eine regulatorische Erwartung.

Das Labeling-Problem: Wer validiert erkannte Anomalien?

Jedes überwachte Lernsystem braucht Ground Truth, eine Referenz, die sagt: “Dieses Signal war wirklich ein Defekt, jenes nicht.” Im Hubschrauber-Kontext ist das komplizierter als in fast jeder anderen Industrie.

Das Problem der seltenen Ereignisse: Eine Betreiberflotte von zehn bis fünfzehn Maschinen sieht vielleicht ein bis zwei echte Getriebebefunde im Jahr (dieselbe Annahme wie in der Rechnung unten), und davon zeigt nicht jeder ein erkennbares Vibrationsmuster vor der Entdeckung. Das bedeutet: Das ML-Modell trainiert auf einem extrem unausgewogenen Datensatz (tausende “normale” Flüge, ein bis zwei “defekte” Fälle pro Jahr). Oversampling und Synthetic Minority Oversampling (SMOTE) helfen, lösen das Grundproblem aber nicht.

Wer validiert?: Die Interpretation eines HUMS-Anomalie-Scores für ein Hubschrauber-Hauptgetriebe erfordert freigabeberechtigtes Personal nach Part-66 mit Musterberechtigung auf dem spezifischen Typ, für das Getriebe selbst Kategorie B1 (Mechanik), für die Sensorik auch B2. Generische ML-Ingenieure ohne Luftfahrterfahrung können die Ausgabe des Modells nicht sinnvoll interpretieren, und die falsche Interpretation eines echten Signals ist gefährlicher als der Fehlalarm.

Ground-Truth-Labeling kostet: Pro Befund-Ereignis braucht man: HUMS-Datenexport, Korrelation mit Instandhaltungsaufzeichnung, physische Inspektion des Getriebes (oft Demontage erforderlich), Labeling durch qualifizierte Person. Bei kleinen Flotten und seltenen Ereignissen kann dieser Prozess die Datenqualität fundamental begrenzen. Wer kein Budget für diesen Prozess hat, wird ein unvalidiertes Modell betreiben, das ist in der Luftfahrt keine Option.

Externe Datenpools: Einige OEMs und HUMS-Anbieter aggregieren anonymisierte Flottendaten, um die Ground-Truth-Basis zu verbreitern. Das ist der Hauptvorteil etablierter HUMS-Plattformen gegenüber proprietären Einzelentwicklungen, sie haben mehr labeled Events für das Training.

Konkrete Werkzeuge, was wann passt

Vier Klassen von Werkzeugen spielen zusammen:

Zertifiziertes HUMS-System (Pflicht)

GPMS Foresight MX , der derzeit direkteste Weg für Betreiber von H125, H135, H145, Bell 407/429 und AS332. FAA-STC vorhanden, die EASA-Approvals wurden Ende 2025 erweitert, decken aber nicht jeden FAA-Typ ab. Das System enthält eigene Anomalieerkennung und RUL-Prognose (Remaining Useful Life) und läuft auf Cloud-Infrastruktur in den USA. Die individuelle Baseline-Lernphase braucht 50–100 Flugstunden. Preis: Abonnement pro Luftfahrzeug mit Hardware-Kit und Software, öffentliche Listenpreise gibt es nicht. Der Einbau nach STC kommt extra.

Airbus M’ARMS (Modular Aircraft Recording Monitoring System) ist das herstellereigene Überwachungssystem von Airbus Helicopters. Für welche Muster und mit welchem Funktionsumfang, klärt ihr mit dem Hersteller. Weniger transparent als Drittanbieter, aber für Airbus-Flotten regulatorisch der einfachste Weg.

Modellentwicklung (wenn Eigenbau geplant)

MATLAB Aerospace Toolbox ist der Industriestandard für Signalanalyse und Algorithmenentwicklung in Luftfahrtprojekten. Die Signal Processing Toolbox und Predictive Maintenance Toolbox decken FFT-Analyse, Cepstrum-Analyse und Modelltraining ab, in einer Umgebung, die Ingenieure in der Branche kennen. GPMS selbst hat Foresight MX mit MATLAB entwickelt (laut MathWorks-Fallstudie). Lizenz im deutschen MathWorks-Store: MATLAB 2.410 Euro im Jahr, die Aerospace Toolbox als Add-on 1.770 Euro im Jahr zusätzlich.

PyTorch ist die bevorzugte Open-Source-Alternative für Autoencoder-Entwicklung, kostenlos, flexibel, mit großer Community. Kein zertifizierter Deployment-Pfad für Luftfahrt-Primärsysteme; geeignet für Forschung, Algorithmenetwicklung und das Training von Modellen, die dann in validierter Umgebung eingesetzt werden.

Datenhaltung und Zeitreihen

InfluxDB , Open-Source-Zeitreihendatenbank für hochfrequente Vibrationsdaten on-premise. Write-Performance für HUMS-typische Datensätze (Zehntausende Samples je Sekunde und Kanal) ist stark; on-premise-Betrieb ohne Cloud-Datenabfluss ist für regulierte Luftfahrtoperatoren relevant.

Visualisierung und Reporting

Grafana , Open-Source-Dashboarding für Zeitreihendaten. Direktanbindung an InfluxDB. Erlaubt Erstellung techniker-orientierter Dashboards für Vibrationstrends und Anomalie-Scores, ohne proprietäres Dashboard des HUMS-Anbieters.

Wann welcher Ansatz:

• Airbus-Flotte, einfachste Zertifizierung → M’ARMS (OEM)
• Gemischte Flotte bis H145, marktgängige HUMS → GPMS Foresight MX
• Eigene ML-Entwicklung, Forschungsumgebung → MATLAB + PyTorch
• Datenhaltung on-premise → InfluxDB + Grafana

Datenschutz und Datenhaltung

Vibrationsdaten selbst sind Maschinensignale. Sobald sie mit Flugdaten und Dienstplänen verknüpft sind, lassen sie sich aber einer Crew zuordnen, und viele HUMS zeichnen auch Flugdaten auf, Foresight MX etwa zusätzlich ein Flugdatenmonitoring. Datenschutz und Datenhaltung haben deshalb erhebliche Bedeutung.

Operationelle Sensibilität: Vibrationsprofile und Getriebe-Health-Daten erlauben Rückschlüsse auf den Zustand der Flotte, für Leasinggesellschaften, Versicherungen, Unfalluntersuchungsbehörden und Konkurrenten. HUMS-Daten aus dem Unfallvorfeld sind regelmäßig Bestandteil von Unfalluntersuchungen (BFU in Deutschland, AIBN in Norwegen, AAIB in Großbritannien). Die Frage, wer Zugriff auf diese Daten hat, ist nicht nur eine DSGVO-Frage, sondern auch eine betriebliche und juristische.

Cloud vs. on-premise: GPMS Foresight MX speichert Daten auf US-Cloud-Infrastruktur, eine EU-Datenresidenz wirbt GPMS nicht. Wer sie braucht, muss sie vertraglich verhandeln, zugesagt ist sie nicht. Mindestens AVV und Standardvertragsklauseln einfordern und Flugdatenfelder mit Personenbezug minimieren. Eine on-premise-Alternative mit InfluxDB + eigener ML-Pipeline gibt volle Datensouveränität, erfordert aber entsprechende Infrastruktur und Personal.

Anforderungen an Datenintegrität: Jede behördliche Anerkennung ML-basierter HUMS setzt Datenintegrität und Rückverfolgbarkeit voraus, Trainingsdaten müssen vollständig dokumentiert sein. Datenlücken, fehlerhafte Kalibrierung oder nicht dokumentierte Sensorwechsel invalidieren retroaktiv die Baseline und können regulatorische Probleme erzeugen.

Personenbezug: HUMS-Daten enthalten oft auch Flugdaten (Flugtrajektorie, Steuereingaben, Betriebspunkte), die sich über den Dienstplan einer Crew zuordnen lassen. Damit sind sie personenbezogen, und Flugdaten mit Crewbezug sind im Flugdatenmonitoring besonders geschützt. Verwendet ein ML-Modell sie als Kontextmerkmal, muss die Nutzung mit der Personalvertretung und der Rechtsberatung abgestimmt sein. Für die Getriebeüberwachung reichen meist Maschine, Flugphase und Last ohne Crew-Kennung.

Was es kostet, realistisch gerechnet

Einmalige Einrichtungskosten

• Bei eigener Sensorik: Hardware (Sensoren, Edge-Box, Kabel, Montage) nach unserer Einschätzung 15.000–40.000 € pro Luftfahrzeug. Bei GPMS ist das Hardware-Kit im Abo enthalten, der Einbau nach STC durch einen Part-145-Betrieb nicht
• Zertifizierung / STC (über Anbieter wie GPMS): bei vorhandenem STC keine eigene Entwicklung; eigene STC-Entwicklung: ein Projekt über viele Monate, öffentliche Kostenangaben gibt es nicht
• Baseline-Lernphase: Keine Zusatzkosten, normaler Flugbetrieb in den ersten 50–100 Flugstunden
• Integration in MRO-System: 20.000–80.000 € (je nach bestehendem System und API-Verfügbarkeit)

Laufende Kosten (monatlich)

• GPMS Foresight MX: Abonnement pro Hubschrauber, Preis nur auf Anfrage
• Eigene ML-Infrastruktur (InfluxDB + MATLAB + Entwicklerstunden): 3.000–12.000 €/Monat je nach Team
• Validierungsaufwand durch freigabeberechtigtes Fachpersonal: 500–1.500 €/Monat je nach Häufigkeit der Befunde

Wann rechnet sich das?

Rechne rückwärts, weil der Abo-Preis nur auf Anfrage kommt. Szenario: Flotte mit zehn H145, Betrieb über fünf Jahre, also 50 Maschinenjahre. Pro Jahr 0,5–1,5 HUMS-relevante Getriebebefunde (unsere Annahme). Davon einer in fünf Jahren, den adaptives ML drei Wochen früher erkennt als klassisches HUMS. Das Getriebe wird trotzdem getauscht oder überholt, gespart werden nur Folgeschäden und ungeplante Standzeit. Setzen wir diese Differenz mit 200.000 € an, trägt der eine Fall 200.000 geteilt durch 50, also 4.000 € je Maschine und Jahr, für alles zusammen. Davon gehen die Integration (20.000–80.000 €, also 400–1.600 € je Maschinenjahr) und die Validierung durch Fachpersonal (500–1.500 € im Monat, über fünf Jahre 600–1.800 € je Maschinenjahr) schon ab. Für das Abo bleiben 600 bis 3.000 € je Maschine und Jahr. Liegt euer Angebot darüber, rechnet sich das System über vermiedene Kosten nicht.

Günstigeres Szenario, Offshore-Betreiber mit 15 Maschinen und hoher Auslastung: zwei bis drei frühe Erkennungen in fünf Jahren zu je 200.000 €, also 400.000 bis 600.000 €, verteilt auf 75 Maschinenjahre: 5.300 bis 8.000 € je Maschine und Jahr. Auch das trägt ein Abo nur, wenn es deutlich darunter bleibt. Die volle Summe eines Getriebetauschs gehört nicht in diese Rechnung, weil ein früh erkannter Schaden den Tausch nicht erspart. Der tragende Grund für dieses System ist Sicherheit, nicht Kosten. Das ist ein legitimer Grund, er gehört nur so ins Budgetgespräch.

Wie du den Nutzen tatsächlich misst: Nicht einfach. “HUMS hat Defekt Y erkannt” ist kein Beweis dafür, dass klassisches HUMS ihn nicht auch irgendwann erkannt hätte. Seriöse Operatoren führen Back-Testing durch: Historische HUMS-Rohdaten aus Perioden mit bekannten Defekten werden durch den neuen Algorithmus geleitet und auf Früherkennungspotenzial überprüft. Das ist die einzige valide Methode.

Typische Einstiegsfehler

1. Hardware-Anforderungen unterschätzen. Das häufigste Scheitern in frühen Projekten: vorhandene HUMS-Hardware wurde als “kompatibel” angenommen, ist es aber nicht. Eine niedrige Abtastrate reicht für klassische HUMS-Alarme, nicht für die Spektral-Features moderner ML-Modelle. Wer Hardware-Kosten aus der Planung streicht, weil “HUMS läuft schon”, startet mit falschen Annahmen.

2. Die Zulassung als Formalität behandeln. Das Modell ist fertig, die Sensordaten stimmen, die ersten Ergebnisse sind vielversprechend, und jetzt beginnt der eigentliche Prozess: das STC für neue Sensorik und die Abstimmung mit der Behörde, sobald das System Instandhaltungsaufgaben beeinflussen soll. Folge: Monate Stillstand, in denen ein technisch funktionierendes System nicht eingesetzt werden darf. Die EASA-Leitlinien erwarten für ML-Systeme Nachweise zu Erklärbarkeit, Robustheit unter Extrembedingungen und vollständige Trainingsdaten-Dokumentation, alles Dinge, die im Nachgang teuer nachgebessert werden müssen. Was hilft: Die Abstimmung mit Behörde und Entwicklungsbetrieb in Monat 1 beginnen, nicht nach dem ersten Prototyp. Den STC-Anbieter (z. B. GPMS) von Anfang an als regulatorischen Partner einbinden, nicht nur als Softwarelieferant.

3. Das Cry-wolf-Problem nicht lösen, sondern verlagern. Wenn das neue System immer noch jeden fünften Alarm ohne Befund erzeugt (statt vorher der Mehrheit), ist das objektiv besser, aber nicht gut genug, um das Verhalten von Technikern zu verändern. Techniker, die gelernt haben, Alarme zu ignorieren, brauchen eine aktiv gestaltete Rehabilitation: strukturierte Übergangssessionen, in denen Alarme gemeinsam bewertet werden, und nachweisliche Erfolge, die zeigen, dass das System besser ist.

4. Das Modell nach der Einführung sich selbst überlassen. Ein adaptives Modell, das einmal trainiert und dann nicht mehr gepflegt wird, driftet. Nach sechs bis zwölf Monaten hat sich das Getriebe technisch weiterentwickelt, durch Wartungsmaßnahmen, Schmierstoffwechsel, neue Ersatzteile. Wer definiert, wann die Baseline neu gelernt werden muss? Wer überwacht, ob das Modell nach einem Bauteilwechsel noch sinnvolle Ausgaben macht? Ohne eine benannte Person und einen Prozess ist das System nach 18 Monaten nicht besser als ein Kalenderalarm.

5. Den statistischen Validierungsbedarf ignorieren. Zwei bis drei Früherkennnungen reichen nicht für statistischen Nachweis. Wer das System intern “bewerten” will, braucht entweder Daten aus sehr vielen Flugstunden über viele Betreiber und Jahre oder eine Kooperation mit dem HUMS-Anbieter, der Flottendaten aggregiert. Ohne valide Datenbasis ist jede positive Evaluierung anekdotisch, und wird bei einem Unfall regulatorisch kein Gewicht haben.

Was mit der Einführung wirklich passiert, und was nicht

Technisch funktioniert das System oft schneller als erwartet. Das Schwierige ist nicht der Algorithmus. Es sind die Menschen und die Organisation darum herum.

Die Techniker-Skepsis ist berechtigt. Tobias aus der Einstiegsgeschichte ist kein schlechter Analyst. Er hat gelernt, HUMS-Alarmen nicht zu trauen, weil die Basis-Rate für “echter Befund gegeben Alarm” nach Jahren mit klassischen HUMS extrem niedrig war. Ein neues System, das mehr verspricht, muss diese Basis-Rate tatsächlich verbessern und das nachweisbar kommunizieren. Das passiert nicht durch Präsentationen, sondern durch Ergebnisse, und die brauchen Zeit.

Das Piloten-Maintenance-Gap ist real. Piloten wissen, wenn ihr Hubschrauber “anders klingt”. Dieses implizite Wissen ist wertvoller als jeder Sensor, wenn es dokumentiert wird. In der Praxis fließt es selten in die HUMS-Analyse ein. Strukturierte Rückmeldeprozesse für Piloten (15-Sekunden-Klick-Protokoll nach dem Flug: “alles normal / ungewöhnlich / kommentieren”) verbessern die Ground Truth erheblich. Kein System implementiert das automatisch.

Maintenance-Organisationen haben kein ML-Personal. Erwarte nicht, dass deine Wartungsabteilung die Python-Notebooks versteht. Erwarte, dass die Plattform des Anbieters eine Oberfläche liefert, die Techniker ohne ML-Hintergrund nutzen können. Wenn das nicht der Fall ist, brauchst du eine eigene Schnittstelle, das ist Entwicklungsaufwand.

Was konkret hilft:

• Einen erfahrenen Part-66-Techniker mit Musterberechtigung von Anfang an als technischen Champion einbinden, nicht als Reviewer am Ende, sondern als Mitgestalter der Alert-Logik
• Die ersten drei Monate als “learning mode” deklarieren: Alarme werden protokolliert, aber nicht als Arbeitsanweisung behandelt, erst das Verständnis aufbauen, dann den operationellen Einsatz beginnen
• Eine wöchentliche “Case Review”-Runde einführen: Alle Alarme der Woche, Befund oder kein Befund, Muster analysieren, das sind die Sessions, in denen das Team lernt, dem System zu vertrauen oder gezielt zu hinterfragen

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Unser HUMS funktioniert bereits, warum noch mehr Komplexität?” Klassisches HUMS funktioniert im Sinne von “es ist zertifiziert und erzeugt Alarme”. Ob diese Alarme tatsächlich zu früherer Erkennung von Defekten führen, ist eine andere Frage. Wer seine HUMS-Alarm-Historie der letzten drei Jahre auswertet und ermittelt, wie viele Alarme echte Befunde ergaben, wird die Antwort kennen. Wenn die Quote unter 30 Prozent liegt, ist die Grundfrage berechtigt.

“Wir können einen Absturz nicht statistisch rechtfertigen, wir brauchen zero risk.” Zero risk gibt es nicht, auch klassisches HUMS erreicht das nicht, wie Turøy und Peterhead gezeigt haben. Die Frage ist nicht “0 vs. 1 Risiko”, sondern “welches System reduziert das Risiko am effektivsten und ist regulatorisch vertretbar”. Adaptives ML ist keine Magic-Box gegen alle Ausfallmoden, aber es kann Fehlalarme reduzieren und die Früherkennung bei Abnutzungsmustern mit Vibrationssignal verbessern. Ob es das bei euch tut, zeigt der Back-Test.

“Das ist zu teuer für unsere kleine Flotte.” Für Flotten unter fünf Maschinen mit einem Mustertyp ist das wahrscheinlich wahr. Die Fixkosten der Baseline-Lernphase und der Zulassung verteilen sich nicht sinnvoll auf wenige Maschinen. Ab acht bis zehn Hubschraubern desselben Musters, typisch für Offshore, SAR oder HEMS-Konsortien, verteilen sie sich besser, aber auch dort trägt die Rechnung über vermiedene Kosten allein selten, siehe oben. Der ehrliche Vergleich ist nicht “Abo gegen verhinderten Schaden”, sondern “was ist uns das zusätzliche Sicherheitsnetz wert”.

“EASA wird ML in Safety-Critical-Systemen nie zulassen.” Das stimmt nicht mehr. EASA hat 2021 und 2024 Konzeptpapiere für ML-Anwendungen in der Luftfahrt veröffentlicht und im November 2025 mit NPA 2025-07 konkrete Anforderungen an vertrauenswürdige KI vorgeschlagen. Der Weg ist regulatorisch offen, er ist nur zeitaufwändig und verlangt Transparenz der Modelle.

Woran du merkst, dass das zu dir passt

• Deine Flotte hat mehr als acht Hubschrauber desselben Mustertyps, für den ein STC für das gewählte HUMS bereits vorliegt
• Du arbeitest in einem Hochrisikoumfeld (Offshore Oil & Gas, SAR, Rettungsflüge), nicht für reine Charter- oder Touristikoperationen
• Dein HUMS-Team verfügt über mindestens eine Person mit Part-66-Lizenz (B1) und Musterberechtigung auf dem eigenen Mustertyp, sonst fehlt die Interpretationskompetenz
• Deine HUMS-Alarm-Befundquote liegt nachweislich unter 30 Prozent, das zeigt, dass der Cry-wolf-Effekt bereits eingetreten ist
• Du hast einen aktiven Part-145-Betrieb, der die Hardware-Installation und laufende Kalibrierung übernehmen kann

Drei harte Ausschlusskriterien:

1. Flotte unter fünf Hubschraubern desselben Mustertyps. Die Baseline-Lernphase und die Zulassungskosten verteilen sich nicht sinnvoll. Für Kleinbetreiber ist klassisches HUMS mit konsequenter manueller Auswertung der richtige Weg.

2. Kein EASA-STC für die nötige Sensorik am eigenen Mustertyp und kein Budget für Eigenzertifizierung. Ohne STC darf keine neue Sensorik an Bord. Eine Bodenauswertung vorhandener HUMS-Daten bleibt möglich, ist aber durch deren Abtastrate begrenzt. Eine eigene STC-Entwicklung ist ein Projekt über viele Monate und außerhalb der Kapazität der meisten kleinen Betreiber.

3. Keine qualifizierte Fachperson für HUMS-Dateninterpretation im Team. Ein HUMS-System ohne eine Person mit Part-66-Lizenz und Musterberechtigung, die die Ausgaben interpretiert, ist ein System, das niemand ernst nimmt. Die Software allein trifft keine Wartungsentscheidungen, das bleibt menschliche Verantwortung. Wer diese Personalkompetenz nicht hat oder sicherstellen kann, wird mit dem System nichts anfangen.

Das kannst du heute noch tun

Fang nicht mit dem ML-Modell an. Fang mit deinen eigenen HUMS-Daten an.

Zieh die Alarm-Historien der letzten 24 Monate aus deinem bestehenden HUMS-System und berechne die Befundquote: Wie viele Alarme hatten einen tatsächlichen Wartungsbefund? Wie viele waren “reviewed, no action”? Diese Zahl ist dein Ausgangspunkt für jedes Gespräch mit HUMS-Anbietern und die ehrlichste Messung dafür, wie groß dein Problem mit dem Cry-wolf-Effekt tatsächlich ist.

Wenn du noch keinen Zugang zu HUMS-Rohdaten oder ein strukturiertes Reporting-Tool hast, hilft der folgende Prompt als Ausgangspunkt für eine erste Analyse. Ersetz vorher die Kennzeichen durch Flottennummern und lösch Namen aus den Techniker-Notizen, bevor die Liste in einen Chat-Dienst geht.

Quellen & Methodik

• AIBN-Unfallbericht H225 Turøy 2016: Accident Investigation Board Norway (AIBN), „Rapport om luftfartsulykke, Airbus Helicopters H225, LN-OJF, Turøy, Hordaland, 29. april 2016” (2018). Betreiber CHC Helikopter Service. Kernbefund: Ermüdungsbruch eines Planetenrads der zweiten Stufe im Hauptgetriebe, der Riss begann an einer Pittingstelle an der Oberfläche und wuchs unentdeckt unter der Oberfläche.
• AAIB-Unfallbericht AS332 L2 Peterhead 2009: Air Accidents Investigation Branch (AAIB), „Report on the accident to Aerospatiale (Eurocopter) AS332 L2, G-REDL, 2 nm North of the Cormorant Alpha platform, North Sea” (2011). Anders als 2016 waren vor dem Absturz Partikel im Getriebeöl gefunden worden.
• EASA Research Report 2012_6: EASA, „Vibration Health or Alternative Monitoring Technologies for Helicopters” (EASA_REP_RESEA_2012_6, 2012). Wissenschaftliche Grundlage für VHM-Anforderungen in Europa.
• EASA AI Concept Paper Issue 2: EASA, „Artificial Intelligence (AI) Concept Paper Issue 2: Guidance for Level 1&2 machine learning applications” (6. März 2024), Nachfolger der ersten Fassung für Level-1-Anwendungen von 2021. Regulatorischer Rahmen für ML-basierte Alarmsysteme.
• GPMS Foresight MX Fallstudie: MathWorks, „GPMS Streamlines Predictive Maintenance for Helicopters” (mathworks.com). Entwicklungsansatz und MATLAB-Einsatz bei GPMS.
• GPMS Preise und Zulassungsstand: gpms-vt.com, keine öffentlichen Listenpreise; FAA-STC und EASA-Stand laut unserer Toolseite zu Foresight MX.
• MATLAB-Preise: Deutscher MathWorks-Store, laut unserer Toolseite zur MATLAB Aerospace Toolbox (Stand Juli 2026).
• SKYbrary VHM-Artikel: SKYbrary Aviation Safety, „Vibration Health Monitoring (VHM)”, skybrary.aero (laufend aktualisiert). Überblick über HUMS-Systemarchitektur.
• Autoencoder-Studie Helikopter-Getriebe (2022): „A new comprehensive monitoring and diagnostic approach for early detection of mechanical degradation in helicopter transmission systems”, Expert Systems with Applications (ScienceDirect, 2022). Autoencoder + Post-Processing-Filterung reduziert Fehlalarme.
• Befundhäufigkeit, Kostendifferenz je früh erkanntem Schaden, Hardwarekosten eigener Sensorik: Annahmen für die Rechnung, keine veröffentlichten Branchenwerte. Ersetze sie durch eure eigenen Zahlen.

Du willst wissen, ob euer bestehendes HUMS-System eine realistische Basis für adaptives Monitoring bietet, oder ob ihr mit dem Bestand zu sehr eingeschränkt seid? Meld dich, das klären wir in einem kurzen technischen Gespräch.