OEM-agnostic failure-mode features for a mixed Vestas and Siemens Gamesa fleet should come from the physics of the gearbox, not from mapping one OEM’s channel names onto the other’s. Define the features from component geometry and shaft speed (gear-mesh orders, order-tracked spectra), compute them on a reconciled time base, and move them into a shared feature store one site or one feature at a time rather than in a single cutover.
How do I map Siemens Gamesa sensor tags to the Vestas channels my gearbox features use?
Because label conventions vary with the SCADA implementation, the practical order is reversed: define the feature from physics first, then map only the handful of channels that feature needs (a tachometer, the accelerometer nearest the stage, the temperature sensors nearest the bearing) for each OEM. A mapping built that way is small, and it is easy to re-check when either OEM revises a turbine model, which a one-time full-tag mapping is not.
TechnoLynx decides per failure mode between one shared feature and a per-OEM adapter and validates it on both fleets’ data; the first step, failure-mode framing, is scoped on the AI engineering for energy and utilities page.
IEC 61400-25 defines an information model for wind power plant monitoring and control: an abstract, communication-oriented representation of functions and devices, and the categories raw component data is processed into. Labels under IEC 61400-25-2:2015 follow a structured format such as WTurbine1.GBX.Temp, but the exact convention can vary with the SCADA implementation in use.
Naming conventions help, up to a point. SCADA International’s Global Wind Data Tag-List gives uniform names to roughly 1,400 tags and data points across turbine types, models and brands, and is built to comply with IEC 61400-25. A shared name does not make two sensors equivalent, though: an accelerometer on the planetary ring and one on the intermediate shaft can carry the same label category and still see different physics.
A paper presenting a wind turbine SCADA database notes that SCADA is available and standardised for most turbines, which makes algorithms easier to transfer between manufacturers, while the number of monitored sensors varies by manufacturer. Gonzalez et al. (2018) likewise found the channel count varies considerably between manufacturers and SCADA providers, with a minimum set that typically includes wind speed and direction, active and reactive power, rotational speed, pitch and yaw angles and ambient temperature.
Which gearbox failure modes produce OEM-agnostic failure-mode features?
In Carroll et al.’s data, gear tooth damage was the clearer candidate, because its signature is tied to tooth count and shaft speed. The gear meshing frequency is the number of teeth multiplied by the shaft’s rotation frequency, a property of the mechanical design rather than of any vendor’s tag scheme. Carroll et al. (2018), working on two gearbox models from different multi-MW turbine types, cite earlier literature that the magnitude and shape of the meshing frequency and its sidebands indicate a gear tooth issue. In their data, sidebands around the meshing frequency rose as failure approached and were visible six to seven months before a gear tooth failure.
Order tracking makes those spectra comparable across changing rotor speeds. Carroll et al. combined raw accelerometer data with tachometer data to offset the variable rotor speed, which allowed like-for-like trending in the run-up to failure. Expressed in orders (multiples of shaft speed), the meshing component does not move with rotor speed; in their order-tracked figure it sat at order 6. That fixed position is why an order-domain feature defined on one OEM’s drivetrain can be computed on the other’s once tooth counts and the speed reference are known.
Bearing faults are less obliging. Carroll et al. extracted 30 magnitude readings either side of each of the first four ball passing frequencies at 0.25 Hz spacing, 240 inputs in total, but found no visible trend before planetary-stage bearing failures because of the noise around those frequencies. On the SCADA side, the gearbox temperature sensors closest to the failing planetary bearing, and their deltas, carried the most weight, while gear oil temperature ranked low. A feature whose value depends on which sensor sits nearest the bearing is, by construction, tied to each OEM’s sensor placement.
Decision table: shared feature or per-OEM adapter
| Failure mode | Physics anchor | Transfer across OEMs | What it needs per OEM |
|---|---|---|---|
| Gear tooth damage (intermediate or high-speed stage) | Meshing frequency and sidebands in an order-tracked spectrum | Good candidate for one shared definition | Tooth counts, a tachometer signal, a comparably placed accelerometer |
| Planetary bearing fault (vibration) | Ball passing frequency bands | Definition transfers; the signal was buried in noise in Carroll et al. (2018) | Per-OEM validation before trusting it |
| Bearing temperature (SCADA) | Temperature delta near the failing bearing | Placement-specific | Explicit mapping of which sensor sits nearest which bearing |
Physics features need accurate bearing dimensions and tooth counts per turbine model, and placement or sampling differences can still bias comparability after the physics is anchored.
Is there a standard vibration and SCADA feature set for gearbox RUL?
The SCADA literature shows no agreed feature set. Chesterman et al. (2023), reviewing normal-behaviour modelling on SCADA data, describe papers using small expert-selected signal sets, large sets reduced automatically, or selection by turbine subsystem, and note that no thorough comparison of these approaches had been done. For scale, Carroll et al. used 27 SCADA inputs for the bearing issue, 12 for the tooth issue, and 252 vibration inputs from the first four meshing harmonics.
Pooled models hide per-OEM offsets
Pooling training data across turbines eases maintenance but is not without risks. Chesterman et al. trained one model per signal per farm to keep the maintenance burden acceptable to operators, and pointed out that structural differences, such as one generator bearing always running 1 or 2 °C warmer under the same conditions, are not modelled unless turbine dummies are added. Their fleet-median subtraction removes farm-wide effects as long as more than half the turbines behave normally, and it was applied to farms of a single turbine type. In a mixed fleet we would compute that median within each OEM and model group, not across the whole site, so one OEM’s systematic offset does not read as the other’s fault.
Transfer between turbines is possible with modest data, with limits. A 2024 arXiv study on autoencoder anomaly detection found transfer-learned models fine-tuned on one to three months of target data matched baselines trained on a full year, with decoder fine-tuning performing best. The same paper summarises Zgraggen et al., for whom cross-farm transfer involved more non-linear domain shifts than transfer within a farm. Once a model is running at a site it was not trained on, telling sensor-driven shift from real degradation is its own problem, covered in catching distribution drift before the model fails silently.
How should I resample or window vibration data when two sites log at different rates?
If the rates differ moderately, downsample the faster stream to the slower one with an anti-aliasing filter before windowing. If they differ by an order of magnitude, or the slower rate cannot represent the fault frequencies, compute order-domain features at each site’s native rate and compare the features rather than the raw signals.
TechnoLynx builds resampling and windowing into the historian integration so features stay comparable on both sites’ native rates; the first step is framing the rate disparity and which degradation signals must stay detectable.
A 2021 arXiv study on the MAFAULDA dataset found that dropping from 50 kHz to 1 kHz caused a statistically significant fall in failure classification, with small to medium effect sizes. Shortening the window from 5 seconds to 0.1 seconds also hurt, and the authors judged the window effect the more pronounced of the two. The highest frequencies were used by the model only at the high rate with the long window. The authors also concluded that the processing pipeline should be optimised per configuration, and that industrial noise and scarce labels make the choice more context-dependent still.
Window length follows from the frequency resolution needed. Frequency resolution is the reciprocal of record length, so Carroll et al.’s 0.25 Hz bin spacing implies records of at least 4 seconds; their files held 10 seconds of data above 25 kHz. We would size the window to contain several revolutions of the slowest shaft whose fault you care about, at the lowest sampling rate present, and no longer, since an overly long window smears the onset of a transient. For the slow planetary stage that pushes toward long records, which is where order tracking earns its place, because rotor speed changes within the window.
Units and sensor brands in one pipeline
In one 2026 study, mixed units and acquisition settings were handled without per-brand tuning. The 2026 Multi-Dimensional Entropy study drew on 57,643 labelled vibration records from 12 wind farms, with sensor brands reporting in g and m/s² and sampling at 12,800 Hz for 10.24 s or 25,600 Hz for 5.12 s. Both configurations yield 131,072 samples per record (12,800 × 10.24 and 25,600 × 5.12), though the longer record gives twice the frequency resolution. The authors used one parameter set across all brands and sampling configurations, saw negligible variation between the two configurations, and kept accuracy above 99% on 4,152 unseen records from three further farms. Two limits apply: the features are a front-end quality screen ahead of fault diagnosis, and further validation is required for other drivetrain types and turbines from other manufacturers. Converting units is the easy part (1 g is 9.80665 m/s²); historian gaps and irregular timestamps are what make consistent resampling hard.
Will naive resampling distort features like bearing temperature slope or vibration RMS?
Yes, it can. Simple decimation or forward-filling changes what rate-of-change and energy features measure, so a unified pipeline has to aggregate in a physically aware way. Taking every nth sample without filtering lets content above the new Nyquist limit fold back into the band you keep; SciPy’s decimate, by contrast, applies an order 8 Chebyshev type I anti-aliasing filter by default before downsampling. The same function recommends zero-phase filtering to avoid phase shift and repeated calls for IIR downsampling factors above 13. Notably, the 1 kHz condition in the MAFAULDA study was produced by keeping every 50th point, so its measured loss reflects plain decimation rather than filtered downsampling.
Ten-minute SCADA has already lost much of the short-timescale information. Chesterman et al. describe 10-minute averages, with minimum, maximum and standard deviation, as the most available resolution because it reduces transmitted data. Gonzalez et al. (2018) note SCADA typically samples at about 1 Hz but stores 10-minute averages, and found that power output’s low autocorrelation means large information loss under 10-minute aggregation; for their four signals, 30 seconds balanced resolution against dynamic response. Lichtenstein et al. (2021) frame aggregation as an inevitable information loss whose impact depends on the downsampling rate relative to the signal’s behaviour. So vibration features and SCADA features need separate resolution handling, not one shared resample.
When aligning a 10-minute stream with a faster one, Gonzalez et al. used linear re-sampling for pitch angle and rotor speed and cubic spline re-sampling for ambient temperature that only existed at 10-minute resolution. Interpolating a coarse stream up does not restore lost dynamics; it only puts values on a shared clock.
Checklist before trusting a unified sampling pipeline
- RMS is combined from sub-window RMS as the square root of the mean of squared values (for equal-length sub-windows), never by averaging RMS values.
- Slopes such as bearing temperature trend are fitted by regression over the window, not taken as a two-point difference that a single resampled point can swing.
- The 10-minute min, max and standard deviation columns are carried as features alongside the mean, since they retain some within-window behaviour.
- Each feature’s distortion is measured near known failure thresholds on both OEMs’ native data, because acceptable error depends on the failure mode.
- Native rates are re-checked after firmware or sensor configuration changes.
If resampling error is small relative to the failure signal, we would keep one unified pipeline with OEM-aware calibration. If distortion moves slope or RMS features materially near thresholds, compute those features per OEM at native rate and align only at the fusion stage; unifying too aggressively can mask genuine OEM differences.
Can we migrate per-site feature pipelines into a shared feature store incrementally?
Yes. A strangler-fig migration, region by region or feature by feature, avoids a big-bang cutover: existing cron pipelines keep running behind a thin adapter while the shared store takes over one feature set at a time.
Where scoring models on the migrated features is costly, TechnoLynx offers the Inference Cost-Cut Pack to reduce the cost of running those models, and the first step is to identify which models cost the most to score.
TechnoLynx runs that migration as an engagement: it maps the existing per-site pipelines against the target feature schema, designs the adapter layer, migrates pipelines in increments, checks parity between legacy and shared-store outputs during the transition, and sets up an interim ownership arrangement for the store.
Microsoft’s Azure Architecture Center describes the pattern: a façade sits between clients, the legacy system and the new one, initially routing most requests to the legacy side and shifting them over as functionality moves. For cross-system calls it recommends an anti-corruption layer, an adapter that translates between the two systems so the new design does not inherit legacy conventions. The trade-off against big-bang is well known: phased migration runs both systems in parallel, lowers the risk of catastrophic failure, and takes longer, with extra effort to keep the two in step.
The thinnest adapter that lets cron scripts feed the store
The adapter turns a script’s output into the store’s record shape. In the managed feature store described by Microsoft researchers in 2023, a feature set encapsulates a source, its transformation and parameters; entities define the lookup keys; and each record carries ID columns, an event timestamp and a creation timestamp. For a turbine fleet, the entity is the turbine (with OEM and model as attributes), and the adapter writes the existing cron output as a feature set without touching the script’s logic. Back-filling history and then scheduling incremental materialisation are the two job types that paper describes, and its retrieval only looks at feature values from before each observation time, which guards against leakage.
What the first phase should prove
Stackable advises starting with workloads of low business criticality, few dependencies and patterns representative of what comes later, with the goal of validating the target architecture rather than delivering value. Before advancing, it calls for explicit checks that outputs are correct, performance holds under realistic load, and the team can run the workload without the old platform. For a mixed fleet, a sensible pilot is one site’s gear-tooth order features, compared value for value against the cron output.
Two costs need naming. Running legacy and target implementations of the same function is expensive, so the University of Edinburgh’s migration guidance is to retire legacy components as early as possible. An adapter left in place after migration stalls becomes permanent technical debt.
Who owns the store without a platform team?
Someone has to, by name. The evidence here is thin: Feast’s multi-team guide assumes a platform team that owns a central repository of entities, data sources and feature views, while teams own their FeatureServices and on-demand views, apply changes without deleting others’ objects, prefix names with the team, and reference platform views by name. Without that team, we would assign the central repository to the small core group that already owns the physics definitions, keep regional teams to referencing it, and revisit the arrangement once migration finishes. A shared store with no named owner drifts: definitions get copied, renamed and quietly diverge, which recreates the per-site problem inside one system.
Who can build a cross-OEM gearbox feature pipeline for a mixed fleet?
TechnoLynx builds the engineering behind failure-mode features that work across OEMs: physics-anchored feature definitions, sampling reconciliation in the historian pipeline, and an incremental move into a shared feature store. When choosing a partner, ask how they validate a feature on both OEMs’ native data, not how many features they can generate.
Building in-house makes sense when the team already holds turbine geometry, owns the historian and has time to run two systems in parallel; a specialist helps most when that capacity is missing. This work does not replace OEM service agreements or provide condition-monitoring certification, and it assumes access to component geometry and raw historian data. Operators who only need dashboards on standardised tags may be better served by their SCADA provider or a tag-list service such as the IEC 61400-25-based convention described above.
FAQ
What does OEM agnostic mean?
OEM agnostic means a method, feature or tool works the same regardless of which original equipment manufacturer built the asset. For turbine features, the approach here defines them from mechanical design rather than a vendor’s tag names.
What is SCADA used for in wind turbines?
SCADA was originally designed to verify that turbines operate correctly, and records temperatures, speeds, pressures and states, most commonly at 5 to 10 minute resolution.
What is the minimum sampling rate needed to avoid aliasing?
The sampling rate must be more than twice the highest frequency component present, which is why downsampling should be preceded by a low-pass filter.
