Major Component Replacement – Complete Guide
Overview
A Major Component Replacement (MCR) is used to model the full lifecycle of replacing a large component on a wind turbine — such as a main bearing, gearbox, or generator. It is the most complex work order type in the simulation, involving multiple vessels, extended turbine downtime, and a carefully sequenced series of phases.
This article covers how an MCR works from the moment a failure is detected through to the turbine returning to operation, including how durations, lead times, and downtime are configured and calculated.
The Four Phases
An MCR is divided into four sequential phases, each requiring a different vessel and triggering its own scheduling cycle. The turbine remains unavailable throughout all four phases.
Phase 1 — Inspection
Vessel: Ghost CTV (a virtual support vessel representing subcontractor crew)
The inspection phase begins immediately when the failure is detected and the work order is created. A technical crew is dispatched to the turbine to assess the failure, confirm the scope of work, and document the condition of the component.
-
Duration is configured on the task definition (
inspectionDuration) and can vary year by year using a time series -
Crew size is configurable (
inspectionCrewSize) -
The turbine is already unavailable from the moment the failure occurs — the inspection phase is part of the overall lead time period, not additional downtime on top of it
-
The phase completes when the Ghost CTV crew has finished their assessment and returned to port
Once inspection is complete, the work order automatically moves to the preparation phase.
Phase 2 — Preparation
Vessel: Ghost CTV
The preparation phase dispatches a crew back to the turbine to carry out the physical groundwork needed before the HLV can begin its lift operation. This typically includes removing auxiliary components, staging the site, and making the turbine ready for the crane.
-
Duration is configured on the task definition (
preparationDuration) and supports time series -
Crew size is configurable (
preparationCrewSize) -
The time the crew spends actively working is classified as Major Work downtime
-
The phase completes when the Ghost CTV crew has finished preparation work and returned to port
Once preparation is complete, the work order enters the ReadyForReplacement state and waits for the HLV to be scheduled.
Phase 3 — Replacement
Vessel: Heavy Lift Vessel (HLV)
The replacement phase is the core of the MCR. The HLV performs the physical component exchange — crane lifts, component removal, and installation of the new part. This is typically the longest and most weather-sensitive phase.
-
Duration is determined by the HLV's crane operation process cycle (see the section on replacement duration below)
-
Crew size is configurable (
replacementCrewSize) -
When the HLV begins work, the turbine is registered as a blocking fixable on the infrastructure, preventing any other work orders from being scheduled on that turbine for the duration of the replacement
-
This blocking is removed as soon as the replacement is complete
Option: Allow scheduled work while waiting
If the allowScheduledWorkWhileWaiting flag is enabled on the task, the infrastructure blocking is deferred until the HLV actually starts working — rather than being applied when the work order first enters the ReadyForReplacement state. This means that if the HLV is chartered but not yet on site, other already-scheduled work on the turbine can still proceed.
The phase completes when the HLV finishes its crane operation. A REPLACEMENT_COMPLETED milestone is logged at this point.
Phase 4 — Finalization
Vessel: Ghost CTV
The finalization phase sends a crew back to the turbine to complete commissioning, close out the job, restore systems, and confirm the turbine is ready to return to operation.
-
Duration is configured on the task definition (
finalizationDuration) and supports time series -
Crew size is configurable (
finalizationCrewSize) -
For critical replacements, the turbine remains stopped throughout the entire finalization phase
-
For non-critical replacements, the turbine is allowed to restart between individual work sessions during finalization — so the turbine may show brief periods of availability while the crew is not actively on site
The phase completes when the Ghost CTV crew has finished their work and returned to port. A WORKORDER_COMPLETED milestone is logged and the work order is closed.
Phase Summary
| Phase | Vessel | Infrastructure blocked | Turbine unavailable | Output root cause |
|---|---|---|---|---|
| Inspection | Ghost CTV | No | Yes (from failure) | Major lead time |
| Preparation | Ghost CTV | No | Yes | Major work / weather delay |
| Replacement | HLV | Yes | Yes | Major work / weather delay / lead time |
| Finalization | Ghost CTV | No (blocking removed at start) | Yes (until complete) | Major work / weather delay |
Lead Times
There are two distinct types of lead time involved in an MCR. Both begin at the moment of failure — when the work order is created.
Task Lead Time
The task lead time (leadTime on the task definition) represents an administrative or procurement delay before the simulation's scheduler is even allowed to make its first scheduling attempt. It models the time between a failure being detected and the point at which operations teams can begin organising a response.
-
Configured in hours on the task definition
-
Begins at the moment the work order is created
-
Ends when the first scheduling attempt is made
-
Shown in the output as Major lead time downtime
Vessel Charter Lead Time
The vessel charter lead time (leadTime on the vessel configuration) represents the time it takes for the HLV to mobilise from its base and be ready for operation. This models the real-world reality that a spot-chartered vessel is not immediately available — it needs time to be prepared, positioned, and mobilised.
Critically, this lead time also starts at the moment of failure, not when the HLV is eventually selected by the scheduler. When a work order is created, the simulation immediately initiates spot-chartering for all vessels in the allowed vessel list. This places a mobilisation period on each vessel's timeline straight away, blocking them from being assigned to other work while they mobilise.
-
Configured in hours on the vessel definition
-
Begins at the moment the work order is created (vessel is immediately spot-chartered)
-
The
LEADTIMEtimeline node on the vessel's schedule represents this period -
Shown in the output as Major lead time – No available HLV while the vessel is mobilising
How the Two Lead Times Relate
Both lead times run concurrently from the moment of failure. They represent different kinds of waiting:
| Lead time type | What it represents | Starts | Ends |
|---|---|---|---|
| Task lead time | Administrative/procurement delay before scheduling begins | Failure | First scheduling attempt |
| Vessel charter lead time | Vessel mobilisation time | Failure | Vessel arrives and is ready |
In practice, the vessel may be ready before the task lead time has elapsed, or vice versa — whichever takes longer determines when the HLV can actually begin its journey to the turbine.
Replacement Duration Configuration
The duration of the HLV's physical work on the turbine (Phase 3) is configured differently from the other three phases. Rather than being set directly on the task, it is determined by the HLV's crane operation process cycle.
What Is a Process Cycle?
Every vessel has one or more process cycles that define the sequence of activities it follows when executing a job. For an HLV performing a component replacement, the crane operation process cycle defines the steps the vessel carries out once it is jacked up and in position — for example, rigging, lifting, installation, and de-rigging. The total duration of all these steps is the replacement working time.
Two Ways to Set the Duration
Option 1 — Fixed Step Duration
A specific number of hours is entered directly on the crane operation step. This duration applies to every replacement job the vessel performs, regardless of which component is being replaced.
Use this when the crane operation time does not vary significantly between component types, or when the vessel's own working procedures are the primary driver of how long the job takes.
Option 2 — Inherit Task Duration
The "Inherit task duration" option on the process step causes the step's duration to be automatically drawn from the replacement duration defined on each individual task, rather than from the step itself.
This allows different component types to drive different HLV working times using the same vessel and the same process cycle. For example, a main bearing replacement and a generator replacement can have different crane operation times without needing separate vessel configurations.
How it works behind the scenes:
When a simulation is submitted, the platform prepares the full input package for the engine. During this preparation, it checks whether any crane operation steps have "Inherit task duration" enabled. If they do, the platform automatically creates a separate version of the process cycle for each component type the vessel is configured to work on, substituting the replacement duration from each task's definition into the inheriting step. By the time the simulation engine receives the configuration, it only sees fixed durations — the inherit logic is fully resolved at export time.
For HLVs and site cranes, the inherited duration comes specifically from the replacement work duration field on the task definition. This is a dedicated field separate from the general repair time used for other vessel types.
Use "Inherit task duration" when:
-
Different component types have meaningfully different HLV working times
-
You want the task definition to be the single source of truth for replacement duration
-
You are using time series on the task and want the HLV working time to change year by year
Downtime Root Cause Classification
All time the turbine spends unavailable during an MCR is categorised into one of the following root causes in the simulation output:
| Output label | What it represents |
|---|---|
| Major work | Time a vessel (Ghost CTV or HLV) spends actively performing physical work on site |
| Major weather delay | Work stopped or postponed because weather restrictions are not met |
| Major lead time – Waiting to be scheduled for HLV | HLV not yet chartered; work order is pending in the scheduler queue |
| Major lead time – No available HLV | HLV is chartered but still in its mobilisation period (charter lead time active) |
| Major lead time – Waiting to be scheduled for support vessel | Ghost CTV not yet dispatched for inspection, preparation, or finalization |
| Major lead time – No available support vessel | Ghost CTV is assigned but not yet on site |
| Major lead time – Other | Other scheduling delays, such as no valid weather window being found within the scheduling horizon |
These root causes are surfaced in the P–TBA and P–BA outputs and in the per-turbine downtime breakdowns.
Configuration Parameters
All phase durations and crew sizes are defined on the task definition and can be varied year by year using time series. The HLV replacement duration can additionally be configured via the vessel's process cycle.
| Parameter | Applies to | Description |
|---|---|---|
inspectionDuration |
Task | Duration of the inspection phase in hours. Supports time series. |
inspectionCrewSize |
Task | Number of technicians required during inspection. |
preparationDuration |
Task | Duration of the preparation phase in hours. Supports time series. |
preparationCrewSize |
Task | Number of technicians required during preparation. |
replacementCrewSize |
Task | Number of personnel required on the HLV during replacement. |
finalizationDuration |
Task | Duration of the finalization phase in hours. Supports time series. |
finalizationCrewSize |
Task | Number of technicians required during finalization. |
leadTime |
Task | Administrative delay in hours before the first scheduling attempt. |
allowScheduledWorkWhileWaiting |
Task | If enabled, infrastructure blocking is deferred until the HLV actually starts work rather than when the work order becomes ready for replacement. |
leadTime |
Vessel | Mobilisation time in hours from when the vessel is chartered to when it is ready to depart. Begins at the moment of failure. |
| Step duration / Inherit task duration | HLV process cycle | Determines HLV working time — either a fixed number of hours on the step, or inherited from the task's replacement duration field. |
Notes for Interpreting Results
Why does the turbine sometimes show brief availability windows during finalization?
This is expected behaviour for non-critical replacements. Between finalization work sessions — for example, if the crew finishes a shift and the Ghost CTV returns to port before coming back — the turbine is allowed to restart temporarily. If you see this and it is unexpected, check whether the task is configured as critical or non-critical.
Why does the "No available HLV" period start at the same time as the failure?
The vessel charter lead time begins immediately when the work order is created. This is intentional — in reality, the process of mobilising a spot-chartered HLV begins as soon as the decision is made to proceed with a replacement, which happens at the point of failure detection. The lead time on the vessel configuration represents the full mobilisation window from that point.
What happens if the task lead time is shorter than the vessel charter lead time?
The scheduler can begin looking for suitable scheduling windows as soon as the task lead time has elapsed, but the HLV will not be available to dispatch until its mobilisation period is also complete. Both conditions must be satisfied before active planning can proceed.
What if the inherited replacement duration is zero?
If "Inherit task duration" is enabled on an HLV step but the replacement duration on the task is not configured (or is set to zero), the step will use a duration of zero. This will result in the replacement phase completing instantly. Always ensure the replacement duration is set on every task that an HLV with inherited duration is configured to work on.