Ein digitaler Zwilling der Windkraftanlage ist ein lebendiges Modell einer Anlage, das SCADA-Messwerte mit dem Wissen darüber kombiniert, wie sich die Maschine verhalten sollte, sodass Betreiber entgangenen Ertrag, aufgelaufene Lasten und sich anbahnende Fehler erkennen. Dieser Artikel erklärt die wichtigsten Anwendungsfälle, wie SCADA-Daten auf MQTT gelangen und wie Sie eine einfache Abweichung von der Leistungskurve berechnen, die Sie selbst ausführen können.
Warum Windkraftanlagen ideale Kandidaten für digitale Zwillinge sind
Windkraftanlagen stehen abgelegen, sind teuer zu erreichen und arbeiten unter ständig wechselnden Bedingungen. Ein Technikereinsatz kann eine lange Anfahrt oder ein Schiff erfordern, dazu geeignetes Wetter zum Aufstieg. Jede Entscheidung, die sich anhand von Daten statt eines Vor-Ort-Besuchs treffen lässt, spart Geld und Risiko.
Windkraftanlagen sind zudem gut instrumentiert. Die Anlagensteuerung und das Parkleitsystem (SCADA) erfassen bereits Windgeschwindigkeit, Windrichtung, Rotor- und Generatordrehzahl, Pitchwinkel, Gierposition, Wirkleistung, Temperaturen im gesamten Triebstrang und eine lange Liste von Statuscodes. Das Rohmaterial für einen Zwilling ist vorhanden; die Herausforderung besteht darin, es zugänglich zu machen und in Kontext zu setzen. Zum allgemeinen Konzept siehe den Leitfaden zur Digital-Twin-Technologie.
Drei zentrale Anwendungsfälle
Ertrag: Leistung im Vergleich zur Leistungskurve
Jeder Anlagentyp hat eine Referenz-Leistungskurve: die erwartete Leistung bei jeder Windgeschwindigkeit. Der Zwilling vergleicht die tatsächliche mit der erwarteten Leistung bei der gemessenen Windgeschwindigkeit, gefiltert auf gültige Betriebsbedingungen. Anhaltende Minderleistung in einem bestimmten Windgeschwindigkeitsbereich kann auf eine Pitch-Fehlstellung, einen Gierfehler, verschmutzte oder vereiste Rotorblätter oder eine Steuerungseinstellung hindeuten.
Lasten: Ermüdungsverbrauch verfolgen
Strukturbauteile wie Rotorblätter, Turm und Hauptwelle akkumulieren Ermüdung durch zyklische Belastung. Manche Anlagen haben Lastsensoren, bei anderen werden die Lasten mit Modellen aus Betriebsdaten geschätzt. Ein Zwilling, der die geschätzte Lasthistorie je Anlage verfolgt, hilft Betreibern, Anlagen im selben Park zu vergleichen, und unterstützt Entscheidungen zum Weiterbetrieb. Lastschätzmodelle sind Spezialistenarbeit, meist vom Hersteller oder von Ingenieurbüros geliefert, aber der Zwilling stellt den Datenpfad bereit, den sie brauchen.
Wartung: Komponentenzustand
Triebstrangtemperaturen, Schwingungen aus Condition-Monitoring-Systemen und Partikelzählungen im Öl zeigen sich entwickelnde Schäden an Getrieben, Lagern und Generatoren. Ein Zwilling, der die Temperaturen jeder Anlage mit denen ihrer Nachbarn bei ähnlicher Last vergleicht, ist ein einfaches und wirksames Frühwarnsystem. Der allgemeine Ansatz wird in Predictive Maintenance mit dem digitalen Zwilling behandelt.
| Anwendungsfall | Zentrale Signale | Typische Aktualisierungsrate | Hauptnutzer |
|---|---|---|---|
| Ertrag | Windgeschwindigkeit, Wirkleistung, Pitch, Gierwinkel, Status | 1 s bis 10-Minuten-Mittelwerte | Performance-Ingenieure |
| Lasten | Rotordrehzahl, Pitch, Leistung, Lastsensoren falls vorhanden | Hohe Rate an der Edge, zusammengefasst | Asset Manager, Engineering |
| Wartung | Getriebe-, Lager- und Generatortemperaturen, Schwingung, Öldaten | Sekunden bis Minuten | Instandhaltungsplaner |
| Betrieb | Statuscodes, Alarme, Verfügbarkeit | Bei Änderung | Leitwarte |
SCADA-Daten auf MQTT bringen
SCADA-Systeme von Windparks stellen Daten typischerweise über OPC UA, Modbus, Schnittstellen auf Basis von IEC 61400-25 oder Herstellerdatenbanken bereit. Das übliche Muster ist ein Edge-Gateway im Umspannwerk oder Betriebsgebäude:
- Das Gateway liest Anlagendaten vom SCADA-Server oder direkt von den Anlagensteuerungen.
- Es veröffentlicht Messwerte über TLS auf MQTT-Topics, über die ausgehende Internetverbindung des Standorts.
- Cloud- oder zentrale Dienste abonnieren die Topics, berechnen Zwillingsergebnisse und speichern die Historie.
MQTT eignet sich aus bekannten Gründen für abgelegene Energiestandorte: Es ist sparsam auf eingeschränkten Verbindungen, die Verbindung geht vom Standort nach außen, sodass keine eingehenden Firewall-Ports nötig sind, und persistente Sessions mit QoS 1 helfen, kurze Verbindungsabbrüche zu überbrücken. Mit einem Cloud-MQTT-Broker veröffentlichen Parks in verschiedenen Regionen an einen Endpunkt, und das Betriebsteam muss nicht an jedem Standort Broker-Server pflegen.
Wichtig: Das Gateway sollte SCADA nur lesen. Steuerbefehle an Anlagen gehören in die zertifizierten Steuerungssysteme und deren geschützte Netzwerke. Betreiber, die unter NIS2 fallen, sollten diese Zonentrennung zum Beispiel nach IEC 62443 dokumentieren.
Topic- und Payload-Design
Ordnen Sie Topics nach Park und Anlage, dann nach Datentyp:
connectmq/<farm>/<turbine>/<data-type>
connectmq/northridge/wtg07/operation
connectmq/northridge/wtg07/drivetrain
connectmq/northridge/wtg07/status
connectmq/northridge/met-mast1/weather
Betreiben Sie mehrere Parks oder auch Umspannwerke und Speicher, lohnt es sich, diese Struktur als Unified Namespace (UNS) anzulegen: Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem MQTT-Broker, also Unternehmen, Windpark, Anlagengruppe, Anlage und Komponente, etwa acme/windpark-nordsee/cluster-a/wea-07/triebstrang. Leitwarte, Instandhaltung und Zwilling greifen dann auf dieselbe Struktur zu; das Prinzip erklärt Sparkplug B und Unified Namespace.
Eine Betriebs-Payload im Zehn-Sekunden-Takt:
{
"windSpeedMs": 9.4,
"windDirDeg": 251,
"yawDeg": 248,
"rotorRpm": 13.8,
"pitchDeg": 0.5,
"activePowerKw": 1985,
"ts": "2026-10-16T09:41:20Z"
}
Veröffentlichen Sie Statusänderungen (in Betrieb, abgeregelt, Störung, Wartung) als Retained Messages, damit ein Zwillings-Viewer immer den aktuellen Modus jeder Anlage kennt. Nutzen Sie die Message Expiry von MQTT 5 für Betriebswerte, damit eine Anlage, deren Gateway offline geht, nicht aufgrund veralteter Daten als produzierend erscheint.
Praxis: Abweichung von der Leistungskurve in Python
Das folgende Beispiel läuft gegen broker.connectmq.com mit simulierten Anlagendaten. Es enthält eine kleine Referenz-Leistungskurve, einen Simulator, der bei mittleren Windgeschwindigkeiten leicht unterdurchschnittlich arbeitet, und einen Zwillingsdienst, der ein gleitendes Leistungsverhältnis veröffentlicht. Verwenden Sie nur simulierte Werte, denn der öffentliche MQTT-Broker ist für Tests und Prototypen gedacht und für alle lesbar.
import json
import random
import time
import uuid
from collections import deque
import paho.mqtt.client as mqtt
RUN = "wtg-91be" # change to your own unique id
BASE = f"connectmq/demo/{RUN}/northridge/wtg07"
# Illustrative reference power curve: wind speed (m/s) -> power (kW)
CURVE = [(3, 0), (4, 80), (5, 200), (6, 380), (7, 620), (8, 950), (9, 1350),
(10, 1750), (11, 2050), (12, 2200), (25, 2200)]
def expected_kw(ws):
if ws < CURVE[0][0] or ws > CURVE[-1][0]:
return 0.0
for (x0, y0), (x1, y1) in zip(CURVE, CURVE[1:]):
if x0 <= ws <= x1:
return y0 + (y1 - y0) * (ws - x0) / (x1 - x0)
return 0.0
window = deque(maxlen=60)
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe(f"{BASE}/operation", qos=1)
def on_message(client, userdata, msg):
d = json.loads(msg.payload)
exp = expected_kw(d["windSpeedMs"])
if exp > 100: # ignore very low wind where the ratio is noisy
window.append((d["activePowerKw"], exp))
if len(window) >= 10:
actual = sum(a for a, _ in window)
expected = sum(e for _, e in window)
ratio = round(actual / expected, 3)
client.publish(f"{BASE}/twin/performance",
json.dumps({"performanceRatio": ratio, "samples": len(window)}),
qos=1, retain=True)
print("performance ratio", ratio)
twin = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"wtg-twin-{uuid.uuid4().hex[:6]}")
twin.on_connect = on_connect
twin.on_message = on_message
twin.connect("broker.connectmq.com", 1883, keepalive=30)
twin.loop_start()
sim = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"wtg-sim-{uuid.uuid4().hex[:6]}")
sim.connect("broker.connectmq.com", 1883, keepalive=30)
sim.loop_start()
try:
while True:
ws = max(0.0, random.gauss(9, 2))
loss = 0.92 if 7 <= ws <= 10 else 1.0 # simulated underperformance
power = expected_kw(ws) * loss * random.uniform(0.97, 1.02)
sim.publish(f"{BASE}/operation",
json.dumps({"windSpeedMs": round(ws, 2), "activePowerKw": round(power, 1), "ts": time.time()}),
qos=1)
time.sleep(2)
except KeyboardInterrupt:
pass
Das Verhältnis pendelt sich unter 1,0 ein und macht den simulierten Verlust sichtbar. Eine echte Analyse ergänzt Filter für Abregelung, Störungen, Luftdichtekorrektur und Windsektor, aber der Datenfluss bleibt identisch: SCADA-Werte hinein, Zwillingsergebnisse zurück an MQTT für Viewer und Alarme.
Checkliste für das Deployment
- Vereinbaren Sie mit dem Anlagenhersteller und dem Standortbetreiber einen reinen Lesezugriff auf die SCADA-Daten.
- Platzieren Sie das Gateway in einem abgetrennten Netzwerk mit ausschließlich ausgehendem TLS auf Port 8883.
- Verwenden Sie je Standort-Gateway eine eigene Zugangskennung und Client ID; ConnectMQ bindet Client IDs an die ausgegebenen Zugangsdaten.
- Aktivieren Sie persistente Sessions und QoS 1 für Status- und Alarm-Topics, damit kurze Verbindungsausfälle keine Ereignisse verlieren.
- Veröffentlichen Sie gemittelte Werte für Langzeitanalysen und Werte mit höherer Rate nur dort, wo ein Anwendungsfall sie braucht.
- Speichern Sie die Historie mit einem separaten Subscriber in einer Zeitreihendatenbank.
- Ergänzen Sie Alarme für offensichtliche Zustände, etwa eine Getriebetemperatur über einem Grenzwert, mit den Schwellenwertregeln des Portals oder Ihrem eigenen Dienst.
- Validieren Sie die Zwillingsergebnisse gegen die bestehenden Berichte des Betreibers, bevor Sie sich darauf verlassen.
Häufige Stolpersteine
- Gondelanemometer-Daten unkritisch nutzen. Der Rotor verfälscht die Messung; Betreiber wenden oft eine Gondel-Transferfunktion an. Vergleichen Sie zwischen Anlagen nur Gleiches mit Gleichem.
- Abregelung nicht herausfiltern. Abgeregelte Zeiträume wirken wie massive Minderleistung, wenn sie nicht über Statuscodes ausgeschlossen werden.
- Abweichende Zeitzonen und Zeitstempel zwischen SCADA-Servern und Gateways.
- Steuerung und Überwachung vermischen. Halten Sie den Zwilling schreibgeschützt, sofern die Steuerungsarchitektur Fernbefehle nicht ausdrücklich unterstützt.
Dieselben Muster gelten für andere Industrieanlagen in den Artikeln zum digitalen Zwilling der Fabrik und zum digitalen Zwilling für Energie.
Verbinden Sie Ihren Windpark mit ConnectMQ
ConnectMQ ist ein verwalteter MQTT-Broker mit TLS, MQTT 5 sowie Dedicated- oder BYOC-Optionen für Betreiber, die Isolation benötigen. Starten Sie kostenlos unter app.connectmq.com mit dem Serverless-Tarif, ohne Kreditkarte, und streamen Sie Ihre ersten Anlagendaten in wenigen Minuten.
Häufig gestellte Fragen
Welche Daten nutzt ein digitaler Zwilling der Windkraftanlage?
Hauptsächlich SCADA-Daten: Windgeschwindigkeit und -richtung, Rotordrehzahl, Pitch, Gierwinkel, Wirkleistung, Triebstrangtemperaturen und Statuscodes, dazu Condition-Monitoring- und Lastdaten, sofern verfügbar.
Kommt MQTT mit Daten aus abgelegenen Windparks zurecht?
Ja. MQTT ist schlank, funktioniert mit rein ausgehenden Verbindungen und unterstützt QoS 1 mit persistenten Sessions, was zu abgelegenen Standorten mit begrenzten oder instabilen Verbindungen passt.
Sollte ein digitaler Zwilling Befehle an die Anlagen zurücksenden?
In der Regel nicht. Die meisten Zwillinge sind reine Überwachungs- und Analysewerkzeuge; die Anlagensteuerung bleibt in den zertifizierten Steuerungssystemen.
Wie wird die Leistung gegenüber der Leistungskurve gemessen?
Die tatsächliche Leistung wird mit der erwarteten Leistung aus einer Referenz-Leistungskurve bei der gemessenen Windgeschwindigkeit verglichen, nachdem Abregelung, Störungen und ungewöhnliche Bedingungen herausgefiltert wurden.
