dynamic-positioning

How it is built

Architecture overview

A dynamic positioning (DP) system holds a ship or a floating rig at a point and a heading, with no anchors, by driving its own propellers and thrusters. A computer reads the position from several independent reference systems (satellite, acoustic, laser and others), the heading from gyrocompasses, and the wind and ship motion from sensors, then commands thrust in surge, sway and yaw so that the vessel stays on station against wind, waves and current (see the overview in Wikipedia). Drill ships, diving and cable ships and crane vessels rely on it, and a loss of position can injure people, so redundancy is part of the design.

Four ideas hold it together. First, estimate before control: the raw position jitters with waves and sensor noise, so an observer combines a ship model with all the reference sensors, separates the slow drift (which thrust must fight) from the wave-frequency motion (which thrust must not chase), and also infers the unmeasured force called "current". Second, control asks for forces, allocation chooses thrusters: the controller outputs a desired force and moment, and a separate step distributes it over many thrusters under limits on power, angle and thruster-to-thruster interaction. Third, redundancy by independent copies and voting: three of each critical sensor and often three computers, so a disagreeing unit can be found and outvoted. Fourth, the failure case is the design case: the equipment class (1, 2 or 3) is defined by what single failure the system must survive, and the worst-case failure analysis decides the architecture.

Parts:

• Sensors and reference systems — position, heading, motion, wind, and their quality checks — Rigid-body transforms, Quaternion rotations, transform-tree (no page yet), pseudorange-least-squares-positioning (no page yet), Robust statistics, Newton root finding
• State estimator — observer with model, sensor weighting and wave filter — sensor-fusion (no page yet), Kalman filter, Extended Kalman filter, complementary-filter (no page yet), IIR and FIR filters, biquad-filters (no page yet), Fast Fourier transform, system-identification (no page yet), levenberg-marquardt (no page yet)
• Controller — position and heading control with wind feed-forward — PID controller, Model predictive control, gain-scheduled-control-laws (no page yet), Runge-Kutta 4, Explicit Euler, Fixed-rate control loop
• Thrust allocation — turn a force demand into thruster commands under constraints — control-allocation-mixing (no page yet), quadratic-programming (no page yet), Interior-point method, Sparse direct solver, Fill-reducing ordering, Sparse matrices (CSR), Graph partitioning, L-BFGS, d-ary heap
• Thruster and I/O layer — set-points to drives, feedback from drives — real-time-fieldbus (no page yet), time-triggered-scheduling (no page yet), modbus-protocol (no page yet), dma-transfers (no page yet), PWM generation, SPSC ring buffer, Memory ordering, False sharing, CPU caches and memory hierarchy, SIMD programming
• Redundancy and fault handling — voting, takeover, fault detection and safe states — redundancy-voting (no page yet), fault-detection-isolation-recovery (no page yet), Hot-standby redundancy, Primary-backup replication, Leases, Fencing tokens, Health checking, Watchdog timer, Hierarchical state machine, safety-monitor-architecture (no page yet), Memory protection unit, end-to-end-protection-e2e (no page yet)
• Safety analysis — worst-case failure and common-cause analysis — Fault tree analysis, Binary decision diagrams, BFS and DFS
• Operator interface and logging — alarms, mode changes, event records — Alarm management, debouncing-throttling (no page yet), Write-ahead log, CRC32C checksums, fsync, O_DSYNC and O_DIRECT

 position references (DGPS, acoustic, laser, taut wire) ─┐
 gyrocompasses (heading) ────────────────────────────────┤  plausibility checks, voting
 motion units (roll, pitch, heave), wind sensors ────────┘            │
                                                                      ▼
                          observer: ship model + weighted references + wave filter
                       (position, heading, velocity, unmeasured "current" force)
                                                                      │ estimate
 operator setpoint ──► controller (feedback + wind feed-forward) ──► force & moment demand
                                                                      ▼
                  thrust allocation (QP: limits, power, forbidden sectors, minimal energy)
                                                                      │ rpm / pitch / azimuth
                                   thruster drives ◄──── fieldbus ◄───┘
                     thruster feedback ──► observer (actual thrust)     DP console: alarms, modes

How the parts fit together

Sensors and reference systems

The system never relies on one position source. Typical references are differential GNSS, hydroacoustic systems with transponders on the seabed, laser-based range and bearing to a nearby target, and a light taut wire to a clump weight on the seabed; heading comes from gyrocompasses, roll, pitch and heave from motion reference units, and wind from anemometers (the Wikipedia overview lists these). Each source reports in its own frame at its own time, so all measurements are brought to the vessel's control point by a time-indexed tree of frames (transform-tree, no page yet) using Rigid-body transforms: an antenna offset from the control point, plus roll and pitch, shifts the reported position, and a pose is rotated with quaternions to avoid singularities. A satellite fix is itself an iterative least-squares solution (pseudorange-least-squares-positioning, no page yet; Newton root finding). Before a measurement reaches the observer it passes quality checks (jump, frozen-signal and noise tests) that use Robust statistics, so a single outlier does not break the check.

State estimator

The observer is the centre of the system. It runs a low-frequency model of the vessel in surge, sway and yaw (mass, damping, thruster forces, wind force) and corrects it with the reference measurements, weighting each by its expected noise, so a precise satellite fix counts more than a coarse acoustic one. Wikipedia's description is the same: the difference between the measured and the predicted position updates the model by Kalman filtering, and that makes it possible to ride through a short loss of all references. The building blocks are the Kalman filter for a linear model and the Extended Kalman filter for a nonlinear one (heading enters through rotation). A well-known alternative with a stability proof is the passive nonlinear observer (Fossen and Strand 1999, tested on a supply vessel, see Sources).

Two separations make the estimate useful:

• Wave filtering. Waves move the ship at wave frequencies, which are much faster than the vessel's slow drift. If the controller reacted to that motion, thrusters would constantly work against the waves, wasting energy and wearing the drives. The observer therefore treats the wave-frequency part as a separate state or filters it out with notch or band-stop filters (IIR and FIR filters, biquad sections: biquad-filters, no page yet). The dominant wave frequency can be estimated from the measured motion with a Fast Fourier transform.
• Unmeasured forces. Current, second-order wave drift and model errors are lumped into a slowly varying force bias that the observer estimates; Wikipedia notes the same, that forces not attributable to direct measurement are labelled "current". The controller uses the bias as feed-forward.

Model parameters come from design data and sea trials, refined by system-identification (no page yet) and nonlinear fitting (levenberg-marquardt, no page yet).

Controller

The controller turns the position and heading error and the estimated velocity into a force and moment demand. Simple systems use a PID controller per axis (still in use, per the same overview); modern systems use model-based control with feed-forward from the wind sensors, which "anticipates gusts before the ship is blown off position". Model predictive control is the option when constraints matter: limited thrust, a heading limit, or a planned move to a new position. Gain scheduling (gain-scheduled-control-laws, no page yet) changes the gains with sea state and mode (station keeping, low-speed tracking, joystick). Model prediction uses Runge-Kutta 4 or, in a cheap loop, Explicit Euler. The loop runs at a fixed period (Fixed-rate control loop), because time-step jitter corrupts the velocity estimate. The contract with the allocator is three numbers per cycle: surge force, sway force and yaw moment.

Thrust allocation

A vessel has more thrusters than degrees of freedom (azimuth thrusters, tunnel thrusters, main propellers, rudders), so there are many ways to produce the demanded force. The allocator picks the one that satisfies the demand while minimising energy, keeping within limits: maximum thrust per unit, rate limits on pitch and azimuth angle, forbidden sectors where one thruster's wash hits another, and the power that the generators can supply. Written out, this is a constrained quadratic program (quadratic-programming, no page yet; the mixing matrices of control-allocation-mixing, no page yet): minimise a weighted sum of thrust squares and slack on the demand, subject to linear bounds. The method is surveyed in Johansen and Fossen's control allocation survey. Solvers are an Interior-point method or an active-set method; the linear systems inside use a Sparse direct solver after a Fill-reducing ordering on Sparse matrices (CSR); L-BFGS fits box-constrained variants. Warm starting from the last cycle's solution is the central trick, since consecutive demands are close. If the demand exceeds the available thrust, the allocator scales it by a defined priority, usually heading before position, so the vessel does not spin while chasing position.

Thruster and I/O layer

Set-points go to the thruster drives (rpm, pitch, azimuth angle) and feedback returns the actual thrust state, which the observer needs for its model. The links are deterministic fieldbuses (real-time-fieldbus, no page yet) or Modbus (modbus-protocol, no page yet) for slower devices, with time-triggered scheduling of tasks and messages (time-triggered-scheduling, no page yet), so a late frame is a detected fault. Inside the controller, the I/O and control tasks exchange data through a lock-free SPSC ring buffer, whose correctness depends on Memory ordering; False sharing and CPU caches and memory hierarchy explain why a naively shared struct causes jitter; DMA (dma-transfers, no page yet) moves sensor frames without CPU work, and PWM generation drives small actuators. Filters and matrix products use SIMD programming.

Redundancy and fault handling

IMO guidance, as summarised by Wikipedia, defines three equipment classes. Class 1 has no redundancy (a single fault can lose position). Class 2 must not lose position from a single fault of an active component (generators, thrusters, switchboards, valves) but may after failure of a static one (cables, pipes). Class 3 must also survive fire or flood in one compartment. The text goes on to say that at least three position reference systems should be used so voting logic can find the failing one, and that Class 3 ships have three DP control computers, three gyrocompasses, three motion units and three wind sensors. A single fault that damages redundancy and cannot be fixed at once means the operation should be abandoned.

Mechanisms behind this:

• Voting. With three sources, a faulty one is the outlier (redundancy-voting, no page yet; 2-out-of-3). The observer weights references by variance, and a reference far from the others is rejected and flagged.
• Computer redundancy. Several independent controllers run in parallel with an online and standby role. A standby copy shadows the primary's state and takes over when the primary goes silent (Hot-standby redundancy, Primary-backup replication). Only one may command the thrusters at a time, which is a lease problem (Leases): the primary's authority expires unless renewed, and a stale primary's output is refused by the I/O layer by epoch number (Fencing tokens). Failure detection uses heartbeats (Health checking) and each unit has a Watchdog timer.
• Modes. The system's states (off, standby, manual, auto position, auto track, degraded) form a Hierarchical state machine; a fault moves it down to a defined degraded state, not to an undefined one.
• Independent monitor. A separate checker (safety-monitor-architecture, no page yet) verifies the commands against limits and forces a safe state; a Memory protection unit separates safety-critical tasks from the rest, and a counter plus CRC on every message over a shared network detects loss or repetition (end-to-end-protection-e2e, no page yet). Faults are classified and acted on by fault-detection-isolation-recovery (no page yet).

Safety analysis

The class is proved, not claimed. A failure mode and effects analysis (FMEA) traces each component's failure to its effect on the vessel's ability to keep position, and a worst-case failure design intent defines the single largest loss the rest must survive (for example the loss of a whole thruster room). The logical side is a Fault tree analysis: the top event "loss of position" is expressed as AND/OR over component failures, with common-cause failures (one power bus, one network, one software bug in all computers) as shared leaves. Binary decision diagrams evaluate such trees exactly even when components appear in many branches, and graph traversal (BFS and DFS) finds the sets of components that fail together. The consequence for software: identical software on three computers is a common-cause risk, so independent monitors and whole-vessel simulation testing are needed.

Operator interface and logging

The operator sees a console with alarms, modes and a position plot. Without discipline, a single fault floods the screen: Alarm management groups causes, adds delay and deadband, and keeps a few actionable alarms; debouncing-throttling (no page yet) stops chatter from a noisy sensor. Event and sensor logs are written with a Write-ahead log and checksums (CRC32C checksums), and flushed with the guarantees described in fsync, O_DSYNC and O_DIRECT, because the log is the evidence after an incident. The marine contractors' association IMCA runs a free DP incident database.

Data and control flow

One control cycle

1. Sensors deliver measurements with time stamps: references, heading, motion, wind, thruster feedback.
2. Each is checked for plausibility, converted to the vessel's control point, and compared with the other sources by the voting logic.
3. The observer predicts the state from its model and last thrust, then corrects it with the accepted measurements, weighted by their noise; the wave component is removed from the low-frequency estimate and the force bias is updated.
4. The controller computes the force and moment demand from the error, the velocity and the wind feed-forward.
5. The allocator solves the constrained problem (warm-started), applies power limits, and produces rpm, pitch and angle set-points.
6. The set-points are sent over the fieldbus; the monitor checks them against limits; drive feedback comes back for the next cycle.
7. The cycle result is shown to the operator and logged.

A position reference fails

1. The jump or noise test or the voter marks one source as suspect; the observer lowers its weight to zero.
2. If enough references remain, control continues with an alarm; the operator is informed which reference was lost.
3. If too few remain, the observer rides on its model for a limited time while the system warns; the operation stops if no reference returns.
4. The reference is readmitted only after it passes the checks for a defined time.

Scaling

1. Thrust allocation is the heaviest numeric step per cycle. Levers: warm starts, exploiting the sparse structure, a smaller problem (fewer constraints), a fixed iteration cap with a fall-back to the last feasible solution.
2. Sensor and thruster count grows estimator and allocator. Levers: fixed-size matrices, SIMD, no allocation in the loop.
3. Timing is the real limit: a missed deadline is a fault. Levers: fixed-period scheduling, lock-free hand-off between tasks, pinning the control task to a core, a hardware watchdog.
4. Redundancy cost grows with class. Lever: choose the class by the risk of the operation, not by the ship.

Failure modes

Real implementations

DP systems from the vendors (for example Kongsberg, Wärtsilä, Marine Technologies, Navis Engineering) are proprietary and certified by classification societies. Open material covers modelling, estimation and allocation.

Sources

• T. I. Fossen and J. P. Strand, Passive nonlinear observer design for ships using Lyapunov methods: full-scale experiments with a supply vessel, Automatica, 1999. doi
• T. A. Johansen and T. I. Fossen, Control allocation: a survey, Automatica, 2013. doi
• Dynamic positioning (Wikipedia): reference systems, equipment classes, redundancy requirements and control overview, read for this page.
• IMCA: DP incident database (site listing only).
• Repositories in the table above (README and file list read for MSS; licences from the GitHub API).