Method for constructing FPSO front-end engineering design database based on multi-dimensional data fusion

Abstract

This invention discloses a method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion, belonging to the field of FPSO front-end engineering design data management technology. The method includes establishing a global virtual data directory and an FPSO design semantic model, completing the semantic mapping configuration between various professional design data fields and standardized data attributes; capturing key design activity events through data adapters, triggering an active knowledge capture process, automatically extracting cross-professional related data to generate data snapshots, pushing structured templates to collect decision-making process information, and then encapsulating it into design knowledge capsules and storing them in a case knowledge base; based on the FPSO design semantic model and the global virtual data directory, integrating data from various professions in real time and returning a cross-professional data view, while actively pushing matching design knowledge capsules according to the current design task context. This invention effectively improves cross-professional data collaboration efficiency, effectively shortens the design cycle, ensures design quality, and assists in the digital transformation of the industry.

Description

Technical Field

[0001] This invention relates to the field of FPSO front-end engineering design data management technology, specifically to a method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion. Background Technology

[0002] The front-end engineering design phase of FPSO involves multiple disciplines such as hull, marine engineering, process engineering, and electrical engineering, generating a large amount of heterogeneous design data, including 3D models, calculation sheets, drawings, and technical specifications. Efficiently managing, integrating, and utilizing this multi-source, multi-modal design data and knowledge is crucial for shortening the design cycle, ensuring design quality, and achieving knowledge transfer; it is one of the core challenges of the industry's digital transformation.

[0003] Currently, there are some technological explorations regarding the management of FPSO design data. For example, existing technologies focus on managing design deliverables through physical centralization or improved correlation retrieval. The invention patent titled "Method for Constructing a Front-End Engineering Design Database Consistently Applicable to FPSO Projects" (Publication No.: CN120744138B) focuses on calculating the index correlation degree based on the correlation between any two documents in the FPSO front-end engineering design and sorting the related documents, aiming to establish clearer document index relationships to improve query quality. This technology primarily focuses on the post-event correlation and retrieval optimization of static document deliverables. Other related technologies focus on solving the data collection, transmission, and storage problems of FPSOs during the production and operation phase, improving the real-time performance of data processing through edge computing. However, these technologies focus on real-time data during the operation phase, rather than the process data and decision-making knowledge dynamically generated during the design phase.

[0004] Existing technologies generally share a common deficiency: they all fail to address the proactive capture and effective reuse of dynamic process knowledge and implicit decision-making logic generated during cross-disciplinary collaboration in the FPSO front-end engineering design process. Existing database systems mostly passively receive final design documents or merely associate existing documents. "Process knowledge" containing a wealth of engineering wisdom, such as the iteration history of key parameters, the basis for multi-scheme comparisons, and cross-disciplinary coordination decisions, is dispersed and lost after the project ends. This leads to new design projects being unable to fully utilize historical experience, making it difficult to avoid repeating mistakes, and creating a serious "knowledge gap." Therefore, how to not only achieve logical association and real-time collaboration of cross-disciplinary design data while respecting the existing tools and data storage status of each discipline, but also proactively identify key design nodes and structurally capture and encapsulate the decision-making logic and multi-dimensional related data generated during the design process, forming a continuously accumulating and intelligently reusable design knowledge system, is a pressing technical problem that needs to be solved in this field.

[0005] In view of this, the present invention aims to propose a new method for constructing an FPSO front-end engineering design database to overcome the shortcomings of the prior art. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies by providing a method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion. By establishing an FPSO design semantic model and a global virtual data directory, deploying data adapters to capture key design events, triggering cross-disciplinary data extraction and decision-making process information collection, encapsulating and generating design knowledge capsules and intelligently pushing them, this method can proactively capture cross-disciplinary dynamic process knowledge and implicit decision-making logic, realize the structured accumulation and reuse of knowledge, and make up for the shortcomings of existing technologies in terms of knowledge loss and difficulty in reuse.

[0007] To solve the above-mentioned technical problems, this invention provides the following technical solution: a method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion, the method comprising the following steps: Step 1: Establish a global virtual data directory and an FPSO design semantic model. The global virtual data directory is used to register the index information of design data stored in different professional design systems. The FPSO design semantic model is used to define the data attributes that are unified across different professions with the design object as the core and the logical relationships between the data attributes. Step 2: Based on the FPSO design semantic model, map the actual data fields of each professional design system to the corresponding standardized data attributes to complete the semantic mapping configuration; Step 3: Monitor and capture preset design activity events through data adapters deployed in various professional design systems. These design activity events include key design parameter stabilization events, design change approval completion events, and multi-scheme comparison completion events. Step 4: When any design activity event is captured, the proactive knowledge capture process is triggered. The proactive knowledge capture process includes: automatically extracting cross-disciplinary design data associated with the event from relevant professional design systems according to the event context and semantic mapping configuration, generating a data snapshot, pushing a structured knowledge encapsulation template to the designated designer, and receiving decision process information input by the designer based on the knowledge encapsulation template. Step 5: Associate and encapsulate the data snapshot with the decision-making process information to generate a structured design knowledge capsule, and store the design knowledge capsule in the case knowledge base; Step 6: Based on the FPSO design semantic model and the global virtual data catalog, in response to design operations or query commands from the user interface, the cross-disciplinary design data view is returned through real-time logical integration from various professional design systems. Step 7: Based on the context information of the current design task, match and actively push relevant design knowledge capsules from the case knowledge base to the user interface.

[0008] Furthermore, in step one, establishing the FPSO design semantic model specifically includes: The design object is defined as a physical entity or functional module in an FPSO project; Define a set of standardized data attributes for each type of design object. The data attributes shall include at least geometric attributes, performance attributes, system attributes, and professional affiliation attributes. Define the logical relationships between the attributes of different design objects, including spatial location relationships, system function relationships, and data flow relationships.

[0009] Furthermore, in step three, capturing the stabilization event of the key design parameter includes the following process: Monitor the numerical sequence of specified key design parameters in multiple consecutive design iterations; Calculate the magnitude of change in the numerical sequence; When the change magnitude is lower than a preset stability threshold and a confirmation instruction for the key design parameter is received, it is determined that a stability event has occurred for the key design parameter.

[0010] Furthermore, in step four, the automatic extraction of cross-disciplinary design data includes the following processes: Parse the context of the design activity events to determine the core design objects and event types; Based on the semantic mapping configuration, find other design objects that are logically connected to the core design object; Based on the global virtual data directory, locate the data indexes of the core design object and other related design objects; Based on the data index, data content of a specified version is extracted from the corresponding professional design system and combined to form the data snapshot.

[0011] Furthermore, in step four, the structured knowledge encapsulation template includes the following fields: The decision problem description field, multiple alternative solution field, solution comparison basis field, final decision reason field, and external constraint record field are used to record the decision process information, which is filled into the fields by the designer.

[0012] Furthermore, step five, generating the design knowledge capsule, also includes the following process: Generate a unique identifier for the design knowledge capsule; The design knowledge capsule is tagged with multiple knowledge tags, which are derived from the automatic keyword extraction of the decision-making process information and the automatic classification of the attribute information of the design objects in the data snapshot.

[0013] Furthermore, step six, which involves real-time logical integration from various professional design systems and the return of a cross-professional design data view, includes the following processes: Receive user queries or operation requests for the target design object; Based on the FPSO design semantic model and the global virtual data directory, identify the associated design objects that have a logical relationship with the target design object and the professional design system to which the associated design objects belong; In parallel, data requests are initiated to the professional design systems corresponding to the target design object and the associated design object; The acquired data of the target design object and the data of the associated design object are organized according to the association relationship defined in the FPSO design semantic model to generate a unified data view and return it.

[0014] Furthermore, in step seven, proactively pushing relevant design knowledge capsules based on the context information of the current design task includes the following process: Extract the design object types, design stages, and design parameters involved in the current design task from the currently operating design software or the task description entered by the user; The design object type, design stage, and design parameters are matched and calculated with the knowledge tags of the design knowledge capsules in the case knowledge base; Push summary information of design knowledge capsules with a matching degree exceeding a preset threshold to the current user interface.

[0015] Furthermore, following step three, the method further includes an auxiliary step: When a change in design data is detected in any professional design system through the data adapter, other related design objects affected by the change are determined according to the semantic mapping configuration. The global virtual data directory is used to locate the professional design system and user interface to which the other related design objects belong; Generate a notification message about the changes and their potential impact, and send the notification message to the user interface corresponding to the other related design objects.

[0016] Furthermore, in the auxiliary steps, the prompt information includes the identifier of the source design object that has been changed, the content of the change, a list of affected related design objects determined based on the FPSO design semantic model, and suggested verification items.

[0017] Compared with existing technologies, this method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion has the following advantages: I. This invention establishes an FPSO design semantic model and a global virtual data catalog to achieve standardized definition and index management of cross-disciplinary design data. Combined with data adapters deployed in various professional design systems, it accurately captures key design events such as the stabilization of key design parameters, completion of design change approvals, and completion of multi-scheme comparisons. After triggering the proactive knowledge capture process, it automatically extracts cross-disciplinary related data to generate data snapshots. It collects decision-making process information through structured templates, and then encapsulates it into design knowledge capsules and stores them. This effectively solves the problem that existing technologies cannot proactively capture dynamic process knowledge and implicit decision-making logic, realizing the structured accumulation and inheritance of design knowledge. This enables subsequent design projects to fully reuse historical experience, avoid repeating mistakes, and ensure design quality.

[0018] Second, based on the FPSO design semantic model and global virtual data catalog, this invention can respond to design operations or query commands, integrate data from various professional design systems in real time and return a unified cross-professional data view. It can achieve efficient association and retrieval of cross-professional data without the need for physical data centralization. At the same time, through the design data change monitoring and impact notification mechanism, it can promptly push change and potential impact information to relevant designers, ensuring the consistency of cross-professional collaborative design.

[0019] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the FPSO design semantic model of the present invention; Figure 2 This is a schematic diagram of the data snapshot generation process of the present invention; Figure 3 This is a flowchart illustrating the knowledge capsule generation and delivery process of the present invention. Detailed Implementation

[0022] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below. Example

[0023] This embodiment discloses a specific implementation scheme for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion. This scheme is applicable to the FPSO front-end engineering design stage, covering collaborative design data management scenarios involving multiple disciplines such as hull, marine engineering, process engineering, and electrical engineering. Through the technical solution of this embodiment, semantic unification of cross-disciplinary design data, proactive capture of dynamic process knowledge, reuse of structured knowledge, and improvement of cross-disciplinary collaboration efficiency can be achieved. The specific implementation process of each step is described in detail below with reference to the accompanying drawings.

[0024] The technical architecture of this embodiment mainly comprises six core components: a professional design system, a data adapter, a core service layer, a semantic mapping configuration library, a case knowledge base, and a user interface. These components interact and transmit commands via network communication. The professional design system is a mature, industry-specific design tool; the data adapter is responsible for data acquisition and event monitoring; the core service layer handles core functions such as data integration and knowledge processing; the semantic mapping configuration library and case knowledge base provide data storage support; and the user interface provides an entry point for designers. The hardware deployment of each component adopts a distributed architecture, supporting multi-node collaborative work to ensure system stability and scalability.

[0025] The specific implementation steps of this embodiment are as follows: 1. Establish a global virtual data directory and design a semantic model for FPSO: The core objective of this step is to achieve standardized definition and index management of cross-disciplinary design data, laying the foundation for subsequent data association and knowledge capture.

[0026] Establish a global virtual data directory: The global virtual data directory is used to register the index information of design data stored in different professional design systems. It is essentially a distributed index management system. In this embodiment, Elasticsearch is used as the storage and retrieval engine. This engine has efficient full-text search capabilities and distributed storage characteristics, which can meet the needs of fast querying of large amounts of index data across disciplines.

[0027] The index information of the global virtual data catalog mainly includes core fields such as the source identifier of the design data, data storage path, data version number, data creation time, design object type, and professional affiliation identifier. The source identifier is a unique number for each professional design system; for example, the hull design system is numbered SYS-HULL, the marine engineering design system is numbered SYS-MACHINERY, the process design system is numbered SYS-PROCESS, and the electrical design system is numbered SYS-ELECTRIC. The data version number is named in the format "year-month-date-iteration number," for example: 2024-05-20-03 indicates the third iteration version on May 20, 2024; the design object type is coded according to the physical entity or functional module of the FPSO project, for example, the hull deck is coded as OBJ-HULL-DECK, and the generator is coded as OBJ-ELEC-GENERATOR.

[0028] The registration process for index information is as follows: When each professional design system generates new design data or updates its data version, the data acquisition module of the data adapter automatically extracts the core index fields of the data and transmits them to the core service layer via the communication module. The core service layer verifies the format of the index information and then stores it in the global virtual data directory. Index information updates employ a real-time synchronization mechanism to ensure that the indexes in the directory are consistent with the data status of each professional design system. The global virtual data directory supports multi-dimensional searches by design object type, professional affiliation, data version number, etc., with a search response time controlled within 1 second, meeting the need for rapid data location during the design process.

[0029] Establishing an FPSO Design Semantic Model: The FPSO design semantic model is used to define data attributes and logical relationships between data attributes that are unified across disciplines and centered on the design object. In this embodiment, the model is constructed in the form of an OWL ontology, such as... Figure 1 The diagram shows the semantic model of FPSO design. This model enables semantic unification of design data from different disciplines and provides a logical basis for cross-disciplinary data association.

[0030] The specific construction process is as follows: Define the design object: The design object is clearly defined as the physical entity or functional module in the FPSO project. Physical entities include the hull deck, engine room, storage tanks, propulsion system, generators, transformers, pipelines, pumps, sensors, etc.; functional modules include crude oil processing modules, seawater desalination modules, power distribution modules, control system modules, etc. Each design object is assigned a unique object identifier, which consists of an 8-digit alphanumeric combination. For example, the object identifier for the hull deck is HD000001, and the object identifier for the crude oil processing module is PM000001.

[0031] Define standardized data attributes: Define a set of standardized data attributes for each type of design object, which should at least cover geometric attributes, performance attributes, system attributes, and professional affiliation attributes.

[0032] Geometric attributes: These mainly describe the spatial dimensional characteristics of the design object. For example, the geometric attributes of a ship's deck include length, width, thickness, deck area, number of compartments, and location of mounting holes; the geometric attributes of a generator include volume, weight, installation dimensions, and base length, width, and height; and the geometric attributes of a pipeline include diameter, length, wall thickness, and bending radius.

[0033] Performance attributes: These mainly describe the functional indicators and operating parameters of the design object. For example, the performance attributes of a ship's deck include load-bearing capacity, wave resistance, applicable sea depth, and service life; the performance attributes of a generator include rated power, output voltage, operating efficiency, rated speed, fuel consumption, and starting current; and the performance attributes of a crude oil processing module include processing capacity, rated pressure, operating temperature, and separation efficiency.

[0034] System Attributes: Describes which overall system within the FPSO project the design object belongs to. For example, the hull deck belongs to the hull structure system, the generator belongs to the power system, the crude oil processing module belongs to the process system, and the sensor belongs to the data acquisition system.

[0035] Professional affiliation: Clearly define the design discipline corresponding to the design object. For example, the discipline of ship deck belongs to ship design, generator belongs to electrical design, crude oil processing module belongs to process design, and propulsion device belongs to marine engineering design.

[0036] Define logical relationships: The logical relationships between the attributes of different design objects include spatial location relationships, system function relationships, and data flow relationships.

[0037] Spatial location association: describes the physical installation location relationship between design objects. For example, the generator is installed in the engine room, which is located on the lower deck in the middle of the ship. Therefore, the generator is spatially associated with the engine room and the ship deck. The crude oil processing module is installed on the upper deck and is arranged adjacent to the storage tank. Therefore, the crude oil processing module is spatially associated with the upper deck and the storage tank.

[0038] System Function Association: This describes the collaborative relationship between design objects in terms of functional implementation. For example, the output end of the crude oil processing module is connected to the input end of the storage tank through a pipeline. The products after crude oil processing need to be stored in the storage tank. Therefore, there is a system function association between the crude oil processing module, the storage tank, and the pipeline. Similarly, the output end of the generator is connected to the input end of the transformer. The electrical energy generated by the generator needs to be transformed by the transformer and then transmitted to various electrical devices. Therefore, there is a system function association between the generator, the transformer, and the electrical devices.

[0039] Data flow association: describes the data transmission and interaction relationships between design objects. For example, the equipment operation data collected by sensors needs to be transmitted to the control system, and the control system issues instructions based on the data. Therefore, there is a data flow association between the sensor, the control system, and the controlled equipment. The deck thickness parameters modified by the designer in the hull design system will affect the design data of the equipment installation base in the engine design system. Therefore, there is a data flow association between the deck data of the hull design system and the base data of the engine design system.

[0040] 2. Complete semantic mapping configuration: Based on the established FPSO design semantic model, the actual data fields in each professional design system are mapped to the corresponding standardized data attributes. This process is implemented through a semantic mapping configuration library, which is stored in a PostgreSQL database and supports efficient storage and querying of complex relational data.

[0041] The professional design system and corresponding data fields involved in this embodiment are as follows: The hull design system uses TRIBON software. Its actual data fields include hull length, beam, draft, deck thickness, compartment volume, and hull weight, which need to be mapped to the geometric and performance attributes of the relevant design objects in the semantic model. For example, the "hull length" field in TRIBON is mapped to the "length" attribute under the geometric attributes of the hull deck; the "deck thickness" field is mapped to the "thickness" attribute under the geometric attributes of the hull deck; and the "hull weight" field is mapped to the "gross weight" attribute under the performance attributes of the hull structure.

[0042] The marine engine design system uses AVEVAE3D software. Its actual data fields include main engine rated power, main engine speed, fuel consumption rate, pump flow rate, pump head, and heat exchanger heat transfer area, which are mapped to the performance attributes of relevant design objects in the semantic model. For example, the "main engine rated power" field in AVEVAE3D maps to the "rated power" attribute under the main engine's performance attributes, and the "pump flow rate" field maps to the "rated flow rate" attribute under the pump's performance attributes.

[0043] The process design system uses PDMS software. Its actual data fields include pipe diameter, pipe length, medium flow rate, equipment capacity, operating pressure, and operating temperature, which are mapped to the geometric and performance attributes of the relevant design objects in the semantic model. For example, the "pipe diameter" field in PDMS is mapped to the "diameter" attribute under the geometric attributes of the conveying pipe, and the "equipment capacity" field is mapped to the "capacity" attribute under the performance attributes of the process equipment.

[0044] The electrical design system uses ETAP software. Its actual data fields include transformer rated capacity, output voltage, short-circuit impedance, cable cross-sectional area, and protection device setting values, which are mapped to the performance attributes and geometric attributes of the relevant design objects in the semantic model. For example, the "transformer rated capacity" field in ETAP is mapped to the "rated capacity" attribute under the transformer's performance attributes, and the "cable cross-sectional area" field is mapped to the "cross-sectional area" attribute under the cable's geometric attributes.

[0045] The specific implementation process of semantic mapping configuration is as follows: Professional system configuration personnel create a mapping relationship table in the semantic mapping configuration library based on the definition of the FPSO design semantic model. This table includes fields such as professional design system identifier, actual data field name, standardized attribute identifier, mapping status, configuration time, and configuration personnel. After the mapping relationship is established, the mapping configuration is synchronously updated through the data adapter's configuration module to ensure consistency between the mapping relationships of data fields and standardized attributes across different professional design systems. When a field in a particular professional design system changes, the configuration personnel must promptly update the mapping relationship table and synchronize it to all relevant components through the configuration module.

[0046] 3. Design the monitoring and capture of activity events: By deploying data adapters in various professional design systems, preset design activity events are monitored and captured. The data adapter is a key component connecting the professional design system and the core service layer. Each professional design system has one data adapter deployed in a distributed manner. It communicates with the professional design system and the core service layer via TCP / IP protocol to ensure the stability and real-time performance of data transmission.

[0047] The data adapter comprises four main functional modules: a data acquisition module, an event monitoring module, a communication module, and a configuration module. The data acquisition module is responsible for collecting design data and related operational information from the professional design system; The event monitoring module is responsible for monitoring preset design activity events and is the core module for event capture; The communication module is responsible for information transmission between the data adapter and the core service layer and the professional design system; The configuration module is responsible for receiving updates to the semantic mapping configuration library to ensure the accuracy of event monitoring and data extraction.

[0048] In this embodiment, the preset design activity events include key design parameter stabilization events, design change approval completion events, and multi-scheme comparison completion events. The specific capture process is as follows: Capture of stable events for critical design parameters: Critical design parameters refer to the core parameters that have a significant impact on the design quality, cost, and performance of FPSO. They are determined in advance by the design team based on project requirements. Examples include the length, beam, and draft in hull design; the rated power of the main engine and fuel consumption rate in engine design; the crude oil handling capacity and operating pressure in process design; and the rated capacity and output voltage of the main transformer in electrical design. Each professional design system has 8 to 12 preset critical design parameters.

[0049] The capture process specifically includes: The event monitoring module monitors the numerical sequence of specified key design parameters in real time across multiple consecutive design iterations. In this embodiment, the number of design iterations is set to 5, meaning that the module monitors the numerical changes of the parameter after 5 consecutive design modifications. For example, the numerical sequence of the ship length parameter in the hull design is monitored as 180 meters, 180.5 meters, 180.3 meters, 180.4 meters, and 180.3 meters.

[0050] The magnitude of change in the numerical sequence is calculated as follows: First, calculate the absolute value of the difference between each iteration's value and the previous iteration's value. Then, divide this absolute value by the previous iteration's value to obtain the rate of change for each iteration. Finally, take the average of the five rates of change as the overall magnitude of change for the numerical sequence. For example, the rates of change for the above ship length numerical sequence are (180.5-180) / 180≈0.278%, (180.3-180.5) / 180.5≈-0.111%, (180.4-180.3) / 180.3≈0.055%, and (180.3-180.4) / 180.4≈-0.055%, with an average value of approximately 0.124%.

[0051] The preset stability threshold is set to 3%. When the calculated change is less than 3%, and the event monitoring module receives a confirmation command from the designer via the user interface for the critical design parameter, a critical design parameter stability event is determined to have occurred. The confirmation command is issued by the designer through the "Parameter Confirmation" button on the user interface after parameter adjustment. Upon receiving the command, the event monitoring module records the event occurrence time, parameter name, final value, and other information, and triggers the subsequent proactive knowledge capture process.

[0052] Capturing the completion event of design change approval: The design change approval process is a standard process in FPSO design, which includes four nodes: designer initiates change request, design team leader reviews, professional manager reviews, and chief engineer approves. The design change only becomes effective after all approval nodes have been passed.

[0053] The data adapter's event monitoring module interfaces with the approval module of the professional design system to obtain real-time approval status information for design changes. The approval module's status codes include six types: pending review, design team leader reviewing, professional manager reviewing, chief engineer reviewing, approved, and rejected. Status code 200 represents approved. When the event monitoring module detects that the approval status code for a design change has changed to 200, it determines that the design change approval is complete and records information such as the design object identifier, parameter values ​​before and after the change, approval completion time, and approver.

[0054] For example, when a marine engineer initiates a request to change the main engine model, after the design team leader approves it, the professional manager approves it, and the chief engineer approves it, the approval module of the professional design system returns a status code of 200. After the event monitoring module captures this status code, it confirms that the design change approval has been completed and triggers the active knowledge capture process.

[0055] Capturing the completion event of multiple option comparison: In the FPSO design process, there are often multiple alternative solutions for the design of key design objects. Designers need to compare and select the final solution. The process of capturing the completion event of multiple option comparison is as follows: Designers create multi-scheme comparison tasks in the professional design system, entering parameter information, technical specifications, cost estimates, and other details for each alternative scheme. After completing the comparison, they submit the identifier of the final selected scheme through the "Scheme Confirmation" function of the professional design system. The event monitoring module monitors the status of the comparison task in the professional design system in real time. When the status of the comparison task changes to "Completion" and includes the identifier of the final selected scheme, it determines that the multi-scheme comparison completion event has occurred, and records information such as the comparison task identifier, core design object, number of alternative schemes, identifier of the final selected scheme, and comparison completion time.

[0056] For example, in the process design, there are two alternative schemes for the crude oil processing module: Scheme 1 is a single large processing unit, and Scheme 2 is two medium-sized processing units connected in parallel. After the designers complete the comparison, they select Scheme 2 and submit it for confirmation in the professional design system. After the event monitoring module captures this information, it determines that the multi-scheme comparison has been completed.

[0057] 4. Execution of the proactive knowledge capture process: When the data adapter captures any design activity event, the core service layer immediately triggers a proactive knowledge capture process. This process includes two core steps: automatically extracting cross-disciplinary design data to generate a data snapshot and pushing structured knowledge encapsulation templates to collect decision-making process information. Figure 2 The diagram shown illustrates the data snapshot generation process. The details of the process will be explained in conjunction with this diagram: Automatically extracting cross-disciplinary design data and generating a data snapshot: The core purpose of automatically extracting cross-disciplinary design data is to collect all cross-disciplinary related data associated with the current design activity and form a complete data snapshot. The specific process is as follows: Analyze the context of design activity events to determine the core design object and event type. The event context includes information such as the professional design system in which the event occurred, the parameter name that triggered the event, the event time, and the operators. Analyzing this information clarifies the core design object. For example, if the captured event is the completion of a multi-scheme comparison for the crude oil processing module in the process design system, then the core design object is the crude oil processing module, and the event type is a multi-scheme comparison completion event. If the captured event is the stabilization of a critical design parameter of the ship's length in the hull design system, then the core design object is the hull deck, and the event type is a critical design parameter stabilization event.

[0058] Based on the semantic mapping configuration, other design objects that are logically connected to the core design object can be found. Taking the crude oil processing module as the core design object, related design objects such as storage tanks, pipelines, pumps, sensors, and control systems can be found through system function association; related design objects such as installation decks, support structures, and engine rooms can be found through spatial location association; and related design objects such as sensor data acquisition modules and control systems can be found through data flow association.

[0059] Based on the global virtual data catalog, the data indexes of the core design object and other related design objects are located. The global virtual data catalog stores index information categorized by design object type and data version number. The corresponding index entry can be quickly found using the unique identifier of the core design object (such as PM000001 for the crude oil processing module), and information such as data storage path and data version number can be obtained. At the same time, the corresponding index entry can be found based on the identifier of the related design object (such as T000001 for the storage tank and P000001 for the pipeline).

[0060] Based on the data index, data content of a specified version is extracted from the corresponding professional design system and combined to form a data snapshot. The specified version is the latest data version at the time of the event, and the extracted data content consists of field values ​​corresponding to the standardized data attributes of each design object. For example, extracting attribute values ​​such as processing capacity, rated pressure, and operating temperature of the crude oil processing module; attribute values ​​such as volume, pressure rating, and storage medium of the storage tank; attribute values ​​such as diameter, length, and material of the pipeline; and attribute values ​​such as load-bearing capacity and thickness of the installation deck.

[0061] The extracted data is organized by design object and stored in JSON format to form data snapshots. Each snapshot includes the data extraction time, event identifier, core design object identifier, list of associated design objects, and attribute data of each object. Each snapshot is assigned a unique snapshot identifier and named in the format of "snapshot-year-month-date-serial number", such as snapshot-2024-05-20-001, to facilitate subsequent association with decision-making process information.

[0062] Pushing structured knowledge encapsulation templates to collect decision-making process information: The structured knowledge encapsulation templates are used to standardize the format for designers to enter decision-making process information, ensuring the integrity and reusability of decision-making logic. The templates include five core fields: decision problem description field, multiple alternative solution field, solution comparison basis field, final decision reason field, and external constraint condition record field. Each field has clear instructions for filling in, guiding designers to accurately enter information.

[0063] The template is pushed to the design lead of the relevant discipline and key designers in related disciplines. For example, if the core design object is the crude oil processing module (process engineering), the target audience includes the process engineering design lead, the hull engineers responsible for the deck installation, the electrical engineers responsible for the control system, and the marine engineers responsible for the pump equipment. The push is made via a pop-up notification on the user interface, titled "Please supplement design decision-making process information." Designers will see this pop-up after logging into the user interface, and the pop-up cannot be closed until the information is completed and submitted.

[0064] Designers should fill in the content of each field according to the actual design situation: Decision Problem Description Field: Enter the core problem that needs to be solved in this design decision, such as "To meet the requirement of increasing crude oil processing capacity to 5,000 cubic meters per hour, select a suitable crude oil processing module design scheme".

[0065] Multiple Alternative Options Field: Fill in all the alternative options participating in the comparison in the order of Option 1, Option 2, etc. Each option should briefly describe the core parameters and technical characteristics. For example, "Option 1: Use a single large-scale processing unit with a processing capacity of 5,000 cubic meters per hour, a rated pressure of 1.2 MPa, and a floor area of ​​30 square meters; Option 2: Use two medium-sized processing units in parallel, with a single unit processing capacity of 2,500 cubic meters per hour, a rated pressure of 1.2 MPa, and a floor area of ​​40 square meters."

[0066] The field for selecting the solution: Fill in the core indicators considered during the selection process, including technical feasibility, equipment cost, operating energy consumption, maintenance difficulty, floor space, and fault redundancy. For example, "The selection criteria include processing efficiency, equipment procurement cost, operating energy consumption, maintenance workload, installation space requirements, and system redundancy capability in case of failure."

[0067] Final Decision Reasons: Fill in the specific reasons for selecting the final solution, and explain the advantages of the solution in conjunction with the comparison criteria. For example, "Solution 2 is selected for the following reasons: 1. The two devices operate in parallel, and the other device can continue to work when one device fails, which has a stronger fault redundancy capability; 2. The total procurement cost of medium-sized equipment is 15% lower than that of large equipment; 3. The maintenance difficulty is lower, and the individual devices are lightweight, making them easy to disassemble and repair; 4. Although the footprint increases by 10 square meters, the current deck space meets the requirements."

[0068] External Constraints Record Field: Fill in the external constraints that must be followed during the design process, including project budget, installation space, industry standards, customer requirements, etc. For example, "External constraints: The project equipment procurement budget shall not exceed RMB 8 million, the installation space shall not exceed 50 square meters, it must comply with API industry standards, and the customer requires the equipment to operate with an energy consumption of less than 500 kW / h."

[0069] After the designers complete the form, they submit the decision-making process information through the "Submit" button on the user interface. After receiving the information, the core service layer establishes a connection with the previously generated data snapshot through an event identifier to ensure data consistency.

[0070] 5. Design the generation and storage of knowledge capsules: The data snapshots are associated with and encapsulated with decision-making process information to generate structured design knowledge capsules, which are then stored in a case knowledge base. The specific process is as follows: Generation of Design Knowledge Capsules: A unique identifier is generated for each design knowledge capsule using the UUID (Universally Unique Identifier) ​​method. The identifier is a 32-bit hexadecimal number, for example: 123e4567e89b12d3a4564266141740000 ensures that each knowledge capsule has a unique identifier, facilitating subsequent retrieval and management.

[0071] To design knowledge capsules, multiple knowledge tags are used to quickly describe the core content of the knowledge capsule, facilitating subsequent matching and push. Tag generation includes two methods: First, automatic keyword extraction from decision-making process information, using the TF-IDF algorithm to extract keywords from fields such as decision problem description, alternative solutions, and comparison criteria, for example, "crude oil processing module, processing capacity 5000 cubic meters per hour, parallel equipment, fault redundancy, cost control"; second, automatic classification of the attribute information of design objects in data snapshots, generating design object type tags, design stage tags, and core parameter tags, for example, "Design object type: process equipment; design stage: detailed design; core parameters: processing capacity 5000 cubic meters per hour, rated pressure 1.2 MPa". The number of tags for each knowledge capsule is controlled between 5 and 10 to ensure that the tags accurately reflect the core content without being overly redundant.

[0072] Data snapshots, decision-making process information, unique identifiers, and knowledge tags are combined to form a complete design knowledge capsule. The design knowledge capsule is stored in a structured file format using JSON for easy subsequent parsing and use.

[0073] The storage design for the knowledge capsules is as follows: The case knowledge base adopts a storage architecture combining HDFS and Elasticsearch. HDFS is used to store the complete data files of the knowledge capsules (including data snapshots and decision process information), while Elasticsearch is used to store the index information of the knowledge capsules (including unique identifiers, knowledge tags, storage paths, generation times, etc.) to achieve efficient retrieval and matching.

[0074] Storage is managed by partitioning according to design stage and design object type: The design phase is divided into three sections: conceptual design, preliminary design, and detailed design. The design objects are divided into four major categories: hull structure, marine equipment, process systems, and electrical equipment.

[0075] For example, knowledge capsules for process equipment during the detailed design phase are stored in HDFS: In the ` / detailed_design / process_equipment` directory, a corresponding index partition is created in Elasticsearch. This index partition uses an inverted index built based on knowledge tags, supporting fast tag-based retrieval. During storage, data is compressed using the GZIP compression algorithm, achieving a compression ratio of approximately 3:1, saving storage space. A data backup mechanism is also implemented, performing a full backup every day at midnight and an incremental backup every 6 hours. Backup data is stored on a dedicated storage node to prevent data loss.

[0076] 6. Real-time logical integration and return of cross-disciplinary design data views: Based on the FPSO design semantic model and global virtual data catalog, in response to design operations or query commands from the user interface, the system logically integrates and returns a cross-disciplinary design data view in real time from various professional design systems. The specific process is as follows: Receiving User Requests: Users initiate design operations or query commands through the user interface. The user interface adopts a B / S architecture, supports multi-terminal login, and designers can operate it through a browser. Request types include data query requests and design operation requests. Data query request: Designers can enter query conditions, such as querying "all cross-disciplinary data related to the crude oil processing module" or "data on related equipment of the generator". Query conditions can be set according to dimensions such as design object type, professional affiliation, and core parameters. Design operation request: When a designer performs operations such as modifying parameters or editing attributes of a design object, such as modifying the rated capacity of a transformer or editing the material of a transmission pipeline, the operation request will trigger the system to query and update the related data.

[0077] The user interface converts request information into standardized request instructions, including core information such as request type, target design object identifier, required attribute fields, and user identifier, which are then transmitted to the core service layer over the network.

[0078] Identifying related design objects and their respective professional design systems: After receiving the request instruction, the core service layer, based on the FPSO design semantic model and the global virtual data directory, identifies the related design objects and their respective professional design systems that have a logical relationship with the target design object. First, based on the target design object identifier, find all its logical relationships in the FPSO design semantic model, including spatial location relationships, system function relationships, and data flow relationships; Then, based on the relationships, determine the identifiers and professional affiliations of the related design objects; Finally, the professional design system identifier corresponding to the associated design object is found through the global virtual data directory to clarify the data source.

[0079] For example, if a user queries a generator (identified by G000001), according to the semantic model: The spatially related design objects include the engine room (marked E000001) and the installation base (marked B000001), which belong to the marine engineering design system and the hull design system, respectively. The system's functionally related design objects include the steam turbine (identified by T000001), the fuel supply system (identified by F000001), and the transformer (identified by TR000001), belonging to the turbine design system, process design system, and electrical design system, respectively. The design objects associated with the data flow include sensors (identified by S000001) and control systems (identified by C000001), belonging to the electrical design system and the control system design system, respectively.

[0080] Parallel data request initiation: The core service layer employs a multi-threaded parallel processing mechanism, simultaneously initiating data requests to the target design object and the corresponding professional design system. Each data request includes information such as the design object identifier, required attribute fields, and data version number, with the default data version number being the latest version.

[0081] To ensure the reliability of data requests, each request has a timeout of 5 seconds. If no response is received from the professional design system within 5 seconds, the request is re-initiated. If the timeout also occurs, a data retrieval failure message is returned, and an error log is logged. This parallel processing mechanism significantly reduces data retrieval time, improving efficiency by more than 40% compared to serial requests.

[0082] Data Integration and View Generation: After receiving data returned by various professional design systems, the core service layer organizes and integrates the data according to the relationships defined in the FPSO design semantic model, generating a unified cross-professional data view. Data integration: The data of the target design object and related design objects are classified and organized according to the type of relationship, such as spatial location related data, system function related data, and data flow related data. Each category is sorted according to the type of design object. View Generation: The data view adopts a hierarchical display structure. The top layer contains the core attribute data of the target design object, and the lower layer contains the attribute data of each related design object. It provides both tabular and graphical display methods. The tabular display lists detailed data by design object and attribute field, while the graphical display uses diagrams to illustrate the relationships and core parameters between design objects. Designers can switch between display methods as needed.

[0083] For example, the top layer of the generator's data view displays core attributes such as rated power, output voltage, and weight. The lower layers are linked by spatial location, displaying data such as the nacelle's location and mounting base dimensions; by system function, displaying data such as the turbine's power and the fuel supply system's fuel quantity; and by data flow, displaying data such as sensor acquisition parameters and control system commands. Once generated, the data view is returned to the user interface for designers to view or use in subsequent design operations.

[0084] 7. Design proactive matching and delivery of knowledge capsules: Based on the context of the current design task, relevant design knowledge capsules are matched from the case knowledge base and proactively pushed to the user interface, such as... Figure 3 The diagram shown illustrates the process of generating and pushing knowledge capsules. The pushing process is explained using this diagram. Extract the context information of the current design task: The sources of contextual information extraction include two aspects: real-time acquisition from the design software being used by the designer, and capture of the designer's operational information through the data acquisition module of the data adapter, including the type of design object being operated, the design stage, and the design parameters being edited. For example, if the designer is using ETAP software to design the parameters of a main transformer, and the currently edited rated capacity is 10000kVA, the output voltage is 110kV, and the design stage is preliminary design, the data acquisition module will capture this information in real time and transmit it to the core service layer.

[0085] The design is extracted from the task description entered in the user interface. Designers can enter relevant information about the current design task in the "Task Description" field of the user interface, such as "Preliminary design stage, selection of 10000kVA main transformer". The core service layer uses a keyword extraction algorithm to extract information such as design object type, design stage, and design parameters from the task description.

[0086] The extracted contextual information includes core content such as design object type, design stage, core design parameters, and design objectives. For example, "Design object type: main transformer; design stage: preliminary design; core parameters: rated capacity 10000kVA, output voltage 110kV; design objective: equipment selection."

[0087] Knowledge Capsule Matching Calculation: The core service layer converts the extracted context information into feature vectors. At the same time, it retrieves the knowledge tags of all design knowledge capsules from the Elasticsearch index of the case knowledge base and converts them into feature vectors. The cosine similarity algorithm is used to calculate the matching degree between the two vectors. The matching degree ranges from 0 to 1, and the closer the value is to 1, the higher the matching degree.

[0088] For example, the feature vector of the current design task includes features such as "main transformer, preliminary design, rated capacity 10000kVA, output voltage 110kV, and selection", while the feature vector of a certain knowledge capsule includes features such as "main transformer, preliminary design, rated capacity 8000kVA, output voltage 110kV, selection, and cost control". The calculated cosine similarity is 0.85, indicating that the knowledge capsule has a high degree of correlation with the current design task.

[0089] In this embodiment, the preset matching threshold is 0.7. When the calculated matching degree exceeds 0.7, the knowledge capsule is determined to be related to the current design task and is included in the push candidate list.

[0090] Knowledge Capsule Push: The top 5 knowledge capsules with the highest matching degree are selected from the candidate list, and a summary is generated and pushed to the user interface. The summary information of the knowledge capsule includes a unique identifier, the name of the core design object, an overview of the decision problem, key points of the final solution, and applicable scenarios. For example, "Knowledge Capsule ID: 123e4567e89b12d3a4564266141740000; Core object: Main transformer; Decision problem: Selection of 8000kVA main transformer in the preliminary design stage; Final solution: Select XX brand XX model transformer, procurement cost 7.5 million yuan, operating energy consumption 450kW / h; Applicable scenario: Selection of main transformer with rated capacity of 8000-12000kVA in the preliminary design stage."

[0091] The push notification is delivered via a pop-up window on the right side of the user interface, titled "Recommended Design Knowledge," accompanied by a soft sound alert to ensure designers notice it promptly. The pop-up displays knowledge capsule summaries sorted by relevance from highest to lowest, with a "View Details" button below each summary. Clicking this button allows designers to view the full content of the knowledge capsule, including data snapshots and decision-making process information. If designers are not interested in the recommended knowledge capsule, they can click the "Close" button to close the pop-up; the system will not push the same knowledge capsule again.

[0092] 8. Monitoring and Impact Alerts for Design Data Changes (Supporting Steps): After step three, the data adapter continuously monitors the design data in each professional design system. When data changes are detected, it promptly pushes change and potential impact alerts to relevant designers. The specific process is as follows: Data Change Monitoring: The event monitoring module of the data adapter uses a combination of timed polling and real-time triggering to monitor design data changes. Timed polling: Every 30 seconds, key design parameters in each professional design system are polled to check whether the values ​​have changed; Real-time triggering: When designers save and modify data in the professional design system, the system will trigger a data change notification, and the event monitoring module will receive the notification in real time.

[0093] When a change in design data is detected, the event monitoring module records the change information, including the identifier of the changed design object, the parameter value before the change, the parameter value after the change, the change time, the operator of the change, and the reason for the change (if filled in by the designer). For example, if the hull design system detects that the deck thickness parameter was changed from 20mm to 22mm, the change time is 14:30 on May 20, 2024, the operator of the change is Engineer Zhang, and the reason for the change is "to improve the deck load-bearing capacity".

[0094] Identify affected related design objects: Based on the semantic mapping configuration and the FPSO design semantic model, analyze the attributes of the design objects corresponding to the changed data to identify other related design objects affected by the change. For example, changing the deck thickness from 20mm to 22mm corresponds to a change in the geometric attributes of the hull deck. Based on the association relationships in the semantic model: Spatial location correlation: The weight that the mounting bases of equipment such as generators, pumps, and storage tanks installed on the deck need to bear remains unchanged, but the deck's load-bearing capacity is increased, which may affect the design parameters of the bases. System function correlation: The stress conditions of the supporting structures such as beams and columns supporting the deck have changed, and the strength needs to be recalculated; Data flow correlation: Changes in deck thickness may affect the total weight of the hull, which in turn affects the ship's draft, stability and other performance parameters, requiring recalculation by the engine design system and the hull performance analysis system.

[0095] Therefore, the affected related design objects include generator mounting bases, pump mounting bases, storage tank mounting bases, support beams, support columns, etc.

[0096] Locate the system and user interface of the associated design object: Find the index information of the affected associated design object through the global virtual data directory to determine the professional design system to which it belongs and the corresponding designer's user interface.

[0097] Generate and send notification messages: Generate notification messages that include the identifier of the source design object that has been changed, the details of the change, a list of affected related design objects, and suggested review items. For example: "Prompt Message: The original design object is the hull deck (identified by HD000001), and the change is that the deck thickness has been modified from 20mm to 22mm; Affected related design objects include generator mounting base (identified by B000001), pump mounting base (identified by B000002), storage tank mounting base (identified by B000003), support beams (identified by BE000001), and support columns (identified by CO000001); Recommended checks: 1. Check whether the load-bearing capacity of each mounting base needs to be adjusted; 2. Recalculate whether the strength of the support beams and columns meets the requirements; 3. Confirm whether the storage tank installation and fixing method is affected." The notification message is sent via a pop-up window in the user interface. This pop-up is set to be non-ignorable; designers must click the "I have read and confirmed" button to close it. Simultaneously, the system logs information such as the sending time, recipient, and confirmation time of the notification message for future reference. If the designer is not currently logged into the user interface, the system will automatically display the notification message upon their next login.

[0098] This embodiment, through the detailed technical solution described above, realizes the construction and application of an FPSO front-end engineering design database based on multi-dimensional data fusion. In practical engineering applications, this solution can effectively achieve semantic unification and real-time collaboration of cross-disciplinary design data, proactively capture dynamic process knowledge and implicit decision-making logic in the design process, and form a reusable design knowledge capsule to provide reference for subsequent design projects.

[0099] Meanwhile, the impact notification mechanism for design data changes can promptly inform relevant designers of the changes and potential impacts, helping to ensure consistency in cross-disciplinary design. The technical architecture adopted in this embodiment is based on existing mature software and hardware products. The selected parameters and thresholds have been verified through engineering practice, possessing good feasibility and stability. It can meet the data management needs of the FPSO front-end engineering design stage, and to a certain extent shorten the design cycle, reduce the design error rate, and improve design quality and collaboration efficiency.

[0100] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion, characterized in that, The method includes the following steps: Step 1: Establish a global virtual data directory and an FPSO design semantic model. The global virtual data directory is used to register the index information of design data stored in different professional design systems. The FPSO design semantic model is used to define the data attributes that are unified across different professions with the design object as the core and the logical relationships between the data attributes. Step 2: Based on the FPSO design semantic model, map the actual data fields of each professional design system to the corresponding standardized data attributes to complete the semantic mapping configuration; Step 3: Monitor and capture preset design activity events through data adapters deployed in various professional design systems. These design activity events include key design parameter stabilization events, design change approval completion events, and multi-scheme comparison completion events. Step 4: When any design activity event is captured, the proactive knowledge capture process is triggered. The proactive knowledge capture process includes: automatically extracting cross-disciplinary design data associated with the event from relevant professional design systems according to the event context and semantic mapping configuration, generating a data snapshot, pushing a structured knowledge encapsulation template to the designated designer, and receiving decision process information input by the designer based on the knowledge encapsulation template. Step 5: Associate and encapsulate the data snapshot with the decision-making process information to generate a structured design knowledge capsule, and store the design knowledge capsule in the case knowledge base; Step 6: Based on the FPSO design semantic model and the global virtual data catalog, in response to design operations or query commands from the user interface, the cross-disciplinary design data view is returned through real-time logical integration from various professional design systems. Step 7: Based on the context information of the current design task, match and actively push relevant design knowledge capsules from the case knowledge base to the user interface.

2. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, Step one, establishing the FPSO design semantic model, specifically includes: The design object is defined as a physical entity or functional module in an FPSO project; Define a set of standardized data attributes for each type of design object. The data attributes shall include at least geometric attributes, performance attributes, system attributes, and professional affiliation attributes. Define the logical relationships between the attributes of different design objects, including spatial location relationships, system function relationships, and data flow relationships.

3. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, In step three, the stabilization event of the key design parameter is captured. The process includes the following: Monitor the numerical sequence of specified key design parameters in multiple consecutive design iterations; Calculate the magnitude of change in the numerical sequence; When the change is lower than a preset stability threshold and a confirmation instruction for the key design parameter is received, it is determined that a stability event has occurred for the key design parameter.

4. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, Step four, which involves automatically extracting cross-disciplinary design data, includes the following processes: Parse the context of the design activity events to determine the core design objects and event types; Based on the semantic mapping configuration, find other design objects that are logically connected to the core design object; Based on the global virtual data directory, locate the data indexes of the core design object and other related design objects; Based on the data index, data content of a specified version is extracted from the corresponding professional design system and combined to form the data snapshot.

5. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, In step four, the structured knowledge encapsulation template includes the following fields: The decision problem description field, multiple alternative solutions field, solution comparison basis field, final decision reason field, and external constraint record field are used to record decision process information, which is filled into these fields by the designer.

6. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, In step five, generating the design knowledge capsule also... The process includes the following: Generate a unique identifier for the design knowledge capsule; The design knowledge capsule is tagged with multiple knowledge tags, which are derived from the automatic keyword extraction of the decision-making process information and the automatic classification of the attribute information of the design objects in the data snapshot.

7. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, In step six, real-time logical integration is performed from various professional design systems, and a cross-professional design data view is returned. The process includes the following: Receive user queries or operation requests for the target design object; Based on the FPSO design semantic model and the global virtual data directory, identify the associated design objects that have a logical relationship with the target design object and the professional design system to which the associated design objects belong; In parallel, data requests are initiated to the professional design systems corresponding to the target design object and the associated design object; The acquired data of the target design object and the data of the associated design object are organized according to the association relationship defined in the FPSO design semantic model to generate a unified data view and return it.

8. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, In step seven, relevant design knowledge capsules are proactively pushed based on the context information of the current design task. The process includes the following: Extract the design object types, design stages, and design parameters involved in the current design task from the currently operating design software or the task description entered by the user; The design object type, design stage, and design parameters are matched and calculated with the knowledge tags of the design knowledge capsules in the case knowledge base; Push summary information of design knowledge capsules with a matching degree exceeding a preset threshold to the current user interface.

9. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 1, characterized in that, Following step three, the method further includes an auxiliary step: When a change in design data is detected in any professional design system through the data adapter, other related design objects affected by the change are determined according to the semantic mapping configuration. The global virtual data directory is used to locate the professional design system and user interface to which the other related design objects belong; Generate a notification message about the changes and their potential impact, and send the notification message to the user interface corresponding to the other related design objects.

10. The method for constructing an FPSO front-end engineering design database based on multi-dimensional data fusion according to claim 9, characterized in that, In the auxiliary steps, the prompt information includes the identifier of the source design object that has been changed, the content of the change, a list of affected related design objects determined based on the FPSO design semantic model, and suggested verification items.

Images