The Master suspends the operation and contacts the DP system OEM's technical support. What information will the OEM need to diagnose the software fault effectively?

A. The OEM does not need any vessel-specific data since all software faults are identical across all installations

B. Only a verbal description of what the DPO saw on the console, since logs are not normally useful for this type of fault

C. The vessel's FMEA document alone is sufficient without any live diagnostic data

D. The system's event/alarm logs and software diagnostic records from the time of the fault — these typically capture far more detail about the internal fault condition than what the DPO observed on the console, and are the primary diagnostic tool for software-level faults

A. The vessel should immediately drop anchor regardless of changeover success

B. No automatic action occurs for a software fault; only hardware faults trigger changeover

C. The system should automatically switch over to DP Computer 2 (the standby/redundant controller) seamlessly, with thrusters continuing under DP2's control without interruption; the DPO must verify the changeover actually occurred cleanly, that DP2 has correct position and reference data, and that no thruster commands were lost or duplicated during the transition

D. Thrusters automatically default to maximum power output until manually reset

A. It must be a power generation fault since any thrust transient implies an electrical issue

B. It must be a sensor fault since thrust is downstream of position data

C. The category does not matter — all DP failures are addressed identically regardless of cause

D. This is a control-system/software failure category, distinct from power generation or sensor failures — correctly identifying the category matters because the troubleshooting, the people who need to be involved (DP system OEM/software support, not just the electrical engineer), and the appropriate caution around trusting the "recovered" system are all different from a power or sensor event