4.1 System Design Overview

Author

Lancelot Blondeel

Designing a real-time fisheries monitoring system requires a clear definition of what is being monitored, how data is collected, and how it flows through the system to support decision-making. The following overview outlines the architecture from vessel to end-user, using the Belgian beam trawl fleet as the primary reference.

The Fishing Unit: Core of Monitoring

At the heart of monitoring lies the fishing unit—a discrete fishing activity, often called a tow, haul, or fishing event. For the Belgian beam trawl context, a fishing unit is defined as:

  • The period from gear deployment and active fishing,

  • Through retrieval, sorting, and weighing of catch,

  • Ending before the next deployment.

This definition provides clean segmentation of operations and enables high-resolution analysis of catch, effort, fuel consumption, and environmental factors.

Detecting a Fishing Event

Reliable identification of fishing units in real time depends on sensor fusion. In beam trawlers, three inputs are central:

  1. GPS data – to detect speed patterns and course changes.

  2. Towing force and rope length – to confirm gear deployment and active fishing.

  3. First weighing event – to verify that catch has been retrieved and processed.

Alternative or supplementary indicators may include drum sensors (net movement), or fuel consumption data, though these are more prone to noise. Together, these signals feed into algorithms that segment trips into meaningful fishing events.

System Architecture: From Vessel to Dashboard

The monitoring system can be understood as a layered data flow:

  1. Sensors on the vessel – GPS, towing force/rope length, weighing scales, fuel sensors.

  2. Onboard data hub – centralises sensor signals, applies preliminary logging and quality checks.

  3. Transmission layer – VSAT satellite or 4G connection, depending on range and availability.

  4. First server (distribution) – receives data from vessels, ensures reliable storage and routing.

  5. Second server (processing & algorithms) – runs tow detection algorithms, aggregates and analyses data.

  6. Visualisation – tailored dashboards for end-users, adapted to context (e.g. a large screen on the bridge for at-a-glance information, or mobile devices for onshore stakeholders).