Fisheries VMS Domain · Lesson 4 of ∞ · ← Lesson 3
Monitoring, the hardware end
Before a position ever reaches e-Boat's map, a physical unit on a boat has to decide when to send it. That decision has real trade-offs, and it's the one piece of the ToR the codebase deliberately leaves unimplemented.
A VMS unit is purpose-built shipboard equipment: GNSS receiver, a satellite or cellular uplink, and firmware that decides when to transmit a position report. Two design choices dominate real-world deployments, and both are worth knowing before you read any ToR requirement about "tracker devices."
This is the polling interval, and it is a genuine engineering-vs-cost trade-off, not a solved problem. Research on real VMS datasets shows enormous variation in practice — roughly a mix of 20-minute, 1-hour and 2-hour intervals across different fleets historically — while current best-practice guidance pushes much tighter: small-scale/passive-gear fisheries should be polled at least every 30 seconds, large-scale active-gear fisheries every few minutes, and reconstructing an accurate vessel track generally needs 10 minutes or better. NOAA's own national VMS fleet — the largest in the world at over 4,000 vessels — delivers 24+ position reports per day (roughly hourly) at 100m accuracy.
The trade-off is blunt: tighter polling means better enforcement resolution (you can actually tell if a vessel dipped into a closed area for five minutes) but higher transmission cost, and in most regimes the fisher pays for their own VMS transmissions — so a regulator can't just mandate the tightest possible interval without a cost fight.
Sources: Frontiers — Methods to get more information from sparse VMS data, NOAA Fisheries — Vessel Monitoring System.
e-Boat's NFR target of ≤30s device-to-map latency is about pipeline speed after a report arrives — it says nothing about how often a given device reports in the first place. A vessel polling every 2 hours will still show a 2-hour-old position on the map 29 seconds after the report lands. Don't conflate "the system is fast" with "the picture is current" — they're two different numbers, and only one of them is e-Boat's to control.
A VMS unit can fail, be tampered with, or be switched off — and because carrying a working unit is a licence condition (Lesson 1), the device's own health is itself something a regulator has to monitor. This is tracker device management: registering a unit against a specific vessel and licence, tracking its lifecycle (active, faulty, deactivated, reassigned), and treating a suspicious gap in reporting as a signal worth investigating in its own right — not just missing data.
In the ToR, this is its own requirement group: C-077..C-087, distinct from the position-processing requirements in C-009..C-039. The distinction matters for the same reason event/violation did in Lesson 2 — "is this vessel where it shouldn't be" and "is this vessel's tracker itself working correctly" are different questions, checked by different logic, against different failure modes.
e-Boat's EBoat.Adapters project defines an ITrackerAdapter interface — the seam where a specific vendor's protocol would be translated into e-Boat's canonical position format. Per the project's own internal notes, the adapters are intentionally unimplemented: they return not_implemented, because the vendor list hasn't been received from the Customer yet. This is not a bug or an oversight — it's the honest state of a requirement that genuinely cannot be finished until an external fact (which hardware is actually in use) is known. Worth remembering next time the map shows no live vessels: the pipe exists, the format at the far end of the pipe doesn't yet.
Something unclear, or want to go deeper on any term here? Ask the agent that built this lesson — it's your teacher for this workspace, not just a lesson generator.