LNG storage tank body diagram database construction method and system

Abstract

The application discloses a LNG (liquefied natural gas) storage tank ontology graph database construction method and system, and belongs to the field of data processing, comprising: obtaining a plurality of design task information of the LNG storage tank, constructing a LNG storage tank field ontology containing a concept set, a relationship set and an attribute set, the concept set containing structural concepts of three levels of assembly level, component level and part level, the relationship set containing composition relationship and contact relationship, and the attribute set containing position attribute, geometric attribute and material attribute; converting the LNG storage tank field ontology into an architecture constraint of a graph database, and according to the architecture constraint, instantiating engineering data of the LNG storage tank into the graph database to generate an ontology graph database; in response to a modification request, performing an incremental update operation on the ontology graph database; and in response to a data extraction request, extracting target data from the ontology graph database and outputting, so that a unified semantic digital basis is provided for integrated management and collaborative generation of cross-disciplinary design data of the LNG storage tank.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and system for constructing an LNG storage tank body diagram database. Background Technology

[0002] The structure of large, fully containment steel LNG storage tanks, such as... Figure 1 As shown, it includes an inner tank wall, insulation layers (bottom insulation layer and side insulation layer), inner tank bottom plate, outer tank wall, outer tank bottom plate, pile cap, lifting rods, steel dome, and outermost steel accessories. As a novel tank structure, unlike traditional concrete storage tanks, it adopts a double-layer thin-walled steel structure system, with both inner and outer tanks constructed from steel plates with a thickness of 8 to 22 millimeters. It has significant advantages such as a high degree of prefabrication and ease of construction, making integrated design-manufacturing-construction possible. However, actual engineering projects involve diverse and complex data sources of varying types. The design of large liquefied natural gas (LNG) storage tanks is a highly complex systems engineering project, involving deep collaboration among multiple disciplines such as structural mechanics, fluid mechanics, materials engineering, and construction management. A complete LNG storage tank design project typically involves a workflow comprised of multiple parallel professional branches: structural engineers use finite element analysis (FEA) software (such as ANSYS and ABAQUS) to build mechanical analysis models to verify the structural safety of the tank under conditions such as self-weight, internal pressure, wind load, and earthquakes; building information modeling (BIM) engineers use software such as Revit and CATIA to build building information models (usually following Industry Basic Class (IFC) standards) for multi-disciplinary clash checks, construction simulation, and asset management; and for visualization, design review, or virtual reality walkthroughs, the geometric model needs to be exported as a surface mesh model in STL (stereolithography) format.

[0003] In traditional design paradigms, the three models mentioned above—FEA, IFC, and STL—are built independently and stored in different file systems or databases. They differ significantly in the following key dimensions:

[0004] 1. Different data organization methods: The FEA model uses nodes, elements, sections, and materials as basic organizational units, emphasizing mesh topology and mechanical properties; the IFC model follows a strict semantic hierarchy, emphasizing the type, relationship, and attributes of engineering objects; the STL model consists only of discrete triangular patches and their normal vectors, without containing any semantic or engineering attribute information.

[0005] 2. Different granularity representations: In the FEA model, a stiffening rib may be simplified to a beam element; in the IFC model, it is represented as a component with complete geometric cross-section and material information; while in the STL model, it is merely a set of triangular facets.

[0006] 3. Different semantic definitions: A component that a structural engineer calls a "shell" may be called a "wall panel" by a BIM engineer. This difference in terminology makes cross-system information retrieval and association extremely difficult without a unified ontology.

[0007] This "one project, multiple models" working model has directly led to a series of serious technical problems:

[0008] 1. Information silos and repetitive data entry are prominent issues. The geometric dimensions (such as diameter and height), material properties (such as the elastic modulus and yield strength of S30408 ​​stainless steel), and design parameters (such as the thickness of each wall panel) of the same storage tank need to be repeatedly entered and modified manually in multiple unrelated systems such as ANSYS and Revit. This is not only inefficient but also highly prone to data conflicts due to version inconsistencies. For example, the wall panel thickness in the structural analysis model may have been optimized to 12mm, but the corresponding component in the BIM model may still retain the old value of 10mm, leading to inconsistent design benchmarks.

[0009] 2. Severe information loss and semantic distortion occur during model conversion. To address data exchange between heterogeneous models, existing technologies have primarily attempted two methods, but both have inherent drawbacks:

[0010] 1) Conversion based on intermediate file formats: For example, exporting a BIM model as an IFC file and then converting it to a FEA model using a third-party tool. However, due to differences in how different software interprets the IFC standard, geometric interpretation deviations (such as excessive discretization of surfaces), loss of attribute information (such as the inability to map material nonlinear parameters), and complete breakage of semantic relationships between components (such as bolted connections and welding relationships) often occur during the conversion process. Research by Gerbino et al. has clearly pointed out that this IFC-based interoperability faces persistent technical obstacles in structural engineering applications.

[0011] 2) Application Programming Interface (API)-based conversion: This involves writing scripts to call the APIs of different software for model creation and modification. While this method can achieve unidirectional model synchronization in certain specific scenarios, it is heavily dependent on specific software versions and platforms, has poor versatility, and high maintenance costs. When the design changes, updates need to be coordinated across multiple APIs, which can easily lead to synchronization failures or data overwrite errors. Putrama and Martinek's review also confirms that the API method has fundamental limitations such as strong platform dependence and limited cross-system applicability.

[0012] 3. Design knowledge is difficult to formalize and computable. In existing technologies, the design knowledge of LNG storage tanks (such as "the inner tank is composed of wall plates and a bottom plate", "there is welding contact between adjacent wall plates", and "the wall plate thickness can vary in stages along the height direction") is mostly implicit in drawings, calculation sheets, or engineers' experience, and has not formed a structured, computer-understandable formal model. This results in the inability to automatically reason, query, and reuse design knowledge, and a lack of data foundation for advanced applications such as intelligent design and automatic scheme comparison.

[0013] 4. The data model lacks dynamic evolution capabilities. LNG tank design is a typical incremental iterative process: the preliminary design phase focuses on overall dimensions, the detailed design phase focuses on layered wall thickness and stiffening rib arrangement, and the construction drawing phase focuses on component subdivision and weld details. Design changes (such as adding a ring of stiffening ribs or modifying the thickness of a certain wall layer) occur frequently throughout the process. Traditional relational databases or static file storage methods struggle to support the flexible expansion and efficient incremental updates of this knowledge model. A seemingly localized design change often requires modifying multiple data tables or files and regenerating all downstream models, resulting in enormous computational overhead and severely restricting the speed of design iteration.

[0014] 5. Existing ontology / knowledge graph applications do not cover this field. In recent years, ontology technology and knowledge graphs have been applied in the field of architecture, engineering, and construction (AEC), such as for automated compliance checks and building information retrieval. However, as Farghal et al. pointed out in their review, existing research mainly focuses on building construction and general building information management. Methods for constructing ontology graph databases that can support the collaborative generation and dynamic evolution of multidisciplinary models, specifically for the structural design phase of large industrial facilities (especially LNG storage tanks), are almost entirely lacking in current technology. Summary of the Invention

[0015] This invention provides a method and system for constructing an LNG storage tank ontology database. The technical problems it aims to solve are: difficulties in integrating multi-source heterogeneous data in the existing LNG storage tank design process, loss of information during model conversion, lack of formal representation of design knowledge, inability of data models to evolve dynamically, and the absence of a unified semantic digital foundation for LNG storage tanks.

[0016] To address the aforementioned technical problems, this invention provides a method for constructing an LNG storage tank body diagram database, comprising:

[0017] Obtain various design task information for LNG storage tanks, and construct an LNG storage tank domain ontology based on the design task information. The LNG storage tank domain ontology includes a concept set, a relationship set, and an attribute set. The concept set includes structural concepts at three levels: assembly level, component level, and part level. The relationship set includes compositional relationships and contact relationships. The attribute set includes location attributes, geometric attributes, and material attributes.

[0018] The LNG storage tank ontology is converted into the architectural constraints of a graph database, and the engineering data of the LNG storage tank is instantiated into the graph database according to the architectural constraints to generate an ontology graph database.

[0019] In response to the modification request, an incremental update operation is performed on the ontology graph database;

[0020] In response to a data extraction request, target data is extracted from the ontology graph database and output.

[0021] Furthermore, the construction of the LNG storage tank ontology based on the design task information includes:

[0022] The design scope is defined jointly by multiple LNG storage tank design tasks, and an initial ontology is constructed based on the design scope.

[0023] For any design task, the incremental knowledge corresponding to the design task is organized into concept increments, relation increments, and attribute increments;

[0024] The concept increment, relation increment, and attribute increment are performed with terminology alignment and consistency verification, and the verified incremental knowledge is incorporated into the core ontology library.

[0025] Furthermore, organizing the incremental knowledge corresponding to the design task into concept increments, relation increments, and attribute increments includes:

[0026] New concepts are added to the initial ontology through keyword extraction and expansion mechanisms, and / or concepts from different ontologs are combined through a combination mechanism to obtain the concept increment.

[0027] Furthermore, the composition relation is used to express the physical inclusion relationship between concepts at different levels, and the composition relation satisfies the transitivity axiom; the contact relation is used to express the adjacency relationship between concepts at the same level, and the contact relation satisfies the symmetry axiom.

[0028] Furthermore, the step of converting the LNG storage tank ontology into architectural constraints for a graph database, and instantiating the engineering data of the LNG storage tank into the graph database according to the architectural constraints to generate an ontology graph database, includes:

[0029] Pattern-level mapping: Parse the concept set, relation set, and attribute set from the network ontology language file of the LNG storage tank domain ontology, map each concept in the concept set to a node label in the graph database, map each relation in the relation set to an edge type in the graph database, map each attribute in the attribute set to an attribute key-value pair in the graph database, and generate edge endpoint constraint functions according to the domain and scope constraints in the network ontology language file;

[0030] Instance-level mapping: Under the aforementioned architectural constraints, each data instance in the engineering data of the LNG storage tank is mapped to a node in a graph database, wherein the label of the node contains the direct type of the data instance and all its parent types; each relation assertion in the engineering data instance is mapped to a directed edge between corresponding nodes in the graph database, wherein the direction of the directed edge is from the source node of the relation assertion to the target node, and the label of the directed edge is the relation name of the relation assertion; each attribute assertion in the engineering data instance is stored as a key-value pair in the attribute of the corresponding node.

[0031] Furthermore, in the pattern-level mapping, the node label set of the ontology graph database From the formula Definition, where For the set of concepts, for Any concept in For mapping functions, For the concept The mapped node labels; the set of edge types in the ontology graph database. From the formula Definition, where For the set of relations, for Any relation in, For relationship The edge type obtained from the mapping; the set of attribute key-value pairs in the ontology graph database. From the formula Definition, where For the attribute set, for Any attribute in, For attributes key name, For attributes Data type; edge endpoint constraint function From the formula definition, Each edge type is mapped to a pair of node labels to specify the source node label and the target node label to which the edge connects.

[0032] Furthermore, the instance-level mapping includes: a set of engineering data instance records. Any data instance in Create graph nodes , tag collection Includes the data instance direct type and all its parent types; and, the set of relation assertions. Any two data instances Relationship assertion In these two data instances Corresponding graph nodes and Directed edges are generated between them. The directed edge endpoint functions The directed edge The tag is ; and, for data instances Property assertions Property assertions are made through property mapping functions. key-value pairs Stored to the graph node In the attributes.

[0033] Furthermore, performing an incremental update operation on the ontology graph database includes:

[0034] When the modification request is a structural adjustment, a topology sequence is generated from the source node to the target node along a specified path. The topology sequence contains nodes and edges and is used to insert new components or remove obsolete components.

[0035] When the modification request is an attribute update, the internal parameter value of the target node is modified directly.

[0036] Furthermore, the step of extracting and outputting target data from the ontology graph database includes:

[0037] When the data extraction request is entity extraction, the system filters out individual nodes that meet the query conditions based on node tags and node attributes, and outputs the tags and attributes of the nodes.

[0038] When the data extraction request is path extraction, under the specified edge type constraint, a simple path consisting of a continuous sequence of relations and without duplicate nodes is obtained by traversing from the source node to the target node, and the attributes of each node, each edge and each node in the path are output.

[0039] When the data extraction request is a subgraph extraction, a connected subgraph is extracted with the specified node as the root, and the node set, edge set, and attributes of each node in the node set of the connected subgraph are output.

[0040] This invention also provides an LNG storage tank body diagram database construction system. The key feature of the LNG storage tank body diagram database construction method described above is that the system includes:

[0041] The ontology construction module is used to acquire various design task information of LNG storage tanks and construct an ontology of the LNG storage tank domain based on the design task information. The ontology of the LNG storage tank domain includes a concept set, a relationship set, and an attribute set. The concept set includes structural concepts at three levels: assembly level, component level, and part level. The relationship set includes compositional relationships and contact relationships. The attribute set includes location attributes, geometric attributes, and material attributes.

[0042] The graph database generation module is used to convert the LNG storage tank ontology into the architectural constraints of the graph database, and to instantiate the engineering data of the LNG storage tank into the graph database according to the architectural constraints, thereby generating the ontology graph database.

[0043] The graph database evolution module is used to perform incremental update operations on the ontology graph database in response to a modification request for the graph database.

[0044] The data extraction module is used to extract target data from the ontology graph database and output it in response to a data extraction request from the graph database.

[0045] The LNG storage tank body diagram database construction method and system provided by this invention have the following advantages:

[0046] By constructing an ontology for the LNG storage tank field that follows a multi-level hierarchical structure of "assembly-component-part", the core concepts, compositional relationships, contact relationships, and three types of attributes (location, geometry, and material) are clearly defined. This provides a unified semantic dictionary for different disciplines such as structural engineering, BIM management, and visualization, eliminates ambiguity in cross-disciplinary terms, and lays a digital foundation for the integrated management and collaborative generation of design data.

[0047] By establishing a two-stage mapping mechanism from web ontology language to labeled attribute graphs, namely schema-level mapping and instance-level mapping, the concepts, relations, and attribute constraints of the ontology are converted into node labels, edge types, and attribute keys of the graph database. At the same time, specific engineering data is instantiated into nodes, edges, and attribute values ​​in the graph. This achieves lossless conversion from abstract ontology to computable graph database, ensuring that design knowledge can be completely and accurately converted into a graph structure model that can be directly stored, queried, and computed by computers.

[0048] By decomposing design changes into two basic operations—structural adjustment and attribute update—incremental updates of the graph database are achieved. Structural adjustment generates a topological sequence along a specified path for inserting new components or removing obsolete components, while attribute update directly modifies the internal parameter values ​​of the target node. Compared with the existing technology that requires deleting and rebuilding the entire model for each modification, the incremental update mechanism of this invention operates directly on the persistent graph instance, avoiding the computational overhead of a complete reconstruction, and enabling the graph database to be efficiently synchronized with the incremental and iterative design process of LNG storage tanks.

[0049] By defining three core data extraction methods—entity extraction, path extraction, and subgraph extraction—downstream applications can accurately obtain the attribute information of a single component, the topological transmission logic of a relationship chain, or the structural composition of a complete subsystem according to their own needs. The data is then output in a standardized JSON format, providing unified and efficient data service support for the seamless integration of external computing modules such as finite element analysis, IFC model export, and visualization rendering. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the structure of an LNG storage tank provided in an embodiment of the present invention;

[0051] Figure 2 A schematic diagram illustrating the principle of the LNG storage tank body diagram database construction method provided in this embodiment of the invention;

[0052] Figure 3 A schematic diagram illustrating a progressive ontology development strategy for multi-task applications provided in an embodiment of the present invention;

[0053] Figure 4 This is a schematic diagram illustrating the evolution of the core body of the LNG storage tank provided in an embodiment of the present invention;

[0054] Figure 5 A schematic diagram of a two-stage mapping mechanism from network ontology language to tag attribute graph provided in an embodiment of the present invention;

[0055] Figure 6 This is a schematic diagram illustrating the dynamic evolution of graph databases and multi-modal data extraction process provided in an embodiment of the present invention;

[0056] Figure 7 This is an example diagram illustrating the application of target component query and 3D model mapping based on graph database provided in an embodiment of the present invention. Detailed Implementation

[0057] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0058] Example 1

[0059] This invention provides a method for constructing an LNG storage tank body diagram database, the principle of which is as follows: Figure 2 As shown, this method acquires various design task information for LNG storage tanks. These tasks include at least structural analysis tasks (corresponding to finite element models, for mechanical analysis, etc.), building information modeling tasks (corresponding to IFC models, for multi-disciplinary clash checks, construction simulation, and asset management, etc.), and visualization tasks (corresponding to STL models, for visualization, design review, or virtual reality walkthroughs, etc.). Based on the acquired design task information, an ontology engineering approach is used to construct a domain ontology, establishing a multi-level conceptual hierarchy of "assembly-component-part" and its semantic relationships. A graph database is used for ontology instantiation and storage, supporting the generation, modification, querying, and retrieval of node labels, edge types, and attribute key-value pairs. This forms a unified digital foundation for the tank structure, supporting an automatic mapping workflow between the structural analysis model, IFC model, and geometric display model, thereby achieving consistent representation and collaborative generation of multi-source models.

[0060] Ontology is a core concept in knowledge engineering, defined as a "conceptualized and clearly defined specification." Simply put, an ontology is like a dictionary that defines what concepts exist within a domain (e.g., "inner tank," "wall panel"), what relationships exist between these concepts (e.g., "composition," "contact"), and what attributes each concept possesses (e.g., thickness, material, location). With ontology, humans and computers can understand and exchange domain knowledge in a consistent manner. In LNG storage tank design, different disciplines may use different terminology for the same thing; ontology eliminates ambiguity through clear definitions, enabling cross-disciplinary collaboration.

[0061] The integrated design of LNG storage tanks involves the collaborative management of multi-source data and various types of entities. For example, statistical data representing the geometry of LNG storage tanks (such as height, diameter, and curvature) can be adjusted during the design process, while structural analysis requires semantic data indicating material types (such as S30408 ​​steel and carbon steel). To uniformly describe this diverse information and the complex relationships between such data and entities, ontology engineering methods are used to formally model the structure of LNG storage tanks.

[0062] Each ontology can be represented as a triple. ,in , and These represent concepts, relationships, and attributes, respectively. Given the diversity of LNG storage tank design tasks, this invention adopts a multi-task-oriented incremental ontology development strategy, the principle of which is as follows: Figure 3 As shown. Reference Figure 3First, the design scope is defined and an initial ontology is constructed based on multiple LNG tank design tasks. This initial ontology is built upon general engineering foundation classes from ISO 15926 or IFC standards, and then tailored and expanded in conjunction with LNG tank design specifications (such as EN 14620). Subsequently, new concepts are added to the initial ontology through keyword extraction and expansion mechanisms, and / or concepts from different ontologies are combined through a combination mechanism to obtain concept increments. The keyword extraction and expansion mechanism can be implemented using a predefined LNG tank domain dictionary (containing common terms and their synonyms, and English translations) combined with regular expression matching. For new terms not included in the dictionary, a string similarity algorithm (such as edit distance) is used for fuzzy matching with existing concept names, supplemented by expert review. The combination mechanism is used to integrate concepts from different task ontologies, aligning semantically similar concepts through equivalence relations, or mapping heterogeneous names to standard terms. For any given task... The relevant incremental knowledge is organized into , Given tasks The increments of concepts, relationships, and attributes. Then, the increments of concepts. Relationship increment and attribute increment Perform terminology alignment and consistency verification. Verification includes: ① Checking for circular inheritance (e.g., ...). yes subclasses, Again ① Subclasses of the relation; if any exist, report an error and suggest corrections; ② Check for attribute conflicts, i.e., whether the same attribute is assigned an incompatible data type; ③ Verify whether the domain and range of the relation conflict with the existing concept hierarchy; ④ Ensure that the transitivity of the constituent relations is not violated (e.g., ...). composition , composition Then it will automatically deduce composition For incremental knowledge that fails validation, the system generates a conflict report and refuses to incorporate it into the core ontology. Finally, validated, reusable, and stable semantics are incorporated into the core ontology library. ,in and Representing the first Wheel and the first The composition mechanism combines increments from different tasks when multiple design tasks need to be supported simultaneously.

[0063] The core ontology, developed using Protege (an ontology editing tool), abstracts the LNG storage tank into a multi-level semantic network, containing concepts. ,relation and attributes Top-level structure concept set Strictly mapped to the engineering design granularity: assembly level ( ), component level ( ) and part level ( These levels of granularity support preliminary scheme decisions, detailed parameter specifications, and detailed construction drawing design, respectively. Each specific structural concept is categorized at these levels; for example, the InnerTank is defined as... The subclass InnerShellPlate is defined as Subclasses of. Relationship set. It contains two user-defined object properties: composition relation and contact relationship Compositional relationships Satisfying transitivity axioms to express physical inclusion and contact relationships across levels The symmetry axiom is satisfied to describe the adjacency relationships between components within a level. Together, they establish the topology of vertical decomposition and horizontal association. Finally, the attribute set... Encapsulated location ,geometry and materials The data provides a unified parameter basis for downstream models such as structural analysis and Building Information Modeling (BIM).

[0064] For example, the inner tank (Inner_Tank) as subclasses, in The level is decomposed into inner tank wall plates (Inner_Shell) and inner tank bottom plates (Inner_Bottom), which are further... The hierarchy is refined into inner tank wall plate units (Inner_ShellPlate) and inner tank bottom plate units (Inner_BottomPlate). Subsequently, the task ontology dynamically evolves when performing tank wall design tasks—especially when driven by layered wall thickness design and structural stability verification requirements. To support layered design, it utilizes compositional relationships... The Inner_ShellLayer concept (inner shell layer) is extended under the Inner_Shell node. Simultaneously, to address stability constraints, the InnerStiffener concept (inner stiffening rib) is directly added under the Inner_Tank concept, further... The level is refined to inner tank stiffening rib units. Once verified, these increments are integrated into the core ontology for semantic reuse, and the corresponding evolution results are as follows: Figure 4 As shown.

[0065] LNG storage tank design data exhibits a complex hierarchical structure, highly interconnected entities, and strict topological constraints. Graph databases can intuitively describe entities and their semantic relationships using nodes and edges. Therefore, this embodiment employs a graph database to instantiate and store the ontology model, thereby supporting model generation, updating, information management, and retrieval throughout the design process.

[0066] To facilitate the computationalization of ontology concepts, this embodiment utilizes a Web Ontology Language (OWL) file (hereinafter referred to as OWL file) exported by an ontology editor as a semantic bridge to map abstract domain knowledge to a graph database (LPG), resulting in an ontology graph database (or graph model). The graph database is preferably a database system that supports attribute graph databases, such as Neo4j or JanusGraph. The LPG is formally defined as... In the ontology database, engineering entities and directed semantic edges This forms the topological skeleton, while the endpoint functions Tag allocation and property mapping This endows the graph with multidimensional features. The construction of an ontology graph database is achieved through two collaborative mapping phases: schema-level mapping and instance-level mapping, such as... Figure 5 As shown.

[0067] In pattern-level mapping, the concept set Each concept in the graph is mapped to a node label in the graph database, thus connecting the relation sets. Each relation in the graph is mapped to an edge type in the graph database, which maps attribute sets. Each attribute in the graph database is mapped to an attribute key-value pair. Specifically, the ontology concept... and object properties Node label sets were defined respectively. and edge type set The elements. At the same time, data attributes. Converted into an ordered set of specified attribute keys and their data types Furthermore, the domain and range constraints embedded in the OWL file are interpreted as edge endpoint constraint functions. This is to ensure the topological validity of the generated graph.

[0068] (1)

[0069] (2)

[0070] (3)

[0071] (4)

[0072] Formulas (1) and (2) define the set of node labels for the ontology graph database. and edge type set .in All concepts in the ontology Through mapping function The resulting labels constitute, and Then all relations in the ontology The mapping is obtained. These two formulas together establish the foundation for the mapping from ontology to graph database schema: each concept corresponds to a type of node, and each relation corresponds to a type of edge, ensuring that the graph obtained by subsequent instantiation is semantically strictly consistent with the ontology. Formula (3) maps all attributes in the ontology. Convert to a collection of key-value pairs Each record contains the key name of the attribute. and data types This provides a type-safe definition for storing the attributes of graph nodes. Equation (4) defines an edge endpoint constraint function. It will be for each edge type Mapped to a pair of node labels This means that edges can only connect nodes with specific labels, thus ensuring the legality of the graph topology at the structural level.

[0073] After the schema-level mapping is completed, the system creates corresponding node labels, edge types, and attribute key definitions in the database based on the architectural constraints generated by formulas (1)-(4), and uses the constraint mechanism provided by the database to perform mandatory validation of the edge endpoint types to ensure that any subsequently inserted edge meets the domain and value range restrictions. When using Neo4j, the mapped labels, relation types, and attribute keys can be directly mapped to Label, Relationship Type, and Property Key in the database, thereby ensuring the seamless implementation of ontology semantics.

[0074] In instance-level mapping, the engineering data instance record set of the LNG storage tank is obtained. Each data instance in the engineering data instance record set is filled into the diagram from bottom to top under architectural constraints, following the logic described by formulas (5)-(7). The engineering data instance record set comes from structural analysis models (such as neutral files of ANSYS), BIM models (such as IFC files), or design parameter tables (such as wall thickness tables in Excel format). Each data instance is parsed and uniformly converted into an intermediate representation in the form of triples: entity instance, relation assertion, and attribute assertion. Specifically, the data instance record set comes from the entity instance set. Each entity instance Instantiated as a graph node Based on the class hierarchy defined by the subClassOf axiom, all parent class tags are inherited (e.g., an instance of InnerTank carries both InnerTank and Assembly tags), thus supporting queries at any design granularity. Simultaneously, a globally unique identifier is assigned to each project entity to ensure lifecycle traceability. Then, a set of relationship assertions... Driver endpoint function and tag assignment Generate oriented edges with type, while the attribute value set Through property mapping Attach it to the corresponding node.

[0075] (5)

[0076] (6)

[0077] (7)

[0078] in, Represents a data instance The most specific class (i.e., direct type) to which it belongs in the ontology, and according to Axiom: This instance should inherit from all its parent class types. Therefore, the node... tag collection Not only includes It also includes the tags of each of its parent classes. For example, if an InnerTank instance's direct type is InnerTank and its parent class is Assembly, then the tag set for that node is... For attribute mapping functions This article defines it as the operation of persisting key-value pairs to node properties: Let... This indicates that the key is... Value The attributes are written into the node's attribute set, while This is the concrete expression of the operation, that is, the operation on the node. Assign the key name Value Attributes.

[0079] Formula (5) describes the instantiation process of a graph node: for the instance record set Each data instance in The system creates a graph node. And the label set of this node. It must contain the direct type of the instance. And all its parent types. This means that a node of an "inner tank" instance will have tags such as InnerTank and Assembly, thus supporting data querying at different design granularities. Formula (6) converts relation assertions into directed edges in a graph database. For each relation assertion The system is at the corresponding graph node and Generate a directed edge between them The direction of the side is from point to The label of the edge Take as relation name In this way, the relationships such as "composition" or "contact" defined in the ontology become traversable paths in the graph database, facilitating complex relationship queries. Formula (7) asserts attributes. Stored on graph nodes. The system uses attribute mapping functions. At the node Chinese key-value pairs The attribute value is recorded in a specific format. This allows the geometric parameters (such as thickness and diameter) and material properties (such as steel grade) of each engineering entity to be saved as node attributes, supporting subsequent read and modification operations.

[0080] Ultimately, the fusion of schema-level semantics and instance-level data resulted in a complete ontology graph database (graph database). This unified framework, bridged by OWL, efficiently organizes the object structure, semantic relationships, and parameter information in LNG tank design, providing a robust digital foundation for subsequent complex queries and knowledge reuse.

[0081] LNG storage tank design is essentially a continuous, iterative optimization process. Faced with constantly changing operating conditions and specification constraints, engineers must frequently adjust geometric parameters, component schemes, and material selections. Since these adjustments directly alter the engineering entity and its semantic network, the graph database must possess the ability to dynamically evolve in sync with the design process. This requires specific modification requests. The following embodiment will use a graph database. The update behavior is formally defined as follows: According to the graph evolution model, these updates are divided into two basic operations, as shown in Equation (8):

[0082] (8)

[0083] Formula (8) defines the graph database in modification requests. The dynamic evolution behavior under this framework is divided into two types: structural adjustment and attribute update. Structural adjustment follows a specified path. The path, consisting of a series of alternating nodes and edges, is represented as follows: ,in , , As the source node, For the target node, This refers to the alternating nodes and edges between the source and target nodes. For insertion operations, the system first parses the new component type, target parent node, and expected location carried in the modification request. Then, it creates new nodes and the required relational edges (including compositional and contact relationships) at the corresponding locations on the path. The new nodes inherit the labels and attribute templates of their respective concepts, and the system automatically verifies the validity of edge endpoints based on ontology constraints. For removal operations, the system deletes nodes and their associated edges on the specified path. If a node has child components (connected through compositional relationships), the user must specify whether to cascade deletion or only remove the parent-child relationship. Regardless of whether it is insertion or removal, an integrity check is performed after the operation to ensure that the graph database still satisfies the edge endpoint constraint functions. And the axioms of relational transitivity / symmetry. For example, when a new ring of stiffening ribs (InnerStiffener) needs to be added under the Inner Shell, the user request includes the target path. The system creates an InnerStiffener node at the end of this path and establishes... The relationship is defined, and positional and geometric parameters are set simultaneously. Attribute updates directly modify the nodes. The internal parameters, whose new values ​​are derived from the attribute mapping. Return. This mechanism enables incremental updates to persistent graph instances, avoiding the need to rebuild the entire graph database with every design change.

[0084] To effectively enable diverse downstream application scenarios, graph databases must be able to both dynamically update and retrieve data. This embodiment defines three core graph extraction mechanisms, unified in the extraction function. As shown in formula (9):

[0085] (9)

[0086] The first method is entity extraction, which uses a predicate filtering function. Precisely isolate individual nodes that meet the specified query conditions, based on their labels. and attributes The decision is made. The second method is path extraction, which involves selecting from a specified set of edge types. Under constraints, this operation occurs at the source node. and target node Traverse between and extract from Three pairs The third method is subgraph extraction, which utilizes extraction functions to create a continuous sequence of relationships, thereby revealing the deep topological transmission logic between components. Isolate by specifying nodes The connected subgraph rooted at the specified root will ultimately output the local node set. Edge set And their role in property mapping On the restrictions The path extraction returns a continuous sequence of relationships without duplicate nodes or edges, indicating a simple path. If the query requires traversing a loop structure, subgraph extraction should be used to obtain the complete connected components. All extraction results are serialized into JSON format for use by downstream modules.

[0087] These two fundamental capabilities—dynamic evolution and multi-pattern extraction—work together to establish the complete read / write lifecycle of a graph database. The dynamic evolution and multi-pattern extraction process of a graph database can be referenced. Figure 6 .like Figure 6 As shown, incremental updates are performed on the persistent graph instance (left), effectively avoiding the computational overhead of a complete reconstruction. Subsequently, this updated graph database seamlessly serves as the basis for the execution of the three extraction modes (right). Finally, all extracted topology and parameter data are uniformly serialized into a lightweight JSON (JavaScript Object Notation) format. This standardized data interface eliminates transmission redundancy and ensures seamless integration between the evolving graph database and downstream structural analysis computation modules.

[0088] To verify the effectiveness of the proposed ontology graph database construction method, this embodiment selects a double-walled steel full-containment LNG storage tank as an engineering case. The effective storage volume of this tank is approximately The seismic fortification conditions correspond to an intensity of 8 degrees, and the basic design seismic acceleration is... Based on the established ontology model and database mapping mechanism, the LNG storage tank case is instantiated into an ontology graph database through entity extraction and relationship recognition.

[0089] The instantiated ontology graph database contains 2330 entity nodes and 16791 relations. In terms of node hierarchy, it includes 1 top-level root node, 5 assembly-level nodes, 126 component-level nodes, and 2198 part-level nodes. At the relational level, two types of relations are defined: composition relations. Composed of 2329 links, representing the inclusion and contact relationships between different levels. Composed of 14,462 links, it describes the physical adjacency relationships between entities. Through the hierarchical organization of nodes and the semantic definition of relationships, the graph database provides an explicit representation of the structural composition and local topological connectivity of LNG storage tanks.

[0090] Figure 7 The paper further demonstrates an application example based on a graph database (i.e., an ontology graph database). First, a target node (e.g., an inner tank wall panel) is selected from the ontology graph database, and its local relational subgraph is retrieved to obtain the corresponding hierarchical relationships, adjacency relationships, and associated attribute information. Then, the retrieved node data is parsed into a structured representation containing node categories, relational semantics, and engineering attributes (corresponding to node labels, variant types, and attribute key-value pairs in the graph database, respectively). For example, a wall panel node can be associated with geometric attributes of a thickness of 9 mm and a height of 2500 mm, as well as the material properties of steel grade S30408. Finally, the query results are mapped to a 3D model, achieving step-by-step location and visualization of the target component and its corresponding structural hierarchy. The node types, relational semantics, and attribute patterns in the graph database maintain strict structural consistency with the ontology definition, validating the effective coverage and instantiation operability of the proposed ontology graph database.

[0091] In summary, this invention addresses the challenge of integrating multi-source heterogeneous data in LNG tank design by proposing a method for constructing an LNG tank body diagram database. Its contribution lies in:

[0092] First, an ontology for the LNG storage tank domain was constructed, following a multi-level hierarchical structure of "assembly-component-part". Adopting a progressive development strategy, two core relationships—composition and contact—were defined, along with three types of attributes: location, geometry, and material. This ontology provides a unified semantic dictionary for different disciplines, eliminating terminological ambiguity.

[0093] Second, a complete mapping mechanism from the OWL ontology to the tag attribute graph was established, including schema-level mapping and instance-level mapping. This mechanism ensures that knowledge in the ontology can be losslessly converted into a computable and queryable graph structure.

[0094] Third, a dynamic evolution and multi-pattern extraction method for graph databases is proposed. It supports two incremental operations: structural adjustment and attribute update, avoiding full graph reconstruction for every design change. It also provides entity, path, and sub-database extraction methods. Figure 3 It offers several extraction modes and outputs standardized JSON format, facilitating integration with downstream applications such as finite element analysis, IFC export, and visualization rendering.

[0095] Fourth, with a Using a double-walled steel LNG storage tank as a case study, an ontology graph database containing 2330 nodes and 16791 relationships was successfully instantiated. The feasibility, scalability, and semantic consistency of the method were verified through graph querying, attribute parsing, and 3D model generation.

[0096] The established unified graph database provides a solid digital foundation for the integrated management, collaborative generation, and intelligent optimization of interdisciplinary design data for LNG storage tanks, and also provides a reference paradigm for knowledge modeling and data management of other complex industrial facilities.

[0097] Example 2

[0098] Corresponding to the LNG tank body diagram database construction method provided in Embodiment 1 above, this embodiment of the invention provides an LNG tank body diagram database construction system, including:

[0099] The ontology construction module is used to obtain various design task information of LNG storage tanks and construct an ontology of the LNG storage tank domain based on the design task information. The ontology of the LNG storage tank domain includes a concept set, a relationship set, and an attribute set. The concept set includes structural concepts at three levels: assembly level, component level, and part level. The relationship set includes compositional relationships and contact relationships. The attribute set includes location attributes, geometric attributes, and material attributes.

[0100] The graph database generation module is used to convert the ontology of LNG storage tanks into the architectural constraints of the graph database, and to instantiate the engineering data of LNG storage tanks into the graph database according to the architectural constraints, thereby generating the ontology graph database.

[0101] The graph database evolution module is used to perform incremental update operations on the ontology graph database in response to modification requests.

[0102] The data extraction module is used to respond to data extraction requests from the graph database, extract target data from the ontology graph database, and output it.

[0103] The specific functions of each module correspond to the steps in the above method embodiments, and will not be repeated here.

[0104] In terms of hardware implementation, the system can be deployed on general-purpose computing devices, which include at least one or more processors (such as a central processing unit (CPU) or a graphics processing unit (GPU) and coupled storage media (such as a solid-state drive or memory). The storage media stores computer program instructions, and the processor executes the program instructions to implement the method steps as described in Example 1. For the massive node and relationship data involved in large-scale LNG storage tank design projects (such as the scale of 2330 nodes and 16791 relationships in Example 1), the system can adopt a distributed graph database cluster as the underlying storage engine, supporting the efficient execution of complex topology queries and large-scale graph traversal operations through a multi-node parallel computing architecture. In terms of interaction, the system can be configured as stand-alone engineering design software, or it can be encapsulated as an application programming interface (API) service or integrated as a plug-in into existing structural analysis platforms (such as ANSYS or ABAQUS) or building information modeling platforms (such as Revit or CATIA), providing transparent graph database access capabilities to the upstream design end. On the data output end, the system communicates decoupled from external computing modules through a standardized JSON data interface, and can directly connect to finite element analysis preprocessing programs, IFC model generators or STL visualization rendering engines to achieve one-click data derivation from a unified graph database to multi-professional application models.

[0105] This system, through its integrated modular architecture, organically integrates ontology construction, graph database generation, dynamic evolution, and data extraction in the LNG storage tank design process, providing a complete data infrastructure for the multidisciplinary collaborative design of large LNG storage tanks. In practical engineering applications, the system effectively breaks down data barriers between structural analysis, building information modeling, and visualization, eliminates ambiguity in cross-disciplinary terminology, avoids information loss during model conversion, and achieves unified expression and computable storage of design knowledge. Simultaneously, the system's built-in incremental update mechanism eliminates the need to rebuild the entire model for design changes, significantly reducing computational overhead and improving the efficiency of iterative design for large-scale, complex storage tanks. With its clear architecture and strong scalability, the system can directly serve practical scenarios such as intelligent design, scheme comparison, and compliance review in LNG storage tank engineering, and also provide valuable reference for knowledge modeling and cross-system data collaboration in other large-scale industrial facilities.

[0106] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for constructing an LNG storage tank body diagram database, characterized in that, include: Obtain various design task information for LNG storage tanks, and construct an LNG storage tank domain ontology based on the design task information. The LNG storage tank domain ontology includes a concept set, a relationship set, and an attribute set. The concept set includes structural concepts at three levels: assembly level, component level, and part level. The relationship set includes compositional relationships and contact relationships. The attribute set includes location attributes, geometric attributes, and material attributes. The LNG storage tank ontology is converted into the architectural constraints of a graph database, and the engineering data of the LNG storage tank is instantiated into the graph database according to the architectural constraints to generate an ontology graph database. In response to the modification request, an incremental update operation is performed on the ontology graph database; In response to a data extraction request, target data is extracted from the ontology graph database and output.

2. The method for constructing an LNG storage tank body diagram database according to claim 1, characterized in that, The construction of the LNG storage tank ontology based on the design task information includes: The design scope is defined jointly by multiple LNG storage tank design tasks, and an initial ontology is constructed based on the design scope. For any design task, the incremental knowledge corresponding to the design task is organized into concept increments, relation increments, and attribute increments; The concept increment, relation increment, and attribute increment are performed with terminology alignment and consistency verification, and the verified incremental knowledge is incorporated into the core ontology library.

3. The method for constructing an LNG storage tank body diagram database according to claim 2, characterized in that, The process of organizing the incremental knowledge corresponding to the design task into concept increments, relation increments, and attribute increments includes: New concepts are added to the initial ontology through keyword extraction and expansion mechanisms, and / or concepts from different ontologs are combined through a combination mechanism to obtain the concept increment.

4. The method for constructing an LNG storage tank body diagram database according to claim 1, characterized in that, The composition relation is used to express the physical inclusion relationship between concepts at different levels, and the composition relation satisfies the transitivity axiom; the contact relation is used to express the adjacency relationship between concepts at the same level, and the contact relation satisfies the symmetry axiom.

5. The method for constructing an LNG storage tank body diagram database according to claim 1, characterized in that, The process of converting the LNG storage tank ontology into a graph database based on architectural constraints, and instantiating the engineering data of the LNG storage tank into the graph database according to the architectural constraints to generate an ontology graph database, includes: Pattern-level mapping: Parse the concept set, relation set, and attribute set from the network ontology language file of the LNG storage tank domain ontology, map each concept in the concept set to a node label in the graph database, map each relation in the relation set to an edge type in the graph database, map each attribute in the attribute set to an attribute key-value pair in the graph database, and generate edge endpoint constraint functions according to the domain and scope constraints in the network ontology language file; Instance-level mapping: Under the aforementioned architectural constraints, each data instance in the engineering data of the LNG storage tank is mapped to a node in a graph database, wherein the label of the node contains the direct type of the data instance and all its parent types; each relation assertion in the engineering data instance is mapped to a directed edge between corresponding nodes in the graph database, wherein the direction of the directed edge is from the source node of the relation assertion to the target node, and the label of the directed edge is the relation name of the relation assertion; each attribute assertion in the engineering data instance is stored as a key-value pair in the attribute of the corresponding node.

6. The method for constructing an LNG storage tank body diagram database according to claim 5, characterized in that, In the schema-level mapping, the node label set of the ontology graph database From the formula Define, where For the set of concepts, for Any concept in For mapping functions, For the concept The mapped node labels; the set of edge types in the ontology graph database. From the formula Definition, where For the set of relations, for Any relation in, For relationship The edge type obtained from the mapping; the set of attribute key-value pairs in the ontology graph database. From the formula Definition, where For the attribute set, for Any attribute in, For attributes key name, For attributes Data type; edge endpoint constraint function From the formula definition, Each edge type is mapped to a pair of node labels to specify the source node label and the target node label to which the edge connects.

7. The method for constructing an LNG storage tank body diagram database according to claim 6, characterized in that, The instance-level mapping includes: a set of engineering data instance records. Any data instance in Create graph nodes , tag collection Includes the data instance direct type and all its parent types; and, the set of relation assertions. Any two data instances Relationship assertion In these two data instances Corresponding graph nodes and Directed edges are generated between them. The directed edge endpoint functions The directed edge The tag is ; and, for data instances Property assertions Property assertions are made through property mapping functions. key-value pairs Stored to the graph node In the attributes.

8. The method for constructing an LNG storage tank body diagram database according to claim 1, characterized in that, The incremental update operation on the ontology graph database includes: When the modification request is a structural adjustment, a topology sequence is generated from the source node to the target node along a specified path. The topology sequence contains nodes and edges and is used to insert new components or remove obsolete components. When the modification request is an attribute update, the internal parameter value of the target node is modified directly.

9. The method for constructing an LNG storage tank body diagram database according to claim 1, characterized in that, The step of extracting and outputting target data from the ontology graph database includes: When the data extraction request is entity extraction, the system filters out individual nodes that meet the query conditions based on node tags and node attributes, and outputs the tags and attributes of the nodes. When the data extraction request is path extraction, under the specified edge type constraint, a simple path consisting of a continuous sequence of relations and without duplicate nodes is obtained by traversing from the source node to the target node, and the attributes of each node, each edge and each node in the path are output. When the data extraction request is a subgraph extraction, a connected subgraph is extracted with the specified node as the root, and the node set, edge set, and attributes of each node in the node set of the connected subgraph are output.

10. An LNG storage tank body diagram database construction system, using the LNG storage tank body diagram database construction method according to any one of claims 1 to 9, characterized in that, The system includes: The ontology construction module is used to acquire various design task information of LNG storage tanks and construct an ontology of the LNG storage tank domain based on the design task information. The ontology of the LNG storage tank domain includes a concept set, a relationship set, and an attribute set. The concept set includes structural concepts at three levels: assembly level, component level, and part level. The relationship set includes compositional relationships and contact relationships. The attribute set includes location attributes, geometric attributes, and material attributes. The graph database generation module is used to convert the LNG storage tank ontology into the architectural constraints of the graph database, and to instantiate the engineering data of the LNG storage tank into the graph database according to the architectural constraints, thereby generating the ontology graph database. The graph database evolution module is used to perform incremental update operations on the ontology graph database in response to a modification request for the graph database. The data extraction module is used to extract target data from the ontology graph database and output it in response to a data extraction request from the graph database.

Images