A method and system for collaborative management of port engineering full life cycle data

Abstract

This invention discloses a collaborative management method and system for port engineering lifecycle data, belonging to the field of port engineering digital management technology. The method includes: connecting a port management platform with multi-source data interfaces, updating layer libraries and databases; developing a management engine array, interpreting acquired tasks, matching and reconstructing layers, and writing them into the database to determine a task scenario model; visualizing the task scenario model, and determining management strategies based on multi-threaded sub-stages and greedy decisions for extended tasks. This invention solves the technical problems in port engineering lifecycle management where traditional data management methods struggle to achieve full-process data synchronization and deep collaboration, leading to incomplete data integration, inaccurate task responses, and difficulty in supporting efficient decision-making and precise management. It achieves efficient collaborative management of port engineering lifecycle data, ensuring synchronized data updates and deep integration, accurately responding to tasks, supporting scientific decision-making, and improving management efficiency.

Description

Technical Field

[0001] This invention relates to the field of digital management technology for port engineering, and in particular to a collaborative management method and system for data throughout the entire lifecycle of port engineering. Background Technology

[0002] In port engineering construction and operation, product lifecycle management is crucial for ensuring the efficiency, safety, and sustainability of the project, requiring precise and coordinated data throughout the entire process. However, under current technology, data from different stages of port engineering is scattered, and multi-source heterogeneous data is difficult to integrate. Traditional management methods cannot adapt to the needs of the entire lifecycle, resulting in asynchronous data updates, inaccurate task responses, and difficulty in supporting full-process decision-making and control. The lack of a unified collaborative management mechanism in existing technologies hinders the effective integration of data across the entire lifecycle, leading to incomplete data integration, difficulties in implementing management decisions, and an inability to meet the precise management needs of the entire port engineering lifecycle. Summary of the Invention

[0003] This application provides a collaborative management method and system for port engineering lifecycle data, which solves the technical problem that traditional data management methods in port engineering lifecycle management are unable to achieve full-process data synchronization and deep collaboration, resulting in incomplete data integration, inaccurate task response, and difficulty in supporting efficient decision-making and precise management.

[0004] The first aspect of this application provides a collaborative management method for port engineering lifecycle data. The method includes: establishing a connection between a port management platform and a multi-source data interface; updating the layer library and database; developing a management engine array as an embedded plugin for the port management platform; the platform acquires port management tasks, triggers the management engine array to interpret the tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines a task scenario model; visualizing the task scenario model in the platform's display module; performing directional management decisions based on port management tasks; and determining a port management strategy, wherein the directional management decisions are greedy decisions based on multi-threaded sub-tasks and extended tasks of task decomposition; and storing the generated data management sequence on the blockchain and introducing block permission authentication.

[0005] The second aspect of this application provides a collaborative management system for port engineering lifecycle data. The system includes: a platform interface connection construction module for establishing connections between a port management platform and multi-source data interfaces, and updating layer libraries and databases; a task scenario model acquisition module for developing a management engine array as an embedded plugin for the port management platform, whereby the platform acquires port management tasks, triggers the management engine array to interpret tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines the task scenario model; a port management strategy acquisition module for visualizing the task scenario model on the platform display module, performing targeted management decisions based on port management tasks, and determining port management strategies, wherein the targeted management decisions are greedy decisions based on multi-threaded sub-tasks and extended tasks of task decomposition; and a block permission authentication introduction module, whereby the generated data management sequence is stored on the blockchain and block permission authentication is introduced.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0007] This application establishes a port engineering management platform that connects to multiple data sources and embeds an scalable management engine array. It interprets port management tasks, reconstructs execution layers, and writes data to define task scenario models. After visualization, management strategies are determined based on greedy decision-making. Combined with multi-dimensional strategy execution information distribution and secure electronic fence interaction, it achieves collaborative data management throughout the entire lifecycle of port engineering projects. This makes data management more efficient and accurate, supports decision-making and control throughout the entire port engineering process, and achieves efficient collaborative management of port engineering data throughout its lifecycle. It ensures synchronized data updates and deep integration, accurately responds to tasks, supports scientific decision-making, and improves management quality and efficiency. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating a collaborative management method for port engineering lifecycle data provided in an embodiment of this application.

[0010] Figure 2 This is a schematic diagram of the structure of a collaborative management system for the entire lifecycle data of port engineering provided in an embodiment of this application.

[0011] Figure labeling: Platform interface connection construction module 1, task scenario model acquisition module 2, port management strategy acquisition module 3, block permission authentication introduction module 4. Detailed Implementation

[0012] This application provides a collaborative management method and system for port engineering lifecycle data, which solves the technical problem that traditional data management methods in port engineering lifecycle management are unable to achieve full-process data synchronization and deep collaboration, resulting in incomplete data integration, inaccurate task response, and difficulty in supporting efficient decision-making and precise management.

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0014] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0015] Example 1, as Figure 1 As shown, a collaborative management method for port engineering lifecycle data is provided, wherein the method includes:

[0016] Step A100: Establish a connection between the port management platform and the multi-source data interface, and update the layer library and database.

[0017] In this embodiment, the port management platform is the central system for collaborative data management throughout the entire lifecycle of port engineering. It integrates multi-source data interfaces, a management engine array, and a visualization module, undertaking data access, task scheduling, and decision output functions. The layer library is the data carrier in the spatial dimension, integrating engineering BIM layers and GIS layers. The database adopts a distributed storage library cluster architecture, decomposed into data classes and rule classes. The data classes store dynamic information of the port throughout its entire lifecycle, while the rule classes encapsulate management strategies such as task interpretation logic and data verification rules.

[0018] Specifically, the entire lifecycle of port engineering involves multiple stages, including design, construction, operation, and maintenance. Data from each stage is stored across heterogeneous media such as BIM models, GIS systems, equipment sensors (e.g., crane vibration sensors, transportation equipment energy consumption modules), environmental monitoring stations (wind speed and humidity monitoring), ship scheduling systems, and equipment inspection platforms. The port management platform needs to construct a multi-source data interface system and develop standardized interfaces for different data types.

[0019] For BIM layers, the IFC protocol parsing module extracts the geometric parameters, component assembly relationships, and material properties of the 3D model. For GIS layers, the WMS / WFS protocol is used to convert spatial data such as geographic coordinates, terrain vectors, and shoreline boundaries. For equipment sensors, Modbus and MQTT protocols are used to capture real-time parameters such as crane vibration frequency and transportation equipment energy consumption. For systems such as ship scheduling and environmental monitoring, RESTful APIs are used to obtain information such as dynamic ship berths and port weather changes. Simultaneously, the interface incorporates built-in data preprocessing logic, automatically aligning timestamps from multiple data sources, filtering outliers such as sensor mutations, and supporting modular expansion. When new intelligent monitoring equipment or management systems are added to the port, they can be quickly integrated into the interface system, ensuring continuous data aggregation throughout the entire lifecycle.

[0020] Next, using communication protocols such as HTTPS and MQTT, the port management platform establishes stable connections with each interface, and marks the transmitted data according to data type + timestamp rules. For the layer library, BIM layer data is converted into a format and then overlaid and merged with GIS layer data to form a set of two-dimensional / three-dimensional layers containing the port's spatial layout and facility distribution; for the database, i.e., the distributed database cluster, dynamic data such as project progress and quality inspection are classified into the data category, while task interpretation rules and data verification logic are classified into the rule category.

[0021] Finally, it is clarified that the layer library includes engineering BIM and GIS layers, and the database is a distributed storage cluster of databases containing data types and rule types. Based on the port update data obtained from the multi-source data interface interaction, the layer library and the database are updated synchronously. The specific steps are explained in detail in A110-A130.

[0022] Through multi-interface linkage and dynamic synchronization, efficient aggregation of multi-source data throughout the port's entire lifecycle has been achieved, laying a unified and accurate data foundation for subsequent management tasks.

[0023] Step A200: By developing a management engine array as an embedded plugin for the port management platform, the platform obtains port management tasks, triggers the management engine array to interpret the tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines the task scenario model.

[0024] In this embodiment, the management engine array is an embedded plugin of the port management platform, possessing scalability and containing at least three management engines. Task interpretation is used to determine task-oriented elements for matching and reconstructing layers and data, resulting in a port model that fits the task derivation and is free of redundancy.

[0025] Optionally, the management engine array, as an embedded plugin of the port management platform, has the core value of achieving efficient processing of port management tasks through modular division of labor. The specific process and logic are as follows:

[0026] From a functional perspective, the management engine array, as an embedded plugin, not only relies on the platform's multi-source data interfaces, layer library, and database resources, but also adapts to different management scenarios through its extended features, providing modular support for full lifecycle task processing.

[0027] After the platform acquires a port management task, it triggers the collaborative operation of the management engine array. Task interpretation is the primary step, led by the first management engine: based on standardized element terms, the task is semantically broken down and transformed. For example, if the task is "maintenance of piling vessel equipment in Terminal B," the interpretation will extract task-oriented elements such as spatial elements (Terminal B), entity elements (piling vessel), and operational elements (maintenance), filtering out redundant information unrelated to the task, such as vessel data from other areas. This interpretation process does not involve complex decision-making; its core is to clarify which layers and data support the task requires, providing accurate targets for subsequent matching. This ensures that the final port model (a scenario model combining layers and data) contains only elements strongly related to the task, achieving a perfect match between task derivation and no redundancy.

[0028] After the task-oriented elements are clarified, the second and third management engines take turns processing: the second management engine is triggered to identify the task package and match and determine at least one target layer, filter out the valid target layers, and if there is more than one target layer, perform spatial phase-based overlay reconstruction to complete the task matching reconstruction based on the layer library. The specific steps are explained in detail in A230-A250.

[0029] The third management engine is triggered to identify the task package and call the database to determine the target data containing the first rule and the second data. The second data is reorganized into the second task data according to the task orientation. The first rule and the second task data are written into the valid target layer to determine the task scenario model. The task matching and writing based on the database is completed. The specific steps are explained in detail in A260-A280.

[0030] Step A300: Visualize the task scenario model in the platform display module, execute directional management decisions based on port management tasks, and determine the port management strategy. The directional management decision is a greedy decision based on multi-threaded sub-tasks and extended tasks of task decomposition.

[0031] In this embodiment, the platform display module is a functional module in the port management platform responsible for the visualization of task scenario models. It can render GIS layers, BIM models, management rules and task data in layers according to their relationships, and embed interactive response logic to support operations such as zooming, panning, and timeline sliding, transforming complex task scenarios into intuitive and perceptible visual content.

[0032] In one embodiment of this application, when the platform display module visualizes the task scenario model, it first needs to parse the underlying structure of the model and extract the spatial data, rule information, and task data. Taking the scenario model of the monthly safety assessment of the piling vessel in area B of the wharf as an example, the module will read the three-dimensional geometric parameters of the piling vessel in the BIM layer, such as the pile frame height of 28 meters and the pile hammer diameter of 1.5 meters; the precise geographic coordinate range of the GIS layer; and identify the associated first rule, such as the prohibition of unrelated vessels from entering within a 50-meter working radius in the "Safety Specifications", and the second task data, such as the vibration frequency exceeding the limit twice in week 3 and crossing the boundary once in week 4, to provide complete data support for subsequent rendering.

[0033] Based on the analysis results, the platform display module then initiates a layered rendering mechanism: using satellite imagery from the GIS layer as a base, it overlays the 3D model of the piling vessel from the BIM layer, employing metallic texture rendering to highlight the structural details of the equipment; for the first rule, a 50-meter work boundary circle is drawn on the GIS layer using dynamic red dashed lines, with a rule description indicating that entry is prohibited; for the second task data, color coding is performed according to the type of exceedance and time, with vibration exceedance points marked with orange dots and boundary crossing points marked with red triangles, and each marked point is accompanied by floating text displaying the specific value, such as vibration frequency: 50Hz.

[0034] Meanwhile, to enhance the usability of visualization, the platform's display module incorporates interactive response logic: it supports mouse wheel zoom (zooming in to the details of the pile hammer to view wear parameters), drag-and-pan (panning to the edge of the restricted area to observe if a ship is approaching), and timeline sliding (dragging the slider on the timeline switches between weekly data views; for example, sliding from week 1 to week 4 shows the increase or decrease in the number of orange dots). When a user clicks on a marker, the module retrieves the associated database record and displays a pop-up window showing the complete data chain of that event.

[0035] Next, the rendered content of each layer is integrated and presented under a unified spatial coordinate system: the 3D model of the piling vessel is precisely anchored to the actual working position of the GIS layer, the red forbidden circle completely encloses the area around the equipment, and the color markers are distributed on the working trajectory in chronological order, forming an integrated view of spatial entities, regular boundaries and dynamic data.

[0036] Finally, directional management decisions based on port management tasks are executed, including decomposing port management tasks into management task subsets at the smallest task unit and extending them into extended task subsets according to task-oriented deduction. The two are then used as task clusters to perform multi-threaded parallel decision-making in the task scenario model to determine the port management strategy. The specific steps are explained in detail in A310-A330.

[0037] By analyzing the model structure, rendering information in layers, and adapting interactive operations, the spatial relationships, management rules, and task data of the task scenario model are transformed into intuitive and perceptible visual content, providing clear information support for port management decisions.

[0038] Step A400: The generated data management sequence is stored on the blockchain and block permission authentication is introduced.

[0039] Specifically, during the data management sequence generation phase, the flow of data throughout the entire lifecycle of the port project needs to be structured and recorded, covering key information from each stage of data acquisition, processing, and application. For example, during hydrological data acquisition, the sensor number, acquisition time, raw values, and preprocessing algorithm are recorded; during the task interpretation phase, the feature extraction results, interpretation timestamps, and execution engine IDs are recorded. These records are integrated into a data management sequence in chronological order, with each sequence containing a unique identifier (UUID) to ensure traceability.

[0040] The platform's built-in consortium blockchain nodes initiate the on-chain evidence storage process, employing the PBFT consensus mechanism to handle data management sequences. First, each sequence is hashed using the SHA-256 algorithm to generate a 64-bit hash value. Each hash value uniquely corresponds to the sequence content; changes to the content are reflected in the hash value. Then, the hash value, sequence UUID, and on-chain time (accurate to milliseconds) are packaged into a block. The block size is controlled within 1MB, and each block includes the hash value of the previous block to form a chain connection. The header of block 100 references the hash of block 99, and the header of block 101 references the hash of block 100. This chain structure ensures the immutability of the blocks. Each node in the consortium blockchain (port operation center, supervision unit, construction party) synchronously stores a copy of the block, achieving distributed evidence storage.

[0041] Block access authentication is implemented based on data security level classification, dividing blocks into three levels: Level 1 (public) contains basic port geographic information, Level 2 (restricted) contains equipment operation data, and Level 3 (confidential) contains core geological exploration data. Access control policies are configured for each level of block: Level 1 blocks use symmetric key encryption, with the key embedded in all nodes and obtainable by any authorized user through the platform interface; Level 2 blocks use asymmetric encryption, decrypted only by operations management personnel (such as equipment supervisors) holding the private key, with the public key used for encrypted data transmission; Level 3 blocks require multi-factor authentication, requiring the user to submit a digital certificate (including job identifier) ​​and a dynamic verification code (updated every 30 seconds), and access is only granted after verification by at least three nodes on the consortium blockchain. Access levels are bound to block hashes and stored in the blockchain's access control layer. Changes require a smart contract-initiated vote, taking effect only after approval by more than two-thirds of the nodes.

[0042] By using structured data management sequences, on-chain notarization on the consortium blockchain, and hierarchical access authentication, the system achieves immutability, full traceability, and refined access control throughout the data flow process, thereby enhancing the security and reliability of port engineering data management.

[0043] Furthermore, step A100 in the method provided in this application embodiment includes:

[0044] A110: The layer library includes at least engineering BIM layers and GIS layers, and the database includes a distributed storage cluster on the platform, containing data classes and rule classes.

[0045] A120: Determine port update data based on the interaction with the multi-source data interface.

[0046] A130: Based on the port update data, synchronize the layer library with the database.

[0047] In this embodiment, BIM stands for Building Information Modeling. In port engineering, it is represented by a three-dimensional design model containing components such as wharf structures, pile foundations, and abutments, along with detailed attribute information such as material specifications, dimensional parameters, and design loads of the load-bearing components. It is a digital representation of the spatial entities and attributes of port engineering projects. GIS stands for Geographic Information System, used to construct a three-dimensional geospatial scene of the port engineering construction area, integrating geographic information such as satellite remote sensing imagery, UAV oblique photography, and orthophotos.

[0048] Specifically, throughout the entire lifecycle of a port project, dynamic data updates are the fundamental support for management decisions. First, the structure of the data carrier is clearly defined: the layer library focuses on the spatial dimension, integrating at least engineering BIM layers and GIS layers. The BIM layer carries 3D model data such as wharf structure and equipment layout, accurately depicting the geometric parameters and component attributes of the engineering entity; the GIS layer covers port geographic information, including spatial elements such as shoreline coordinates, terrain vectors, and water boundaries. The database uses a platform-distributed database cluster as its carrier, broken down into data classes and rule classes: the data class stores dynamic information throughout the port's entire lifecycle, such as time-series data on construction progress, equipment energy consumption, and vessel scheduling; the rule class encapsulates management strategies such as task interpretation logic and data verification rules, providing algorithmic support for subsequent task processing.

[0049] The multi-source data interface acts as a bridge for data flow, connecting to ports such as the construction management system, equipment monitoring module, and ship AIS system. When port engineering undergoes status changes, such as updates to the installation progress of wharf components, ship position shifts, or fluctuations in equipment parameters, the interface follows communication protocols such as MQTT and HTTP to capture these port update data in real time. The data parsing module then extracts key information, including the component installation completion rate associated with the BIM layer, the ship's latitude and longitude corresponding to the GIS layer, and energy consumption values ​​to be added to the database data.

[0050] Next, based on the extracted port update data, the synchronous update process is initiated: the database stores incremental information in a time-series chain, attaching a timestamp to each update data entry to construct a historical trajectory of time-state correlation. For example, equipment energy consumption data is recorded hourly, forming a continuous energy consumption curve. If the rule class is adjusted due to management needs, such as optimizing task interpretation rules, the logic algorithm is updated via script. Layer library synchronous response: BIM layers mark the installation / non-installation status of components according to the construction progress, and GIS layers dynamically refresh their spatial distribution based on ship positioning data, ensuring that information such as ship location and berth occupancy is synchronized with the port's actual situation. For example, when a ship docks, the GIS layer updates its location markers in real time, and the BIM layer synchronously associates it with the berth's usage status, achieving instant matching of spatial data and physical status.

[0051] By defining the data carrier structure, capturing multi-source updated data in real time, and driving storage and visualization synchronization according to rules, the spatial and attribute data of the entire life cycle of port engineering can be dynamically integrated, laying a solid multi-dimensional and highly timely data foundation for the accurate interpretation and execution of subsequent management tasks.

[0052] Furthermore, step A200 in the method provided in this application embodiment includes:

[0053] A210: The management engine array is scalable.

[0054] A220: Wherein, the management engine array includes at least:

[0055] The first management engine performs task element interpretation, using element terms based on dimensional uniformity as the interpretation standard; the second management engine performs layer reconstruction, establishing a connection with the layer library; the third management engine performs rule writing and data writing, establishing a connection with the database.

[0056] Optionally, firstly, the management engine array, as an embedded plugin of the port management platform, is scalable in that it can flexibly add new engines to adapt to more task types according to the management needs of the entire life cycle of port engineering. For example, when a new environmental risk assessment task is added, a fourth management engine can be added to handle the interpretation and analysis of environmental data, ensuring the system's adaptability to complex tasks. Similarly, acquiring more types of tasks allows for the addition of corresponding management engines.

[0057] The first management engine focuses on task element interpretation, constructing an interpretation framework based on standardized element terms. Specific steps are detailed in A221-A223. After a port management task enters the port management platform, for example, the maintenance scheduling of equipment in Terminal A, the engine first performs semantic decomposition, extracting core elements such as area identifier, equipment type, task type, and time window. Then, it performs conversion by referring to a pre-set element terminology library. For example, the area identifier is standardized as a 6-digit numeric code, and the equipment type is limited to standardized names such as crane and loader, ultimately forming a structured set of task elements. For instance, Terminal A is converted to 001002, and the corresponding maintenance task type is 03, ensuring that task descriptions from different sources are parsed uniformly.

[0058] The second management engine establishes a real-time connection with the layer library, undertaking the responsibility of layer reconstruction. After acquiring the task element set, the engine searches the layer library based on the spatial identifiers within the elements, such as area 001002, matching the corresponding BIM layer (3D model layer of equipment in area A of the dock) and GIS layer (geographic coordinate layer of this area), forming a target layer set. Subsequently, a task relevance algorithm filters out redundant layers irrelevant to the task, such as the GIS layer of a distant waterway, retaining only valid target layers. For example, for equipment maintenance tasks, only the BIM equipment layer and the precise GIS coordinate layer of that area are retained, focusing on core spatial data for subsequent scene construction.

[0059] The third management engine is deeply integrated with the database, executing rule and data writing. For the decoded task element set, the engine first calls the matching management rules from the database's rule class, such as safety operation procedures for equipment maintenance and scheduling priority rules. Then, it writes the specific data in the task elements (such as maintenance start time and responsible team) into the corresponding table entries in the data class. For example, it writes "Maintenance starts at 09:00 on 2025-07-15, Team = A" into the equipment maintenance data table and associates it with the rule in the rule class that "Equipment status must be checked before maintenance," ensuring that the task data and management rules are linked in the database.

[0060] By constructing a scalable engine array, and performing task interpretation, layer matching, and data interaction according to division of labor, port management tasks can be transformed from unstructured descriptions into a collaborative association of structured elements, spatial layers, and database records, providing a standardized and modular processing path for the accurate construction of task scenario models.

[0061] Furthermore, step A220 in the method provided in this application embodiment includes:

[0062] A221: The port management tasks include active management tasks and passive management tasks. The active management tasks are task classes uploaded by the platform, and the passive management tasks are feedback task classes generated based on the layer library and the database.

[0063] A222: Trigger the first management engine to perform semantic interpretation and element term conversion on the port management task to determine the task element set.

[0064] A223: Temporarily encapsulate the set of task elements to determine the task package.

[0065] Specifically, port management tasks are categorized into proactive and reactive management tasks based on their source. Proactive management tasks are uploaded by those skilled in the art through the port management platform, such as dispatching three material ships to unload at Terminal C on July 15, 2025—these are manually initiated operational instructions. Reactive management tasks, on the other hand, are automatically generated by the system based on the real-time status of the layer library and database. For example, when the GIS layer shows that a ship has continuously deviated from its planned route for 10 minutes, or when the energy consumption of equipment in the database exceeds the threshold, feedback tasks such as ship route correction and equipment energy consumption checks are automatically triggered.

[0066] When a task enters the port management platform, the first management engine is triggered, initiating a semantic interpretation and element conversion process. Using standardized element terms as the benchmark, the engine first breaks down the task's natural language description. For example, for an active task like dispatching three material ships to unload at Terminal C on July 15, 2025, the core elements are: Time = 2025-07-15, Number of Ships = 3, Ship Type = Material Ship, Target Area = Terminal C, and Task Type = Unloading. For a passive task like equipment energy consumption exceeding a threshold, the elements are: Equipment ID = CR005, Anomaly Type = Energy Exceeding Limit, and Trigger Time = 2025-07-15 08:30. Subsequently, the engine matches and converts these elements against a pre-defined element term library. For instance, Terminal C corresponds to the term area code = 003, and unloading corresponds to the task code = 02, forming a structured set of task elements to ensure consistent descriptions for different task types.

[0067] Furthermore, the pre-defined element terminology library should be constructed based on the core elements of the port engineering lifecycle management tasks, combined with the principle of unified dimensionality and the needs of actual management scenarios, and defined in a standardized manner step by step:

[0068] Step a: Identify the core element types of port management tasks. Based on the classification of proactive management tasks (platform-uploaded tasks) and reactive management tasks (feedback tasks), extract the common key elements of the two types of tasks, such as spatial elements (area identifiers, berth numbers, etc.), physical elements (equipment type, vessel type, etc.), temporal elements (task start and end times, cycle, etc.), operational elements (task types such as scheduling, maintenance, and early warning), and status elements (normal, abnormal, pending, etc.).

[0069] Step b: Standardize the definition of each element. Those skilled in the art can refer to port engineering industry standards and data management requirements to unify the names, coding rules, dimensions, and value ranges of elements: for example, the area identifier in spatial elements uses a 6-digit code, with the first 3 digits representing the port area and the last 3 digits representing the specific area; the equipment type in physical elements is limited to standardized names such as cranes, loaders, and piling vessels; and the time element uniformly adopts the YYYY-MM-DDHH:MM:SS format.

[0070] Step c: Supplement specific elements based on scenarios such as port construction vessel and machinery monitoring. This includes incorporating equipment identification elements such as vessel MMSI codes and Beidou positioning terminal IDs, as well as safety management elements such as electronic fence area codes and early warning levels (Level 1 and Level 2), to ensure that the terminology database covers the specific task requirements of the construction and operation phases.

[0071] Step d: Improve the terminology library through dynamic iteration. For new management tasks, such as scheduling of new equipment and early warning of special working conditions, supplement the corresponding element terms in real time to maintain adaptability to the needs of port engineering management. Ultimately, a standardized terminology set with unified dimensions and covering all task elements throughout the entire lifecycle will be formed, providing a consistent benchmark for task interpretation.

[0072] After the task feature set is generated, it is temporarily packaged to form a task package. The packaging process adds a unique identifier and timestamp to the feature set. For example, an active task package is marked TK-20250715-001, containing all converted feature codes and a summary of the original task description; a passive task package is marked FB-20250715-001, associated with the layer anomaly data ID that triggered its generation and the database threshold record. The packaged task packages have a unified format and can be directly recognized and called by subsequent second and third management engines.

[0073] By differentiating task types, interpreting and converting them using unified element terms, and encapsulating them into standardized task packages, port management tasks can overcome the format confusion caused by differences in sources. This provides a consistent and complete processing unit for subsequent layer reconstruction and data writing, ensuring efficient connection of task processing throughout the entire process.

[0074] Furthermore, step A200 in the method provided in this application embodiment includes:

[0075] A230: Trigger the second management engine to identify the task package and perform layer matching to determine the target layer, wherein the target layer contains at least one.

[0076] A240: Perform task relevance filtering on the target layer to determine the valid target layer.

[0077] A250: Wherein, if the number of target layers is greater than 1, perform spatial phase-based overlay reconstruction on the effective target layers.

[0078] Specifically, after a task package enters the processing flow, the second management engine is triggered. It first parses the structured elements in the task package, such as spatial identifiers and entity types, and then uses these as indexes to retrieve matching layers from the layer library. For example, if the task package contains elements related to the maintenance of container cranes in Terminal C, the engine will match the BIM 3D model layer of the container cranes in Terminal C (including equipment structural parameters) with the GIS geographic coordinate layer of that area (including precise latitude and longitude). These two layers together constitute the target layer, satisfying at least one of the requirements.

[0079] Next, based on task orientation, the target layer is subjected to relevance filtering, and the correlation between layer attributes and task elements is compared using an element matching algorithm:

[0080] The feature matching algorithm first extracts key task elements from the task package. For example, in the crane maintenance task, the core comparison benchmarks are extracted as follows: maintenance object = crane, spatial range = wharf C area, and task type = equipment maintenance. Then, the algorithm analyzes the attribute information of each target layer: the BIM crane layer's attributes include object type = crane, area = wharf C area, and layer purpose = equipment structural detail display; the GIS precise coordinate layer's attributes are spatial range = local 200m × 100m area of ​​wharf C area, layer precision = centimeter level, and layer purpose = equipment positioning; the port area overall aerial photography GIS layer's attributes are spatial range = entire port area 5 square kilometers, layer precision = meter level, and layer purpose = macro layout display.

[0081] Next, the algorithm assigns weights to task elements based on their relevance to the maintenance task: maintenance object matching accounts for 0.4, spatial range matching accounts for 0.3, and layer usage adaptability accounts for 0.3, with a total weight of 1. Then, the relevance of each layer to the task elements is calculated: the BIM bridge crane layer scores 1 for all three aspects (complete object type matching, complete spatial range matching, and direct service to maintenance), with a relevance of 0.4×1 + 0.3×1 + 0.3×1 = 1.0; the GIS precise coordinate layer scores 0.9 for partial spatial range matching and 0.8 for usage supporting positioning requirements, with a relevance of 0.4×0 (non-bridge crane objects) + 0.3×0.9 + 0.3×0.8 = 0.51; the port area overall aerial photography GIS layer scores 0.2 for spatial range far exceeding requirements and 0.1 for usage with no direct connection to maintenance, with a relevance of 0.4×0 + 0.3×0.2 + 0.3×0.1 = 0.09.

[0082] Finally, the algorithm sets a correlation threshold of 0.5, retains layers with a correlation of ≥0.5 (BIM bridge crane layer 1.0, GIS precise coordinate layer 0.51), and removes the overall port area aerial GIS layer 0.09 which is below the threshold. This completes the correlation filtering and forms effective target layers containing only core information.

[0083] If there are more than one valid target layer, such as the BIM crane layer and the GIS precise coordinate layer mentioned above, the engine will perform a spatial phase-based overlay reconstruction: by unifying the spatial coordinate system, such as converting to WGS84 coordinates, the 3D model of the equipment in the BIM layer is overlaid into the geographic space of the GIS layer according to the actual installation location, ensuring that the spatial position of the crane model is precisely aligned with the terrain and berth boundaries of the GIS layer, forming a fused layer that includes spatial position and entity details.

[0084] By triggering the engine to identify the target layer of the task package, filter the effective layers, and perform spatial overlay reconstruction as needed, the precise association between tasks and layers is achieved, providing a focused and integrated spatial data base for the construction of task scene models.

[0085] Furthermore, step A200 in the method provided in this application embodiment includes:

[0086] A260: Trigger the third management engine to identify the task package and make a database call to determine the target data, wherein the target data includes the first rule and the second data.

[0087] A270: Based on the task orientation, the second data is reorganized to determine the second task data.

[0088] A280: Write the first rule and the second task data into the effective target layer to determine the task scenario model.

[0089] Specifically, after the third management engine is triggered, it first parses the structured elements in the task package, such as task type, time range, and evaluation object, and then initiates targeted calls in the database (distributed database cluster) based on this. For example, if the task package is to evaluate the port vessel entry and exit efficiency over the past 90 days, the engine will identify elements such as vessels, entry and exit efficiency, and 90 days, and retrieve the first rule related to vessel scheduling from the rule class in the database, such as the berthing priority rule and waterway passage efficiency standard in the "Port Vessel Entry and Exit Management Measures". It will also extract source data from the data class. This source data often contains a lot of redundant information, such as hourly positioning records of all vessels, crew change details, and equipment energy consumption data unrelated to efficiency. Direct use of such data would increase the processing burden.

[0090] For efficiency assessment tasks, the third management engine will refine and integrate redundant source data: remove irrelevant information such as crew change records, select core indicators such as the number of ships entering and leaving the port each day, the average time for ships to enter the port and berth, and the distribution of channel congestion periods, and compile structured second data on a weekly basis, so that the originally complicated source data is transformed into effective information that is strongly related to the task.

[0091] For tasks like monthly safety assessments of piling vessels in Terminal B, the engine first examines the redundant source data for the vessel in the database for the past 30 days, such as the original vibration monitoring curves every 5 minutes, complete fuel refueling records, and crew daily attendance. Through extraction and integration, core data such as vibration frequency peaks and fault alarm records related to safety are retained, while redundant attendance information is removed, ultimately forming the second set of data to support the safety assessment and ensuring that subsequent processing focuses on key information.

[0092] Next, based on the task orientation of the safety assessment, the second data was restructured in a targeted manner. Core safety-related indicators were selected from the original second data: fuel supply records unrelated to safety were removed, and the daily operating hours, number of vibration frequency exceedances, and location points of electronic fence crossings were retained. The data was then compiled into structured second task data on a weekly basis, such as a table corresponding to week, operating hours, and number of exceedances.

[0093] After data restructuring, the third management engine writes the first rule and the second task data into the effective target layers, such as the BIM 3D model layer of the piling vessel and the GIS layer of the work area. Specifically, the first rule (safety specifications) is associated with the equipment information in the BIM layer in the form of attribute tags, specifying constraints such as the need to stop and inspect if the vibration frequency exceeds 50Hz; the second task data (weekly statistical results) is overlaid onto the piling vessel's work trajectory in the GIS layer according to the time dimension through a spatial association algorithm, forming a visual association of date-location-safety indicators.

[0094] Ultimately, the effective target layer is integrated with the written rules and data to construct a task scenario model that includes the physical model of the piling vessel, the workspace, safety rules, and historical data, intuitively presenting and evaluating all elements of information related to the task.

[0095] By using a third management engine to call database data in a targeted manner, reorganize key information according to task requirements, and integrate rules and data into spatial layers, a deep binding between data and scenarios is achieved, providing standardized data support and logical connections for the accurate construction of task scenario models.

[0096] Furthermore, step A300 in the method provided in this application embodiment includes:

[0097] A310: Decompose the port management task into sub-levels using the smallest task unit to determine the subset of management tasks.

[0098] A320: For the aforementioned port management tasks, a task-oriented extrapolation and expansion are conducted to determine the expanded task subset.

[0099] A330: The management task subset and the extended task subset are used as a task cluster to perform multi-threaded parallel decision-making in the task scenario model to determine the port management strategy.

[0100] In one embodiment, when making targeted management decisions based on port management tasks, the port management tasks are first decomposed into sub-levels based on the smallest task unit. For example, if the core task is to increase the weekly container throughput of Terminal C to 8,000 TEUs, it is broken down into indivisible operational units: first, it is decomposed into three major sub-tasks: equipment efficiency optimization, vessel scheduling adjustment, and personnel shift adaptation. Then, equipment efficiency optimization is further broken down into smaller units such as increasing the hourly operation of gantry cranes to 40 TEUs and shortening the turnaround time of container trucks to 15 minutes. These independently executable and clearly defined smallest units together constitute a subset of management tasks. Each unit is accompanied by quantitative indicators, such as the daily monitoring of gantry crane operation volume, which triggers calibration if it fails to meet the standard for three consecutive days.

[0101] Next, based on a task-oriented approach, the core task is extrapolated and expanded to determine the subset of extended tasks. With increasing throughput as the guiding principle, the relevant factors affecting the objective are analyzed: ship arrival delays may lead to equipment idleness, thus expanding to include optimizing pilotage routes to reduce arrival time; personnel operational proficiency affects efficiency, thus expanding to include conducting skills training for crane operators; weather factors can also be considered, thus expanding to include adjusting work plans in advance by connecting with meteorological data. Although these extended tasks are not directly related to loading and unloading operations, they are strongly correlated with the core objective and together constitute the subset of extended tasks.

[0102] Finally, after integrating the management task subset and the extended task subset into a task cluster, multi-threaded parallel decision-making is initiated based on the task scenario model. The model has integrated the BIM equipment layer, GIS waterway layer, historical throughput data from the database, and optimization rules for area C.

[0103] The decision-making process applies the greedy principle of the smallest unit: prioritizing tasks with the highest impact on throughput, such as those with a 35% weighting for increasing crane operations, which are given priority in computing resource allocation. Simultaneously, multi-threaded parallel analysis is employed: Thread 1 processes equipment performance data, simulating energy consumption and efficiency balance under different workloads; Thread 2 optimizes ship scheduling schemes, testing time differences across multiple pilotage routes; and Thread 3 matches personnel shifts with equipment operating times to avoid personnel idleness. The analysis results from each thread are fed back to the model in real time. A result normalization algorithm eliminates conflicting solutions; for example, if a scheduling scheme shortens arrival time but causes crane waiting, the optimal collaborative solution is retained.

[0104] By focusing on core task units through sub-level decomposition, extrapolating and expanding the coverage of related factors, making decisions in parallel with multi-threaded processes, and combining the greedy principle, port management tasks are transformed from complex objectives into executable strategy combinations. While ensuring the effectiveness of decisions, the analysis is completed with minimal complexity, ultimately determining a precisely suitable port management strategy.

[0105] Furthermore, step A400 in the method provided in this application embodiment includes:

[0106] A410: Identify the port management strategy and generate strategy execution information, wherein the strategy execution information includes platform response dimension, port equipment response dimension and mobile terminal response dimension.

[0107] A420: According to the communication protocol, the policy execution information is distributed in a targeted manner and multi-party response is managed.

[0108] Optionally, after determining the port management strategy, the strategy is first structured and identified to extract the core information requiring responses from various stakeholders, generating strategy execution information that includes platform response dimensions, port equipment response dimensions, and mobile terminal response dimensions. Taking the load balancing optimization strategy for container cranes in Terminal A as an example: the platform response dimension needs to update the load threshold parameters for cranes in that area in the database; the port equipment response dimension specifies the operating parameters that need to be adjusted for the cranes; and the mobile terminal response dimension pushes an execution list to on-site operators.

[0109] Based on the communication needs of different response entities, an appropriate communication protocol is adopted for the targeted distribution of policy execution information: the platform response dimension writes the load threshold adjustment instruction into the rule class table of the distributed database through the internal HTTP protocol, ensuring that the historical load records in the data class can be associated with the new rules; the port equipment response dimension sends parameter adjustment instructions to the PLC control system of the crane based on the Modbus protocol, and crane No. 1 returns a confirmation signal that the parameters have been updated within 10 seconds after receiving the instruction; the mobile terminal response dimension pushes messages to the smart terminal APP of those skilled in the art through the MQTT protocol. The messages contain encrypted parameter adjustment details. After the terminal receives the message, a pop-up reminder is triggered. After the operator clicks to confirm the execution, the APP returns a read receipt and timestamp to the platform.

[0110] During the multi-party response process, the platform activates a real-time monitoring mechanism: it verifies the effectiveness of threshold updates for the platform's response dimensions through database logs; it confirms the execution status of port equipment response dimensions based on equipment sensor data; and it verifies the completion progress of task items through mobile terminal backend data. If a certain dimension fails to respond as expected, the platform automatically triggers a second issuance until the response loop is completed across all dimensions.

[0111] By generating multi-dimensional execution information through structured identification strategies, distributing it in a targeted manner according to the adaptation protocol, and monitoring the responses of multiple parties, port management strategies are transformed from decision outputs into collaborative actions of platforms, equipment, and personnel. This achieves the accuracy of strategy execution and full-chain traceability, ensuring the efficient implementation of port management tasks.

[0112] Furthermore, step A400 in the method provided in this application embodiment includes:

[0113] A430: In accordance with port management standards, a rigid electronic fence is introduced.

[0114] A440: Deploy the rigid electronic fence on the edge of the port, establish short-range interaction with the multi-source data interface, and perform data prior alarm management.

[0115] In this embodiment, the rigid electronic fence is a high-risk area with clearly defined boundaries set according to port management standards. It has a fixed range with no degrees of freedom and is deployed on the edge of the port. It establishes short-range interaction with multi-source data interfaces and can directly monitor ships, personnel, equipment and other things entering the boundary in real time at the front end. Once triggered, it will start an early warning response and will not enter the subsequent analysis process. It is used for the prior safety control of high-risk areas in the port.

[0116] In one embodiment, real-time control of high-risk areas in port engineering is a core aspect of full lifecycle safety management, and the introduction of rigid electronic fences must be based on port management standards. Those skilled in the art can determine the boundary parameters of rigid electronic fences based on the control requirements for dangerous goods operation areas in the "Regulations on the Safety Management of Dangerous Goods in Ports," combined with the actual risk level of the port area. For example, a 50-meter restricted area can be designated around a dangerous goods terminal, with its boundary coordinates set according to the WGS84 coordinate system, forming a closed polygon boundary. This boundary is definite and unadjustable, directly corresponding to a judgment standard with no degrees of freedom.

[0117] Rigid electronic fences are deployed along the port edge, with edge computing nodes located close to the physical boundaries of high-risk areas, such as local servers next to the duty room at a hazardous materials terminal, to avoid delays in remote data transmission. During deployment, hardware triggering modules are integrated, including infrared beam sensors (one set deployed every 10 meters along the fence boundary) and millimeter-wave radar (added at key corners), forming a dual monitoring network. This ensures that the positional awareness accuracy of ships, personnel, and equipment reaches ±1 meter, meeting the real-time requirements for direct front-end response.

[0118] This electronic fence system establishes a short-range interaction mechanism with multi-source data interfaces, connecting to data sources such as ship AIS systems, personnel positioning wristbands, and drone inspection equipment. Ship AIS signals transmit location data every 3 seconds, transmitted to the fence system via the LoRa short-range protocol; personnel positioning wristbands broadcast location information via Bluetooth, which is received and parsed every second by the fence edge nodes; drone inspection images, after having their target coordinates extracted by the edge computing module, are transmitted to the system in real time. This data does not require processing through the platform's core database; comparison is performed directly at the front end.

[0119] Finally, the data-driven alarm management process is executed: when the ship's AIS coordinates fall within the electronic fence boundary, the system triggers a front-end warning after coordinate matching is completed. The local audible and visual alarm activates continuous beeping and red flashing, while simultaneously pushing alarm information, including the ship's MMSI code and real-time coordinates, to the port monitoring center via the 4G module, and synchronizing it to the on-site patrol vehicle terminal. Since the rigid electronic fence's response logic is preset to trigger-and-respond immediately, there is no need to enter the task interpretation or model analysis stage, ensuring the immediacy of alarms and responses.

[0120] By defining rigid electronic fence boundaries according to standards, deploying them on the edge side and interacting with multiple source interfaces in close proximity, and executing data-based pre-alarms, real-time monitoring and immediate response to high-risk areas in the port have been achieved, ensuring operational safety throughout the entire lifecycle of port projects with low latency and high precision control.

[0121] In summary, the collaborative management method for port engineering lifecycle data provided in this application has the following technical effects:

[0122] This application establishes a connection between a port management platform and multi-source data interfaces to update the layer library and database. It embeds an scalable management engine array to interpret port management tasks, performs matching and reconstruction based on the layer library and matching and writing based on the database to determine the task scenario model, and performs targeted management decisions to determine port management strategies after visualization. Combined with the distribution of strategy execution information and prior alarms from rigid electronic fences, it achieves collaborative management of port engineering data throughout its entire lifecycle, making port engineering management more efficient and accurate. This results in efficient collaborative management of port engineering data throughout its entire lifecycle, ensuring synchronized data updates and deep integration, accurately responding to tasks, supporting scientific decision-making, and improving management quality and efficiency.

[0123] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a collaborative management system for port engineering lifecycle data, the system comprising:

[0124] Platform interface connection construction module 1 is used to establish a connection between the port management platform and the multi-source data interface, and to update the layer library and database.

[0125] Task scenario model acquisition module 2 is used to develop a management engine array as an embedded plugin of the port management platform. The platform acquires port management tasks, triggers the management engine array to interpret the tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines the task scenario model.

[0126] The port management strategy acquisition module 3 is used to visualize the task scenario model on the platform display module, execute directional management decisions based on port management tasks, and determine port management strategies. The directional management decisions are greedy decisions based on multi-threaded sub-tasks and extended tasks of task decomposition.

[0127] Block permission authentication module 4 is introduced, wherein the block permission authentication module 4 performs on-chain storage of the generated data management sequence and introduces block permission authentication.

[0128] Furthermore, the platform interface connection construction module 1 is used to perform the following steps:

[0129] The layer library includes at least engineering BIM layers and GIS layers, and the database includes a distributed storage cluster on the platform, containing data classes and rule classes; based on the interaction with the multi-source data interface, port update data is determined; based on the port update data, the layer library and the database are synchronously updated.

[0130] Furthermore, the task scenario model acquisition module 2 is used to perform the following steps:

[0131] The management engine array is scalable; wherein the management engine array includes at least: a first management engine that performs task element interpretation, wherein the interpretation standard is element terms based on dimensional uniformity; a second management engine that performs layer reconstruction, wherein the second management engine establishes a connection with a layer library; and a third management engine that performs rule writing and data writing, wherein the third management engine establishes a connection with a database.

[0132] Furthermore, the task scenario model acquisition module 2 is used to perform the following steps:

[0133] The port management tasks include active management tasks and passive management tasks. The active management tasks are task classes uploaded by the platform, and the passive management tasks are feedback task classes generated based on the layer library and the database. The first management engine is triggered to perform semantic interpretation and transformation based on element terms on the port management tasks to determine the task element set. The task element set is temporarily encapsulated to determine the task package.

[0134] Furthermore, the task scenario model acquisition module 2 is used to perform the following steps:

[0135] The second management engine is triggered to identify the task package and perform layer matching to determine the target layer, wherein the target layer contains at least one; the target layer is screened for task relevance to determine the valid target layer; wherein, if the number of target layers is greater than 1, spatial phase-based overlay reconstruction is performed on the valid target layer.

[0136] Furthermore, the task scenario model acquisition module 2 is used to perform the following steps:

[0137] The third management engine is triggered to identify the task package and make database calls to determine the target data, wherein the target data includes a first rule and a second data; according to the task guidance, the second data is reorganized to determine the second task data; the first rule and the second task data are written into the effective target layer to determine the task scenario model.

[0138] Furthermore, the port management strategy acquisition module 3 is used to perform the following steps:

[0139] The port management task is decomposed into sub-levels using the smallest task unit to determine a subset of management tasks. For the port management task, task-oriented deduction and expansion are performed to determine an expanded subset of tasks. The subset of management tasks and the expanded subset of tasks are used as a task cluster, and multi-threaded parallel decision-making is performed in the task scenario model to determine the port management strategy.

[0140] Furthermore, the port management strategy acquisition module 3 is used to perform the following steps:

[0141] The port management strategy is identified, and strategy execution information is generated, wherein the strategy execution information includes platform response dimensions, port equipment response dimensions, and mobile terminal response dimensions; according to the communication protocol, the strategy execution information is distributed in a targeted manner and multi-party response management is performed.

[0142] Furthermore, the port management strategy acquisition module 3 is used to perform the following steps:

[0143] In accordance with port management standards, a rigid electronic fence is introduced; the rigid electronic fence is deployed on the edge of the port and establishes short-range interaction with a multi-source data interface to perform data prior alarm management.

[0144] The collaborative management system for port engineering lifecycle data provided in this embodiment of the invention can execute the collaborative management method for port engineering lifecycle data provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0145] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0146] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A collaborative management method for port engineering lifecycle data, characterized in that, The method includes: Establish a connection between the port management platform and multi-source data interfaces, and update the layer library and database; By developing a management engine array as an embedded plugin for the port management platform, the platform obtains port management tasks, triggers the management engine array to interpret the tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines the task scenario model. The platform display module visualizes the task scenario model, executes directional management decisions based on port management tasks, and determines port management strategies. The directional management decisions are greedy decisions based on multi-threaded sub-tasks and extended tasks of task decomposition. The extended tasks are auxiliary task subsets that are strongly related to the core management objectives, generated by analyzing the related factors affecting the core tasks of port management through task-oriented deduction and extension. Among these measures, the generated data management sequence is stored on the blockchain for verification, and block permission authentication is introduced. The management engine array is scalable; The management engine array includes at least: The first management engine performs task element interpretation, with element terms based on dimensional uniformity serving as the interpretation standard; The second management engine performs layer reconstruction, wherein the second management engine establishes a connection with the layer library; The third management engine executes rule writing and data writing, wherein the third management engine establishes a connection with the database; The port management tasks include proactive management tasks and reactive management tasks. The proactive management tasks are task classes uploaded by the platform, and the reactive management tasks are feedback task classes generated based on the layer library and the database. The first management engine is triggered to perform semantic interpretation and element term-based transformation on the port management task to determine the task element set; The task element set is temporarily encapsulated to determine the task package; The execution of task matching and reconstruction based on the layer library includes: The second management engine is triggered to identify the task package and perform layer matching to determine the target layer, wherein the target layer contains at least one; The target layers are filtered for task relevance to determine the valid target layers; If the number of target layers is greater than 1, spatial phase-based overlay reconstruction is performed on the effective target layers.

2. The collaborative management method for port engineering lifecycle data as described in claim 1, characterized in that, Update the layer library and database, including: The layer library includes at least engineering BIM layers and GIS layers, and the database includes a distributed storage cluster on the platform, containing data classes and rule classes; Based on the interaction with the multi-source data interface, determine the port update data; Based on the port update data, the layer library and the database are updated synchronously.

3. The collaborative management method for port engineering lifecycle data as described in claim 1, characterized in that, Perform database-based task matching and writing to determine the task scenario model, including: The third management engine is triggered to identify the task package and make database calls to determine the target data, wherein the target data includes a first rule and second data; Based on the task orientation, the second data is reorganized to determine the second task data; Write the first rule and the second task data into the effective target layer to determine the task scenario model.

4. The collaborative management method for port engineering lifecycle data as described in claim 1, characterized in that, Execute targeted management decisions based on port management tasks, including: The port management task is decomposed into sub-levels using the smallest task unit to determine the subset of management tasks; For the aforementioned port management tasks, a task-oriented approach is used to extrapolate and expand the scope, thereby determining a subset of expanded tasks. The management task subset and the extended task subset are used as a task cluster, and multi-threaded parallel decision-making is performed in the task scenario model to determine the port management strategy.

5. The collaborative management method for port engineering lifecycle data as described in claim 1, characterized in that, After determining the port management strategy, the following should be included: Identify the port management strategy and generate strategy execution information, wherein the strategy execution information includes platform response dimension, port equipment response dimension and mobile terminal response dimension; According to the communication protocol, the policy execution information is distributed in a targeted manner and managed by multiple parties.

6. The collaborative management method for port engineering lifecycle data as described in claim 1, characterized in that, The method further includes: In accordance with port management standards, rigid electronic fences will be introduced; The rigid electronic fence is deployed on the edge of the port and establishes short-range interaction with the multi-source data interface to perform data prior alarm management.

7. A collaborative management system for port engineering lifecycle data, characterized in that, The system is used to implement the collaborative management method for port engineering lifecycle data as described in any one of claims 1-6, the system comprising: The platform interface connection module is used to establish a connection between the port management platform and the multi-source data interface, and to update the layer library and database. The task scenario model acquisition module is used to develop a management engine array as an embedded plugin of the port management platform. The platform acquires port management tasks, triggers the management engine array to interpret the tasks, performs task matching and reconstruction based on the layer library and task matching and writing based on the database, and determines the task scenario model. The port management strategy acquisition module is used to visualize the task scenario model on the platform display module, execute targeted management decisions based on port management tasks, and determine port management strategies. The targeted management decisions are greedy decisions based on multi-threaded sub-tasks and extended tasks of task decomposition. The block permission authentication module is introduced, which performs on-chain notarization of the generated data management sequence and introduces block permission authentication.

Images