Question 1

The OCIMF DP FMEA Assurance Framework defines a "proving trial" as "a series of tests carried out on DP to prove the conclusions of the DP System FMEA," and states a comprehensive FMEA and proving trials programme together should achieve objectives including developing the DP annual trials programme and "effective decision support tools, such as Activity-Specific Operating Guidelines (ASOG)." Why does a paper FMEA analysis alone, without a corresponding proving trials programme, fail to satisfy the assurance objective?

Accepted Answer

An FMEA is a theoretical analysis of how the system should behave under various failure scenarios — proving trials are the practical test of whether the real, installed system actually behaves the way the analysis predicted, and a real system can diverge from its own design analysis due to installation errors, software configuration, or unforeseen interactions that only physical testing under controlled conditions can reveal This is the core reason FMEA and proving trials are described as the "twin foundations" of DP assurance — an analysis on paper, however well-reasoned, is a prediction about system behaviour, not a confirmation of it. Proving trials close the gap between "this is how the system should behave according to our analysis" and "this is how the system actually behaves when tested," which is exactly the gap where installation/configuration errors hide.

Question 2

OVID's structure separates the OVPQ (Offshore Vessel Particulars Questionnaire — permanent/semi-permanent vessel features: dimensions, tonnage, crane capabilities, certification) from the OVIQ (the actual inspection questionnaire, completed by the inspector). Why does OVID require the vessel operator to maintain the OVPQ as a separate, standing document rather than having the inspector record all of this information fresh at every inspection?

Accepted Answer

Particulars like dimensions, tonnage, and crane capacity do not change between inspections, so having the operator maintain this as a standing record (which the inspector can verify rather than re-derive from scratch) lets the inspection itself focus its limited time on what actually needs fresh, on-the-spot assessment — current condition, crew competency, operational practice — rather than re-collecting static facts every visit This is a sensible division of labour between a standing-facts document (OVPQ, maintained by the operator) and a point-in-time assessment document (OVIQ, completed by the inspector) — it lets a time-limited inspection focus on what genuinely needs fresh verification rather than re-establishing facts that do not change visit to visit.

Question 3

OVID inspection reports respond to each question with "Yes," "No," "Not Seen," or "Not Applicable" — with "Not Seen" and "Not Applicable" both requiring a stated reason, distinct from a straightforward "No." Why does the OVID reporting structure treat "I could not verify this" as a category requiring its own justification, rather than simply defaulting an unverifiable item to "No"?

Accepted Answer

"No" represents a confirmed negative finding (the item was checked and found deficient), while "Not Seen" represents an inability to verify (e.g. access was restricted, or the relevant operation was not occurring during the inspection window) — collapsing these into one category would make every inspection report ambiguous about whether something was actually wrong or simply not observed, and the required reason for "Not Seen" forces the inspector to document why verification was not possible rather than silently treating absence of evidence as evidence of failure This distinction protects the integrity of the inspection record — a vessel should not be penalised with a confirmed negative finding for an item the inspector genuinely could not observe, but the inspection also should not let unverifiable items disappear silently. Requiring a documented reason for "Not Seen" achieves both: it avoids unfair negative findings while still surfacing exactly which items the report could not actually confirm.