A method and system for collision warning of open sea vessels

Abstract

This invention belongs to the field of intelligent collision avoidance and early warning technology for ships, specifically relating to a method and system for collision avoidance and early warning in open sea areas. The method includes the following steps in sequence: multi-source navigation data acquisition and analysis, intelligent filtering of open water conditions, real-time calculation of collision risk parameters, collision risk early warning triggering, automatic recording of close-range navigation events, and ship-shore synchronization of early warning and recorded information. The main hardware used in the system includes an AIS signal controller, marine ARPA radar, GPS equipment, gyrocompass, serial port server, switch, collision avoidance tablet computer, captain's cabin computer, ship-side communication host, and shore-side platform. This invention aims to solve the problems of "alarm fatigue" and safety risks caused by numerous invalid alarms and poor scene adaptability in traditional collision avoidance early warning systems during navigation in open sea areas by integrating intelligent scene filtering, accurate risk calculation, and ship-shore collaborative management into a system and method, thereby achieving efficient and reliable automatic collision early warning.

Description

Technical Field

[0001] This invention belongs to the field of intelligent collision avoidance and early warning technology for ships, specifically relating to a method and system for collision avoidance and early warning of ships in open sea areas. Background Technology

[0002] With the rapid development of the global shipping industry, the trend towards larger and faster ships is evident, and maritime traffic volume continues to increase, leading to a significant rise in the frequency of ship encounters and the risk of collisions in open waters. Ship collisions are one of the main threats to maritime safety. Statistics show that collisions in open waters often result in serious consequences due to late detection, delayed judgment, and untimely avoidance. Although the International Maritime Organization mandates that ships be equipped with Automatic Identification Systems (AIS) and radar, how to automatically and accurately identify genuine collision risks and provide timely warnings from massive amounts of real-time navigation information remains a key technical challenge for ensuring navigation safety in open waters.

[0003] Currently, collision avoidance in open waters primarily relies on continuous lookout by crew members, experience-based judgment, and manual monitoring and analysis of electronic navigation equipment (such as AIS and radar). Traditional methods typically rely on electronic chart systems or simple AIS displays, with crew members manually observing the dynamics of surrounding vessels and estimating the encounter situation based on experience. However, this manually-driven approach has significant limitations: First, manual monitoring suffers from blind spots and fatigue risks. During long voyages or in poor visibility, crew members struggle to continuously track and assess dozens or even hundreds of surface targets. Second, risk assessment is delayed and highly subjective. Crew members need to comprehensively calculate the target's course, speed, encounter distance, and encounter time from scattered AIS and radar information, a cumbersome and error-prone process that often results in a reaction only when danger is imminent. Furthermore, existing early warning systems lack scenario adaptability. Many commercial collision avoidance alarms generate numerous invalid alarms in complex waters such as ports and straits, forcing crew members to shut down the system, thus losing automatic warning protection when entering truly open, high-risk areas.

[0004] To address the aforementioned issues, existing technologies include some research and applications of automatic collision avoidance warnings based on AIS and radar data, such as issuing warnings by calculating the minimum encounter distance and minimum encounter time between two vessels. However, these methods generally suffer from low warning effectiveness and a large amount of interference. Their algorithms typically treat all waters equally, generating continuous interference alarms in densely populated ports and waterways, leading to "alarm fatigue" among crew members and even selectively ignoring all alarms. Simultaneously, the systems cannot effectively filter out non-collision risk targets such as radar clutter, high-speed small boats, fishing nets, and buoys, as well as abnormal data caused by signal errors, resulting in a high false alarm rate. Furthermore, existing systems have limited functionality, focusing on real-time alarms and lacking the ability to objectively record and analyze the navigation process afterward, and they cannot effectively coordinate with shore-based safety management. Therefore, there is an urgent need for a new collision avoidance warning method and system that can intelligently identify application scenarios, automatically filter invalid information, accurately focus on real collision risks in open sea areas, and possess ship-shore collaborative management capabilities, in order to significantly improve the effectiveness of warnings and the overall safety management level of vessels. Summary of the Invention

[0005] This invention addresses the "alarm fatigue" and safety risks caused by the numerous invalid alarms and poor scenario adaptability of traditional collision avoidance warning systems when navigating in open seas, and provides a method and system for collision avoidance warning of ships in open seas.

[0006] The technical solution claimed by this invention is as follows:

[0007] A method for ship collision avoidance early warning in open sea areas includes the following steps:

[0008] S1: Multi-source navigation data acquisition and analysis: Through the signal conversion server, the ship's AIS, ARPA radar target, GPS and gyrocompass data are accessed, the ship's data is acquired, the acquired data is converted into network signals, and the network signals are output as messages through Ethernet. The various messages are decoded, analyzed and fused.

[0009] S2: Intelligent Filtering for Open Water Conditions: Automatically filters the data obtained from S1 according to preset electronic fence rules, dynamic target and scene rules, filters out invalid alarm signals that occur in non-open water areas, and removes interference data from non-ship targets.

[0010] S3: Real-time calculation of collision risk parameters: Based on the ship's current course, speed and position, calculate in real time the minimum encounter distance and minimum encounter time between the ship and all other ship targets within the effective range after filtering and screening.

[0011] S4: Collision Risk Warning Trigger: When the minimum encounter distance and minimum encounter time calculated by S3 are both lower than the preset alarm threshold, the system determines that there is a collision risk, immediately triggers an alarm, and pushes the warning information to the shore platform;

[0012] S5: Automatic recording of close-range navigation events: Regardless of whether the alarm threshold described in S4 is reached, as long as another vessel enters the designated range of this vessel, an encounter event with key data will be automatically recorded and simultaneously reported to the shore platform.

[0013] S6: Ship-shore synchronization of early warning and recording information: The ship automatically and in real time compresses and reports real-time collision risk early warning information and encounter event records within a specified range to the shore platform via the network.

[0014] Preferably, step S1 involves real-time aggregation of the ship's AIS, ARPA radar target, GPS, and gyrocompass data, followed by preliminary structuring processing. This is specifically implemented through a hardware layer, a parsing layer, and a fusion layer. The hardware layer utilizes the heterogeneous signal access and networking capabilities of the NS304I signal conversion server. This server has multiple serial communication ports, allowing the ship's four types of data to be accessed through different ports and converted into standard TCP / IP network data packets in real-time. The converted data is then output as messages via a network cable and connected to the ship's local area network. The parsing layer decodes the messages and extracts key information based on the NMEA 0183 standard. The fusion layer performs spatiotemporal alignment and structured encapsulation of the multi-source data based on timestamps.

[0015] Preferably, the network data stream output by the NS304I signal conversion server is an ASCII text string conforming to the NMEA 0183 format, with each statement beginning with "$" or "!" and ending with "". <cr> <lf>"End. The processing steps for each statement are as follows:"

[0016] Step 1: Format verification and filtering: Perform statement format integrity checks, verification and validation, and discard invalid or damaged messages; then classify and filter messages according to statement identifiers, and only process message types related to ship collision avoidance warnings;

[0017] Step 2: Deep Decoding of AIS Messages: For AIS !AIVDM / !AIVDO statements, the payload is decoded according to the ITU-R M.1371 protocol standard as follows:

[0018] Step 2.1: 6-bit ASCII to binary: Convert each character in the payload to 6 bits of binary data and concatenate them into a complete binary data stream;

[0019] Step 2.2: Bit-by-bit parsing: Based on the AIS message type, extract the required fields from the binary data stream according to the bit offsets and lengths defined in the protocol.

[0020] a. User ID / MMSI: 8-37 digits, converted to a decimal integer;

[0021] b. Longitude: 61-88, 1 / 10000, converted to decimal system using the following formula:

[0022] (1)

[0023] c. Latitude: 89-115, 1 / 10000, conversion formula is:

[0024] (2)

[0025] d. Ground speed: 50-59 knots, equivalent to 1 / 10 of a knot. The conversion formula is:

[0026] (3)

[0027] e. Heading relative to the ground: Position 116-127, 1 / 10 degree, conversion formula is:

[0028] (4)

[0029] In formulas (1)-(4): Lon deg Longitude, decimal system; Lon raw Represents the raw longitude value, the unconverted numerical value extracted from the data in units of 1 / 10000th of a degree; Lat deg Indicates latitude, decimal system; Lat raw Represents the raw latitude value, an unconverted numerical value extracted from the data in units of 1 / 10000; SOG knots Speed ​​over ground, unit: knots; SOG raw Represents the raw ground speed value, the unconverted value extracted from the data in units of 1 / 10 knots; COG knots COG indicates heading relative to the ground, in degrees; raw This represents the original heading value relative to the ground, an unconverted value extracted from the data in units of 1 / 10 degrees.

[0030] Preferably, the spatiotemporal alignment and structured encapsulation process is as follows:

[0031] Step 1: Time base unification: The UTC timestamp in the GPS message is used as the main time base. All parsed data points are accompanied by their original timestamp. If there is no original timestamp, it is marked as the time of receipt.

[0032] Step 2: Ship State Fusion: Associate the ground heading (COG), ground speed (SOG), and position (Lat / Lon) from GPS with the actual ship heading (HDG) from the gyrocompass; pair the GPS and gyrocompass (GYRO) data within the same time window to form a complete ship state structure, OwnShipState(t):

[0033] (5)

[0034] Step 3: Target Ship Data Structuring: The parsed data from AIS and ARPA are encapsulated into a unified target ship structure TargetState(i, t) according to their unique identifiers and location information, respectively. For the same physical target tracked by both AIS and ARPA, the system can perform data association based on location correlation, prioritizing the use of the more informative AIS data, and using ARPA data as a backup or verification. The unique identifier for AIS is MMSI, and the unique identifier for ARPA is the target number.

[0035] Step 4: Data Buffer and Output: The processed ship status and target ship list are temporarily stored in a thread-safe circular buffer.

[0036] Preferably, step S2 designs a three-level progressive intelligent filtering mechanism, including: first-level filtering, second-level filtering, and third-level filtering; the first-level filtering is static geographic area filtering; the second-level filtering includes filtering based on target dynamic attributes and scene filtering based on traffic density; the third-level filtering is manual control filtering based on captain's decision; the first-level filtering excludes non-open areas; the filtering based on target dynamic attributes specifically includes:

[0037] a. Target filtering for abnormal speeds: Any target whose reported ground speed exceeds a preset physical limit threshold is directly filtered out, i.e.:

[0038] (6)

[0039] This rule is used to filter out non-merchant vessel collision risk sources such as high-speed small boats and "flying points" caused by data errors;

[0040] b. Filtering known non-ship targets: For AIS targets, if their MMSI or ship type code belongs to known special purpose identifiers such as fishing net buoys, search and rescue beacons, etc., they are directly filtered; for ARPA targets, although the type cannot be directly identified, it can be indirectly determined by associating them with AIS targets.

[0041] The scene filtering based on traffic density counts the number of ships within two concentric circles centered on the current ship: Let... This represents the total number of ships within a 3-nautical-mile radius. Given the total number of vessels within a 6-nautical-mile radius, the rules for determining densely populated areas are as follows:

[0042] (7)

[0043] if Greater than 5 and If the value is greater than 20, it is marked as dense and filtered directly.

[0044] Preferably, the calculation in step S3 is based on the following assumptions: within the short-term prediction window, both the ship and the target ship maintain their current course and speed. By establishing a mathematical model of the relative motion of the two ships, the extreme points of their future relative positions are solved, thereby obtaining the minimum encounter distance DCPA and the minimum encounter time TCPA. The specific process is as follows:

[0045] Step 1: Mathematical Model Establishment and Coordinate Transformation

[0046] a. Data Input: For each valid target ship that needs to be calculated... Obtain the following real-time data: Ship status: position ,course speed Target ship Status: Position ,course speed ;

[0047] b. Projection transformation from latitude and longitude to plane coordinates: Since DCPA / TCPA calculations involve distance and direction, the Earth's sphere is usually approximated as a plane in local sea areas. The latitude and longitude of all ships are transformed into a plane rectangular coordinate system through map projection in order to perform vector calculations;

[0048] Step 2: Relative Motion Vector Decomposition and Calculation

[0049] Based on the assumption of uniform linear motion, the positions of the ship and the target ship after time t can be predicted as follows:

[0050] Our ship's position:

[0051] Target ship location:

[0052] in, , and , These are the components of the velocity vectors of the ship and the target ship in the planar coordinate system:

[0053] (8)

[0054] sin corresponds to the eastward component, cos corresponds to the northward component, depending on the coordinate axis definition; C is the angle from true north in a clockwise direction.

[0055] The relative position vectors of the two ships for:

[0056] (9)

[0057] Let the initial relative position be The relative velocity vector is ,but:

[0058] (10)

[0059] Step 3: Solving for minimum meeting distance and minimum meeting time

[0060] Minimum meeting distance refers to the shortest relative distance that two ships will reach if they continue sailing at their current state of motion; this is a vector problem. The problem of finding the minimum value of the modulus;

[0061] a. Calculate the relative motion parameters:

[0062] Relative speed: ;

[0063] Initial distance: .

[0064] b. Solving for the minimum encounter time: Based on vector analysis, when the relative position vectors... With relative velocity vector When the two ships are perpendicular, the distance between them is the shortest; from this, the time to reach the minimum meeting point can be derived. :

[0065] (11)

[0066] like This indicates that the two ships have not yet reached their closest point and will meet again in the future. Arrive in hours;

[0067] like This indicates that the two ships have passed their closest point and the distance between them is increasing;

[0068] like This indicates that the current point is the closest point;

[0069] c. Solve for the minimum encounter distance: Substituting into the relative position equation, the minimum meeting distance can be obtained. :

[0070] (12)

[0071] Unit conversion: Calculated If the unit is meters, it needs to be divided by 1852 to convert to nautical miles; If the unit is hours, it needs to be multiplied by 60 to convert it to minutes.

[0072] Preferably, the specified range for this vessel in S5 is 1 nautical mile.

[0073] This invention also provides a system for collision avoidance early warning of ships in open sea areas, implementing the aforementioned method. The main hardware of the system includes an AIS signal, a marine ARPA radar, a GPS device, a compass, a serial port server, a switch, a collision avoidance tablet computer, a captain's cabin computer, a shipboard communication host, and a shore-based platform. The AIS signal, marine ARPA radar, GPS device, and compass are located at the ship's end. The serial port server connects to the AIS signal, marine ARPA radar, GPS device, and compass via the ship's bridge. The collision avoidance tablet computer, captain's cabin computer, and shipboard communication host read data from the serial port server via the switch. The shipboard communication host connects to the shore-based platform and transmits information from the ship to the shore-based platform.

[0074] Preferably, the serial port server is an NS304I signal conversion server with multiple serial communication ports, connecting four data sources respectively: PORT1: connected to the A and B signal lines output by the AIS signal controller; the AIS data stream output by the AIS signal controller contains dynamic and static information of the ship and surrounding vessels, conforming to the IEC 61162-1 / 2 standard; PORT2: connected to the TTM message output by the marine ARPA radar; the TTM message provides the distance, bearing, heading, and speed information of the radar automatically tracking target, effectively supplementing the AIS data, especially for ships with the AIS not activated or malfunctioning; PORT3: connected to the Global Positioning System (GGA) positioning data and Recommended Minimum Specific Navigation (RMC) statement output by the GPS receiver, providing the ship with high-precision longitude, latitude, speed above ground, heading above ground, and UTC timestamp; PORT4: connected to the heading-true north (HDT) or heading (HDG) message output by the gyrocompass, providing the ship's true heading, used to correct the GPS heading above ground. The deviation of COG is caused by the airflow pressure difference.

[0075] Preferably, the ship-side communication host automatically and in real time compresses and reports the real-time collision risk warning information, 1-nautical-mile encounter event records, and the system's own operation logs to the shore-side platform via the network.

[0076] The beneficial effects of this invention are as follows:

[0077] This invention provides a method and system for collision avoidance early warning in open sea areas. Compared with existing technologies, this invention offers the following technical advantages: it achieves precise focusing and proactive interference reduction in early warning scenarios. Traditional collision avoidance early warning systems typically treat all waters equally, generating numerous "invalid alarms" in complex waters such as ports and waterways that conform to algorithmic logic but have no practical avoidance significance. This leads to "alarm fatigue" among crew members and may even cause the system to shut down, creating safety hazards. This invention, through an intelligent filtering mechanism for open water conditions, automatically identifies and silences alarm functions within electronic fence areas (ports, narrow waterways, etc.) before calculating risks, and can suppress front-end alarm prompts during periods of extremely dense traffic flow. This ensures that the system's core early warning function is highly focused on open sea areas, proactively shielding interference sources and making each alarm more targeted and valuable. This significantly improves crew members' trust in and willingness to use the system, solving the "alarm fatigue" and safety risks caused by numerous invalid alarms and poor scenario adaptability in traditional collision avoidance early warning systems operating in open seas. This invention improves the accuracy and reliability of risk assessment. Existing technologies often rely on a single DCPA or TCPA threshold for alarms, which are prone to false alarms or missed alarms due to instantaneous parameter fluctuations or special encounter situations (such as large-angle intersections). This invention uses an AND logic between DCPA and TCPA as the core trigger condition, meaning that both "encounter distance too close" and "encounter time urgent" conditions must be met simultaneously for a collision risk to be determined. This dual-parameter coupled criterion better aligns with the definition of emergency situations in maritime practice, effectively filtering out pseudo-risk scenarios of "distance without time" or "time without distance," significantly improving the accuracy and reliability of alarms and reducing false alarms that might interfere with the navigator. It constructs a dual-pillar safety management system that emphasizes both "real-time early warning" and "process traceability." Existing systems often limit their functionality to real-time alarms. While providing accurate real-time early warnings, this invention also includes an independent and parallel "automatic recording of events within a certain range" function. Regardless of whether the alarm threshold is reached, as long as another vessel enters a certain range, the system automatically and objectively records a complete encounter event. This is equivalent to installing a "navigation safety black box" on the ship, forming a complete data chain covering "high-risk instantaneous events" and "close-range encounters throughout the entire process." This record provides an objective data foundation for shore-based safety management to quantitatively assess the effectiveness of crew lookout and avoidance, analyze navigation habits, conduct accident tracing and training, and shift safety management from post-incident investigation to process supervision and continuous improvement. It achieves a closed-loop collaborative safety management system integrating ship and shore. Traditional ship-based early warning systems suffer from information silos, and shore-based management lacks real-time, objective process data. The ship automatically and in real-time compresses and reports collision risk warnings and encounter event records within a specified range to the shore platform via the network. This enables shore-based maritime personnel to grasp the navigation safety situation of the global fleet in near real-time, remotely track and coordinate the handling of high-risk events, and effectively supervise equipment usage (such as whether it has been improperly shut down).This connects the data and business flows from "ship-based perception" to "shore-based management," achieving a deep integration of intelligent early warning for individual ships and systematic safety management of the fleet, greatly enhancing the overall safety risk prevention and control capabilities. Attached Figure Description

[0078] Figure 1 This is a flowchart of a method for ship collision avoidance and early warning in open sea areas, as described in an embodiment of the present invention.

[0079] Figure 2 This is a schematic diagram of the hardware of a system for ship collision avoidance and early warning in open sea areas, as described in an embodiment of the present invention. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions will be further described clearly and completely below with reference to the accompanying drawings.

[0081] This invention provides a method and system for collision avoidance early warning in open sea areas. It aims to solve the "alarm fatigue" and safety risks caused by traditional collision avoidance early warning systems in open sea navigation, which suffer from numerous invalid alarms and poor scene adaptability, through a system and method integrating intelligent scene filtering, accurate risk calculation, and ship-shore collaborative management. This achieves efficient and reliable automatic collision warning. Figure 1 As shown, the method includes the following steps in sequence: multi-source navigation data acquisition and analysis, intelligent filtering of open water conditions, real-time calculation of collision risk parameters, collision avoidance risk warning triggering, automatic recording of close-range navigation events, and ship-shore synchronization of warning and recording information. Figure 2 As shown, the main hardware used in the system includes AIS signal controller, marine ARPA radar, GPS equipment, gyrocompass GYRO, serial server, switch, collision avoidance tablet computer, captain's cabin computer, shipboard communication host and shore platform.

[0082] The multi-source navigation data acquisition and parsing process mainly involves using a serial port server to access the ship's AIS, ARPA radar target, GPS, and gyrocompass data from the ship's control console. This process converts the serial data format navigation messages into network signals, connects them to the system's processing host via Ethernet, and then decodes, parses, and fuses the various messages.

[0083] The basic idea behind this step is:

[0084] Addressing the challenges of diverse signal formats, interfaces, and information dispersion from various navigation sensors (AIS, ARPA, GPS, Gyro) in the ship navigation environment, a standardized data processing front-end chain is constructed, encompassing hardware signal access, format conversion, software parsing, and spatiotemporal alignment. Its core objective is to physically integrate four key, heterogeneous data streams into the central processing unit in a lossless, real-time, and reliable manner, performing preliminary structured processing to provide unified, high-quality data input for subsequent intelligent filtering and risk calculation. The implementation is divided into the following three layers:

[0085] 1. Hardware Layer: Heterogeneous Signal Access and Networking Based on NS304I Signal Conversion Server

[0086] 1.1. Port Definition and Physical Signal Access: The system provided by this invention uses a serial port server (one NS304I signal conversion server) as the core access device. This device has multiple serial communication ports (RS-232 / 422 / 485). Following strict port mapping rules, the four navigation data sources are connected respectively:

[0087] PORT1: Connects to the A and B signal lines output by the AIS signal controller. The AIS data stream contains dynamic (position, heading, speed) and static (ship name, MMSI) information of this ship and other surrounding ships, in accordance with the IEC 61162-1 / 2 (NMEA 0183) standard.

[0088] PORT2: Accesses TTM (Radar Track Target) messages output by the marine ARPA radar. TTM messages provide information such as the distance, bearing, heading, and speed of the radar-tracked target, effectively supplementing AIS data, especially for vessels with AIS not activated or experiencing AIS malfunction.

[0089] PORT3: Accesses GGA (Global Positioning System positioning data) and RMC (Recommended Minimum Specific Navigation Data) statements output by the GPS receiver, providing the ship with high-precision longitude, latitude, ground speed, ground heading, and UTC timestamp.

[0090] PORT4: Access the HDT (Heading-True North) or HDG (Heading) messages output by the gyrocompass to provide the ship's true heading. This is used to correct for deviations caused by wind and pressure differences in GPS COG (Course of Horizon), ensuring the accuracy of the ship's heading reference.

[0091] 1.2 Signal Conversion and Network Transmission: The NS304I signal conversion server has built-in protocol conversion firmware. Its core function is to convert serial data streams input from the four ports mentioned above, based on different electrical standards (such as RS-422 for AIS) and baud rates, into standard TCP / IP network data packets in real time. The conversion process ensures data integrity and timing. The converted data is output through a network cable (connected to the Ethernet port of the NS304I) and connected to the ship's local area network. The system's processing host (industrial-grade touch panel) receives these TCP data streams through another independent network interface (isolated from the ship's business network to avoid interference). This hardware solution decouples data acquisition and processing, ensures the independence of the original navigation equipment link, and allows the data processing host to be flexibly deployed at any location on the bridge.

[0092] 2. Parsing Layer: Message decoding and key information extraction based on the NMEA 0183 standard.

[0093] The acquisition service running on the processing host of the system provided by this invention continuously monitors the network data stream from the NS304I signal conversion server. The received raw data is an ASCII text string conforming to the NMEA 0183 format, with each statement beginning with "$" or "!" and ending with " <cr> <lf>"End. Process each statement as follows:"

[0094] Step 1: Format Verification and Filtering: First, perform statement format integrity checks, verification, and validation, discarding invalid or corrupted messages. Then, classify and filter messages according to statement identifiers (such as !AIVDM, !AIVDO, $TTM, $GPGGA, $GPRMC, $HEHDT), processing only message types related to ship collision avoidance warnings.

[0095] Step 2: Deep Decoding of AIS Messages: For AIS !AIVDM / !AIVDO statements, the payload portion uses 6-bit ASCII encoding compression. This is the most complex part of the parsing. According to the ITU-R M.1371 protocol standard, the payload is decoded as follows:

[0096] Step 2.1: 6-bit ASCII to binary: Convert each character in the payload (ASCII value minus 48, then ANDed with 0x3F) into 6-bit binary data and concatenate them into a complete binary data stream.

[0097] Step 2.2: Bit-by-bit parsing: Based on the AIS message type (Message ID), extract the required fields from the binary stream according to the bit offset and length defined in the protocol. For example, for message types 1, 2, and 3 (Class A location reports):

[0098] a. User ID / MMSI: 8-37 bits, converted to decimal integer.

[0099] b. Longitude: 61-88, 1 / 10000 (signed 28-bit integer), convert to decimal using the following formula:

[0100] (1)

[0101] c. Latitude: 89-115, 1 / 10000 (signed 27-digit integer), conversion formula is:

[0102] (2)

[0103] d. Ground speed: 50-59 knots, equivalent to 1 / 10 of a knot. The conversion formula is:

[0104] (3)

[0105] e. Heading relative to the ground: Position 116-127, 1 / 10 degree, conversion formula is:

[0106] (4)

[0107] In formulas (1)-(4): Lon deg Longitude, decimal system; Lon raw Represents the raw longitude value, the unconverted numerical value extracted from the data in units of 1 / 10000th of a degree; Lat deg Indicates latitude, decimal system; Lat raw Represents the raw latitude value, an unconverted numerical value extracted from the data in units of 1 / 10000; SOG knots Speed ​​over ground, unit: knots; SOG raw Represents the raw ground speed value, the unconverted value extracted from the data in units of 1 / 10 knots; COG knots COG indicates heading relative to the ground, in degrees; raw This represents the original heading value relative to the ground, an unconverted value extracted from the data in units of 1 / 10 degrees.

[0108] Step 3: Parsing other messages: For NMEA statements such as TTM, GGA / RMC, and HDT, parse each field directly according to the comma separator and convert it into the corresponding value and unit.

[0109] 2. Fusion Layer: Spatiotemporal alignment and structured encapsulation of multi-source data based on timestamps

[0110] Different data sources update at different frequencies (AIS approximately 2-10 seconds, ARPA radar targets approximately 2-6 seconds, GPS approximately 1 second, gyrocompass approximately 1 second), and there may be slight time delays. To ensure that subsequent calculations use a "snapshot" of the same moment for data fusion:

[0111] Unified time reference: The UTC timestamp in the GPS message is used as the primary time reference. All parsed data points are accompanied by their original timestamp (if none is available, it is marked as the time of receipt).

[0112] Ship state fusion: This involves correlating COG (heading over land), SOG (speed over land), and Lat / Lon (position) from GPS with HDG (heading over land) from the gyrocompass. While COG and SOG are typically used for DCPA / TCPA calculations, HDG is crucial for determining ship maneuvering intentions, displaying a "head-up" view, and advanced behavioral analysis. GPS and GYRO data within the same time window (e.g., ±0.5 seconds) are paired to form the complete ship state structure, OwnShipState(t).

[0113] (5)

[0114] Target vessel data structuring: Parsed data from AIS and ARPA are encapsulated into a unified target vessel structure TargetState(i, t) according to their unique identifiers (MMSI for AIS, target number for ARPA) and location information. For the same physical target tracked by both AIS and ARPA, data is correlated based on location correlation, prioritizing the use of more informative AIS data, and using ARPA data as a backup or for verification.

[0115] Data Buffer and Output: The processed ship status and target ship list are temporarily stored in a thread-safe circular buffer. This buffer, acting as a "data pool," is read at a fixed frequency (e.g., 1Hz) by the "Open Water Condition Intelligent Filtering" step for subsequent processing.

[0116] Through the above three-layer processing, the transformation from physical signals to structured information is realized, laying a precise, real-time, and integrated data foundation for the entire open sea collision avoidance and early warning system.

[0117] The aforementioned intelligent filtering of open water conditions automatically filters the collected data according to preset electronic fence rules, dynamic targets and scene rules, filtering out invalid alarm signals occurring in non-open sea areas such as ports, narrow waterways, and dense traffic areas, and eliminating interference data from non-ship targets such as abnormal speed and fishing nets, ensuring that the core function focuses on the process of encountering situations in open water.

[0118] The basic idea behind this step is:

[0119] To overcome the drawback of "alarm fatigue" in existing collision avoidance warning systems, this invention does not directly perform collision calculations on all detected targets. Instead, it designs a three-level progressive intelligent filtering mechanism. This mechanism simulates the decision-making logic of experienced pilots facing different navigation environments, actively and selectively "reducing noise" in the data source before collision calculation. Its core is to accurately define the judgment boundary of "effective collision risk in open sea areas" through a combination of spatial geofencing, dynamic feature thresholds, and manual intervention commands, thereby greatly improving the effectiveness of subsequent warnings. The specific filtering logic is as follows:

[0120] 1. First-level filtering: Static geographic area filtering (electronic fence)

[0121] The goal of this filter layer is to exclude non-open water areas in space, which is the primary prerequisite for ensuring focus on the design scenario.

[0122] (1) Construction and management of the geofence database: The system has a built-in manageable geofence database. This database contains two types of areas:

[0123] a. Pre-defined complex waterways: This includes at least the territorial sea baseline of the People's Republic of China and 14 globally recognized narrow and busy waterways such as the English Channel, the Strait of Gibraltar, the Suez Canal, and the Panama Canal. The latitude and longitude boundary polygons of these areas are predefined and stored in the system.

[0124] b. Expandable Area: Supports shore-based management personnel to add electronic fences for areas such as ports, anchorages, and specific controlled waterways as needed through the shore-based platform, and remotely distribute them to shipboard equipment.

[0125] (2) Enclosure Detection and Function Silence: Real-time point-to-surface containment detection is performed between the ship's GPS location (Lon_{own}, Lat_{own}) and all geofence polygons. The commonly used algorithm is the Ray Casting Algorithm. When the ship is detected to be inside any geofence polygon, the following operations are immediately performed:

[0126] a. Suspend collision avoidance warning function: Stop DCPA / TCPA calculation and collision risk alarm for all targets.

[0127] b. Pause automatic recording within 1 nautical mile: Stop generating records of events encountered within 1 nautical mile.

[0128] c. Interface status prompt: The status window in the lower left corner of the software interface displays the name of the current area (such as "English Channel"), clearly informing the crew that the system has entered filtering mode.

[0129] d. Logical basis: In narrow, congested or special traffic areas, encounters between vessels are common. Simple DCPA / TCPA alarms are no longer applicable. Avoidance actions are more based on the specific provisions of the International Regulations for Preventing Collisions at Sea and local special regulations. In this case, the system's automatic alarms may actually cause interference.

[0130] 2. Second-level filtering: Dynamic target and traffic scene filtering

[0131] After passing through the first-level geographic filter (i.e., the ship is in open water), this filter layer performs fine screening of individual targets and the overall traffic scene.

[0132] (1) Filtering based on target dynamic attributes:

[0133] a. Target filtering for abnormal airspeed: Any target (AIS or ARPA) whose reported ground speed (SOG) exceeds a preset physical limit threshold will be filtered. (If the default setting is 50 sections), then it will be filtered directly. That is:

[0134] (6)

[0135] This rule is used to filter out non-merchant vessel collision risk sources such as high-speed small boats and "flypoints" caused by data errors.

[0136] b. Filtering known non-ship targets: Maintain a special code list. For AIS targets, if their MMSI or ship type code belongs to a known special-purpose identifier such as a fishing net buoy or search and rescue beacon, they are directly filtered. For ARPA targets, although the type cannot be directly identified, it can be indirectly determined by associating them with AIS targets.

[0137] (2) Scene filtering based on traffic density:

[0138] This rule is designed to address special scenarios where, although the geographical area is open water, there is an extremely high instantaneous traffic flow. It involves real-time counting of vessels within two concentric circles centered on the current vessel.

[0139] set up This represents the total number of ships within a 3-nautical-mile radius. This represents the total number of ships within a 6-nautical-mile radius. The rules for determining densely populated areas are as follows:

[0140] (7)

[0141] When a scene is marked "DENSE", differentiated processing is applied:

[0142] a. Front-end alarm suppression: Suspend collision alarm confirmation prompts on the dashboard tablet software interface to avoid continuous audible and visual alarms interfering with the driver's decision-making in complex situations.

[0143] b. Continuous background recording: Collision risk calculation and 1-nautical-mile recording continue as normal in the background, and all data is uploaded to the shore-based platform as usual. This ensures that safety management is not lacking, with only interference reduction at the interaction level.

[0144] 3. Third-level filtering: Manually controlled filtering based on captain's decisions

[0145] This filter layer embodies the design concept of human-machine collaboration, giving the highest decision-maker (the captain) ultimate control.

[0146] (1) Function switch command analysis: The captain can manually turn off the collision avoidance detection and recording function through the "Stop" button on the tablet software interface. This command will take effect immediately after being captured.

[0147] (2) Behavior in switch state:

[0148] a. Off state: Stops all collision calculations, alarms, and 1-nautical-mile recording. This is the most thorough filtering state.

[0149] b. On status: Normal operation restored.

[0150] (3) Status recording and monitoring: Crucially, regardless of whether the captain turns the system on or off, this "power-on / off" action itself will be recorded as a critical operational event in the local log and simultaneously pushed to the shore-based system. This ensures that shore-based marine management personnel can monitor the use of the equipment, prevent the equipment from being shut down without cause for a long period of time, and form a closed loop in management.

[0151] After filtering, a target's data is marked as "valid" and flows into the next step—the "real-time collision risk parameter calculation" module—only when the target is not within the electronic fence, its speed does not exceed the anomaly threshold, it is not a known special target, the current traffic scenario is not in a dense mode (or it is in a dense mode but the target on this ship still participates in the background calculation), and the system has not been manually shut down by the captain. Through this three-level "static-dynamic-manual" filtering system, the system achieves precise purification from "full data" to "high-value data," creating a clean and efficient input environment for the core early warning algorithm.

[0152] The real-time calculation of collision risk parameters refers to the process of calculating the minimum encounter distance and minimum encounter time between the ship and all other ship targets within the effective range after filtering and screening, based on the ship's current course, speed and position.

[0153] The basic idea behind this step is:

[0154] After completing the "Intelligent Filtering for Open Water Conditions," a high-quality list of target vessels with potential encounter relationships with our ship was obtained. The core of this step is to apply a kinematic geometry model to predict and quantify the relative motion trend between our ship and each target vessel over a future period. Its output parameters are the minimum encounter distance and minimum encounter time, which are internationally recognized core indicators for quantifying collision risk. The calculation model is based on the following assumption: within a short prediction window (typically several minutes), both our ship and the target vessel maintain their current course and speed (uniform linear motion). By establishing a mathematical model of the relative motion of the two ships, the extreme points of their future relative positions are solved, thus obtaining the DCPA and TCPA.

[0155] 1. Mathematical Model Establishment and Coordinate Transformation

[0156] (1) Data input: For each valid target ship that needs to be calculated The system obtains the following real-time data: Ship status: position (Plane coordinates), heading (True north direction, degrees), speed Target ship Status: Position ,course speed .

[0157] Note: COG and SOG are typically used for calculations to reflect the actual ground motion trend. Ship's heading. COG from GPS, target ship's heading The heading is taken from COG or ARPA calculations from AIS.

[0158] (2) Projection transformation from latitude and longitude to plane coordinates: Since DCPA / TCPA calculations involve distance and direction, the Earth's surface is usually approximated as a plane in local sea areas (such as within tens of nautical miles). First, the latitude and longitude of all ships are converted into plane coordinates. Transform to a Cartesian coordinate system using a map projection (such as the Mercator projection). The coordinates are converted to allow for vector operations. The converted coordinate units are usually meters.

[0159] 2. Relative Motion Vector Decomposition and Calculation

[0160] Based on the assumption of uniform linear motion, the positions of the ship and the target ship after time t can be predicted as follows:

[0161] Our ship's position:

[0162] Target ship location:

[0163] in, , and , These are the components of the velocity vectors of the ship and the target ship in the planar coordinate system:

[0164] (8)

[0165] Note: Here, sin corresponds to the eastward component, and cos corresponds to the northward component, depending on the coordinate axis definition; C is the angle from true north in a clockwise direction.

[0166] The relative position vectors of the two ships for:

[0167] (9)

[0168] Let the initial relative position be The relative velocity vector is ,but:

[0169] (10)

[0170] 3. Solving for minimum meeting distance and minimum meeting time

[0171] The minimum meeting distance is the shortest relative distance that two ships will reach if they continue sailing at their current states of motion. This is a vector problem. The problem of finding the minimum value of the modulus.

[0172] (1) Calculate the relative motion parameters:

[0173] Relative speed: ;

[0174] Initial distance: .

[0175] (2) Solving for the minimum meeting time: According to vector analysis, when the relative position vectors With relative velocity vector When the two ships are perpendicular, the distance between them is the shortest. From this, the time to reach the minimum meeting point can be derived. (Unit: hours, usually converted to minutes):

[0176] (11)

[0177] Physical meaning: It can be positive, negative, or zero:

[0178] like This indicates that the two ships have not yet reached their closest point and will meet again in the future. Arrive in hours.

[0179] like This indicates that the two ships have passed their closest point and the distance between them is increasing.

[0180] like This indicates that the current point is the closest point.

[0181] (3) Solve for the minimum meeting distance: Substituting into the relative position equation, the minimum meeting distance can be obtained. Units: consistent with coordinate units, usually converted to nautical miles).

[0182] (12)

[0183] Unit conversion: Calculated If the unit is meters, it needs to be divided by 1852 to convert to nautical miles. If the unit is hours, it needs to be multiplied by 60 to convert it to minutes.

[0184] This step is for each valid target ship. Output a tuple , and mark Positive and negative. This quantified risk parameter pair is the sole direct basis for the logical judgment in the next step of "collision avoidance risk warning triggering". By continuously, quickly and accurately calculating these parameters, digital and dynamic perception of the navigation situation in open waters is achieved.

[0185] The aforementioned collision avoidance risk warning trigger refers to the process where, when the calculated minimum encounter distance and minimum encounter time are both lower than the preset alarm threshold, the system determines that there is a collision risk, immediately triggers audible, visual, and graphical interface alarms, and pushes the warning information to the shore platform.

[0186] The basic idea behind this step is:

[0187] After obtaining the quantitative risk parameters (DCPA, TCPA) for all valid targets, the risk must be binary-classified (i.e., "risk exists" or "no risk") according to a clear and configurable set of judgment rules. This step innovatively uses an "AND" logic (both conditions must be met simultaneously) as the trigger condition, rather than a single DCPA or TCPA threshold judgment. This significantly improves the accuracy and reliability of alarms and reduces false alarms caused by transient fluctuations in a single parameter. Once a risk is determined, the system will activate a hierarchical, multi-layered, and traceable alarm response mechanism to ensure that warning information is effectively transmitted to the driver and to provide a complete data chain for safety management.

[0188] 1. Risk Assessment: Based on "AND" logic with dual thresholds

[0189] (1) Alarm threshold setting: The system has a default alarm threshold, which can be adjusted within a certain range. The default value is:

[0190] Minimum encounter distance threshold: nautical miles;

[0191] Minimum encounter time threshold: minute.

[0192] Shore-based management departments can uniformly issue thresholds through a shore-based platform, or authorize captains to make local adjustments using tablet software on board, but the adjustment scope is limited to a prescribed safety range (such as minimum). In the sea, (minutes), to prevent unlimited relaxation of standards.

[0193] (2) Core decision algorithm: For each target and its calculated Perform the following logical judgment:

[0194] (13)

[0195] Only when When true, the target It was marked as a "collision risk target".

[0196] 2. Alarm Response: Multi-sensor channels and tiered alerts

[0197] Once a target is identified as a collision risk, an integrated alarm response is immediately activated.

[0198] (1) Auditory alarm:

[0199] The collision avoidance panel at the bow triggers an alarm sound, such as a "beep beep" tone. To avoid continuous noise interference, the alarm sound will automatically stop after a few seconds and will not loop (unlike traditional continuous alarms). The driver can immediately mute the alarm by clicking the "Mute" button on the interface.

[0200] Call extension: By integrating the captain's cabin computer, alarm information can be pushed to the captain's cabin to realize the "call captain" function and ensure that critical alarms are not missed.

[0201] (2) Visual alarm:

[0202] Graphical interface highlighting: Risk targets are highlighted on the collision avoidance tablet software interface. The icon immediately changes from the default green or normal color to a yellow or red triangle, accompanied by intermittent flashing, to strongly attract the driver's visual attention. The color choice can be associated with the risk level (e.g., red for very low TCPA).

[0203] Dedicated Alarm Message Box: An alarm message box pops up or updates in a fixed area on the left or right side of the software interface. The box clearly lists key information about the risk target, such as the vessel name, MMSI, bearing, distance, DCPA, TCPA, etc.

[0204] (3) Maintaining and resetting the alarm status:

[0205] Continuous monitoring: Continuously recalculate DCPA / TCPA for risk targets. As long as the target still meets the alarm conditions, its visually highlighted state will remain.

[0206] Automatic Reset: When the system detects that the target does not meet the warning conditions, determines that the risk has been eliminated, automatically restores the target icon to its normal color, and clears the relevant alarm information box. The entire process requires no manual confirmation from the driver, reducing the operational burden.

[0207] Manual reset: The driver can also manually clear all current alarm statuses by clicking the "Reset" button on the interface.

[0208] 3. Information Reporting: Structured encapsulation and synchronization of early warning data

[0209] The data reporting process is initiated immediately upon alarm triggering, which is the key to achieving "ship-shore synchronization".

[0210] (1) Alarm event data packet generation: Generate a structured alarm event record containing the following fields:

[0211] Event identifier: unique ID, event type (collision warning), trigger timestamp.

[0212] Vessel information: MMSI, position, heading, speed.

[0213] Target vessel information: MMSI / target number, vessel name, position, course, speed.

[0214] Risk parameters: When an alarm is triggered .

[0215] Related data identifier: Marks the AIS data backtracking segment associated with this event.

[0216] (2) Related data backtracking and packaging: To support the shore-based platform in "alarm trajectory playback", when an alarm is triggered, the full amount of AIS data within a range of several nautical miles around the ship for a period of time is automatically snapshotted and packaged. This data provides shore-based analysts with a complete encounter situation background.

[0217] (3) Network push: The encapsulated alarm event data packet and the associated AIS data backtracking packet are immediately pushed to the ship-to-shore communication host via the ship's local area network, and then synchronized to the shore platform via satellite communication or other network links. This ensures that shore-based management personnel can see the alarm events on the ship in almost real time.

[0218] The output of this step is not only the audio-visual prompts in the cockpit, but also a digital "risk snapshot" containing complete spatiotemporal information. On the one hand, it directly assists the driver in making avoidance decisions, and on the other hand, it places the risk event under the monitoring of the shore-based management system, providing tamper-proof data for subsequent safety supervision, event analysis, and liability determination, thus realizing a closed loop from risk perception to management intervention.

[0219] The aforementioned automatic recording of close-range navigation events refers to the process of automatically recording an encounter event containing key data such as information of both vessels, closest distance, and time whenever another vessel enters within 1 nautical mile of the vessel, regardless of whether the alarm threshold is reached. This event is then simultaneously reported to the shore-based platform, providing objective data for post-navigation analysis and safety management.

[0220] The basic idea of ​​this step is:

[0221] This invention not only focuses on real-time, high-risk collision warnings but also creatively establishes a continuously operating, unobtrusive navigation "safety black box." Its core is to strip away the logic of risk assessment and focus solely on recording objective facts. Regardless of whether the encounter situation is dangerous, as long as a vessel physically enters a pre-defined, generally accepted close-range spatial range (1 nautical mile), a noteworthy navigational event is considered to have occurred. This parallel recording channel provides ship safety management with a comprehensive, quantitative navigation archive that surpasses real-time alarms. It is a valuable data source for assessing the effectiveness of crew lookout and avoidance maneuvers, analyzing navigation habits, and conducting post-accident tracing. Its implementation includes three stages: triggering, recording, and reporting.

[0222] 1. Event Triggering: Objective Determination Based on Spatial Distance

[0223] (1) Recording threshold setting: Set a fixed recording trigger radius. One nautical mile. This is an empirical value based on nautical practice, representing a clear, recordable close encounter between two ships.

[0224] (2) Trigger Logic: Unlike the "Collision Risk Warning Trigger" step, which relies on future predicted parameters (DCPA / TCPA), this step's trigger condition is based on real-time, measured relative distance. The actual distance between the vessel and each "valid target" (i.e., targets filtered through "open water conditions intelligently") is continuously calculated. Distance calculations use the Haversine formula for spherical distances, ensuring accuracy in open sea areas.

[0225] (14)

[0226] A "1-nautical-mile event" record is triggered when the following conditions are met:

[0227] (15)

[0228] 2. Event Logging: Structured Extraction and Snapshots of Key Information

[0229] When an event is triggered, a snapshot of the current navigation status is immediately captured, generating a structured "1-nautical-mile event record." This record contains all key information, including the ship's navigation information, the target vessel's navigation information, distance, and time.

[0230] 3. Recording and Reporting: The encapsulated "1 nautical mile event record" data packet and its associated AIS context data packet are pushed to the ship's communication host through the same path as the alarm information, and then synchronized to the shore platform.

[0231] This step does not directly generate bridge alarms, but the data it produces has extremely high management value. It objectively and continuously records every close encounter between the vessel and other vessels, realizing the extension of capabilities from "immediate risk management" to "full-process safety management".

[0232] The aforementioned ship-to-shore synchronization of early warning and recording information refers to the process by which the ship-side communication host automatically and in real time compresses and reports real-time collision risk early warning information, 1-nautical-mile encounter event records, and the system's own operation logs to the shore-side platform through the network, thereby realizing the integrated and closed-loop management of ship-to-shore safety information.

[0233] The basic idea behind this step is:

[0234] The collision avoidance and early warning system constructed in this invention is not an isolated shipboard tool, but a key, intelligent front-end sensing node in a digital safety management system. The core of this step is to build a reliable, efficient, and standardized data uplink channel, enabling all critical safety events and raw data generated on the ship to be aggregated in real time to the shore-based data center on the shore platform, transcending geographical limitations. This achieves a fundamental shift from "single-ship intelligence" to "fleet intelligence," from "post-event reporting" to "process monitoring," and from "local handling" to "remote support," providing a technical guarantee for implementing safety management systems. Its implementation encompasses three levels: data integration, compressed transmission, and shore-based reception and management.

[0235] 1. Data Integration: Standardized encapsulation of multi-source information flows

[0236] (1) Event data packets: The ship continuously generates three types of uplink data streams that need to be synchronized. These need to be integrated into standard data packets that conform to the shore-side platform access specifications: collision risk warning packet, 1 nautical mile event record packet, and operation log packet.

[0237] (2) Context data packet (AIS backtracking data). In order to ensure that the shore-based platform can perform complete trajectory playback analysis of alarms and recorded events, it is necessary to package and upload the full AIS data of the ship and other ships within a certain range of several nautical miles around it over a period of time.

[0238] 2. Compression and Transmission: Optimization Strategies for Adapting to the Maritime Communication Environment

[0239] Shipborne satellite communications have limited bandwidth, are costly, and can be unstable, making efficient and reliable data transmission crucial.

[0240] (1) Data compression:

[0241] Lossy / lossless compression: For event data packets and operation logs, lossless compression algorithms (such as GZIP) are used to ensure the absolute accuracy of critical information. For AIS backtracking data, with the consent of the shore platform, lossy compression or differential transmission strategies can be used, such as transmitting only the changes relative to the last report, or reducing the update frequency of non-critical targets to significantly reduce the amount of data.

[0242] (2) Intelligent transmission scheduling:

[0243] Priority Queue: Maintains a priority-based transmission queue. Collision risk warning packets have the highest priority and are attempted to be transmitted immediately upon occurrence. 1-nautical-mile log packets and operation log packets have medium priority. AIS backtracking packets have low priority and can be transmitted when the network is idle.

[0244] Resume transmission and caching: Considering the possibility of satellite link interruptions, all data packets to be sent are persistently stored locally. The sending module records the transmission status of each packet. In the event of a transmission failure, the data packet is kept in a queue and automatically retried after the network is restored, until the shore platform confirms successful reception. This ensures that data is "not lost".

[0245] 3. Shore-based reception and closed-loop management

[0246] The data is transmitted via the ship's local area network through a satellite gateway and eventually reaches the receiving server in the shore-based data center.

[0247] (1) Shore-based platform reception and decoding: The shore-based server receives data according to the agreed protocol, performs verification, decompression and decoding. The decoded data is stored in a distributed database and a real-time data processing engine.

[0248] (2) Real-time monitoring and visualization: The shore-based platform analyzes and displays the global situation map, event alarms and detailed data views in real time.

[0249] (3) Safety management closed loop: shore-based personnel can monitor whether the vessel has illegally shut down its system in non-open waters or has a large number of 1-nautical-mile records for a long time, thereby initiating remote inquiries or safety inspections; in case of emergency, shore-based management personnel can provide decision support to the ship based on more comprehensive information (such as weather and multiple vessel tracks).

[0250] By synchronizing early warning and recording information between ship and shore, this invention ultimately completes the construction of a complete ship collision avoidance safety management technology chain of "ship-side perception - intelligent judgment - automatic recording - shore-based collaboration".< / lf> < / cr> < / lf> < / cr>

Claims

1. A method for collision avoidance early warning of ships in open sea areas, characterized in that, Includes the following steps: S1: Multi-source navigation data acquisition and analysis: Through the signal conversion server, the ship's AIS, ARPA radar target, GPS and gyrocompass data are accessed, the ship's data is acquired, the acquired data is converted into network signals, and the network signals are output as messages through Ethernet. The various messages are decoded, analyzed and fused. S2: Intelligent Filtering for Open Water Conditions: Automatically filters the data obtained from S1 according to preset electronic fence rules, dynamic target and scene rules, filters out invalid alarm signals that occur in non-open water areas, and removes interference data from non-ship targets. S3: Real-time calculation of collision risk parameters: Based on the ship's current course, speed and position, calculate in real time the minimum encounter distance and minimum encounter time between the ship and all other ship targets within the effective range after filtering and screening. S4: Collision Risk Warning Trigger: When the minimum encounter distance and minimum encounter time calculated by S3 are both lower than the preset alarm threshold, the system determines that there is a collision risk, immediately triggers an alarm, and pushes the warning information to the shore platform; S5: Automatic recording of close-range navigation events: Regardless of whether the alarm threshold described in S4 is reached, as long as another vessel enters the designated range of this vessel, an encounter event with key data will be automatically recorded and simultaneously reported to the shore platform. S6: Ship-shore synchronization of early warning and recording information: The ship automatically and in real time compresses and reports real-time collision risk early warning information and encounter event records within a specified range to the shore platform via the network.

2. The method for collision avoidance and early warning of ships in open sea areas according to claim 1, characterized in that, Step S1 aggregates the ship's AIS, ARPA radar target, GPS, and gyrocompass data in real time and performs preliminary structured processing. This is implemented through a hardware layer, a parsing layer, and a fusion layer. The hardware layer utilizes the heterogeneous signal access and networking capabilities of the NS304I signal conversion server. This server has multiple serial communication ports, allowing the ship to access the four types of data through different ports and convert them in real time into standard TCP / IP network data packets. The converted data is then output as messages via a network cable and connected to the ship's local area network. The parsing layer decodes the messages and extracts key information based on the NMEA 0183 standard. The fusion layer performs spatiotemporal alignment and structured encapsulation of the multi-source data based on timestamps.

3. The method for collision avoidance and early warning of ships in open sea areas according to claim 2, characterized in that, The network data stream output by the NS304I signal conversion server is an ASCII text string conforming to the NMEA 0183 format. Each statement begins with "$" or "!" and ends with "". <cr> <lf> "End. The processing steps for each statement are as follows:"< / lf> < / cr> Step 1: Format verification and filtering: Perform statement format integrity checks, verification and validation, and discard invalid or damaged messages; then classify and filter messages according to statement identifiers, and only process message types related to ship collision avoidance warnings; Step 2: Deep Decoding of AIS Messages: For AIS !AIVDM / !AIVDO statements, the payload is decoded according to the ITU-R M.1371 protocol standard as follows: Step 2.1: 6-bit ASCII to binary: Convert each character in the payload to 6 bits of binary data and concatenate them into a complete binary data stream; Step 2.2: Bit-by-bit parsing: Based on the AIS message type, extract the required fields from the binary data stream according to the bit offsets and lengths defined in the protocol. a. User ID / MMSI: 8-37 digits, converted to a decimal integer; b. Longitude: 61-88, 1 / 10000, converted to decimal system using the following formula: (1) c. Latitude: 89-115, 1 / 10000, conversion formula is: (2) d. Ground speed: 50-59 knots, equivalent to 1 / 10 of a knot. The conversion formula is: (3) e. Heading relative to the ground: Position 116-127, 1 / 10 degree, conversion formula is: (4) In formulas (1)-(4): Lon deg Longitude, decimal system; Lon raw Represents the raw longitude value, the unconverted numerical value extracted from the data in units of 1 / 10000th of a degree; Lat deg Indicates latitude, decimal system; Lat raw Represents the raw latitude value, an unconverted numerical value extracted from the data in units of 1 / 10000; SOG knots Expresses speed over ground, unit: knots; SOG raw Represents the raw ground speed value, the unconverted value extracted from the data in 1 / 10 knots; COG knots Indicates heading relative to the ground, unit: degrees; COG raw This represents the original heading value relative to the ground, an unconverted value extracted from the data in units of 1 / 10 degrees.

4. The method for collision avoidance and early warning of ships in open sea areas according to claim 2, characterized in that, The specific process of spatiotemporal alignment and structured encapsulation is as follows: Step 1: Time base unification: The UTC timestamp in the GPS message is used as the main time base. All parsed data points are accompanied by their original timestamp. If there is no original timestamp, it is marked as the time of receipt. Step 2: Ship State Fusion: Associate the ground heading (COG), ground speed (SOG), and position (Lat / Lon) from GPS with the actual ship heading (HDG) from the gyrocompass; pair the GPS and gyrocompass (GYRO) data within the same time window to form a complete ship state structure, OwnShipState(t): (5) Step 3: Target Ship Data Structuring: The parsed data from AIS and ARPA are encapsulated into a unified target ship structure TargetState(i, t) according to their unique identifiers and location information, respectively. For the same physical target tracked by both AIS and ARPA, the system can perform data association based on location correlation, prioritizing the use of the more informative AIS data, and using ARPA data as a backup or verification. The unique identifier for AIS is MMSI, and the unique identifier for ARPA is the target number. Step 4: Data Buffer and Output: The processed ship status and target ship list are temporarily stored in a thread-safe circular buffer.

5. The method for collision avoidance and early warning of ships in open sea areas based on any one of claims 2-4, characterized in that, Step S2 designs a three-level progressive intelligent filtering mechanism, including: first-level filtering, second-level filtering, and third-level filtering; the first-level filtering is static geographic area filtering; the second-level filtering includes filtering based on target dynamic attributes and scene filtering based on traffic density; the third-level filtering is manual control filtering based on captain's decision; the first-level filtering excludes non-open areas; the filtering based on target dynamic attributes specifically includes: a. Target filtering for abnormal speeds: Any target whose reported ground speed exceeds a preset physical limit threshold is directly filtered out, i.e.: (6) This rule is used to filter out non-merchant vessel collision risk sources such as high-speed small boats and "flying points" caused by data errors; b. Filtering known non-ship targets: For AIS targets, if their MMSI or ship type code belongs to known special purpose identifiers such as fishing net buoys, search and rescue beacons, etc., they are directly filtered; for ARPA targets, although the type cannot be directly identified, it can be indirectly determined by associating them with AIS targets. The scene filtering based on traffic density counts the number of ships within two concentric circles centered on the current ship: Let... This represents the total number of ships within a 3-nautical-mile radius. Given the total number of vessels within a 6-nautical-mile radius, the rules for determining densely populated areas are as follows: (7) if Greater than 5 and If the value is greater than 20, it is marked as dense and filtered directly.

6. The method for collision avoidance and early warning of ships in open sea areas according to claim 5, characterized in that, Step S3 is based on the following assumptions: within the short-term prediction window, both the ship and the target ship maintain their current course and speed. By establishing a mathematical model of the relative motion of the two ships, the extreme points of their future relative positions are solved, thereby obtaining the minimum encounter distance DCPA and the minimum encounter time TCPA. The specific process is as follows: Step 1: Mathematical Model Establishment and Coordinate Transformation a. Data Input: For each valid target ship that needs to be calculated... Obtain the following real-time data: Ship status: position ,course speed Target ship Status: Position ,course speed ; b. Projection transformation from latitude and longitude to plane coordinates: Since DCPA / TCPA calculations involve distance and direction, the Earth's sphere is usually approximated as a plane in local sea areas. The latitude and longitude of all ships are transformed into a plane rectangular coordinate system through map projection in order to perform vector calculations; Step 2: Relative Motion Vector Decomposition and Calculation Based on the assumption of uniform linear motion, the positions of the ship and the target ship after time t can be predicted as follows: Vessel's position: Target ship location: in, , and , These are the components of the velocity vectors of the ship and the target ship in the planar coordinate system: (8) sin corresponds to the eastward component, cos corresponds to the northward component, depending on the coordinate axis definition; C is the angle from true north in a clockwise direction. The relative position vectors of the two ships for: (9) Let the initial relative position be The relative velocity vector is ,but: (10) Step 3: Solving for minimum meeting distance and minimum meeting time Minimum meeting distance refers to the shortest relative distance that two ships will reach if they continue sailing at their current state of motion; this is a vector problem. The problem of finding the minimum value of the modulus; a. Calculate the relative motion parameters: Relative speed: ; Initial distance: ; b. Solving for the minimum encounter time: Based on vector analysis, when the relative position vectors... With relative velocity vector When the two ships are perpendicular, the distance between them is the shortest; from this, the time to reach the minimum meeting point can be derived. : (11) like This indicates that the two ships have not yet reached their closest point and will meet again in the future. Arrive in hours; like This indicates that the two ships have passed their closest point and the distance between them is increasing; like This indicates that the current point is the closest point; c. Solve for the minimum encounter distance: Substituting into the relative position equation, the minimum meeting distance can be obtained. : (12) Unit conversion: Calculated If the unit is meters, it needs to be divided by 1852 to convert to nautical miles; If the unit is hours, it needs to be multiplied by 60 to convert it to minutes.

7. The method for collision avoidance and early warning of ships in open sea areas according to claim 6, characterized in that, The specified range for this vessel under S5 is 1 nautical mile.

8. A system for ship collision avoidance and early warning in open sea areas that implements the method of any one of claims 1-7, characterized in that, The main hardware used in the system includes an AIS signal, marine ARPA radar, GPS equipment, compass, serial port server, switch, collision avoidance tablet computer, captain's cabin computer, shipboard communication host, and shore-based platform. The AIS signal, marine ARPA radar, GPS equipment, and compass are located at the ship's end. The serial port server connects to the AIS signal, marine ARPA radar, GPS equipment, and electric compass via the ship's bridge. The collision avoidance tablet computer, captain's cabin computer, and shipboard communication host read data from the serial port server through the switch. The shipboard communication host connects to the shore-based platform and transmits information from the ship to the shore-based platform.

9. The system for collision avoidance and early warning of ships in open sea areas according to claim 8, characterized in that, The serial port server uses an NS304I signal conversion server, which has multiple serial communication ports to connect to four data sources: PORT1: Connects to the A and B signal lines output by the AIS signal controller; the AIS data stream output by the AIS signal controller contains dynamic and static information of the ship and surrounding vessels, conforming to the IEC 61162-1 / 2 standard; PORT2: Connects to the TTM message output by the marine ARPA radar; the TTM message provides distance, bearing, heading, and speed information for radar-tracked targets, effectively supplementing AIS data, especially for ships with AIS not activated or malfunctioning; PORT3: Connects to the Global Positioning System (GGA) positioning data and Recommended Minimum Specific Navigation (RMC) statements output by the GPS receiver, providing the ship with high-precision longitude, latitude, ground speed, ground heading, and UTC timestamp; PORT4: Connects to the heading-true north (HDT) or heading (HDG) messages output by the gyrocompass, providing the ship's true heading, used to correct the GPS heading. The deviation of COG is caused by the airflow pressure difference.

10. The method for collision avoidance and early warning of ships in open sea areas according to claim 8, characterized in that, The shipboard communication host automatically and in real time compresses and reports the real-time collision risk warning information, 1-nautical-mile encounter event records, and the system's own operation logs to the shore platform via the network.

Images