Wind Turbine SCADA and O&M Records for AI

What a usable wind SCADA and O&M package contains

A usable package has four linked tables: 10-minute SCADA, status and alarm events, work orders, and an asset register, all keyed to the same turbine and timestamp convention. Researchers report that most models are built on 10-minute means, and that the confidentiality of operator data is a main brake on progress [1][2]. That is the gap a licensed fleet extract fills.

• 10-minute SCADA. Per turbine and interval: wind speed and direction, nacelle position, active and reactive power, rotor and generator speed, blade pitch, ambient and nacelle temperature, and gearbox oil, gearbox bearing, main bearing, generator winding and converter temperatures. Ask for min, max and standard deviation channels, not only means; a standard deviation spike often leads a mean shift.
• Status and alarm logs. Event-level records with OEM status code, description, start and end time, and category (fault, warning, manual stop, grid, environmental). These carry the operating state that 10-minute averages smear.
• O&M work orders. Work order ID, turbine, open and close time, component, symptom text, action text, parts consumed and serial numbers. Pairing these with SCADA is what most public data lacks.
• Asset register. Turbine model, rated power, commissioning date, gearbox and generator make, and component swap history.

The IEC 61400-25 series [7] addresses communications for monitoring and control of wind power plants, including standard information models. In practice, many fleets still export OEM-specific tag names, so budget for a tag-mapping table rather than assuming 61400-25 naming in the delivered files. For general sensor licensing terms, see sensor and IoT data; this page covers what is specific to wind and solar fleets.

Why public wind turbine failure datasets fall short

Public wind datasets are good for prototyping but too small or too narrow for a production failure model. The Dundalk V52 set, for example, is 10-minute SCADA from a single turbine over 2006 to 2020 [4]. Other open releases, including multi-farm anomaly benchmarks, typically cover a few to a few dozen turbines, and the reviews note that most operator SCADA stays confidential [1][2].

Open sets also show the traps buyers inherit. Releases from operating farms are usually anonymized, which limits weather joins, and published files can be re-versioned when timestamp or label errors surface, so record the version you train on. And because faults are rare, the normal-to-abnormal imbalance degrades fault detection, a point the 2023 review makes directly [1].

What a fleet extract adds: more turbines of the same model (so gearbox or main-bearing failures repeat), multiple years per turbine (so seasonal baselines exist), and work orders that turn anomalies into named failure modes.

How to build failure labels from work orders

Failure labels come from component replacements and corrective work orders, not from alarms alone. Alarms fire on transient conditions and resets; a gearbox replacement with a part number is ground truth. Build labels in this order:

1. Anchor events. Major component exchanges (gearbox, generator, main bearing, blade, converter), identified by part number or serial swap in the work order.
2. Onset window. Define a pre-failure horizon (for example 30 to 90 days) as positive, and exclude a buffer before it so ambiguous degradation does not pollute the negatives.
3. Exclusions. Remove or flag intervals with curtailment, grid-operator setpoints, icing, scheduled maintenance, and manual stops. These look like underperformance but are not faults.
4. Negatives. Use turbines of the same model and season with no corrective work in a wider window.

The table below is a starting point for agreeing label semantics with a supplier before extraction.

Illustrative example: invented to show structure; it does not describe an available dataset.

Teams that model alarm streams across other industries face the same reset and chattering problems; see PLC, SCADA and DCS alarm and event logs.

Data quality checks before you accept a SCADA extract

Pre-processing decides whether a SCADA extract is trainable: outlier handling, gap interpolation and filtering are central steps in the literature [3]. Run these checks on a sample before agreeing scope:

• Timestamp convention. Interval start or end label, time zone, daylight-saving handling, and duplicate rows from date conversion, which can survive even into published data.
• Coverage. Percent of expected 10-minute rows per turbine-month; long gaps around failures are common because the turbine was down or the logger was replaced.
• Channel stability. Sensor swaps and controller firmware changes shift temperature offsets; ask for a change log.
• Power-curve sanity. Plot power against wind speed per turbine; derated or curtailed points should match status codes.
• Work order linkage. Share of corrective work orders that resolve to a turbine ID and a timestamp within the SCADA span.

Request delivery as columnar files, such as Parquet partitioned by turbine and month, which keeps typed timestamps and compresses wide temperature channels well [6].

Rights, OEM agreements and site sensitivity

Rights to wind data depend on who controls the SCADA system, not only who owns the turbine. Under full-service or long-term service agreements, the OEM may operate the SCADA platform and the contract may restrict how the owner uses or shares the data; check that agreement in the rights review rather than assuming the asset owner can license everything. Work order narratives written by technicians raise separate questions, covered in employee-authored records in training data.

Ask the supplier for a chain of documents: asset ownership, service agreement data clauses, and any third-party platform terms. Our guide to chain of title for AI training data lists what that file should contain.

Turbine IDs combined with coordinates or hub-height weather reveal the site and owner. Pseudonymize turbine and farm IDs unless you need weather or reanalysis joins; if you do, ask for coarsened location or pre-joined weather features. NIST cautions that traditional de-identification has inherent limits, so treat pseudonymized site data as re-identifiable and govern it accordingly [5]. Technician names and phone numbers in work orders need removal like any other personal detail.

Solar inverter fault data and other renewable assets

Solar fleets follow the same pattern: inverter status and fault codes play the role of turbine alarms, string or combiner current and voltage play the role of SCADA channels, and O&M tickets supply the labels. The differences are scale (thousands of strings per plant), irradiance and soiling as confounders instead of icing, and inverter vendor code tables that differ by model and firmware. Apply the same label discipline: anchor on replaced inverters or IGBT modules, and exclude clipping and grid curtailment. For maintenance record structures shared across asset types, see maintenance work order datasets and licensed maintenance logs.

Request template for wind SCADA and O&M data

A good request describes the data and labels you need, not the companies you think hold it. Buyers can adapt this template and send it through the SourceX buyer page.

Illustrative example: invented to show structure; it does not describe an available dataset.

request: wind turbine SCADA + O&M for component failure prediction
assets:
  technology: onshore wind, 2-5 MW class, single OEM platform preferred
  turbines: same model across farms; multiple years per turbine
scada:
  interval: 10-minute
  statistics: [mean, min, max, std]
  channels: [wind_speed, active_power, pitch_angle, rotor_speed,
             gearbox_bearing_temp, main_bearing_temp, generator_winding_temp]
events:
  status_alarm_log: OEM code, description, category, start_ts, end_ts
  curtailment_flags: grid setpoint, noise, wildlife, icing
labels:
  source: corrective work orders + component replacements with serials
  components: [gearbox, generator, main_bearing]
privacy:
  turbine_ids: pseudonymized; coarse region only
  personal_details: technician names and contacts removed
delivery:
  format: Parquet, partitioned by turbine and month
  docs: tag dictionary, timestamp convention, sensor change log
intended_use: train and evaluate failure and power-curve models

How SourceX sources wind and solar operating records

SourceX sources operational datasets from US companies on request, including engineering records; nothing is held in stock and a request does not guarantee a match. We look for US businesses that hold the data you describe, assess the data and licensing permissions, and agree pricing and allowed uses in a license; nothing is contracted until the supplying company agrees and approves the release. Every dataset is rights-reviewed for ownership and consents, personal details such as names, emails and phone numbers are removed or replaced before delivery with the method recorded and a sample checked, and delivery runs through private, access-controlled workflows only after an executed agreement. SourceX does not train models and does not publish prices. See the wider industry-specific operational data guide for related categories, and compare with utility outage tickets and restoration logs.

Request wind SCADA and O&M records

SourceX sources operational records from US companies on request and manages the licensing process, with every dataset rights-reviewed and released only with the supplying company's approval. Describe the turbines, channels, labels and uses you need on the SourceX buyer page.