Question 1

The framework lists "common failings in FMEAs" including cases where "the system in which the common point occurred was part of the FMEA scope, but it was not identified," and separately, cases where "the common point was identified, but the range of failure modes considered was not adequate or comprehensive." Why does the framework distinguish between these two failure types rather than treating "FMEA missed something" as one category?

Accepted Answer

These represent genuinely different quality gaps requiring different fixes — one is a scope/thoroughness failure (the analysis did not look hard enough to find the common point at all), the other is an analytical depth failure (the common point was found, but the analysis of what could go wrong with it was shallow) — an assurance reviewer needs to distinguish these because "did the FMEA look in the right places" and "was the analysis once there deep enough" are different things to check This is a genuinely useful distinction for anyone reviewing or relying on an FMEA: a document that missed a common point entirely has a coverage gap, while one that found the common point but analysed its failure modes shallowly has a depth gap — both are real quality failures, but they point to different root causes and different fixes in how the analysis was conducted.

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.