Engineering technology data governance methods and systems for the entire life cycle

Abstract

This application relates to the field of data processing technology and discloses a method and system for engineering technology data governance throughout its entire lifecycle. The method includes: dividing engineering object attributes into anchor attribute sets and extended attribute sets; adding locking tags to the anchor attribute sets; obtaining a data object meta-model by layering the extended attribute sets according to stages; establishing a dependency mapping table based on the data object meta-model to automatically verify attribute changes; establishing spatial topology maps and flowcharts to diagnose inconsistencies; establishing weighted maps to quantitatively analyze the impact of changes; and assessing data quality based on scenario type and intelligently completing missing attributes. This application improves the integrity and consistency of engineering data transfer across stages, the real-time performance and accuracy of multi-disciplinary data collaboration, the depth and automation of data quality diagnosis, the scientific rigor and comprehensiveness of change impact analysis, and the flexibility and efficiency of data utilization.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to an engineering technology data governance method and system for the entire life cycle. Background Technology

[0002] Engineering data governance refers to a systematic approach to the standardized management and quality control of technical data generated throughout the entire lifecycle of an engineering project, from design and construction to operation and maintenance. Existing engineering data management technologies mainly include BIM-based building information modeling management systems, PLM product lifecycle management systems, and collaborative design platforms. These systems achieve centralized storage and sharing of engineering data by establishing a unified data model, formulating data standards, and implementing version control. Regarding data quality management, existing technologies typically employ post-hoc inspection methods, i.e., manually reviewing drawings or using software to verify data after design completion. When data is transferred across stages, manual sorting and format conversion are relied upon. In multi-disciplinary collaborative design, regular review meetings are held to coordinate data conflicts between disciplines.

[0003] However, existing technologies have significant shortcomings. First, key design parameters of engineering objects lack effective protection mechanisms during the entire lifecycle transfer process. Anchor attributes such as design pressure and design temperature are easily modified arbitrarily during construction and operation and maintenance, leading to distortion of design intent. Independent modeling of data at each stage lacks a unified attribute layering mechanism and cross-stage constraint rules. Second, data consistency verification in multi-disciplinary collaborative design is limited to internal or file-level conflict detection within a single discipline, failing to achieve cross-disciplinary linkage verification at the object attribute level. Parameter changes in the process discipline cannot automatically trigger data verification in related disciplines such as equipment, piping, and instrumentation, resulting in data inconsistencies between disciplines that can only be discovered through manual review, which is inefficient and prone to omissions. Third, data quality inspection mainly relies on manual review of two-dimensional drawings or individual inspection of three-dimensional models, failing to effectively identify inconsistencies between spatial physical connections and process flow logic, making it difficult to detect hidden logical errors and missing connections.

[0004] The lack of anchor point attribute locking mechanisms and stage extension attribute inheritance rules increases the risk of key design parameters being tampered with during cross-stage transfer of engineering objects. This can lead to a chain reaction of design or operation and maintenance decisions based on erroneous parameters in subsequent stages. Furthermore, the lack of explicit interdisciplinary dependency mapping and real-time cross-validation mechanisms makes it difficult to promptly identify the impact of data changes on other disciplines, resulting in missed or conflicting changes being discovered only during the construction phase and causing rework losses. Finally, the lack of a dual-constraint diagnostic method for spatial topology maps and process flow maps leads to connections in the process flow definition being distorted in three-dimensional space. Defects such as missing parts or spatial connections that do not conform to the process logic cannot be automatically identified, leading to inconsistencies between the as-built model and the process design, which affects subsequent digital twin applications. Due to the lack of a change impact quantification analysis mechanism based on dependency weighted graphs, the scope and degree of impact of design changes cannot be accurately assessed, resulting in a lack of scientific basis for change decisions or omission of adjustments to affected objects. Due to the lack of data quality differentiation assessment and intelligent completion mechanisms based on application scenarios, low-quality data cannot be effectively utilized or the cost of collecting high-quality data is too high, resulting in low data utilization or an imbalance between data collection input and output. Summary of the Invention

[0005] This application provides a method and system for engineering technology data governance throughout the entire lifecycle, which addresses the problems of key parameters being easily tampered with during the transmission of engineering technology data throughout the entire lifecycle, the difficulty in timely detection of data inconsistencies in multi-disciplinary collaborative design, the inability to automatically identify mismatches between spatial connections and process flow logic, the difficulty in quantifying and assessing the impact of design changes, and the low matching degree between data quality and application needs. It improves the integrity and consistency of engineering data transmission across stages, the real-time performance and accuracy of multi-disciplinary data collaboration, the depth and automation of data quality diagnosis, the scientificity and comprehensiveness of change impact analysis, and the flexibility and efficiency of data utilization.

[0006] Firstly, this application provides a method for engineering and technical data governance oriented towards the entire life cycle, the method comprising:

[0007] Step S1: Divide the attributes of the project object into anchor attribute set and extended attribute set. Add a locking mark to the anchor attribute set and layer the extended attribute set according to stage to obtain the data object metamodel.

[0008] Step S2: Establish a dependency mapping table based on the data object meta-model. When the object attributes change, query the dependency mapping table to extract the associated objects and verify the attributes of the associated objects against the constraint rules.

[0009] Step S3: Establish a spatial topology graph and a flowchart graph based on the data object meta-model. Traverse the directed edges of the flowchart graph to search for paths in the spatial topology graph. Record inconsistent paths as defects.

[0010] Step S4: Establish a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated by density, criticality, and margin. When an object in the data object meta-model changes, traverse the weighted graph and multiply the edge weights by the decay coefficients to filter objects with weight values ​​greater than the threshold.

[0011] Step S5: Load the attribute list and evaluation function according to the scene type, score the objects in the data object meta-model, and when the score is lower than the threshold, extract the related object attributes in the weighted graph, calculate the missing attribute values ​​according to the association relationship, and add a mark.

[0012] Secondly, this application provides an engineering technology data governance system oriented towards the entire life cycle, the engineering technology data governance system oriented towards the entire life cycle includes:

[0013] The partitioning module is used to divide the attributes of engineering objects into anchor attribute sets and extended attribute sets. The anchor attribute sets are marked with a locking tag, and the extended attribute sets are layered according to stages to obtain the data object meta-model.

[0014] The query module is used to establish a dependency mapping table based on the data object meta-model. When the object attributes change, the dependency mapping table is queried to extract the associated objects, and the attributes of the associated objects are verified against the constraint rules.

[0015] The traversal module is used to establish a spatial topology graph and a flowchart based on the data object meta-model, traverse the directed edges of the flowchart to search for paths in the spatial topology graph, and record inconsistent paths as defects.

[0016] The filtering module is used to build a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated by density, criticality and margin. When the objects in the data object meta-model change, the module traverses the weighted graph and multiplies the edge weights by the decay coefficient to filter objects with weight values ​​greater than a threshold.

[0017] The scoring module is used to load an attribute list and evaluation function according to the scene type, score the objects in the data object meta-model, and extract the related object attributes in the weighted graph when the score is lower than the threshold, calculate the missing attribute value according to the association relationship and add a mark.

[0018] Thirdly, an engineering technology data governance device oriented towards the entire life cycle is provided, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the engineering technology data governance device oriented towards the entire life cycle to execute the above-described engineering technology data governance method oriented towards the entire life cycle.

[0019] Fourthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the aforementioned engineering data governance method oriented towards the entire life cycle.

[0020] The technical solution provided in this application fundamentally solves the technical problem of arbitrary modification of key design parameters during the entire lifecycle of engineering data by dividing the attributes of engineering objects into anchor attribute sets and extended attribute sets and adding locking markers to the anchor attribute sets. The locking mechanism of the anchor attribute sets forcibly prohibits modification operations on core parameters such as design pressure, design temperature, and materials through database constraint rules, ensuring the accurate transmission of design intent during construction and operation and maintenance phases. The phased and layered design of the extended attribute sets allows professional attributes generated in each phase to be gradually accumulated without overlapping or conflicting with each other. The attribute inheritance rules automatically copy the attributes of previous phases through triggers and set read-only permissions, which not only ensures the continuity of data but also prevents subsequent phases from destroying historical data. The cross-phase constraint rules automatically verify the logical consistency with the anchor attributes when writing extended attributes, effectively avoiding the security risks of operation and maintenance parameters exceeding the design boundaries. By establishing a dependency mapping table and defining constraint rules for each dependency, the textual requirements in engineering design specifications are transformed into executable logical expressions. This enables real-time cross-validation of object attributes in multi-disciplinary collaborative design. When an object attribute changes, the dependency mapping table is queried to automatically identify all affected related objects. The changed attribute value and the current attribute value of the related object are substituted into the constraint rule expression for logical operation. This allows for the immediate detection of inconsistencies that violate constraint rules and the prevention of erroneous data writing when a change operation is submitted. This completely changes the inefficient mode of relying on manual review to discover problems after the fact, and significantly improves the real-time performance and accuracy of error interception in multi-disciplinary data collaboration. Based on the data object meta-model, spatial topology and flowcharts are constructed respectively. By traversing the directed edges of the flowchart, corresponding connection paths are searched in the spatial topology. This innovatively realizes data integrity checks from both spatial and logical dimensions. The spatial topology establishes physical connection relationships based on 3D coordinates and Euclidean distance, while the flowchart establishes process logic relationships based on the tag labels and flow arrows of the process flow diagram. The dual-graph consistency diagnosis algorithm uses breadth-first search to find the process paths defined in the flowchart in the spatial topology. It can automatically identify spatial connection defects where the required connections for the process flow are missing in the 3D model, as well as path logic mismatch defects where spatial connections exist but the intermediate node types do not meet the process requirements. This effectively solves the technical bottleneck of traditional manual drawing review, which makes it difficult to discover hidden logical errors.

[0021] A weighted graph is constructed based on a dependency mapping table. The edge weights are calculated from density, criticality, and margin. This innovative approach quantifies and integrates three factors—the strength of dependencies, the importance of changed attributes, and the fault tolerance of the target object—into an impact weight. When an object changes, the weighted graph is traversed, and the edge weights are multiplied by the attenuation coefficient to calculate the impact weight of the target object. By filtering objects with weight values ​​greater than a threshold, the set of affected objects is accurately identified. This method elevates the traditional qualitative assessment of the scope of change impact to a quantitative calculation of impact weight. Density distinguishes the strength of physical connection dependencies and parameter reference dependencies based on dependency type. Criticality distinguishes the importance of critical parameters such as pressure and temperature and secondary parameters such as annotations based on the type of changed attribute. Margin reflects the fault tolerance of the target object by calculating its current design margin ratio. The attenuation coefficient simulates the objective law of impact attenuation with increasing distance based on propagation hierarchy. The edge weights calculated by multiple factors can accurately reflect the actual impact of changes on each related object, providing a scientific quantitative basis for change decisions and effectively avoiding changes that are missed due to insufficient impact assessment or ineffective adjustments due to excessive impact assessment. Based on the scenario type, the attribute list and evaluation function are loaded to score objects in the data object metamodel. When the score is below the threshold, the associated object attributes in the weighted graph are extracted, and the missing attribute values ​​are calculated and marked according to the association relationship. This achieves accurate matching and intelligent completion of data quality and application requirements. Different application scenarios have significantly different requirements for data completeness, accuracy, and timeliness. The 3D visualization scenario mainly relies on spatial coordinates and geometric dimensions and has low requirements for the accuracy of process parameters, while the operation and maintenance management scenario has strict requirements for the accuracy and completeness of technical parameters. The evaluation function achieves on-demand evaluation by configuring differentiated weight coefficients for different scenarios. The intelligent data completion mechanism uses the process association relationship and associated object attributes in the weighted graph to infer the missing attribute values, transforming data that was originally unusable due to insufficient quality into usable data through reasonable inference. This maximizes data utilization while ensuring application availability and effectively solves the contradiction of excessively high data collection costs or unmet application requirements caused by uniform quality standards. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of one embodiment of the engineering technology data governance method for the entire life cycle in this application.

[0024] Figure 2This is a schematic diagram of one embodiment of the engineering technology data governance system for the entire life cycle in this application.

[0025] Figure 3 This is a schematic block diagram of the engineering technology data governance device for the entire life cycle in this embodiment of the invention. Detailed Implementation

[0026] This application provides a method and system for engineering technology data governance throughout its entire lifecycle. The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0027] For ease of understanding, the specific process of the embodiments of this application is described below. Please refer to [link / reference]. Figure 1 One embodiment of the engineering technology data governance method oriented towards the entire life cycle in this application includes:

[0028] Step S1: Divide the attributes of the project object into anchor attribute set and extended attribute set. Add a locking mark to the anchor attribute set and layer the extended attribute set according to stage to obtain the data object metamodel.

[0029] Step S2: Establish a dependency mapping table based on the data object meta-model. When the object attributes change, query the dependency mapping table to extract the associated objects and verify the attributes of the associated objects against the constraint rules.

[0030] Step S3: Based on the data object meta-model, establish a spatial topology graph and a flowchart graph. Traverse the directed edges of the flowchart graph to search for paths in the spatial topology graph, and record inconsistent paths as defects.

[0031] Step S4: Build a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated by density, criticality and margin. When the objects in the data object meta-model change, traverse along the weighted graph and multiply the edge weights by the decay coefficient to filter objects with weight values ​​greater than the threshold.

[0032] Step S5: Load the attribute list and evaluation function according to the scenario type, score the objects in the data object meta-model, and when the score is lower than the threshold, extract the related object attributes in the weighted graph, calculate the missing attribute values ​​according to the association relationship, and add a mark.

[0033] It is understood that the executing entity of this application can be an engineering technology data governance system covering the entire lifecycle, or it can be a terminal or a server; the specific implementation is not limited here. This application's embodiment uses a server as an example for illustration.

[0034] Specifically, the attributes of engineering objects are divided into anchor attribute sets and extended attribute sets. Anchor attribute sets include object identifiers, design pressure, design temperature, and material. Modification is prohibited by adding a Boolean lock flag to the database fields; when the flag is true, database constraint rules automatically block any update operations. Extended attribute sets are divided into design extended attribute subsets, construction extended attribute subsets, and operation and maintenance extended attribute subsets according to different stages. The design extended attribute subset includes process parameters such as heat exchange area and heat transfer coefficient; the construction extended attribute subset includes construction parameters such as manufacturer information and installation coordinates; and the operation and maintenance extended attribute subset includes operation and maintenance parameters such as operating hours and maintenance records. The attribute inheritance mechanism is implemented through database triggers. When the object stage identifier is updated from design to construction, the trigger automatically copies the anchor attribute set and the design extended attribute subset to the construction stage data table and sets read-only permissions, while granting write permissions to the construction extended attribute subset. Cross-stage constraint rules trigger validation when writing extended attributes. For example, when writing the upper limit of operating pressure, the trigger extracts the design pressure value from the anchor point attribute, calculates the design pressure multiplied by 0.9, and compares the value to be written with the calculation result. If it exceeds the limit, the write is rejected. For instance, in the design phase, the design pressure in the anchor point attribute of a heat exchanger is set to 2.5 MPa and a lock mark is added. During the construction phase, when it is found that the actual rated pressure of the equipment is 3.0 MPa, the anchor point attribute cannot be modified. Instead, a new record of the actual rated pressure attribute of 3.0 MPa is added to the construction extended attribute subset. In the operation and maintenance phase, when the upper limit of operating pressure is set to 2.4 MPa, the trigger calculates 2.5 multiplied by 0.9, which equals 2.25 MPa. Since 2.4 is greater than 2.25, the write is rejected, and a warning is issued that it must not exceed 90% of the design pressure. After correcting it to 2.2 MPa, the write passes validation and is completed, ultimately forming a complete data object meta-model containing the anchor point attribute set and the three stage extended attribute subsets.

[0035] A dependency mapping table is established based on the parameter dependencies between objects in the data object metamodel. This table contains six fields: source object type, source attribute name, dependency type, target object type, target attribute name, and constraint rule expression. Dependency types include physical connection dependency, parameter reference dependency, control logic dependency, and spatial location dependency. The constraint rule for physical connection dependency is that the nominal pipe diameter equals the equipment connection size and the nominal pipe pressure is greater than or equal to the equipment design pressure. The constraint rule for parameter reference dependency is that the downstream equipment inlet pressure is greater than or equal to the upstream equipment outlet pressure multiplied by a safety factor. When an object attribute changes, the change detection mechanism extracts the changed object identifier and the changed attribute name. It then queries the dependency mapping table for records matching the source object type and source attribute name, extracts the target object identifier from these records to form a set of associated objects, and reads the current attribute value of the associated objects from the data object metamodel based on the identifier. The verification process involves traversing the set of associated objects, substituting the changed attribute values ​​and the current attribute values ​​of the associated objects into the constraint rule expression for logical operations. If the result is false, an inconsistency record is generated, which includes the identifier of the changed object, the identifier of the associated object, the violated constraint rule, and the adjustment plan. All inconsistency records are returned to the change initiator and the database transaction is rolled back to reject the change. For example, if the design pressure of a reactor is changed from 1.8 MPa to 2.3 MPa, the dependency mapping table will find three connecting pipes. The constraint rule is that the pipe design pressure must be greater than or equal to the reactor design pressure multiplied by 1.1. The minimum required pipe pressure is calculated to be 2.3 multiplied by 1.1, which equals 2.53 MPa. The current pressures of the three pipes are read as 2.5 MPa, 4.0 MPa, and 2.8 MPa. The first pipe, 2.5 MPa, is less than 2.53 MPa, so the check fails and an inconsistency record is generated, suggesting an adjustment to 4.0 MPa. The second pipe, 4.0 MPa, is greater than 2.53 MPa, so the check passes. The third pipe, 2.8 MPa, although greater than 2.53 MPa, has a margin of only 0.27 MPa, so a warning record is generated, ultimately preventing the reactor pressure change operation.

[0036] Spatial topology graphs are constructed by extracting the spatial coordinate attributes of engineering objects from the data object metamodel. The vertices of the graph represent engineering objects, and the edges represent physical connections. Edges are constructed by traversing pipe objects, extracting the coordinates of the start and end points, setting a search radius of 500mm at the start point, and querying equipment connections, pipe endpoints, valve ports, and tee branch points within the search domain. The Euclidean distance between candidate connection points and pipe endpoints is calculated. When the distance is less than 150mm, an undirected edge is created in the graph, and the connection type and distance value are recorded. The flow diagram is constructed by extracting tag labels from the process flow diagram document using optical character recognition (OCR), matching the tag labels with object identifiers in the data object metamodel to establish a mapping, extracting flow direction arrows through image recognition to determine upstream and downstream relationships, and creating directed edges in the graph to represent the flow direction. Dual-graph consistency diagnosis involves traversing the directed edges of the flowchart, extracting the identifiers of the start and end objects, and performing a breadth-first search algorithm in the spatial topology graph, starting from the start point. A queue is initialized, and the start point is added. Objects are retrieved from the queue, and their adjacent objects are queried. If an adjacent object equals the end point, the search is successful, and the path is returned; otherwise, the adjacent object is added to the queue. The maximum search depth is set to 8 levels. After finding a path, the sequence of intermediate nodes is extracted. The dependency mapping table is checked to see if the process requires a specific type of intermediate object. The types of intermediate nodes are checked for matching. If no path is found or the types do not match, a defect record is generated. For example, a flowchart showing a path from a boiler to a turbine might be searched in the spatial topology graph, starting from the boiler, passing through pipes, valves, and then pipes again to reach the turbine. Checking the intermediate valve types reveals a shut-off valve, while the process requires a regulating valve, resulting in a path logic mismatch defect record. Another flowchart might show a path from a condenser to a deaerator, but after searching to a depth of 8 levels, the deaerator is not found, generating a spatial connection missing defect record.

[0037] A weighted graph is constructed based on the dependency mapping table. The vertices of the graph represent engineering objects, and edges represent dependencies with assigned weights. Edge weights are calculated from density, criticality, and margin. Density is determined by querying a value table based on the dependency type: physical connection dependency is 1.0, parameter reference dependency is 0.8, control logic dependency is 0.7, and spatial location dependency is 0.5. Criticality is determined by the changed attribute type: geometric dimensions are 0.9, pressure and temperature are 0.8, material is 0.7, and annotation is 0.3. Margin is calculated by determining the target object's requirement value based on the changed attribute values ​​and constraint rules. The current value of the target object is extracted from the data object meta-model, and the margin is calculated by dividing the difference between the current value and the original requirement value by the difference between the current value and the original requirement value. The edge weight is equal to density multiplied by criticality multiplied by 1, minus the margin. When an object changes, the initial queue adds the changed object and an initial weight of 1.0. The object is then retrieved from the queue, and the outgoing edges of the weighted graph are queried. The target object and edge weights are extracted, and the impact weight of the target object is calculated. This impact weight is equal to the current weight multiplied by the edge weight multiplied by the decay coefficient. The decay coefficient is determined based on the propagation level and is either 1.0, 0.8, 0.6, or 0.4. If the impact weight is greater than the threshold of 0.15, it is added to the record set and queue to continue propagation; otherwise, the branch is stopped. After traversal, objects with weights greater than the threshold are selected.

[0038] Based on the scenario type, the attribute list and evaluation function are loaded from the scenario mapping knowledge base. The attribute list includes a list of required attributes and a list of optional attributes. The evaluation function includes a weighted calculation of attribute completeness, accuracy, and timeliness. The process iterates through the engineering objects in the data object metamodel, checking whether each object contains all attributes from the required attribute list. The required attribute completeness is calculated by dividing the number of existing required attributes by the total number of required attributes. The optional attribute completeness is calculated by dividing the number of existing optional attributes by the total number of optional attributes. The accuracy is obtained by verifying the constraint rules of the mapping table between object attribute values ​​and dependencies, and the timeliness is obtained by extracting the object's last update timestamp, calculating the time difference between the timestamp and the current time, and dividing by the scenario timeliness threshold. The weight coefficients in the evaluation function are extracted based on the scenario type. The completeness of the required attributes is multiplied by the first weight, the completeness of the optional attributes by the second weight, the accuracy by the third weight, and the timeliness by the fourth weight, and then summed to obtain the score. The score is compared with the scenario threshold. If the score is lower than the threshold, the missing attribute type is analyzed. The related objects with process correlation are queried in the weighted graph, and the corresponding attribute values ​​of the related objects are extracted. The missing attribute values ​​are estimated according to the calculation formula of process correlation. The estimated values ​​are written into the data object meta-model and the estimation source and accuracy mark are added. For example, the required attribute list for loading a 3D visualization scene includes coordinates, size, and color. The evaluation function weights are 0.5, 0.1, 0.3, and 0.1. A device object has coordinates and size but lacks color. The required attribute completeness is 2 divided by 3, which equals 0.67. The optional attribute completeness is 0.8, the accuracy is 0.95, and the timeliness is 0.9. The score is 0.67 multiplied by 0.5 plus 0.8 multiplied by 0.1 plus 0.95 multiplied by 0.3 plus 0.9 multiplied by 0.1, which equals 0.74. The scene threshold is 0.6, and the score of 0.74 is greater than... 0.6 If the quality is deemed acceptable, the object is returned. Another essential attribute for operation and maintenance management includes technical parameters and maintenance cycle. An object lacks the rated power parameter, and its score of 0.58 is lower than the threshold of 0.75. In the weighted graph, the associated object is the upstream power supply system. The output power of the power supply system is extracted as 100kW. According to the process relationship, the rated power of this object should be the output power of the power supply system multiplied by 0.9. The value of the missing attribute is calculated to be 100 multiplied by 0.9, which equals 90kW. This value is written into the object and marked with a note indicating that the calculation accuracy is ±10% based on the power supply system power.

[0039] In one specific embodiment, step S1 includes:

[0040] Define an anchor point attribute set for the engineering object. The anchor point attribute set includes the object identifier, design pressure, design temperature and material. Add a locking flag to each attribute in the anchor point attribute set and set constraints to prevent modification.

[0041] Define extended attribute sets for engineering objects, and divide the extended attribute sets into design extended attribute subsets, construction extended attribute subsets, and operation and maintenance extended attribute subsets;

[0042] Establish attribute inheritance rules so that when a project object moves to the next stage, it inherits the anchor attribute set and extended attribute subset of the previous stage and allows writing to the extended attribute subset of the current stage;

[0043] Define cross-stage constraint rules. When writing extended attributes, extract the attribute values ​​of the anchor attribute set. Validate the extended attribute values ​​to be written against the cross-stage constraint rules to obtain the data object meta-model.

[0044] Specifically, an anchor point attribute set is defined for each engineering object. This set includes four core attributes: object identifier, design pressure, design temperature, and material. The object identifier is uniquely identified by the project code, object type code, system number, and object sequence number. Design pressure and design temperature are key design parameters for the engineering object, while the material determines its physical properties. The implementation of adding a locking flag to each attribute in the anchor point attribute set involves adding a Boolean locking flag field to each of the four attribute fields in the database table structure. When the object is created, the locking flag is set to true, and constraints are set at the database level. When the application attempts to perform an update operation on an attribute with a true locking flag, the database constraints automatically intercept the operation and return an error message prohibiting modification. An extended attribute set is defined for engineering objects, containing attributes that change with the lifecycle stages. This extended attribute set is divided into three subsets: the design subset stores attributes generated during the design stage, such as process calculation parameters like heat exchange area, heat transfer coefficient, and number of tube passes; the construction subset stores attributes generated during the construction stage, such as construction management parameters like manufacturer name, serial number, delivery date, measured coordinates of installation location, and welding inspection record number; and the operation and maintenance subset stores attributes generated during the operation and maintenance stage, such as operation and maintenance management parameters like initial commissioning date, cumulative operating hours, last maintenance date, measured corrosion rate, upper limit of operating pressure, and upper limit of operating temperature. These three subsets are stored in different association tables in the database and linked by object identifiers. The attribute inheritance rules are established through a database trigger mechanism. When the phase identifier field of an engineering object is updated from the design phase to the construction phase, the trigger is executed automatically. The trigger logic first reads all attribute values ​​of the anchor attribute set and the design extended attribute subset of the object in the design phase, then inserts a new record into the construction phase data table, writes the read values ​​of the anchor attribute set and the design extended attribute subset into the corresponding fields of the new record, sets read permissions for these inherited attribute fields to read-only permissions through database permission control, and simultaneously grants write permissions to the corresponding fields of the construction extended attribute subset. When the object moves from the construction phase to the operation and maintenance phase, the trigger executes the same logic to inherit the anchor attribute set, the design extended attribute subset, and the construction extended attribute subset into the operation and maintenance phase data table and grants write permissions to the operation and maintenance extended attribute subset.Cross-stage constraint rules are defined as the logical consistency relationships that must be satisfied between attributes in different stages. Cross-stage constraint rules are stored in the constraint rule table. Each rule contains a rule identifier, a source attribute field, a target attribute field, and a constraint expression. The constraint expression defines the numerical relationship between the source attribute and the target attribute, such as the upper limit of operating pressure being less than or equal to the design pressure multiplied by 0.9, or the actual rated pressure of the equipment being greater than or equal to the design pressure. When an extended attribute is written, a database trigger is triggered. The trigger queries the constraint rule table for the constraint rules related to the attribute to be written, extracts the source attribute field name from the constraint rule, reads the corresponding attribute value from the anchor attribute set, substitutes the anchor attribute value and the extended attribute value to be written into the constraint expression for logical operation. If the operation result is true, the writing is allowed; if the operation result is false, the writing is rejected and an error message is returned. After all the attributes that pass the validation are written, together with the anchor attribute set and the extended attribute subset of the previous stage, they constitute a complete data object meta-model. For example, when a heat exchanger object is created during the design phase, the object identifier is generated as the project code plus the object type plus the system number plus the object sequence number. The design pressure is filled in as 2.5MPa, the design temperature is filled in as 180℃, the material is filled in as 316L stainless steel, the lock flag fields of the four anchor point attributes are all set to true, and the heat exchange area in the design extended attribute subset is filled in as 120m². 2 When the object is transferred to the construction phase, the trigger reads the values ​​of four anchor point attribute sets and eighteen design extended attribute subsets, totaling twenty-two attribute values. A new record is inserted into the construction phase table, writing these twenty-two attributes and setting it to read-only. Construction personnel scan the equipment nameplate, entering the manufacturer and serial number. When the actual equipment rated pressure is entered as 3.0 MPa, the trigger queries the constraint rules and finds that the actual equipment rated pressure must be greater than or equal to the design pressure. It extracts the design pressure of 2.5 MPa from the anchor point attributes, determines that 3.0 is greater than or equal to 2.5, and accepts the result as true, allowing writing. When the object is transferred to the operation and maintenance phase, the trigger inherits twenty-two design phase attributes and fourteen construction phase attributes, totaling thirty-six attributes, into the operation and maintenance table. Operation and maintenance personnel set the upper limit of the operating pressure to 2.4 MPa. When trigger a query constraint rule extracts the design pressure of 2.5 MPa, calculates 2.5 multiplied by 0.9 equals 2.25 MPa, judges 2.4 as greater than 2.25 as false, rejects the write operation, and prompts that the upper limit of the operating pressure must not exceed 90% of the design pressure. After the operation and maintenance personnel correct it to 2.2 MPa, they judge 2.2 as less than or equal to 2.25 as true and complete the write operation. Finally, the data object metamodel of the heat exchanger object contains 64 attributes in total, including four anchor point attributes, eighteen design extended attributes, fourteen construction extended attributes, and twenty-eight operation and maintenance extended attributes. Among them, the design pressure of 2.5 MPa of the anchor point attribute remains unchanged throughout the entire life cycle, and the extended attributes gradually accumulate with the stage flow and are restricted by cross-stage constraint rules to ensure data consistency.

[0045] In one specific embodiment, step S2 includes:

[0046] Establish a dependency mapping table based on the parameter dependencies between objects in the data object metamodel, and define constraint rules for each dependency.

[0047] When the attributes of an object in the data object metamodel change, the matching dependency record is queried in the dependency mapping table, and the associated object identifier is extracted to obtain the set of associated objects;

[0048] Traverse the collection of associated objects, extract the current attribute values ​​of the associated objects from the data object meta-model, construct a validation expression based on the constraint rules, and substitute the changed attribute values ​​and the current attribute values ​​into the validation expression for calculation.

[0049] When the validation expression evaluates to false, an inconsistency record is generated and attribute write operations are prevented.

[0050] Specifically, a dependency mapping table is established based on the parameter dependencies between objects in the data object metamodel. The parameter dependencies are derived from engineering design specifications and physical connection relationships between objects. The dependency mapping table is created as an independent relational table in the database. The table structure includes a source object type field, a source attribute name field, a dependency relationship type field, a target object type field, a target attribute name field, and a constraint rule expression field. The source object type and target object type are engineering object categories such as pressure vessels, pipelines, valves, and instruments. The source attribute name and target attribute name are specific attribute field names such as design pressure, design temperature, and nominal diameter. The dependency relationship types are divided into four categories: physical connection dependency, parameter reference dependency, control logic dependency, and spatial location dependency. The constraint rule expression stores the mathematical or logical relationships that must be satisfied between the source object attributes and the target object attributes. The process of defining constraint rules for each dependency involves analyzing engineering design specification documents, extracting mandatory clauses regarding parameter relationships between objects, and converting textual descriptions into executable logical expressions. For example, a pipeline design specification requires that the nominal pressure of the pipeline connecting equipment be no less than the equipment design pressure, which translates to the constraint rule expression: the nominal pressure of the pipeline is greater than or equal to the equipment design pressure. A pressure vessel design specification requires that the inlet pressure of downstream equipment be greater than the outlet pressure of upstream equipment with a safety margin, which translates to the constraint rule expression: the inlet design pressure of downstream equipment is greater than or equal to the outlet design pressure of upstream equipment multiplied by a safety factor. The safety factor is determined based on the hazard classification of the medium and is taken as 1.2 to 1.5. When an object's attribute changes in the data object metamodel, the change detection mechanism captures the attribute update event through database triggers or application listeners. It extracts three key pieces of information from the update event: the object identifier, object type, and changed attribute name. An SQL query is then executed in the dependency mapping table, with the query conditions being that the source object type field value equals the changed object's object type and the source attribute name field value equals the changed attribute name. The query results return a record set containing all dependency records that meet the conditions. The record set is traversed to extract the target object identifier field value from each record. All extracted target object identifiers are collected into a set data structure to form a related object identifier set. Based on each identifier in the related object identifier set, the corresponding object instance is queried in the data object metamodel to obtain the related object set. The process of traversing the related object set uses a loop structure to process each related object in the set sequentially. For the currently processed related object, the target attribute name is first obtained from the dependency record. Using the target attribute name as the key, the corresponding current attribute value is read from the related object's attribute dictionary or attribute record. Simultaneously, the constraint rule expression is obtained from the dependency record. The constraint rule expression is a string containing variable placeholders, for example, the expression "pipeline design pressure is greater than or equal to equipment design pressure multiplied by 1".1. In this context, the equipment design pressure is a placeholder for the source object's attribute, and the pipeline design pressure is a placeholder for the target object's attribute. The process of constructing a validation expression based on the constraint rule expression involves replacing the source object attribute placeholders in the expression with the changed attribute values ​​of the changed object, and replacing the target object attribute placeholders with the current attribute values ​​of the associated object. After the replacement, a complete logical judgment expression is obtained. The process of substituting the changed attribute values ​​and the current attribute values ​​into the validation expression for calculation involves performing arithmetic and comparison operations in the expression. First, the arithmetic expression part is calculated, for example, the equipment design pressure multiplied by 1.1. Then, the calculation result is compared with the current attribute value of the target object. The comparison operation returns a Boolean value of true or false. When the validation expression evaluates to false, the current attribute value of the associated object is determined to not meet the constraint rule. The process of generating an inconsistency record involves creating a data record containing multiple fields. These fields include: Change Object Identifier (set to the identifier of the object that triggered the change), Associated Object Identifier (set to the identifier of the associated object whose validation failed), Change Attribute Name (set to the name of the changed attribute), Post-Change Attribute Value (set to the new attribute value of the changed object), Current Attribute Value of Associated Object (set to the attribute value read from the associated object), Violated Constraint Rule (set to the textual description of the constraint rule expression), and Adjustment Scheme (derived by reverse-calculating the constraint rule expression to obtain the target value that the associated object's attribute should be adjusted to, for example, a constraint rule of "pipeline design pressure greater than or equal to design pressure"). If the design pressure is multiplied by 1.1, and the equipment design pressure is changed to 3.0 MPa, the calculated pipeline design pressure should be greater than or equal to 3.0 multiplied by 1.1, which equals 3.3 MPa. If the current pipeline design pressure is 3.0 MPa, which is less than 3.3 MPa, the adjustment plan is to adjust the pipeline design pressure from 3.0 MPa to the closest value of 4.0 MPa (greater than or equal to 3.3 MPa) in the standard pressure rating series. All generated inconsistent records are summarized into a record set, which is returned to the user or application that initiated the change operation. Preventing attribute write operations is achieved by triggering the database transaction rollback mechanism. Database transaction rollback undoes the attribute update operation of the changed object, restoring the attribute value of the changed object to its state before the change. Simultaneously, error messages and the inconsistent record set are returned to the user or application. For example, the original design pressure attribute of reactor R-2001 in a petrochemical plant was 1.8 MPa. The process engineer modified the design pressure to 2 MPa in the design software.The database trigger captures the attribute update event at 3MPa. The changed object identifier is identified as R-2001, the object type is reactor, and the changed attribute name is design pressure. The dependency mapping table is queried for records where the source object type is equal to reactor and the source attribute name is equal to design pressure. The query results return three dependency records. The target object identifiers for these three records are P-3001, P-3002, and P-3003, respectively. All three target object types are pipes, all target attribute names are design pressure, all dependency types are physical connection dependencies, and all constraint rule expressions are pipe design pressure greater than or equal to reactor design pressure multiplied by 1.1. The associated object identifiers are obtained by extracting these three target object identifiers. The set contains P-3001, P-3002, and P-3003. In the data object metamodel, three pipe object instances are retrieved based on these three identifiers. Traversing the associated object set, pipe P-3001 is processed first. The current value of the target attribute design pressure is read from the attribute record of the P-3001 object instance as 2.5 MPa. The constraint rule expression "pipe design pressure is greater than or equal to reactor design pressure multiplied by 1.1" is obtained from the dependency record. A verification expression is constructed by replacing the reactor design pressure placeholder with the changed value of 2.3 MPa and the pipe design pressure placeholder with the current value of 2.5 MPa, resulting in the complete verification expression: 2.5 is greater than or equal to 2.3 multiplied by 1.1. Calculation 2... 0.3 multiplied by 1.1 equals 2.53 MPa. Comparing 2.5 with 2.5, the result is false because 2.5 is less than 2.53, resulting in a false check and generating an inconsistency record. In this record, the changed object identifier is R-2001, the associated object identifier is P-3001, the changed attribute name is design pressure, the changed attribute value is 2.3 MPa, and the current attribute value of the associated object is 2.5 MPa. The violated constraint is that the pipeline design pressure should be greater than or equal to 1.1 times the reactor design pressure. Reverse calculation shows that the pipeline design pressure should be greater than or equal to 2.53 MPa. Querying the standard pressure rating series 0.6, 1.0, 1.6, 2.5, 4.0, 6.3, and 10.0 MPa, the largest value is selected. The closest value to 2.53 MPa is 4.0 MPa. The proposed adjustment is to increase the design pressure of pipeline P-3001 from 2.5 MPa to 4.0 MPa. Next, pipeline P-3002 is processed. The current design pressure is read as 4.0 MPa. A verification expression is constructed: 4.0 ≥ 2.53. The calculation result is true, and the verification passes without generating a record. Pipeline P-3003 is processed. The current design pressure is read as 2.8 MPa. A verification expression is constructed: 2.8 ≥ 2.53. The calculation result is true, and the verification passes. However, further calculation shows a margin of 2.8 minus 2.53 equals 0.27 MPa. The margin as a percentage of the current value is 0.27 divided by 2.8, approximately 0.096, or 9.A 6% error margin was detected, indicating insufficient pressure margin. An early warning record was generated, suggesting an assessment of whether to increase the pressure level. After traversing the data, one inconsistency record was obtained for pipeline P-3001 and one early warning record for pipeline P-3003. This record set was returned to the process engineer, simultaneously triggering a database transaction rollback. The design pressure attribute value of reactor R-2001 was restored from 2.3 MPa to 1.8 MPa. After reviewing the inconsistency record, the process engineer notified the piping engineer, who modified the design pressure attribute of pipeline P-3001 from 2.5 MPa to 4.0 MPa. After the modification, the process engineer resubmitted the reactor design pressure change request and executed the above verification process again. This time, the verification expression for pipeline P-3001 became 4.0 greater than or equal to 2.53, which is true. All three pipelines passed the verification, no inconsistency record was generated, the database transaction was successfully committed, and the design pressure attribute of reactor R-2001 was finally updated to 2.3 MPa.

[0051] In one specific embodiment, step S3 includes:

[0052] Extract the spatial coordinate attributes of engineering objects from the data object metamodel, and construct a spatial topology graph using engineering objects as vertices and physical connection relationships as edges.

[0053] Extract the tag labels and flow arrows of the engineering objects from the flowchart document, establish a mapping relationship between the flowchart elements and the engineering objects in the data object meta-model based on the tag labels, and construct the flowchart by using the engineering objects as vertices and the flow direction as directed edges based on the flow arrows.

[0054] Traverse each directed edge in the flowchart to extract the start and end objects, and search for the connection path to the end object in the spatial topology graph, starting from the start object.

[0055] When no connection path can be found or the path does not conform to the process logic, record the starting object identifier, the ending object identifier, and the defect type.

[0056] Specifically, the spatial coordinate attributes of engineering objects are extracted from the data object metamodel. These attributes include three numerical fields: X, Y, and Z coordinates in three-dimensional space. All engineering objects in the data object metamodel are traversed to read their coordinate attributes. Engineering objects are then used as vertices to construct a spatial topology graph. This graph is represented using a graph data structure. The vertex set of the graph contains all engineering objects, and the edge set represents the physical connections between them. These physical connections are established by determining the spatial distance between the start and end coordinates of pipe objects and the connection point coordinates of equipment objects. Specifically, all pipe objects are traversed, and the start and end coordinates of each pipe are extracted. A spherical search domain with a search radius of 50 is set at the start coordinate position. 0mm. Within the search domain, query whether there is a connecting center point of an equipment object, an endpoint of other pipe objects, a port of a valve object, or a branch point of a tee object. For each candidate connection point found within the search domain, calculate the Euclidean distance between its coordinates and the coordinates of the pipe start point. The Euclidean distance calculation formula is the square root of the sum of the squares of the X, Y, and Z components of the candidate point coordinates minus the square of the starting point coordinates. When the calculated distance is less than the connection threshold of 150mm, it is determined that a valid connection is established between the pipe start point and the candidate connection point. Create an undirected edge in the spatial topology map from the pipe object to the object to which the candidate connection point belongs. The attribute field of the edge records the connection type and connection precision, i.e., the actual distance value. Perform the same search and connection judgment process on the pipe end point.The process involves extracting tag labels and flow arrows from flowchart documents, typically in PDF or image format, representing process flow diagrams and piping / instrumentation diagrams. Optical character recognition (OCR) is used to scan the flowchart image, identifying text regions and extracting tag label text. Tag labels include equipment tag numbers, pipe tag numbers, valve tag numbers, and instrument tag numbers. Image recognition algorithms are then used to identify arrow symbols in the flowchart, extracting their start and end points and direction. The process of mapping flowchart elements to engineering objects in the data object meta-model based on tag labels involves querying the data object meta-model for each identified tag label text, matching the object identifier field value with the tag label text using either exact string matching or fuzzy matching with filtering. After comparing spaces and special characters, if a match is found, a corresponding record is created in the mapping table for the flowchart element identifier and the engineering object identifier. Based on the flow direction arrows, the engineering objects are used as vertices and the flow direction is used as directed edges to construct the flowchart. The flowchart is also represented using a graph data structure. The set of vertices in the graph is the engineering objects in the data object meta-model, and the set of edges in the graph is directed edges representing the upstream and downstream relationships of the process flow. The method for constructing directed edges is as follows: for each identified flow direction arrow, the starting element is located in the flowchart based on the starting position of the arrow, and the starting object is obtained by querying the mapping table for the corresponding engineering object of the starting element. The ending element is located based on the ending position of the arrow and the ending object is obtained by querying. A directed edge is created in the flowchart from the starting object to the ending object, and the direction of the directed edge represents the flow direction of the process flow. The process iterates through each directed edge in the flowchart to extract the start and end objects. A loop is used to sequentially visit each directed edge in the flowchart's edge set. The start and end object identifier fields are read from the directed edge data structure. A breadth-first search algorithm is used to search for a connection path to the end object in the spatial topology graph, starting from the start object. The execution steps of the breadth-first search are: initializing a queue data structure and adding the start object identifier to the queue; initializing a set of visited objects to prevent duplicate visits; retrieving an object identifier from the head of the queue as the current object; and querying the current object in the spatial topology graph. All adjacent objects of an object are those directly connected by undirected edges. Traverse the set of adjacent objects. For each adjacent object, check if its identifier is equal to the identifier of the destination object. If they are equal, the search is successful, the sequence of objects traversed from the starting point to the destination is recorded as the connection path, and the search is terminated. If they are not equal, check if the adjacent object is in the visited set. If not, add its identifier to the queue and the visited set. Repeat the steps of retrieving objects from the queue and querying adjacent objects until the queue is empty or the destination object is found. The search process is set to a maximum search depth of 8 levels, that is, a maximum of 8 intermediate objects are traversed from the starting point. If the depth limit is exceeded, the search is terminated and it is determined that no connection path has been found.When no connection path is found, it is determined to be a spatial connection missing defect. The starting object identifier, ending object identifier, and defect type field values ​​are recorded as spatial connection missing. When a connection path is found but the path does not conform to the process logic, it is determined to be a path logic mismatch defect. The method for determining whether the path conforms to the process logic is to extract the intermediate node sequence on the connection path and query the dependency mapping table to see if the process corresponding to the directed edge of the process graph requires a specific type of intermediate object. For example, if the process flow diagram shows that a regulating valve should be set between the reactor and the cooler, then check whether there is an object with the object type of valve and the control type attribute of regulating valve in the intermediate node sequence. If the object is missing or the object type does not match, it is determined that the path does not conform to the process logic. The starting object identifier, ending object identifier, and defect type field values ​​are recorded as path logic mismatch. All defect records are summarized into the defect record set.For example, the piping and instrumentation flowchart of a power engineering project shows that water flows from the outlet of boiler B-1001 through a pipeline to the inlet of turbine T-1001. Optical character recognition (OCR) extracts the boiler tag number B-1001 and the turbine tag number T-1001 from the flowchart. Image recognition extracts the flow direction arrow pointing from B-1001 to T-1001. The data object meta-model is then used to query the boiler object with the identifier B-1001 and the turbine object with the identifier T-1001, establishing a mapping relationship between flowchart elements and engineering objects. Finally, a directed edge from B-1001 to T-1001 is created in the flowchart. Traverse the flowchart to extract the directed edge, with the starting object identifier B-1001 and the ending object identifier T-1001. Perform a breadth-first search in the spatial topology graph starting from B-1001. Initialize the queue and add B-1001. Remove B-1001 from the queue and query its adjacent objects. The query results are pipes P-5001 and P-5002. Check if P-5001 and P-5002 are equal to T-1001; if not, add P-5001 and P-5002 to the queue and the visited set. Remove P-5001 from the queue and query its adjacent object, which is valve V-5. 001. Determine if V-5001 is not equal to T-1001, add V-5001 to the queue, retrieve V-5001 from the queue and check its adjacent object, which is pipeline P-5003. Determine if P-5003 is not equal to T-1001, add P-5003 to the queue, retrieve P-5003 from the queue and check if its adjacent object contains T-1001. If they are equal, the search is successful. Record the connection path as B-1001 to P-5001 to V-5001 to P-5003 to T-1001, with the intermediate node sequence being P-5001, V-5001, P-5003. (This is related to the dependency relationship.) The mapping table is used to query the process flow requirements from the boiler to the turbine. The query results show that a main steam regulating valve should be installed at the boiler outlet. The object type of intermediate node V-5001 is checked and found to be a valve. The control type attribute value of V-5001 is read as a shut-off valve. It is determined that a shut-off valve is not the same as a regulating valve. The path does not conform to the process logic, and a defect record is generated. The starting object identifier is B-1001, the ending object identifier is T-1001, the defect type is path logic mismatch, and the problem description is: According to the process flow diagram, a regulating valve should be installed between the boiler and the turbine, but the valve V-5001 in the current connection is a shut-off valve, which does not meet the requirements.

[0057] In one specific embodiment, step S4 includes:

[0058] Establish a version chain for each project object in the data object metamodel. When the attributes of a project object are modified, create a new version node to record the attribute values ​​before and after the change and link it to the previous version node.

[0059] A weighted graph is constructed based on the dependency mapping table. The attribute values ​​before and after the change of the changed object are extracted from the version chain. The change magnitude is calculated. The tightness is determined according to the dependency type. The criticality is determined according to the change attribute type. The margin is obtained by calculating the ratio of the difference between the current value and the required value of the target object to the margin. The edge weight is obtained by multiplying the tightness, criticality, margin and change magnitude.

[0060] When an engineering object in the data object metamodel changes, the queue is initialized and the changed object and initial impact weight value are added to the queue. The object is retrieved from the queue, the edge is queried in the weighted graph, and the target object and edge weight are extracted.

[0061] The influence weight of the current object is multiplied by the edge weight and then multiplied by the decay coefficient corresponding to the propagation level to obtain the influence weight of the target object. When the influence weight is greater than the threshold, the target object is added to the queue to continue propagation.

[0062] Specifically, a version chain is established for each project object in the data object metamodel. The version chain adopts a singly linked list data structure. Each version node contains four fields: version identifier, timestamp, change attribute list, and pointer to the previous version. The version identifier is used to uniquely identify the version node. The timestamp records the precise time of version creation. The change attribute list records the names of the attributes that have changed relative to the previous version and their attribute values ​​before and after the change. The pointer to the previous version stores the memory address or version identifier of the previous version node. When the attributes of the project object are modified, the database trigger or application listener captures the attribute modification event. The process of creating a new version node is to generate a new version identifier in the format of object identifier plus version sequence number, record the current timestamp, record the modified attribute name in the change attribute list, read the attribute value before modification from the database, and obtain the attribute value after modification from the modification request, set the pointer field of the new version node to point to the current latest version node, update the current version pointer of the object to point to the newly created version node, and complete the linking of the version chain.A weighted graph is constructed based on the dependency mapping table. The data structure of the weighted graph is a graph, where the vertices are engineering objects in the data object metamodel, and the edges are directed edges representing dependencies between objects. Each edge has a weight value, and the calculation of the edge weight involves four factors: tightness, criticality, margin, and change magnitude. Extracting the pre-change and post-change attribute values ​​of a changed object from the version chain involves accessing the current version node of the changed object and reading the old and new values ​​of the changed attributes from the changed attribute list of the version node. The change magnitude is calculated by subtracting the absolute value of the pre-change attribute value from the post-change attribute value and dividing by the pre-change attribute value to obtain the relative proportion of the change magnitude. Determining the tightness based on the dependency type involves querying a predefined tightness value table. The tightness of physical connection dependencies is 1.0, parameter reference dependencies are 0.8, control logic dependencies are 0.7, and spatial location dependencies are 0.5. Determining the criticality based on the changed attribute type involves taking a value from a predefined criticality table. The table shows that the criticality of geometric dimension attributes is 0.9, pressure and temperature attributes are 0.8, material attributes are 0.7, and annotation attributes are 0.3. The specific method for calculating the margin by the ratio of the difference between the current value and the required value of the target object to the margin is as follows: First, calculate the required value that the target object should meet based on the changed attribute values ​​of the changed object and the constraint rule expressions in the dependency mapping table. For example, if the constraint rule is that the pipeline design pressure is greater than or equal to the equipment design pressure multiplied by 1.1, and the changed equipment design pressure is 3.0 MPa, the calculated required value is 3.0 multiplied by 1.1, which equals 3.3 MPa. Extract the current attribute value of the target object from the data object meta-model. Simultaneously, calculate the required value before the change as the equipment pressure before the change multiplied by 1.1. Calculate the remaining margin by subtracting the new required value from the current value, and calculate the original margin by subtracting the original required value from the current value. Divide the remaining margin by the original margin to obtain the margin ratio. Multiply the four values—tightness, criticality, 1 minus the margin ratio, and change magnitude—to obtain the edge weight. When an engineering object in the data object metamodel changes, an impact propagation analysis is triggered. The initial queue data structure adopts a first-in-first-out queue. The identifier of the changed object and the initial impact weight value of 1.0 are combined into a tuple and added to the queue. At the same time, the set of affected object records is initialized to store all affected objects and their impact weight values. A tuple is taken from the head of the queue to extract the identifier of the current object and the current impact weight value. In the weighted graph, all outgoing edges starting from the identifier of the current object are queried. Outgoing edges represent other objects that will be affected by the change of the current object. The outgoing edge set is traversed to extract the target object identifier and the edge weight value of each outgoing edge.The initial influence weight is obtained by multiplying the influence weight of the current object by the edge weight. Then, the influence weight of the target object is obtained by multiplying it by the corresponding attenuation coefficient according to the propagation level. The propagation level is determined by recording the number of edges traversed from the source object to the current target object. The attenuation coefficient is 1.0 for level 1 influence (directly affected), 0.8 for level 2 influence, 0.6 for level 3 influence, and 0.4 for level 4 and above influence. It is determined whether the influence weight of the target object is greater than the preset threshold of 0.15. When the influence weight is greater than the threshold, the target object identifier and influence weight are combined into a tuple and added to the queue for continued propagation. At the same time, the target object identifier, influence weight, and propagation path from the source object to the target object are recorded in the influence object record set. When the influence weight is less than or equal to the threshold, the propagation of this branch is stopped and the target object is not added to the queue. The steps of retrieving objects from the queue and querying edges are repeated until the queue is empty. After the influence propagation analysis is completed, all objects with influence weight values ​​greater than the threshold are selected from the influence object record set as the affected object set.

[0063] In one specific embodiment, step S5 includes:

[0064] Load the attribute list and evaluation function from the scene mapping knowledge base according to the scene type. The attribute list includes a list of required attributes and a list of optional attributes.

[0065] Traverse the engineering objects in the data object metamodel, calculate the ratio of the number of existing required attributes to the total number of required attributes to obtain the completeness of required attributes, calculate the ratio of the number of existing optional attributes to the total number of optional attributes to obtain the completeness of optional attributes, verify the attribute values ​​with the constraint rules to obtain the attribute accuracy, and extract the last update timestamp to calculate the time difference to obtain the data timeliness.

[0066] The score is obtained by weighting and summing the required attribute completeness, optional attribute completeness, attribute accuracy, and data timeliness into the evaluation function;

[0067] When the score is below the threshold, query the associated objects in the weighted graph, extract the attribute values ​​of the associated objects, calculate the missing attribute values ​​based on the process relationship, and add a mark.

[0068] Specifically, attribute lists and evaluation functions are loaded from the scenario mapping knowledge base according to the scenario type. The scenario mapping knowledge base stores the differentiated data quality requirements of different application scenarios. Scenario types include typical application scenarios such as 3D visualization roaming, construction progress management, engineering quantity statistics, operation and maintenance equipment management, and digital twin real-time monitoring. The attribute list is divided into two categories: required attribute list and optional attribute list. The required attribute list contains attribute fields that must be present in the application scenario, otherwise it cannot be used. The optional attribute list contains attribute fields that help improve the application effect but whose absence does not affect the basic function. The evaluation function defines the weighted calculation formula for calculating the data quality score, which includes weight coefficients for four dimensions: completeness of required attributes, completeness of optional attributes, attribute accuracy, and data timeliness. Different scenario types correspond to different weight coefficient configurations. The process iterates through the project objects in the data object metamodel, using a loop to sequentially access each project object instance stored in the data object metamodel. For the currently processed project object, it retrieves the total number of required attributes from the required attribute list loaded from the scene mapping knowledge base. It then checks the project object's attribute records to determine if each required attribute exists and has a non-empty value, counts the number of existing required attributes, and calculates the ratio of the number of existing required attributes to the total number of required attributes to obtain the required attribute completeness. This ratio ranges from 0 to 1. Finally, it retrieves the total number of optional attributes from the optional attribute list, checks the project object's attribute records to count the number of existing optional attributes, and calculates the ratio of the number of existing optional attributes to the total number of optional attributes to obtain the optional attributes. Completeness, the process of verifying attribute values ​​against constraint rules to obtain attribute accuracy involves traversing all attributes of the project object, querying the constraint rules related to each attribute from the dependency mapping table, substituting the attribute values ​​into the constraint rule expressions for logical operations to determine whether the constraint conditions are met, counting the number of attributes that pass the verification, calculating the attribute accuracy by dividing the number of attributes that pass the verification by the total number of attributes, extracting the last update timestamp field of the project object, calculating the time difference by subtracting the last update timestamp from the current system time, obtaining the timeliness threshold for this scenario type from the scenario mapping knowledge base, calculating the data timeliness by subtracting the time difference from 1 and dividing by the timeliness threshold, and when the time difference exceeds the threshold, the data timeliness is 0. The score is obtained by substituting the completeness of required attributes, the completeness of optional attributes, the accuracy of attributes, and the timeliness of data into the evaluation function and summing them by weight. Specifically, the calculation process is as follows: extract the first weight coefficient corresponding to the completeness of required attributes, the second weight coefficient corresponding to the completeness of optional attributes, the third weight coefficient corresponding to the accuracy of attributes, and the fourth weight coefficient corresponding to the timeliness of data from the evaluation function. Multiply the completeness of required attributes by the first weight coefficient to obtain the first weighted value, multiply the completeness of optional attributes by the second weight coefficient to obtain the second weighted value, multiply the accuracy of attributes by the third weight coefficient to obtain the third weighted value, and multiply the timeliness of data by the fourth weight coefficient to obtain the fourth weighted value. The four weighted values ​​are then added together to obtain the score. The score range is 0 to 1 or 0 to 100, depending on the dimension of the weight coefficients.When the score is below a threshold, the data quality of the project object is deemed insufficient to support the current application scenario. An intelligent data completion process is then initiated. This involves querying the weighted graph for related objects with technological connections to the project object. The query method involves finding edges in the weighted graph that originate from or end with the project object and have a parameter reference dependency type. The identifier of the related object is extracted from the other end of the edge. Based on the identifier, the attribute records of the related object are read from the data object metamodel. Attribute values ​​related to the missing attribute are extracted from the related object. The missing attribute value is calculated based on the technological connections. The technological connections define a formula for inferring the missing attribute of the target object from the attributes of the related object; for example, the pump's outlet pressure equals the downstream... The equipment inlet pressure plus pipeline resistance loss is calculated using fluid dynamics formulas based on pipeline length, diameter, and flow rate, or estimated as 5% to 10% of the inlet pressure based on empirical coefficients. The attribute values ​​of the associated objects are substituted into the calculation formula to obtain the estimated values ​​of the missing attributes. The estimated values ​​are written into the attribute records of the engineering object and marked. The marking content includes the "Source of Estimation" field indicating which associated object the value was derived from, the "Base of Estimation" field indicating the process relationship or calculation formula used, and the "Estimation Accuracy" field indicating the error range or confidence interval of the estimated value. The marking distinguishes the estimated attributes of the engineering object from the measured or design attributes. The application system decides whether to use the estimated value or prompts the user that the attribute is an estimated value based on the marking.

[0069] In one specific embodiment, the required attribute completeness, optional attribute completeness, attribute accuracy, and data timeliness are substituted into the evaluation function and weighted summed to obtain a score, including:

[0070] Based on the scenario type, extract the first weight coefficient corresponding to the completeness of required attributes, the second weight coefficient corresponding to the completeness of optional attributes, the third weight coefficient corresponding to the accuracy of attributes, and the fourth weight coefficient corresponding to the timeliness of data from the evaluation function;

[0071] The first weighted value is obtained by multiplying the completeness of the required attributes by the first weight coefficient, the second weighted value is obtained by multiplying the completeness of the optional attributes by the second weight coefficient, the third weighted value is obtained by multiplying the accuracy of the attributes by the third weight coefficient, and the fourth weighted value is obtained by multiplying the timeliness of the data by the fourth weight coefficient.

[0072] The score is obtained by adding the first weighted value, the second weighted value, the third weighted value, and the fourth weighted value.

[0073] The score is compared with the threshold corresponding to the scene type. When the score is less than the threshold, it is judged as insufficient quality. When the score is greater than or equal to the threshold, it is judged as qualified quality.

[0074] Specifically, based on the scenario type, the evaluation function extracts the first weight coefficient corresponding to the completeness of required attributes, the second weight coefficient corresponding to the completeness of optional attributes, the third weight coefficient corresponding to the accuracy of attributes, and the fourth weight coefficient corresponding to the timeliness of data. The evaluation function is stored in the scenario mapping knowledge base as a configuration record associated with the scenario type. The configuration record contains a scenario identifier field and four weight coefficient fields. Based on the input scenario type, the matching configuration record is queried in the scenario mapping knowledge base, and the values ​​of the first, second, third, and fourth weight coefficients are read from the configuration record. The weight coefficients range from 0 to 1, and the sum of the four weight coefficients is equal to 1. The weight coefficient configuration for different scenario types reflects the differentiated requirements for different dimensions of data quality. For example, in a 3D visualization scenario, the weight of the completeness of required attributes is set to 0.5 because objects cannot be displayed if coordinates or size attributes are missing. In an operation and maintenance management scenario, the weight of the accuracy of attributes is set to 0.35 because incorrect technical parameters will lead to errors in the maintenance plan. The first weighted value is obtained by multiplying the required attribute completeness by the first weight coefficient. The calculation process involves multiplying the required attribute completeness value obtained in the previous step with the first weight coefficient value extracted from the evaluation function. The result of the multiplication operation is assigned to the first weighted value variable. The second weighted value is obtained by multiplying the optional attribute completeness by the second weight coefficient. The third weighted value is obtained by multiplying the attribute accuracy by the third weight coefficient. The fourth weighted value is obtained by multiplying the data timeliness by the fourth weight coefficient. The dimensions of the four weighted values ​​are the same as the original completeness and accuracy values, and the value range is from 0 to the upper limit of the corresponding weight coefficient. The score is obtained by adding the first, second, third, and fourth weighted values. The calculation process involves performing an addition operation on the four weighted values, and the result of the addition operation is assigned to the score variable. Since the sum of the four weight coefficients is 1 and the original completeness and accuracy values ​​range from 0 to 1, the score ranges from 0 to 1. The closer the score value is to 1, the higher the data quality; the closer the score value is to 0, the lower the data quality.The score is compared with the threshold corresponding to the scene type. The threshold is stored in the scene mapping knowledge base in association with the scene type. The scene mapping knowledge base is queried according to the scene type to obtain the quality qualification threshold value for that scene. The score is compared with the threshold. When the score is less than the threshold, it is judged as insufficient quality. Insufficient quality means that the data quality of the project object cannot meet the minimum requirements of the application scenario. The data completion process is triggered or the object is excluded from the returned dataset. When the score is greater than or equal to the threshold, it is judged as qualified quality. Qualified quality means that the data quality of the project object meets the requirements of the application scenario. The object is included in the returned dataset for the application system to use. The comparison result returns a Boolean value of true for qualified or false for insufficient. The corresponding subsequent processing logic is executed according to the comparison result.

[0075] The above describes the engineering and technical data governance method for the entire lifecycle in the embodiments of this application. The following describes the engineering and technical data governance system for the entire lifecycle in the embodiments of this application. Please refer to [link / reference]. Figure 2 One embodiment of the engineering technology data governance system oriented towards the entire life cycle in this application includes:

[0076] The partitioning module is used to divide the attributes of engineering objects into anchor attribute sets and extended attribute sets. The anchor attribute sets are marked with a locking tag, and the extended attribute sets are layered according to stages to obtain the data object meta-model.

[0077] The query module is used to establish a dependency mapping table based on the data object meta-model. When the object attributes change, the dependency mapping table is queried to extract the associated objects, and the attributes of the associated objects are verified against the constraint rules.

[0078] The traversal module is used to establish a spatial topology graph and a flowchart based on the data object meta-model, traverse the directed edges of the flowchart to search for paths in the spatial topology graph, and record inconsistent paths as defects.

[0079] The filtering module is used to build a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated by density, criticality and margin. When the objects in the data object meta-model change, the module traverses the weighted graph and multiplies the edge weights by the decay coefficient to filter objects with weight values ​​greater than a threshold.

[0080] The scoring module is used to load an attribute list and evaluation function according to the scene type, score the objects in the data object meta-model, and extract the related object attributes in the weighted graph when the score is lower than the threshold, calculate the missing attribute value according to the association relationship and add a mark.

[0081] above Figure 2The engineering and technical data governance system oriented towards the entire life cycle in this embodiment of the invention will be described in detail from the perspective of modular functional entities. The engineering and technical data governance device oriented towards the entire life cycle in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0082] Reference Figure 3 This invention also provides an engineering technology data governance device oriented towards the entire lifecycle. This device can be a server, and its internal structure can be as follows: Figure 3 As shown. This lifecycle-oriented engineering data governance device includes a processor, memory, display screen, input device, network interface, and database connected via a system bus. The processor in this computer design provides computing and control capabilities. The memory of this lifecycle-oriented engineering data governance device includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of this lifecycle-oriented engineering data governance device stores the data corresponding to this embodiment. The network interface of this lifecycle-oriented engineering data governance device is used for communication with external terminals via network connection. When the computer program is executed by the processor, it implements the above-described method.

[0083] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the engineering technology data governance equipment for the entire life cycle to which the present invention is applied.

[0084] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the engineering technology data governance method for the entire life cycle.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0086] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an engineering data management device (which can be a personal computer, server, or network device, etc.) that is designed for the entire lifecycle to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for engineering technology data governance oriented towards the entire life cycle, characterized in that, The method includes: Step S1: Divide the attributes of the project object into anchor attribute set and extended attribute set. Add a locking mark to the anchor attribute set and layer the extended attribute set according to stage to obtain the data object metamodel. Step S2: Establish a dependency mapping table based on the data object meta-model. When the object attributes change, query the dependency mapping table to extract the associated objects and verify the attributes of the associated objects against the constraint rules. Step S3: Establish a spatial topology graph and a flowchart graph based on the data object meta-model. Traverse the directed edges of the flowchart graph to search for paths in the spatial topology graph. Record inconsistent paths as defects. Step S4: Establish a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated from density, criticality, and margin. When an object in the data object meta-model changes, traverse the weighted graph and multiply the edge weights by a decay coefficient to filter objects with weight values ​​greater than a threshold. This includes: establishing a version chain for each project object in the data object meta-model; when the attributes of a project object are modified, create a new version node to record the attribute values ​​before and after the change and link it to the previous version node; construct the weighted graph based on the dependency mapping table; extract the attribute values ​​before and after the change of the changed object from the version chain; calculate the change magnitude; determine the density based on the dependency type; determine the criticality based on the changed attribute type; calculate the margin by the ratio of the difference between the current value and the required value of the target object to the margin; and multiply the density, criticality, margin, and change magnitude to obtain the edge weights. When an engineering object in the data object metamodel changes, a queue is initialized and the changed object and its initial influence weight value are added to the queue. The object is retrieved from the queue, and the edge is retrieved from the weighted graph. The target object and edge weight are extracted. The influence weight value of the current object is multiplied by the edge weight and then multiplied by the attenuation coefficient corresponding to the propagation level to obtain the influence weight value of the target object. When the influence weight value is greater than the threshold, the target object is added to the queue for continued propagation. Step S5: Load the attribute list and evaluation function according to the scene type, score the objects in the data object meta-model, and when the score is lower than the threshold, extract the related object attributes in the weighted graph, calculate the missing attribute values ​​according to the association relationship, and add a mark.

2. The engineering technology data governance method oriented towards the entire life cycle as described in claim 1, characterized in that, Step S1 includes: Define the anchor point attribute set for the engineering object. The anchor point attribute set includes object identifier, design pressure, design temperature and material. Add the locking flag to each attribute in the anchor point attribute set and set constraints to prevent modification. The extended attribute set is defined for the engineering object, and the extended attribute set is divided into a design extended attribute subset, a construction extended attribute subset, and an operation and maintenance extended attribute subset; Establish attribute inheritance rules so that when a project object moves to the next stage, it inherits the anchor attribute set and extended attribute subset of the previous stage and allows writing to the extended attribute subset of the current stage; Define cross-stage constraint rules. When writing extended attributes, extract the attribute values ​​of the anchor attribute set. Verify the extended attribute values ​​to be written with the cross-stage constraint rules to obtain the data object meta-model.

3. The engineering technology data governance method oriented towards the entire life cycle according to claim 1, characterized in that, Step S2 includes: Establish the dependency mapping table based on the parameter dependencies between objects in the data object metamodel, and define the constraint rules for each dependency. When the attributes of objects in the data object metamodel change, the matching dependency records are queried in the dependency mapping table, and the associated object identifiers are extracted to obtain the associated object set; Traverse the set of associated objects, extract the current attribute values ​​of the associated objects from the data object meta-model, construct a verification expression according to the constraint rules, and substitute the changed attribute values ​​and the current attribute values ​​into the verification expression for calculation. When the result of the verification expression is false, an inconsistency record is generated and attribute write operations are prevented.

4. The engineering technology data governance method oriented towards the entire life cycle according to claim 1, characterized in that, Step S3 includes: The spatial coordinate attributes of engineering objects are extracted from the data object meta-model, and the spatial topology graph is constructed by using engineering objects as vertices and physical connection relationships as edges. Extract the tag number and flow direction arrow of the engineering object from the flowchart document, establish a mapping relationship between the flowchart elements and the engineering objects in the data object meta-model according to the tag number, and construct the flowchart spectrum with the engineering object as the vertex and the flow direction as the directed edge according to the flow direction arrow; Traverse each directed edge in the flowchart to extract the start object and end object, and search for a connection path to the end object in the spatial topology graph, starting from the start object. When no connection path can be found or the path does not conform to the process logic, record the starting object identifier, the ending object identifier, and the defect type.

5. The engineering technology data governance method oriented towards the entire life cycle according to claim 1, characterized in that, Step S5 includes: The attribute list and the evaluation function are loaded from the scene mapping knowledge base according to the scene type. The attribute list includes a list of required attributes and a list of optional attributes. Traverse the engineering objects in the data object metamodel, calculate the ratio of the number of existing required attributes to the total number of required attributes to obtain the completeness of required attributes, calculate the ratio of the number of existing optional attributes to the total number of optional attributes to obtain the completeness of optional attributes, verify the attribute values ​​with the constraint rules to obtain the attribute accuracy, and extract the last update timestamp to calculate the time difference to obtain the data timeliness. The score is obtained by substituting the completeness of the required attributes, the completeness of the optional attributes, the accuracy of the attributes, and the timeliness of the data into the evaluation function and performing a weighted summation. When the score is lower than the threshold, query the associated objects in the weighted graph, extract the attribute values ​​of the associated objects, calculate the missing attribute values ​​according to the process association relationship, and add the marker.

6. The engineering technology data governance method oriented towards the entire life cycle according to claim 5, characterized in that, The step of substituting the completeness of the required attributes, the completeness of the optional attributes, the accuracy of the attributes, and the timeliness of the data into the evaluation function and then performing a weighted sum to obtain the score includes: Based on the scenario type, extract from the evaluation function the first weight coefficient corresponding to the completeness of required attributes, the second weight coefficient corresponding to the completeness of optional attributes, the third weight coefficient corresponding to the accuracy of attributes, and the fourth weight coefficient corresponding to the timeliness of data; The first weighted value is obtained by multiplying the completeness of the required attribute by the first weight coefficient, the second weighted value is obtained by multiplying the completeness of the optional attribute by the second weight coefficient, the third weighted value is obtained by multiplying the attribute accuracy by the third weight coefficient, and the fourth weighted value is obtained by multiplying the data timeliness by the fourth weight coefficient. The score is obtained by adding the first weighted value, the second weighted value, the third weighted value, and the fourth weighted value. The score is compared with the threshold corresponding to the scene type. When the score is less than the threshold, it is determined to be of insufficient quality. When the score is greater than or equal to the threshold, it is determined to be of acceptable quality.

7. A data governance system for engineering technology oriented throughout the entire life cycle, characterized in that, For implementing the engineering and technical data governance method oriented towards the entire life cycle as described in any one of claims 1 to 6, the engineering and technical data governance system oriented towards the entire life cycle includes: The partitioning module is used to divide the attributes of engineering objects into anchor attribute sets and extended attribute sets. The anchor attribute sets are marked with a locking tag, and the extended attribute sets are layered according to stages to obtain the data object meta-model. The query module is used to establish a dependency mapping table based on the data object meta-model. When the object attributes change, the dependency mapping table is queried to extract the associated objects, and the attributes of the associated objects are verified against the constraint rules. The traversal module is used to establish a spatial topology graph and a flowchart based on the data object meta-model, traverse the directed edges of the flowchart to search for paths in the spatial topology graph, and record inconsistent paths as defects. A filtering module is used to build a weighted graph based on the dependency mapping table. The edge weights of the weighted graph are calculated by density, criticality, and margin. When an object in the data object meta-model changes, the module traverses the weighted graph and multiplies the edge weights by a decay coefficient to filter objects with weight values ​​greater than a threshold. This includes: establishing a version chain for each project object in the data object meta-model; when the attributes of a project object are modified, creating a new version node to record the attribute values ​​before and after the change and linking it to the previous version node; constructing the weighted graph based on the dependency mapping table; extracting the attribute values ​​before and after the change of the changed object from the version chain; calculating the change magnitude; determining the density based on the dependency type; determining the criticality based on the changed attribute type; calculating the margin by the ratio of the difference between the current value and the required value of the target object to the margin; and multiplying the density, criticality, margin, and change magnitude to obtain the edge weights. When an engineering object in the data object metamodel changes, a queue is initialized and the changed object and its initial influence weight value are added to the queue. The object is retrieved from the queue, and the edge is retrieved from the weighted graph. The target object and edge weight are extracted. The influence weight value of the current object is multiplied by the edge weight and then multiplied by the attenuation coefficient corresponding to the propagation level to obtain the influence weight value of the target object. When the influence weight value is greater than the threshold, the target object is added to the queue for continued propagation. The scoring module is used to load an attribute list and evaluation function according to the scene type, score the objects in the data object meta-model, and extract the related object attributes in the weighted graph when the score is lower than the threshold, calculate the missing attribute value according to the association relationship and add a mark.

8. An engineering technology data governance device for the entire life cycle, characterized in that, It includes a memory and a processor, the memory storing a computer program that can run on the processor, and the processor executing the computer program to implement the engineering technology data governance method for the entire life cycle as described in any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it causes the processor to execute the engineering data governance method for the entire life cycle as described in any one of claims 1 to 5.

Images