This article covers:
- How do we Calculate production-based availability (PBA)
- Defining the Root Causes
- Logic on how the Shoreline defines PBA
How do we calculate production-based availability (PBA)
Production-based availability is a measure of how much of the potential production is actually produced. Defined here:
PBA [%] = Actual production [MWh] / Potential production [MWh]
These terms explained
- Potential production is the amount of energy an asset can produce if it was always operational (never fails or shuts down). Found by calculating energy production using the power curve of the asset and the wind speed at hub height.
- Actual production is the amount of energy an asset produces when operational. Found by calculating energy production using the power curve of the asset and the wind speed at hub height.
- Lost production is the energy not produced when an asset is non-operational but would be produced if it was operational. Calculated as the difference between potential production and lost production.
PS! If failures and scheduled maintenance occur in periods of low wind speeds the PBA loss is minimised because the lost production in low wind periods is less.
An example for one asset during one month:- Lost production: 85 MWh
- Actual production: 4,165 MWh
This gives a PBA of:
Possible production = 4,165 MWh + 85 MWh = 4,250 MWh
PBA = 4,165 MWh / 4,250 MWh = 0.98 = 98%Two reports are available which can be found in the output dashboards and be downloaded:
Defining the Root Causes
There are four types of root causes in Shoresim:
- Weather – not scheduled because of bad weather
- Response – not scheduled because of something other than weather
- Work – the time where work is actually done on assets
- Towing – the time the asset is being towed (only for floating assets)
Root causes are split into general categories. The root cause types are measured for each category.
Categories are:
- Major – the task is a Component Replacement Task
- Special condition – response time is recorded as lead time
- Floating – the task is a Component Towing Task
- Minor – the task is a Repair task (regular task, but not Scheduled Maintenance)
- Scheduled Service Work – the task is a Scheduled Maintenance
- Special condition – only the root cause type Work is recorded
The root causes and the sub-root causes:
- Scheduled service WTG
- Minor Work WTG
- Minor Weather Delay
- Minor Response
- Minor Response Time - Waiting to be scheduled
- Minor Response Time -No available vessel
- Minor Response time -No available drop-off and pick-up combination
- Minor Response time No available personnel
- Major WTG
- Major weather Delay
- Major Lead time
- Major Lead time -Waiting to be Scheduled for HLV
- Major Lead time No available HLV
- Major Lead time Other
- Floating work WTG
- Floating towing time
- Floating weather delay
- Floating response time
All root causes also exist with an "external" prefix, to show when the downtime is caused by a substation influencing the turbines
Logic on how the Shoreline defines PBA
When running an O&M simulation the turbines stop and start again multiple times. This is when a critical failure happens and when work is started on non-critical and scheduled work orders. Each time a turbine is not running we register downtime and production loss for the wind farm as well as the root cause for the production loss.
When a turbine is not running there are two steps to figuring out the root cause:
Which work order is the cause of the downtime?
Most times when there is downtime on a turbine it is because of a single failure happening or work currently ongoing on a single work order. However, there are some scenarios where there can be multiple work orders influencing the turbine. For example when two teams working on the same turbine at the same time, a critical failure is ongoing while scheduled work is also being carried out on the turbine. Other situations such as a substation being down will influence all turbines in the same wind farm, and here the individual turbine can also have its own failure at the same time.
When this happens, we use the following set of rules to determine which of the work orders is the dominating one:
- The highest impact on power production
- The turbine itself before any substation impacts
- Work orders with work currently ongoing on the turbine
- Critical work orders before non-critical work orders
- The downtime period that started first
For a downtime period, this process will also split it up into multiple smaller downtime periods, if there is different work order being the dominating one at different times.
Why are we not working on that work order?
When we know which work order is causing the downtime, we need to find the root cause. The first one to be pulled out always works – this also includes the towing times for towing work orders.
For the downtimes that are not working, we will find the reason for why no work is currently being carried out. The following list is the order in which different causes are checked:
1. There are no personnel available from their calendar availability
2. There are no vessels available from their calendar availability
3. There are no personnel available from their work shift availability
4. There are no vessels available from their work shift availability
5. First scheduling: From the work order is created (or when the lead time on the work order is over) until we first try to schedule it.
6. Lead time: From work, the order is created until we first try to schedule it - or we complete it in case it's a remote reset
7. All vessels that can do the work order are doing the lead time
8. One of the used vessels is in route to the work order.
9. The weather does not comply with the restrictions on the work order
10. All vessels that can do the work order have bad weather
11. One vessel that can do the work order is doing the lead time
12. One vessel that can do the work order has bad weather
At some point in the future, it will be possible for the users to define this prioritisation themselves.
If a time period is not covered by any of the above reasons it will hit the root cause of “no drop-off and pickup combination”
For longer downtime periods where the root cause would change over time, it is split into smaller downtime periods each with its own root causes. As illustrated below.
Mark a template as default to load it automatically while creating a new article.