With large-scale renewable energy grid integration today, an onshore wind farm is no longer just a collection of assets with turbines spread across complex terrain. It is a highly dispersed operations site where generating efficiency, turbine health, equipment life, and maintenance cost are tightly bound together.
For wind farm operators, the real challenge is not a lack of data. When blades, main shafts, generators, converters, pitch systems, met masts, and grid connection points all keep producing data at the same time, the control center still struggles to answer the most important questions right away. At the same wind speed, why does unit 3 produce 200 kW less than the other 15 turbines? The converter temperature on unit 6 has been creeping up for two days. Does the duty operator get a chance to step in before the turbine trips? Is the vibration you are seeing a normal characteristic of this turbine, or a sign that the blades are quietly degrading?
This is also the dividing line that is becoming clearer as onshore wind operations move into fine-grained management. What enterprises need is no longer just connecting turbine data and building SCADA dashboards, but letting data truly support judgment, explain anomalies, and help the site act faster.
16 units fighting alone: a distributed yet highly comparable operations site
Before discussing the data challenges of a wind farm, it is worth clarifying one thing first. A wind farm is physically different from most industrial monitoring scenarios. In a centralized factory, all equipment sits in the same building in front of the same console, and the propagation path of an anomaly is clearly visible. Even a centralized PV plant, though the strings are spread out, converges on a limited number of inverters, so it is still essentially centralized control. An onshore wind farm, by contrast, has 16 2.0 MW permanent magnet direct-drive turbines at a single site, 32 MW of total capacity, with turbine positions spread across hills or Gobi terrain over several square kilometers. Each turbine is a power generating unit that fights almost on its own. They share no gearbox, no inverter, no blade, and even the wind over their heads at any moment is not quite the same.
This distributed yet highly comparable shape gives wind farm operations a maintenance meaning that is completely different from any other scenario.
From a spatial standpoint, turbines sit hundreds of meters or even kilometers apart, and a manual inspection run can take a whole day in an off-road vehicle. Remote siting means that both finding and resolving a problem carry far higher response costs than at a city substation. From an independence standpoint, each turbine has its own complete drive train, pitch system, converter, and tower. They are independent yet similar. Independent enough that one unit’s fault will not directly drag down its neighbors, and similar enough that the historical data of 16 turbines forms a natural lateral control group. From a driving-source standpoint, wind is a highly random input. Cut-in wind speed is 3 m/s, rated wind speed is 12 m/s, and cut-out wind speed is 25 m/s. Within the same wind farm, turbines on the windward side and the leeward side can feel wind speeds that differ by 30%. A turbine’s normal performance simply cannot be defined by one static curve. It has to be judged against the real wind conditions of that moment.
It is precisely because of these differences that the wind farm data challenge cannot be solved by simply adding more sensors and more alarms. With 8,760 operating hours a year and a scale where one day of lost full-capacity output on any turbine means 48,000 kWh of electricity flowing away, what the operations center really needs to answer is not which turbine has stopped. It needs to answer whether this turbine’s performance deserves the wind speed it is seeing, whether it is drifting away from the common level of its neighboring units, and whether today’s silence hides tomorrow’s fault. None of these three questions can be answered from a single-point reading.
Three kinds of silence: alarms that never sound and power that quietly leaks away
Wind farms are not short of alarms. In the red and yellow entries that SCADA pushes every day, tower-base vibration, pitch faults, and grid connection anomalies have never been absent. But if you watch where frontline maintenance teams actually get stuck, the problem is usually not that nobody saw it, but that they saw it and did not realize what it meant. The following three kinds of silence happen in almost every operating wind farm that has been running for years, all at the same time.
Silence 1: the silence of pitch angle deviation. The pitch angle of blade A on unit 3 drifts slowly from a baseline of 8.3° to 9.8°, and the pitch angle dispersion climbs gradually from 0.12° to 0.82°. None of the individual values triggers a routine red alarm by itself. On the SCADA curve it looks like a slight drift, and it may even be classified by the rules engine as normal fluctuation. But this deviation is a direct signal that the aerodynamic surface of blade A has changed from long-term wind and sand erosion on the leading edge. If nobody compares the pitch angle of unit 3 with the other 15 turbines while the value is still normal, this deviation stays silent until main-shaft vibration climbs to 3.8 mm/s dozens of hours later and the turbine derates to 1465 kW. Only then does the maintenance team start chasing the problem, and by that point two and a half days of generation have already been lost.
Silence 2: the silence of lateral comparison. The independent nature of wind farm turbines means they can support lateral comparison across units. Under the same wind window, the power curves of 16 turbines are expected to be broadly consistent. But traditional monitoring screens are never organized that way. Each turbine has its own set of dashboards. When the duty operator opens unit 3 and sees 1720 kW, the first reaction is that it matches the current wind speed. He does not open the screens of the other 15 turbines at the same time and compare their power side by side. If he did, he would immediately notice that at the same 11 m/s wind speed, the other 15 turbines are all around 1950 kW and only unit 3 has fallen to 1720 kW, a 12% power deviation far beyond any normal dispersion range. The data has often been there. The problem is that every turbine is watched as an individual, when they should be understood as a comparable group.
Silence 3: the silence of slow temperature rise. On unit 6, the converter inlet air temperature rises slowly from 32°C to 36°C and the IGBT junction temperature rises slowly from 65°C to 73°C. Each instantaneous value stays below the traditional alarm threshold, the rules engine stays quiet, and the duty operator’s phone does not buzz. But this slow rising trend is the direct reflection of the cooling duct filter being gradually blocked by dust and lint. When the junction temperature finally breaks 85°C and triggers a warning 24 hours later, the cooling headroom is already exhausted. Ten hours later the junction temperature hits 91°C and the turbine derates itself to 1560 kW. A few hours after that it reaches 95°C and the overtemperature protection shuts the turbine down. Many wind turbine faults are not sudden breakage. The turbine has long since entered a degrading spiral, and nobody connected those readings that looked normal during the gradual change into a trend.
These three kinds of silence point to the same conclusion. Wind farm operations are never stuck because there is not enough data. They are stuck because lateral comparison is not done, gradual trends are not watched, and a single turbine’s deviation is not read as a group signal. No matter how many SCADA screens there are, if every turbine’s readings are only evaluated independently and only sound off when a threshold is crossed, the maintenance team can only keep chasing losses after the fact. And what actually drives up economic loss is never the number of alarms. For unit 3, the four days of blade aerodynamic imbalance lost about 33,705 kWh in total, an economic loss of about US2,190.Forunit6,thefourdaysofconverteroverheatinglostabout12,333kWh,aneconomiclossofaboutUS800. Behind both figures is the same pattern. The data arrived, but the lateral comparison did not. The trend was there, but the early action did not.
From passive monitoring to proactive judgment: reorganizing the data pipeline
Object modeling: scattered units return to a unified operational view
The judgment problem at a wind farm does not come from the number of turbines or sensors. It comes from how the data is organized. TDengine uses a tree hierarchy to map wind turbines, met masts, grid connection points, and other objects into a clear data catalog, and each node can carry attributes, analyses, dashboards, events, and associated documents. After object modeling, the A/B/C/D unit zones and the site control system are no longer a scattered collection of time-series measurement points but understandable objects on the same chain from wind capture and drive conversion to converter grid connection. The 16 turbines are no longer 16 separate dashboards but an operating group that can be compared as a whole and drilled into unit by unit.
Figure 1: A tree hierarchy organizes plant assets and measurement points into a unified operational view
This change has a very direct meaning for wind farm operators. In the past, many turbine anomalies were hard to judge not because there was no historical data, but because the same data point represented different health states under different wind speeds, seasons, and turbine positions. Vibration of 1.8 mm/s on a windward turbine is normal. The same 1.8 mm/s on a leeward turbine can already signal a blade anomaly. Only after data structure, asset relationships (site, zone, turbine, component), and operational context are sorted out can later analysis and judgment have a common foundation. Once a unified entry point is built around the object, the maintenance team no longer sees scattered measurement points but operational objects that can be understood together with wind speed, turbine position, and neighbor status.
Real-time analysis and event linkage: alarms regain full process context
Detecting an anomaly alone is not enough to improve wind farm response. What a wind farm needs is that once an anomaly appears, the system can also present the key context around it at the same time. Which turbine the power deviation happened on, what wind condition it corresponds to, whether it is already affecting the downstream converter and grid connection point, and whether it is forming an obvious contrast with other turbines. On top of data modeling, TDengine adds real-time analysis, event management, and alarm linkage. It monitors the data stream continuously, generates KPIs, detects anomalies, and triggers events on its own, then organizes each event together with the associated asset, duration, severity, and context trend instead of just throwing out an isolated alarm.
Take the rising pitch angle dispersion as an example. The site does not only need to know that a blade pitch angle has drifted. It also needs to see the linked changes in nacelle vibration, main-shaft speed, active power, and pitch battery voltage at the same time, to judge whether this is normal regulation from a wind disturbance or a sustained decay in blade aerodynamic performance. When the converter inlet air temperature alarm comes up, it cannot only stare at the temperature value itself, but should combine IGBT junction temperature, cooling fan operating state, active power, and overtemperature alarm state to judge whether it is moving toward overtemperature shutdown. The real value is not how many new alarms were added, but that anomalies finally have a process context that can be explained.
Figure 2: General information settings for real-time analysis
Figure 3: Trigger conditions for real-time analysis
Figure 4: Action after the real-time analysis is triggered
TDengine offers a natural-language query capability that turns a plain-language description of a real-time analysis requirement into a real-time analysis task after AI-assisted parsing, which greatly lowers the difficulty and barrier of manual configuration. TDengine also offers a proactive recommendation capability that senses the scenario on its own and recommends the real-time analysis tasks that should be created for it, further reducing dependence on wind power domain knowledge and lowering the difficulty of data analysis.
Process analysis and AI-assisted insight: judgment shifts from experience-driven to evidence-driven
Once data is organized into object relationships and anomalies can be explained along the drive chain and electrical chain, insight no longer depends only on a few experienced site managers. Maintenance teams, control center operators, equipment administrators, and asset managers can all share the same basis for judgment around the same time axis, the same operational object, and the same set of key indicators. Coordination shifts from everyone watching their own turbine to forming a consistent judgment around the same facts, and fault locating and handling become faster and more stable.
TDengine provides natural-language Q&A for process analysis, correlation analysis, regression, batch comparison, anomaly discovery, and dashboard interpretation, helping users move from what happened to why it happened. Troubleshooting that used to require repeated confirmation across multiple systems and multiple specialties can now be done more often within the same object, event, and analysis chain. What the operations site faces is no longer just knowing that a turbine’s data is abnormal, but being able to form an evidence-backed judgment faster and turn that judgment into action.
Figure 5: AI interpretation and data mining on the analysis panel
Based on the anomaly events that occur, TDengine supports AI root-cause analysis. It searches relevant historical data, forms hypotheses about the cause, validates those hypotheses, and generates a structured analysis report, reducing manual back-and-forth, greatly reducing dependence on IT skills and industry knowledge and experience.
Figure 6: AI root-cause analysis of an event
Closed-loop analysis in typical anomaly scenarios
Blade aerodynamic imbalance scenario: judgment path from pitch angle deviation to power derating
In the blade aerodynamic imbalance scenario, the earliest signal captured by the system is not the final nacelle vibration but a small deviation inside the pitch system. The pitch angle of blade A on unit 3 drifts slowly from a baseline of 8.3° to 9.8°, the pitch angle dispersion rises from 0.12° to 0.82%, breaks the 0.5° alarm threshold, and stays there for more than 30 minutes, triggering the Warning alarm in the resident rules. Right behind it, nacelle X-direction vibration climbs from 1.5 mm/s to 2.6 mm/s and breaks the 3.0 mm/s alarm line the next day, triggering the Major alarm. The two resident rules mesh one after the other, bringing a process that would otherwise be split into a pitch event and a vibration event into a single anomaly that needs to be traced immediately, no longer an isolated pitch angle drift but an aerodynamic anomaly that is already affecting the health of the whole turbine.
After the alarm triggers, the site adds the event to the analysis workbench and runs a three-step trace around unit 3 and its neighboring turbines to judge the nature of the anomaly, the degree of its evolution, and its business impact.
Step 1: lateral comparison confirms the unit-level anomaly. Overlay the pitch angle curves of unit 3 and the other 15 turbines on the same time axis. In the figure, the blade A pitch angle of unit 3 deviates clearly, more than 1.5° above the site-wide average baseline, while the B and C blade pitch angles still sit on the baseline. Over the same period the three-blade pitch angles of the other 15 turbines are consistent, all maintaining dispersion within 0.15°. This shows it is not a site-wide wind disturbance and not a strategy change in the pitch algorithm, but a permanent offset on blade A of unit 3 itself, most likely a change in the aerodynamic surface from long-term wind and sand erosion of the leading edge. The nature of the anomaly is now clear.
Step 2: trace the vibration source and drive train impact. Continue by placing nacelle X-direction vibration, Y-direction vibration, and main-shaft speed on the same time axis. In the figure, nacelle X-direction vibration rises monotonically from 1.5 mm/s to 3.8 mm/s, and the main-shaft speed waveform shows a regular once-per-revolution impact. This is the typical 1P vibration signature, matching exactly the periodic excitation produced by uneven aerodynamic force on one of the three blades. At this point the pitch battery voltage also starts to decline. Channel A voltage drops from 384V to 358V, breaks the 360V threshold, and triggers a Critical alarm, showing that the high-frequency pitch compensation is draining the battery faster, and the cascade effect has begun. Looking at vibration values alone cannot explain this battery undervoltage chain reaction.
Step 3: quantify the impact on site-wide generating capability. Extend the trace to the power curve layer. In the figure, at 11 m/s wind speed unit 3 produces only 1720 kW while the other 15 turbines generally reach around 1950 kW in the same wind window, a 12% power deviation far beyond the -10% alarm line. The system then derates the turbine to 1465 kW, and the power loss widens further. At this step the nature of the anomaly, the evolution process, and the business impact all close the loop. Leading-edge erosion on blade A causes aerodynamic imbalance, vibration excitation raises the pitch battery load, the turbine is derated protectively, and generation keeps losing output all day. The operations center issues a work order from this, schedules blade repair and pitch battery replacement on day 4, completes the repair and reconnects to the grid at 11:00 on day 7, and measured vibration recovers to 1.4 mm/s with power back at 1960 kW. The whole event lost about 33,705 kWh over four days, an economic loss of about US2,190atafeed−intariffofaboutUS0.065 per kWh.
Figure 7: Blade aerodynamic imbalance scenario, judgment path from pitch angle deviation to power derating
Around this closed analysis loop, a few key conclusions come into focus. The pitch angle dispersion, an unimpressive auxiliary parameter, shows the anomaly about 20 hours earlier than nacelle vibration and is the earliest sentinel in this evolution. Lateral comparison across the 16 turbines is the key tool for pulling a real anomaly out of a plausible explanation. Looking at unit 3’s power curve alone can never explain the problem. One comparison exposes it. The drop in pitch battery voltage reveals an easily overlooked cascade path. The aerodynamic anomaly is not just a blade problem. Through high-frequency regulation it passes the burden on to the electrical system.
Inverter IGBT overtemperature scenario: judgment path from inlet temperature rise to overtemperature shutdown
In the inverter IGBT overtemperature scenario, the earliest alarm also comes from a resident rule, but the entry point is not the final high junction temperature but the inlet air temperature upstream in the cooling chain. On unit 6, the converter inlet air temperature rises slowly from a baseline of 32°C to 36°C, breaks the 35°C alarm threshold, and stays there for more than 20 minutes, triggering a Warning alarm. A few hours later the IGBT junction temperature climbs slowly from 65°C to 73°C and breaks the 85°C threshold in the early hours of the next day, staying above it for more than 30 minutes and triggering a Major alarm. A few hours after that the junction temperature hits 95°C, the overtemperature alarm bit flips to true, and the turbine goes straight into overtemperature shutdown with active power dropping instantly to zero. The three alarms mesh one after the other, bringing a process that would otherwise be split into inlet air temperature, IGBT temperature, and shutdown events into a single evolution chain that needs to be traced immediately.
Once the event is added to the analysis workbench, the trace runs forward along the cooling chain, working through three groups of indicators inside the unit 6 converter.
Step 1: locate the root cause of cooling capability decay. Put inlet air temperature, IGBT junction temperature, and ambient temperature on the same chart for unit 6. In the figure, the ambient temperature stays roughly stable around 25°C while the converter inlet air temperature keeps rising monotonically. The outside environment has not changed but the internal inlet air is getting worse, so the problem must be inside the cooling duct itself. Overlay the cooling fan operating state as well. The fan keeps running and its speed shows nothing abnormal. Combining the two signals, the cooling fan is not broken and the outside temperature has not changed, so the only reasonable explanation is that the cooling duct filter is blocked by dust and lint. The inlet air volume has dropped while the fan still spins at full speed, creating the illusion of normal operation while heat rejection is actually failing.
Step 2: confirm the actual impact of overheating on performance. Continue by adding active power and conversion efficiency attributes to unit 6. In the figure, while the IGBT junction temperature rises from 65°C to 91°C, active power does not drop immediately. This is the most deceptive part of this kind of anomaly. The temperature is already alarming, but generating capability has not been affected, so the duty operator may easily assume it can just be watched for now. But when the junction temperature passes 91°C, the turbine protection system actively derates the unit to 1560 kW. Six hours later the junction temperature breaks 95°C and directly triggers overtemperature shutdown, with active power dropping from 1600 kW to 0 in an instant. If you also look at neighboring units 5 and 7 at this point, they are still generating at full capacity of 1980 kW under the same wind speed. That comparison again confirms this loss is entirely a single-unit fault on unit 6.
Step 3: quantify the impact on the site’s total output. Extend the trace to the grid connection point. In the figure, the total active output at POI-01 drops from around 30 MW to 28.4 MW during the unit 6 shutdown, and the gap exactly matches the rated capacity of one fully loaded turbine. On the morning of day 4 the maintenance team arrives and cleans the filter. At 10:00 the system returns to normal, with inlet air temperature back to 33°C, IGBT junction temperature back to 68°C, and active power recovered to 1960 kW. The whole event lost about 12,333 kWh over four days, an economic loss of about US$800.
Figure 8: Inverter IGBT over temperature scenario, judgment path from inlet temperature rise to over temperature shutdown
Following these three steps, a clear root-cause chain is fully reconstructed. The total output gap at the grid connection point comes from the unit 6 shutdown. The unit 6 shutdown comes from IGBT overtemperature protection. The IGBT overtemperature comes from cooling capability decay. The cooling capability decay comes from a blocked filter. And at the very top of this chain, the blocked filter has no direct measurement point at all. What lets the operations center trace back this root-cause chain is the elimination logic of putting three pieces of data together on the same chart. The ambient temperature has not changed, the fan speed is normal, but the inlet air temperature is still rising. The inlet air temperature, an auxiliary parameter, leads the IGBT overtemperature shutdown by about 26 hours, giving the maintenance team an extremely valuable preventive maintenance window. If this precursor had not been read, the chain would stay silent until the IGBT junction temperature spiked to 95°C before forcing a response.
Fine-grained wind farm operations: what is really needed is not more dashboards but stronger judgment capability
As wind farm operators push digitalization forward, what really sets the ceiling on digital value is no longer how much data has been connected or how many visualization screens have been built, but whether that data can form actionable judgment in the control room. For a scenario like an onshore wind farm, where turbines are dispersed, faults are hidden, and the site is remote, the hard part has never been collecting data. Once the data is plentiful, the hard part is how to read deviation faster in the lateral comparison of 16 turbines, read precursors in gradual trends, and turn that judgment into maintenance action.
The comparison data also shows the value of this shift. Anomaly discovery time drops from 1248 hours with manual patrols to under 5 minutes with real-time threshold alarms. Power curve deviation identification improves from ±8% in monthly offline statistics to ±1.5% in sliding-window real-time comparison. Blade imbalance detection rate rises from about 30% with manual perception to over 90% with multi-sensor combined analysis. Inverter thermal faults change from passive response after shutdown to trend warnings 26 hours in advance. Together these improvements support the transition from fixing after the fact to intervening during the process. Especially for remote turbine positions, a warning window a few hours in advance means the maintenance crew has enough time to arrive with the right spare parts, instead of frantically organizing repairs after the shutdown.
TDengine organizes scattered data into understandable operational objects, turns alarms into explainable process judgments, and further converts data capability into operational capability that supports generating efficiency, turbine health, and site availability, bringing more efficient, precise, and sustainable business results to the fine-grained operations of wind farms.
TDengine comes with a high-performance, distributed time-series database, Industrial Ontology modeling, and an Industrial Agent Runtime, providing a full-stack solution for industrial data streams from collection and storage to real-time analytics, visualization, event management, and root-cause analysis. To learn more about TDengine, visit www.tdengine.com and try it for free.
Try it yourself
Install and deploy TDengine Visit the TDengine Download Center, select TDengine All-in-One, choose the deployment platform and architecture that matches your environment, and follow the guided steps to complete the installation.
Load the sample data
On first activation, choose Wind Turbine Operations Analysis Scenario on the sample data loading screen and wait for it to finish loading.
If you have already activated the product, click your avatar in the top-right corner, select Management Console, choose Sample Data on the left, then select Wind Turbine Operations Analysis Scenario. Wait a few minutes for the data to load.
Wind Turbine Operations Analysis Scenario
