Software that assumes the link will drop

A survey vessel generates more data in a day than its satellite link can carry in a week. That single ratio decides most of the architecture, and it is the one most easily missed by a team that has only ever deployed into a data centre.

The instinct on shore is to stream everything and process centrally. At sea that instinct produces a system which is either permanently behind or silently dropping the data nobody notices is missing.

Decide what has to travel

The useful question is which decision each byte is meant to support, and only then how to move it. A vehicle's position and health need to reach the operations centre within seconds. A full multibeam swath does not; it needs to arrive intact eventually, and be complete enough on the vessel for the crew to act on now.

Separating those two paths, a thin telemetry channel that is always current and a bulk channel that is eventually complete, is usually worth more than any compression scheme.

Capture must survive the gap

Capture on the vessel has to keep working with no uplink at all, for hours or days, and reconcile without human intervention when the link returns. That means durable local storage, resumable transfer with checkpointing and a reconciliation step that can prove what arrived rather than assume it.

The failure mode to design against is the partial reconnect rather than the outage: enough bandwidth to look healthy, too little to keep up, and a backlog growing that nobody sees until the campaign ends.

The operator is the constraint

Data that reaches shore and cannot be read in time has not arrived in any sense that matters. Real time 3D earns its place here. It is the difference between an operator seeing the seabed and an analyst reading a file next week.

The frame budget is a hard requirement and should be tested against real survey volumes early. A visualisation that is beautiful on sample data and unusable on a full dataset is still a prototype.