HD84 ROV Downtime Analysis | West of Shetland

HD84 Analysis

Password protected

ROV breakdown and equipment-failure review

A conservative minimum of 70:54:47 ROV-system downtime

Seventeen defensible root-cause incidents were identified across HD84 vehicle, launch/recovery, navigation and ROV-mounted survey or inspection systems.

West of Shetland28 Jun–5 Aug 2026All times UTC

Executive reading

What drove the result

01

Dominant class

Payload and survey systems account for 62.4%

CP, TSS, laser, camera and MBES interruptions totalled 44:14:28, substantially more than strict core vehicle or electrical downtime.

02

Largest campaign

24:14:33

CP communications, digitiser, MUX, Mini IPS and ground-fault troubleshooting across 30–31 July.

03

Recovery exposure

13 of 17

Incidents involved deck recovery, TMS return, recovery instruction or multiple recovery cycles.

04

Open at log end

MBES remained unresolved

Only three explicit stopped intervals on 5 August are counted. The reported total is therefore a minimum, not an upper bound.

System contribution

Where the 70:54:47 sits

Click a class to carry that filter into the timeline and incident ledger.

Downtime by primary class

Measured operational unavailability

Hours

Chronology

Failures clustered late in the campaign

The bars show elapsed incident windows across 12 July–5 August. Very short interruptions are widened for visibility.

Primary class
Visible incidents17
Visible downtime70:54:47

Showing the complete audited ledger.

Audited ledger

Seventeen grouped root-cause incidents

Select any incident for the full duration basis, recovery treatment, source rows and caveat.

Audit boundaries

What was deliberately kept outside the KPI

Exclusion prevents weather, planned activity, inspection IT and unconfirmed constraints being misrepresented as ROV breakdown.

Important: these records may still matter to campaign performance. They are separated because this KPI is specifically breakdown and equipment-failure downtime.

Methodology

Built for traceability, not false precision

The source is an online operational log, not a dedicated downtime register. Each interval therefore follows the chronology of explicit failures, stops, recoveries, troubleshooting, repairs, redeployments and resumptions.

Conservative minimum: the final MBES issue had no confirmed resolution by source row 1909. Unmeasured continuation is not added.

  1. 01

    Read the complete operational record

    All 1,906 rows in Survey-HD84 were assessed with supporting settings and connection sheets.

  2. 02

    Identify defensible markers

    Failure, stop, recovery, deck or TMS state, troubleshooting, repair and production-resumption wording was linked chronologically.

  3. 03

    Group repeated root causes

    Repeated entries from the same campaign were grouped into one incident to prevent double counting.

  4. 04

    Measure operational unavailability

    Intervals run from the first defensible stop to resolution, redeployment or production resumption.

  5. 05

    Separate non-breakdown causes

    Commissioning, inspection IT, survey software, weather, planned calibration and unconfirmed constraints remain outside the KPI.

  6. 06

    Expose uncertainty

    Mixed causation, corrected timestamps, approximate endpoints and open incidents are shown rather than silently normalised.

Incident detail

Failure and operational effect

Evidence and caveat