3.1 DP Controller & Mathematical Model

Why the Controller Matters on the DPO Exam

On an Induction or Simulator assessment, questions about the DP controller rarely ask for brand-specific menu clicks. They test whether you understand the control loop: what goes in, what is estimated, what is commanded, and what the thrusters actually do. If you can explain the path from position reference systems (PRS) and sensors → process station → force demand → thrust allocation → thrusters, you can answer most controller items without memorising product names.

The controller is the brain of the seven-component DP system. Power supplies energy, thrusters create force, references measure where you are, and environmental sensors describe disturbances — but the controller is what turns those streams into continuous station-keeping. When something goes wrong on a DP vessel, the DPO’s first mental model should be: Is the controller seeing good data, estimating state correctly, and allocating thrust safely?

Inputs to the Process Station

The process station (DP computer / control cabinet) continuously receives:

These inputs are not simply averaged and copied to thrusters. The controller estimates state (position, heading, velocities, and often residual current forces), compares that estimate to setpoints, and computes the force and moment needed in surge, sway, and yaw — the three degrees of freedom DP actively controls.

The Control Loop in Plain Language

1. Setpoints define where the vessel should be (position) and which way it should point (heading). In Auto DP these may be fixed; in follow-target or track modes they move over time.
2. Measured data arrive from PRS and sensors; they are noisy, delayed, and occasionally wrong.
3. The mathematical model predicts how the vessel should move given known thruster forces and estimated environmental forces.
4. An estimator (commonly a Kalman filter — covered in the next section) blends model prediction with measurements to produce a best state estimate.
5. The controller computes the error between estimate and setpoint, plus rates of change, and generates a force demand (Fx, Fy, Mz).
6. Thrust allocation logic (TAL) converts that demand into individual thruster commands.
7. Thrusters respond; the vessel moves; sensors update; the loop repeats at high frequency.

If any link breaks — bad reference, frozen gyro, thruster offline, model completely wrong for the loading condition — the loop still runs, but the vessel’s actual footprint may grow or the system may alarm and degrade.

Mathematical Model: What It Is (and Is Not)

The mathematical model is a real-time software representation of vessel hydrodynamics: mass and added mass, drag, thruster force-to-acceleration behaviour, and often wind coefficients and residual current effects. Vendors initialise it from shipyard data, sea trials, and model tests, then the online estimator adapts certain parameters (especially residual forces often labelled as current).

Model versus measured position is a classic operator and exam concept. Displays often show the model’s predicted position alongside the fused or individual PRS position. When they agree within normal residuals, confidence is high. When they diverge sharply, investigate:

• A single wild PRS dragging the estimate (voting should help)
• A thruster producing less (or more) force than commanded
• Sudden current or wake from another vessel
• Incorrect thruster enable status or forbidden-zone constraints starving allocation

Setpoints: Position and Heading

Position setpoint is the commanded worksite location (absolute coordinates or relative to a structure). Heading setpoint is the commanded yaw. Operators change setpoints deliberately (move vessel, weather-vane heading, approach track). Unintended setpoint changes — wrong joystick step size, accidental gain of position from a bad reference when selecting, or follow-target tracking the wrong target — are operational hazards, not merely HMI mistakes.

Practical setup concepts the exam expects you to recognise:

• Gains / controller settings affect how aggressively the system corrects errors; too high and thrusters oscillate, too low and the vessel lags weather.
• Present position / present heading selection freezes the current estimate as the new setpoint when entering Auto DP — do not do this while references are jumping.
• Thruster enable/disable and power available shrink the force the TAL can produce; capability after worst-case failure depends on remaining thrusters, not on the setpoint alone.
• Consequence analysis (later chapter) continuously checks whether, after a defined failure, remaining capability still holds position in the present weather — the controller and TAL still run, but the operational decision may be to stop work.

Thrust Allocation Logic (TAL)

Thrust allocation logic answers four practical questions for every control cycle:

1. How much thrust is required from the thruster set to meet Fx, Fy, Mz?
2. Which thrusters should contribute (enabled, not faulted, not in forbidden zones)?
3. What direction should azimuth thrusters point (and what pitch/RPM for tunnels)?
4. How is demand limited over time so rate limits, power limits, and interaction constraints are respected?

TAL is an optimisation under constraints. It may use thruster bias (opposing thrusters force against each other) to keep units responsive, respect forbidden zones where wash hits hull, risers, or ROVs, and reallocate instantly when a thruster drops offline. The controller does not permanently assign “bow thruster only does sway”; allocation is free to use any combination that best meets the demand vector within limits.

Exam Scenarios: Controller Thinking

Operator Responsibilities at the Controller Level

As DPO you do not rewrite the model equations, but you do:

• Confirm the correct control mode and setpoints before critical work
• Keep adequate independent PRS online so the estimator is not single-thread
• Watch residuals, thruster feedback, and alarms when weather or configuration changes
• Understand that disabling thrusters or accepting power limitations changes what TAL can achieve
• After any major change (mode, heading, thruster set, reference mix), allow the system a short settling period and verify the footprint before resuming critical operations

Master the loop — inputs, estimate, setpoint error, force demand, TAL — and the controller becomes a coherent system rather than a black box full of unexplained symbols.