A computer-implemented method for electronic boat licence fishing vessel regulation

Abstract

This invention relates to the field of electronic vessel tag monitoring technology for fishing vessels, and discloses a computer implementation method and system for electronic vessel tag monitoring. The method includes: ensuring data collection continuity through token caching and automatic refresh; cleaning and uniformly transforming the original coordinates reported by the device to ensure consistent spatial references; generating signatures for the boundary coordinates of restricted areas and caching the corresponding polygon objects, reusing geometric objects to accelerate the determination of massive fences; determining the online timeliness of devices based on event time windows rather than instantaneous network status to reduce misjudgments; and performing work order-level deduplication and timeliness updates on triggered events to avoid alarm redundancy. This invention achieves end-to-end optimization from data collection, coordinate processing, efficient fence determination, stable status monitoring to closed-loop work order management, significantly improving the performance, accuracy, and reliability of the monitoring system.

Description

Technical Field

[0001] This invention relates to the field of electronic vessel tag fishing vessel supervision technology, and in particular to a computer implementation method that combines communication optimization, coordinate unification, accelerated fence determination, online timeliness determination and event closed-loop management. Background Technology

[0002] In recent years, with the expansion of fishing vessel operations and the increasing demands for marine supervision, electronic vessel tag-based fishing vessel monitoring systems have gradually become an effective means of fisheries management. Electronic vessel tag devices can report real-time information such as vessel location, battery level, and connection status. The monitoring platform analyzes this data to provide functions such as boundary crossing warnings, offline monitoring, and low battery alerts, thereby improving the safety and compliance of maritime operations.

[0003] However, in actual operation, the existing technology still has the following prominent problems: 1. Communication links rely on external platform access tokens and network quality: Most systems directly call third-party interfaces to obtain data, relying on the access tokens returned by these interfaces for authentication. Tokens have an expiration date and must be reapplied for after expiration, increasing the system burden due to frequent authentication requests. Simultaneously, network fluctuations can cause token acquisition failures or data transmission interruptions, thus affecting the continuity and real-time nature of data collection.

[0004] 2. Inconsistent coordinate sources introduce bias in boundary crossing judgment: Different devices or data sources may use different coordinate systems (such as WGS84, GCJ-02, etc.), and even within the same coordinate system, there may be coordinate representations with directional suffixes (such as "E", "N", etc.). If these coordinates are not cleaned and converted uniformly and directly used for geofencing judgment and map display, it will lead to location deviation, resulting in false alarms or missed alarms.

[0005] 3. Performance Bottleneck in Fence Determination: Determining the spatial relationship between a large number of fishing vessels and complex restricted areas (such as no-fishing zones, protected areas, and restricted zones) is a computationally intensive task. Existing methods typically dynamically construct polygonal geometric objects for each determination, which cannot be effectively reused, resulting in large response latency and low system throughput in high-concurrency scenarios.

[0006] 4. Online determination relies on real-time network status: Traditional methods usually determine whether a device is online or offline based on the real-time connection status reported by the device. This is easily affected by instantaneous network fluctuations and brief signal loss, resulting in frequent online / offline status reversals, increasing invalid alarms and processing burden.

[0007] 5. Loose management of alarm work orders, lacking a closed-loop handling mechanism: The same event may result in duplicate work orders being entered into the database due to repeated data reporting or multiple triggers within a short period, causing data redundancy and wasting processing resources. In addition, untimely updates to work order status and unclear completion procedures lead to high noise in regulatory data, making it difficult to form an effective regulatory closed loop.

[0008] Therefore, there is an urgent need for an electronic vessel tag-based fishing vessel supervision method that can still achieve high efficiency, accuracy, stability, and closed-loop operation even in scenarios with unstable communication, inconsistent coordinates, large number of fence determinations, and frequent network fluctuations. Summary of the Invention

[0009] This invention provides a computer implementation method for electronic vessel tagging and fishing vessel supervision, aiming to solve the above-mentioned technical problems and achieve full-process optimization from data acquisition, coordinate processing, fence determination, event generation to work order closure.

[0010] The core idea of ​​this invention is to: ensure communication stability through local token caching and automatic refresh mechanisms; unify spatial benchmarks through coordinate cleaning and bidirectional transformation; improve spatial judgment performance through fence signature caching and reuse; mitigate the impact of instantaneous network fluctuations through online judgment based on time windows; and construct a regulatory closed loop through event work order deduplication and timely updates. Ultimately, this forms an integrated end-to-end regulatory system encompassing "collection—processing—judgment—alarm—disposal—display."

[0011] Specifically, the method of the present invention includes the following steps: Step 1: Communication Token Management The input consists of the base address, username, and password; the output is the access token and its expiration date. The system first reads the token from its local cache. If the cache hits and the token is still valid, it is used directly. If the cache misses or the token has expired, the system automatically sends a token refresh request to the authentication service to obtain a new token and update the cache. Simultaneously, a cache lifespan consistent with the token's expiration date is set. This mechanism reduces frequent calls to the authentication interface and lowers the risk of data collection interruptions due to token expiration.

[0012] Step 2: Equipment Data Acquisition Using device type as the filtering criterion, a request is initiated to the data platform using a valid token to obtain the latest reported data from the specified electronic vessel tag device. Data items include event time, raw WGS84 latitude and longitude, battery percentage, and device connection status. Thanks to the token guarantee in step 1, this step maintains a high success rate and continuity in data collection even during network fluctuations.

[0013] Step 3: Coordinate Preprocessing and Unification The collected raw latitude and longitude coordinates are cleaned to remove any directional suffix characters (such as E, W, N, S, or their lowercase forms), resulting in pure numerical strings. Next, the cleaned WGS84 coordinates are converted according to the system's unified display coordinate system (usually GCJ-02). To ensure the accuracy of reverse lookup and backtracking, this invention also provides an iterative inverse calculation method from GCJ-02 to WGS84. Through a finite number of iterations, the conversion error converges to an acceptable threshold, thereby ensuring consistency between spatial determination and map display.

[0014] Step 4: Construct the fence signature cache The system preloads the boundary coordinate sequences of all restricted areas (such as fishing ban zones and protected areas) from the database. A unique signature key (e.g., using a hash algorithm) is generated for each coordinate sequence. A polygon object is constructed based on the coordinate sequence using a geometry library (such as JTS), and this polygon object is cached in memory or a distributed cache using the signature key as an index. When determining if a point lies within a polygon, the cached polygon object is directly retrieved using the signature key, avoiding redundant construction and significantly improving throughput.

[0015] Step 5: Point Polygon Determination The input consists of the unified coordinate point processed in step 3 and the corresponding restricted area polygon object obtained in step 4. Using spatial relationship calculation functions from the geometry library, it determines whether the point is inside the polygon and outputs a Boolean value. This step is a preliminary spatial check to trigger an out-of-bounds event.

[0016] Step 6: Proceed to License Determination Based on spatial judgment, a strategy assessment is conducted by combining the type of prohibited area and the fishing vessel's own attributes. Prohibited area types may include fixed fishing ban areas, seasonal fishing ban areas, fishing vessel type restriction areas, dynamic protection areas, and quota restriction areas. Fishing vessel attributes include operation type, vessel tonnage, and main engine power. The system determines whether the fishing vessel is permitted to enter the area based on preset policy rules (e.g., fixed fishing ban areas prohibit entry under any circumstances; seasonal fishing ban areas prohibit entry of fishing vessels of the corresponding operation type during the closed season). This step combines spatial location with business rules, making the determination more consistent with actual regulatory policies.

[0017] Step 7: Online Timeliness Determination The event times reported by the devices are uniformly converted into ZonedDateTime objects with time zones. A fixed offline determination time window (e.g., 2 hours) is set. The system compares the current time with the latest event time of the device. If the time difference exceeds the threshold of the window, the device is determined to be offline; otherwise, it is considered online. This method is based on event time rather than instantaneous network status, effectively avoiding misjudgments caused by brief network fluctuations.

[0018] Step 8: Event Generation and Work Order Deduplication Based on the judgment results of steps 5, 6, and 7, events such as illegal boundary crossing, equipment offline, and low battery may occur. Before converting the event into a work order for persistence, the system performs a deduplication check: it queries whether there are any work orders related to the fishing vessel, of the same event type, and in an "unprocessed" or "processing" state. Specifically, for boundary crossing events, it also checks whether the prohibited areas are the same. If they exist, only the most recent trigger time of the work order is updated, and no new work order is created; if they do not exist, a new work order is created and an appropriate urgency level is set (e.g., high for boundary crossing, medium for offline, and normal for low battery). This mechanism avoids a flood of work orders for the same event within a short period, ensuring the simplicity and timeliness of work order data.

[0019] Step 9: Persistence and Display of Trajectory and Situation The location information of fishing vessels (including original coordinates and uniformly converted coordinates), event time, and event type are recorded in the trajectory log. Simultaneously, the status of fishing vessels (online / offline / alert) is updated to the database. Supervisory personnel can view the distribution of fishing vessels, work order lists, and statistical overviews in real time via a web dashboard or mobile application, and can filter and paginate the display by time, type, and keywords. Processing personnel can handle and complete work orders, completing the entire regulatory loop.

[0020] The present invention also provides a system for monitoring fishing vessels using electronic vessel tags, comprising: 1. Communication Client Module: Responsible for caching and refreshing tokens and fetching device data.

[0021] 2. Data Processing Module: Responsible for coordinate cleaning, coordinate system transformation, and event time parsing.

[0022] 3. No-entry zone geometry engine module: responsible for constructing, caching, and determining the position of points within the polygon in the no-entry zone.

[0023] 4. Strategy Assessment Module: Responsible for determining entry permits based on the type of restricted area and the attributes of fishing vessels.

[0024] 5. Event Ticket Module: Responsible for deduplication of events, updating timeliness, and generating and managing ticketing processes.

[0025] 6. Persistence module: Responsible for storing trajectory logs, work order data, and fishing vessel status.

[0026] The modules described above work together through predetermined data flows and calling relationships to jointly implement the method described in this invention.

[0027] The beneficial effects of this invention are: 1. Significantly improved communication stability: Through token caching and automatic refresh mechanisms, the dependence on external authentication services and the impact of network jitter are reduced, ensuring the continuity and success rate of data collection.

[0028] 2. Significantly improved fence detection performance and accuracy: The use of coordinate signature caching to reuse polygon objects avoids repetitive geometric calculations in massive detection scenarios, significantly improving system throughput; combined with unified coordinate cleaning and high-precision bidirectional conversion, it ensures consistency between spatial judgment and map display, reducing misjudgments.

[0029] 3. More stable and reliable online judgment: The judgment method based on the event time window eliminates the strong dependence on the instantaneous network state, effectively reducing the problem of frequent switching between online / offline states caused by network fluctuations.

[0030] 4. Tight and efficient regulatory closed loop: Through the work order deduplication and timeliness update mechanism, data redundancy and processing noise are effectively reduced, forming a complete closed loop from event discovery to work order completion, which improves regulatory efficiency and data quality.

[0031] 5. Enhanced system scalability and adaptability: Key parameters (such as offline time window and low power threshold) can be adjusted through configuration; restricted area types and permission rules can be flexibly expanded; coordinate transformation strategies can be adapted to the regulatory requirements of different regions, making the solution of this invention have good universality. Attached Figure Description

[0032] Figure 1 The overall system architecture principle block diagram provided for embodiments of the present invention.

[0033] Figure 2 The software processing core flowchart provided for embodiments of the present invention.

[0034] Figure 3 This is a schematic representation of the restricted area type and permission condition strategy in an embodiment of the present invention. Detailed Implementation

[0035] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] Example 1: Communication Acquisition and Token Management This embodiment details the implementation of steps 1 and 2.

[0037] During system initialization, the base address, username, and password of the external data platform are configured. When data from the electronic vessel nameplate device needs to be retrieved, the communication client module first checks if a valid access token exists in the local cache (such as Redis). The cache key is typically generated by combining the platform identifier and the username. If the cache exists and has not expired, the token is used directly to construct the HTTP request header. If the cache does not exist or has expired, the platform's authentication interface is automatically called, passing in the username and password to request a new token. The response returned by the interface includes the access token string and its validity period (e.g., 7200 seconds). The client module writes the new token and its validity period to the cache and sets the cache's TTL to be slightly less than the token's validity period (e.g., 7000 seconds) to allow buffer time for the next refresh.

[0038] After obtaining a valid token, the client module constructs a device data request URL, appends device type parameters and token authentication headers, and initiates a GET request. Through reasonable timeout settings and retry mechanisms, even in the event of brief network fluctuations, the success rate of a single data retrieval can be maximized.

[0039] This embodiment upgrades token management from a passive response to an active maintenance by adopting a strategy of prioritizing caching and refreshing upon expiration, significantly reducing the probability of data collection interruption due to authentication failure.

[0040] Example 2: Restricted Area Fence Determination and Boundary Crossing Work Order Generation This embodiment details the implementation of steps 3 to 6 and part of step 8.

[0041] Suppose the system loads a list C of boundary coordinates for a seasonal fishing ban zone from the database, containing N points. First, the system performs direction suffix cleaning on each coordinate point in C (e.g., "121.5E" is cleaned to "121.5").

[0042] Next, the cleaned coordinate sequence is sorted or normalized, and then its MD5 hash value is calculated as the signature key (K). The system checks whether a polygon object with key K exists in the cache of the geometry engine module.

[0043] If the coordinates do not exist, a Polygon object is created using the GeometryFactory from the JTS library based on the coordinate sequence. Special attention is paid to ensuring that the first and last points of the coordinate sequence are consistent to form a closed region. After creation, the (K, Polygon) key-value pair is stored in the cache. If the Polygon object exists, it is retrieved directly. When processing the current position p of a fishing boat, the original coordinates of p are first cleaned in the same way and uniformly converted to GCJ-02 coordinates. Then, the Geometry.contains() method is called to determine whether p is inside the previously retrieved Polygon, resulting in inArea=true.

[0044] Since this area is a seasonal fishing ban zone, the strategy evaluation module further determines whether the current date falls within the fishing ban period and whether the fishing vessel's operation type is a prohibited type. If both conditions are met, the output permission decision A=false (entry not permitted).

[0045] The event ticket module receives a judgment result of inArea=true and A=false, and prepares to generate a "violation of boundary" ticket. Before generation, it first queries the database: looking for tickets under the fishing vessel ID with the event type "violation of boundary," the status "unprocessed," and the associated restricted area ID. If a ticket created 10 minutes ago is found, the module will not create a new ticket, but will update the modified_time field of the existing ticket to the current time and may increase its urgency level (if allowed by the rules). If no ticket is found, a new ticket is created, set to a high urgency level, and associated with information such as the fishing vessel, restricted area, coordinates, and time.

[0046] This embodiment, through cache reuse and business rule integration, greatly improves the processing capacity of massive fence determination while ensuring the accuracy of judgment, and effectively manages alarm events through work order deduplication.

[0047] Example 3: Online Timeliness and Offline / Low Power Events This embodiment details another part of the implementation of steps 7 and 8.

[0048] The system received equipment data from a fishing boat, and parsed it to show that the event time te was "2023-10-27T08:50:00Z", the battery level b% was 18%, and the connection status cs was "disconnected".

[0049] The data processing module parses `te` into a `ZonedDateTime` object. The online timeliness determination module takes the current system time (assumed to be 2023-10-27T10:55:00Z) and calculates the time difference as 2 hours and 5 minutes. The system's preset offline time window `W_offline` is 2 hours. Since the time difference is greater than the window threshold, the fishing vessel is determined to be offline (`online=0`).

[0050] Meanwhile, the low battery detection module checks whether the battery percentage (b%) is lower than the threshold (B_low, assumed to be 20%). Since 18% < 20%, a low battery event is triggered.

[0051] For offline events, the event ticket module performs deduplication logic: it checks if there is a "device offline" ticket for the fishing vessel with a status of "unprocessed" or "processing". If a ticket was generated 1 hour ago, only its most recent trigger time is updated. If not, a new ticket is created with a medium urgency level.

[0052] For low battery events, perform deduplication checks (for the "low battery" work order type), create or update the work order, and set the normal urgency level.

[0053] This embodiment demonstrates how to reliably determine offline status using event time windows, and generate multiple types of events by combining threshold judgments. Work orders are managed through a unified deduplication mechanism to reduce redundant alarms caused by temporary status changes or duplicate data reporting.

[0054] Example 4: Kanban and Mobile Display This embodiment details the implementation of step 9 and its role in the regulatory closed loop.

[0055] The persistence module writes the work orders generated in Examples 2 and 3, the updated fishing vessel status (such as "offline warning" and "low battery reminder"), and the fishing vessel's trajectory points (including time, original coordinates, and converted coordinates) into the database. The monitoring platform's web dashboard backend service provides a data interface: Work order list interface: supports pagination, filtering by event type, filtering by time range, and searching by keywords (such as ship name).

[0056] Fishing vessel real-time status interface: Returns the current location of all fishing vessels (GCJ-02 coordinates for map display), online status, and latest alarm information.

[0057] The statistics overview interface provides key indicators such as the total number of work orders today, the number of work orders in progress, and the number of fishing vessels online. The front-end dashboard displays the distribution of fishing vessels in map form, with prohibited areas overlaid as polygon layers. The sidebar displays a list of work orders, allowing processing personnel to click on work orders to view details, perform actions (such as contacting the vessel owner, recording the handling measures), and finally mark them as "completed." Completed work orders are removed from the unprocessed list, but their historical records can still be queried for auditing and analysis. A similar function is provided in the mobile application for convenient use by supervisors in the field.

[0058] This embodiment completes an end-to-end closed loop from data collection to final visualization and processing, making the regulatory process coherent, efficient, and traceable.

[0059] Scope and extension of the present invention The method described in this invention is not only applicable to the electronic vessel registration of marine fishing vessels, but can also be extended to other fields that require mobile target trajectory monitoring, geofencing judgment and event management, such as vehicle transportation supervision, personnel inspection management, and asset tracking.

[0060] The system can flexibly adjust the following parameters through configuration files to adapt to different scenarios: Offline determination time window W_offline Low battery threshold B_low Token caching policy parameters, restricted area types, and their corresponding permission rule bases can be easily expanded or modified as policies change. Coordinate transformation policies can adapt to different coordinate systems or transformation algorithms based on the geographic information regulations of the target deployment area.

[0061] The present invention and its embodiments have been described above. This description is not restrictive, and the accompanying drawings are only one embodiment of the present invention; the actual structure is not limited thereto. In conclusion, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the invention, such designs should fall within the protection scope of the present invention.

Claims

1. A computer-based method for monitoring fishing vessels using electronic vessel identification tags, characterized in that: Includes the following steps: 1) Communication token management steps: Obtain and maintain valid access tokens for accessing the data platform through local caching and automatic refresh mechanisms; 2) Device data acquisition steps: Using the valid access token, collect the data reported by the designated electronic ship tag device from the data platform. The data includes at least the event time, original coordinates, device battery level, and connection status. 3) Coordinate preprocessing and unification steps: The collected raw coordinates are cleaned to remove direction suffix characters, and the cleaned coordinates are converted into coordinates under a unified coordinate system according to the display coordinate system set by the system. 4) Fence determination step: Based on the preloaded boundary coordinates of the restricted area, the spatial relationship between the coordinate points in the unified coordinate system and the restricted area is efficiently determined by caching and reusing polygonal geometric objects; 5) Event generation and work order management steps: Based on the spatial location relationship, equipment power and online status determination results, generate corresponding types of events, and perform deduplication checks and timeliness updates before persisting the events as work orders to form an alarm handling closed loop.

2. The computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The communication token management steps specifically include: first, reading the access token from the local cache; if the cache misses or the token has expired, sending a request to the authentication service to obtain a new token and its expiration date; updating the cache with the new token and its expiration date, and setting the cache's lifespan.

3. The computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The coordinate preprocessing and unification steps also include: providing a reverse transformation method for iterative calculation from the unified coordinate system back to the original coordinate system to ensure coordinate backtracking accuracy.

4. The computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The fence determination step specifically includes: Generate a unique signature for each preloaded restricted area boundary coordinate sequence; Check if a polygon geometry object indexed by this signature exists in the cache; if not, construct and cache it. Points are determined to be on the polygon by directly calling the cached polygon geometry object.

5. A computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 4, characterized in that: The fence determination step is followed by an entry permission determination step: combining the type of the restricted area, the current time, and the attributes of the fishing vessel, the determination step assesses whether the fishing vessel is allowed to enter the restricted area according to preset strategy rules.

6. The computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The method further includes an online timeliness determination step: comparing the event time reported by the device with the current system time; if the time difference exceeds a preset offline determination time window threshold, the device is determined to be offline; otherwise, it is online.

7. A computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The deduplication check in the event generation and work order management steps is as follows: before creating a new work order, check if there is a work order of the same type that is related to the current event and is in an uncompleted state; if so, update the most recent trigger time of the existing work order and do not create a new work order.

8. A computer implementation method for electronic vessel registration and fishing vessel supervision according to claim 1, characterized in that: The method also includes trajectory and situation persistence and display steps: the location coordinates, event time and status of fishing vessels are recorded and stored, and the distribution of fishing vessels, work order list and statistical overview are displayed in real time through a visual dashboard, supporting the processing and completion of work orders.

9. A system for monitoring fishing vessels using electronic vessel tags, characterized in that, include: 1) A communication client module, used to execute the communication token management steps and device data acquisition steps as described in claim 1; 2) Data processing module, used to perform the coordinate preprocessing and unification steps as described in claim 1; 3) Restricted area geometry engine module, used to execute the fence determination step as described in claim 4; 4) Event ticket module, used to execute the event generation and ticket management steps as described in claim 1; 5) Persistence module, used to store trajectory logs, work order data and fishing vessel status.

Images