Wind Turbine SCADA Data For Early Fault Detection

Table of Contents

Data Description

Notes

Known Data Issues

Version Changes

Description

This dataset is published together with the paper "CARE to Compare: A real-world dataset for anomaly detection in wind turbine data" which explains the dataset in detail and defines the CARE score that can be used to evaluate anomaly detection algorithms on this dataset. When referring to this dataset, please cite the paper mentioned in the related work section. 

The data consists of 95 datasets, containing 89 years of SCADA time series distributed across 36 different wind turbinesfrom the three wind farms A, B and C. The number of features depends on the wind farm; Wind farm A has 86 features, wind farm B has 257 features and wind farm C has 957 features. 

The overall dataset is balanced, as 45 out the 95 datasets contain a labeled anomaly event that leads up to a turbine fault and the other 50 datasets represent normal behavior. Additionally, the quality of training data is ensured by turbine-status-based labels for each data point and further information about some of the given turbine faults are included.

The data for Wind farm A is based on data from the EDP open data platform (https://www.edp.com/en/innovation/open-data/data), and consists of 5 wind turbines of an onshore wind farm in Portugal. It contains SCADA data and information derived by a given fault logbook which defines start timestamps for specified faults. From this data 22 datasets were selected to be included in this data collection. The other two wind farms are offshore wind farms located in Germany. All three datasets were anonymized due to confidentiality reasons for the wind farms B and C.Each dataset is provided in form of a csv-file with columns defining the features and rows representing the data points of the time series. Files

More detailed information can be found in the included README-file.

Notes

In wind farm A status_type_id labels can be ignored while evaluating prediction time frames of error events with metrics like the CARE-score since the status_type_id is of wind farm A is based on the EDP failure logbook and it is intended to be used for filtering of the training data.

Known Data Issues

This dataset contains per‑timestamp summary statistics (Min, Max, Avg, Std) for multiple sensors and wind farms.The following issues are known and should be taken into account when using the data.

1. General Remarks and Recommendations

Implausible values in Min, Max and Std are present across all wind farms, with varying severity by feature and site.

Values were provided as-is by the operator. The only modifications are:

Anonymization-related scaling of power-related data.

Renaming of features.

As a consequence, all Min, Max and Std values should be used with caution and may not be physically meaningful.

Per-timestamp Avg (average) sensor measurements are generally plausible across all datasets and can be used for meaningful analysis.

2. Types of Issues

The following types of implausibilities occur in the Min/Max/Std statistics:

Issue

Description

1

Std per timestamp is higher than the maximum possible standard deviation given the corresponding Min, Max and Avg.

2

Min values are higher than the corresponding Avg values.

3

Max values are lower than the corresponding Avg values.

4

Min, Max and Std are equal to 0 for all datapoints of a feature.

3. Wind-Farm-Specific Issues

3.1 Wind Farm A

Grid Reactive Power

Min, Max and Std are affected by Issue 1 and Issue 3.

Pitch Angle

Contains implausible values likely caused by angle wrapping (e.g. 0° equivalent to 360°), leading to ambiguities.

All other sensors

Have fewer than 5% implausible values in Min/Max/Std.

These features can generally be cleaned and used after appropriate quality filtering.

3.2 Wind Farm B

Features with constant zero statistics (Issue 4) For the following sensors, Min, Max and Std are equal to 0 for all datapoints:

sensor_0, sensor_1, sensor_2, sensor_3, sensor_5, sensor_9

Features with localized inconsistencies (Issues 1, 2, 3) The following sensors show Issues 1, 2 and 3 for about 5% of datapoints on average across all events:

sensor_6, sensor_54, sensor_55, sensor_56, wind_speed_60

All other features with Min/Max/Std in Wind Farm B

A large proportion (typically >50%) of datapoints per feature is affected by Issue 1.

For many signals, the share of datapoints with implausible Min/Max/Std values is close to 100%.

Recommendation for Wind Farm B:Use Avg signals only for most analyses. Treat all Min, Max and Std statistics as unreliable unless you perform additional, feature-specific validation.

3.3 Wind Farm C

In Wind Farm C, Min/Max/Std statistics exhibit varying levels of contamination by Issues 1, 2 and 3. The percentages refer to the average fraction of affected datapoints across all events of Wind Farm C.

3.3.1 High Contamination (≈20–30% of datapoints affected)

The following 17 sensors have a high proportion (20–30%) of datapoints affected by Issues 1, 2 and 3:

sensor_11, sensor_15, sensor_40, sensor_61, sensor_62, sensor_63, sensor_64, sensor_74, sensor_194, sensor_195, sensor_197, sensor_198, sensor_205, sensor_206, sensor_207,sensor_217, sensor_218

These features should be treated with particular caution when using Min/Max/Std.

3.3.2 Medium to High Contamination (≈10–15% of datapoints affected)

The following 90 sensors show a medium to high proportion (mostly 10–15%) of datapoints affected by Issues 1, 2 and 3:

power_5, power_6, sensor_7, sensor_9, sensor_10, sensor_12, sensor_13, sensor_14, sensor_18, sensor_19, sensor_20, sensor_21, sensor_23, sensor_24, sensor_26, sensor_39,sensor_41, sensor_44, sensor_45, sensor_65, sensor_71, sensor_72, sensor_73, sensor_77,sensor_78, sensor_79, sensor_80, sensor_87, sensor_88, sensor_89, sensor_95, sensor_96,sensor_104, sensor_105, sensor_106, sensor_149, sensor_150, sensor_151, sensor_152,sensor_153, sensor_154, sensor_155, sensor_156, sensor_157, sensor_158, sensor_159,sensor_160, sensor_161, sensor_162, sensor_163, sensor_164, sensor_165, sensor_166,sensor_167, sensor_168, sensor_169, sensor_170, sensor_171, sensor_176, sensor_178,sensor_179, sensor_180, sensor_181, sensor_182, sensor_183, sensor_184, sensor_185,sensor_186, sensor_187, sensor_188, sensor_189, sensor_190, sensor_191, sensor_192,sensor_193, sensor_196, sensor_199, sensor_200, sensor_201, sensor_202, sensor_203,sensor_204, sensor_210, sensor_212, sensor_213, sensor_225, sensor_231, sensor_232,sensor_233, sensor_234

3.3.3 Low Contamination (<5% of datapoints affected)

The following 131 sensors show a low contamination level (below 5% of datapoints affected by Issues 1, 2 and 3):

sensor_0, sensor_1, power_2, sensor_3, sensor_4, sensor_8, sensor_16, power_17, sensor_22, sensor_25, sensor_27, sensor_28, sensor_29, sensor_30, sensor_31, sensor_32,sensor_33, sensor_34, sensor_35, sensor_36, sensor_37, sensor_38, sensor_42, sensor_43,sensor_46, sensor_47, sensor_48, sensor_49, sensor_50, sensor_51, sensor_52, sensor_53,sensor_54, sensor_55, sensor_56, sensor_57, sensor_58, sensor_59, sensor_60, sensor_66,sensor_67, sensor_68, sensor_69, sensor_70, sensor_75, sensor_76, sensor_81, sensor_82,sensor_83, sensor_84, sensor_85, sensor_86, sensor_90, sensor_91, sensor_92, sensor_93,sensor_94, sensor_97, sensor_98, sensor_99, sensor_100, sensor_101, sensor_102, sensor_103,sensor_108, sensor_107, sensor_109, sensor_110, sensor_111, sensor_112, sensor_113, sensor_114,sensor_115, sensor_116, sensor_117, sensor_118, reactive_power_119, reactive_power_120,reactive_power_121, reactive_power_122, sensor_123, sensor_124, sensor_125, sensor_126,sensor_127, sensor_128, sensor_129, sensor_130, sensor_131, sensor_132, sensor_133,sensor_134, sensor_135, sensor_136, sensor_137, sensor_138, sensor_139, sensor_140,sensor_141, sensor_142, sensor_143, sensor_144, sensor_145, sensor_146, sensor_147,sensor_148, sensor_172, sensor_173, sensor_174, sensor_175, sensor_177, sensor_208,sensor_209, sensor_211, sensor_214, sensor_215, sensor_216, sensor_219, sensor_220,sensor_221, sensor_222, sensor_223, sensor_224, sensor_226, sensor_227, sensor_228,sensor_229, sensor_230, wind_speed_236, wind_speed_235, wind_speed_237

Version Changes:

Version 5 -> 6:

Changed unit of sensor_40 and sensor_61 for wind farm C to hPa instead of bar. This unit error became obvious when looking at the data and comparing it to the standard air pressure.

Edited event_description of events 34, 7 and 19 to high temperature in transformer cell.

Changed date in event description of event 44 since it was not affected by the change in the date anonymization procedure from version 2.

Changed date in event description of event 47 since it was not affected by the change in the date anonymization procedure from version 2 and edited the description text

 Changed date format in event_info files to match the date format in the dataset files.

Fixed typo in Readme

Re-added Readme files

Version 4->5:

Corrections to labels were made:

Previously missing status_type_id 4 labels were added to datasets in Wind Farm A. 

Event 51 from Wind Farm A was wrongly labeled as a normal event. With the newly added status_type_id 4 occurences, it is to be considered an anomaly event due to a gearbox bearing damage within the prediction data.

Wind Farm A no longer contains status_type_id 5. All occurences of status_type_id 5 have been changed to 0 and are considered normal time stamps. This change is done, because status_type_id 5 was set as a result of a wind speed and power analysis, flagging potential anomalous data. This is not based on a fixed ground truth, so status_type_id 5 was removed. For Wind Farms B and C status_type_id 5 is still valid since it is based on real SCADA-status codes.

The event_info.csv files now contain an additional column 'asset_id'.

Version 3->4:

The change of the timestamp anonymization lead to duplicate timestamps when transitioning from a leap year to 2022. This is now fixed in Version 4.

Version 2->3:

In version 2 timestamp changes were not consistent with the timestamps in the event-info-files. Version 3 fixes this.

Version 1->2:

Version 2 contains one deviation from version 1 regarding the anonymization procedure. Instead of shifting the timestamps of each sub-dataset by a random number of years, the size of the time shift is now determined to be the number of years so that each sub-dataset starts in 2022. This change is made to make the timestamp anonymization more consistent and to avoid future timestamps being present within the data.