Wind und Wetter - Herausforderungen beim Testen von Windrädern

Software-Tests an Windturbinen umfassen weit mehr als reine Softwareprüfung: Rund 164 Subsysteme, mechanische und elektrische Komponenten sowie wetterabhängige Betriebsbedingungen müssen abgedeckt werden. Getestet wird in Schichten: vom Hardware-in-the-Loop-Simulator über Prototypen-Testfelder bis zu Feldtests an realen Kundenanlagen.

Das Wichtigste in Kürze

• Windturbinen bestehen aus rund 164 Subsystemen, die alle softwareseitig implementiert und integriert werden müssen, was den Testaufwand mit dem eines komplexen cyberphysischen Systems wie einem Auto vergleichbar macht.
• Wetterbedingungen wie Blitzeinschläge lassen sich im Labor nicht provozieren, weshalb Felddaten aus einer großen Turbinen-Flotte die einzige verlässliche Grundlage für Tests unter realen Umgebungsbedingungen sind.
• Länderspezifische Regularien erzwingen unterschiedliche Softwareverhalten: In Japan muss eine Turbine nach jedem Blitzeinschlag stoppen, in Deutschland gilt diese Anforderung nicht.
• Die komplette Steuerungshardware einer Turbine ist im Headquarter als Hardware-in-the-Loop-System 1:1 nachgebaut und läuft jede Nacht automatisiert durch Testsuiten, weil Safety-kritische Tests wie Hochspannungsprüfungen keinen Simulator ersetzen kann.
• Steigende Modularität, also das Ziel, einzelne Komponenten wie Gearbox oder Steuereinheit unabhängig upgraden zu können, lässt die Varianten- und Konfigurationsvielfalt explodieren und überfordert bestehende Regressionsteststrategien.

Windturbinen testen heißt: ein cyberphysisches System unter realen Wetterbedingungen absichern

Eine Windturbine ist in der Testpraxis ein cyberphysisches System mit ähnlicher Komplexität wie ein Auto. Mechanik, Hardware und Software greifen ineinander, und der Test folgt im Kern denselben Prinzipien wie in anderen Industrien. Was die Sache besonders macht, sind ein paar Knackpunkte, die sich kaum kontrollieren lassen.

Der größte davon ist das Wetter. Windrichtung, Windstärke, Gewitter oder Überspannung lassen sich weder im Labor zuverlässig simulieren noch auf Kommando provozieren. Genau diese Bedingungen entscheiden aber über Sicherheit und Stromproduktion. Deshalb arbeitet der Test mit einer Mischung aus Simulation, Hardware-in-the-Loop und Messungen an echten Turbinen im Feld.

Onshore-Tests haben dabei Vorrang vor Offshore. Geht an einer Offshore-Anlage etwas schief, ist die Downtime hoch, die Turbinen sind größer und das Risiko entsprechend höher. Wer kann, testet an Land, bevor er aufs Wasser geht.

Wie ist die Software einer Windturbine aufgebaut?

Eine Windturbine wird modular gebaut, und diese Modularität zieht sich von der Mechanik bis in die Software. Jedes Submodul, etwa das Pitching-System für die Rotorblätter, wird als eigenes System betrachtet und separat getestet, bevor es in das Gesamtsystem integriert wird.

Die Steuerungssoftware selbst ist dabei nicht in getrennte Programme zerlegt. Ein Kontrollsystem steuert alle Einheiten der Turbine. Es läuft auf gedoppelten Kontrollnodes, einmal unten im Tower und einmal oben in der Nacelle, sodass die Module ohne Umweg miteinander kommunizieren. Intern ist diese Software modular aufgeteilt, sodass ein Scrum-Team gemeinsam mit Hardware- und Mechanik-Team an den Requirements und der Implementierung eines Moduls arbeiten kann.

Abgekoppelt davon läuft nur die Safety-Software. Sie hat ihren eigenen Controller, sitzt aber im gleichen Steuerungskasten. Die Turbine erreicht ein Safety-Integrity-Level von SIL 2, nicht SIL 3 wie etwa die Bahnindustrie. Die Sicherheitsanforderungen sind damit hoch, aber niedriger als im Bahnbereich.

Modularität reduziert Aufwand und vervielfacht zugleich die Komplexität

Modularität ist in der Windindustrie kein Selbstzweck, sondern die Voraussetzung dafür, auf Wetterbedingungen, Kundenwünsche und Regularien zu reagieren. Müsste für jede Anforderung eine komplett neue Turbine entstehen, wäre das schlicht nicht machbar.

Die Varianten- und Konfigurationsvielfalt ist mit der Autoindustrie vergleichbar. Verschiedene Turbinengrößen kommen hinzu: ältere, kleinere Anlagen produzieren weniger, neuere sind größer und leistungsfähiger. Für Qualitätssicherung und Test bedeutet das einen erheblichen Aufwand allein durch die Zahl der möglichen Konfigurationen.

Die angestrebte Richtung geht zu noch mehr Modularität, etwa zu Performance Steps, bei denen nur ein Teil der Turbine verbessert wird statt einer kompletten Neukonstruktion. Eine neue Gearbox, eine Verbesserung im Tower oder eine ausgetauschte Steuerungshardware lassen sich so einzeln upgraden. Dieser Schritt ist noch nicht abgeschlossen, viele Projekte sind weiterhin komplette neue Prototypen.

Mit der Modularität wächst aber ein Risiko: Die Varianten können geradezu explodieren. Regressionstests und eine gewisse Abdeckung bestehender Varianten gibt es bereits, doch eine stärker modularisierte Welt verlangt ein anderes Niveau der Verifikation. Sonst bringt jede neue Kombination neue Fehler mit, die kaum noch vollständig prüfbar sind.

Was steckt technisch in einer Windturbine?

Eine Windturbine ist weit mehr als ein drehender Rotor mit blinkender Lampe. Sie richtet sich nach der Windrichtung aus, damit der Rotor immer dem Wind entgegen steht. Die Nacelle, das Häuschen oben am Turm, dreht sich dafür laufend mit. Die Blätter selbst lassen sich je nach Windstärke und Last verstellen, was zugleich die Stromproduktion reguliert.

In der Nacelle sitzt der Generator. Es gibt verschiedene Bauweisen, etwa Direct Drive oder eine mechanische Gearbox. Hinzu kommen der Converter und die Verbindungen zur Powerplant, die bei einem ganzen Windpark die Einspeisung ins Netz übernimmt.

Offshore-Turbinen haben zusätzlich ein großes Power-Backup-System mit vielen Batterien. Diese Anlagen sind schwer wartbar, und in Deutschland verbieten bestimmte Wetterbedingungen den Zugang per Helikopter überhaupt. Eine Offshore-Turbine kann dadurch längere Zeit stillstehen.

Dazu kommt die Sensorik. Eine Turbine misst nicht nur Wind, sondern auch Vibration, Schock, Temperatur und vieles mehr. Smoke Detection und Fire Suppression gehören ebenso dazu. In der aktuellen Software sind rund 164 Subsysteme implementiert, was den Integrationsaufwand und das Fehlerpotenzial deutlich macht.

Neuere Offshore-Turbinen sind zudem ans Internet angebunden, teils über Starlink. Das bringt zusätzliche Komplexität bei Kommunikation und Monitoring.

Wie testet man, was sich nicht provozieren lässt?

Bedingungen, die sich nicht herstellen lassen, prüft man über die Daten realer Turbinen. Eine große Flotte und Verträge mit Partnern liefern Zugriff auf Betriebsdaten von fast allen Anlagen. Aus dem realen Verhalten lassen sich Fehler und Verbesserungen ableiten und die Performance bewerten.

Regularien verschärfen das Problem zusätzlich, weil sie sich von Land zu Land unterscheiden. Das Blinklicht muss in Deutschland immer an sein, in Dänemark nicht. Das Blitzableitersystem unterliegt überall anderen Anforderungen. In Japan muss die Turbine bei einem Blitzeinschlag stoppen, selbst wenn nichts beschädigt wurde, in Deutschland nicht.

Solche Anforderungen brauchen besonderen Fokus, und ausgerechnet in Japan schlägt der Blitz häufiger ein. Partner vor Ort geben deshalb etwas mehr Freiheit, um das Verhalten an echten Anlagen zu prüfen.

Die Auswertung dieser Datenmengen ist zu einem eigenen Schwerpunkt geworden. Ein Team von rund 100 Leuten beschäftigt sich ausschließlich mit Data Analytics: Data-Pipelines bauen, Algorithmen automatisch deployen, Daten auswerten und Erkenntnisse in die Entwicklung zurückspielen. Predictive Maintenance und Serviceability hängen direkt daran. Genutzt wird bislang nur ein Bruchteil der verfügbaren Daten.

Hardware-in-the-Loop ersetzt nicht den Test an echter Hardware

Die Software wird zuerst auf mehreren Ebenen im Simulator verifiziert. Ein guter Hardware-Simulator bildet die Mechanik sowie Wetterbedingungen und Außensensorik ab und wird im Softwareteam täglich genutzt. Weil die Hardware in dieser Branche zuerst da ist und oft die Richtung der Implementierung vorgibt, steht sie meist fest, bevor die Software ernsthaft entsteht.

Über den reinen Simulator hinaus existiert ein Hardware-in-the-Loop-System. Dort ist die komplette Steuerungshardware der Nacelle eins zu eins im Keller nachgebaut, an mehreren Standorten. Nachts laufen automatisierte Tests, tagsüber lassen sich die Systeme für eigene Tests buchen.

Manche Prüfungen lassen sich grundsätzlich nicht simulieren. Ein Hochspannungstest etwa muss auf echter Hardware bestanden werden.

In the end someone needs to crash the Volvo. Man möchte nicht 100 Autos in die Wand fahren, aber am Ende muss mindestens ein Auto in die Wand, um den Crashtest zu bestehen. Beim Hochspannungstest ist es ähnlich: beweisen lässt er sich nur auf echter Hardware.

Florian Wartenberg

Den letzten Schritt bilden Prototypen im nationalen Testcenter in Dänemark, etwa in Østerild, wo die großen Hersteller ihre Anlagen stehen haben. Eigene Turbinen besitzen die Hersteller sonst kaum. Alle Anlagen im Feld gehören Energiekonzernen. Tests an deren Kundenturbinen laufen über Verträge, bei denen die Kunden im Gegenzug schneller neue Software und Optimierungen erhalten sowie Kompensation für mögliche Ausfälle.

Testautomatisierung läuft normal, mit einem proprietären Kern

Beim Test-Setup ist die Windindustrie näher am Standard anderer Branchen, als man vermuten würde. Die vorherrschende Sprache ist C++, dazu kommen bekannte Frameworks wie Google Test. Eine ganz normale CI/CD-Pipeline führt die Tests aus und liefert Feedback zurück.

Die Besonderheit liegt im Haupt-Automatisierungsframework. Es ist intern entwickelt, spielt mit dem Simulator zusammen und basiert auf XML-Scripting. Solche proprietären, gewachsenen Werkzeuge sind schwer abzulösen, sobald eine hohe Abhängigkeit von automatisierten Tests besteht.

Geprüft wird die übliche Bandbreite an funktionalen und nicht-funktionalen Tests, dazu Performance-, Security- und Safety-Tests. Sicherheitskritische Prüfungen wie Überspannung oder Hochspannung gehören in den Hardware-in-the-Loop-Aufbau, weil ein Simulator hier als Nachweis nicht ausreicht.

Security wird durch den Cyber Resilience Act zum Treiber

Security-Tests prägen die Arbeit derzeit stark, getrieben durch den Cyber Resilience Act. Die nächste Stufe greift erst im Dezember 2027, doch viele Kunden verlangen schon jetzt vertraglich Konformität.

Das verändert die Sicherheitsphilosophie. Früher reichte das Argument, man schirme sich mit einer Firewall ab und alles Interne sei unkritisch. Heute gilt Defense in Depth. Daraus ist erheblicher zusätzlicher Testaufwand entstanden, sowohl zur eigenen Absicherung als auch zur vertraglichen und regulatorischen Konformität.

Software-Updates over the air sind in der Windbranche noch jung

Over-the-air-Updates sind in der Windindustrie ein vergleichsweise neues Thema, vergleichbar mit der Entwicklung in der Autobranche. Früher kam eine neue Software allenfalls in der Werkstatt aufs Auto, heute kommt sie automatisch wie beim Handy.

Bei Windturbinen erwarten Kunden inzwischen dasselbe: aktuelle Software, so oft wie möglich, over the air. Müsste für jedes Update ein Serviceteam rausfahren, würde es teuer, bei Offshore-Anlagen erst recht. Daraus entstehen neue Aufwände, damit der gesamte Update-Prozess möglichst nahtlos läuft und so wenige Rollbacks und Probleme wie möglich verursacht.

Diese Anforderung trifft auf eine Lebensdauer, die für mindestens 30 Jahre ausgelegt ist und so auch verkauft wird. Einige Anlagen im Feld laufen bereits über 30 Jahre. Neue Turbinen mit Höhen um 300 Meter und Leistungen Richtung 20 Megawatt verschieben dabei die Anforderungen erneut, allein schon wegen der starken Vibrationen, die das Material strapazieren.

Sales und Entwicklung müssen die Variantenvielfalt gemeinsam beherrschen

Die zentrale Aufgabe der nächsten Jahre liegt darin, die wachsende Variantenvielfalt zu beherrschen, bevor sie unkontrollierbar wird. Mehr Modularität bringt mehr Konfigurationsmöglichkeiten, und ohne passende Mechanismen lässt sich diese Vielfalt nicht mehr sinnvoll verifizieren.

Dafür braucht es ein besseres Zusammenspiel zwischen Sales und Entwicklung. Wird etwas verkauft, das nicht mit R&D abgestimmt ist, entstehen Konfigurationen, die niemand abgesichert hat. Der Sales-Konfigurator muss exakt abbilden, was intern entwickelt, verkauft und verifiziert wurde. Dieses Problem kennen Produktteams quer durch alle Branchen: Marketing und Vertrieb sind mit Features oft vorn, und die Entwicklung muss sicherstellen, dass sich das Versprochene auch sicher und getestet umsetzen lässt.