Question 1

The event was managed without any actual loss of position or contact, purely through the DPO's cross-technology verification habit catching the false GNSS readings before they were trusted. Viewed through a Safety-II lens, what is the most valuable lesson to capture from this event?

Accepted Answer

The specific anticipatory habit that worked — routinely cross-checking GNSS against a different-technology reference rather than relying on GNSS-to-GNSS agreement — should be explicitly recognised, reinforced in training, and not simply filed away because "nothing went wrong" This is the practical Safety-II payoff: the DPO's specific habit — verifying across technology types, not just within the GNSS family — is exactly the kind of resilient practice that should be deliberately studied and spread, precisely because it is what prevented this from becoming a real incident.

Question 2

A DP2 vessel is holding position. Both DGNSS units (normally independent) suddenly show an identical, sudden position jump of 40 metres in the same direction at the same instant, while the Fanbeam shows no corresponding change. What should the DPO immediately suspect?

Accepted Answer

A GNSS-wide problem affecting both satellite receivers simultaneously (interference, spoofing, or a satellite constellation issue) rather than two independent sensor faults — the fact that both units moved identically and together is the key clue, since genuinely independent reference systems failing identically at the same instant is far less likely than a shared external cause The signature here is diagnostic: independent systems agreeing with each other but disagreeing with a genuinely different technology (Fanbeam) is a classic common-cause signature pointing at the GNSS signal environment itself, not the receivers. This is exactly the pattern seen in real GNSS jamming and spoofing incidents.

Question 3

The DPO checks the Fanbeam reading against the suspect DGNSS units and confirms the vessel has not actually moved 40 metres — the Fanbeam position is consistent with the pre-event position. What should the DPO do immediately?

Accepted Answer

Manually exclude both DGNSS units from the DP position solution immediately, relying on the Fanbeam (and any other unaffected reference) — do not wait for the DP system's automatic voting to resolve this, since two affected units may outvote the one correct reference if left to automatic logic This is precisely why blind trust in majority voting is dangerous during a common-cause GNSS event: two affected systems can outnumber the one unaffected system, and naive voting logic would pick the wrong answer. The DPO's own judgement, informed by cross-checking technology types, must override simple vote-counting here.