Alarm data as an asset

While the paper from Peak Wind and BCG focuses on the levers in offshore operations, the same applies to onshore, though with less gains as logistics is significantly simpler and more economical, and the assets in general have less capacity.

But how do you start? What data supports the important use cases? What is need-to-have and what is simply nice-to-have?
The purpose of this paper series is to give insights into how different data sources from a windfarm can support performance tracking and optimisation. The hope is that this can provide some support in making informed decisions about what datasets to prioritise accessing.

Data from a windfarm can come from many different types of sources. One of the most common ones is alarm data. Which is the event log from the individual assets on the windfarm (Wind Turbine Generator (WTG), Park Pilot or Substation) which captures all the stops, warnings and other events occurring on the asset.

For this article we will cover the general format and possible use cases for the event log from the WTGs so you can understand what this dataset can do for you.

• Stop alarms will stop the turbine from producing. These alarms will have a start time and an end time.
• Warnings will not stop the turbine from producing, but they might impact production on the WTG. Some warnings may curtail the WTG to produce less as to prevent damage to components, this could for instance be if some temperatures are running too high in the WTG.
  Warnings will have a start time and an end time.
• Informational events will not affect production on the WTG. They are singular events that have occurred on the asset. E.g., generator cut-in, remote log in or log out. These events might only have a start time, as they do not always have a duration.
  
  

For some OEMs the event type might not be available in the event log directly. Using the event identification, either numerical or description, will enable the event type to be mapped from technical documentation of the controller software.

Now we’ve covered how the alarm data looks. Let’s get into how you can use it.

If the full event log is available, you have all the notable events that have occurred according to the turbine controller. This is a valuable pool of information if you know how to use/exploit it, in this section we cover some cases where the event log is useful.

Root cause analysis

For unplanned stops on the WTG, the event log is the most likely place to find your root cause. Identifying the right stop alarm from the event log can help make sure you are bringing the right spare parts and troubleshooting guides, so you are more likely to get the turbine fixed on the first visit.
Important thing to keep in mind: the controller is biased. It observes the world from the perspective of the turbine. If an issue affecting the turbine is not stemming from the turbine itself, then the event log is not very reliable for root cause analysis. An example of such a scenario could be a grid connection failure which leaves the WTG without a power connection.

Condition monitoring and integrity management

Since the event log from the asset describes things that have already occurred, it might not be obvious that condition-based maintenance can be improved by utilising the event log. However, most OEMs are building more and more early warning events into the software of the controller – these enable you to make good decisions for maintaining your turbines before they have an unplanned stop.
An example of an early warning could be low grease level on a moving component. Having the warning tells you that within a short period of time you should visit the asset and refill the grease, so the integrity of the component is maintained.
You can use the event log to monitor if these warnings are reacted to within the recommended time.

Furthermore, the event log can tell you if stop alarms are being reacted to in the correct way. Some stop alarms can safely be remotely reset a few times, while others cannot. As an owner or operator this can inform you if the integrity of the turbines is properly considered by the control center monitoring the assets.

Visualisation from demo product made by Clover Energy using data from Kelmarsh and Penmanshiel

Outage tracking and classification

The event log can be used to identify periods where the turbine was stopped, and what event was the most likely cause of the stop. However, one should keep in mind that there can be multiple “stop alarms” active at the same time.

Understanding the individual alarms can help to place downtimes into IEC categories and to verify which downtimes were planned vs. unplanned, environmental vs. forced outages.

Operational Performance tracking

In the event log you can usually see when the turbine is visited. It will often be marked as local control/operations, which means that there are technicians working and they have taken control of the turbine. This is primarily a safety thing, as technicians working on the turbine need to know that the turbine cannot be remotely operated while they are doing maintenance or troubleshooting.
From a performance management standpoint the visit information is quite useful, as tracking these can give you a measure of how often the turbine is visited, and for how long. For offshore assets this information is particularly interesting, as the visits are significantly more expensive and difficult to do. Cost of logistics for offshore turbines and accessibility to the turbines, due to wind and waves, is a big consideration when doing operations.

Visualisation from demo product made by Clover Energy using data from Kelmarsh and Penmanshiel

The biggest limitation to the usage of the event log data is the quality of the dataset. In theory you should be able to detect all downtime accurately through the event log. However, the quality of the data is not always optimal. End times for events can be missing or be very delayed. In some cases, stop alarms might be completely missing from the event log.
Furthermore, if an issue is unrelated to the turbine itself there might be no entries at all. For example, a grid related issue sometimes leads to a scenario where the WTG does not log any events at all; as the WTGs do not have sufficient back-up power to correctly log the events.

To get the full value of the event log it is recommended to have a critical approach. For example, the use of a complimentary data source like the state signals from the turbines, could be useful for verification of the event log. The state signals can give a clearer picture of what state the turbine is running in, e.g., full, partial or no performance. This can be used to ignore unclosed stop alarms and still capture downtimes, which have no stop alarms logged at all.

As an OEM: the event log can help you evaluate if the controller is performing as intended. Does it raise events when it is supposed to, or do the parameters for the event need tweaking in the controller? Are the events registered as the right event types by the controller? Are there an unusual number of certain events which might indicate a flaw in the software?

As an owner: the event log is an excellent source of information to verify how the operation is going. You can track availability and the primary categories of downtime. You can challenge the strategy of the remote resets, the number of visits in a year and so on.

A supplementary data set could be the turbine state signals to improve the quality of the event log. For lost production estimates you could add some key sensor signals to your data portfolio, such as wind speed and active power from the turbines. The Lost Production calculation would enable you to put revenue numbers into your performance tracking, which makes it easier to define business cases of improvement initiatives.

Overall, the event log is a good and reliable base dataset, if the biases are remembered and considered when utilising the data for decision-making.