All Technical Articles
ArchitectureLatency

The Data Pipeline From Deck Sensor to Bridge Console

By Engineering — Platform · February 22, 2026 · 7 min read

A walk-through of every hop the data takes — sensor cell, segment master, vessel server, bridge console — and the latency budget at each.

The bridge console must change state within seconds of the deck event, and the latency budget is fixed: from sensor measurement to red-state on the console, under 4 seconds with 99.9% confidence. Here is how we spend that.

Latency budget

8 ms
Sensor → segment master (EtherCAT poll cycle)
120 ms
Segment master → vessel server (anomaly evaluation)
350 ms
Vessel server → bridge console (websocket update)
~3 s
Confirmation window before red-state commit

Why the 3-second confirmation

A red state on the bridge has to be trustworthy. We trade 3 seconds of additional latency for cross-cell coherence — confirming the anomaly is local to one vehicle, not a sensor glitch and not an environmental spike.

What gets retained

Every sensor reading is retained at 1 Hz for the full voyage on the vessel server, and downsampled to 1 / minute on shore upload. Anomaly windows are retained at full resolution (10 Hz) for 90 days.