Question 1

The framework requires the DP FMEA to undergo a systematic review "through the vessel's life cycle, and not restricted to the five-yearly review/refresh," with triggers including hardware/software modifications, changes in operating procedures or industrial mission, and "learnings from DP incidents (LFI)... that the Vessel Technical Operator has experienced or been made aware of." Why would an industry incident the vessel was never directly involved in still trigger a review of that vessel's own FMEA?

Accepted Answer

An FMEA's conclusions are based on the failure modes its authors considered at the time — if an industry incident reveals a failure mode or interaction nobody had previously considered, that gap potentially exists in every FMEA that did not specifically analyse it, regardless of which vessel the incident actually happened on, so a genuinely thorough VTO treats industry-wide learning as evidence its own analysis may need updating, not just a warning about someone else's ship This is the same logic as a near-miss investigation in any safety system — the value of an industry incident is in the failure mode or interaction it reveals, which is a piece of knowledge applicable wherever that same gap might exist, not a fact confined to the specific vessel where it happened. A VTO that only reviews its own FMEA after its own incidents is learning the hard way what industry-wide LFI review is designed to teach in advance.

Question 2

OCIMF's DP FMEA Assurance Framework states it was developed because, despite extensive existing guidance, "a significant number of FMEAs lack comprehensive analysis," and that adherence to its prescribed format "will be confirmed by OVID inspectors as part of the DP FMEA assurance processes commissioned by OCIMF members." What does this tell a DP crew member about what an OVID inspection is actually checking when it comes to the FMEA?

Accepted Answer

The OVID inspector is not just confirming a class-approved FMEA document exists onboard, but assessing whether that document meets a specific quality and completeness standard (clear identification of common points, fail-safe conclusions, compensating provisions) — a vessel can hold a class-stamped FMEA and still fail this assurance check if the document itself is not comprehensive This is the critical, easily-missed point: OCIMF built this framework specifically because class approval alone was not catching FMEA quality gaps — the 2004 UK HSE/DNV review found weaknesses including non-thorough class review and late submission. An OVID inspection using this framework is checking the substance of the document, not just its existence or its class stamp.

Question 3

The framework defines a "common point" as an element that "interfaces with or influences redundant groups and... can defeat the redundancy concept," and states common points "cannot be eliminated completely in a redundant DP system" — closed bus ties, cross-connected control power supplies, and some hybrid power designs are cited as examples. Why does the framework treat common points as something to be managed rather than something a well-designed DP system simply avoids entirely?

Accepted Answer

Some common points exist because they are required to achieve specific legitimate design objectives (e.g. closed bus tie operation for certain power management benefits) — the framework's actual requirement is that any common point that does exist must be explicitly identified, its failure modes analysed, and its compensating provisions proven by testing, not that DP systems must have zero common points to be acceptable This is a precise, easily misunderstood point — the framework is not a zero-common-points standard, it is a "if a common point exists, prove you understand and have mitigated it" standard. A DPO or vetting-facing officer who assumes any common point automatically means a failed system, or conversely assumes common points are harmless because they sometimes serve a legitimate purpose, has both gotten the principle wrong in different directions.