Pressure vessel fault tracing method and device based on xBOM

Abstract

The invention provides a pressure vessel fault tracing method and device based on xBOM. The method provided by the invention comprises the following steps: collecting multi-source heterogeneous data of a full life cycle of a pressure vessel, and generating a structured data set; establishing an ontology model according to the component structure and function relationship of the pressure vessel; generating a plurality of semantic BOM models based on the life cycle and the mapping relation between the structured data and the materials, and combining the semantic BOM models to form an xBOM data model of the pressure vessel; based on the real-time working state data and a preset traceability strategy matrix table, whether a traceability triggering condition is met is judged; when a condition is satisfied, determining a traceability parameter according to the traceability strategy matrix table; and according to the traceability parameter and the fault point corresponding to the real-time working state data, executing traceability analysis in the xBOM data model to generate a fault traceability result. According to the method provided by the invention, the rapid positioning and root cause tracing of the pressure vessel fault can be realized, and the equipment operation safety and the management intelligence level are improved.

Description

Technical Field

[0001] This application relates to the field of pressure vessel risk monitoring technology, and in particular to a method and apparatus for tracing pressure vessel failures based on xBOM. Background Technology

[0002] Pressure vessels, as crucial pressure-bearing equipment in energy, chemical, and equipment manufacturing sectors, are widely used in strategic high-tech and industrial production processes, serving as key foundational equipment for modernization and major national projects. Due to the complex operating conditions they typically contain, including high temperatures, high pressures, flammability, and explosiveness, leaks or explosions in pressure vessels can cause severe casualties and economic losses. Therefore, their safety and reliability have always been a key research focus in the equipment manufacturing and safety engineering fields.

[0003] The current industry standard is periodic maintenance. This model typically involves inspection and maintenance at uniform intervals, failing to adequately consider the varying service environments, load changes, and material aging differences of different containers. This leads to issues of "under-maintenance" or "over-maintenance" for some equipment, increasing maintenance costs and hindering the prevention of sudden failures. To improve the accuracy and safety of maintenance, there is an urgent need to establish a full lifecycle management system capable of supporting dynamic monitoring and precise decision-making.

[0004] However, the complexity of pressure vessel safety management lies not only in monitoring and maintenance but also in data collaboration and traceability throughout the entire lifecycle. Data generated at each stage—design, manufacturing, operation, testing, and maintenance—is often scattered across different heterogeneous systems, such as CAD / PLM, ERP / MES, and RBI / CMMS systems. Some information is even stored in paper or offline document form, creating data silos and hindering information flow. This data collaboration deficiency breaks the information chain throughout the pressure vessel lifecycle, making it difficult to achieve closed-loop management from design to manufacturing, operation, and testing.

[0005] When equipment malfunctions or fails, the lack of a seamless traceability channel prevents the system from quickly tracing back to the source stages such as design, manufacturing, and testing, resulting in low efficiency, wide scope, and difficulty in fault location during analysis. Therefore, traditional pressure vessel supervision and traceability methods are no longer sufficient to meet the needs of intelligent operation and maintenance and safety supervision. There is an urgent need to build a data association and intelligent traceability system covering the entire lifecycle to support equipment safety assessment and root cause analysis. Summary of the Invention

[0006] In view of this, this application provides a method and apparatus for tracing pressure vessel faults based on xBOM, in order to solve the problems of fragmented data, inaccurate maintenance, and difficulty in tracing faults in existing pressure vessel systems.

[0007] Specifically, this application is implemented through the following technical solution:

[0008] The first aspect of this application provides a method for tracing faults in pressure vessels based on xBOM, the method comprising:

[0009] Collect multi-source heterogeneous data throughout the entire lifecycle of the pressure vessel to generate a structured dataset;

[0010] Based on the component structure and functional relationships of the pressure vessel, a body model of the pressure vessel is established;

[0011] Multiple semantic BOM models are generated based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel and includes multiple materials and semantic relationships between the materials.

[0012] The relationships between the semantic BOM models are determined based on the ontology model, and the xBOM data model is generated by combining them.

[0013] Based on the real-time operating status data of the pressure vessel and the preset traceability strategy matrix table, determine whether the traceability triggering conditions are met.

[0014] Based on the triggering conditions and the preset source tracing strategy matrix table, the source tracing parameters are determined;

[0015] Based on the fault points corresponding to the traceability parameters and the real-time working status data, a fault traceability result is generated.

[0016] A second aspect of this application provides a pressure vessel traceability device based on xBOM, the device comprising a data acquisition module, a data construction module, a prediction module, and a determination module; wherein...

[0017] The acquisition module is used to collect multi-source heterogeneous data throughout the entire life cycle of the pressure vessel and generate a structured dataset.

[0018] The construction module is used to establish a body model of the pressure vessel based on the component structure and functional relationships of the pressure vessel.

[0019] The construction module is used to generate multiple semantic BOM models based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel, and each semantic BOM model includes multiple materials and semantic relationships between the materials.

[0020] The construction module is used to determine the relationship between the semantic BOM models based on the ontology model and combine them to generate an xBOM data model.

[0021] The judgment module is used to determine whether the traceability triggering conditions are met based on the real-time working status data of the pressure vessel and the preset traceability strategy matrix table.

[0022] The determining module is used to determine the tracing parameters based on the triggering conditions and the preset tracing strategy matrix table;

[0023] The determining module is used to generate fault tracing results based on the tracing parameters and the fault points corresponding to the real-time working status data.

[0024] The xBOM-based method and apparatus for tracing pressure vessel failures provided in this application constructs an xBOM data model covering the entire lifecycle of a pressure vessel by combining semantic BOM data models throughout the entire lifecycle. This ensures semantic relationships between nodes in the data models, nodes within the same BOM data model, and nodes between different BOM data models. Data management overcomes the limitations of the BOM data model itself, achieving unified management and traceability of multi-source heterogeneous data from pressure vessels. First, by collecting multi-source heterogeneous data from the entire lifecycle of the pressure vessel, a structured dataset is generated, solving the problems of scattered information and inconsistent formats in traditional systems. Second, an ontology model is established based on the component structure and functional relationships. Then, multiple semantic BOM models are generated based on the pressure vessel's lifecycle and the mapping relationship between the structured dataset and materials. Finally, the relationships between the various semantic BOM models are determined based on the ontology model, and they are combined to generate an xBOM data model, thereby establishing a data link throughout the entire lifecycle of the pressure vessel and achieving semantic association and traceable management of the data. Based on this, using real-time operating status data of the pressure vessel and a pre-defined traceability strategy matrix, the system determines whether the traceability triggering conditions are met. When the triggering conditions are met, the system combines the triggering conditions and the traceability strategy matrix to determine the corresponding traceability parameters. Subsequently, based on the traceability parameters and the fault points corresponding to the real-time operating status data, traceability analysis is performed in the xBOM data model to generate fault traceability results, enabling rapid backtracking and analysis of the fault source. This method significantly improves the correlation and traceability of pressure vessel lifecycle data, enhances the efficiency of fault analysis and risk warning, reduces manual intervention and judgment errors, and strengthens the system's intelligent operation and maintenance and safety management capabilities. Attached Figure Description

[0025] Figure 1 A flowchart of an embodiment of the xBOM-based pressure vessel fault tracing method provided in this application;

[0026] Figure 2 A schematic diagram of a risk matrix shown in an exemplary embodiment of this application;

[0027] Figure 3This is a schematic diagram of the structure of the xBOM-based pressure vessel fault tracing device provided in this application, according to Embodiment 1. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0029] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0030] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0031] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0032] Figure 1 This is a flowchart of an embodiment of the xBOM-based pressure vessel fault tracing method provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:

[0033] S101. Collect multi-source heterogeneous data of the entire life cycle of the pressure vessel and generate a structured dataset.

[0034] Specifically, the process involves collecting multi-source heterogeneous data generated throughout the entire lifecycle of pressure vessels, including design, manufacturing, inspection, and operation and maintenance. This data may originate from various systems or document formats, such as CAD systems, MES systems, ERP systems, PLM systems, quality inspection reports, operation monitoring logs, maintenance records, ultrasonic inspection images, and scanned paper documents. Through data parsing, standardization, and cleaning, the raw unstructured or semi-structured data is transformed into a structured dataset with a consistent identification system and standard field definitions, thus establishing a data foundation for cross-stage information association and traceability.

[0035] Optionally, in one possible implementation, generating the structured dataset may include:

[0036] (1) Analyze the multi-source heterogeneous data topic, determine the target metadata template corresponding to it, and extract the target data from the multi-source heterogeneous data based on the metadata tags in the target metadata template.

[0037] Specifically, the multi-source heterogeneous data themes are parsed, with multiple metadata templates corresponding to different business themes. These business themes include stages such as design, manufacturing, testing, operation, and maintenance. Each metadata template under a business theme can be defined for a specific data source or data type. For example, a design theme might include CAD model templates, bill of materials templates, and design change record templates; a manufacturing theme might include process parameter templates, equipment operating condition templates, and quality inspection templates. Each metadata template defines the field names, data types, unit standards, and key identifier mapping rules for the corresponding data, enabling unified parsing and structured representation of data from different sources.

[0038] Furthermore, the system extracts target data from multiple heterogeneous data sources one by one based on the metadata tags in the selected target metadata template. Specifically, it reads the metadata tags corresponding to each field in the target metadata template and extracts or calculates the target data from the data source based on the metadata tags. For structured data, fields can be read directly from the system interface; for semi-structured data, keyword positioning and table extraction algorithms are used to extract key parameters; for unstructured data, deep learning or OCR models are used to identify key parameters. For example, the YOLOv5 weld defect recognition model can be used to extract defect coordinates from ultrasonic inspection images, or an OCR model can be used to identify text content from scanned materials. It should be noted that the above classification and algorithm selection can be flexibly adjusted according to the data type and characteristics, and are not limited to a specific implementation method.

[0039] (2) Fill the target data into the target metadata template to obtain a structured dataset.

[0040] Specifically, before filling the target data into the target metadata template, the system first constructs the metadata template. The construction of the metadata template mainly includes:

[0041] A) Perform semantic analysis on multi-source heterogeneous data to identify the business themes of each data object.

[0042] Specifically, the system reads the metadata of each data object, including field names, field descriptions, data types, and their business tags in the original system. Then, by matching these with business concepts in a predefined business rule base, it determines the functional affiliation of the data object. Simultaneously, the system analyzes field content and data value characteristics, such as whether they are associated with design parameters, manufacturing parameters, inspection records, or operational monitoring data. Based on the analysis results, the data object is labeled with its corresponding business theme, such as design, manufacturing, inspection, operation, or maintenance. In this way, the system classifies multi-source heterogeneous data according to business themes. The implementation process of the rule base is described in subsequent methods and will not be repeated here.

[0043] B) Analyze the data structure of each business theme and extract the relevant field sets.

[0044] Specifically, the system scans all data tables, data files, or interfaces under each business theme, identifying field names and their basic attributes, including data type, unit, value range, and key identifiers. Subsequently, the system analyzes the relationships between fields, such as parent-child fields, dependent fields, or repeating fields, to identify the logical structure and hierarchical relationships of the fields. Through systematic organization of each field, its attributes, and relationships, a complete field set is formed for the subsequent generation and standardized management of candidate field component templates.

[0045] C) Classify each field in the field set according to its purpose and semantics, and generate candidate field component templates.

[0046] Specifically, the system labels the purpose of each field, for example, identifying whether a field is used to describe component geometry, material properties, process parameters, test results, or operating status. Then, the system uses semantic analysis to identify semantic relationships between fields, such as synonyms, hierarchical relationships, or functional associations. Finally, based on the purpose labels and semantic relationships, related fields are grouped together to form candidate field component templates. Through this method, fields with similar functions or purposes are categorized into reusable components, providing a unified and standardized data structure for different business themes or subsequent template expansions.

[0047] D) Calculate the field similarity and semantic relevance between the candidate field component template and each field component template.

[0048] Specifically, after the candidate field component template is generated, the system compares it with existing field component templates to calculate field similarity and semantic relevance. This step includes: comparing the meta-attributes of fields in the candidate template and existing templates, such as field names, data types, units, key identifiers, and semantic tags; analyzing the functional relationships and usage consistency between fields, such as whether fields all represent pressure, temperature, stress, or material parameters; and then, based on preset similarity calculation methods, such as methods based on name edit distance, type matching rate, and comprehensive semantic similarity scoring, generating similarity values ​​between the candidate template and each existing template.

[0049] E) When the semantic relevance between a candidate field component template and a certain field component template is higher than a threshold, the candidate field component template inherits the common fields of that field component template and extends its feature fields; otherwise, a new field component template is created.

[0050] Specifically, after the system generates candidate field component templates, it calculates their semantic relevance with existing field component templates. If the semantic relevance between a candidate template and one or more existing field component templates is higher than a preset threshold, the system will allow the candidate field component template to inherit the common fields of these existing field component templates and expand the feature fields of the candidate field component template based on the actual scenario needs, forming a new field component template. If the semantic relevance between a candidate field component template and all existing field component templates does not reach the threshold, a new field component template is directly created. The threshold here can be set according to the actual scenario and data complexity to ensure that the inheritance relationship can reasonably reflect the semantic relevance of the fields; it is not limited here. Since a candidate field component template may have inheritance relationships with multiple existing field component templates simultaneously, a network structure is formed between the field component templates, and each template node can inherit fields from multiple existing field component templates. This network structure realizes field reuse and standardized management, while also supporting dynamic expansion.

[0051] Furthermore, the system fills the target data into the target metadata template to obtain a structured dataset. The metadata template defines a general data description structure, including at least field names, data types, unit standards, and key identifier mapping rules. For example, the "part number" field in the design system and the "part code" field in the manufacturing system are mapped to a unified material identifier (Material_ID) to achieve cross-system field correspondence and semantic alignment. This structured processing provides a unified data description foundation for subsequent semantic modeling. The system further performs unified mapping and indexing of the parsing results based on the established metadata template, forming a standardized, complete, and consistent structured dataset.

[0052] It should be noted that for missing or abnormal data, the system performs verification and completion based on predefined data quality rules. These rules ensure the accuracy and completeness of the structured dataset and include rules for field completeness, numerical reasonableness, uniqueness constraints, and logical consistency. The system can configure and extend these rules according to the characteristics of different data sources and application scenarios. In actual implementation, the generated structured data units undergo quality checks to identify missing fields, abnormal values, and logical conflicts. For example, data completeness is determined by checking the non-emptiness of key fields, unit consistency, and identifier matching; numerical anomalies deviating from the normal range are identified through threshold range verification or historical statistical comparison; and attribute conflicts of the same material at different stages are detected through cross-table join comparisons.

[0053] Furthermore, for detected abnormal data, the system performs automated correction and completion processing based on predefined rules. For missing data, methods such as historical data backfilling, inference from similar samples, or model prediction can be used for completion; for abnormal data, rules can be set for replacement, smoothing, or discarding; for conflicting data, selective retention can be based on timestamps, data source credibility, or business priority. These processing strategies can be flexibly configured according to business needs and are not limited to specific algorithms.

[0054] It should be noted that, to ensure the traceability and verifiability of the data correction process, the system can generate a data quality log during the correction and completion process. This log records the original value, correction strategy, and correction result of each data entry, and establishes a unique identifier for subsequent traceability and auditing. Through these steps, anomalies, missing information, or conflicts in structured data units are corrected and completed, thereby forming a unified, accurate, and traceable structured dataset.

[0055] S102. Based on the component structure and functional relationships of the pressure vessel, establish the main body model of the pressure vessel.

[0056] Specifically, the system builds an ontology model based on a structured dataset to describe the structural and functional relationships of pressure vessel components, thereby extending the data layer to the semantic layer and enabling knowledge modeling. The ontology model construction steps include at least:

[0057] A) Based on the component structure information of the pressure vessel, generate nodes for the ontology model, with each node containing corresponding attribute information.

[0058] Specifically, the system establishes each component as a node in the ontology model based on the structural information of the pressure vessel components. Each node contains multiple attribute information from the structured dataset, which includes at least: a) geometric information, such as length, diameter, and thickness; b) material properties, such as material type, strength grade, and corrosion resistance; c) manufacturing process, such as welding method and heat treatment state; d) detection parameters, such as allowable stress and fatigue life; and e) service environment, such as operating pressure, temperature, and medium type.

[0059] B) Establish functional association edges between nodes based on the functional relationships between component entities, and calculate the strength of the association between nodes.

[0060] Specifically, the system establishes functional association edges based on the functional relationships between nodes. Each edge represents logical relationships such as functional dependencies, load transfer, or sealing constraints between components. Edge establishment is based on at least the following: a) Node attribute matching: If node A and node B have a physical connection in terms of interface, load, or energy transfer, an edge is established. For example, if a shell node and a flange node are structurally directly connected and bolted together, and the shell is subjected to internal pressure during operation, this load is transferred to the support node through the flange, thus establishing an edge between the shell node and the flange node to represent the load transfer relationship. b) Functional dependency rules: The system determines whether an interaction relationship exists based on the component functional dependency rules in the rule base. For example, if the opening function of a safety valve node depends on the shell pressure exceeding a set value, an edge is established between the safety valve node and the shell node to represent the functional dependency. c) Design standard constraints: The system determines the connection or support relationship between nodes based on standards such as GB150 and ASME VIII. For example, according to ASME VIII standards, a support plate must form a fixed support with the cylinder. If a support plate node is located below a cylinder node and bears the cylinder load, an edge is established to represent the support relationship.

[0061] Furthermore, the system extracts component assembly relationship tables, energy flow paths, and signal communication topologies from the structured dataset. Based on their source and attributes, functionally related edges are classified into the following connection types: a) Structural connections: derived from 3D assembly models or CAD assembly tables, used to describe structural couplings such as physical contact, welding, riveting, and bolting; b) Capacity transfer: derived from thermal, fluid, or electrical system design documents, used to describe energy transfer relationships such as heat conduction, fluid flow, and current transmission; c) Signal interaction: derived from control system network topology or I / O mapping tables, used to describe logical dependencies of signal input / output, communication protocols, or control commands; d) Functional coupling: derived from the system functional decomposition model, used to describe task dependencies between different subsystems, such as "drive module → actuator". The system automatically analyzes and classifies the above data sources through keyword matching, attribute tag recognition, and topology relationship parsing algorithms to determine the connection type identifier of each edge.

[0062] Furthermore, different calculation methods are used to calculate the connection strength of the edges based on the connection type. The calculation methods for the different edge types include: a) Structural connection edges: The stiffness matrix or node response vector of the node contact area is extracted from the finite element model, and the coupling stiffness is calculated based on the displacement compatibility relationship under load. For components with abundant historical monitoring data, the least squares fitting method can be used to calculate the correlation coefficient of stress-strain response as an indicator of structural coupling strength. b) Energy transfer edges: The system calculates the connection strength based on the energy flux density or transfer efficiency between nodes. Taking heat conduction edges as an example, the steady-state heat flux is calculated by extracting the temperature gradient of the nodes and the thermal conductivity of the materials; taking fluid transmission edges as an example, the transfer efficiency is determined based on flow rate, pressure difference, and energy loss coefficient. c) Signal interaction edges: The system calculates the connection strength based on the delay characteristics of the signal path, the signal amplitude attenuation ratio, and the communication frequency. By parsing communication logs or sampled data, the average signal delay and packet loss rate between nodes are statistically analyzed, and then a normalization transformation is used to obtain the strength index in the [0,1] interval. d) Functional coupling edge: The system calculates the strength based on the degree of functional dependence and the tightness of the task execution sequence, for example, by statistically analyzing the task triggering time interval, the number of mutual calls, or the resource sharing ratio to determine the functional coupling weight.

[0063] Furthermore, the weights of edges are calculated based on structured datasets, rule bases, and knowledge bases. Specifically, the system extracts edge data information from the structured dataset, including parameters such as connection type, connection location, number of connections, stress characteristics, and historical stability. Simultaneously, it reads type factor parameters corresponding to different edge connection types from the rule base or knowledge base to reflect the fundamental importance of that type of connection in the overall system; for example, the type factor for main load-bearing structural connections is higher than that for signal transmission connections. The rule base includes component function dependency rules, connection constraints, attribute inheritance rules, and design standard constraints; the knowledge base includes historical component structural information, functional information, failure modes, and industry standard data, which are established based on historical project experience, accumulated CAD / PLM data, and industry standards. Based on this, the system combines operational monitoring data from the structured dataset, such as stress distribution, load change frequency, maintenance records, and fault statistics, and uses the Analytic Hierarchy Process (AHP) or weighted regression model to calculate the importance factor of each specific connection in actual operation. Finally, the edge weight is determined by the connection strength, the comprehensive importance parameter (type factor × importance factor), and the historical stability index. The system normalizes and weights these three factors to obtain the edge weight value.

[0064] C) Model the state behavior of nodes based on the data information of nodes and edges.

[0065] Specifically, the system extracts operational status parameters for each node from the structural dataset. These parameters may include real-time monitoring data such as stress, strain, temperature, vibration acceleration, current, voltage, flow rate, and pressure. Then, the system performs time alignment, anomaly removal, and normalization on these operational status parameters to obtain node state feature vectors. Subsequently, combining the node's material properties, geometric parameters, and manufacturing processes with static characteristics, the system uses finite element analysis or empirical models to calculate the node's response behavior under different operating conditions. For example, by setting external loads, boundary conditions, and environmental parameters, the system calculates the node's stress distribution, deformation, and vibration characteristic values. For complex nodes that cannot be directly modeled, least squares fitting or neural network regression methods can be used to fit the node's stress-strain relationship or temperature-deformation law based on historical monitoring data. Finally, after obtaining the response results under different operating conditions, the system compares the changing trends of node state characteristics at different times or load levels to establish state transition relationships, which are used to characterize the evolution process of the node from a normal state to an abnormal or failed state. The system identifies typical failure modes of nodes based on historical operating data and detection records, including crack propagation, weld fatigue, corrosion perforation, and seal leakage. By analyzing the state feature vector at the time of failure and the corresponding triggering thresholds (such as stress upper limit, corrosion rate critical value, or fatigue cycle number threshold), the system establishes a mapping relationship between failure modes and triggering conditions, which is used to determine the health level of node status in real time during operation. Through the above process, the system unifies the static attributes and dynamic states of nodes into a parameterized model, forming a node state behavior sub-model. Each node contains a state feature vector, response characteristic parameters, failure mode, and triggering conditions, which can support subsequent health assessment and risk prediction.

[0066] Furthermore, based on the node state behavior sub-model, an edge state propagation model is constructed by combining edge weights. Specifically, the system first establishes an adjacency matrix based on the topological relationship between nodes and edges to identify the connection relationships between each node, and forms a weighted graph representation by combining edge weights. Further, combining the node state behavior sub-model, the system calculates the edge weights between the state feature vector generated by each node and its adjacent nodes, processes all nodes and their adjacent nodes sequentially according to the node topology, and fills the adjacency matrix with the influence relationships between all nodes, thus obtaining the complete state propagation matrix. During system operation, the state propagation matrix can be dynamically updated as the node state changes to reflect the cascading impact of local anomalies or failures on the overall system. When a node state is detected to have reached a failure threshold, the system calculates the risk increment of the affected nodes based on the propagation matrix and predicts potential failure propagation paths along edges with higher weights. Through the joint analysis of node state and edge propagation relationships, the system can achieve early warning and source tracing analysis of potential faults.

[0067] In summary, after constructing the node, edge, state behavior sub-models, and state propagation model, the system generates a complete pressure vessel ontology model. The ontology model is represented in graph form, where each node corresponds to a component entity and its static attributes and dynamic state characteristics; each edge represents the functional, structural, or standard constraint relationships between nodes; the node state behavior sub-model records the response characteristics and typical failure modes of nodes under different operating conditions; and the state propagation model depicts the transmission path of dynamic states between nodes. By unifying and integrating node, edge, state behavior, and state propagation information, the ontology model achieves a unified description of static and dynamic attributes at both the component and system levels, providing a computable, searchable, and reusable knowledge foundation for subsequent risk prediction, health assessment, fault tracing, and decision support.

[0068] S103. Generate multiple semantic BOM models based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel and includes multiple materials and semantic relationships between the materials.

[0069] Specifically, based on the pressure vessel ontology model and combined with the lifecycle stage division and material information in the structured dataset, a multi-stage BOM model with semantic association capabilities is constructed. This semantic BOM model describes the hierarchical structure, attribute information, and semantic relationships of materials in different lifecycle stages, enabling data integration and semantic alignment across multiple stages, including design, manufacturing, testing, and operation and maintenance.

[0070] Optionally, in one possible implementation, generating multiple semantic BOM models based on the lifecycle of the pressure vessel and the mapping relationship between the structured dataset and materials may include:

[0071] (1) Determine the life cycle segments of the pressure vessel.

[0072] Specifically, based on the engineering management specifications and actual production practices of pressure vessels, the system divides the entire lifecycle into design, manufacturing, inspection, operation, and maintenance phases, with each phase corresponding to different data sources and business activities. For example, the design phase focuses on structural configuration and material selection; the manufacturing phase focuses on welding and assembly process parameters; the inspection phase includes quality inspection and non-destructive testing records; the operation phase includes real-time monitoring and operating logs; and the maintenance phase includes repair and replacement records. This segmentation approach can be expanded or refined according to project characteristics and enterprise management processes to support multi-level lifecycle modeling.

[0073] (2) Determine the BOM model for each stage based on the material requirements corresponding to each life cycle segment. Each BOM model includes multiple materials corresponding to the life cycle segment and the attributes of the materials.

[0074] Specifically, based on the bill of materials and material attribute information in the structured dataset, and combined with the component hierarchy in the ontology model, the system generates a corresponding BOM model for each lifecycle stage. Each BOM model includes multiple material nodes, and each node contains attribute information such as material number, name, specifications, material, process parameters, and design status. This approach forms a hierarchical BOM model system corresponding to each lifecycle stage, enabling structural description and attribute aggregation of materials within each stage.

[0075] (3) Determine the component structure associated with each data object in each structured dataset, and determine the semantic association of each data object based on the relationship between the component structures in the ontology model.

[0076] Specifically, the system maps materials at each stage to component entities in the ontology model based on material codes, component identifiers, and associated fields in the structured dataset. Then, it determines the semantic relationships between data objects at different stages by considering the functional dependencies, connectivity relationships, and positional relationships between component entities defined in the ontology model. For example, based on the "geometric mapping" rule, weld numbers in the design model can be mapped to weld inspection IDs in the inspection report; based on the "process mapping" rule, semantic relationships can be established between welding current parameters in the manufacturing stage and process specification entries. Furthermore, semantic matching can be performed between monitoring data in the operation and maintenance stage and stress analysis results in the design stage. Through these multi-level mapping rules, semantic relationships between data objects across multiple stages, including design, manufacturing, inspection, and operation and maintenance, are achieved.

[0077] (4) Determine the BOM model to which each data object belongs, establish the correspondence between the structured dataset with semantic association and the BOM model, generate a semantic BOM model, each semantic BOM model includes multiple material nodes, each material node includes material attribute information, and the multiple material nodes in each semantic BOM model have the semantic association.

[0078] Specifically, based on lifecycle segmentation information and semantic relationships defined in the ontology model, the system identifies the stage attributes and functional affiliations of each data object in the structured dataset and assigns them to the corresponding BOM model for each lifecycle stage. Taking a pressure vessel as an example, the lifecycle can be divided into design, manufacturing, inspection, and operation and maintenance stages, with each stage corresponding to a BOM model: the design stage BOM model includes structural component nodes, stress analysis nodes, and design parameter nodes; the manufacturing stage BOM model includes weld nodes, assembly nodes, and material batch nodes; the inspection stage BOM model includes radiographic inspection nodes, pressure testing nodes, and inspection result nodes; and the operation and maintenance stage BOM model includes sensor monitoring nodes, maintenance record nodes, and operating status nodes. The system establishes a mapping relationship between data objects and BOM nodes in the structured dataset based on the component identifiers and semantic tags associated with the data objects. On this basis, it further determines the semantic relationships between different BOM nodes using the functional dependencies, connectivity relationships, and positional relationships between component entities in the ontology model, and generates a semantic BOM model with a hierarchical semantic structure. Each semantic BOM model corresponds to one lifecycle stage of the pressure vessel.

[0079] Furthermore, when generating the semantic BOM model, the system encapsulates the attribute information of each material node (including design parameters, material type, manufacturing process, inspection records, and operating status) into a unified semantic data structure. Different nodes are logically linked through semantic relationships (such as manufacturing dependency, inspection correspondence, maintenance inheritance, and operational feedback). For example, the system can establish an "inspection correspondence" relationship between weld nodes in the manufacturing stage and radiographic inspection nodes in the inspection stage, and an "operational feedback" relationship between monitoring and sensing nodes in the maintenance stage and stress analysis nodes in the design stage. Through this approach, the generated semantic BOM model achieves semantic fusion and unified representation of data across stages.

[0080] S104. Determine the relationship between the semantic BOM models based on the ontology model, and combine them to generate an xBOM data model.

[0081] Specifically, based on ontology models and semantic BOM models, semantic relationships across lifecycle stages are established, enabling the fusion and unified management of multi-stage BOM models. By introducing semantic rules and component relationships defined in the ontology model, the system can identify the logical correspondences between material nodes in different semantic BOM models and combine them according to the lifecycle stage sequence to form an xBOM data model covering multiple stages such as design, manufacturing, testing, operation, and maintenance. This xBOM data model, with semantics at its core, enables cross-stage traceability, data fusion, and knowledge association at the material level, providing semantic support for subsequent fault location and source analysis.

[0082] Optionally, in one possible implementation, determining the relationships between the various semantic BOM models based on the ontology model and combining them to generate an xBOM data model may include:

[0083] (1) Determine the association relationship between the material nodes of each semantic BOM model based on the correspondence between the material nodes of each semantic BOM model and the ontology model.

[0084] Specifically, the system reads material node information from each semantic BOM model, including attributes such as node identifier, component number, material type, geometric parameters, and functional identifier. Then, the system searches for the corresponding node in the ontology model, extracting its attribute information, functional association edges, and state behavior sub-model data. For each pair of cross-stage material nodes, the system performs association judgments based on information in the ontology model: for example, comparing the node's component number, material type, design parameters, and functional identifier; if the attributes highly match, it initially determines that the nodes have an inheritance or update relationship; using the functional association edges between nodes in the ontology model, it analyzes the upstream and downstream relationships and load and energy transfer paths of the nodes at different stages to determine possible evolutionary or replacement relationships between nodes; referring to the response characteristics and typical failure modes in the node state behavior sub-model, it determines whether the nodes maintain the same function or performance requirements at different stages, further confirming the inheritance or replacement relationships between nodes. Based on the above analysis, the system establishes semantic mappings between semantic BOM models. For example, the "Shell_001" node in the design-stage semantic BOM model can be semantically mapped to the "Shell_001A" node in the manufacturing-stage semantic BOM model through the "evolvesFrom" relationship, thereby representing the evolution of the component from design to manufacturing. The system also performs consistency checks on semantic relationships based on the rule base in the ontology model, including component composition logic, functional constraints, and connection integrity, ensuring that the node associations in the generated semantic BOM model conform to engineering reality and design specifications. Finally, the system integrates the cross-stage mapping relationships of all nodes to form a complete xBOM data model.

[0085] (2) Combine the semantic BOM models in the order of life stages to generate the xBOM data model. The xBOM data model includes multiple semantic BOM models. The semantic BOM models establish multi-domain mapping and data fusion based on the correlation between the material nodes across stages. The nodes of different semantic BOM models in xBOM have semantic correlation.

[0086] Specifically, the system sequentially combines various semantic BOM models based on the lifecycle sequence (including design, manufacturing, inspection, operation, and maintenance phases). During the combination process, the system utilizes the relationships between material nodes across different phases to perform multi-domain mapping and semantic fusion operations. Multi-domain mapping is used to establish semantically consistent material relationships across different lifecycle phases, such as attribute mapping from design parameters to manufacturing processes, and performance mapping from inspection results to operational status. Data fusion is used to integrate attribute and status information from different phases within a unified semantic framework, forming a semantic data chain that spans the entire lifecycle.

[0087] Furthermore, during the combination process, the system handles the node connections between different semantic BOM models, specifically including the following steps:

[0088] A) Filter material node pairs that may have functional or attribute dependencies from the semantic BOM model of adjacent lifecycle stages.

[0089] Specifically, the system filters material node pairs that may have functional or attribute dependencies from semantic BOM models of adjacent lifecycle stages (such as design and manufacturing stages) based on the component structure level, functional affiliation, and lifecycle stage sequence of the nodes. Each node pair includes a source node and a target node, where the source node refers to the node in the preceding stage (such as a design stage node), and the target node refers to the node in the following stage (such as a manufacturing stage node). In this way, the system can identify node pairs that may have inheritance, evolution, or substitution relationships during the lifecycle. For example, the "Shell_001" node (source node) in the design stage semantic BOM model and the "Shell_001A" node (target node) in the manufacturing stage semantic BOM model can be considered as candidate related node pairs because they belong to the same shell subsystem and have a continuous stage sequence.

[0090] B) Calculate the correlation degree of candidate node pairs based on the semantic BOM model and ontology model.

[0091] Specifically, for each candidate node pair, the system extracts key attributes of the source and target nodes from the semantic BOM model, including design parameters, material type, manufacturing process, inspection results, and operating status. Simultaneously, the system extracts edge information between candidate node pairs from the established ontology model, including parameters such as edge connection type, connection strength, and historical stability. The system combines node attributes with edge information to generate an attribute-edge feature vector for the candidate node pair. This vector contains the source node attributes, target node attributes, and feature information of the edges between the two nodes. This feature vector serves as input for correlation calculation. A weighted comprehensive scoring method and semantic similarity are used to calculate a preliminary correlation score for each candidate node pair, providing a foundation for subsequent threshold judgment and cross-stage connection establishment. For example, the attribute-edge feature vector of the design stage node "Shell_001" and the manufacturing stage node "Shell_001A" includes the material type, shell thickness, and functional attribution information of the two nodes, as well as the corresponding structural connection edge type, connection strength, and historical stability index in the ontology model. This vector can be used to calculate the correlation between the two nodes from the design to the manufacturing stage.

[0092] C) Determine whether to establish a connection based on the correlation degree and the preset threshold.

[0093] Specifically, the system sets a correlation threshold. If the correlation value of a candidate node pair exceeds this threshold, an edge is established in the xBOM data model, indicating a semantic association between nodes across stages, thus achieving logical connectivity between nodes. This threshold can be set according to actual needs and is not limited here. The system sequentially performs the above judgment and connection operations on all candidate node pairs until all stage node pairs are processed, thereby forming a complete cross-stage semantic BOM node connection network covering design, manufacturing, testing, operation, and maintenance stages. Furthermore, to improve the searchability and traceability of the xBOM data model, the system uses a graph database for storing and indexing the xBOM data model. Each material node, attribute node, and its semantic relationships are stored in the form of a graph structure, connecting semantic entities at different lifecycle stages through edges, thus forming a semantically connected lifecycle network. This graph database supports relational schema-based queries, path tracing, and semantic reasoning, enabling rapid responses to queries of the evolutionary links, state changes, and historical events of specific components. For example, the system can trace the evolution path of the "Shell_001A" node during the design, manufacturing and testing stages through a path query algorithm, thereby achieving structured and semantic fault tracing.

[0094] S105. Based on the real-time working status data of the pressure vessel and the preset traceability strategy matrix table, determine whether the traceability triggering conditions are met.

[0095] Specifically, the system continuously monitors the real-time operating status data of the pressure vessel, including temperature, pressure, stress, corrosion rate, acoustic emission signals, and leakage monitoring parameters. When the real-time data or relevant parameters calculated from the real-time data are compared with a preset traceability strategy matrix, the system automatically determines whether to enter the traceability state based on the triggering rules defined therein.

[0096] Optionally, in one possible implementation, determining whether the traceability triggering condition is met based on the real-time operating status data of the pressure vessel and a preset traceability strategy matrix table may include:

[0097] (1) Based on the real-time working status data of the pressure vessel and the risk assessment model, predict the real-time risk status, which includes at least the risk level; compare the risk level with the triggering conditions in the traceability strategy matrix table to determine whether the traceability triggering conditions are met.

[0098] Specifically, the system inputs the collected real-time operating status data into a preset risk assessment model for calculation, obtaining the real-time risk value and corresponding risk level of each key component. The real-time operating status data includes, but is not limited to, parameters such as pressure, temperature, stress, vibration, corrosion rate, and acoustic emission signals. The risk assessment model can be a risk prediction model based on probability statistics, fuzzy comprehensive evaluation, or machine learning algorithms, used to calculate the risk level under different combinations of variables. Subsequently, the system compares the calculated risk level with the triggering conditions defined in the traceability strategy matrix table. For example, when the risk level rises to medium level or above, the triggering condition is met. If the triggering condition is determined to be met, the system automatically enters the traceability process, determines the traceability parameters, and initiates the fault traceability process. The calculation of real-time risk status is described in subsequent methods and will not be repeated here.

[0099] (2) Compare the monitoring parameters in the real-time working status data with the trigger conditions in the source tracing strategy matrix table to determine whether the source tracing trigger conditions are met.

[0100] Specifically, the system continuously collects and updates real-time monitoring data from each sensor node, including parameters such as operating pressure, shell strain, seal leakage rate, temperature gradient, and media flow rate. When any monitored parameter exceeds the threshold defined in the traceability strategy matrix table, such as pressure exceeding 110% of the design pressure, corrosion rate exceeding the material's allowable value, or continuous exceedance of acoustic emission signals, the traceability trigger condition is considered met. At this point, the system generates traceability parameters based on the trigger event and initiates subsequent xBOM traceability analysis. This method enables a rapid triggering mechanism based on real-time physical quantity exceeding limits, without relying on complex risk calculation models, and is suitable for immediate traceability response in situations of sudden anomalies or extreme parameter changes.

[0101] S106. Based on the triggering conditions and the preset tracing strategy matrix table, determine the tracing parameters.

[0102] Specifically, after detecting that the source tracing trigger conditions are met, the system automatically configures source tracing parameters, such as source tracing depth, focus dimension, time range, and source tracing direction, based on the different types of trigger conditions and a predefined source tracing strategy matrix. Through this process, the system can dynamically limit the source tracing scope and analysis boundaries according to different risk scenarios, efficiently locating the target area and data dimension to be analyzed in the xBOM data model.

[0103] Optionally, in one possible implementation, determining the tracing parameters based on the triggering condition and a preset tracing strategy matrix table may include:

[0104] (1) Based on the preset source tracing strategy matrix table, the source tracing parameter configuration is determined according to the triggering conditions. The source tracing parameters include source tracing depth, focus dimension, time range and source tracing direction.

[0105] Specifically, the system retrieves corresponding entries from a pre-defined traceability strategy matrix table based on the risk level output by the risk assessment model and real-time monitored abnormal parameters, such as pressure, temperature, corrosion rate, and acoustic emission signals. This traceability strategy matrix table can be manually defined by the system administrator based on industry standards, historical fault data, and expert experience, and can be dynamically adjusted according to different equipment types or operating scenarios. The matrix table defines the correspondence between various triggering conditions and traceability strategies. For example, when the risk level rises to medium risk, the system can set the traceability depth to the component level, focusing on manufacturing records and the three most recent inspection data; when the risk level rises to high risk, the system can set the traceability to the weld level, focusing on welding processes, material certificates, and operating stress data; when the corrosion rate exceeds a threshold, the traceability direction is set to the upstream path, tracing the material source, heat treatment records, and corrosion monitoring points. Through this matrix-style strategy configuration, the system can automatically generate traceability parameter templates according to different risk states, achieving flexible adaptation and automated triggering of traceability strategies.

[0106] (2) Determine the component structure level of the traceability based on the traceability depth, and regard the component structure above the component structure level in the ontology model as risk components.

[0107] Specifically, the system combines the structural hierarchy of the pressure vessel's body model and determines the component level range required for the current risk analysis based on the set traceability depth (such as vessel level, component level, weld level, etc.). For example, when the traceability depth is at the weld level, the system identifies the weld and its parent structures such as the cylinder and head, marking them as risk components to ensure that the traceability analysis covers potentially affected adjacent structures.

[0108] (3) Determine the BOM node corresponding to the risk component in the xBOM data model as the first traceability scope.

[0109] Specifically, based on the semantic mapping relationship between component structures in the ontology model and material nodes in the xBOM model, the system uses component identifiers, material codes, or structural path information to locate the BOM nodes corresponding to risky components in the xBOM data model and establish a node index. The determined set of BOM nodes is defined as the first traceability range, serving as the starting area for subsequent traceability analysis and limiting the initial boundaries and data retrieval scope of traceability queries.

[0110] (4) Based on the tracing direction, determine the association path type between nodes within the first tracing range, including upward tracing relationship and downward tracing relationship.

[0111] Specifically, the system represents the nodes and connections between them within the first traceability scope as a graph structure, and sets an associated path attribute for each connection path. This attribute identifies the traceability direction of the path. Associated path types include upward traceability relationships and downward traceability relationships. Upward traceability relationships identify paths from maintenance or testing nodes to design or manufacturing nodes, used to analyze design origins, material sources, and manufacturing processes. Downward traceability relationships identify paths from design or manufacturing nodes to maintenance or testing nodes, used to track maintenance status, stress response, and testing reports. In practical applications, the system can analyze both upward and downward paths simultaneously as needed to establish a complete causal chain between design, manufacturing, and maintenance stages. By parsing node attributes and relationships between nodes, and combining this with predefined traceability rules, the system automatically determines the direction and type of each path. For example, when an abnormal corrosion rate is detected, the system identifies the corresponding upward tracing path and traces the material and process information along that path; when an overpressure or leakage alarm occurs, the system identifies the corresponding downward tracing path and tracks the operation and maintenance status and inspection reports along that path, thereby realizing full-process traceability analysis of the design, manufacturing and operation and maintenance links.

[0112] (5) Filter target traceability nodes and candidate attributes from the first traceability range according to the traceability dimension.

[0113] Specifically, the system first classifies nodes within the initial traceability scope based on traceability dimensions (such as manufacturing, testing, operation, or maintenance). Mapping can be done based on node attribute types, functional roles, or predefined categories in the ontology model to achieve semantic consistency and provide an organizational structure for subsequent screening. Subsequently, the system calculates and analyzes the relevance or importance score of each node, for example, through causal path length, the frequency of co-occurrence of attribute anomalies and historical events, or quantification based on graph structure centrality indicators (such as weighted degree and PageRank), thereby screening out high-value target nodes. The system then extracts candidate attribute fields from the target nodes, prioritizing attributes relevant to traceability analysis, such as welding current, inspection batch number, material chemical composition, or operating pressure. Semantic alignment is performed using the attribute classification system in the ontology model to ensure semantic interoperability of data from different sources.

[0114] (6) Filter the source attributes from the candidate attributes according to the time range to generate the source range.

[0115] Specifically, the system filters candidate attributes based on a specified time range parameter. By comparing the timestamps of candidate attributes with time windows, the system retains only attribute records within that window that are relevant to the time sequence of the target event being analyzed, thereby eliminating irrelevant historical data. After filtering, the system internally generates a source tracing scope, including a set of nodes, a set of paths, and a set of attributes. The attribute set contains the key attribute data after time filtering, which can be used for subsequent graph queries and root cause analysis.

[0116] S107. Generate fault tracing results based on the fault points corresponding to the tracing parameters and the real-time working status data.

[0117] Specifically, the system generates query commands for risky components by combining the set of nodes, paths, and attributes within the traceability scope, and constructs a traceability graph in the xBOM data model. The system traverses the traceability graph along the nodes and their semantic relationships, analyzes the abnormal states of each node's attributes, and quickly identifies possible faulty nodes and their associated paths, providing structured data support for subsequent root cause analysis and improvement measures.

[0118] Optionally, in one possible implementation, generating fault tracing results based on the tracing parameters and the fault points corresponding to the real-time operating status data may include:

[0119] (1) Combine the triggering conditions and the source tracing strategy matrix table to obtain the query template.

[0120] Specifically, the system matches triggering conditions with risk component types based on a pre-configured traceability strategy matrix table, forming a structured query template. These triggering conditions include abnormal pressure, excessive temperature, or detection alarms. The template defines the node types, attribute fields, and relationships between nodes that require attention, providing standardized input for subsequent graph queries.

[0121] (2) Generate query node identifiers based on the risk components within the traceability scope.

[0122] Specifically, the system first filters out component nodes that meet risk conditions from the traceability scope, such as those whose predicted risk level reaches a set threshold or those with abnormal attributes. Then, for each risk node, the system generates a query node identifier based on the node's unique identification field (such as BOM node ID, material code, or serial number). If the same component has corresponding entities in multiple lifecycle stages, the system can append stage information to the identifier to form a unique identifier across stages.

[0123] (3) Fill the query template according to the query node identifier and generate a query instruction.

[0124] Specifically, the system dynamically fills the query template with the query node identifier and selected attribute fields from the tracing scope, generating an executable graph query command. The query command can include fault points, attribute filtering conditions, and path traversal rules to ensure that the query covers all potential fault paths.

[0125] (4) Input the fault point into the query template, and construct the source map by combining the xBOM data model and the query template.

[0126] Specifically, the system fills the query node identifiers and candidate attribute fields selected within the traceability scope into a pre-configured query template, and simultaneously inputs the pre-determined fault points into the template to form an executable graph query instruction. In this application, the fault points are manually determined, but in practice, they can also be automatically generated by the system according to agreed-upon rules based on real-time working status data. Based on the generated query instruction, the system constructs a traceability graph in the xBOM data model, mapping nodes and semantic relationships into a graph structure for path traversal and semantic reasoning. The query instruction may include fault points, attribute filtering conditions, and path traversal rules to ensure that the graph database can cover all potential fault paths starting from the fault point. After executing the query, the system returns nodes that meet the traceability strategy and risk conditions, along with their associated paths, for subsequent fault location and traceability report generation.

[0127] (5) Query the source map according to the query instruction, determine the abnormal state of the corresponding attributes of each node in the source map, determine the associated fault point corresponding to the fault point, and generate the fault source tracing result.

[0128] Specifically, the system traverses the source tracing graph using a graph query algorithm, combining node attribute outliers, historical co-occurrence data, and source tracing strategy matrix table rules to identify potential fault nodes and abnormal paths. For example, for weld fatigue risk, the source tracing path might include: container → cylindrical circumferential weld → Welding process (WPS) → welding material batch → material certificate → non-destructive testing report → operational history → online stress / strain monitoring points. The system can analyze node attributes along the path, determine the associated fault points corresponding to the final fault point, and generate a structured source tracing report.

[0129] The method provided in this embodiment achieves automated and traceable fault location through xBOM-based full lifecycle data management and analysis of pressure vessels. First, the system collects multi-source heterogeneous data from each stage of the pressure vessel's lifecycle, including design, manufacturing, testing, operation, and maintenance, forming a structured dataset. An ontology model based on component structure and functional relationships is then established, providing a foundation for generating semantic BOM models for different lifecycle stages. Subsequently, the system combines the various semantic BOM models across stages based on the ontology model, forming an xBOM data model covering the entire lifecycle, achieving material-level semantic association and data fusion. On this basis, based on the pressure vessel's real-time operating status data and a preset traceability strategy matrix, the system determines whether traceability triggering conditions are met. When the triggering conditions are met, the system determines the corresponding traceability parameters by combining the triggering conditions and the traceability strategy matrix. Then, based on the traceability parameters and the fault points corresponding to the real-time operating status data, traceability analysis is performed in the xBOM data model to generate fault traceability results, enabling rapid backtracking and analysis of the fault source. This method effectively improves the accuracy and efficiency of pressure vessel fault location, enables rapid response to events of different risk levels, supports root cause analysis and improvement plan development, while reducing manual intervention and data omissions, and enhances safety management and reliability assurance throughout the entire life cycle.

[0130] Optionally, in one possible implementation, predicting the real-time risk status based on the real-time operating status data of the pressure vessel and the risk assessment model may include:

[0131] (1) Obtain the real-time operating status data of the pressure vessel.

[0132] Specifically, the system collects real-time operating parameters of pressure vessels during service through sensor networks, monitoring instruments, and an Industrial Internet of Things (IIoT) platform. These parameters include temperature, pressure, stress, vibration, media flow rate, corrosion rate, wall thickness decay rate, and operating time. For historical equipment without real-time monitoring devices, supplementary data can be obtained through manual inspection records, periodic inspection reports, or historical trend data. The system synchronizes the collected raw operating data with time and removes outliers to ensure the accuracy and continuity of data input.

[0133] (2) Input the real-time working status data into the risk assessment model and calculate the failure probability of each key variable.

[0134] Specifically, the system first extracts historical failure data for each component from a structured dataset, such as the number of past failures and failure modes. Then, it statistically analyzes the historical failure data to calculate the average failure frequency of each component within a certain time window. Subsequently, the system performs time alignment, anomaly removal, and normalization on the real-time operating status data, calculating node status feature vectors to characterize the current operating status and health of the nodes. The average failure frequency and node status feature vectors are then input into a risk assessment model to predict the failure probability value. The risk assessment model can be a probabilistic statistical model, a Bayesian network, or an empirical lifetime model, etc., and is not limited here. Finally, a probability mapping method based on interval partitioning is used to map the failure probability value to a discrete five-level risk level: 1 represents an extremely low probability, and 5 represents an extremely high probability. This level represents the component's failure probability level.

[0135] (3) Calculate the severity of the failure consequences based on the failure probability and the preset failure assessment model.

[0136] Specifically, the system calculates the severity level of failure consequences based on the functional importance, potential accident impact range, and safety specification requirements of each component in the pressure vessel. The data sources for functional importance, potential accident impact range, and safety specification requirements are: a) Structured datasets: imported from the design system, equipment ledger, and operation and maintenance system, containing the structural type, material properties, operating pressure, operating temperature, service life, and historical maintenance records of each component; b) Rule base and knowledge base: constructed from expert knowledge and industry standards, including the provisions of safety design codes such as GB150 and ASME VIII regarding the safety level, inspection cycle, and permissible failure criteria for critical components, as well as empirical parameters and statistical distributions of typical component failure consequences; c) Real-time operating status data: from real-time monitoring systems or accident databases, containing parameters such as stress, vibration, leakage rate, corrosion rate, energy release, and personnel impact range. The system standardizes and structures the above data to form a parameter set for subsequent evaluation.

[0137] Furthermore, the system inputs the above parameters into the failure consequence assessment model to obtain a severity score for the failure consequence. The failure consequence assessment model can be a weighted scoring model based on the analytic hierarchy process (AHP), a comprehensive evaluation model based on fuzzy membership, or an expert scoring model based on rule reasoning; no specific limitation is made here.

[0138] Furthermore, the severity level of the failure consequences is derived based on the severity score of the failure consequences. The system uses an interval-based severity grading method to map the failure consequence severity score output by the model to the failure consequence severity level: A represents negligible consequences; B represents minor consequences; C represents moderate consequences; D represents major consequences; and E represents catastrophic consequences.

[0139] (4) Calculate the risk value based on the failure probability and the severity of the failure consequences.

[0140] Specifically, the system uses a preset risk calculation formula. ,in Indicates the risk value. Indicates the probability level of failure (1-5). This indicates the severity level of the failure consequences (AE corresponds to a numerical level of 1-5). The calculated risk value is a continuous value in the range of 0-25, used to represent the overall risk level of each component. The system stores the calculation results in the risk matrix module for risk visualization and hierarchical analysis.

[0141] (5) Compare the risk value with a preset threshold range to obtain the corresponding risk level.

[0142] Specifically, the system classifies risk values ​​into levels based on a risk matrix model. The risk matrix uses a two-dimensional mapping of "failure probability – severity of failure consequences," dividing risks into four levels: low risk, medium risk, medium-high risk, and high risk. In one possible implementation, the system divides risk value ranges according to preset grading thresholds: 0-5 corresponds to low risk; 6-10 to medium risk; 11-17 to medium-high risk; and 18-25 to high risk.

[0143] Figure 2 A schematic diagram of a risk matrix illustrating an exemplary embodiment of this application is provided below. Figure 2 , Figure 2 The medium-risk matrix uses the failure probability level and failure consequence severity level as coordinate axes. The vertical axis represents the failure probability level, increasing from 1 to 5; the horizontal axis represents the failure consequence severity level, increasing from A to E. Different colored squares in the matrix correspond to different risk level areas, including low risk, medium risk, medium-high risk, and high risk. As the failure probability level and failure consequence severity level increase, the risk level gradually transitions from low risk to high risk.

[0144] (6) Output the risk value and risk level to obtain the real-time risk status.

[0145] Specifically, the calculated risk values ​​and risk levels are visualized in tabular or graphical formats and output as a real-time risk status report. In addition to risk values ​​and risk levels, the real-time risk status report may also include information such as risk sources, key influencing factors, and trends. Key influencing factors can be identified through sensitivity analysis or feature importance analysis of input variables in the risk assessment model, such as regression coefficients and SHAP values, to determine the parameters that contribute most to risk changes. Risk sources can be calculated by tracing the status feature vectors of traceable nodes or key influencing factors (such as monitoring parameters for temperature, stress, and vibration). Trends can be calculated based on the time-series changes in real-time risk values, such as by calculating gradients or rates of change using a sliding window. Furthermore, the system can link real-time risk status with the xBOM data model to achieve rapid mapping from risk events to structural components. For example, when the system determines that the weld at the lower head of the shell is at high risk, the xBOM data model can be used to locate relevant nodes at each stage of its life cycle, providing input for subsequent source tracing analysis.

[0146] Optionally, in one possible implementation, the method for determining the associated fault points corresponding to the fault point and generating fault tracing results further includes:

[0147] (1) Obtain the node name and its abnormal attributes corresponding to the fault point as basic information.

[0148] Specifically, the system extracts the unique identifier, component name, model and related attribute values ​​of the fault point from the xBOM data model or single-stage BOM model, and marks the abnormal state or predicted risk level of the fault point in the real-time risk assessment, forming a basic dataset that reflects the core information of the fault point.

[0149] (2) Determine the associated nodes and their attributes in the current BOM model and xBOM data model where the fault point has an association relationship, as the association information.

[0150] Specifically, based on the semantic relationships between nodes in the xBOM data model, the system identifies upstream and downstream nodes that have inheritance, evolution, or functional dependence relationships with the failure point, and extracts their key attributes, such as material batches, process parameters, test results, and operating status, to form a set of related node information, providing a reference for full life cycle analysis.

[0151] (3) Combine the basic information and the associated information to obtain the full life cycle data of the fault point and its associated nodes.

[0152] Specifically, the system integrates the basic information of the fault point with the information of related nodes under a unified semantic framework, forming a full lifecycle data chain covering the design, manufacturing, testing, operation and maintenance stages, and saves it through graph structure or indexing for quick access and analysis later.

[0153] (4) Generate a traceability report based on the full lifecycle data.

[0154] Specifically, the system will integrate the entire lifecycle data and output it in a visualized or structured manner, including the evolution path of the fault point and its related nodes, the history of abnormal events and risk factor analysis. At the same time, it will generate root cause analysis conclusions based on preset rules or models, forming a complete source tracing report to support fault rectification, improvement measure formulation and safety management optimization.

[0155] Corresponding to the aforementioned embodiment of a pressure vessel fault tracing method based on xBOM, this application also provides an embodiment of a pressure vessel fault tracing device based on xBOM.

[0156] Figure 3 This is a schematic diagram of the structure of Embodiment 1 of the xBOM-based pressure vessel fault tracing device provided in this application. Please refer to... Figure 3 The device provided in this embodiment includes a data acquisition module 301, a construction module 302, a prediction module 303, and a determination module 304; wherein,

[0157] The acquisition module 301 is used to acquire multi-source heterogeneous data throughout the entire life cycle of the pressure vessel and generate a structured dataset.

[0158] The construction module 302 is used to establish a body model of the pressure vessel based on the component structure and functional relationships of the pressure vessel.

[0159] The construction module 302 is used to generate multiple semantic BOM models based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel, and each semantic BOM model includes multiple materials and semantic relationships between the materials.

[0160] The construction module 302 is used to determine the relationship between each semantic BOM model based on the ontology model and combine them to generate an xBOM data model.

[0161] The judgment module 303 is used to determine whether the traceability triggering conditions are met based on the real-time working status data of the pressure vessel and the preset traceability strategy matrix table.

[0162] The determining module 304 is used to determine the tracing parameters based on the triggering conditions and the preset tracing strategy matrix table;

[0163] The determining module 304 is used to generate fault tracing results based on the tracing parameters and the fault points corresponding to the real-time working status data.

[0164] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.

[0165] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0166] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0167] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for tracing the failure source of a pressure vessel based on xBOM, characterized in that, The method includes: Collect multi-source heterogeneous data throughout the entire lifecycle of the pressure vessel to generate a structured dataset; Based on the component structure and functional relationships of the pressure vessel, a body model of the pressure vessel is established; Multiple semantic BOM models are generated based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel and includes multiple materials and semantic relationships between the materials. The relationships between the semantic BOM models are determined based on the ontology model, and the xBOM data model is generated by combining them. Based on the real-time operating status data of the pressure vessel and the preset traceability strategy matrix table, determine whether the traceability triggering conditions are met. Based on the triggering conditions and the preset source tracing strategy matrix table, the source tracing parameters are determined; Based on the fault points corresponding to the traceability parameters and the real-time working status data, a fault traceability result is generated.

2. The method according to claim 1, characterized in that, The generation of the structured dataset includes: The multi-source heterogeneous data topic is parsed to determine the corresponding target metadata template, and the target data is extracted from the multi-source heterogeneous data based on the metadata tags in the target metadata template. The target data is filled into the target metadata template to obtain a structured dataset.

3. The method according to claim 1, characterized in that, The generation of multiple semantic BOM models based on the lifecycle of the pressure vessel and the mapping relationship between the structured dataset and materials includes: Determine the life cycle segments of the pressure vessel; The BOM model for each stage is determined based on the material requirements corresponding to each life cycle segment. Each BOM model includes multiple materials for the corresponding life cycle segment and the attributes of the materials. Determine the component structure associated with each data object in each structured dataset, and determine the semantic association of each data object based on the relationship between the component structures in the ontology model; The BOM model to which each data object belongs is determined, and a correspondence between the structured dataset with semantic association and the BOM model is established to generate a semantic BOM model. Each semantic BOM model includes multiple material nodes, each material node includes material attribute information, and the multiple material nodes in each semantic BOM model have the semantic association.

4. The method according to claim 1, characterized in that, The step of determining the relationships between the various semantic BOM models based on the ontology model and combining them to generate an xBOM data model includes: The association relationships between the material nodes of each semantic BOM model are determined based on the correspondence between the material nodes of each semantic BOM model and the ontology model. The xBOM data model is generated by combining the semantic BOM models in the order of the life stages. The xBOM data model includes multiple semantic BOM models. The semantic BOM models establish multi-domain mapping and data fusion based on the association between the material nodes across stages. The nodes of different semantic BOM models in the xBOM have semantic association.

5. The method according to claim 1, characterized in that, The step of determining whether the traceability triggering conditions are met based on the real-time operating status data of the pressure vessel and a preset traceability strategy matrix table includes: The real-time risk status is predicted based on the real-time operating status data of the pressure vessel and the risk assessment model. The real-time risk status includes at least a risk level. The risk level is compared with the triggering conditions in the traceability strategy matrix table to determine whether the traceability triggering conditions are met. The monitoring parameters in the real-time working status data are compared with the trigger conditions in the source tracing strategy matrix table to determine whether the source tracing trigger conditions are met.

6. The method according to claim 5, characterized in that, The step of predicting the real-time risk status based on the real-time operating status data of the pressure vessel and the risk assessment model includes: Obtain real-time operating status data of the pressure vessel; The real-time operating status data is input into the risk assessment model to calculate the probability of failure of each key variable; Based on the failure probability and the preset failure assessment model, the severity of the failure consequences is calculated; Calculate the risk value based on the probability of failure and the severity of the consequences of failure; The risk value is compared with a preset threshold range to obtain the corresponding risk level; The risk value and risk level are output to obtain the real-time risk status.

7. The method according to claim 1, characterized in that, The determination of tracing parameters based on the triggering conditions and a preset tracing strategy matrix table includes: Based on the preset source tracing strategy matrix table, the source tracing parameter configuration is determined according to the triggering conditions. The source tracing parameters include source tracing depth, focus dimension, time range, and source tracing direction. The component structure level for tracing is determined based on the tracing depth, and components at or above the specified component structure level in the ontology model are designated as risk components. In the xBOM data model, the BOM node corresponding to the risk component is determined as the first traceability scope; Based on the tracing direction, determine the association path type between nodes within the first tracing range, including upward tracing relationship and downward tracing relationship; Target tracing nodes and candidate attributes are selected from the first tracing scope based on the tracing dimensions. The tracing attribute is selected from the candidate attributes based on the time range to generate the tracing range.

8. The method according to claim 7, characterized in that, The step of generating fault tracing results based on the tracing parameters and the fault points corresponding to the real-time operating status data includes: By combining the triggering conditions and the source tracing strategy matrix table, a query template is obtained; Generate query node identifiers based on the risk components within the traceability scope; The query template is populated based on the query node identifier to generate a query instruction; Input the fault point into the query template, and construct a source map by combining the xBOM data model and the query template; The source tracing graph is queried according to the query instruction, the abnormal state of the corresponding attributes of each node in the source tracing graph is determined, the associated fault points corresponding to the fault points are identified, and the fault source tracing results are generated.

9. The method according to claim 8, characterized in that, The process of determining the associated fault points corresponding to the fault point and generating fault tracing results includes: Obtain the node name and its abnormal attributes corresponding to the fault point as basic information; Identify the associated nodes and their attributes in the current BOM model and xBOM data model where the fault point has a relationship, and use them as association information; By combining the basic information and the associated information of each node in the xBOM in order, the full lifecycle fault tracing data of the fault point and its associated nodes can be obtained.

10. A pressure vessel traceability device based on xBOM, characterized in that, The device includes a data acquisition module, a data construction module, a prediction module, and a determination module; wherein, The acquisition module is used to collect multi-source heterogeneous data throughout the entire life cycle of the pressure vessel and generate a structured dataset. The construction module is used to establish a body model of the pressure vessel based on the component structure and functional relationships of the pressure vessel. The construction module is used to generate multiple semantic BOM models based on the life cycle of the pressure vessel and the mapping relationship between the structured dataset and the materials. Each semantic BOM model corresponds to a life stage of the pressure vessel, and each semantic BOM model includes multiple materials and semantic relationships between the materials. The construction module is used to determine the relationship between the semantic BOM models based on the ontology model and combine them to generate an xBOM data model. The judgment module is used to determine whether the traceability triggering conditions are met based on the real-time working status data of the pressure vessel and the preset traceability strategy matrix table. The determining module is used to determine the tracing parameters based on the triggering conditions and the preset tracing strategy matrix table; The determining module is used to generate fault tracing results based on the tracing parameters and the fault points corresponding to the real-time working status data.

Images