Windturbinen-Eisansatz erkennen ohne Kontaktsensoren

Das echte Ausmaß des Problems

Eisansatz an Rotorblättern ist kein Randphänomen. In Deutschland betrifft es jeden Windpark ab etwa 400 Höhenmetern, das bedeutet große Teile des Schwarzwalds, der Mittelgebirge (Eifel, Sauerland, Erzgebirge, Harz, Thüringer Wald), des Voralpenlands und vieler Küstenstandorte mit icing-begünstigtem Nieselregen.

Laut einer Feldstudie der Iowa State University (veröffentlicht in Renewable Energy, 2021) können Icing-Ereignisse bis zu 80 Prozent der Produktionsleistung einer betroffenen Turbine kosten. Im Jahresmittel liegt der Ertragsausfall für icing-exponierte Standorte nach Daten von IEA Wind Task 19 bei 10–20 Prozent der Jahreserzeugung. Eine finnische Langzeitstudie (Dexter Energy, 2023) kalkuliert durchschnittliche Einnahmeverluste von 67.000 Euro pro Turbine und Jahr durch Eisansatz.

Das eigentlich unterschätzte Problem ist aber nicht der Ertragsausfall, es ist der Eiswurf. Eisstücke von 0,5 bis 5 kg, die von einem laufenden Rotor mit Spitzengeschwindigkeiten von 200–300 km/h losgeschleudert werden, können bei einem 150-m-Turm Wurfweiten von bis zu 400 Metern erreichen. Die deutsche Muster-Verwaltungsvorschrift Technische Baubestimmungen (MVV TB) schreibt einen Sicherheitsabstand von 1,5 × Nabenhöhe plus Rotordurchmesser vor. In der Praxis bedeutet das bei modernen Anlagen: 300–400 Meter Sicherheitsbereich, in dem bei Eisansatz niemand sein sollte.

Das Kontrollproblem ist strukturell: Die meisten Betreiber reagieren mit pauschalem Temperatur-Schwellwert, bei unter 0 °C oder unter minus 2 °C wird abgeschaltet. Das Ergebnis sind hunderte Abschaltstunden pro Wintersaison, von denen ein erheblicher Teil unnötig ist, weil kein Eis vorhanden war oder bereits abgetaut hatte. Umgekehrt läuft die Anlage in Perioden, in denen Eis physisch vorhanden, aber die Temperatur noch im Grenzbereich ist.

Wo bisher Kontaktsensoren eingesetzt wurden (kapazitive Blattsensoren, Schwingungsgewichte), zeigt sich ein zweites Problem: Diese Sensoren liefern in den härtesten Frostbedingungen, genau dann, wenn Eisansatz am kritischsten ist, die unzuverlässigsten Werte. Kapazitive Sensoren auf dem Rotorblatt brauchen eine gleichmäßige Eisverteilung, um verlässlich anzuschlagen. Bei patchy rime, also ungleichmäßigem Reifansatz, der in Mittelgebirgslagen häufiger vorkommt als Glatteis, versagen sie systematisch.

Mit vs. ohne KI, ein ehrlicher Vergleich

¹ Ertragsverlustwerte basierend auf IEA Wind Task 19 (2021) und Iowa State University Feldstudie (Renewable Energy, 2021). Abschaltzeitenreduktion: eigene Schätzung basierend auf Betreiberberichten.

Einschätzung auf einen Blick

Zeitersparnis, mittel (3/5) Der Hauptgewinn liegt nicht in gesparter Arbeitszeit, sondern in der Vermeidung von unnötigen Produktionspausen: 100–300 Stunden Mehrerzeugung pro Wintersaison und Turbine sind realistisch, wenn das System sauber kalibriert ist. Verglichen mit Anwendungsfällen wie der Lastprognose oder dem KI-Energiemanagementsystem für Industrie, die jeden Betriebstag sparen, ist das eine saisonale, aber signifikante Größe.

Kosteneinsparung, hoch (4/5) Bei einer durchschnittlichen Einnahme von 60–90 €/MWh und 100–300 vermiedenen Abschaltstunden à 2–4 MW Leistung summiert sich das schnell auf 12.000–100.000 Euro pro Turbine und Wintersaison, stark standortabhängig. Dazu kommt die vermiedene Haftung: Ein Eiswurf-Schadensereignis (Fahrzeugschaden, Personengefährdung) kann schnell im fünf- bis sechsstelligen Bereich enden, selbst wenn keine Personenschäden entstehen.

Schnelle Umsetzung, mittel (3/5) Sensorinstallation, Datenaufbau und Modelltraining benötigen realistisch 3–6 Monate, und das ist nur der technische Teil. Ein belastbares Modell entsteht erst nach einer vollständigen Frostsaison (mindestens 8–12 Wochen mit nennenswerten Icing-Ereignissen). Wer im Frühjahr startet, hat im Herbst ein Modell, das seinen ersten echten Winter erlebt. Das ist typisch für energiespezifische ML-Projekte in diesem Bereich, schnellere Einstiege existieren kaum.

ROI-Sicherheit, mittel (3/5) Das ist die ehrliche Schwachstelle dieses Use Cases: Der Ertragszuwachs ist direkt proportional zu den tatsächlichen Frostbedingungen des Jahres. Ein milder Winter kann den ROI einer vollständigen Frostsaison um 60–80 Prozent reduzieren. Erst nach zwei bis drei Wintern zeigt die ROI-Kurve einen verlässlichen Durchschnitt. Das unterscheidet diesen Use Case deutlich von Anwendungen wie der Transformatorgas-Analyse, bei der der Nutzen von einer konkreten vermiedenen Havarie abhängt und kein Wettermuster.

Skalierbarkeit, hoch (4/5) Ist das Modell einmal für einen Turbinentyp trainiert (z.B. Enercon E-101), lässt es sich auf weitere Turbinen des gleichen Typs im selben Park mit deutlich weniger Aufwand (Feintuning statt Neuentwicklung) übertragen. Plattformen wie Turbit setzen genau dieses Transfer-Prinzip ein: Ein Basismodell je Anlagenklasse, das für jeden Standort kalibriert wird. Eine vollständige Parkintegration skaliert linear mit der Turbinenzahl.

Richtwerte, stark abhängig von Standorthöhe, Klimazone, Turbinentyp und SCADA-Datenqualität.

Eisphysik: Warum Reif und Glatteis das Modell unterschiedlich herausfordern

Nicht jedes Eis ist gleich, und das ist für die Modelleigenschaft entscheidend.

Reifeis (rime ice) entsteht, wenn unterkühlte Wassertröpfchen (Nebel, Wolken, Nieselregen) auf der kalten Blattoberfläche sofort gefrieren. Das Ergebnis ist eine opake, weißliche, poröse Eisschicht, die sich vor allem an den Blattvorderkanten und den Blattspitzen bildet. Reifeis wächst langsam und ungleichmäßig, die Verteilung zwischen den drei Blättern eines Rotors ist typischerweise asymmetrisch, weil Wind und Feuchtigkeitsfelder über das Rotorfeld nicht gleichmäßig sind. Diese Asymmetrie ist der stärkste SCADA-erkennbare Fingerabdruck: Die Pitchwinkeldifferenz zwischen den Blättern steigt, die Leistungskurve weicht ab, und die Vibrationssignatur an Gondel und Turm verändert sich charakteristisch, weil das Unwuchtmoment zunimmt.

Glatteis (glaze ice) entsteht bei flüssigem Regen, der auf Oberflächen unter dem Gefrierpunkt trifft und sich als transparente, schwere Schicht ablagert. Glatteis bildet sich gleichmäßiger über das Blatt und ist schwerer (höhere Dichte) als Reifeis. Die Lastand gleichmäßiger, die Vibrationssignatur weniger asymmetrisch, aber die aerodynamische Profilstörung und damit die Leistungskurvenabweichung ist massiver. Glatteis ist für Machine Learning-Modelle in einer Hinsicht günstiger: Die Leistungskurvenabweichung ist klarer und reproduzierbarer. In einer anderen Hinsicht schwieriger: Glatteis-Ereignisse sind seltener und die Labeling-Grundlage dünner.

Für den Modellansatz bedeutet das: Ein robustes Eiserkennnungssystem muss beide Eistypen abdecken. Reifeis erkennst du am besten über Vibrations- und Pitchwinkelsignale; Glatteis über Leistungskurvendeviation und Nacellenbeschleunigung. Die besten in der Forschung publizierten Ansätze (u.a. Li et al., 2024 in Renewable Energy) kombinieren multivariate Sensor-Features zu einem gemeinsamen Klassifikator und erzielen damit Erkennungsraten über 95 Prozent.

SCADA-Signale: Was das System wirklich liest

Ein SCADA-basiertes Eiserkennungsmodell arbeitet typischerweise mit einer Kombination aus sieben bis zwölf Eingangssignalen. Nicht alle sind gleich informativ, hier die wichtigsten:

Leistungskurvenabweichung ist das stärkste Einzelsignal: Eis reduziert den Auftrieb und erhöht den Luftwiderstand der Blätter, was bei gegebener Windgeschwindigkeit zu niedrigerer Leistungsabgabe führt. Die Abweichung der gemessenen Leistung von der turbinen-typischen Leistungskurve (Power Curve Deviation, PCD) ist für moderate Eisansätze schon bei 5–8 Prozent statistisch signifikant detektierbar.

Pitchwinkeldifferenz zwischen den drei Blättern ist der zuverlässigste Indikator für asymmetrischen Reifansatz. Das Pitchsystem versucht automatisch, die Drehzahl zu stabilisieren, wenn ein Blatt mehr Eis trägt als die anderen, kompensiert der Regler mit unterschiedlichen Stellwinkeln. Diese Differenz ist im SCADA-Historian dokumentiert und kann direkt als Feature genutzt werden.

Gondelschwingungen (X/Y/Z-Beschleunigung) registrieren die erhöhte Unwucht eines asymmetrisch vereisten Rotors. Die charakteristischen Frequenzkomponenten in der einfachen Rotationsfrequenz und deren Obertönen sind mit spektraler Analyse (FFT, Wavelet) extrahierbar und bilden die Basis für Deep-Learning-Ansätze auf Spektrogrammen.

Rotorblatttemperatur (wo vorhanden): Direkte Temperaturmessungen an der Blattvorderkante korrelieren stark mit Eisbildungswahrscheinlichkeit. Nicht alle Turbinen haben diese Sensoren, und die Nachrüstung ist teuer. Wenn vorhanden, deutlich verbesserte Modellqualität.

Windgeschwindigkeit und Windrichtung: Werden als Normalisierungsfeatures benötigt, das Modell muss unterscheiden, ob eine Leistungsabweichung von Eis kommt oder von geringerem Windangebot.

Umgebungstemperatur und Feuchtigkeit: Meteorologische Vorbedingungen für Eisbildung. Oft aus dem SCADA-System selbst verfügbar (Gondelwettermessung).

Was 10-Minuten-Mittelwerte nicht können: Viele ältere SCADA-Historiane speichern nur 10-Minuten-Mittelwerte, das ist der IEC-Standard. Für Gondelvibrationen und Pitchwinkeldynamiken reicht diese Auflösung nicht aus: Das Vibrationsmuster, das Eisansatz charakterisiert, liegt im Sekundenbereich und wird durch 10-Minuten-Mittelung vollständig wegglätet. Neuere SCADA-Systeme speichern 1-Sekunden-Daten für ausgewählte Kanäle. Wer nur 10-Minuten-Daten hat, muss Leistungskurvenabweichung und Pitchwinkeldifferenz als primäre Features nutzen, und akzeptiert eine geringere Erkennungsgenauigkeit für frühe Reifansatz-Stadien.

Physische Sensoren vs. SCADA-Modell: Ein ehrlicher Vergleich

Auf dem Markt gibt es zwei Grundansätze für die Eiserkennung, und die Wahl zwischen ihnen ist entscheidend für das richtige Setup.

Physische Sensorsysteme (z. B. EOLOGIX-PING, Vaisala WMT700) montieren kapazitive oder akustische Sensoren direkt auf dem Rotorblatt. Sie messen die Eisschicht direkt am Entstehungsort, ohne Umweg über Betriebsdaten. Der Vorteil: unabhängig von SCADA, arbeitet auch bei Drehzahl null, unterscheidet Eistypen zuverlässig bei guter Kalibrierung. Der Nachteil: Kosten von 1.000–3.000 Euro pro Turbine und Jahr (eologix-ping :LITE-Tier für akustische Turmbasis-Messung: 1.080 USD/Turbine/Jahr, Stand 2024), regelmäßiger Kalibrieraufwand, und, das ist der paradoxe Punkt, die härtesten Frostbedingungen sind die, in denen Sensoren am Blatt am häufigsten ausfallen.

SCADA-basierte ML-Modelle brauchen keine neue Hardware, sie nutzen vorhandene Betriebsdaten. Nach einmaliger Einrichtung und Training liegen die laufenden Kosten bei 200–600 Euro pro Turbine und Jahr (Software-Subscription, Stand Marktübersicht 2025). Die Erkennungsqualität ist bei guter SCADA-Datenqualität und nach einer vollständigen Trainingssaison mindestens gleichwertig mit physischen Sensorsystemen, für asymmetrischen Reifansatz in manchen Konfigurationen sogar überlegen.

Die nüchterne Empfehlung: Für Neubauprojekte in stark icing-exponierten Lagen (Jahresdurchschnitt über 200 Eisstunden, Höhe über 600 m) ist eine Kombination aus SCADA-Modell + einfachem Nacellen-Beschleunigungssensor die sinnvollste Wahl, die Sensoren ersetzen fehlende Hochfrequenz-SCADA-Daten und das Modell gibt den Kontext. Für Bestandsanlagen in gemäßigt icing-exponierten Lagen (100–200 Eisstunden/Jahr, typisches deutsches Mittelgebirge) reicht ein gut kalibriertes SCADA-Modell.

Was das Erkennungssystem konkret macht

Der technische Ablauf eines SCADA-basierten Eiserkennungssystems lässt sich in vier Schichten aufteilen:

Datenhaltung: SCADA-Zeitreihendaten (1-Sekunden- oder 10-Minuten-Werte, je nach Verfügbarkeit) werden in einer Zeitreihendatenbank wie InfluxDB gespeichert. Die Daten bleiben lokal auf dem Anlagen-Gateway, keine Cloud-Pflicht für den Betrieb.

Modellinfrastruktur: Ein Machine Learning-Modell, typischerweise ein LSTM-Netzwerk für sequentielle Zeitreihenmuster oder ein Random-Forest-Klassifikator für Feature-basierte Erkennung, läuft auf einem Edge-Gateway in der Gondel oder im Turmfuß. Der Vorteil: keine Latenz durch Cloud-Routing, Erkennung in Echtzeit.

Klassifikation: Das Modell unterscheidet vier Zustände: Normalbetrieb, Verdacht auf Eisansatz (Frühwarnstufe), bestätigter Eisansatz (Sicherheitsrelevanz-Stufe), Freigabe nach Abtauung. Jede Stufe kann an die Anlagensteuerung übergeben werden, als Signal für Blattheizungsaktivierung, Drehzahlreduzierung oder Abschaltbefehl.

Visualisierung und Alerting: Die Zustände werden in ein Dashboard (z. B. Grafana) gespiegelt. Das Betriebsführungsteam sieht live den Eiszustand jeder Turbine und die Modellkonfidenz. Alerts bei Überschreitung der Sicherheitsschwelle gehen per SMS oder E-Mail an den Diensthabenden.

Für den vollständigen ML-Workflow, also Modelltraining, Hyperparameter-Tuning und Rollout, eignet sich Azure Machine Learning als Cloud-Trainingsumgebung, von der die Modelle dann als serialisierte Artefakte auf die Edge-Gateways ausgerollt werden.

Spezialisierte Plattformen wie Turbit bieten diesen gesamten Stack als betriebsfertigen Service an: SCADA-Integration, Modell-Training, kontinuierliches Monitoring und Alerting sind gebündelt. Der Eigenentwicklungsweg über InfluxDB + Grafana + eigenes Modell ist flexibler, aber erfordert Data-Science-Kompetenz im Team oder einen spezialisierten Dienstleister.

Sicherheitsabschaltung und regulatorische Anforderungen

Wer eine KI-gestützte Eiserkennung in den Abschaltprozess integriert, muss die regulatorische Lage kennen.

Die MVV TB (Muster-Verwaltungsvorschrift Technische Baubestimmungen, in den meisten Bundesländern in Landesrecht überführt) schreibt vor: Windenergieanlagen in Lagen mit Eisansatz-Risiko müssen mit Eiserkennungs- und Eisabschaltsystemen ausgestattet sein. Diese Systeme müssen bei erkanntem Eisansatz die Anlage sicher in den Stillstand bringen und dürfen erst nach Freigabe (Abtauung bestätigt) wieder anlaufen. Warnschilder im Nahbereich sind Pflicht.

Was zählt als “Eiserkennungssystem” im regulatorischen Sinne? Physische Sensorsysteme (kapazitiv, akustisch) sind explizit anerkannte Lösung. SCADA-basierte ML-Modelle befinden sich in einer Grauzone: Sie sind nicht explizit ausgeschlossen, aber auch nicht positiv gelistet. In der Praxis empfehlen Windpark-Genehmigungsbehörden, die KI-Erkennung mit einer physischen Redundanz (mindestens einem Nacellen-Vibrationssensor als Backup) zu kombinieren, um den regulatorischen Nachweis zu stützen.

Die IEC 61400-1 (Ausgabe 4, 2019) definiert in Annex L die Klimaklassen für Eisbedingungen (Icing Climate I–IV). Für Standorte in den Eisklassen SII und SIII (Mittelgebirge, alpin) empfiehlt die Norm explizit eine aktivierte Eis-Schutzstrategie, ohne ein spezifisches Detektionsverfahren vorzuschreiben. Das öffnet den Raum für datenbasierte Ansätze, solange die Systemperformance dokumentiert und bei der Behörde hinterlegt ist.

Praktischer Hinweis: Wenn du ein SCADA-Modell als primäres Eiserkenungssystem einführen willst, lass das System durch einen akkreditierten Prüfer (z. B. TÜV, DEKRA, WindGuard) validieren und dokumentiere Erkennungsraten, Fehlalarmquoten und Reaktionszeiten. Diese Dokumentation ist die Grundlage für den Behördennachweis.

Konkrete Werkzeuge, was wann passt

Turbit, wenn du einen schlüsselfertigen Service bevorzugst. Turbit baut turbinen-spezifische Anomaliemodelle aus vorhandenen SCADA-Daten, liefert kontinuierliches Monitoring und Alerting und hat nachgewiesene Betriebserfahrung mit über 3.500 überwachten Turbinen (inkl. Enercity, WPD). Für Eiserkennung ist Turbit derzeit das anerkannteste spezialisierte Tool auf dem deutschen Markt. Kosten auf Anfrage; typisch: Pro-Turbine-Subscription, Preisindikation nur durch Angebot.

InfluxDB + Grafana, wenn du eine eigenständige, offene Dateninfrastruktur aufbauen willst. InfluxDB speichert die SCADA-Zeitreihen hochperformant; Grafana visualisiert Zustände und Modell-Alerts in Echtzeit. Beide sind Open Source und on-premise betreibbar, kein Cloud-Zwang, vollständige Datensouveränität. Dieser Stack ist die Basis, auf der du ein eigenes Modell (Python + scikit-learn oder LSTM) deployen kannst. Kosten: nahezu null für Lizenz; Eigenleistung für Integration und Modell.

Siemens Industrial Edge, wenn du eine Siemens-Turbine oder -Steuerung einsetzt und eine industriell gehärtete Edge-Plattform für das Modell-Deployment brauchst. Der AI Inference Server als Industrial-Edge-App nimmt trainierte Modelle im ONNX-Format entgegen und führt sie lokal am Turm aus. Besonders geeignet für Siemens-Gamesa-Turbinen oder Windparks, die bereits Siemens-Automatisierungsinfrastruktur einsetzen. Hardware ab 2.000–3.000 Euro; Lizenz auf Anfrage.

Azure Machine Learning, für das Modell-Training in der Cloud. Die SCADA-Historiedaten werden einmalig in Azure hochgeladen, das Modell trainiert (GPU-Compute nach Bedarf, ca. 0,90 USD/Stunde für Einstiegs-GPU), validiert und als Artefakt ausgerollt. Nach dem Training läuft das Modell lokal auf dem Edge-Gateway, keine laufenden Azure-ML-Kosten außer Storage. Sinnvoll für Teams mit Azure-Infrastruktur oder wenn das Training-Dataset zu groß für lokale Rechner ist.

Wann welcher Ansatz:

• Schlüsselfertiger Betrieb ohne eigenes Data-Science-Team → Turbit
• Volle Datenkontrolle, offener Stack, eigene Modellentwicklung → InfluxDB + Grafana + eigenem Modell
• Siemens-Turbinen, Industrieumgebung mit Edge-Anforderungen → Siemens Industrial Edge
• Modelltraining skalierbar in der Cloud, dann on-premise deployen → Azure Machine Learning

Datenschutz und Datenhaltung

Windturbinen-Betriebsdaten sind technische Maschinendaten, sie enthalten in der Regel keine personenbezogenen Informationen im Sinne der DSGVO. Das klingt nach geringem Datenschutz-Aufwand, unterschätzt aber die strategische Sensibilität: Produktionskurven, Ausfallmuster und Betriebsparameter sind wertvolle Wettbewerbsinformationen, die nicht unreflektiert bei Cloud-Anbietern landen sollten.

Für On-Premise-Betrieb (InfluxDB auf lokalem Gateway, Grafana im internen Netz) verlässt kein Betriebsdatum das eigene Netzwerk. Das ist für viele Windparkbetreiber der präferierte Weg, insbesondere wenn SCADA-Daten vertraglich als proprietär deklariert sind.

Für Cloud-Training (Azure Machine Learning mit EU-Region Frankfurt): Microsoft verarbeitet Daten ausschließlich in der gewählten Region, kein Weitertransfer ohne Zustimmung. AVV ist Standardbestandteil der Microsoft Online Services Terms. SCADA-Daten für Windparks sind keine personenbezogenen Daten, aber ein AVV ist dennoch empfehlenswert, wenn Drittanbieter Trainingsdaten verarbeiten.

Für SaaS-Dienste wie Turbit: Turbit ist ein deutsches Unternehmen mit EU-Datenhaltung, die Daten verlassen den europäischen Rechtsraum nicht. Vor Vertragsabschluss sollte geprüft werden, ob SCADA-Daten nur zum Monitoring verwendet oder auch für Modellverbesserungen über die eigene Turbine hinaus genutzt werden (Benchmark-Pooling). Das ist bei vielen Condition-Monitoring-Plattformen üblich und in der Regel vertragsfähig, muss aber aktiv ausgehandelt werden.

Was es kostet, realistisch gerechnet

Einmalige Projektkosten

Laufende Kosten (nach Anlauf)

• Eigenentwicklung + Open-Source-Stack: 500–1.500 €/Monat (Server, Updates, Modellpflege intern)
• Managed Service (Turbit o.ä.): 1.000–3.000 €/Monat für einen 5-Turbinen-Park (Pro-Turbine-Subscription)
• Eologix physische Sensorsysteme: 1.080–2.500 USD/Turbine/Jahr (Vergleichsbasis)

Was du dagegen rechnen kannst Bei einem Park mit 5 × 3-MW-Turbinen und 150 vermiedenen unnötigen Abschaltstunden pro Wintersaison: 5 Turbinen × 150 Stunden × 3 MW × 70 €/MWh = 157.500 Euro pro Wintersaison. Das ist die theoretische Obergrenze. Realistisch liegt der realisierte Gewinn, nach Fehlalarmen, Wettervariabilität und Modellunschärfe, erfahrungsgemäß bei 40–60 Prozent davon, also 60.000–90.000 Euro pro Wintersaison. Selbst im konservativen Szenario amortisiert sich ein Managed-Service bei einem 5-Turbinen-Park innerhalb von 12–18 Monaten.

Dazu kommt der schwer quantifizierbare, aber reale Wert der vermiedenen Haftungsexposition: Ein einziger Eiswurf-Schaden an einem Fahrzeug auf einem Forstweg beginnt bei 5.000–15.000 Euro, und das ist noch das unkritische Szenario.

Drei typische Einstiegsfehler

1. Mit unvollständiger Trainingshistorie starten Der häufigste Fehler: Ein Betreiber installiert das System im Oktober, hofft auf Daten aus dem ersten Winter, und wundert sich nach April, warum das Modell nur mittelmäßig funktioniert. Das Problem: Icing-Ereignisse sind im SCADA-Datensatz seltene Minderheitsereignisse (Klassenungleichgewicht). Ein Modell, das auf 10.000 Normalbetriebsstunden und 50 Vereisungsstunden trainiert wird, lernt primär “normal” zu sagen, weil das statistisch fast immer richtig ist. Erst ab 150–300 dokumentierten Vereisungsstunden in der Trainingshistorie werden die Modellgrenzen verlässlich. Das bedeutet: Realistische Anlaufzeit ist zwei Wintersaisonen, nicht eine.

2. Fehlalarme nicht systematisch auswerten SCADA-Modelle produzieren gelegentlich Fehlalarme, das Modell schlägt Alarm, obwohl kein Eis vorhanden ist. Das ist kein Fehler, sondern ein Signal. Die Frage ist: Welche Betriebszustände verursachen Fehlalarme? Häufige Ursachen sind starke Windböen (die die Vibrationssignatur ähnlich wie asymmetrischer Reif verändern), Lagerfehler-Frühstadien oder Regennässe. Wer Fehlalarme ignoriert statt auszuwerten und das Modell nachzuschärfen, hat nach einem Jahr ein System mit 25–30 Prozent Fehlalarmrate, und Betriebspersonal, das die Alerts nicht mehr ernst nimmt. Jeder Fehlalarm muss im Labeling-System mit Ursache dokumentiert werden.

3. Das Modell nach dem ersten Winter nicht neu trainieren ML-Modelle für Zeitreihendaten driften mit veränderten Betriebsbedingungen: neue Rotor-Pitchkalibrierung nach Wartung, Lagerverschleiß im Folgejahr, veränderte Windparkumgebung (neuer Nachbarpark in Wakeposition). Ein Modell, das im Frühjahr 2024 auf Winter 2023/24 trainiert wurde und seitdem nicht aktualisiert wurde, hat im Winter 2025/26 möglicherweise eine signifikant schlechtere Erkennungsrate. Jährliches Retraining mit dem neuesten Winter als primärem Trainingsdatensatz ist Pflicht.

Der versteckte Fehler: Zu wenig Aufmerksamkeit für Stillstandsphasen Wenn die Turbine still steht (Wartung, Niedrigwind), gibt es kein SCADA-Signal für Vibrationen und Leistungskurve. Eisansatz während des Stillstands ist aber möglich und führt beim Wiederanlauf zu kritischem Unwucht-Anfahren. Kein SCADA-Modell der Welt erkennt Eisansatz an einer stehenden Turbine, das muss im Betriebsprotokoll durch eine manuelle Sichtprüfung oder Temperatursensor-Abfrage vor dem Anlaufen abgedeckt werden. Wer das übergeht, hat eine Sicherheitslücke.

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

Das Technische ist in diesem Use Case nicht das Schwierige. Das Schwierige ist die organisatorische Seite.

Der Betriebsführungsdienst muss umdenken. Wer jahrelang auf “Temperatur unter null = abschalten” konditioniert wurde, dem fällt es schwer, einem ML-Signal zu vertrauen, das sagt “alles gut, laufen lassen”, auch wenn es kalt ist. Diese Vertrauensbildung braucht Zeit und transparente Kommunikation: Das Modell muss in den ersten Wochen live gegen das bisherige Regelwerk beobachtet werden, bevor es vollständige Entscheidungshoheit erhält.

Erwarte nicht sofort Vollautomatisierung. Der sinnvolle Startpunkt ist ein Assistenz-Modus: Das Modell gibt eine Empfehlung, der Schichtleiter trifft die Entscheidung. Erst nach 6–8 Wochen Betrieb mit dokumentierter Übereinstimmungsrate (Modell lag in X% der Fälle richtig) wird auf automatische Abschaltlogik umgestellt.

Labeling ist ein unterschätzter Engpass. Für das Training braucht es einen “Ground Truth”, also dokumentierte Icing-Ereignisse mit Zeitstempel. Woher kommen diese Labels? Typischerweise aus drei Quellen: Wartungsberichte mit Eis-Sichtungsprotokollen, Webcam-Bilder der Rotorblätter (sofern vorhanden), nachträgliche Auswertung von Leistungseinbrüchen in Korrelation mit Wetterdaten. Der Aufbau einer guten Label-Datenbank ist mindestens vier Wochen Arbeit, und das ist die Aufgabe, die Windpark-Teams am meisten unterschätzen.

Was hilft: Ein gemeinsamer Session mit dem Data-Science-Team und dem Betriebsführungspersonal in der ersten Frost-Woche. Echte Ereignisse live beobachten, Modell-Output diskutieren, Fehlalarme direkt dokumentieren. Diese Praxis-Session ist mehr wert als jede nachträgliche Modellvalidierung.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände, und was dahintersteckt

“Wir haben schon ein Eiserkennungssystem, Temperatursensor.” Ein Temperaturgrenzwert ist kein Eiserkenungssystem, es ist eine Eiswahrscheinlichkeits-Heuristik. Temperatur unter null bedeutet nicht zwingend Eisansatz (trockene Kälte, warmer Rotor durch Nennlast), und Eisansatz bedeutet nicht zwingend Temperatur unter null (Gefrierregen über null Grad bei spezifischen Druckverhältnissen). Das Modell arbeitet mit der tatsächlichen Anlagenreaktion, nicht mit der Außentemperatur. Das ist der qualitative Unterschied.

“Was ist, wenn das Modell versagt und wir trotzdem Eiswurf haben?” Das ist der berechtigtste Einwand. Die Antwort ist nicht, das Modell blindlings zu vertrauen, sondern die Risikoarchitektur korrekt zu bauen: Das Modell ist ein Entscheidungsassistent, keine Single-Point-of-Defense. Kombiniert mit einem Nacellen-Vibrationssensor als Hardware-Redundanz, festgelegten Temperatur-Backstop-Regeln (unter minus 12 °C immer abschalten, unabhängig vom Modell) und einer dokumentierten Notfallprozedur ist die Gesamtsicherheit höher als mit dem bisherigen Regelwerk allein.

“Unsere SCADA-Daten sind zu lückenhaft.” Das ist kein Ausschlussgrund, aber es beeinflusst den Modellansatz. Wenn mehr als 10 Prozent der relevanten Zeitfenster im SCADA-Historian fehlen, empfiehlt sich ein Feature-Engineering-Ansatz mit robusten Aggregaten (Tagesmittel, Gleitende Durchschnitte) statt roher Zeitreihenklassifikation. Die Erkennungsqualität ist damit geringer, aber deutlich besser als ein reiner Temperaturschwellwert.

Woran du merkst, dass das zu dir passt

Du bist gut aufgestellt, wenn:

• Dein Windpark liegt auf mehr als 350 Höhenmetern oder in einer Lage mit bekannten Icing-Ereignissen (Erzgebirge, Schwarzwald, Harz, Sauerland, Voralpenland)
• Du hast einen SCADA-Historian mit mindestens zwei vollständigen Betriebsjahren Datenhistorie
• Du hast bereits mindestens eine dokumentierte Frostsaison mit Icing-Protokollen oder Wartungsberichten, die als Trainingslabels dienen können
• Dein bisheriges System basiert auf Temperatur-Schwellwerten und du hast das Gefühl, zu viele unnötige Abschaltungen zu fahren
• Du betreibst mindestens drei Turbinen an einem Standort, das Mindestvolumen für ein statistisch belastbares Modell

Wann es (noch) nicht funktioniert, drei harte Ausschlusskriterien:

1. Weniger als zwei vollständige Wintersaisonen SCADA-Daten. Icing-Ereignisse sind seltene Minderheitsereignisse in jedem SCADA-Datensatz. Unter zwei Saisons gibt es nicht genug Positiv-Labels für ein verlässliches Modell. Keine Plattform, auch Turbit nicht, kann dieses Grundproblem mit Algorithmus-Tricks überbrücken. Lösung: Datenpipeline aufbauen, erste Saison dokumentieren, im Jahr darauf starten.

2. Nur 10-Minuten-SCADA-Mittelwerte ohne Hochfrequenzdaten. Wer keine 1-Sekunden-Daten für Gondelschwingung und Pitchwinkeldynamik hat, muss den Modellansatz auf Leistungskurvenabweichung und statische Pitchwinkeldifferenz beschränken. Das Modell erkennt fortgeschrittenen Eisansatz, nicht das frühe Stadium. Wenn der Windpark diese Daten nicht nachrüsten kann, ist ein physisches Sensorsystem (EOLOGIX, Vaisala) die bessere Option.

3. Kein Data-Science-Know-how im Team oder beim Dienstleister und kein Budget für einen spezialisierten Managed Service. Eine sauber entwickelte SCADA-basierte Eiserkennung braucht Kompetenz in Zeitreihendaten, Klassenungleichgewicht, Modellvalidierung und Deployment. Wer dieses Know-how weder intern noch über einen Dienstleister (wie Turbit oder einen spezialisierten ML-Dienstleister) bereitstellen kann, bekommt ein System, das beim ersten realen Winter scheitert. Die DIY-Version auf Basis von Open-Source-Bibliotheken ist möglich, aber unterschätze den Aufwand nicht.

Das kannst du heute noch tun

Bevor du in ein Modell investierst, prüfe, was du bereits hast. Öffne deinen SCADA-Historian und extrahiere für eine bekannte Icing-Woche (idealerweise aus dem letzten Winter) die folgenden vier Signale stündlich: Leistungsabgabe (kW), mittlerer Pitch-Winkel (°), Pitchwinkeldifferenz zwischen Blättern (°) und Gondelschwingung (falls verfügbar). Trage sie in einer einfachen Tabelle nebeneinander auf, oder in ein Python-Notebook mit matplotlib.

Was du sehen wirst: eine erkennbare Abweichung der Leistungskurve und eine erhöhte Pitchwinkeldifferenz in den Eisstunden gegenüber Vergleichsstunden ähnlicher Windgeschwindigkeit. Das ist der erste manuelle Beweis, dass deine Daten genug Signal enthalten, um ein Modell zu trainieren. Wenn du das Signal nicht siehst, fehlt dir entweder Datenqualität oder Labelqualität, und das ist die wichtigste Information, bevor du 25.000 Euro in ein ML-Projekt investierst.

Hier ist ein Prompt, den du direkt in ChatGPT oder Claude eingeben kannst, um eine erste Abweichungsanalyse zu beschreiben:

Quellen & Methodik

• IEA Wind Task 19 (2021): Technical Report on Ice Detection Guidelines for Wind Energy Applications. Internationale Richtlinien für Eiserkenungssysteme in der Windenergie. iea-wind.org/task19/
• Iowa State University / ScienceDaily (2021): “Field study shows icing can cost wind turbines up to 80% of power production.” Feldstudie zu Ertragsverlusten durch Eisansatz an Utility-Scale-Turbinen. sciencedaily.com
• Dexter Energy (2023): “Icing on wind turbines: Causes, risks, and forecasts.” Durchschnittliche Einnahmeverluste von 67.000 Euro/Turbine/Jahr (finnische Turbinen, 2021–2023). dexterenergy.ai
• Li et al. (2024): “Icing detection and prediction for wind turbines using multivariate sensor data and machine learning.” Renewable Energy, Elsevier. Erkennungsrate von bis zu 96,4% bei minimalen Fehlalarmen. sciencedirect.com/S0960148124009479
• arxiv.org (2021, Zhang et al.): “Intelligent Icing Detection Model of Wind Turbine Blades Based on SCADA data.” CNN + GAN-Ansatz mit Domain Adaptation für Modell-Transfer zwischen Turbinen. arxiv.org/abs/2101.07914
• IEA Wind TCP GitHub: T19IceLossMethod, offene Methode zur Schätzung von Icing-Verlusten aus SCADA-Daten. github.com/IEAWind-Task19/T19IceLossMethod
• Sensorkosten physische Systeme: EOLOGIX-PING :LITE ICE, Stand 2024: 1.080 USD/Turbine/Jahr (akustische Turmbasis-Messung). eologix-ping.com
• MVV TB Eiswurfanforderungen: Muster-Verwaltungsvorschrift Technische Baubestimmungen in der Fassung 2021/22, Abschnitt Windenergieanlagen, Sicherheitsabstand und Eisabschaltsysteme.
• Laufende Kosten SCADA-Modell: Marktübersicht Condition-Monitoring-Plattformen für Windenergie, eigene Erhebung (Stand Mai 2026).

Du willst wissen, ob deine SCADA-Daten für ein Eisansatz-Modell ausreichen, und welche Anlaufzeit und welches Budget du einplanen musst? Meld dich für ein kurzes Gespräch.