11.3 Consequence Analysis

Online residual safety — what consequence analysis is

Consequence analysis (also called online consequence analysis, DP consequence analysis, or residual-capability monitoring, depending on vendor language) is a live software function on Class 2 and Class 3 DP systems. Continuously, or on a short cycle, it asks:

Given present environmental forces, thruster status, power status, and configuration, if the worst-case failure happened now, could the remaining thrusters and power still hold position and heading within acceptable limits?

If the answer becomes no (or margin becomes too small per system settings), the system alarms / warns the operator. The point is not academic curiosity. It is an early operational trigger: change something before the failure, or stop the critical activity so that a design failure does not become a loss-of-position incident.

[!TIP] Think of consequence analysis as a permanent “what if WCF hits this minute?” check, using today’s real plant and weather — not last month’s office plot.

Why Class 2/3 systems include it

Class 2/3 vessels are allowed to work in conditions where intact plant holds easily, but residual plant after WCF might not. Humans are bad at continuously re-computing residual force versus wind, current, thruster enables, and power limits. Consequence analysis automates that residual check so degraded weather, a deselected thruster, or a power limitation cannot silently leave the vessel one failure away from drift-off during critical work.

Distinct from offline capability plots

Candidates mix these up constantly. Keep them separate:

Capability plots remain essential for voyage and task planning. Consequence analysis remains essential for real-time residual assurance. A green consequence-analysis status does not rewrite a bad plan against the plots; a perfect plot set does not replace watching the live residual alarm during the job.

What the function typically considers

Exact algorithms are vendor-specific, but exam-level inputs include:

1. Which thrusters are available now (enabled, ready, not faulted, deployed).
2. Which thrusters would remain after WCF (residual set from configuration/FMEA model).
3. Power available to residual thrusters (bus state, generators, limits).
4. Present environmental demand (wind, current estimate, wave-related forces as modelled).
5. Heading and position control demand (present setpoints and force needs).
6. Sometimes load/bias and forbidden-zone constraints that reduce effective residual force.

If the WCF model in software no longer matches the real vessel (outdated after modification), consequence analysis can give false comfort or false alarms. That is another reason FMEA and trials currency matter to operators.

What the operator does on a consequence-analysis warning

A warning means: if the design failure occurs in present conditions, residual capability is insufficient (or marginal). Typical responses — chosen per company procedure, ASOG, and the task — include:

Exam framing: the system warns; the operator decides and acts. Consequence analysis does not by itself recover divers or open the bus-tie.

Link to ASOG red/amber status

Activity Specific Operating Guidelines (ASOG) (and related WSOG/SOM tables) translate plant and environmental status into green / amber / red (or equivalent) operating guidance. Consequence-analysis unhealthy status is a classic driver toward amber or red:

A consequence-analysis alarm saying residual hold after WCF would fail is effectively telling you that single-failure tolerance for this weather and config is no longer true. For diving or close-proximity construction, that is not a “note in the log and continue” event. ASOG should already define whether that condition is amber (time-limited improvement allowed) or red (immediate terminate).

Related chapters cover ASOG/CAM/TAM in depth; here the exam link is simple: consequence analysis is a live residual red-flag input to ASOG decisions.

Limitations and healthy scepticism

Consequence analysis is powerful but not omniscient:

• It depends on correct thruster and power status — a thruster showing available but mechanically useless can fool the model.
• Environmental estimates can lag or err (wind sensor issues, current estimate drift).
• Software WCF definition must match actual residual design.
• It does not replace PRS quality, drive-off monitoring, or human detection of model-measurement mismatch.
• Vendor implementations differ in conservatism and alarm hysteresis.

[!IMPORTANT] Holding position with intact plant while consequence analysis is in alarm means you are gambling that WCF will not occur. For Class 2/3 critical work, that gamble is exactly what the function exists to stop.

Worked operational scenario

A DP crane vessel holds 15 m off a platform in rising beam wind. Intact thrusters hold a small footprint. Offline post-WCF plots for the planned heading were acceptable at the 06:00 briefing. By afternoon, one retractable thruster that forms part of the residual set is deselected for a fault, and wind has increased. Online consequence analysis goes into warning: after WCF (loss of the other section), remaining thrusters cannot hold. The DPO treats this as ASOG amber trending red, stops the next critical lift, enables a repaired thruster after test, adjusts heading toward residual-optimal, and only resumes when consequence analysis is healthy and ASOG returns to green. The vessel never lost position — the system prevented a future loss after the design failure.

Exam traps for consequence analysis

Bottom line: consequence analysis is the Class 2/3 online function that continuously tests whether residual plant after WCF can still hold in present conditions; it is not an offline plot; its alarms drive heading, configuration, load, and ASOG amber/red decisions so critical work does not continue one design failure away from loss of position.