A wind turbine digital twin is a live model of a turbine that combines SCADA measurements with knowledge of how the machine should behave, so operators can see lost yield, accumulated loads and emerging faults. This article explains the main twin use cases, how to get SCADA data onto MQTT, and how to compute a simple power curve deviation that you can run yourself.
Why Wind Turbines Are Ideal Candidates for Digital Twins
Wind turbines are remote, expensive to access and operate under constantly changing conditions. A technician visit can require a long drive or a vessel, plus suitable weather for climbing. Every decision that can be made from data instead of a site visit saves money and risk.
Turbines are also well instrumented. The turbine controller and the farm SCADA system already record wind speed, wind direction, rotor and generator speed, pitch angles, yaw position, active power, temperatures throughout the drivetrain and a long list of status codes. The raw material for a twin exists; the challenge is making it accessible and putting it in context. For the general concept, see the digital twin technology guide.
Three Core Use Cases
Yield: performance against the power curve
Every turbine model has a reference power curve: expected output at each wind speed. The twin compares actual output with expected output for the measured wind speed, filtered for valid operating conditions. Persistent underperformance in a certain wind speed range can point to pitch misalignment, yaw error, blade contamination or icing, or a controller setting.
Loads: tracking fatigue consumption
Structural components such as blades, tower and main shaft accumulate fatigue from cyclic loading. Some turbines have load sensors; others estimate loads from operating data with models. A twin that tracks estimated load history per turbine helps operators compare units in the same farm and inform life extension decisions. Load estimation models are specialist work, usually supplied by the manufacturer or engineering consultants, but the twin provides the data path they need.
Maintenance: component health
Drivetrain temperatures, vibration from condition monitoring systems and oil particle counts reveal developing faults in gearboxes, bearings and generators. A twin that compares each turbine's temperatures against its neighbors under similar load is a simple and effective early warning. The general approach is covered in digital twin predictive maintenance.
| Use case | Key signals | Typical update rate | Primary users |
|---|---|---|---|
| Yield | Wind speed, active power, pitch, yaw, status | 1 s to 10 min averages | Performance engineers |
| Loads | Rotor speed, pitch, power, load sensors if fitted | High rate at the edge, summarized | Asset managers, engineering |
| Maintenance | Gearbox, bearing and generator temperatures, vibration, oil data | Seconds to minutes | Maintenance planners |
| Operations | Status codes, alarms, availability | On change | Control room |
Getting SCADA Data onto MQTT
Wind farm SCADA systems typically expose data via OPC UA, Modbus, IEC 61400-25 based interfaces or vendor databases. The usual pattern is an edge gateway in the substation or control building:
- The gateway reads turbine data from the SCADA server or directly from turbine controllers.
- It publishes measurements to MQTT topics over TLS through the site's outbound internet connection.
- Cloud or central services subscribe to the topics, compute twin outputs and store history.
MQTT suits remote energy sites for well-known reasons: it is lightweight on constrained links, the connection is outbound from the site so no inbound firewall ports are needed, and persistent sessions with QoS 1 help ride out short link interruptions. Using a cloud MQTT broker means farms in different regions publish to one endpoint, and the operations team does not maintain broker servers in each location.
Important: the gateway should only read from SCADA. Control commands to turbines belong to the certified control systems and their protected networks.
Topic and Payload Design
Organize topics by farm and turbine, then by data type:
connectmq/<farm>/<turbine>/<data-type>
connectmq/northridge/wtg07/operation
connectmq/northridge/wtg07/drivetrain
connectmq/northridge/wtg07/status
connectmq/northridge/met-mast1/weather
A ten-second operational payload:
{
"windSpeedMs": 9.4,
"windDirDeg": 251,
"yawDeg": 248,
"rotorRpm": 13.8,
"pitchDeg": 0.5,
"activePowerKw": 1985,
"ts": "2026-10-16T09:41:20Z"
}
Publish status changes (running, curtailed, fault, maintenance) as retained messages so a twin viewer always knows the current mode of every turbine. Use MQTT 5 message expiry on operational values so a turbine whose gateway goes offline does not appear to be producing on stale data.
Hands-On: Power Curve Deviation in Python
The example below runs against broker.connectmq.com with simulated turbine data. It includes a small reference power curve, a simulator that underperforms slightly at mid wind speeds, and a twin service that publishes a rolling performance ratio. Use simulated values only, because the public broker is readable by everyone.
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
The ratio settles below 1.0, revealing the simulated loss. Real analysis adds filters for curtailment, faults, air density correction and wind sector, but the data flow stays identical: SCADA values in, twin outputs published back to MQTT for viewers and alerts.
Deployment Checklist
- Agree read-only access to SCADA data with the turbine OEM and site operator.
- Place the gateway on a segregated network with outbound-only TLS on port 8883.
- Use one credential and client ID per site gateway; ConnectMQ binds client IDs to the issued credentials.
- Enable persistent sessions and QoS 1 for status and alarm topics so short link outages do not lose events.
- Publish averaged values for long-term analysis and higher-rate values only where a use case needs them.
- Store history with a separate subscriber in a time-series database.
- Add alerts for obvious conditions, such as gearbox temperature above a limit, using portal threshold rules or your own service.
- Validate twin outputs against the operator's existing reports before relying on them.
Common Pitfalls
- Using nacelle anemometer data naively. The rotor disturbs the measurement; operators often apply a nacelle transfer function. Compare like with like across turbines.
- Not filtering curtailment. Curtailed periods look like severe underperformance unless excluded using status codes.
- Time zone and timestamp mismatches between SCADA servers and gateways.
- Mixing control and monitoring. Keep the twin read-only unless the control architecture explicitly supports remote commands.
The same patterns apply to other industrial assets in the factory digital twin and energy digital twin articles.
Connect Your Wind Farm to ConnectMQ
ConnectMQ is a hosted MQTT broker with TLS, MQTT 5 and dedicated or BYOC options for operators who need isolation. Start free at app.connectmq.com with the Serverless plan, no credit card required, and stream your first turbine data in minutes.
Frequently Asked Questions
What data does a wind turbine digital twin use?
Mainly SCADA data: wind speed and direction, rotor speed, pitch, yaw, active power, drivetrain temperatures and status codes, plus condition monitoring and load data where available.
Can MQTT handle data from remote wind farms?
Yes. MQTT is lightweight, works with outbound-only connections and supports QoS 1 with persistent sessions, which suits remote sites with limited or unstable links.
Should a digital twin send commands back to turbines?
Generally no. Most twins are read-only monitoring and analytics tools; turbine control stays within the certified control systems.
How is power curve performance measured?
Actual output is compared with the expected output from a reference power curve at the measured wind speed, after filtering out curtailment, faults and abnormal conditions.
