Intelligent port logistics customs clearance integrated service method and system

Abstract

The application provides a smart port logistics customs clearance integrated service method and system, relates to the technical field of intelligent control, and the method comprises the following steps: in response to a declaration operation instruction, updating a state identifier to a declared state identifier; based on the declared state identifier, correcting a pilot time window through a berthing and unberthing plan adjustment value, generating a pilot operation plan entity and writing the pilot operation plan entity into a tugboat configuration to-be-processed queue; polling the tugboat configuration to-be-processed queue, responding to a tugboat configuration completion instruction, adapting a tugboat power parameter and updating a state; generating a ship entry and exit structured data packet based on a pilot plan data entity and the pilot operation plan entity, submitting the ship entry and exit structured data packet to a port supervision system to obtain a joint state code; matching the joint state code with a preset threshold value, triggering a ship state machine to switch to a clearance final state or a reverse clearance final state. The application reduces manual intervention in the approval link and shortens the period from the submission of a pilot application to the approval of the pilot application.

Description

Technical Field

[0001] This invention relates to the field of intelligent control technology, and in particular to a smart port logistics and customs clearance integrated service method and system. Background Technology

[0002] In practice, when the logistics operation system generates berthing and departure plan adjustment values ​​through dynamic assessment range adjustment and updates the status identifier to the declared status, the port supervision system can obtain relevant dynamic data. However, there are some shortcomings in the in-depth analysis and intelligent application of the data. Some regulatory review processes rely on manual data sorting and judgment, resulting in a certain gap between the efficiency of regulatory response and the dynamic rhythm of logistics operations. For example, after a vessel completes berthing according to the pilotage operation plan, the logistics operation system has triggered the polling update of the tugboat configuration pending queue. Although the port supervision system can receive the structured data packets of vessel entry and exit, its intelligent matching of joint status codes and preset thresholds, and automatic early warning of abnormal data are not yet fully mature, leaving room for optimization in the intelligent connection of vessel supervision and verification in port.

[0003] The lack of such intelligent collaboration affects the efficiency of logistics flow. For example, when a ship completes unloading operations and the logistics operation system enters the final state of customs clearance preparation, although the port supervision system can complete the final verification of cargo information, the verification cycle has room for further compression due to the lack of intelligent verification throughout the entire process. Occasionally, containers are briefly detained in the terminal storage area, which restricts the efficient use of port storage resources. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a smart port logistics and customs clearance integrated service method and system, which reduces manual intervention in the approval process and shortens the cycle from submission to approval of pilotage application.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] A smart port logistics and customs clearance integrated service method, the method comprising:

[0007] Receive pilotage application input data and generate a pilotage application data entity carrying an undeclared status identifier;

[0008] Parse the status identifier of the pilotage application data entity. When a change in the status identifier to "approved" is detected, generate the pilotage plan data entity.

[0009] Extract the ship tonnage, berth coordinates and time window parameters of the pilotage plan data entity, and dynamically determine three dynamic reference points based on the real-time ship position, port tidal data and waterway congestion index, and construct a dynamic evaluation range including the dynamic reference points.

[0010] Calculate the morphological characteristic values ​​of the dynamic assessment range, generate berthing and departure plan adjustment values, and construct structured berthing and departure plan data by combining parameters; respond to the declaration operation command and update the status identifier to the declared status identifier;

[0011] Based on the declared status identifier, the pilotage time window is corrected by adjusting the berthing and departure plan values, a pilotage operation plan entity is generated and written into the tugboat configuration pending queue;

[0012] Poll the tugboat configuration pending queue, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a vessel entry / exit structured data packet based on the pilotage plan data entity and the pilotage operation plan entity, submit it to the port supervision system to obtain the joint status code; match the joint status code with the preset threshold to trigger the vessel state machine to switch to the customs clearance final state or the anti-customs clearance final state.

[0013] The intelligent port logistics and customs clearance integrated service system includes:

[0014] The acquisition module is used to receive the input data of the ship pilotage application, generate a pilotage application data entity carrying an undeclared status identifier, parse the status identifier of the pilotage application data entity, and generate a pilotage plan data entity when the status identifier is detected to have been approved.

[0015] The extraction module is used to extract the ship tonnage, berth coordinates and time window parameters of the pilotage plan data entity. Based on the real-time position of the ship, port tidal data and channel congestion index, three dynamic reference points are dynamically determined to construct a dynamic evaluation range including the dynamic reference points.

[0016] The calculation module is used to calculate the morphological feature values ​​of the dynamic assessment range, generate berthing and departure plan adjustment values, and construct structured berthing and departure plan data by combining the extracted parameters; in response to the declaration operation command, the status identifier is updated to the declared status identifier.

[0017] The generation module is used to generate a pilotage operation plan entity and write it into the tugboat configuration pending queue, based on the declared status identifier and the adjusted berthing and departure plan values ​​to correct the pilotage time window.

[0018] The control module is used to poll the tugboat configuration queue, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a structured data packet for ship entry and exit based on the pilotage plan data entity and the pilotage operation plan entity, submit it to the port supervision system to obtain the joint status code; match the joint status code with the preset threshold, and trigger the ship state machine to switch to the customs clearance final state or the anti-customs clearance final state.

[0019] The above-described solution of the present invention has at least the following beneficial effects:

[0020] This invention generates pilotage application data entities carrying status identifiers, enabling visualized tracking and automated flow of pilotage application status. When the status identifier changes to "approved," pilotage plan generation is automatically triggered, avoiding the lag of manual entry of unstructured data in the traditional model, reducing manual intervention in the approval process, shortening the cycle from submission to approval of pilotage applications, and ensuring rapid adjustment of pilotage plans in case of emergencies, thereby reducing the risk of ships being stranded in port.

[0021] By extracting core parameters such as ship tonnage and berth coordinates, and combining real-time ship position, port tidal data, and channel congestion index, reference points are dynamically determined and an assessment range is constructed. Based on morphological characteristic values, adjustment values ​​for berthing and departure plans are generated. This process breaks through the limitations of traditional reliance on historical data and experience-based judgment, enabling berthing and departure plans to adapt to dynamic port conditions in real time. It effectively avoids berth adjustment delays and resource waste caused by tidal changes, channel congestion, and other factors, thereby improving the scientific nature and execution efficiency of berthing and departure plans.

[0022] This invention achieves deep data interoperability between the logistics operation system and the port supervision system by standardizing the construction of structured berthing and departure plan data and pilotage operation plan entities, as well as automatically generating and submitting structured data packets for ship entry and exit. With the help of an intelligent matching mechanism of joint status codes and preset thresholds, it triggers the ship's state machine to automatically switch to the customs clearance final state or the anti-customs clearance final state, replacing the traditional manual verification and status transmission mode and solving the problem of regulatory response lag. Through the polling mechanism of the tugboat configuration waiting queue and the optimization of power parameter adaptation, it ensures the accurate matching of tugboat resources and ship demand, reducing the situation of tugboat idleness or insufficient capacity. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the integrated smart port logistics and customs clearance service method provided by an embodiment of the present invention.

[0024] Figure 2 This is a schematic diagram of the integrated smart port logistics and customs clearance service system provided in an embodiment of the present invention. Detailed Implementation

[0025] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0026] like Figure 1 As shown, an embodiment of the present invention proposes a smart port logistics and customs clearance integrated service method, the method comprising the following steps:

[0027] Step 1: Receive the input data for the ship's pilotage application and generate a pilotage application data entity carrying an undeclared status identifier;

[0028] Step 2: Parse the status identifier of the pilotage application data entity. When the status identifier is detected to have changed to "approved", generate the pilotage plan data entity.

[0029] Step 3: Extract the ship tonnage, berth coordinates and time window parameters of the pilotage plan data entity, and dynamically determine three dynamic reference points based on the real-time ship position, port tidal data and waterway congestion index, and construct a dynamic evaluation range including the dynamic reference points.

[0030] Step 4: Calculate the morphological feature values ​​of the dynamic evaluation range, generate berthing and departure plan adjustment values, and construct structured berthing and departure plan data by combining the parameters extracted in Step 3; respond to the declaration operation command and update the status identifier to the declared status identifier.

[0031] Step 5: Based on the declared status identifier, correct the pilotage time window using the berthing and departure plan adjustment value, generate a pilotage operation plan entity, and write it into the tugboat configuration pending queue;

[0032] Step 6: Poll the tugboat configuration pending queue generated in Step 5, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a ship entry / exit structured data packet based on the pilotage plan data entity and the pilotage operation plan entity, and submit it to the port supervision system to obtain a joint status code; match the joint status code with a preset threshold to trigger the ship state machine to switch to the customs clearance final state or the anti-customs clearance final state.

[0033] In this embodiment of the invention, dynamic tracking of application, approval, and plan generation processes using status identifiers enables automated workflow from pilotage application to operational execution, reducing manual intervention, minimizing process redundancy, and improving customs clearance efficiency. By combining real-time data such as vessel location, port tides, and channel congestion, dynamic reference points and berthing / departure adjustment values ​​are generated, allowing berthing / departure plans to flexibly adapt to environmental changes, improving the scientific validity and feasibility of the plans, and reducing the risk of delays due to environmental factors. Furthermore, structured pilotage plans, operational plans, and inbound / outbound data packets are constructed to achieve data standardization. The system provides a unified data foundation for all aspects of port operations (piloting, tugboat configuration, supervision, etc.), improving cross-link collaboration efficiency. It integrates key aspects such as pilotage planning, tugboat configuration, and supervision system integration to form a closed-loop management system of "piloting-operation-supervision," achieving integrated services across the entire logistics and customs clearance chain, breaking down barriers between links, and shortening vessel clearance time. Through tugboat configuration polling, joint status code verification, and vessel status machine final state triggering mechanisms, it enables visualized tracking and closed-loop control of the entire customs clearance process, ensuring compliance at each stage and improving the standardization and reliability of port management.

[0034] In a preferred embodiment of the present invention, step 1, receiving ship pilotage application input data and generating a pilotage application data entity carrying an undeclared status identifier, includes:

[0035] Step 100: Receive the encrypted pilotage request message sent by the ship agency system through a preset electronic data exchange interface, and perform message decryption and format verification operations; specifically, this may include:

[0036] The real-time monitoring process of the electronic data interchange interface is initiated. This process scans the interface data buffer every 0.5 seconds. When an encrypted pilotage request message sent by the ship agency system is detected, the data reception mechanism is immediately triggered. First, a temporary encrypted transmission channel is established via the TCP / IP protocol, and a three-way handshake is used to confirm the connection validity. Then, the complete encrypted message is received in the order of data packet fragmentation. A CRC check is performed after every 1KB of data is received to ensure that no data is lost or tampered with during transmission, until all fragments are assembled into a complete encrypted data packet. After reception, the encrypted message is first parsed. From the header information of the document, two key data units are extracted: one is an encrypted point set consisting of 200-500 two-dimensional coordinate points (each point contains floating-point values ​​for the x and y axes), and the other is the baseline boundary parameters used for convex hull calculation (containing the minimum and maximum x-axis values, minimum and maximum y-axis values). All coordinate points are traversed, and the x-value of each point is compared with the x-axis range of the baseline boundary, and the y-value is compared with the y-axis range of the baseline boundary. All outlier points that exceed the boundary (such as points where x is less than the minimum x-axis value or greater than the maximum x-axis value) are removed, and the remaining points form the valid point set to be processed.

[0037] First, select the point with the smallest y-axis coordinate from the set of valid points as the initial pole. If there are multiple points with the same minimum y-axis coordinate, select the point with the smallest x-axis coordinate. Using this pole as the origin, calculate the inclination angle (the angle between the line connecting all other points and the pole and the positive direction of the horizontal axis), and sort these points in ascending order of angle to form an ordered point sequence. Then, a point-by-point verification method is used to construct the convex hull: points are selected sequentially from the sorted point list, forming triangles with the last two vertices of the current convex hull. The cross product of vectors is used to determine whether the new point is located outside the convex hull (the cross product result is regular and indicates it is outside). If it is, the point is added to the convex hull vertex sequence; otherwise, the last vertex of the convex hull is removed and the verification is repeated until all points are processed, ultimately forming a convex hull polygon containing 10-30 vertices. The coordinates of all convex hull vertices are recorded in a clockwise direction. The Euclidean distance between adjacent vertices is calculated (keeping two decimal places). The total number of vertices is counted, and the perimeter (sum of distances between all adjacent vertices) and area of ​​the convex hull are calculated (using the step-by-step calculation method of the Shoelace formula, decomposing the polygon into multiple triangles and summing them). These parameters are arranged in the order of "total number of vertices - perimeter - area - coordinates of each vertex - distance of each side" to form a set of feature value sequences.

[0038] Simultaneously, the decryption key corresponding to the ship agency system is obtained. This key contains a set of feature mapping tables: the total number of vertices corresponds to the number of data blocks, the perimeter value corresponds to the character set index, the area value corresponds to the check coefficient, the integer part of the vertex coordinates corresponds to the ASCII base value, the decimal part corresponds to the offset, and the edge distance corresponds to the data block length. The value corresponding to the total number of vertices is used as the number of data block segments. The integer part of each vertex coordinate is matched with the character set index to obtain the base character, and the offset converted from the decimal part (e.g., 0.32 is converted to 32) is added to obtain the actual character. The data block is then truncated according to the length corresponding to the edge distance. Consecutive characters form data blocks, and parity checks are performed on each data block using a check coefficient corresponding to its area (odd coefficient checks odd bits, even coefficient checks even bits). After all data blocks have been converted, they are concatenated in the original encryption order to form a complete byte stream. The length of the byte stream is compared with the length of the original data recorded in the encrypted message header. If they match, the byte stream is converted into a plaintext message encoded in UTF-8. If they do not match, decryption fails, and the convex hull construction and feature conversion process is re-executed (up to 3 retries). If it still fails, the error message "Decryption failed: data feature mismatch" is returned to the ship agency system.

[0039] After decrypting the plaintext message, the system calls a preset message template (containing 32 required fields and 8 optional fields). First, it checks if the total number of message fields is between 40 and 48 (required fields + 0-8 optional fields). Then, it verifies the order of each field according to the template (e.g., the 3rd field must be the "ship call sign", and the 7th must be the "estimated arrival date"). Next, it verifies the data type of each field (e.g., the date field must conform to the "YYYY-MM-DD" format, and the tonnage field must be a positive integer). Finally, it checks the field length (e.g., the ship identification number is fixed at 12 characters, and the application timestamp is fixed at 19 characters). Once all checks pass, it is marked as "verification passed" and proceeds to the next step. If a field is out of order, it returns "Format error: Field X should be YYYY, but is actually XXX"; if the data type is incorrect, it returns "Format error: Field XXX should be an integer, but is actually a string," ensuring the ship agency system can determine the correction direction.

[0040] In this embodiment, during the data receiving stage, high-frequency scanning and fragment verification ensure the integrity and accuracy of encrypted message transmission, reducing the risk of data loss or tampering; preprocessing removes outliers, allowing subsequent convex hull construction to be based on valid data, improving the accuracy of feature extraction; the ordered process of convex hull construction and feature parameter extraction, combined with the mapping and conversion of a dedicated decryption key, achieve secure decryption of encrypted data, enhancing the confidentiality of data transmission; the multiple retry mechanism reduces the impact of random errors, and error information identification helps to quickly correct them.

[0041] Step 101: Extract predefined key fields from the verified message, including the ship identification number, ship type classification code, and application timestamp. Specifically, this may include: for the verified plaintext message, based on the predefined key field list, locating the field corresponding to the ship identification number in the message by matching field identifiers, reading and recording the specific content of that field; then, in the same way, locating and extracting the content of the ship type classification code field and the application timestamp field; after extraction, performing preliminary validity verification on the extracted three fields, such as checking whether the character composition of the ship identification number conforms to the encoding rules, whether the ship type classification code is within the preset code library range, and whether the application timestamp format is a standard time format. After confirming that there are no errors, temporarily storing them in the temporary data cache area.

[0042] Step 102: Based on the ship identification number, initiate a real-time query request to the ship basic database to obtain the associated ship basic file. Parse the ship's main dimensional parameters, design draft, and approved deadweight tonnage in the file to generate a structured additional parameter set. Specifically, this may include: using the ship identification number extracted in step 101 as the query keyword to generate a request command conforming to the ship basic database query protocol; sending the real-time query request to the ship basic database through the database connection module and waiting for the database to return a response; upon receiving the associated ship basic file returned by the database, separating the sub-data blocks related to the ship's main dimensional parameters according to the file data's organizational structure, and parsing out specific parameter values ​​such as ship length, beam, and depth; then locating the record item corresponding to the design draft and reading its value; and then finding the field for approved deadweight tonnage and extracting the corresponding data. Afterwards, classify and organize these parsed parameters according to a preset data structure to form a structured additional parameter set containing parameter names, parameter values, and data units, and store it in the system's intermediate data processing area.

[0043] Step 103 involves performing field-level mapping and concatenation between the predefined key fields and the structured additional parameter set to form a complete ship attribute dataset. Specifically, this may include: first, performing a field compatibility check on the predefined key fields obtained in step 101 and the structured additional parameter set generated in step 102 to confirm that there are no conflicts in field names or data format incompatibility; then, according to preset field mapping rules, associating and matching the ship identification number, ship type classification code, and application timestamp in the predefined key fields with the ship's principal dimension parameters, design draft, and approved deadweight tonnage in the structured additional parameter set; after the matching is completed, performing a data concatenation operation to integrate all fields into a unified data framework, forming a complete ship attribute dataset containing multi-dimensional data such as ship identity information, type information, application time information, and physical parameter information; and simultaneously performing an integrity check on the concatenated dataset to ensure that all necessary fields are included and that no data is missing.

[0044] Step 104: Assign a globally unique application number to the complete ship attribute dataset, inject an undeclared status identifier, and construct a pilotage application data entity with ship static attributes, dynamic application attributes, and status identifiers. Specifically, this may include: generating a globally unique pilotage application number based on preset coding rules, combined with the current system time, partial feature codes of the ship identification number, and a random check code. This number is non-repeatable within the system. Then, call the status identifier injection program to add the coding information corresponding to the "undeclared" status identifier to the status field of the complete ship attribute dataset. Next, perform structured processing on the dataset, classifying and organizing the data according to three categories: ship static attributes (such as principal dimensional parameters, design draft, etc.), dynamic application attributes (such as application timestamp, application number, etc.), and status identifiers. Construct a pilotage application data entity containing data category labels, specific field content, and relationships, and store this entity in the system's pilotage application database, while generating a log record of successful entity storage.

[0045] In this embodiment of the invention, during the data reception and decryption process, high-frequency scanning, fragmentation verification, and encryption / decryption mechanisms based on convex hull algorithms ensure the integrity, accuracy, and confidentiality of pilotage application messages from the source of transmission. Anomaly removal and multiple retry mechanisms further improve decryption accuracy. Key field extraction and validity verification ensure the accuracy and compliance of core data. By associating the ship identification number with the basic file and generating a structured set of additional parameters, the dimensions of ship attribute data are enriched, making the data more comprehensive and complete. Field-level mapping and integrity verification eliminate data conflicts, achieving the organic integration of multi-source data and forming a complete dataset covering multi-dimensional information. Assigning a globally unique application number and injecting a status identifier enables unique data identification and full lifecycle tracking. Structured classification storage improves the standardization of data management and query efficiency. Overall, this step, through meticulous processing throughout the entire process, ensures the security, accuracy, completeness, and standardization of pilotage application data.

[0046] In a preferred embodiment of the present invention, step 2, parsing the status identifier of the pilotage application data entity, and generating a pilotage plan data entity when a change in the status identifier to approval is detected, includes:

[0047] Step 201 involves real-time capture of approval result events sent by the port approval system via asynchronous message notifications. Specifically, this includes: real-time monitoring of the asynchronous message stream of the port approval system through a pre-defined message queue interface (such as RabbitMQ or Kafka), scanning the message queue buffer every 0.1 seconds. When a new message enters the queue, the event type identifier in the message header is first parsed to determine if it is an "approval result event" (by matching the event type field value "ApprovalResultEvent"). After confirming the event type, the digital signature and sender certificate in the message body are extracted. The message integrity is verified using the system's built-in encryption verification module (verifying whether the signature matches the message content). If the verification passes, the approval result event is received; if the verification fails (e.g., signature mismatch or message tampering), it is marked as an invalid event and an exception log is recorded, while the message is ignored.

[0048] Step 202: When the approval result event carries an approval approval flag, extract the ship's main dimensional parameters, the geographical coordinates of the applied berth, and the planned berthing and departure time interval from the persistently stored pilotage application data entity. Specifically, when the "Approval Status" field value in the message body of the approval result event received in step 201 is "Approved" (approval approval flag), the system extracts the associated "Original Application Number" (consistent with the globally unique application number generated in step 104) from the event data; using this application number as the search keyword, the system accesses the persistently stored pilotage application data entity table through the database query interface to locate the corresponding record. Three types of core data are precisely extracted from the record by field name: First, the ship's main dimensional parameters, including the specific values ​​and units of the ship's length, beam, and depth (e.g., "length: 180 meters, beam: 30 meters"); second, the geographical coordinates of the applied berth, including latitude and longitude values ​​(e.g., "38.5°N, 121.2°E") and the berth number; and third, the planned berthing and departure time intervals, including four timestamps: planned berthing start time, berthing end time, planned departure start time, and departure end time (formatted as "YYYY-MM-DDHH:MM:SS"). After extraction, the data is checked for completeness to ensure there are no missing fields or null values. Once all parameters are confirmed to be complete, the data is temporarily stored in the memory data area.

[0049] Step 203: Based on the berth adaptation algorithm in the port scheduling rule base, and the ship's main dimensional parameters and minimum safe distance threshold, generate the precise coordinates and azimuth of the adapted berth. Specifically, this includes: first, loading the preset "berth adaptation basic rules" in the rule base, including core conditions such as "ship length ≤ available berth length × 0.9", "ship width ≤ maximum berth width", and "ship depth ≤ maximum berth depth limit"; comparing and filtering the ship's main dimensional parameters (ship length, ship width, and depth) extracted in step 202 with the basic attributes of all available berths recorded in the rule base (excluding berths that are occupied or under maintenance), and initially selecting a candidate berth list that meets the basic conditions.

[0050] Next, based on the "Minimum Safe Spacing Threshold Table" in the rule base (which includes berth spacing requirements for different ship types, such as a minimum spacing of 50 meters for large bulk carriers), the actual spacing between candidate berths and adjacent berthed vessels is calculated. Berths with spacing less than the threshold are eliminated, and the final suitable berths are retained. A reference coordinate point (berth center latitude and longitude) is extracted from the attribute data of the final suitable berth, and the precise berthing coordinates are calculated in conjunction with the ship's principal dimension parameters: using the reference coordinates as the origin, the longitudinal offset is adjusted according to the ship's length (e.g., a 180-meter-long ship needs to be offset 90 meters from the reference point towards the channel to ensure centering), and the lateral offset is adjusted according to the ship's beam (e.g., a 30-meter-wide ship is offset 15 meters inward towards the berth), resulting in precise berthing coordinates (accurate to 6 decimal places). Simultaneously, referring to the port channel orientation (e.g., if the channel runs east-west), the long side of the berth is aligned with the channel axis to generate an azimuth angle (e.g., if the channel runs east-west, the azimuth angle is 90°, indicating that the ship's longitudinal direction is consistent with the east-west direction).

[0051] Step 204: Synchronously query the tide forecast service interface to obtain the tide height change sequence based on the planned berthing and departure time interval. Calculate the tide level correction amount by combining this with the ship's design draft. Specifically, this includes: calling the port tide forecast service interface via HTTPS protocol, filling in the "planned berthing and departure time interval" (start and end times) extracted in step 202 and the geocode of the port to which the requested berth belongs (e.g., port code "CNQHD") in the request parameters, and sending a tide data query request. The interface returns tide height data (unit: meters) every 10 minutes within this time interval, forming a tide height change sequence (e.g., "2024-05-15 08:00:00 tide level 3.2 meters; 2024-05-15 08:10:00 tide level 3.1 meters…").

[0052] Extract the vessel's design draft (e.g., "12.5 meters") from the pilotage application data entity, and calculate the tide level correction based on the tide level change sequence: During the planned berthing period, find the lowest tide level (e.g., 2.8 meters), and calculate the difference between this tide level and the vessel's design draft (12.5 meters - 2.8 meters = 9.7 meters). If the difference is greater than the port berth reference depth (e.g., 10 meters), the tide level correction is 0. If the difference is less than the reference depth (e.g., 9.7 meters > 9.5 meters), calculate the required tide rise time (e.g., if the tide rises 0.2 meters every 30 minutes, it takes 30 minutes to reach 3.0 meters, resulting in a correction of 0.2 meters). Ensure that the actual water depth (reference depth + tide level) is greater than or equal to the design draft when the vessel berths. Finally, record the calculated tide level correction (including the correction value and correction time point) as structured data.

[0053] Step 205: Integrate the precise coordinates, azimuth, tide correction, and planned berthing / departure time intervals to construct a pilotage plan data entity containing vessel tonnage, berth coordinates, and time window parameters. Inject the original application number into the pending spatial evaluation status identifier. Specifically, this includes: integrating the adapted berth precise coordinates (latitude and longitude) and azimuth (angle value) generated in Step 203, the tide correction (correction value and time point) obtained in Step 204, and the planned berthing / departure time intervals (four timestamps) extracted in Step 202 at the field level; simultaneously, extract the vessel tonnage parameter (approved deadweight tonnage) from the pilotage application data entity and supplement it into the integrated data, forming a core parameter set containing "vehicle tonnage, berth precise coordinates, azimuth, tide correction, berthing time window, and departure time window".

[0054] Next, the parameter set is associated with the original application number generated in step 104 (an "Associated Application Number" field is added to the data entity and the original number is filled in), and the status identifier management module is called to inject the "Pending Spatial Evaluation" status identifier (encoded as "Status:PendingSpatialEvaluation") into the status field of the data entity; finally, the complete pilotage plan data entity is constructed according to the preset data structure template (including the data category label "Pilotage Plan", parameter field list, and association table), stored in the pilotage plan table of the port scheduling database, and a log record of successful storage is generated (including entity ID, storage time, and associated application number).

[0055] In this embodiment, a high-frequency message monitoring and encrypted verification mechanism ensures real-time capture and integrity verification of approval result events, preventing message loss or tampering, enabling rapid response to changes in approval status, and shortening the interval between approval and plan generation. Core data such as vessel main dimensions, berth coordinates, and time intervals are extracted based on the original application number, and null values ​​or missing values ​​are eliminated through integrity verification. Combining port scheduling rules and vessel parameters, suitable berths are determined through a dual mechanism of basic rule filtering and safe distance verification, and berthing coordinates and azimuth are accurately calculated to ensure that the berth matches the vessel size and meets safe berthing distance requirements, reducing collision risks. Real-time tidal data query and tidal level correction calculation, combined with the vessel's design draft, dynamically adjust berthing and departure times to avoid grounding risks due to insufficient tide levels, improving the plan's environmental adaptability and safety. Multi-source data (coordinates, tide levels, time, etc.) are integrated into a structured pilotage plan entity, associated with the original application number, and injected with a status identifier, enabling full-link data traceability and status visualization management, improving the standardization and efficiency of port scheduling.

[0056] In a preferred embodiment of the present invention, step 3 involves extracting the vessel tonnage, berth coordinates, and time window parameters of the pilotage plan data entity. Based on the real-time vessel position, port tidal data, and channel congestion index, three dynamic reference points are dynamically determined, and a dynamic evaluation range including these reference points is constructed, comprising:

[0057] Step 300 involves parsing the vessel's approved deadweight tonnage, berth coordinates, and planned time window parameters from the pilotage plan data entity. Specifically, this includes: accessing the database table storing the pilotage plan data entity and locating the target data entity by associating it with the original application number generated in step 205; extracting three core parameters from this entity according to preset field names: first, the vessel's approved deadweight tonnage, accurate to the tonnage level (e.g., "50,000 tons"), and verifying whether its value is within the approved deadweight tonnage range recorded in the pilotage application data entity to ensure data consistency; second, the berth coordinates, extracting specific latitude and longitude values ​​(e.g., "38.523456°N, 121.234567°E"), confirming that the coordinate format conforms to the standard coding specifications of the port geographic information system; and third, the planned time window parameters, including four timestamps: planned berthing start time, berthing end time, planned departure start time, and departure end time. Checking for overlaps or logical contradictions in the time intervals (e.g., the berthing end time being earlier than the start time), and after confirmation, temporarily storing the three types of parameters in the data processing buffer.

[0058] Step 301: Obtain the ship's latitude and longitude coordinates and speed vector in real time through the Automatic Identification System (AIS). Combine this with the channel topology data provided by the electronic chart service interface to calculate the ship's expected spatiotemporal position at the channel entrance. Specifically, this includes: activating the AIS data receiving service, which obtains real-time data of the target ship from the AIS base station every 30 seconds, including the ship's current latitude and longitude coordinates (accurate to 6 decimal places) and speed vector (including speed value and heading angle, in knots and degrees respectively); and simultaneously, calling the channel topology data through the electronic chart service interface, which includes information such as channel entrance coordinates, total channel length, key turning point coordinates, minimum channel width, and water depth restrictions.

[0059] Starting from the ship's current latitude and longitude, the real-time navigation direction is calculated by combining the speed vector and matching the channel path on the electronic chart: First, the straight-line distance between the ship's current position and the channel entrance is calculated. Then, the theoretical navigation time is estimated based on the real-time speed (after deducting the speed reduction factor caused by the channel speed limit, such as a 10% reduction for busy channels). At the same time, the theoretical time is corrected by referring to the distribution of turning points in the channel (e.g., if a 5-knot reduction is required for a turning section, 5 minutes of navigation time is added for each turning point). Finally, the specific timestamp (accurate to the minute) and the corresponding latitude and longitude coordinates of the ship's expected arrival at the channel entrance are determined, forming the "expected spatiotemporal position of arrival at the channel entrance" data.

[0060] Step 302: Based on the port tide forecast service, obtain the tide height and change gradient data within the planned time window. Specifically, this includes: calling the dedicated interface of the port tide forecast service via HTTPS protocol, filling in the planned time window (i.e., the complete time interval for planned berthing and departure) extracted in step 300 and the geocode of the port to which the berth belongs in the request parameters; the interface returns the tide data within the time window, including the tide height value every 10 minutes (in meters, accurate to two decimal places), and the difference in tide change between adjacent time points (i.e., change gradient, in meters / minute).

[0061] The returned data undergoes time alignment verification to ensure that the time range of the tide level data fully covers the planned time window. If any data is missing (e.g., no records are available for a certain time period), a secondary query request is automatically triggered to supplement the data. After successful verification, the tide level heights are arranged in chronological order to form a sequence, and the absolute value of the change gradient at each time point is calculated (to distinguish between rising and falling tide trends), which is then stored as a structured tide level change dataset.

[0062] Step 303: Through the port traffic flow monitoring platform, the channel congestion index for different time periods is analyzed in real time to generate congestion impact weighting coefficients. Specifically, this includes: obtaining the real-time position coordinates and movement trajectories of all vessels in the channel through radar equipment deployed along the channel (scanning once every 2 seconds); using high-definition cameras (capturing once every 5 seconds) to assist in identifying vessel types and whether there are any abnormal berths; and simultaneously accessing the real-time data stream of the Automatic Identification System (AIS) (updated once every 30 seconds) to obtain information such as vessel identification, actual speed, heading, and destination berth. The three types of data are aggregated in real time through the platform's data bus to form the original monitoring dataset.

[0063] Perform cleaning and calibration on the raw data. Based on the preprocessed data, calculate the following parameters according to the smallest division unit of the planned time window (e.g., hourly):

[0064] Vessel density is calculated by dividing the number of vessels simultaneously present in the channel during a given period by the effective navigable length of the channel (e.g., if a channel is 10 nautical miles long, density = number of vessels / 10 vessels / nautical mile); average speed is calculated by comparing the average actual speed of all vessels during the given period with the channel's design navigable speed (e.g., 12 knots) to obtain the speed reduction rate (design speed - actual average speed) / design speed; vessel spacing compliance rate is calculated by dividing the number of vessel pairs whose actual distance is less than the safe spacing threshold (depending on the vessel type, e.g., 0.5 nautical miles for large vessels) by the total number of vessel pairs to obtain the proportion of non-compliant spacing; and traffic efficiency index is calculated by comparing the actual time taken for vessels to pass through key nodes in the channel (e.g., from channel entrance to exit) during the given period with the theoretical smooth passage time (estimated time without congestion) to obtain the proportion of time extension.

[0065] According to the preset index synthesis rules, the above parameters are weighted and integrated into a congestion index (range 0-10):

[0066] Ship density has the highest weight (40%), with higher density resulting in a higher index score; speed reduction rate is the second highest (25%), with more severe speed reduction (lower actual speed) resulting in a higher score; the proportion of non-compliant spacing accounts for 20%, with higher non-compliant proportions resulting in a higher score; traffic efficiency index accounts for 15%, with higher time extension proportions resulting in a higher score; after obtaining the initial index for the time period through weighted calculation, it is then compared with historical congestion data for the same period for correction (such as appropriately increasing the weight during peak hours), and finally the time-period congestion index value is determined (accurate to integers, 0 indicates completely smooth traffic, and 10 indicates extreme congestion).

[0067] According to the preset congestion weight mapping rules, the congestion index for each time period is converted into an impact weight coefficient: if the congestion index ≤ 3 (light congestion), the weight coefficient is set to 0.8 (indicating a small impact on the pilotage plan); if the congestion index ≤ 4 ≤ 6 (moderate congestion), the weight coefficient is set to 1.2 (indicating a moderate impact, requiring appropriate adjustments to the plan); if the congestion index ≥ 7 (severe congestion), the weight coefficient is set to 1.5 (indicating a significant impact, requiring key coordination and avoidance). At the same time, the congestion index and corresponding weight coefficient for each time period are associated with each time period of the planned time window extracted in step 300 to form a "time period - congestion index - weight coefficient" lookup table, which is stored in the data buffer for subsequent steps.

[0068] Step 304: Based on the predicted arrival position of the ship, the tide level change gradient data, and the congestion impact weighting coefficient, generate three dynamic position reference points. Specifically, this includes generating three dynamic position reference points based on the data from the previous steps:

[0069] The first benchmark point (channel entrance verification point): Based on the "spatial and temporal position of the ship expected to arrive at the channel entrance" calculated in step 301, and combined with the lateral offset at 1 / 3 of the channel width (calculated based on 1.5 times the safety distance of the ship's width), the specific latitude and longitude coordinates are determined as the first key verification point for the ship to enter the port channel.

[0070] The second benchmark point (control point for tide-sensitive section): Within the planned time window, select the period with the largest absolute value of the tide level change gradient (such as the 30 minutes with the fastest rising tide or the fastest falling tide), and combine it with the corresponding mid-channel position of the channel (extract the coordinates of the mid-channel from the electronic chart), and adjust the longitudinal position according to the tide level change gradient value (the larger the gradient, the 50-meter shift towards the deep water area) to form the control benchmark point for the tide level sensitive section.

[0071] The third benchmark point (congestion coordination point): Based on the congestion impact weight coefficient in step 303, select the channel branching position (such as the intersection of the main channel and the tributary) corresponding to the time period with the largest weight coefficient, and adjust the position according to the weight coefficient (for every 0.1 increase in weight, shift 10 meters towards the channel centerline) as the coordination benchmark point for dealing with congestion; each benchmark point records the corresponding timestamp, related influencing factors (such as tidal gradient value, congestion weight) and coordinate accuracy level.

[0072] Step 305: Using the three dynamic position reference points as core anchor points, construct a dynamic evaluation range covering the key stages of the ship's port entry path, and mark the dynamic evaluation range as a state to be analyzed. Specifically, this includes: using the three dynamic position reference points generated in step 304 as core anchor points, constructing the dynamic evaluation range:

[0073] Starting from the first benchmark point (channel entrance verification point), extend 2 nautical miles in the direction of vessel arrival (based on the safety warning distance corresponding to vessel tonnage, 2 nautical miles for 50,000-ton vessels), and extend 500 meters inward into the channel to form a "channel entrance warning zone," covering the initial stage of vessels entering the port. Centered on the second benchmark point (tide-sensitive section control point), extend 1 nautical mile forward and backward along the channel direction, and laterally by 1.2 times the channel width to form a "tide-affected core area," covering the critical stage of vessels passing through sections with drastic tidal changes. Centered on the third benchmark point (congestion coordination point), and combined with a congestion impact weighting system... The scope of the data is expanded (to 1.5 nautical miles around when the weighting coefficient is 1.5) to cover the intersection of waterways or sections with dense shipping, forming a "congestion coordination zone" that covers the key stages of ships avoiding congestion. The three zones are naturally connected through the waterway paths to form a continuous dynamic assessment scope. After the scope is constructed, the system calls the status management module to inject the "Pending Feature Analysis" status label (encoded as "Status:PendingFeatureAnalysis") into the metadata of the assessment scope, and stores the scope boundary coordinates and status information in the spatial database, waiting to be called in the subsequent feature analysis stage.

[0074] In this embodiment, the extraction and consistency verification of ship tonnage, berth coordinates, and time windows ensure the accuracy of core parameters of the pilotage plan, avoiding subsequent analysis deviations due to errors in basic data. Combining real-time AIS data with electronic chart channel topology, refined calculations such as speed reduction and steering correction accurately predict the spatiotemporal position of the ship arriving at the channel entrance, allowing pilotage planning to adapt to the actual navigation status of the ship in advance and enhancing the plan's foresight. The tidal service interface obtains the complete time window's tidal height and gradient, and time alignment and missing data supplementation ensure data integrity, reducing safety hazards such as grounding caused by tidal changes. Integrating multi-source data from radar, cameras, and AIS, and analyzing ship density, navigation... The congestion index is calculated by weighting core parameters such as velocity decay rate and generating corresponding weight coefficients to achieve a quantitative assessment of congestion status. This provides a definite quantitative basis for avoidance coordination in congested sections of the waterway and improves traffic efficiency. The three generated dynamic benchmark points correspond to the waterway entrance, the tide-sensitive section, and the core congestion area, respectively. Each point is dynamically adjusted based on real-time data (such as tide gradient shift and congestion weight shift) to accurately anchor key control nodes in the port entry process and ensure precise control of key links. The constructed dynamic assessment range covers the waterway entrance early warning, the core area of ​​the tide-sensitive section, and the congestion coordination area. Through continuous spatial range division, it fully covers the key stages of ship entry into the port and realizes the early identification and prevention of potential risks.

[0075] In a preferred embodiment of the present invention, step 4, calculating the morphological feature values ​​of the dynamic evaluation range, generating berthing and departure plan adjustment values, and constructing structured berthing and departure plan data by combining the parameters extracted in step 3, includes:

[0076] Step 400 involves performing spatial topological relationship analysis on the dynamic assessment range to extract the relative azimuth relationships and distance sequences between each reference point in the key stages of the ship's port entry path. Specifically, this includes: obtaining the dynamic assessment range metadata stored in step 305, which contains the original coordinate records of three reference points (in latitude and longitude text information, such as "Channel entrance verification point: 38°31.4076′N, 121°14.0742′E"); and converting the latitude and longitude of each reference point from the "degrees and minutes" format (such as 38°31.4076′) to the "decimal degrees" format commonly used in the WGS84 coordinate system. During the conversion, the integer part of the degree (e.g., 38°) is extracted first, and then the fractional part (31.4076′) is divided by 60 (1 degree = 60 minutes) to obtain the decimal degree. Finally, the integer degree and the decimal degree are added together to obtain the decimal value of the latitude. Longitude is converted in the same way to ensure that the coordinate accuracy is retained to 6 decimal places, which meets the accuracy requirements of the port geographic information system. The converted decimal coordinates are compared with the channel boundary range of the port electronic nautical chart to check whether each reference point is located within the preset effective channel area (e.g., the channel entrance check point must be within ±0.001° of the channel entrance coordinates, and the tide-sensitive section control point must be within the area where the water depth in the middle of the channel is ≥ the design draft of the ship). If the coordinates of a reference point exceed the effective range, the coordinate correction mechanism is triggered. Based on the channel centerline data of the electronic nautical chart, the coordinates of the point are adjusted to the nearest effective channel area (e.g., offset 0.0005° towards the channel centerline), and the reason for the correction and the adjustment amount are recorded.

[0077] Each benchmark is assigned a unique spatial identifier ID (e.g., “Benchmark Point-001”, “Benchmark Point-002”). The converted decimal coordinates (latitude, longitude) are bound to the identifier ID, and the source information of the benchmark is associated with it (e.g., the channel entrance verification point is associated with the expected arrival location data in step 301, and the tide level sensitive section control point is associated with the time period data of the maximum tide level gradient in step 302). This forms a structured coordinate dataset containing “identifier ID, latitude (decimal degree), longitude (decimal degree), source information, and verification status”. Then, the relative azimuth relationship between each benchmark is calculated: starting from the first benchmark, the azimuth angle of the second benchmark relative to the first benchmark is calculated through the coordinate difference (e.g., 30° east of north). Then, starting from the second benchmark, the relative azimuth angle of the third benchmark is calculated (e.g., 15° east of south), forming a continuous azimuth sequence of “start point - midpoint - end point”. Simultaneously, based on latitude and longitude coordinate conversion, the straight-line distance between adjacent reference points is calculated (in nautical miles, accurate to two decimal places), and arranged in the order of navigation to form a distance sequence (e.g., "2.5 nautical miles, 3.8 nautical miles"). Finally, the relative bearing relationships (azimuth values ​​and directions of change) and distance sequences are stored as a structured topological dataset.

[0078] Step 401: Calculate the rate of change of the route turning angle based on the relative bearing relationship, and generate a path morphology quantification index in conjunction with the distance sequence. Specifically, this includes: calculating the rate of change of the route turning angle based on the relative bearing relationship obtained in step 400: First, extract the difference in relative bearing angle between adjacent reference points (e.g., the bearing angle from the first reference point to the second reference point changes from 30° east of north to 15° east of south, the difference is 45°), and define this difference as the "route turning angle"; then divide the turning angle value by the distance between adjacent reference points (e.g., 45° ÷ 2.5 nautical miles = 18°). The distances between the three reference points are weighted and integrated with the rate of change of the steering angle per unit distance to obtain the "path curvature index". The sum of the "rate of change of steering angle × distance" values ​​for each turning segment is then divided by the total path length (the sum of the distances between the three reference points) to obtain a quantitative index reflecting the overall curvature of the path (e.g., 0.3 indicates slight curvature, 0.7 indicates severe curvature). The larger the index, the more frequent or larger the turning angles of the path.

[0079] Step 402: Based on the ship's verified deadweight tonnage, tidal level change gradient data, and path morphology quantification indicators, generate the ship's maneuvering inertia compensation coefficient. Specifically, this includes integrating three types of core parameters to generate the coefficient:

[0080] For vessels with rated deadweight tonnage, a basic inertia coefficient is assigned based on tonnage classification rules (e.g., ≤30,000 tons for small vessels, 30,000-100,000 tons for medium vessels, and ≥100,000 tons for large vessels). The coefficient is 0.8 for small vessels, 1.0 for medium vessels, and 1.2 for large vessels. The larger the tonnage, the higher the basic coefficient (greater inertia results in slower maneuvering response). For tidal level gradient, the absolute value of the tidal level gradient from step 302 is divided into three levels (≤0.02 m / min for gentle gradients, 0.02-0.05 m / min for moderate gradients, and ≥0.05 m / min for medium gradients). The gradient correction coefficient is calculated based on the path tortuosity index in step 401 (≤0.3 for smooth, 0.3-0.6 for moderate, ≥0.6 for tortuous). The corresponding correction coefficient is calculated based on the path tortuosity index (≤0.3 for smooth, 0.3-0.6 for moderate, ≥0.6 for tortuous). The corresponding correction coefficient is calculated based on the path tortuosity index (≤0.3 for smooth, 0.3-0.6 for moderate, ≥0.6 for tortuous). The corresponding correction coefficient is calculated based on the path tortuosity index (≤0.3 for smooth, 0.3-0.6 for moderate, ≥0.6 for tortuous). The more tortuous the path, the higher the coefficient (increased turning requirements, requiring more inertial compensation).

[0081] Finally, the ship maneuvering inertia compensation coefficient (retaining two decimal places) is obtained by multiplying the basic inertia coefficient by the gradient correction coefficient by the shape correction coefficient, and is used as the core parameter for subsequent plan adjustments.

[0082] Step 403: Based on the product of the congestion impact weighting coefficient and the maneuvering inertia compensation coefficient, calculate and generate the berthing and departure time offset and berth fine-tuning coordinates to form the berthing and departure plan adjustment value. Specifically, this includes: calculating the berthing and departure plan adjustment value based on the congestion impact weighting coefficient from step 303 and the maneuvering inertia compensation coefficient from step 402.

[0083] The time offset is calculated by multiplying the congestion impact weighting coefficient (e.g., 1.2) and the maneuvering inertia compensation coefficient (e.g., 1.1) to obtain the adjustment coefficient (1.2 × 1.1 = 1.32). The adjustment coefficient is categorized as follows: when the coefficient ≤ 1.0, the time offset is -10 minutes (10 minutes earlier, due to its small impact); when 1.0 < coefficient ≤ 1.3, the offset is 0 (no adjustment required); when the coefficient > 1.3, the offset is +15 minutes (15 minutes later, due to its large impact, a buffer needs to be reserved). Simultaneously, the time offset is fine-tuned by incorporating the tide level correction (step 204) (e.g., an additional 5 minutes later if the tide level is insufficient), ultimately determining the total time offset.

[0084] The berth fine-tuning coordinates are calculated by determining the lateral and longitudinal fine-tuning values ​​based on the adjustment coefficients: Lateral fine-tuning (along the berth width) = adjustment coefficient × 5 meters (e.g., 1.32 × 5 = 6.6 meters, adjusting 6.6 meters towards the deep water area); Longitudinal fine-tuning (along the berth length) = adjustment coefficient × 3 meters (e.g., 1.32 × 3 = 3.96 meters, adjusting 3.96 meters towards the inner channel). The fine-tuning values ​​are converted into latitude and longitude coordinate differences (based on port coordinate transformation rules) and added to the precise berth coordinates from step 203 to obtain the corrected berth fine-tuning coordinates. The time offset and the fine-tuning coordinates together constitute the berthing and departure plan adjustment values, which are stored as a structured adjustment parameter set.

[0085] Step 404: Integrate ship tonnage, berth coordinates, time window parameters, and the aforementioned berthing and departure plan adjustment values ​​to construct structured berthing and departure plan data containing corrected berthing coordinates, departure coordinates, and time offsets. Specifically, this includes: integrating multi-source data to construct structured berthing and departure plan data.

[0086] The basic parameter layer imports the ship's approved deadweight tonnage, original berth coordinates, and planned time window parameters (berthing / departure start and end times) extracted in step 300. The adjustment parameter layer adds the berthing / departure time offsets generated in step 403 (corresponding to berthing and departure time adjustment values ​​respectively) and the corrected berth fine-tuning coordinates (berthing and departure coordinates, which may differ due to different berthing / departure directions). The associated information layer supplements the dynamic reference point coordinates from step 304 and the path morphology quantification indicators from step 401 as auxiliary explanatory fields for the planned data. During the fusion process, field compatibility checks are performed (e.g., time format is unified to "YYYY-MM-DDHH:MM:SS", coordinates retain 6 decimal places) to ensure standardized data format. Logical consistency is also checked (e.g., the corrected berthing time must be within the safe tide period). Finally, structured berthing / departure planned data containing "basic ship information, original planned parameters, adjusted parameters, and auxiliary evaluation indicators" is generated and stored in the planned database.

[0087] Step 405: Responding to the electronic declaration instruction triggered by the port operator, update the associated status identifier to the declared status identifier and activate the berthing / departure plan execution queue. Specifically, this includes: real-time monitoring of the port operator's workbench instruction input interface; when an operator triggers an "electronic declaration" instruction (including instruction signature and operation timestamp), first verifying the operator's permissions (confirming whether the operator account has declaration permissions through the identity authentication module); and then performing a status update after successful verification.

[0088] Extract the associated original application number from the structured berthing and departure plan data, locate the corresponding pilotage plan data entity (step 205), update its status identifier from "Pending Space Assessment" to "Submitted" (coded as "Status:Declared"), and record the status change time and operator information; sort the structured berthing and departure plan data by priority (based on vessel tonnage and urgency), add it to the execution queue buffer, and simultaneously send a queue activation notification to the port scheduling system to trigger the preparation process for subsequent tugboat configuration, pilotage operations, etc. Upon completion, generate a successful application log, including the plan data ID, application time, and status change record.

[0089] In this embodiment of the invention, a structured topological dataset is constructed by analyzing the relative bearing and distance sequences between reference points, clearly presenting the spatial characteristics of the ship's entry path and avoiding planning deviations caused by ambiguous spatial relationships. The calculated rate of change of the route turning angle and the path tortuosity index provide a quantitative description of the curvature of the entry path. The maneuvering inertia compensation coefficient is generated by integrating three key factors: ship tonnage, tidal gradient, and path morphology, accurately reflecting the ship's maneuvering response characteristics under different conditions, ensuring that the plan adjustment can adapt to the actual maneuvering needs of the ship, and reducing operational errors caused by insufficient inertia prediction. The time offset and berth fine-tuning coordinates are calculated based on the product of congestion weight and inertia compensation coefficient, realizing dynamic optimization of berthing and departure plans. Standardized berthing and departure plan data is formed by integrating basic parameters, adjustment parameters, and related information. Data standardization is ensured through format verification and logical consistency checks, facilitating data sharing and collaboration among various port systems and improving the management efficiency of pilotage plans. The status identifier is updated and the execution queue is activated through permission verification, achieving seamless connection from plan evaluation to execution.

[0090] In a preferred embodiment of the present invention, step 5, based on the declared status identifier, corrects the pilotage time window using the berthing / departure plan adjustment value, generates a pilotage operation plan entity, and writes it into the tugboat configuration pending queue, including:

[0091] Step 500: In response to the activation event of the declared status identifier in the berthing and departure plan execution queue, extract the time offset and berth fine-tuning coordinates from the structured berthing and departure plan data. Specifically, this includes: continuously monitoring the status changes of the berthing and departure plan execution queue (monitoring frequency is once every 0.5 seconds); when the status identifier of a record in the queue is detected to be "Declared" (Status:Declared) and an activation event is triggered (identified by the event type field "ActivatedEvent"), immediately lock the structured berthing and departure plan data corresponding to that record.

[0092] Two core parameters are precisely extracted from the data by field name: first, time offset, including berthing time offset (e.g., "+15 minutes") and departure time offset (e.g., "+10 minutes"), checking that the numerical format of the offset is an integer minute (no decimals or negative numbers); second, berth fine-tuning coordinates, including berthing fine-tuning coordinates (latitude and longitude, accurate to 6 decimal places) and departure fine-tuning coordinates (which may differ depending on the berthing or departure direction), verifying that the coordinates are within the reasonable fine-tuning range calculated in step 403 (e.g., lateral fine-tuning not exceeding 10 meters, longitudinal fine-tuning not exceeding 5 meters). After extraction, the two types of parameters are associated with the original application number and temporarily stored in the memory processing area, while marking the data extraction completion status.

[0093] Step 501: Based on the pilotage time window dynamic correction algorithm, input the original pilotage time window parameters, tidal level change gradient data, and time offset to calculate and generate the pilotage operation time interval after dual correction for tides and congestion. Specifically, this includes importing three types of input data: First, the original pilotage time window parameters extracted in step 300 (original berthing start / end time, original departure start / end time); second, the tidal level change gradient data generated in step 302 (including the safe tidal period, i.e., the period when the tidal level is ≥ the ship's design draft + 0.5 meters); and third, the time offset extracted in step 500 (berthing + 15 minutes, departure + 10 minutes).

[0094] Comparing the original time window with the safe tide period, if the original berthing time partially exceeds the safe period (e.g., the original berthing start time is during a period of insufficient tide), the berthing start time is shifted to the nearest safe start time (e.g., from 08:00 to 08:30). The same applies to the departure time, ensuring it falls entirely within the safe tide period. Based on the tidal safety-corrected time, a time offset is added, i.e., corrected berthing start time = tidal safety berthing start time + berthing time offset (e.g., 08:30 + 15 minutes = 08:45), and the berthing end time is shifted back by the same offset. The departure time is calculated using the same logic (e.g., the original departure start time 16:00 is corrected to 16:10 by the tide, and after adding a +10-minute offset, it becomes 16:20). Finally, a pilotage operation time interval containing "corrected berthing start time, berthing end time, departure start time, and departure end time" is generated, ensuring that this interval simultaneously meets tidal safety and congestion buffering requirements, and a time comparison log before and after the correction is recorded.

[0095] Step 502: Update the berth coordinates in the pilotage plan data entity based on the berth fine-tuning coordinates, integrate the corrected pilotage operation time interval, vessel tonnage, and maneuvering inertia compensation coefficient, and generate a pilotage operation plan entity containing key nodes of the pilotage path and power demand parameters. Specifically, this includes: extracting the berth fine-tuning coordinates (berthing and departure) from step 500, replacing the original precise berth coordinates in step 203, and noting the correction reason (such as "fine-tuning due to tides and congestion") and the original coordinate values ​​in the entity's "coordinate change record" field to ensure data traceability.

[0096] Based on the coordinates of the three dynamic reference points obtained in step 304, key nodes such as turning points, deceleration zones, and meeting zones within the channel are supplemented (extracted from electronic charts). For each node, a suggested passage time (calculated based on the revised operation time interval and speed) and safety operation instructions (e.g., a speed limit of 8 knots at turning points) are marked. Combining the vessel's approved deadweight tonnage (e.g., 50,000 tons), the maneuvering inertia compensation coefficient from step 402 (e.g., 1.1), and path morphology quantification indicators (e.g., tortuosity index of 0.4), the power requirements for each key node are determined: for example, a continuous thrust coefficient of 0.8 is recommended for straight channel sections, increased to 1.2 for turning sections, and an additional thrust compensation of 0.1 is required for tide-sensitive sections (to cope with the impact of currents). The key nodes, power requirement parameters, and the revised operation time interval and vessel tonnage are integrated to construct a pilotage operation plan entity according to a preset structure (including "plan ID, associated application number, node list, power parameter table, and time interval"), and stored in the operation plan database.

[0097] Step 503: Calculate the minimum total thrust required for tugboats based on the ship tonnage classification rules and power demand parameters. Specifically, this includes: determining the tonnage class of the target ship (e.g., ≤30,000 tons for small ships, 30,000-100,000 tons for medium ships, and ≥100,000 tons for large ships) according to the ship tonnage classification rules (e.g., 50,000 tons for medium ships); and setting a basic tugboat thrust standard for each class: a minimum basic thrust of 2,000 kN for small ships, 4,000 kN for medium ships, and 6,000 kN for large ships.

[0098] Further refinement based on the power demand parameters from step 502:

[0099] If the maneuvering inertia compensation coefficient is greater than 1.0 (e.g., 1.1), the base thrust is increased according to the coefficient value (4000 × 1.1 = 4400 kN); if the path morphology quantification index is "moderate" or "torsional" (e.g., 0.4 is moderate), an additional 10% thrust compensation is added (4400 × 1.1 = 4840 kN); if the tidal level change gradient is "drastic" (e.g., 0.06 m / min), an additional 5% water flow compensation thrust is added (4840 × 1.05 ≈ 5082 kN); finally, the integer upper limit of the corrected thrust value is taken as the minimum required total thrust of the tugboat (e.g., 5082 kN rounded up to 5100 kN) to ensure that the tugboat's power is sufficient to meet the ship's maneuvering needs.

[0100] Step 504: Inject the pilotage operation plan entity into the tugboat configuration pending queue and configure the queue priority label according to the urgency of the time window. Specifically, this includes: writing the pilotage operation plan entity generated in step 502 into the tugboat configuration pending queue through the queue interface. When writing, first verify the integrity of the entity (check whether it contains required fields such as plan ID, time interval, thrust requirement, etc.). If it is complete, assign a queue entry ID; otherwise, return a data missing error and pause writing.

[0101] Queue priority label configuration is based on time window urgency assessment:

[0102] Extract the start time of the corrected pilotage operation time interval (e.g., berthing start time 08:45), calculate the interval with the current system time (e.g., current time 07:00, interval 105 minutes); intervals ≤60 minutes are marked as "urgent" (priority 1), 60-120 minutes are marked as "medium" (priority 2), and >120 minutes are marked as "normal" (priority 3); at the same time, refer to the tonnage of the vessel, and the priority of large vessels is increased by 1 level within the same time interval (e.g., large vessels are marked as priority 1 with an interval of 105 minutes); after binding priority tags to queue entries, store them in order of priority (priority 1 first, priority 3 last), and send a queue update notification to the tugboat dispatch system to trigger the tugboat resource matching process; after completion, generate a write log, recording the queue entry ID, priority, key information of the planned entity, and write time.

[0103] In this embodiment of the invention, by frequently monitoring activation events of declared status, the target plan data is quickly located and the time offset and berth fine-tuning coordinates are extracted. Format and range verification is combined to ensure parameter accuracy and avoid interference from invalid data. The time window is double-corrected by combining the tidal safety period and congestion offset, ensuring that ships berth and depart during tidal safety periods while reserving congestion buffers through time offsets, effectively reducing the risk of delays due to insufficient tides or channel congestion and improving the feasibility of the time plan. The berthing position is updated and optimized through berth fine-tuning coordinates, and pilotage operations are generated by integrating time intervals, ship tonnage, and inertia compensation coefficients. The operational plan identifies key nodes and power requirements along the route, ensuring the plan better aligns with vessel maneuvering characteristics and actual waterway conditions, thus enhancing the accuracy of operational execution. Based on tonnage classification and power requirement parameters, the minimum total thrust of tugboats is calculated through multi-dimensional corrections (inertia, route, tides) to ensure precise matching between tugboat power and vessel maneuvering needs, avoiding maneuvering risks due to insufficient thrust and guaranteeing safe berthing and unberthing operations. Tugboat resources are allocated in a queue priority system based on time urgency and vessel tonnage, enabling orderly scheduling and prioritizing urgent plans for resource allocation, reducing waiting time, and improving the response speed and overall operational efficiency of port tugboat deployment.

[0104] In a preferred embodiment of the present invention, step 6, polling the tugboat configuration queue generated in step 5, responding to the tugboat configuration completion command, adapting the tugboat power parameters and updating the status, includes:

[0105] Step 600: Start the scheduled task polling engine to scan the tugboat configuration pending queue and capture the configuration completion event command returned by the tugboat scheduling system. Specifically, this includes: performing a full scan of the tugboat configuration pending queue every 30 seconds according to preset rules; during the scan, first read the status of all unprocessed or processed entries in the queue (identified by the "Configuration Status" field, such as "Pending Assignment", "Assigning", "Completed"), and focusing on filtering entries with the status of "Completed"; when the tugboat scheduling system returns a "Configuration Completion Event Command" through the queue interface, immediately extract the event identifier (such as "TugConfigCompletedEvent") and the associated pilotage operation plan ID from the command header, and verify whether the ID matches a certain entry ID in the queue (to ensure command correspondence); then verify the integrity of the command: check whether it contains required fields such as tugboat number group, assignment timestamp, and dispatcher signature. If the fields are complete and the signature passes encryption verification (matching the tugboat scheduling system's preset certificate), then a valid configuration completion event is confirmed to have been captured; if there are missing fields or invalid signatures, mark it as an abnormal command and log it, waiting for the next poll to recapture it.

[0106] Step 601 involves parsing the tugboat number group and initial power parameter set allocated in the instruction, and dynamically adapting the engine according to the tugboat power. Specifically, this includes parsing the fields of the valid configuration completion event instruction captured in step 600. First, the tugboat number group is extracted from the instruction body. This group contains the unique identifiers of all allocated tugboats (such as "TUG-001, TUG-003, TUG-005"). Then, the basic information such as the tugboat type (such as azimuth tugboat, harbor tugboat), rated maximum thrust (such as 3000 kN per wheel), and power system model corresponding to each number is queried through the tugboat basic database to confirm that the tugboat group type matches the vessel tonnage in the pilotage operation plan (such as a medium-sized vessel being adapted to a 3000 kN-class tugboat).

[0107] Simultaneously, the initial power parameter set is extracted, including the initial thrust distribution ratio of the tugboat group (e.g., 60% for the main tugboat and 40% for the auxiliary tugboats), the default speed (e.g., 8 knots), and the power response delay time (e.g., 2 seconds). The initial parameters are then validated for reasonableness: the sum of the thrust distribution ratios is checked to ensure it is 100%, and the default speed is within the tugboat's design speed range (e.g., ≤12 knots). If any anomalies are found (e.g., the sum of the ratios ≠ 100%), the standard initial parameters for that type of tugboat are retrieved from the tugboat database and used as replacements, with the reason for the parameter correction recorded. After parsing, the tugboat number group is associated with the validated initial power parameter set and stored in a temporary data area, awaiting adaptation and optimization.

[0108] Step 602: Based on the ship maneuvering inertia compensation coefficient, route turning angle change rate, and minimum total thrust in the pilotage operation plan entity, generate a tugboat group dynamic optimization parameter set through a dynamic parameter adaptation matrix. Specifically, this includes loading a pre-set "dynamic parameter adaptation matrix," which defines the corresponding adjustment rules for tugboat dynamic parameters under different ship maneuvering conditions. First, import three types of core input parameters:

[0109] The ship maneuvering inertia compensation coefficient in the pilotage operation plan entity (e.g., 1.1); the rate of change of the route turning angle calculated in step 401 (e.g., 18° / nautical mile); the minimum total thrust of the tugboat determined in step 503 (e.g., 5100 kN).

[0110] Parameter optimization based on the adaptation matrix:

[0111] Calculate the current rated total thrust of the tugboat group and compare it with the minimum total thrust. If the rated total thrust is greater than or equal to the minimum (6000 ≥ 5100), the base thrust is retained; if it is insufficient, an alarm is triggered (in actual scenarios, the tugboat dispatching system has already ensured matching, this is a secondary verification). Since a steering angle change rate of 18° / nautical mile represents a medium steering requirement, the thrust ratio of the main tugboat is increased by 5% (from 60% to 65%) according to the matrix rules, while the auxiliary tugboat remains at 35%, enhancing steering control. At the same time, the power response delay time during steering is reduced to 1.5 seconds (default). 2 seconds), improving steering flexibility; combined with a maneuvering inertia compensation coefficient of 1.1, the thrust for straight channel sections is increased (base thrust × 1.1) to ensure that the tugboat's power is sufficient to offset the ship's inertia; an additional 5% thrust compensation is added for tide-sensitive sections (to cope with the influence of water flow); finally, a set of tugboat group power optimization parameters is generated, including "single wheel thrust value, thrust distribution ratio, response delay time, and recommended speed value", and the total thrust is checked to see if it meets the minimum requirement (e.g., the optimized total thrust is 5500 kN ≥ 5100 kN). After confirming that there are no errors, the optimization parameters are stored.

[0112] Step 603: Inject the tugboat number group and the optimized parameter set into the pilotage operation plan entity, and update its status identifier to the ready state. Specifically, this includes: associating the pilotage operation plan entity generated in step 502 with the pilotage operation plan ID; injecting the tugboat number group (such as "TUG-001, TUG-003") from step 601 and the power optimization parameter set (including single wheel thrust, distribution ratio, etc.) from step 602 into the "tugboat configuration information" field of the entity; and recording the tugboat configuration completion timestamp and the adapted engine version number (for tracing the optimization logic); changing the original state (such as "tugboat configuration pending") to "ready state" (coded as "Status:Ready"), and noting the reason for the change ("tugboat configuration completed, power parameters optimized"), the operator (tugboat dispatching system ID), and the change time in the status change log. Once completed, the updated pilotage operation plan entity is stored back in the operation plan database, and a "tugboat ready" notification is sent to the pilotage dispatch terminal, indicating that the pilotage operation can be started. At the same time, a configuration completion report is generated, which includes information such as tugboat number, optimized parameters, and status change records.

[0113] In this embodiment of the invention, a timed polling mechanism (every 30 seconds) continuously monitors the tugboat configuration status, quickly captures configuration completion events, and verifies the validity of instructions, avoiding operational delays caused by information latency and ensuring seamless integration of tugboat configuration with pilotage plans. The tugboat number group and initial parameters are analyzed, and their compatibility with the ship's tonnage is verified using the tugboat database. Abnormal parameters are corrected to ensure that the allocated tugboat type, rated thrust, and other basic attributes meet pilotage requirements, preventing resource mismatch from the outset. Based on core parameters such as inertia compensation coefficient and rate of change of steering angle, the thrust allocation and response delay parameters are optimized through a power adaptation matrix, enabling the tugboat's power output to accurately match the ship's maneuvering needs (such as enhanced thrust during steering and inertia compensation during straight-course sections), significantly improving maneuverability during berthing and unberthing. The tugboat configuration information is injected into the work plan and updated to a ready state, simultaneously triggering a notification mechanism to achieve a closed-loop process from resource configuration to operational preparation, while fully recording the configuration process (timestamps, parameter changes, etc.) to ensure traceability throughout the entire process.

[0114] In a preferred embodiment of the present invention, a structured data packet for ship entry and exit is generated based on the pilotage plan data entity and the pilotage operation plan entity, and submitted to the port supervision system to obtain a joint status code, including:

[0115] Step 604: Extract the vessel's approved deadweight tonnage, berth coordinates, and basic vessel attributes from the pilotage plan data entity. Specifically, this includes: locating the target entity record from the persistently stored pilotage plan database using the unique identifier of the pilotage plan data entity (such as the original application number); and extracting three types of core data according to a preset field list:

[0116] For the vessel's certified deadweight tonnage, the exact value and unit (e.g., "50,000 tons") are extracted and compared with the original tonnage record in the pilotage application data entity to ensure data consistency (error ≤ 1%). For berth coordinates, the corrected berthing and departure fine-tuning coordinates (latitude and longitude, accurate to 6 decimal places) are extracted and linked to basic information such as berth number and port area. For basic vessel attributes, including static information such as vessel name, International Maritime Organization (IMO) number, vessel call sign, port of registry, year of construction, and vessel type classification code (e.g., "bulk carrier" or "container ship"), each field is checked for null values ​​or format errors (e.g., the IMO number must be 7 digits). If missing, it is supplemented from the vessel's basic database to ensure the completeness of basic attributes. After extraction, the data is temporarily stored in the data preprocessing area and marked as "data to be integrated".

[0117] Step 605: Synchronously acquire the revised pilotage operation time interval, tugboat number group, power optimization parameter set, and key nodes of the pilotage route from the pilotage operation plan entity. Specifically, this includes: associating the pilotage operation plan entity generated in step 502 with the pilotage operation plan ID, and synchronously extracting four types of dynamic operation data:

[0118] The revised pilotage operation time interval includes the revised berthing start / end time and departure start / end time (formatted as "YYYY-MM-DDHH:MM:SS"). Check for overlaps or logical contradictions in the time intervals (e.g., berthing end time ≤ departure start time). Extract the unique identifier of the tugboat injected in step 603 (e.g., "TUG-001, TUG-003") and supplement auxiliary information such as the company to which each tugboat belongs and its vessel identification number (MMSI code).

[0119] The power optimization parameter set includes single-wheel thrust value, thrust distribution ratio, power response delay time, and recommended speed value. Verify that the parameters are within the reasonable range calculated in step 602 (e.g., total thrust ≥ minimum total thrust). Extract the coordinates and recommended passage time of the channel entrance verification point, tide-sensitive section control point, congestion coordination point and turning point, and deceleration zone. Sort the data according to the navigation sequence to form a node list. After extraction, perform timestamp alignment verification on the data (ensure that the node time is within the operation time interval). After confirming that there are no errors, temporarily store the data in the dynamic data buffer.

[0120] Step 606: According to the port data specification verifier, the ship's basic attributes, berth coordinates, pilotage time interval, and tugboat configuration data are reorganized and formatted according to the customs data element standard. Specifically, this includes: loading the "Ship Inbound / Outbound Data Element Standard" issued by the General Administration of Customs (including specifications such as field names, data types, format lengths, and value ranges); first, establishing field mapping relationships:

[0121] Map the "Vessel Name" in "Basic Vessel Attributes" to the standard field "VesselName", and the "IMO Number" to "IMONumber" (forced 7-digit number); convert "Berth Coordinates" to standard geographic coordinate format (latitude format is "DD°MM'SS.SS''N", longitude format is "DDD°MM'SS.SS''E"); and uniformly convert "Revised Pilotage Operation Time Interval" to "UTC Time" format (e.g., "2025-08-15T08:45:00Z"), corresponding to the standard field "PilotageS". The format conversion is performed using the fields "tartTime" and "PilotageEndTime". The "Tug Number Group" and power parameters are mapped to the "TugInformation" array, which includes subfields such as "TugID", "RatedThrust", and "ThrustRatio". After format conversion, the validator checks each field according to standard rules: for example, "Port of Registry" must match a preset port code table (e.g., "Shanghai Port" corresponds to code "CNSHA"), time fields must conform to ISO8601 standards, and numerical fields must retain a specified number of decimal places (e.g., thrust is retained as an integer). If a field mismatch exists (e.g., format error), automatic format correction is triggered (e.g., converting "2024 / 05 / 15" to "2024-05-15"), and a correction log is recorded. If the field still does not meet the specifications after correction, it is marked as a "Pending Manual Verification" field.

[0122] Step 607: Inject the real-time position trajectory traceability identifier of the vessel and the digital fingerprint of the tugboat's power, and construct a customs structured data packet containing the vessel's static attributes, dynamic operating parameters, and auxiliary equipment information. Specifically, this includes: generating the real-time position trajectory traceability identifier of the vessel: based on the real-time trajectory data of the vessel's AIS system (latitude and longitude coordinate sequence within the past hour), a unique string (such as "Trace-8F7D2C9A") is generated through a hash algorithm, associated with the vessel's IMO number and the current timestamp, to ensure that the trajectory can be traced back to the specific vessel and time period; performing data digest calculation (such as SHA-256 hash) on the power optimization parameter set (thrust value, allocation ratio, response time, etc.) extracted in step 605, and generating a fixed-length fingerprint string (such as "Fingerprint-3E5B7D1F") to verify whether the power parameters have been tampered with during transmission.

[0123] Construct a structured data package for customs, integrating data according to a standard hierarchical structure, namely:

[0124] The first-level node "StaticProperties" includes basic ship attributes and approved deadweight tonnage; the second-level node "DynamicOperations" includes the corrected time interval and key nodes of the pilotage route; the third-level node "AuxiliaryEquipment" includes tugboat number groups, power optimization parameter sets, and digital fingerprints; the additional node "Traceability" includes trajectory traceability identifiers and data generation timestamps; the data package is encapsulated in JSON format to ensure clear hierarchy and complete fields, and passes the final integrity check of the validator (no missing required fields).

[0125] Step 608: Submit the data packet to the port supervision system via an encrypted data channel, and initiate an asynchronous status code listening service. This involves real-time capture and parsing of the combined status code bitmap returned by the customs, maritime, and border inspection systems. Specifically, this includes submitting a structured data packet to the port supervision system via a dedicated encrypted data channel (using the TLS 1.3 protocol). Before submission, the data packet is digitally signed (using a port electronic certification certificate) to ensure the data source is trustworthy. Immediately after submission, the asynchronous status code listening service is initiated. This service maintains a long connection with the port supervision system via the WebSocket protocol, receiving status update pushes every 5 seconds.

[0126] When a return result is received, the combined status code bitmap is parsed: the bitmap contains status codes from three systems: Customs (1 bit, 0 = failed, 1 = passed), Maritime (1 bit, 0 = failed, 1 = passed), and Border Inspection (1 bit, 0 = failed, 1 = passed), which are combined to form a 3-bit binary code (e.g., "111" indicates all passed, "101" indicates maritime failed). The binary code is converted into a readable status, such as "111" corresponding to "joint approval passed" and "101" corresponding to "maritime approval failed," and the specific feedback information from each system is extracted (e.g., the reason for maritime failure: "tugboat power parameters do not meet the standard"). If the combined status code is "all passed," the pilotage operation plan entity status is updated to "supervisory passed." If there are any failed items, a rectification notice is pushed to the port operator terminal, including the specific failed system and the reason, waiting for the data packet to be resubmitted. At the same time, the status code reception time, bitmap parsing result, and feedback information are recorded to form a complete regulatory interaction log.

[0127] In this embodiment of the invention, static attributes and dynamic operational data are extracted from the planning entity, respectively. Through consistency checks (e.g., tonnage error ≤1%), integrity supplementation (e.g., missing attributes retrieved from the database), and logical checks (e.g., no overlap in time intervals), the accuracy of the basic data is ensured. Field reorganization and format conversion are performed according to customs data element standards. Through mapping alignment (e.g., vessel name → VesselName), format unification (e.g., time to UTC, coordinates to standard format), and standard verification, data format barriers are eliminated, ensuring that data packets can be correctly parsed by various port systems, improving the efficiency of cross-departmental data interaction. The injected trajectory traceability identifier (associated with AIS trajectory) and dynamic digital fingerprint (hash verification) are used to... The system enables traceability of ship dynamic trajectories and tugboat parameter tamper-proofing, enhancing the authenticity and security of data packets and meeting the stringent requirements of port supervision for data credibility. The JSON data packets, encapsulated in a hierarchical structure (static attributes, dynamic operations, auxiliary equipment, etc.), are clearly structured and have complete fields, conforming to customs data standards while facilitating data storage, retrieval, and reuse, thus improving the management standards for ship entry and exit data. Through encrypted channel transmission and triggering multi-system joint approval, an asynchronous monitoring mechanism obtains joint status codes in real time and quickly provides feedback on approval results (e.g., "111" indicates full approval), ensuring data transmission security and enabling collaborative supervision among customs, maritime affairs, and border inspection, shortening the approval cycle and reducing manual intervention costs.

[0128] In a preferred embodiment of the present invention, matching the joint state code with a preset threshold to trigger the ship's state machine to switch to a terminal state or an anti-terminal state includes:

[0129] Step 609: According to the preset customs clearance status threshold rule base, the rule base defines that the final customs clearance state must satisfy the following conditions in the status code combination bitmap: Customs release code = 1, Maritime permit code = 1, and Border inspection verification code = 1. Specifically, this includes: loading the preset "customs clearance status threshold rule base", which is stored in the form of a structured data table and contains three core rule fields and judgment conditions:

[0130] Customs release code is defined as a 1-bit binary value. "1" indicates that customs has approved the vessel's entry and exit procedures and allows clearance; "0" indicates that the approval has not been approved (e.g., incomplete declaration data, outstanding taxes and fees, etc.). Maritime permit code is defined as a 1-bit binary value. "1" indicates that the maritime authorities have approved the vessel's pilotage plan and safe operating conditions; "0" indicates that the approval has not been approved (e.g., insufficient tugboat power, failure to meet waterway safety standards, etc.). Border inspection verification code is defined as a 1-bit binary value. "1" indicates that the border inspection authorities have approved the crew's documents, vessel nationality, etc.; "0" indicates that the approval has not been approved (e.g., expired documents, inconsistent personnel information, etc.).

[0131] The rule base determines the triggering conditions for "final clearance status", which simultaneously satisfy the following conditions: customs release code = 1, maritime license code = 1, border inspection verification code = 1 (i.e., the combined bitmap is "111"), and there are no other abnormal status codes (such as invalid values ​​such as "9" caused by system failure). The rule base supports dynamic updates, and each update requires confirmation by the administrator's signature.

[0132] Step 610: Compare the combined status code bitmap of the vessel to be processed with the threshold rule in real time. When all bitmap values ​​are 1, trigger the vessel state machine to switch to the final customs clearance state. Specifically, this includes: starting the status comparison service and obtaining the combined status code bitmap of the vessel to be processed (such as "111", "101", etc.) parsed in step 608 in real time. Split the bitmap bitwise and match it with three fields in the rule base: the first bit corresponds to the customs release code, the second bit corresponds to the maritime permit code, and the third bit corresponds to the border inspection verification code.

[0133] The comparison process consists of two steps:

[0134] Check if each value is "1": Confirm that the Customs Release Code = 1, Maritime Permit Code = 1, and Border Inspection Verification Code = 1, and there are no abnormal codes (such as invalid values ​​like "9" in the bitmap); verify whether the combined conditions completely match the threshold requirements of "Final Customs Clearance State" in the rule base. If they completely match (e.g., the bitmap is "111"), trigger the ship state machine switching instruction: update the current state (e.g., "Under Regulatory Review") to "Final Customs Clearance State", and record the switching time, triggering condition ("All Joint Status Codes Passed"), and operator (automatically executed by the system) in the state machine log. At the same time, send a "Customs Clearance Completed" notification to the port scheduling system to activate the final execution authority for subsequent ship berthing and departure operations.

[0135] Step 611: When a bitmap value of 0 or an anomaly code is detected, the anti-clearance processing engine is activated to perform the following operations: parse the source system and error type of the anomaly status code, generate an anti-clearance alarm event containing correction instructions, switch the ship's state machine to the anti-clearance final state and roll back to the corresponding processing stage, update the status identifier to the anomaly suspended state and freeze the subsequent process. Specifically, when the comparison result in step 610 does not meet the clearance final state conditions (such as the presence of "0" in the bitmap or the inclusion of anomaly codes such as "9"), the anti-clearance processing is immediately activated; after activation, the pilotage operation plan entity of the ship to be processed is first locked to prevent it from entering the next process; at the same time, all associated tasks of the ship in the tugboat configuration queue and berthing / departure execution queue are suspended and marked as "pending anomaly processing" status.

[0136] The anti-clearance processing engine loads a preset exception handling process template. This template defines exception type classification (such as customs, maritime, border inspection, and system), corresponding responsible persons (such as customs officers and maritime dispatchers), and a rollback mapping table (such as customs exceptions rollback to the data declaration stage, and maritime exceptions rollback to the tugboat configuration stage).

[0137] The de-connection processing engine performs in-depth analysis of the exception status code combination bitmap:

[0138] After splitting the bitmap, check which bit is "0" or an error code (e.g., if the first bit is "0", it corresponds to the customs system; if the second bit is "0", it corresponds to the maritime system; if the third bit is "0", it corresponds to the border inspection system; if there is "9", it is marked as a system interaction error). Combined with the specific feedback information returned by each system in step 608 (e.g., customs feedback "ship tonnage declaration does not match", maritime feedback "tugboat power parameters do not meet the standard"), determine the specific cause of the error and classify it into types such as "data error", "parameters do not meet the standard", "document problem" or "system failure".

[0139] Based on the analysis results, an anti-clearance alarm event is generated. The event content includes the vessel's IMO number, abnormal status code map, abnormal source system, error type description, suggested correction instructions (such as "please supplement customs tonnage certificate" or "re-optimize tugboat power parameters"), and processing time limit (such as within 2 hours). The alarm event is pushed to the corresponding responsible department terminal (such as customs terminal or maritime dispatch console) via system message. The vessel status is switched from the current status (such as "under regulatory review") to "anti-clearance final status", and the abnormality reason and switching time are recorded in the status log. According to the abnormality type, the rollback process mapping table is queried, and the vessel data is rolled back to the corresponding processing stage. At the same time, the status identifier of the pilotage operation plan entity is updated to "abnormal suspension", freezing all subsequent processes (such as tugboat dispatch and berthing execution) until the abnormality is handled and resubmitted for approval.

[0140] In this embodiment, the defined customs clearance status threshold rule base determines that the final clearance state requires the customs, maritime, and border inspection authorities to all pass (bitmap "111"), providing a unified judgment standard for multi-department joint supervision, ensuring that the vessel entry and exit procedures comply with all regulatory requirements, and avoiding omissions of key review links; by comparing joint status codes in real time, once full pass is confirmed, the final clearance state is triggered, and the berthing and departure execution permissions are activated simultaneously, reducing manual intervention waiting time, accelerating the process connection from regulatory review to operation execution, and improving port operation efficiency; the activated anti-clearance processing engine can accurately locate the source system of the anomaly (such as customs, maritime) and the specific error type (such as data mismatch, insufficient power), generate targeted correction instructions, ensure that the problem is quickly traced and rectified, and avoid the risk of blind operation caused by ambiguous anomalies; the abnormal vessel is rolled back to the corresponding processing link (such as data declaration, power optimization) and the subsequent process is frozen to prevent erroneous data from flowing into the execution stage, while the "anomaly suspension" status identifier clearly distinguishes the vessels to be processed and maintains the orderliness of the operation queue.

[0141] like Figure 2 As shown, an embodiment of the present invention proposes an integrated smart port logistics and customs clearance service system, comprising:

[0142] The acquisition module is used to receive the input data of the ship pilotage application, generate a pilotage application data entity carrying an undeclared status identifier, parse the status identifier of the pilotage application data entity, and generate a pilotage plan data entity when the status identifier is detected to have been approved.

[0143] The extraction module is used to extract the ship tonnage, berth coordinates and time window parameters of the pilotage plan data entity. Based on the real-time position of the ship, port tidal data and channel congestion index, three dynamic reference points are dynamically determined to construct a dynamic evaluation range including the dynamic reference points.

[0144] The calculation module is used to calculate the morphological feature values ​​of the dynamic assessment range, generate berthing and departure plan adjustment values, and construct structured berthing and departure plan data by combining the extracted parameters; in response to the declaration operation command, the status identifier is updated to the declared status identifier.

[0145] The generation module is used to generate a pilotage operation plan entity and write it into the tugboat configuration pending queue, based on the declared status identifier and the adjusted berthing and departure plan values ​​to correct the pilotage time window.

[0146] The control module is used to poll the tugboat configuration queue, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a structured data packet for ship entry and exit based on the pilotage plan data entity and the pilotage operation plan entity, submit it to the port supervision system to obtain the joint status code; match the joint status code with the preset threshold, and trigger the ship state machine to switch to the customs clearance final state or the anti-customs clearance final state.

[0147] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A smart port logistics and customs clearance integrated service method, characterized in that, The method includes: Receive pilotage application input data and generate a pilotage application data entity carrying an undeclared status identifier; Parse the status identifier of the pilotage application data entity. When a change in the status identifier to "approved" is detected, generate the pilotage plan data entity. The system extracts the vessel's approved deadweight tonnage, berth coordinates, and planned time window parameters from the pilotage plan data entity. It then acquires the vessel's latitude and longitude coordinates and speed vector in real time via the Automatic Identification System (AIS), and calculates the vessel's expected spatiotemporal position at the channel entrance using channel hydrological topology data provided by the electronic chart service interface. Based on the port tide forecast service, it obtains the tide height and gradient data within the planned time window. Through the port traffic flow monitoring platform, it analyzes the channel's time-segmented congestion index in real time and generates congestion impact weighting coefficients. Based on the vessel's expected arrival position, tide gradient data, and congestion impact weighting coefficients, it generates three dynamic position reference points. Using these three dynamic position reference points as core anchor points, it constructs a dynamic assessment range covering key stages of the vessel's port entry path and marks this dynamic assessment range as awaiting feature analysis. Spatial topology analysis is performed on the dynamic assessment range to extract the relative bearing relationships and distance sequences between reference points in the key stages of the ship's port entry path; the rate of change of the route turning angle is calculated based on the relative bearing relationships, and a quantitative index of the path morphology is generated by combining the distance sequences; the ship's rated deadweight tonnage, tide level change gradient data, and path morphology quantitative index are used to generate the ship's maneuvering inertia compensation coefficient; the berthing and departure time offsets and berth fine-tuning coordinates are calculated and generated based on the product of the congestion impact weighting coefficient and the maneuvering inertia compensation coefficient, forming the berthing and departure plan adjustment values; the ship's tonnage, berth coordinates, time window parameters, and berthing and departure plan adjustment values ​​are integrated to construct structured berthing and departure plan data containing corrected berthing coordinates, departure coordinates, and time offsets; in response to the electronic declaration command triggered by the port operator, the associated status identifier is updated to the declared status identifier, and the berthing and departure plan execution queue is activated; Based on the declared status identifier, the pilotage time window is corrected by adjusting the berthing and departure plan values, a pilotage operation plan entity is generated and written into the tugboat configuration pending queue; Poll the tugboat configuration pending queue, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a vessel entry / exit structured data packet based on the pilotage plan data entity and the pilotage operation plan entity, submit it to the port supervision system to obtain the joint status code; match the joint status code with the preset threshold to trigger the vessel state machine to switch to the customs clearance final state or the anti-customs clearance final state.

2. The integrated smart port logistics and customs clearance service method according to claim 1, characterized in that, Receive pilotage application input data and generate a pilotage application data entity carrying an undeclared status identifier, including: Receive encrypted pilotage request messages sent by the ship agency system through the preset electronic data exchange interface, and perform message decryption and format verification operations; Extract predefined key fields from the verified message, including the ship identification number, ship type classification code, and application timestamp; Based on the ship identification number, a real-time query request is initiated to the ship basic database to obtain the associated ship basic file, and the ship's main dimensional parameters, design draft and approved deadweight tonnage in the file are parsed to generate a structured set of additional parameters. The predefined key fields are mapped and concatenated with the structured additional parameter set at the field level to form a complete ship attribute dataset; Assign a globally unique application number to the complete ship attribute dataset, inject an undeclared status identifier, and construct a pilotage application data entity with static ship attributes, dynamic application attributes, and status identifiers.

3. The integrated smart port logistics and customs clearance service method according to claim 2, characterized in that, Parse the status identifier of the pilotage application data entity. When a change in the status identifier to "approved" is detected, generate a pilotage plan data entity, including: Real-time capture of approval result events sent by the port approval system via asynchronous message notification; When the approval result event carries an approval approval flag, extract the ship's main dimension parameters, the geographical coordinates of the applied berth, and the planned berthing and departure time intervals from the persistently stored pilotage application data entity; Based on the berth adaptation algorithm in the port scheduling rule base, as well as the ship's main dimensional parameters and minimum safe distance threshold, the precise coordinates and azimuth of the adapted berth are generated. Synchronously query the tide forecast service interface, obtain the tide height change sequence based on the planned berthing and departure time interval, and calculate the tide level correction amount in combination with the ship's design draft; By integrating precise coordinates, azimuth, tide correction, and planned berthing and departure time intervals, a pilotage plan data entity containing vessel tonnage, berth coordinates, and time window parameters is constructed, and the original application number is associated with and injected with a status identifier pending spatial evaluation.

4. The integrated smart port logistics and customs clearance service method according to claim 3, characterized in that, Based on the declared status identifier, the pilotage time window is corrected by adjusting the berthing and departure plan values, a pilotage operation plan entity is generated, and written to the tugboat configuration pending queue, including: Responding to the activation event of the declared status identifier in the berthing and departure plan execution queue, extract the time offset and berth fine-tuning coordinates from the structured berthing and departure plan data; Based on the pilotage time window dynamic correction algorithm, input the original pilotage time window parameters, tidal level change gradient data and time offset, and calculate and generate the pilotage operation time interval after dual correction of tide and congestion. Based on the berth coordinates fine-tuning, the pilotage plan data entity is updated with berth coordinates. The corrected pilotage operation time interval, vessel tonnage, and maneuvering inertia compensation coefficient are then integrated to generate a pilotage operation plan entity that includes key nodes of the pilotage path and power demand parameters. Calculate the minimum total thrust required for the tugboat based on the ship tonnage classification rules and power demand parameters; Inject the pilotage operation plan entity into the tugboat configuration pending queue, and configure the queue priority label according to the urgency of the time window.

5. The integrated smart port logistics and customs clearance service method according to claim 4, characterized in that, The system polls the tugboat configuration queue, responds to tugboat configuration completion commands, adapts tugboat power parameters, and updates the status, including: Start the scheduled task polling engine to scan the tugboat configuration pending queue and capture the configuration completion event command returned by the tugboat scheduling system; The tractor number group and initial power parameter set assigned in the parsing instruction are dynamically adapted to the engine based on the tractor power. Based on the ship maneuvering inertia compensation coefficient, route turning angle change rate, and minimum total thrust in the pilotage operation plan entity, a set of dynamic optimization parameters for the tugboat group is generated through a dynamic parameter adaptation matrix. Inject the tugboat number group and the optimized parameter set into the pilotage operation plan entity, and update its status identifier to the ready state.

6. The integrated smart port logistics and customs clearance service method according to claim 5, characterized in that, Based on the pilotage plan data entity and the pilotage operation plan entity, a structured data packet for vessel entry and exit is generated and submitted to the port supervision system to obtain a joint status code, including: Extract the ship's approved deadweight tonnage, berth coordinates, and basic ship attributes from the pilotage plan data entity; Simultaneously acquire the revised pilotage operation time interval, tugboat number group, power optimization parameter set, and key nodes of the pilotage path from the pilotage operation plan entity; According to the port data specification verifier, the basic attributes of the ship, berth coordinates, pilotage time interval, and tugboat configuration data are reorganized and converted in accordance with the customs data element standard. Inject real-time location and trajectory traceability identifiers for ships and digital fingerprints for tugboat power to construct a customs structured data package containing ship static attributes, dynamic operating parameters, and auxiliary equipment information; Data packets are submitted to the port supervision system through an encrypted data channel, and an asynchronous status code listening service is initiated to capture and parse the combined status code bitmap returned by the customs system, maritime system, and border inspection system in real time.

7. The integrated smart port logistics and customs clearance service method according to claim 6, characterized in that, Matching the joint status code with a preset threshold triggers the ship's state machine to switch to either the final settlement state or the reverse settlement state, including: According to the preset customs clearance status threshold rule base, the rule base defines that the final state of customs clearance must meet the following conditions in the status code combination bitmap: customs release code = 1, maritime permit code = 1, and border inspection verification code = 1. The system compares the combined state code bitmap of the vessel to be processed with the threshold rules in real time. When all bitmap values ​​are 1, the system triggers the vessel state machine to switch to the final state. When a bitmap value of 0 or an anomaly code is detected, the de-connection processing engine is activated to perform the following operations: The system that parses the abnormal status code and the error type is used to generate an anti-clearance alarm event containing correction instructions. The ship's state machine is switched to the anti-clearance final state and rolled back to the corresponding processing stage. The status identifier is updated to the abnormal suspended state and the subsequent process is frozen.

8. A smart port logistics and customs clearance integrated service system, characterized in that: The system is used to perform the method as described in any one of claims 1 to 6, comprising: The acquisition module is used to receive the input data of the ship pilotage application, generate a pilotage application data entity carrying an undeclared status identifier, parse the status identifier of the pilotage application data entity, and generate a pilotage plan data entity when the status identifier is detected to have been approved. The extraction module is used to extract the ship tonnage, berth coordinates and time window parameters of the pilotage plan data entity. Based on the real-time position of the ship, port tidal data and channel congestion index, three dynamic reference points are dynamically determined to construct a dynamic evaluation range including the dynamic reference points. The calculation module is used to calculate the morphological characteristic values ​​of the dynamic evaluation range, generate berthing and departure plan adjustment values, and construct structured berthing and departure plan data by combining the ship's tonnage, berth coordinates, and time window parameters; and respond to the declaration operation command to update the status identifier to the declared status identifier. The generation module is used to generate a pilotage operation plan entity and write it into the tugboat configuration pending queue, based on the declared status identifier and the adjusted berthing and departure plan values ​​to correct the pilotage time window. The control module is used to poll the tugboat configuration queue, respond to the tugboat configuration completion command, adapt the tugboat power parameters and update the status; generate a structured data packet for ship entry and exit based on the pilotage plan data entity and the pilotage operation plan entity, submit it to the port supervision system to obtain the joint status code; match the joint status code with the preset threshold, and trigger the ship state machine to switch to the customs clearance final state or the anti-customs clearance final state.

Images