A full life cycle data management system and method for a smart oil depot

Abstract

This invention relates to the field of oil depot management technology, specifically disclosing a smart oil depot's full lifecycle data management system and method. The system constructs a data lineage graph G using a globally unique object code (UOID) as the primary key, achieving unified identification and continuous association of multi-source heterogeneous data during the construction and operation phases. Upon receiving a change event queue Q, it triggers a domain-limited traversal to obtain the set of affected objects U. aff And generate a minimum set of changed objects U min Only for U min Perform cross-modal alignment verification and rule base consistency verification to generate a structured record of discrepancies; based on this, generate a differential delivery package, calculate the consistency score S, and compare it with the acceptance threshold T. acc The comparison enables automatic determination and review of delivery nodes; at the same time, the acceptance results and lineage snapshots are solidified into a version backtracking chain, supporting traceability, auditing and rollback, improving data consistency and delivery efficiency.

Description

Technical Field

[0001] This invention relates to the field of oil depot management technology, and more specifically, to a smart oil depot's full lifecycle data management system and method. Background Technology

[0002] As the oil and gas storage and transportation industry transforms towards intelligence and digitalization, the data generated during the construction phase of smart oil depot projects—including design, procurement, construction, and completion data—and the data generated during the operation phase—including monitoring, maintenance, asset ledgers, and business management data—are characterized by multi-source heterogeneity and cross-system dispersion. The data formats include not only 3D models and spatial information but also structured information such as equipment ledgers, sensor locations, and business forms. During the handover from construction to operation, engineering data needs to be continuously delivered according to milestones and updated iteratively with changes. Without a unified data organization and quality control mechanism, delivered data often cannot be reliably taken over by the operation system, affecting subsequent operation and maintenance decisions and safety management.

[0003] Existing publicly available literature 1 (A Discussion on the Application of Digital Twin Technology in Enterprise Lifecycle—Taking D Chemical New Materials Company as an Example, 2024) proposes that digital twins can cover all stages of an enterprise's lifecycle, from factory design and construction to engineering delivery and intelligent operation and maintenance. It also points out that enterprises commonly face problems such as "serious data silos" during the implementation of digitalization, necessitating the integration of data during the construction phase and applications during the operation and maintenance phase to achieve continuous availability and consistent management of delivered data. However, this literature focuses more on lifecycle integration and application systems, and it still struggles to address specific technical challenges at the delivery node from engineering construction to operational takeover, such as the inability to reliably correspond the same object across systems, the difficulty in automatically verifying version evolution, and the difficulty in quantifying and accepting delivery quality when there are frequent changes in multi-source heterogeneous and multi-modal data.

[0004] Existing public literature 2 (Research on BIM Model Delivery Methods and Technologies for Construction Drawing Review, 2024) proposes, based on the IDM-MVD digital delivery framework under the IFC system, to construct a delivery process model and information requirements around the construction drawing review business, such as... Figure 1 As shown, a BPMN flowchart for the entire BIM lifecycle delivery process is provided. However, this literature mainly focuses on the delivery process and information requirement constraints of BIM models in the construction drawing review scenario. Faced with the handover of multimodal data (such as BIM, GIS, monitoring points and operation and maintenance business data) from the construction period to the operation period of smart oil depot projects under the conditions of multiple version iterations and multi-party collaborative changes, it is still difficult to directly achieve: cross-modal consistency determination of the same object at the delivery node, verifiable extraction of differences, and acceptable organization of delivery content. Therefore, it is difficult to avoid problems such as mislabeling, omissions, version drift and untraceable delivery during operation takeover.

[0005] Therefore, there is an urgent need in this field for a system and method that can achieve consistent object correspondence, verifiable identification of differences, and support acceptance traceability at multimodal data delivery nodes. Summary of the Invention

[0006] To overcome the aforementioned deficiencies in the prior art, this invention provides a smart oil depot's full lifecycle data management system and method. This system solves the problems mentioned in the background by executing a consistency verification and difference extraction algorithm for multimodal engineering data, and forming a set of difference items and a differential delivery package based on UOID and lineage graph G evidence.

[0007] To achieve the above objectives, the present invention provides the following technical solution: A smart oil depot's full lifecycle data management system includes a unified object coding management module, a data lineage graph construction and update module, a consistency verification and automatic comparison module, a differential delivery package generation module, a data traceability acceptance and version management module, and a multi-source data access and fusion module. The system executes consistency verification and difference extraction algorithms for multimodal engineering data, constructs a data lineage graph G based on globally unique object codes (UOIDs), and receives a change event queue Q. When a change event is received, the system traverses the lineage graph G along a preset set of edge types, starting from the UOID corresponding to the change event, to obtain the set of affected objects. The traversal terminates when any of the following stopping conditions are met: the depth reaches a preset value; or the edge type to be expanded does not belong to the preset edge type. When assembling, the expansion along the edge is no longer performed; for each UOID in the affected object set, the corresponding object data is obtained from at least two data modalities and object alignment verification is completed; based on the rule base, the alignment object data is subjected to consistency verification and a set of differences is formed, the consistency verification includes at least attribute consistency verification and relationship consistency verification; a minimum set of changed objects is formed according to the set of differences and its lineage path; a differential delivery package is formed according to the minimum set of changed objects, the differential delivery package includes data ontology differences, lineage snapshots and verification logs; a consistency score is formed according to the set of differences and compared with a preset delivery threshold to determine whether the differential delivery package meets the delivery conditions; the delivery acceptance result is associated with the lineage snapshot and stored to form a version backtracking chain.

[0008] As a further aspect of the present invention, the globally unique object code (UOID) is used to uniquely identify the same business object within the scope of multi-source data accessed by the system. The business object includes equipment, components, pipelines, spatial units and their corresponding business entries. The UOID is generated by the unified object code management module or obtained by mapping from external identifiers. The mapping basis includes object type, spatial location, business primary key and version information, forming a correspondence table between UOID and each source data identifier.

[0009] As a further aspect of the present invention, the preset edge type set includes at least two types of edge types: mapping edge, dependency edge, and version evolution edge.

[0010] As a further aspect of the present invention, the object alignment verification includes uniqueness verification and existence verification; wherein, the uniqueness verification determines that the same UOID corresponds to only one valid object in the same data modality, and the existence verification determines that a preset object type has a corresponding object in a preset data modality.

[0011] As a further aspect of the present invention, the rule base includes a set of mandatory attributes and a set of relational constraints configured according to object type; wherein, the attribute consistency verification is performed within the scope of the mandatory attribute set, and the relational consistency verification includes the integrity determination of the connection relationship between the monitoring point UOID and the equipment / facility UOID or process node UOID.

[0012] As a further aspect of the present invention, the set of differences is a structured record, which includes at least the difference type, the modality involved, the difference field, the difference object UOID and the lineage path identifier; the minimum set of changed objects consists of the difference object UOID and the associated object UOID that satisfies the preset dependency constraint along the lineage path.

[0013] As a further aspect of the present invention, the consistency score is assigned a weight level according to the type of difference, and a higher weight level is assigned to the difference items corresponding to safety-critical objects or key monitoring points.

[0014] As a further aspect of the present invention, the consistency verification further includes spatial consistency verification; the spatial consistency verification determines spatial deviation based on at least two types of data among BIM model data, GIS spatial data and IoT monitoring point data, and when the spatial deviation exceeds a preset threshold, a spatial difference item is formed and included in the difference item set.

[0015] As a further aspect of the present invention, the verification log includes a source data version identifier and a lineage path identifier corresponding to each difference item in the difference item set, and the source data version identifier and the lineage path identifier match the corresponding record in the lineage snapshot.

[0016] A method for full lifecycle data management of a smart oil depot includes the following steps: Step 1: Generate a globally unique object code (UOID) and establish a mapping relationship between the UOID and the object identifiers of each source system; Step 2: Construct and update the data lineage graph G based on UOID and set the preset edge type set; Step 3: Receive change events in the change event queue Q, and traverse the lineage graph G along the preset edge type set starting from the UOID corresponding to the change event to obtain the set of affected objects. The traversal will terminate when the following stopping conditions are met: the traversal depth reaches the preset value, or the edge type of the edge to be expanded of the current node does not belong to the preset edge type set. Step 4: Obtain the corresponding object data of the affected object set from at least two data modalities and complete the object alignment verification; Step 5: Perform consistency verification based on the rule base and form a set of discrepancies; Step 6: Form a minimum set of changed objects based on the set of differences and their lineage paths; Step 7: Form a differential delivery package based on the minimum set of changed objects. The differential delivery package includes data ontology differential, lineage snapshot and verification log. Step 8: Generate a consistency score based on the set of discrepancies and compare it with a preset delivery threshold to determine delivery conditions. Generate an acceptance record and store it in association with the lineage snapshot to form a version backtracking chain.

[0017] As a further aspect of the present invention, each difference item in the difference item set records at least the difference type, the modality involved, the difference field and the lineage path identifier, and outputs a review instruction when the consistency score does not meet the preset delivery threshold.

[0018] The technical effects and advantages of the intelligent oil depot's full life-cycle data management system and method as described in this invention are as follows: This invention uses a rule base to uniformly manage mandatory attributes, relational constraints, unit normalization, and tolerance tables, and manages the minimum change object set U. min Perform rule base consistency verification and generate structured records of discrepancies; bind the discrepancies to the lineage path identifier p. id By combining source version information, the discrepancy results are made verifiable, recalculated, and interpretable. Quality issues can be accurately located to objects, fields, and source links, enhancing the credibility and consistency of data delivery results.

[0019] This invention constructs a data lineage graph G based on globally unique object codes (UOIDs), and automatically obtains the set of affected objects U by triggering an influence domain-limited traversal through a change event queue Q. aff And generate a minimum set of changed objects U min Only for U min The subsequent verification and delivery process transforms the scope of the delivery objects from a completely unordered quantity to a locally converged quantity, significantly reducing computational load and human intervention, and improving data delivery efficiency and processing stability.

[0020] This invention generates a differential delivery package based on a set of differences, including data difference (DataDiff), lineage snapshot (LineageSnapshot), and verification log (VerifyLog). The acceptance results are solidified into a version backtracking chain, enabling traceability of the delivery process, accountability, and version rollback. This ensures that the delivery status of data from the construction phase to the operation phase is continuously traceable, auditable, and reproducible, reducing the risks of mislabeling, omissions, and version drift, and improving the overall reliability and continuity of data management throughout the entire lifecycle.

[0021] This invention uses UOID as the unified primary key to complete the primary mapping and auxiliary feature matching of multi-source system objects, outputs a consistency score S through cross-modal alignment verification, and compares it with the acceptance threshold T. acc Automatic comparison enables automatic determination and review of delivery nodes; it reduces reliance on human experience and the cost of repeated reviews, making data consistency evaluation quantifiable, repeatable, and verifiable, further improving the objectivity of delivery decisions and the consistency of execution. Attached Figure Description

[0022] Figure 1 It consists of BPMN flowcharts based on existing technologies.

[0023] Figure 2 This is a structural block diagram of a smart oil depot's full lifecycle data management system according to the present invention.

[0024] Figure 3 This is a closed-loop flowchart for consistency verification and difference extraction of multimodal engineering data in this invention.

[0025] Figure 4 This is a schematic diagram of a data lineage snapshot sub-graph based on UOID according to the present invention. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] Example 1 This embodiment addresses the data handover scenario from the construction to the operation phase of a smart oil depot project. The oil depot includes facilities such as tank areas, pump rooms, loading and unloading platforms, fire protection systems, and pipe corridors. Construction-phase data includes 3D model data, 2D drawings and inventory lists, equipment procurement and installation records, construction and quality data, and completion and handover documents. Operation-phase data includes equipment ledgers, location configurations, monitoring and alarm records, maintenance work orders, and inspection records. Due to the long project cycle and numerous participating parties, design changes, equipment replacements, location adjustments, and spatial re-surveying occur throughout the entire process. Common problems include: inconsistent identification of the same object in different data sources, leading to unreliable cross-system correspondence; multiple version iterations causing deviations in attribute parameters, linkage relationships, and spatial locations, making automatic verification difficult; and the delivery phase still relies primarily on full packaging and manual sampling, resulting in high redundancy and difficulty in traceability during acceptance. Furthermore, mis-linking, omissions, and version drift are prone to occur during operation and handover. This embodiment presents a full lifecycle data management system that forms a closed loop of consistent object correspondence, verifiable difference identification, incremental delivery organization, and acceptance traceability by executing consistency verification and difference extraction algorithms for multimodal engineering data at delivery nodes.

[0028] like Figure 2 As shown in the figure, this embodiment of a smart oil depot's full lifecycle data management system consists of a multi-source data access and fusion module, a unified object coding management module, a data lineage map construction and update module, a consistency verification and automatic comparison module, a differential delivery package generation module, and a data traceability acceptance and version management module. The multi-source data access and fusion module accesses at least two data modalities. This embodiment selects four modalities to form a typical combination: 3D model data modality (including IFC and native model component data), spatial data modality (GIS elements and coordinate data), monitoring point data modality (point configuration and time-series data collection), and operational business data modality (structured data such as equipment ledgers, work orders, and inspection records). During the access phase, field naming, units of measurement, and time bases are standardized to form a unified object attribute view and event view. The object attribute view records snapshots of object static attributes, and the event view records object change events and event metadata.

[0029] To reduce differences on the access side, this embodiment specifies that: pressure is uniformly measured in kPa, temperature in ℃, and flow rate in m³. 3 / h, with length units standardized to m and timestamps standardized to UTC+8 millisecond timestamps. For data sources that do not meet the standardized unit requirement, the conversion is completed during the integration phase, and the conversion source is recorded in the event view metadata area. The conversion source must at least contain the original unit U. raw Conversion factor k conv Conversion time t conv When the conversion source for the same field in different modalities is missing, or the k of the same field is...conv When the link is inconsistent with the existing version and cannot be normalized through link conversion, the system marks this field as a candidate for unit anomaly. This unit anomaly difference item is then generated during the consistency verification phase and included in the scoring calculation, thus avoiding pseudo-consistency or pseudo-difference due to "same value, different units". In addition to the unit of measurement, the time base is unified during the access phase. A sampling period field is added to the collected data, with the sampling period measured in seconds, and written to the point configuration record. This avoids threshold judgment deviations caused by "inconsistent sampling frequency caliber" across systems for the same collection point.

[0030] The unified object coding management module generates globally unique object codes (UOIDs). The UOID serves as a unique primary key across modalities and versions. It employs a fixed-length coding structure, consisting of an object category segment, a region segment, a sequence segment, and a check segment. The object category segment's value set includes at least tanks, pumps, valves, pipe sections, monitoring points, documents, and business records. The region segment represents a tank area or loading / unloading area. The sequence segment is an incrementing serial number. The check segment is a set of check characters used for code integrity verification. In this embodiment, the UOID length is 24 characters, the region segment is 2 characters, and the sequence segment is a 10-digit number. The UOID coding rules are solidified as part of the delivery standard during the project initiation phase. The delivery standard also specifies the minimum set of deliverable fields and the set of relational constraints for different object categories. Subsequent rule base configurations, difference item field definitions, and check log fields are consistent with this delivery standard to avoid ambiguity among participants regarding "which fields need to be delivered for similar objects."

[0031] The unified object coding management module establishes a mapping relationship between UOIDs and object identifiers of each source system. This mapping relationship must include at least the model component identifier (such as IFC component GUID or native model ID), spatial feature identifier (GISFeatureID), point number (Tag or LoopNo), ledger equipment code (AssetNo), and business table primary key (RecordID). The mapping relationship adopts a "primary mapping + auxiliary feature" structure: the primary mapping stores the source system primary key, and the auxiliary features store variable fields such as object name, short code, drawing number, and equipment model. Auxiliary features participate in candidate sorting but do not constitute a unique matching criterion. The mapping relationship table is stored in the version control system as a relational data table, with fields including at least UOID, modal identifier m, and source system identifier id. src Primary key field k src Auxiliary feature set F aux Effective version v eff With update time t upd This embodiment defines the criteria for determining "valid objects": valid objects refer to object records that have not been marked for deletion and whose version identifier is equal to the current processing version; object records marked for deletion or with inconsistent versions are not included in the uniqueness and existence statistics, thereby ensuring the determinism of alignment verification.

[0032] The data lineage graph construction and update module constructs a lineage graph G using UOID as the primary key for nodes. The graph node set includes object nodes, record nodes, and file nodes. Object nodes correspond to equipment, components, locations, spatial elements, etc.; record nodes correspond to ledger records, work order records, etc.; and file nodes correspond to delivery documents and model fragments. The graph edge set includes at least three types of edges: mapping edges, dependency edges, and version evolution edges. Mapping edges express the correspondence of the same UOID in different modalities; dependency edges express engineering dependencies and attachment relationships, including at least the attachment of monitoring points to equipment, the connection of equipment to pipe sections, and the affiliation of equipment to process nodes; version evolution edges express the evolution relationship of the same object in different delivery versions, and the edge attributes at least include change time, change reason, and change summary. Graph updates are driven by change events.

[0033] In this embodiment, the system receives a change event queue Q, where each queue element contains at least the event time t. e Event type c e Target ID e Change Summary m e With source src e Event types include five categories: addition, deletion, attribute modification, relationship modification, and space modification. To ensure the feasibility of queue Q, this embodiment performs window aggregation and deduplication before events enter Q: a 5-minute sliding window aggregation is performed on the event stream using UOID as the aggregation key; duplicate events with the same UOID within the same window are merged into a single event record, and then... e The events are sorted to form a queue; for the aggregated event records, the earliest event time within the window is retained as t. e And concatenate the change summaries in the window in chronological order to form m e When updating the graph, if an event can resolve to an existing UOID, the corresponding node attribute snapshot is updated and written to the version evolution edge; if the event cannot resolve to a UOID, the consistency verification module provides an alignment result. After the alignment result is finalized, the mapping edge is written and the UOID is finalized. Preset edge type set E Maintained by the system configuration table, the fields of which must include at least the set of enabled edge types and the maximum traversal depth d. max With edge priority sequence.

[0034] This embodiment enables three types of edges: mapping edges, dependency edges, and version evolution edges. The edge priority is set as follows: version evolution edges first, mapping edges second, and dependency edges third. This ensures that version changes and cross-modal mappings are captured first during the influence domain limitation phase. Both the rule base R and the criticality configuration table are versioned and stored according to the delivery version number. During consistency verification, the rule base version identical to the currently processed version is called, ensuring that rule definitions are traceable with each version.

[0035] The consistency verification and automatic comparison module executes the core consistency verification and difference extraction algorithm. This algorithm uses the lineage graph as the basis for limiting the influence domain. Driven by change events, it first locates the set of affected objects, then completes cross-modal alignment verification, consistency verification, evidence recording of differences, generation of the minimum set of changed objects, and organization of differential delivery packages within the affected set. It then forms a recalculated acceptance branch through consistency scoring and delivery thresholds, and finally associates the acceptance results with the lineage snapshot to form a version backtracking chain. Figure 3 As shown, the structured outputs of each step in the closed loop are referenced as deterministic inputs in subsequent steps, thus forming a recalculated data link.

[0036] The algorithm first performs influence domain constraint. For each change event in queue Q, the system starts from the UOID corresponding to the event and moves along the preset edge type set E in the lineage graph G. By iterating through the set of objects, we obtain the affected object set U. aff The traversal path consists of a sequence of nodes and a sequence of edge types; when the next edge type to be expanded is not in E... When the path terminates in that direction of expansion, the traversal stops at the maximum depth d. max Together with edge type constraints, this constitutes: when the traversal depth reaches d max The expansion stops when the edge to be expanded does not belong to E. The expansion along that edge stops when the time is right. In this embodiment, d is taken as... max =3, ensuring the influence domain covers typical propagation links such as "equipment-location-business record" and "equipment-pipeline-valve", while suppressing the inclusion of irrelevant objects. Traversal adopts a queue-based breadth-first strategy and expands according to edge priority sequence, so that version evolution edges and mapping edges enter the influence domain first, while dependent edges are expanded after the version and mapping information are determined, reducing the probability of accidentally including irrelevant objects.

[0037] After obtaining U aff Then, cross-modal object alignment is performed. The alignment goal is to find a unique corresponding object for the same UOID in at least two data modalities or to determine missing or conflicting objects. This embodiment divides the alignment into three stages: candidate generation, matching scoring, and uniqueness determination. The uniqueness determination in the matching stage is used to select the object to be matched within the candidate set; the uniqueness verification in the alignment check is used to verify whether the one-to-one constraint holds at the level of the valid object set. In the candidate generation stage, a candidate set C(u,m) is constructed within each modality. Candidate generation prioritizes direct location based on the main mapping field in the mapping table; when the main mapping is missing, it is based on the auxiliary feature set F. aux Candidate objects are retrieved within the limited range of region segment and object category segment. Limiting the range reduces the probability of mismatch in global retrieval. In the matching scoring stage, a matching score M(u,a) is calculated for each candidate object a, and the one with the highest score is selected as the proposed matching object. The matching score is calculated using formula (1):

[0038] Where u is the UOID to be aligned; a is the candidate object; , , , where w is the weighting coefficient and satisfies id +w att +w geo =1, in this embodiment, w is taken as 1. id =0.60、w att =0.25、w geo =0.15. This is a primary identifier consistency indicator function. If the primary identifier of candidate object a matches the primary key corresponding to UOID in the mapping table, it is set to 1; otherwise, it is set to 0. The attribute similarity score ranges from 0 to 1 and is obtained by a weighted average of the field similarities within the forced attribute set. The field similarity score is determined according to the following rules: For numeric fields, a normalized difference score is used. ),in To avoid a denominator of 0, use 0.01; for enumerated fields, use 1 when they are equal and 0 when they are not; for string fields, use a combination of prefix consistency ratio and keyword hit rate to obtain the similarity, and limit the field similarity to [0,1]. The similarity is geometric or spatial, ranging from [0,1]. In this embodiment, the mapping relationship is determined in accordance with the spatial deviation.

[0039] in For spatial bias, Spatial deviation threshold, Calculated using formula (2). The tolerance table Tol(type,field) is used for candidate sorting and uniqueness determination during the alignment phase, and is used for consistency determination of the numerical fields of aligned objects during the consistency verification phase.

[0040] Set a matching threshold T during the uniqueness determination phase. m The difference between the score and the threshold Δ m When the maximum score M max Less than T m When a candidate is identified as missing, it is considered missing; when there are two or more candidate objects with a score difference less than Δ... m The time frame determines it as a many-to-one conflict. In this embodiment, T is taken as... m =0.70、Δ m =0.05. Missing and conflicting conclusions are written into the difference set and then incorporated into the subsequent minimum change set construction.

[0041] After alignment is complete, object alignment verification is performed. This verification includes uniqueness and existence checks. Uniqueness verification determines that the same UOID corresponds to only one valid object within the same data modality. Existence verification determines that a preset object type has a corresponding object within a preset data modality. This embodiment specifies that for equipment objects, there must be a valid correspondence between the 3D model modality and the ledger modality; for monitoring point objects, there must be a valid correspondence in the monitoring point configuration modality and an associated record in the control configuration or ledger linking record; and for spatial element objects, there must be a valid correspondence in the spatial data modality and a mapping edge association with the 3D model modality. If the existence check fails, a missing difference item is immediately created and written into the difference item set, and the UOID is added to the minimum change object set U. min The initial set makes missing issues explicitly present in the differential delivery and review branches.

[0042] After alignment verification is complete, the consistency verification phase begins. Consistency verification is performed based on the rule base R. The rule base R contains a set of mandatory attributes A configured according to object type. req (type) and the set of relational constraints L req (type). Attribute consistency verification is performed within the scope of the mandatory attribute set and uses values ​​in normalized units for comparison; relationship consistency verification is performed within the scope of the relationship constraint set, and at least includes the integrity determination of the association relationship between monitoring point UOID and equipment / facility UOID or process node UOID. For numerical field conflicts, this embodiment sets a tolerance table Tol(type,field), which is considered consistent within the tolerance range. To ensure the feasibility of the rule base configuration, this embodiment provides a minimum configuration example as shown in Tables 1 and 2. The fields in the tables come from the standard field templates of the object attribute view, and the field templates are fixed during the access phase.

[0043] Table 1. Examples of minimum configurations for mandatory attributes in the rule base (partial).

[0044] The units for the numerical fields in Table 1 have been standardized during the connection phase: pressure is in kPa, temperature is in °C, and flow rate is in m³ / s. 3 / h is the unit of measurement, and the length is in meters. For string or enumeration fields, the tolerance is complete consistency. Table 1 only shows the minimum set of fields for mandatory attributes. Fields can be expanded according to object type during project implementation. Attribute consistency verification should at least cover the mandatory attribute fields listed in Table 1, and relation consistency verification should at least cover the relation constraints listed in Table 2.

[0045] Table 2. Example of minimum configuration for rule base relationship constraints.

[0046] This embodiment provides a minimum implementation of a criticality configuration table: A list of critical objects and critical monitoring points is imported into the repository in the form of a configuration table, and a one-to-one mapping is established between each object and its UOID. The configuration table fields must at least include UOID and criticality level K. lvl Effective version v eff With update time t upd Criticality levels are used in the consistency scoring (w). k(i) This embodiment specifies that key objects or key monitoring points are taken as w k(i) =2, for ordinary objects, take w. k(i) =1.

[0047] Consistency verification further includes spatial consistency verification. Spatial consistency verification determines spatial deviations based on at least two types of data from BIM model data, GIS spatial data, and IoT monitoring point data. When the spatial deviation exceeds a preset threshold, a spatial difference item is generated and included in the difference item set. Spatial deviations are calculated using formula (2):

[0048] Among them, P bim =(x bim ,y bim ,z bim P represents the geometric center coordinates of the object in the 3D model coordinate system; gis =(x gis ,y gis ,z gis ) represents the geometric center coordinates of the object in the spatial data coordinate system; ∥ ∥2 represents the L2 norm distance. Both are transformed to the same engineering coordinate system before calculation: the system transforms the spatial coordinates based on the reference point alignment parameters, which include the translation T. x ,T y ,T z And the rotation angle θ. The rotation angle θ is the rotation angle about the vertical axis in the engineering plane, and the translation amount T. x ,T y ,T z The coordinates θ are obtained by aligning with the reference point and then fixed as the engineering coordinate transformation configuration. In this embodiment, T is taken as... x =128.400 m, T y =56.200 m, T z =0.000 m, θ=1.200° are used as example configurations; this set of conversion parameters is derived from the engineering benchmark delivery configuration, and different values ​​can be used for different projects. The converted P gis Substitute into formula (2) to calculate Δ s The spatial deviation threshold is set to T. s =0.50 m. When Δ s >T sSpatial difference terms are formed at this time. The monitoring point has installation coordinates P. sp In this case, additional calculations are performed in this embodiment. and And take the maximum value of the three as Δ s .

[0049] The set of differences uses structured records. Each difference item must contain at least the difference type, the modality involved, the difference fields, the difference object UOID, and the lineage identifier p. id Source data version identifier. Difference types must include at least missing, attribute conflict, relation difference, excessive spatial deviation, many-to-one conflict, and unit anomaly. Source data version identifiers use the format "VYYYYMMDDHHMMSS". Lineage path identifier p id Determined by the path node sequence and edge type sequence, this embodiment uses CRC32 to calculate p. id : Concatenate the primary key of each node in the path with the edge type in order to form a string s path , for s path Calculate the CRC32 to obtain a 32-bit unsigned integer, then represent it as an 8-bit hexadecimal string as p. id The system will p id Write the path fields to the structured record of the difference item, the verification log, and the lineage snapshot so that the three can be verified and matched during the acceptance phase.

[0050] After the set of differences is formed, the system generates a minimum set of changed objects U based on the set of differences and their lineage paths. min U min Following the principle of minimization of "difference-driven + dependency closure": first, add the UOID of the difference object to the set, and then perform minimal closure expansion along the lineage path for related objects that satisfy the preset dependency constraints. Dependency constraints are configured in the form of a whitelist, and closure expansion only follows the dependency edge E. dep The process is performed, and the types of extensible objects are limited: when equipment differences are triggered, the directly connected monitoring points, directly connected pipe sections, and adjacent valves are expanded; when monitoring point differences are triggered, the connected equipment and corresponding control configuration record nodes are expanded; when spatial differences are triggered, the corresponding spatial element nodes and model component nodes are expanded. The closure expansion depth is limited to 1 to 2 hops, and the same version identifier is maintained throughout the expansion process to ensure U... min It is closed at the version level and has stable boundaries.

[0051] The differential delivery package generation module generates packages based on U min A differential delivery package is formed. The differential delivery package consists of three parts: data ontology differential, lineage snapshot, and verification log. To ensure that the data ontology differential generation rules are explicit and executable, this embodiment specifies: Using U... minThe UOID in the table serves as the index. Corresponding object records are extracted for each modality and categorized into three types: "Add," "Delete," and "Modify," forming a list. "Add" refers to a target version that exists but the previous baseline version does not; "Delete" refers to a target version that does not exist but the previous baseline version does; and "Modify" refers to both versions that exist but have differences in forced attributes, relationships, or spatial verification results. The 3D model portion is exported as a component set to form model incremental fragments or IFC fragments; the spatial data portion is exported as a GIS feature set to form feature-level incremental data; the monitoring point data portion is exported as a point configuration record set to form point incremental data; and the business data portion is exported as a record primary key set to form record-level incremental data. The lineage snapshot is G in U... min A snapshot of the induced subgraph includes at least a snapshot of node attributes, edge types, and edge attributes (including version evolution information). The verification log is the evidence output of the set of discrepancies, containing the source data version identifier and lineage path identifier p for each discrepancy. id The verification log and lineage snapshot are matched using an equality matching method: the source version identifier in the verification log is equal to the snapshot node version field, and the p in the verification log is equal to the source version identifier in the snapshot node version field. id Equal to the snapshot path field. The differential delivery package container adopts a fixed directory structure, and the directory names remain consistent within the same project. For example, the root directory of the differential delivery package contains three directories in sequence: DataDiff, LineageSnapshot, and VerifyLog, which store the data ontology differential, lineage snapshot, and verification log, respectively.

[0052] The data traceability acceptance and version management module performs acceptance control on differential delivery packages and forms a backtracking chain. Acceptance control uses a consistency score S and a delivery threshold T. acc The consistency score is calculated based on the type of discrepancy, the criticality of the object, and the magnitude of the deviation. In this embodiment, formula (3) is used to calculate the consistency score:

[0053] Where S is the final consistency score; S0 is the initial score, which is set to 100 in this embodiment; n is the number of discrepancies; w t(i) The weight for the i-th difference item type is 10 for missing items, 8 for attribute conflicts, 8 for relational differences, 6 for spatial deviation exceeding limits, 6 for many-to-one conflicts, and 4 for unit anomalies; w k(i) Assign a weight to the object's criticality: 2 for critical objects or key monitoring points, and 1 for ordinary objects; g i This is the amplitude coefficient, with a value range of [1,2]. This embodiment provides a defined g value for different difference types. i Value selection rule: For spatial deviation exceeding the limit difference term, let For attribute conflict differences, the value is taken as the relative error and capped at 2; for missing and relation differences, g i =2; for many-to-one conflicting difference terms, gi =1.5; for unit outlier items, g i =1. Delivery threshold T acc Take 85. When S≥T acc When S enters the delivery process and generates an acceptance record; <T acc Output a review instruction and block automatic delivery. The review instruction must include at least a list of UOIDs to be reviewed, a summary of differences, and a lineage path identifier. id This is linked to the source version identifier, ensuring that the review process is locatable and traceable.

[0054] Acceptance records are linked and stored with lineage snapshots to form a version backtracking chain. The version backtracking chain must include at least the delivery version identifier, delivery time, participant identifier, and U. min The fingerprints include the object list fingerprint, the set of differences fingerprint, the consistency score S, the threshold comparison result, and the location of the verification log index. The backtracking chain fingerprint calculation uses a U... min The object list and the set of differences are sorted by UOID and field, concatenated into a string, and hashed to ensure that the same delivery content generates a unique fingerprint. During operation, any issue can be resolved by using the object's UOID to look up its latest delivery version, the source of the difference, and its lineage, reducing the risk of data untraceability due to version drift.

[0055] like Figure 4 As shown, in a delivery of a pump object change, the lineage snapshot subgraph includes pump object nodes, its model component nodes, spatial feature nodes, attached monitoring point nodes, and corresponding ledger record nodes, connected through mapping edges, dependency edges, and version evolution edges. The p in the verification log... id The path field is consistent with the value in the snapshot, and the source version identifier is consistent with the value in the version field in the snapshot, thus forming a verifiable closed loop during the acceptance phase.

[0056] This embodiment provides a comprehensive calculation example of a single change to pump P-101. Assume that the model of pump P-101 is replaced during the construction phase, resulting in changes to its rated flow rate and head. Simultaneously, the connection relationship of a monitoring point is adjusted. The system generates a change event record during the connection phase: event time t. e =2026-01-15T10:05:12.215, Event type c e =Attribute modification, target identifier i de =Ledger equipment code "P101-AST-0007", change summary m e =“The model number has been changed from X1 to X2, Q rated With H rated "Update", source src e=Ledger system. In the mapping relationship table, the main mapping field of this device is located to UOID "PMP01-TA-000000012345-7F". The system uses this as the starting point to traverse the lineage graph G and enable E. Three types of edges and set d max =3. Traverse to obtain the affected object set U. aff Includes: the pump object UOID, its BIM component nodes, its GIS spatial element nodes, the two monitoring point UOIDs attached to it, the ledger record nodes related to the pump, and the UOIDs of the two pipe segments connected to the pump and the adjacent valve UOIDs. Due to the traversal depth limit of 3, the set is not extended to more distant indirect objects to maintain the correspondence between the processing scope and the change impact domain.

[0057] The system for U aff The pump object in the model performs cross-modal alignment. The master mapping in the 3D model modality has a corresponding component GUID, I. id =1; The master mapping exists in the ledger modality, I id =1; the principal mapping exists in the spatial mode, I id =1. If a modality's main mapping is missing, the system generates a candidate set based on auxiliary features within the region segment and object category segment limits, calculates M(u,a), and then proceeds according to T. m With Δ m Uniqueness check completed. In this example, the alignment check shows that the pump object exists as a unique and valid object in both the 3D model modality and the ledger modality. The uniqueness check passed, and the existence check passed.

[0058] The system then performs consistency verification according to rule base R. The pump object's mandatory attribute set contains Q. rated H rated ,P rated D in D out Q in the ledger rated Change from 120m³ / h to 130m 3 / h, the component attribute in the 3D model is still 120m³ / h, forming an attribute conflict difference term. Due to the tolerance on Q rated Set to 1% of the rated value, |120 130∣ / 130 exceeds the tolerance, a conflict is established. The system simultaneously checks relationship constraints: monitoring point "FT-101" requires a dependent edge with the pump object and the relationship type is "measurement object," but the control configuration record shows that this point is attached to valve V-32. The dependency edge attributes in the lineage diagram are inconsistent with the rule base constraints, forming a relationship discrepancy item, which is included in the score with a weight of 8. Spatial consistency verification calculates the geometric center P of the pump component. bim With spatial element center P gis Distance after conversion Δ s=0.62m, exceeding the threshold T s =0.50m, forming a spatial difference item. All of the above differences are recorded in a structured format, and a kinship path identifier p is generated for each difference item. id At the same time, the source data version identifier "V20260115100512" is recorded.

[0059] After the set of differences is formed, the system constructs a minimum set of change objects U. min The initial set contains the differential object pump P-101, monitoring point FT-101, pump space feature nodes, and pump BIM component nodes. The system then proceeds along the dependency edge E. dep Expand by whitelist: For pump differences, expand directly connected monitoring points FT-101 and PT-101, and directly connected pipe sections and adjacent valve V-32; for monitoring point differences, expand connected equipment and control configuration record nodes; for spatial differences, expand corresponding spatial element nodes and model component nodes. The expansion depth is limited to 2 hops. After expansion, U... min A stable boundary is formed.

[0060] The system generates differential delivery packages accordingly. The data ontology differentials are organized into three lists: additions, deletions, and modifications. Pump ledger records are modified, pump component IFC fragments are modified, spatial elements are modified, FT-101 attachment records are modified, and V-32 related records are modified. Unaffected objects are not included in the differentials. The lineage snapshot is U. min The induced subgraph snapshot includes snapshots of node attributes and edge attributes, with the version field for both being "V20260115100512". The verification log includes the source version identifier and p for each difference item. id And perform an equivalence match with the bloodline snapshot.

[0061] The system calculates a consistency score S. The discrepancies in this example include: 1 attribute conflict (weight 8), 1 relationship difference (weight 8), and 1 spatial deviation exceeding the limit (weight 6). Pumps P-101 and FT-101 are both critical objects or critical monitoring points; therefore, w is taken as... k =2. The attribute conflict amplitude coefficient is set to a value based on the relative error and capped at 2; in this example, it is taken as approximately 1.5. Relationship differences are considered high-risk items due to inconsistent attachments, and are assigned an amplitude coefficient of 2. The spatial deviation amplitude coefficient is... Substituting into formula (3), we obtain a consistency score less than the threshold T. acc =85, the system outputs a review instruction and blocks delivery. The review instruction carries a list of UOIDs to be reviewed, a summary of differences, and p id The source version identifier provides a basis for rectification and recalculation. After rectification is completed, a new version event is generated and enters the same closed loop until the score meets the threshold, at which point delivery is completed and the backtracking chain is solidified.

[0062] To verify the effectiveness of the technical solution in this embodiment, three typical change scenarios were selected for testing: Scenario A was the delay in synchronization between equipment parameter changes and ledgers; Scenario B was the change in the attachment relationship of monitoring points; and Scenario C was the deviation between the model and spatial data caused by the adjustment of spatial element positions. The test data scale was: 2,480 equipment objects, 5,320 monitoring point objects, 3,110 spatial element objects, and 12,600 business record nodes. The comparison methods selected were manual verification and full script comparison. The object alignment accuracy, difference detection precision, difference detection recall, single delivery processing time, and delivery package size were statistically analyzed. The number of misattached and missed events during the operation takeover phase was also statistically analyzed. The results are shown in Table 3.

[0063] Table 3 Comparison of Delivery Node Verification and Delivery Results (This Example vs. Reference Method)

[0064] Further statistics on the proportion of processing objects and the main differences in the three types of scenarios are presented in Table 4.

[0065] Table 4. Statistical Breakdown of Scenarios (In this Example)

[0066] As shown in Tables 3 and 4, this embodiment outperforms the reference method in terms of object alignment, difference identification, and delivery efficiency. After limiting the lineage influence domain, this embodiment converges the processing object set to 3% to 7% of the entire database, and performs alignment scoring, uniqueness and existence checks, and consistency verification limited by the rule base within this set, reducing the probability of false matching and missed detection. Forced attribute and relationship constraints focus on key fields and key relationships, and tolerance tables and unit normalization suppress false differences caused by decimal place differences and differences in measurement caliber. The whitelist closure expansion strategy of the minimum change set reduces the size of the delivery package and improves acceptance efficiency. Through the equivalence matching of verification logs and lineage snapshots, the source version and propagation path of differences can be located during the acceptance phase, realizing recalculated verification.

[0067] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0068] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A smart oil depot's full lifecycle data management system, comprising a unified object coding management module, a data lineage map construction and update module, a consistency verification and automatic comparison module, a differential delivery package generation module, a data traceability acceptance and version management module, and a multi-source data access and fusion module, characterized in that, The system executes a consistency verification and difference extraction algorithm for multimodal engineering data. It constructs a data lineage graph G based on globally unique object codes (UOIDs) and receives a change event queue Q. When a change event is received, it traverses the lineage graph G along a preset set of edge types, starting from the UOID corresponding to the change event, to obtain a set of affected objects. The traversal terminates when any of the following stopping conditions are met: the depth reaches a preset value; or the edge type to be expanded does not belong to the preset set of edge types. For each UOID in the affected object set, it retrieves corresponding object data from at least two data modalities and completes object alignment verification. Based on a rule base, it performs consistency verification on the aligned object data and forms a set of difference items. The consistency verification includes at least attribute consistency verification and relation consistency verification. It forms a minimum set of changed objects based on the set of difference items and its lineage path. It forms a differential delivery package based on the minimum set of changed objects. The differential delivery package includes data ontology differences, lineage snapshots, and verification logs. It forms a consistency score based on the set of difference items and compares it with a preset delivery threshold to determine whether the differential delivery package meets the delivery conditions. The delivery acceptance result is stored in association with the lineage snapshot and forms a version backtracking chain.

2. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The preset edge type set includes at least two of the following: mapping edges, dependency edges, and version evolution edges.

3. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The object alignment verification includes uniqueness verification and existence verification; wherein, the uniqueness verification determines that the same UOID corresponds to only one valid object in the same data modality, and the existence verification determines that a preset object type has a corresponding object in a preset data modality.

4. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The rule base includes a set of mandatory attributes and a set of relationship constraints configured according to object type; wherein, the attribute consistency verification is performed within the scope of the mandatory attribute set, and the relationship consistency verification includes the integrity determination of the association relationship between the monitoring point UOID and the equipment facility UOID or process flow node UOID.

5. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The set of differences is a structured record, which includes at least the difference type, the modality involved, the difference field, the difference object UOID, and the lineage path identifier; the minimum set of changed objects consists of the difference object UOID and the associated object UOID that satisfies the preset dependency constraint along the lineage path.

6. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The consistency score is assigned a weight level based on the type of difference, and a higher weight level is assigned to the difference items corresponding to safety-critical objects or key monitoring points.

7. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The consistency verification further includes spatial consistency verification; the spatial consistency verification determines spatial deviation based on at least two types of data among BIM model data, GIS spatial data and IoT monitoring point data, and when the spatial deviation exceeds a preset threshold, a spatial difference item is formed and included in the difference item set.

8. The intelligent oil depot's full lifecycle data management system according to claim 1, characterized in that, The verification log contains the source data version identifier and lineage path identifier corresponding to each difference item in the difference item set, and the source data version identifier and lineage path identifier match the corresponding record in the lineage snapshot.

9. A method for full lifecycle data management of a smart oil depot, characterized in that, Includes the following steps: Step 1: Generate a globally unique object code (UOID) and establish a mapping relationship between the UOID and the object identifiers of each source system; Step 2: Construct and update the data lineage graph G based on UOID and set the preset edge type set; Step 3: Receive change events in the change event queue Q, and traverse the lineage graph G along the preset edge type set starting from the UOID corresponding to the change event to obtain the set of affected objects. The traversal will terminate when the following stopping conditions are met: when the traversal depth reaches the preset value or the edge type of the edge to be expanded of the current node does not belong to the preset edge type set, the expansion along the edge will stop. Step 4: Obtain the corresponding object data of the affected object set from at least two data modalities and complete the object alignment verification; Step 5: Perform consistency verification based on the rule base and form a set of discrepancies; Step 6: Form a minimum set of changed objects based on the set of differences and their lineage paths; Step 7: Form a differential delivery package based on the minimum set of changed objects. The differential delivery package includes data ontology differential, lineage snapshot and verification log. Step 8: Generate a consistency score based on the set of discrepancies and compare it with a preset delivery threshold to determine delivery conditions. Generate an acceptance record and store it in association with the lineage snapshot to form a version backtracking chain.

10. A method for full lifecycle data management of a smart oil depot according to claim 9, characterized in that, Each difference item in the difference item set records at least the difference type, the modality involved, the difference field, and the lineage path identifier, and outputs a review instruction when the consistency score does not meet the preset delivery threshold.

Images