A cross-domain digital twin synchronization method and system integrating a digital asset model library
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- MAGIC BIRD INFORMATION TECHNOLOGY (SHANGHAI) CO LTD
- Filing Date
- 2026-02-25
- Publication Date
- 2026-06-02
Smart Images

Figure CN122132484A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer technology, specifically relating to a cross-domain digital twin synchronization method and system for integrating a digital asset model library. Background Technology
[0002] Digital twin technology is a key enabling technology connecting the physical world and the digital space, playing an increasingly important role in the full lifecycle management of complex equipment. In the process of collaboration across different business areas such as design, production, and operation and maintenance, each link relies on its digital model built based on different standards. These heterogeneous models are semantically incompatible, forming "model silos" that hinder efficient information sharing and consistent maintenance.
[0003] To achieve cross-domain collaboration, existing solutions generally employ centralized digital asset model libraries for model synchronization and distribution. However, this approach has significant shortcomings: First, the synchronization mechanism is usually a full update, requiring the transmission of the entire file even if only minor local changes occur, leading to wasted network bandwidth and synchronization delays. Second, change detection is mostly based on file hashes, failing to identify changes with the same semantics but different expressions, easily causing invalid synchronization. Third, complex dependencies exist within the models, and existing systems lack the ability to track and analyze the impact of these dependencies, making it difficult to accurately determine the scope requiring synchronization after a partial update, potentially leading to logical inconsistencies. Fourth, due to the lack of effective semantic consistency guarantees, local models in each domain are prone to state drift with the central library, affecting the reliability of collaboration.
[0004] While existing research has attempted to introduce version management or semantic enhancement techniques, achieving minimal, verifiable, and dependency-aware incremental synchronization while ensuring semantic consistency remains a challenging technical problem that has yet to be effectively solved. Therefore, the field needs an efficient synchronization method and system capable of accurately identifying semantic changes, intelligently constraining the synchronization range, and ensuring cross-domain state consistency. Summary of the Invention
[0005] This invention provides a cross-domain digital twin synchronization method and system integrating a digital asset model library, aiming to solve core problems in existing technologies such as bandwidth waste, state inconsistency, and runtime logic errors caused by a lack of semantic awareness, coarse synchronization granularity, and missing dependency propagation. The method constructs a unified semantic meta-model framework to perform structured analysis and semantic standardization of multi-source heterogeneous digital twin models. Based on this, a semantic difference detection mechanism based on graph neural networks is introduced to accurately identify model element-level changes. Furthermore, by combining static dependency graphs and dynamic execution contexts, a minimum necessary synchronization subgraph is derived, and a verifiable incremental packet generation and consistency verification protocol ensures strict semantic alignment between the local twins of each business domain and the central model library.
[0006] According to one aspect of the present invention, a cross-domain digital twin synchronization method for integrating a digital asset model library is provided, comprising: Obtain the current version metadata description of the target digital twin model from the centralized digital asset model library; Based on the unified semantic meta-model framework, the target model from the model library and the corresponding copy of the business domain local cache are respectively structured and parsed to generate a central and local standardized directed graph. Using a semantic difference detection model trained on a graph attention network, semantic embedding vectors of aligned nodes in the central and local normalized directed graphs are extracted respectively. Nodes with semantic changes are identified by calculating vector similarity, forming an initial set of changed nodes. Combining the static dependency graph pre-built for the target model and the dynamic execution context collected from the local runtime environment of the business domain, the minimum necessary synchronization subgraph that must be synchronized is pruned from the central standardized directed graph. The pruning includes: starting from the initial set of change nodes, performing a traversal on the static dependency graph constrained by path depth and cumulative dependency weight, and using a Boolean mask generated based on the dynamic execution context for node filtering. Incremental synchronization data packets are generated based on the minimum necessary synchronization subgraph, and these data packets are sent to the local node in the business domain for security verification, difference injection, and semantic fingerprint consistency verification to complete the synchronization.
[0007] Furthermore, structured parsing includes: Based on the modeling standard type in the metadata description, call the corresponding format adapter; Using the parsing rule engine within the format adapter, the original model elements are mapped to semantic nodes under the unified semantic meta-model framework and their attributes are populated. At the same time, the relationships between elements are converted into directed semantic edges, thereby constructing the standardized directed graph.
[0008] Furthermore, the training of the semantic difference detection model includes: Construct a training dataset consisting of a standardized directed graph of a large number of digital twin models, and label the nodes in the graph with semantic category labels; Construct the initial feature vector of a node based on its attribute set; Using the structure of the standardized directed graph and the initial feature vectors of the nodes as input, and with the node classification task as the objective, a graph attention network containing at least three graph attention layers is trained under supervision, so that the trained model has the ability to generate node semantic embedding vectors.
[0009] Furthermore, combining static dependency graphs with dynamic execution contexts to prune the minimum necessary synchronization subgraph specifically includes: Load the static dependency graph, where the edge weights in the graph are assigned fixed integer values based on the dependency type; The dynamic execution context Boolean mask is generated based on the current execution task stage, the activated simulation modules, and the real-time data binding relationship. For each node in the initial set of changed nodes, a controlled breadth-first traversal is performed on the static dependency graph: the traversal depth does not exceed a preset maximum depth, and when expanding neighboring nodes, if the neighboring node is marked as irrelevant in the Boolean mask, it is skipped. At the same time, the edge weights on the path are accumulated, and only nodes covered by paths with accumulated weights greater than a preset threshold are retained. Extract all the retained nodes and their associated edges in the central normalized directed graph to form the minimum necessary synchronization subgraph.
[0010] Furthermore, generating incremental synchronization data packets includes: Based on the internal path identifiers of the nodes in the minimum necessary synchronization subgraph, extract the corresponding original data fragments from the original model file; For the original data fragments of different data types, a differentiated differential coding strategy is used to calculate the amount of change relative to the corresponding fragment in the local copy. The data types include at least script code, geometric features, and ordinary attributes. The differential encoding result is serialized into a data payload, and the data payload is digitally signed using a private key to assemble the final incremental synchronization data packet.
[0011] Furthermore, differentiating differential coding strategies for raw data fragments of different data types include: For script code, after parsing it into the old and new versions of the abstract syntax tree, the tree edit distance is calculated and the edit operation sequence is encoded; For the mesh model in the geometric features, calculate the vertex position offset vector and the face index difference set; For parametric surfaces in geometric features, extract the changes in control point coordinates and surface metadata adjustment flags; For ordinary attributes, perform byte-level difference comparisons and record the changed fields and new values.
[0012] Furthermore, semantic fingerprint consistency verification includes: After an application incremental update, the business domain local node recalculates the semantic fingerprint for the nodes covered by the minimum necessary synchronization subgraph. The semantic fingerprint is obtained by concatenating the node's normalized attribute byte stream and geometric feature vector and performing hash calculation. The recalculated semantic fingerprint is compared with the reference fingerprint extracted from the incremental synchronization data packet; If all data is consistent, the synchronization is considered successful and the local metadata is updated; if there are inconsistencies, a rollback operation is triggered and an alarm is issued.
[0013] Further security verification includes: After receiving the incremental synchronization data packet, the local node in the business domain separates the data payload and digital signature. The hash value of the data payload is calculated using the same hash algorithm as the central model library; The digital signature is verified using a pre-stored central model library public key, and the verification result is compared with the hash value to verify the integrity and authenticity of the data packet.
[0014] Furthermore, the current version metadata description should at least include a globally unique identifier for the model, a semantic version number, a modeling standard type, a semantic type for the root node, and a list of top-level components.
[0015] According to another aspect of the present invention, a cross-domain digital twin synchronization system integrating a digital asset model library is provided, comprising: A central processing subsystem deployed on the centralized digital asset model library side and a local processing subsystem deployed on local nodes in the business domain; The central processing subsystem includes: The model metadata acquisition unit is used to acquire the current version metadata description of the target digital twin model; The structured parsing unit is used to parse the target model into a centrally standardized directed graph based on the unified semantic meta-model framework. The semantic difference detection unit is used to identify semantic change nodes by comparing the central and local normalized directed graphs using a model trained on a graph attention network. The minimum synchronization subgraph pruning unit is used to combine the static dependency graph and the dynamic execution context to prune the minimum necessary synchronization subgraph from the centrally standardized directed graph. An incremental packet generation unit is used to generate and sign incremental synchronization data packets based on the minimum necessary synchronization subgraph. The local processing subsystem includes: The local structured parsing unit is used to parse the local cache model copy into a local normalized directed graph; The consistency verification and update unit is used to perform security verification, difference injection, and semantic fingerprint consistency verification on the received incremental synchronization data packets.
[0016] In summary, this application includes at least one of the following beneficial technical effects: 1. This application introduces fine-grained semantic change detection and a dependency-aware synchronization range pruning mechanism to transmit only the smallest subset of model data affected by changes and required by the business, thus avoiding redundant transmission caused by full synchronization and significantly reducing network bandwidth usage and synchronization latency.
[0017] 2. This application is based on a unified semantic meta-model framework and graph attention network, which can identify deep semantic changes in the model and avoid missynchronization caused by different expression forms. At the same time, through the semantic fingerprint verification mechanism, it ensures that the logical state of cross-domain models is strictly consistent after the update.
[0018] 3. This application combines static dependency graphs with dynamic execution contexts, enabling the system to automatically deduce the propagation scope of changes and maintain the structural and logical integrity of the model during synchronization. This effectively prevents runtime errors or state drift caused by local updates and improves the reliability of cross-domain collaboration. Attached Figure Description
[0019] Figure 1 This is a schematic diagram of the architecture of a cross-domain digital twin synchronization method that integrates a digital asset model library; Figure 2 This is a schematic diagram of semantic difference detection and minimum necessary synchronous subgraph pruning in a graph attention network. Figure 3 It is a flowchart of the incremental synchronous data flow and consistency verification logic from the centralized model library to the local node of the business domain. Detailed Implementation
[0020] This invention provides a cross-domain digital twin synchronization method and system integrating a digital asset model library, aiming to solve core problems in existing technologies such as bandwidth waste, state inconsistency, and runtime logic errors caused by a lack of semantic awareness, coarse synchronization granularity, and missing dependency propagation. The method constructs a unified semantic meta-model framework to perform structured analysis and semantic standardization of multi-source heterogeneous digital twin models. Based on this, a semantic difference detection mechanism based on graph neural networks is introduced to accurately identify model element-level changes. Furthermore, by combining static dependency graphs and dynamic execution contexts, a minimum necessary synchronization subgraph is derived, and a verifiable incremental packet generation and consistency verification protocol ensures strict semantic alignment between the local twins of each business domain and the central model library.
[0021] Referring to the accompanying drawings, the cross-domain digital twin synchronization method for integrating a digital asset model library according to the present invention includes the following steps: The first step, S1, involves obtaining a standardized current version metadata description of the target digital twin model from a centralized digital asset model library, providing a unified benchmark for subsequent model parsing and comparison. This step is specifically implemented through the following sub-processes: S101. The centralized digital asset model library serves as a unified storage hub, employing an asset registry to manage the entire lifecycle of digital twin model assets shared across all business domains. Each model asset is automatically assigned a globally unique identifier upon entry into the library. This identifier is generated by concatenating a predefined namespace prefix with a locally unique serial number generated sequentially within the library, ensuring its global uniqueness when referenced across domains.
[0022] S102. The model library maintains a structured metadata description for each registered asset. This description includes the following core fields: Model identifier: that is, the globally unique identifier mentioned in step S101.
[0023] Version number: Defined using a semantic versioning format, which consists of three parts: major version number, minor version number, and revision number. The major version number is used to identify major changes to the model structure that are not backward compatible, the minor version number is used to identify backward compatible functional changes such as adding new features or components, and the revision number is used to identify backward compatible issue updates such as bug fixes.
[0024] Modeling standard type: This specifies the modeling standard type followed by the original model file, including one or more of STEP, IFC, SysML, and JSON-LD.
[0025] Root node semantic type: used to describe the top-level entity category that the model represents at the business level, such as "complete equipment", "subsystem", "process unit".
[0026] Top-level component list: used to enumerate all first-level child components that the root node of the model directly contains in terms of structure; each child component in the list is recorded by an internal path identifier that is unique within the scope of its own model.
[0027] S103. The aforementioned structured metadata description is persistently stored in the metadata index service of the model library in a machine-readable structured document format; the service provides a query interface based on model identifiers, which can quickly retrieve and return the corresponding complete metadata document based on the received identifier.
[0028] When a local node in a business domain needs to initiate a synchronization process for a specific target model, it first sends a query request to the metadata index service, carrying the identifier of the target model in the request. After receiving the request, the model library locates and returns the complete current version metadata description of the target model through the query interface.
[0029] The returned metadata will serve as the authoritative benchmark for all subsequent parsing, difference detection, and synchronization operations.
[0030] In summary, step S1 completes the initial data preparation for the synchronization process. Through a standardized metadata acquisition mechanism, it ensures that the local nodes of each distributed business domain can carry out subsequent work based on a unified description with a clear version from the central database, thereby avoiding semantic deviations caused by inconsistencies in basic information from the source. The output of this step—the structured current version metadata—is the key input connecting the subsequent model parsing (step S2) and local copy processing (step S3).
[0031] For step S2, based on the preset unified semantic meta-model framework, the target digital twin model is structurally parsed and converted into a standardized directed graph representation.
[0032] Step S2, based on the metadata description obtained in step S1, which includes information such as the modeling standard type, aims to parse and transform the original, diverse target digital twin models into a unified, semantically rich intermediate representation—a standardized directed graph—laying the foundation for subsequent fine-grained difference detection. This process is achieved through the following sub-steps: Step S201: The unified semantic meta-model framework predefines the basic element specifications for constructing a directed graph. This framework specifies four core semantic node types and limits the minimum set of attributes that each type of node must contain to express its core semantics: Physical entity nodes: used to represent specific physical objects, such as equipment components, sensors, or material units. Their attribute set must include at least: a unique identifier, coordinate system origin, mass attributes, material ID, and surface treatment parameters.
[0033] Logical function nodes: These represent abstract behaviors or logic, such as control logic, fault modes, or process flows. Their attribute set must include at least: function name, input / output port list, state transition table, and execution priority.
[0034] Data interface node: Used to represent the data exchange point with external systems. Its attribute set must include at least: protocol type, sampling frequency, data format template, and bound physical address.
[0035] Rule constraint nodes: These are used to characterize design specifications, safety thresholds, or compliance requirements. Their attribute set must include at least: the rule expression, the scope identifier, and the severity level of the violation.
[0036] Meanwhile, the framework stipulates that nodes are connected by directed semantic edges. Each edge must record the unique identifiers of its source and target nodes, the dependency type, and the direction, in order to characterize the specific dependency relationships between nodes, such as functional dependency, spatial containment, or logical association.
[0037] Step S202: The structured parsing unit that performs the parsing task contains an array of format adapter modules. This array deploys multiple independent format adapters, each specifically configured and implemented for a modeling standard type defined in the metadata of step S1, including the STEP format adapter, IFC format adapter, SysML format adapter, and JSON-LD format adapter.
[0038] Step S203: When the parsing process starts, the scheduler in the structured parsing unit searches for and activates the format adapter corresponding to the target model format from the adapter array based on the "modeling standard type" metadata obtained in step S1.
[0039] Step S204: The activated format adapter invokes its dedicated parsing rule engine to perform parsing transformation. Based on the parsing rules predefined for this specific modeling standard, the engine traverses and reads the internal structure of the original model file, sequentially performing the following two core transformation operations: Element-to-Node Mapping and Attribute Population: For each original model element encountered, the parsing rule engine determines the semantic category of the element according to predefined rules and maps it to one of the four core semantic node categories defined in step S201. For example, an IfcBuildingElement element in an IFC file is typically mapped to a "physical entity node". Subsequently, the engine extracts the corresponding information from the original element and populates it according to the attribute set required by the target node type. Simultaneously, a unique internal path identifier is generated for the node within the model scope; this identifier is typically generated based on the element's hierarchical position in the original model structure.
[0040] Edge extraction and transformation: During the traversal, the parsing rule engine synchronously identifies explicitly defined reference relationships between elements of the original model, such as parameter binding relationships, coordinate system linking relationships, event triggering relationships, and script call chain relationships. The engine converts each identified relationship into a directed semantic edge, which records the internal path identifiers of the source node and the target node, and marks its dependency type according to the nature of the reference relationship.
[0041] Step S205: After all elements and relationships in the original model have been traversed and transformed, the structured parsing unit integrates all generated semantic nodes and semantic edges to construct and output a complete standardized directed graph. The set of nodes and edges in this directed graph together constitute the semantic abstract representation of the target digital twin model within the unified semantic meta-model framework. In this graph, each semantic node encapsulates its entity identifier, a complete set of attributes, and a hash value calculated using a standard hash function based on its geometric / topological feature description data; the semantic fingerprint field is reserved at this stage, and its specific value will be calculated and filled in subsequent steps.
[0042] In summary, step S2 completes the transformation from the original model to a standardized semantic graph. It solves the problem of structural and semantic unification of multi-source heterogeneous models through a clearly defined meta-model framework and a parsing adaptation mechanism for different standards.
[0043] Step S3 involves performing the same structured parsing process as the central side on the corresponding twin model copy cached locally in the business domain, generating a locally standardized directed graph. In step S2, the system has already parsed the target model in the central model library into a standard directed graph. To perform effective semantic comparison, step S3 requires generating a graph representation with identical semantic specifications and structure for the cached model copy on the local side of the business domain, ensuring the consistency of subsequent comparison benchmarks. This step is implemented through the following sub-processes: Step S301: The business domain local node maintains a local model cache in its operating environment. This cache is used to persistently store copies of digital twin models of various versions obtained by the node through historical synchronization operations. The cache is implemented based on a local file system or an embedded database, and the copies are organized and managed according to the model identifier and version number.
[0044] Meanwhile, when storing each copy, the cache records the modeling standard type information corresponding to that copy. This information comes from the metadata carried by the copy when it was initially synchronized from the central database, or is automatically obtained by parsing the copy file header, file extension, etc.
[0045] Step S302: When a local node receives a new synchronization trigger signal for a specific target model, it queries and loads the latest version copy matching that target model from the local model cache based on the target model's identifier. The synchronization trigger signal can come from a scheduled task, a user-manual command, or a monitored central library version update event.
[0046] The steps S301 and S302 described above together complete the preparation and retrieval of local data. By associating the cache with the storage modeling standard type, it is ensured that the format information is deterministic when loading the copy, providing the necessary input for accurate subsequent calls to the parsing adapter.
[0047] Step S303: Regardless of whether the loaded local copy is the complete original model file or a model reconstructed locally after historical incremental synchronization data packets are injected, the local node calls its local structured parsing unit. This local structured parsing unit is completely consistent with the structured parsing unit used by the central model library to perform step S2 in terms of functional implementation and component configuration, that is, it adopts the same unified semantic meta-model framework and the same array of format adapter modules.
[0048] S304. The local node uses this structured parsing unit to first activate the corresponding format adapter based on the modeling standard type obtained from the cache or parsed from the copy itself.
[0049] Subsequently, following the exact same parsing rules and execution flow as step S2, structured parsing is performed on the loaded local model copy. This process also involves running the parsing rule engine to map elements to nodes and transform relational semantic edges, ultimately generating a local standardized directed graph.
[0050] In summary, step S3, on the local business domain side, reuses a parsing system completely consistent with that of the central model library side, standardizes and transforms the local cached copy, and directly produces a local standardized directed graph that is strictly comparable to the semantic graph of the central model. Step S3 itself does not introduce new processing logic, but rather lays a reliable foundation for the accurate, semantic-level graph node difference detection in the subsequent step S4 by ensuring the absolute consistency of the processing tools and rules at both ends. This ensures that the comparison results can truly reflect changes in the model content itself, rather than deviations caused by differences in parsing tools or rules.
[0051] Step S4, based on the central and local standardized directed graphs generated in steps S2 and S3 respectively, aims to go beyond byte-level or syntax-level comparisons and accurately identify graph nodes that have undergone substantial changes from the deep semantics inherent in the model. Its core is to train a model that understands the semantics of a node within its graph context (defined by node attributes and edge relationships) and to determine whether it has changed by comparing the semantic representation of the same node in different graphs. This step is implemented through the following sub-processes: Step S401: The core of the semantic difference detection module is a pre-trained graph attention network model. The training and construction of this model are achieved through the following methods: First, a training dataset needs to be prepared. This dataset consists of a large number of standardized directed graph samples of digital twin models, which can be obtained from historical project repositories or generated in batches using standard conversion tools. Nodes in each graph sample have been labeled with category tags according to their business meaning (e.g., "motor", "valve", "control logic").
[0052] Next, the initial feature vectors of the nodes are constructed. For the training graph and the subsequent graph to be detected, the initial feature vector of each node is generated according to the following rules: the key fields in the node's attribute set (as defined in step S201) are converted into numerical representations.
[0053] Specifically, for categorical attributes such as "type label" and "material ID," one-hot encoding is used to convert them into sparse vectors; for numerical attributes such as "coordinate values" and "quality attributes," normalization is performed; for complex structured attributes such as "state transition table" and "rule expression," key metadata (such as the number of states and rules) is extracted or encoded into fixed-dimensional vectors using a pre-trained language model. All converted numerical vectors are concatenated to form the initial feature vector of the node.
[0054] Finally, based on the prepared dataset and initial features, the graph attention network is trained under supervision. The network structure is as described in step S402. During training, the initial feature vectors of the nodes in the graph and the edge structure of the graph are used as input, and the class labels of the nodes are used as supervision signals. The cross-entropy loss function is employed, and the network parameters are optimized through backpropagation. The training objective is to enable the network to accurately predict the class of the nodes. The trained model then possesses the ability to understand the semantics of nodes in the graph context and generate high-quality semantic embedding vectors. This model will have its parameters fixed for subsequent difference detection.
[0055] Step S402: The graph attention network model consists of three sequentially connected graph attention layers. Each layer performs feature transformation on the input directed graph, and its core is to perform "message passing and aggregation" operations. The specific workflow is as follows: For the directed graph input to the current layer, let the feature vector of each node i be denoted as . For any semantic edge in the graph that points from node j to node i. (Direction from neighbor j to target i), this layer calculates the attention weight of node j to node i. This weight is determined by the following factors: First, the type of semantic edges (such as "functional dependency" or "spatial containment") is mapped to a dense vector through a learnable type embedding table. Simultaneously, the direction information of the edges is treated as an inherent property of this vector.
[0056] Secondly, the feature vector of target node i , the feature vector of neighbor node j and the edge The types of embedding vectors are combined (e.g., concatenated) and input into a shared learnable weight matrix. Given an activation function (such as LeakyReLU), a scalar attention score is calculated. .
[0057] Finally, the attention scores are calculated for all incoming neighbor nodes of the target node i (i.e., all nodes j with edges pointing to i). The attention weights are then normalized using the softmax function. This process allows the impact of different edge types and node features on the weights to be modeled.
[0058] After obtaining all weights, this layer calculates the new feature vector of node i. The calculation method is as follows: First, for each incoming neighbor node j of node i, the feature vector... Use the corresponding attention weights We perform weighting and sum all the weighted vectors to obtain the aggregated neighbor message vector.
[0059] Then, the aggregated neighbor message vector is compared with the feature vector of node i itself in the previous layer. The two vectors are then fused. A typical fusion method involves first concatenating them, and then applying a learnable linear transformation matrix to the concatenated vector. The mapping is performed, and optionally passed through a non-linear activation function (such as ReLU), with the final output being the new feature vector of node i in the current layer. .
[0060] After three layers of such processing, the feature vector of each node is updated step by step, and the node feature vector output by the third layer is used as the 128-dimensional semantic embedding vector of that node.
[0061] Step S403: During the model training phase, the following specific steps need to be performed to obtain a usable semantic difference detection model: Training data preparation: Collect a large number of digital twin models from historical projects or public data sources, and convert them into standardized directed graphs in batches according to the method described in step S2. Nodes in these graphs are manually or semi-automatically labeled according to their business meaning, and each node is assigned a specific semantic category label (e.g., "pump body", "temperature sensor", "PID control algorithm", "safety pressure rule").
[0062] Training task setting: The training objective is explicitly set as a node classification task. That is, the entire structure of the directed graph (nodes and edges) and the initial feature vectors of the nodes (as described in S401) are used as the model input, and the consistency between the node categories predicted by the model and the node categories labeled in reality is used as the supervision signal.
[0063] Training process: Using the prepared labeled image dataset, it is divided into training, validation, and test sets. The cross-entropy loss function is used to calculate the model prediction loss. An adaptive moment estimation optimizer is selected to optimize the model parameters (including the network weight matrix). , Iterative optimization is performed using methods such as edge type embedding tables. In each training round, forward propagation calculates the node classification results, and backpropagation updates the parameters based on the loss gradient. Accuracy and other metrics are monitored on the validation set during training.
[0064] Training Termination and Model Consolidation: Training is terminated when the model's performance metrics (such as classification accuracy) on the validation set no longer show significant improvement, or when the preset maximum number of training epochs is reached. At this point, the final trained model parameters, which meet the performance requirements, are fixed and saved. This consolidated model then possesses the ability to generate high-quality semantic embedding vectors for each node in the input graph, which can be used for subsequent difference detection.
[0065] In step S404, during difference detection, the central model graph (from S2) and the local model graph (from S3) are first aligned at the nodes. The alignment operation is based on the "unique internal path identifier" assigned to each node in step S204. Identifier matching ensures that nodes representing the same logical entity in both graphs are correctly paired.
[0066] Step S405: For each successfully aligned node pair, extract its semantic embedding vector in its respective graph using the trained graph attention network model. This vector is a 128-dimensional floating-point vector that comprehensively represents the semantics of the node in a specific graph state.
[0067] Step S406: Calculate the cosine similarity between the two 128-dimensional semantic embedding vectors corresponding to each pair of nodes. Set a similarity threshold of 0.95. If the calculated cosine similarity value is lower than this threshold, the node is determined to have undergone a semantic change. In addition, for nodes that exist only in one graph and cannot find a matching identifier in another graph, they are directly determined to be changed nodes (considered as additions or deletions).
[0068] Step S407: Collect all nodes that have been determined to have undergone semantic changes (including nodes with similarity below the threshold and unmatched nodes) to form an initial set of changed nodes. This set will serve as the starting point for deriving the synchronization range in the subsequent step S5.
[0069] In summary, step S4 utilizes a pre-trained graph attention network that understands the context of graph structure to transform complex model content into comparable semantic vectors, and performs accurate, fine-grained node-level change recognition based on vector similarity.
[0070] Step S5, building upon the initial set of changed nodes output by step S4, aims to overcome the shortcomings of traditional full synchronization by intelligently determining the minimum model scope requiring synchronization. Step S4, by combining global static dependencies with the current local dynamic business context, precisely trims the nodes and edges that must be synchronized from the complete model graph, forming a minimum necessary synchronization subgraph. This process is implemented through the following sub-steps: S501. Prepare the data for cutting. The cutting unit simultaneously performs the following two core operations to provide the data foundation for subsequent cutting: Loading the static dependency graph: The pruning unit loads the pre-built static dependency graph for the target model from persistent storage. This graph is automatically constructed by the system based on the model's standardized directed graph (i.e., the semantic abstract representation generated in step S2) when the model is first added to the database.
[0071] The construction process is as follows: traverse all semantic edges in the standardized directed graph; for each semantic edge pointing from node A to node B, create a corresponding edge in the static dependency graph, indicating that node B is structurally or logically dependent on node A; at the same time, according to the dependency type of the semantic edge (such as "parameter binding", "coordinate system link", etc.), assign a fixed integer weight value to the newly created edge according to the preset mapping table to quantify the strength of the dependency type.
[0072] The default weight mapping example is as follows: the weight of an edge representing a direct parameter binding is 10, the weight of a coordinate system inheritance relationship is 8, the weight of an event triggering relationship is 6, and the weight of a script call relationship is 4. Once this graph is built, it is persistently saved, fully recording all possible dependency propagation paths and strengths between components within the model.
[0073] Generate a dynamic context mask: The pruning unit collects the current dynamic execution context information in real time from the runtime environment of the business domain's local node. This specifically includes three items: The system queries the lifecycle stage identifier of the currently executing task from the task scheduling system, retrieves the list of identifiers of currently activated and running simulation modules from the simulation engine's module registry, and queries the established mapping relationship table that binds specific model nodes to external data sources from the subscription records of the real-time data bus service.
[0074] Subsequently, the pruning unit calculates the relevance of each node in the model to the current context based on a set of predefined judgment rules. For example, the rules may include: if a node is a component of the currently activated simulation module, it is marked as relevant; if a node exists in the real-time data binding mapping table, it is marked as relevant; if the keywords in the node's functional description match the current task stage identifier, it is marked as relevant.
[0075] After traversing all nodes and applying the rules, a boolean value is generated for each node, ultimately forming a dynamic context boolean mask vector with a length equal to the total number of model nodes and indices corresponding to node identifiers. This mask is used in subsequent traversals to quickly determine whether any node belongs to the "relevant" nodes in the current business context.
[0076] S502. Perform a controlled breadth-first traversal. For each node in the initial set of changed nodes, as an independent starting point, execute the following algorithm on the static dependency graph: Initialization: Create a first-in-first-out queue and enqueue the current starting node and its initial path information (current depth is 0, cumulative weight is 0). At the same time, initialize an empty set to record the nodes that should be retained.
[0077] Loop through the queue: When the queue is not empty, perform the following operations: a. Dequeue: Retrieve a node from the head of the queue and its associated path information (current depth, cumulative weight). ).
[0078] b. Termination check: If the depth has reached the maximum depth of 5, skip the node and stop exploring its neighbors.
[0079] c. Neighbor Expansion: Query the static dependency graph to obtain all outgoing neighbor nodes (i.e., nodes that depend on this node). For each neighbor node nb: i. Propagation constraint check: Query the dynamic context boolean mask, and skip this neighbor if nb is marked as "irrelevant".
[0080] ii. Weight Calculation: Obtain the weight w of the edge from the current node to its neighbor nb from the static dependency graph. Calculate the new cumulative weight. .
[0081] iii. Pruning and retention judgment: If If the cumulative weight threshold of 5 is exceeded, the neighbor node nb is added to the set of nodes to be retained. Regardless of whether the weight threshold is met, as long as depth + 1 is less than the maximum depth of 5, the neighbor node nb, the new depth (depth + 1), and the new cumulative weight are added to the set of nodes to be retained. Enqueue it as a new path information tuple to continue exploring nb's subsequent dependent nodes.
[0082] Complete a single starting point: Traversal of the starting point ends when the queue is empty. The algorithm returns the set of nodes that meet the conditions and should be retained, explored from this starting point.
[0083] This process is executed independently once for each changed node in the set. The union of all the nodes that should be retained after independent execution is the set of all nodes selected through controlled traversal.
[0084] S503. Generate the minimum necessary synchronization subgraph. After traversal, the system generates the minimum necessary synchronization subgraph based on the set of all retained nodes obtained in step S502, through the following operations: Extract relevant edges: Traverse all semantic edges in the complete normalized directed graph of the original target digital twin model (i.e., the central model graph generated in step S2). For each semantic edge, check whether its source node and target node both exist in the aforementioned set of retained nodes. If the condition is met, select this edge as the edge that needs to be synchronized.
[0085] Constructing the subgraph structure: All the nodes selected and retained in step 1 are treated as a node set, and all the relevant edges selected in step 1 are treated as an edge set, together forming a new directed graph data structure. This data structure directly inherits all the attributes and semantic information of the nodes and edges in the original standardized directed graph.
[0086] Output: The newly constructed directed graph is the minimum necessary synchronization subgraph obtained by pruning. It is a graph structure that may be disconnected (when multiple independent change clusters do not have an intersection) or composed of multiple connected components, precisely containing all model elements directly affected by the changes and necessary in the current business context, as well as their internal relationships.
[0087] In summary, step S5, by simulating the propagation of the impact of the change and utilizing dynamic business context for real-time filtering and pruning, compresses the theoretically large set of affected nodes into the minimum synchronization set required for actual business operations. This process significantly reduces the amount of model data that needs to be transmitted and processed, directly reducing network bandwidth consumption and synchronization latency, and providing a precise input range for the next step of generating efficient incremental synchronization packets.
[0088] Step S6, following the minimum necessary synchronization subgraph output from step S5, aims to efficiently and securely encode the semantic changes represented by this subgraph into an incremental data packet suitable for network transmission. Its core principle is to avoid transmitting the complete model file, instead extracting only the original data fragments related to the changes, compressing them using differential coding techniques for different data types, and finally assembling them into a packet and securely signing it. This step is implemented through the following sub-processes: S601. Extract the original data fragment. The incremental packet generation unit receives the minimum necessary synchronization subgraph and performs the following operations: Obtaining the original model file and mapping relationship: The unit obtains the latest version of the original model file of the target model from the central model library based on the identifier of the target model.
[0089] Simultaneously, the "path identifier-original element mapping table" generated and persisted during the structured parsing process in step S2 is loaded or accessed. This mapping table records the correspondence between the "internal path identifier" of each normalized directed graph node and the specific location information of the corresponding element in the original model file.
[0090] Traverse and locate subgraph nodes: The unit traverses each node in the minimum necessary synchronization subgraph. For each node, using its "internal path identifier" as the key, it queries the "path identifier-original element mapping table" to obtain the precise location information of the original model element corresponding to that node in the original file.
[0091] Extracting raw data fragments: Based on the obtained location information, the unit calls the parser or data access interface corresponding to the raw file format (e.g., the raw data reading module associated with the format adapter in step S2) to directly read the element located at that position and its complete, unnormalized parsed raw data representation from the raw model file.
[0092] The extracted data fragments are the "raw data blocks" of the element. Their content depends on the element type and may include raw key-value pairs of attribute sets, complete descriptions of geometric data, or raw text of script code.
[0093] S602. Perform differential encoding based on data type. For each extracted data fragment, calculate its difference relative to the corresponding fragment in the local cache copy using different strategies, according to its data type: Script code: For script-type node data, the script code of the new version (central library) and the old version (local cache) are first parsed into abstract syntax trees (ASTs). Then, the tree edit distance between the two ASTs is calculated to identify the minimum sequence of edit operations (such as insertion, deletion, or replacement of subtrees) required to transform the old tree into the new tree. Finally, the encoded transmission only contains these edit operations and their positional paths in the tree.
[0094] Geometric Features: For geometric description data, further distinguish its format. If it is a mesh model, calculate the set of vertex position offset vectors of the new mesh relative to the old mesh, as well as the set of differences in patch indices; if it is a parametric surface, extract the changes in control point coordinates and the adjustment flags for surface order and parameter range.
[0095] Regular attributes: For regular attribute fields (such as numeric and string), directly compare the byte-level differences between the original byte representations of the field in the two versions, generate standard difference data (e.g., based on the longest common subsequence algorithm), and record the changed field key name and its complete new value.
[0096] S603, Serialization and Encapsulation. The system serializes the differential encoding results calculated for all changed data fragments in step S602 according to a predefined structured format, generating a continuous data payload. The specific process is as follows: Constructing the serialization structure: Create a logical data packet structure. This structure contains a header and a body. The header records metadata such as the model's globally unique identifier, target version number, and number of change nodes. The body is a list, where each item corresponds to the encoding result of a change node. Each item must contain at least: the node's internal path identifier, its data fragment type identifier, and the specific differentially encoded data corresponding to that type.
[0097] Perform serialization: Encode the structured data packet structure described above using a predetermined, efficient binary serialization format, converting it into a continuous stream of bytes. This stream of bytes is the data payload to be transmitted. The selected serialization format must support the encoding and decoding of all field types (such as strings, integers, lists, and nested structures) in the above structure.
[0098] S604. Generate a digital signature and assemble the final data packet. The system securely signs the serialized data payload and assembles it into a final transmittable packet: Digital signature calculation: Using the private key held in the central model library, a digital signature is calculated on the data payload obtained in step S603 based on the SM2 national cryptographic algorithm. The signature calculation process follows the standard procedure of the SM2 algorithm, including hashing the data and encrypting the hash value using the private key to generate the signature value.
[0099] Assemble the transport packet: Finally, assemble the following three parts in sequence into the final incremental synchronization data packet: Packet header: A fixed-length header or one with a length field, containing information such as the magic number (used to identify the packet type), the length of the data payload, and the length of the signature value.
[0100] Data payload: i.e., the serialized byte stream generated by step S603.
[0101] Signature value: The original bytes of the SM2 digital signature calculated in step 1.
[0102] The transport packet, as a complete binary data block, will be sent to the local node of the business domain through a secure transport channel.
[0103] In summary, step S6 directly embodies the achievement of efficient network synchronization. It transforms the finely trimmed semantically changed subgraph into a binary incremental packet with minimal size. By employing the most effective differential coding techniques tailored to heterogeneous data such as scripts, geometry, and attributes, it maximizes the compression of the amount of data to be transmitted. The final digital signature ensures the integrity and authenticity of the incremental packet during transmission, providing a guarantee for secure and reliable synchronization. The output of this step, the signed incremental packet, will be sent to the local node in the business domain for reception and verification.
[0104] S7. Perform incremental synchronization and consistency verification. Following the incremental synchronization data packet generated and sent in step S6, this step completes reception, security verification, data injection, and eventual consistency verification on the local node in the business domain, ensuring that the synchronization operation improves efficiency without introducing the risk of inconsistency. This step is implemented through the following sub-processes: S701. Reception and Security Authentication. The local node in the service domain receives incremental synchronization data packets from the central model library through a secure transmission channel. Subsequently, the node performs the following security authentication process: Packet parsing: The local node parses the received binary data blocks according to the transport packet format defined in step S604. Specifically, it first reads the fixed-format packet header, and then, based on the length field, separates the data payload and the digital signature portion that follow.
[0105] Calculate the hash value of the data payload: Using the same hash algorithm as that used for signing the central library (such as the SM3 algorithm, which belongs to the national cryptographic standard and is often used together with the SM2 algorithm), calculate the hash value (digest) of the separated complete data payload byte stream to generate a fixed-length hash value.
[0106] Perform SM2 signature verification: Call the national cryptographic SM2 signature verification function, which requires three core input parameters: a) the data payload hash value calculated in step 2; b) the digital signature value extracted from the data packet; and c) the public key of the central model library, which is stored securely in advance locally. The function will use the public key to perform operations such as decryption on the signature value to obtain a result value.
[0107] Comparison and Judgment: The output of the SM2 signature verification function is compared with the hash value of the data payload generated in step 2. If they match perfectly, the verification passes, confirming that the data packet has not been tampered with during transmission and indeed originates from the central model library holding the corresponding private key, and the process proceeds to the next step. If they do not match, the signature verification fails, the local node discards the entire data packet, triggers a security anomaly alarm to the system monitoring platform, and terminates the current synchronization process.
[0108] S702, Parsing and Injection Update. The injection module within the consistency verification and update unit of the local node begins processing the verified incremental packet and performs the following operations: Packet Structure Parsing: The injection module within the consistency verification and update unit strictly follows the packet assembly and serialization formats defined in steps S603 and S604 to perform reverse parsing of the verified data packets. It first reads the packet header and accurately separates the data payload and digital signature value based on the length field in the header. Next, using the deserialization method specified in step S603, it decodes the data payload byte stream to recover a structured change list. Each entry in this list explicitly includes: the node's internal path identifier, the data fragment's type identifier, and the corresponding differentially encoded data block.
[0109] Application Difference Update: The injection module within the consistency verification and update unit traverses the parsed change list, and for each entry, performs the following steps: Locating local elements: Based on the node internal path identifier in the entry, locate the corresponding model element in the local model cache copy.
[0110] Apply differences by type: Invoke the corresponding difference applicator based on the data type identifier. Script Code: The differential applicator first reads the old version of the script code corresponding to the node from the local cache and parses it into an old version of the abstract syntax tree using the same parser. Then, it sequentially processes the sequence of edit operations recorded in the differentially encoded data block. Each edit operation specifies the operation type, the target position in the old AST, and the new subtree data that may be carried. Based on the operation type and position information, the applicator directly executes the corresponding node add, delete, or modify operations on the old AST, thereby generating the new version of the AST. Finally, an AST de-parsing tool is used to convert the new AST back into script code text and write it back to the local model file.
[0111] Geometric Features (Mesh Model): The difference applicator reads the local mesh data. For each vertex offset vector recorded in the difference data, it finds the corresponding vertex index in the local mesh and adds the offset vector to the vertex's coordinates. For the face index difference set, it directly modifies the face list of the local mesh according to the operation type (add, delete, modify).
[0112] Geometric Features (Parametric Surface): The difference applicator reads the local surface data. It adds the changes in control point coordinates recorded in the difference data to the corresponding local control point coordinates one by one. If order or parameter range adjustment flags exist, these metadata for the local surface are updated accordingly.
[0113] For ordinary attributes: The difference applicator obtains the old value byte stream of the corresponding attribute locally. Then, using the patch application function of the difference algorithm corresponding to step S602, the differentially encoded data block is applied as a "patch" to the old value byte stream, thereby generating a new value byte stream and writing it back. Alternatively, if the difference data directly provides a complete new value, the old value is directly replaced with the new value.
[0114] To ensure the reliability of the entire update process, the engine typically creates a temporary backup of the local model copy before starting, or is designed to ensure that the application of each change entry is idempotent. If an error occurs while applying any change, the engine will abort the process and trigger a rollback (as described in S704) to ensure that the local model state is not corrupted.
[0115] S703. Recalculate the semantic fingerprint. After the update is complete, the consistency check and update unit is started. To avoid re-parsing the entire model, the unit only re-executes the same structured parsing process as step S2 for the nodes covered by the minimum necessary synchronization subgraph determined in step S5 (i.e., the set of nodes theoretically affected by this update), generating the normalized representation of these nodes after the update. Subsequently, the semantic fingerprint is calculated for each such node: Attribute Encoding: Sort the node's attribute set according to a predefined global key order, filtering out fields marked as temporary or non-persistent. Normalize the values of the remaining fields (e.g., convert numeric values to standard format strings, and strings using UTF-8 encoding), and concatenate all encoded strings in order to generate an attribute byte stream.
[0116] Geometric feature extraction: Extract stable features from the geometric / topological feature description data of this node. The specific method is as follows: Curvature histogram generation: If the geometric data is a grid, calculate the Gaussian curvature or average curvature of each vertex of the grid. Divide the entire range of curvature values into N equal intervals (e.g., N=20), count the number of vertex curvature values falling into each interval, form an N-dimensional histogram vector, and perform L2 normalization on this vector.
[0117] Boundary Representation Tree Encoding: This method transforms the boundary representation (B-Rep) structure of a geometry into a normalized tree. The root node represents the geometry itself, child nodes represent faces, grandchild nodes represent cycles, and so on. A depth-first traversal is performed on the tree, encoding the type identifier and key attributes (such as the surface type of a face) of each node into fixed-length feature fragments. These fragments are then concatenated in traversal order to form a boundary representation tree encoding vector.
[0118] Feature vector concatenation: The normalized N-dimensional curvature histogram vector is concatenated with the boundary representation tree encoding vector to form a fixed-dimensional geometric feature vector. If the geometric data is not gridded or has no boundary representation information, a zero vector is used as a placeholder.
[0119] Hash generation: The attribute byte stream obtained in step S1 and the geometric feature vector (converted to byte stream) obtained in step S2 are concatenated in sequence as input. A 256-bit (32-byte) binary digest is calculated using the SHA3-256 hash function. This digest is the semantic fingerprint of the node.
[0120] S704. Consistency Comparison and Result Processing.
[0121] Obtaining Reference Fingerprints: When generating incremental packets in step S6, the central model library uses the exact same algorithm as in S703 to compute reference semantic fingerprints for each node in the synchronization subgraph. These reference fingerprints are serialized and encapsulated within the incremental packet as part of the data payload (e.g., as a separate check field in the structured data packet body described in S603). Local nodes extract and store this list of reference fingerprints when parsing the data packet in step S702.
[0122] Fingerprint matching: The local node recalculates the semantic fingerprint for each affected node in step S703 and performs a bit-by-bit precise comparison with the corresponding reference fingerprint extracted from the incremental packet. The comparison operation is usually performed using a memory binary comparison function (such as memcmp in C).
[0123] Result determination and operation: Consistency: If the locally computed fingerprints of all nodes are completely identical to the reference fingerprint, the incremental synchronization is considered successful, and the model state is semantically strictly aligned with the central library. Local nodes then atomically update the metadata in their model cache: updating the model version number to the target version number for this synchronization and recording the synchronization completion timestamp. Afterwards, temporary data created for this synchronization can be cleaned up.
[0124] Inconsistency: If any node's fingerprint does not match, the synchronized state is deemed inconsistent, and synchronization fails. The system immediately performs a rollback operation. Specifically, the injection engine temporarily backs up the local model copy created before applying the update in step S702 and restores it to the current state; or, it calls the reverse operation for each applied change. This operation ensures that the local model copy is completely restored to the state before the start of this synchronization attempt. Simultaneously, the system triggers an alarm log, recording the inconsistent node identifier, expected fingerprint, and actual fingerprint, for subsequent manual or automated troubleshooting.
[0125] In summary, step S7 is the final checkpoint ensuring the reliability of the entire synchronization method. Rigorous security verification ensures the trustworthiness of the data source, precise difference injection enables efficient updates, and final semantic fingerprint comparison based on a strong hash algorithm verifies the semantic consistency between the synchronized local model and the central library model within a specified range at the logical level, rather than the byte level. This complete "receive-verify-apply-check" protocol ensures the efficiency, security, and reliability of the cross-domain digital twin synchronization process, enabling this method to operate stably in real-world industrial scenarios. Thus, the complete synchronization loop from change detection to final consistency confirmation is complete.
[0126] The above-described steps constitute the core synchronization logic of this invention. To support the execution of this method, this invention also provides a cross-domain digital twin synchronization system integrating a digital asset model library, which includes a model metadata acquisition unit, a structured parsing unit, a semantic difference detection unit, a minimum synchronization subgraph pruning unit, an incremental package generation unit, and a consistency verification and update unit.
[0127] The model metadata acquisition unit is responsible for interacting with the centralized digital asset model library to obtain the current version metadata description of the target model. The structured parsing unit contains an array of format adapter modules. Each adapter is configured with a dedicated parsing rule engine, which can map elements in the original model file to the corresponding node types under the unified semantic meta-model framework and extract standardized attribute fields.
[0128] The graph attention network used in the semantic difference detection unit consists of three graph convolutional layers. The neighbor aggregation function of each layer adopts a weighted summation mechanism, and the weights are determined by the type and direction of the semantic edges between nodes. The network output layer generates a 128-dimensional semantic embedding vector for each node, which is used for subsequent similarity calculation.
[0129] When performing breadth-first traversal, the minimum synchronous subgraph pruning unit sets the maximum traversal depth to five levels and applies a dynamic execution context boolean mask to filter paths when expanding each level. At the same time, it records the cumulative dependency weight of each path and only retains the set of nodes covered by paths with a cumulative weight higher than the threshold of five.
[0130] The incremental packet generation unit and the consistency verification and update unit ensure transmission security through a digital signature mechanism based on the national cryptographic SM2 algorithm. Before being sent, the incremental packet is signed by the central library's private key, and the local node uses the corresponding public key to verify the signature.
[0131] The system is deployed on both the centralized digital asset model repository side and the local nodes in each business domain. The central system is responsible for executing steps S1 to S6, while the local systems are responsible for executing steps S3 and S7. Both sides exchange data through a secure transmission channel to ensure the security and reliability of the entire synchronization process. Through the collaborative work of the above methods and systems, this invention achieves efficient, reliable, and fine-grained cross-domain digital twin synchronization while maintaining the semantic integrity of the model, effectively solving the core defects of existing technologies.
[0132] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.
[0133] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.
Claims
1. A cross-domain digital twin synchronization method integrating a digital asset model library, characterized in that, include: Obtain the current version metadata description of the target digital twin model from the centralized digital asset model library; Based on the unified semantic meta-model framework, the target model from the model library and the corresponding copy of the business domain local cache are respectively structured and parsed to generate a central and local standardized directed graph. Using a semantic difference detection model trained on a graph attention network, semantic embedding vectors of aligned nodes in the central and local normalized directed graphs are extracted respectively. Nodes with semantic changes are identified by calculating vector similarity, forming an initial set of changed nodes. Combining the static dependency graph pre-built for the target model and the dynamic execution context collected from the local runtime environment of the business domain, the minimum necessary synchronization subgraph that must be synchronized is pruned from the central standardized directed graph. The pruning includes: starting from the initial set of change nodes, performing a traversal on the static dependency graph constrained by path depth and cumulative dependency weight, and using a Boolean mask generated based on the dynamic execution context for node filtering. Incremental synchronization data packets are generated based on the minimum necessary synchronization subgraph, and these data packets are sent to the local node in the business domain for security verification, difference injection, and semantic fingerprint consistency verification to complete the synchronization.
2. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, Structured parsing includes: Based on the modeling standard type in the metadata description, call the corresponding format adapter; Using the parsing rule engine within the format adapter, the original model elements are mapped to semantic nodes under the unified semantic meta-model framework and their attributes are populated. At the same time, the relationships between elements are converted into directed semantic edges, thereby constructing the standardized directed graph.
3. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, Training the semantic difference detection model includes: Construct a training dataset consisting of a standardized directed graph of a large number of digital twin models, and label the nodes in the graph with semantic category labels; Construct the initial feature vector of a node based on its attribute set; Using the structure of the standardized directed graph and the initial feature vectors of the nodes as input, and with the node classification task as the objective, a graph attention network containing at least three graph attention layers is trained under supervision, so that the trained model has the ability to generate node semantic embedding vectors.
4. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, The combination of static dependency graph and dynamic execution context to prune the minimum necessary synchronization subgraph specifically includes: Load the static dependency graph, where the edge weights in the graph are assigned fixed integer values based on the dependency type; The dynamic execution context Boolean mask is generated based on the current execution task stage, the activated simulation modules, and the real-time data binding relationship. For each node in the initial set of changed nodes, a controlled breadth-first traversal is performed on the static dependency graph: the traversal depth does not exceed a preset maximum depth, and when expanding neighboring nodes, if the neighboring node is marked as irrelevant in the Boolean mask, it is skipped. At the same time, the edge weights on the path are accumulated, and only nodes covered by paths with accumulated weights greater than a preset threshold are retained. Extract all the retained nodes and their associated edges in the central normalized directed graph to form the minimum necessary synchronization subgraph.
5. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, Generating incremental synchronization data packets includes: Based on the internal path identifiers of the nodes in the minimum necessary synchronization subgraph, extract the corresponding original data fragments from the original model file; For the original data fragments of different data types, a differentiated differential coding strategy is used to calculate the amount of change relative to the corresponding fragment in the local copy. The data types include at least script code, geometric features, and ordinary attributes. The differential encoding result is serialized into a data payload, and the data payload is digitally signed using a private key to assemble the final incremental synchronization data packet.
6. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 5, characterized in that, Differential coding strategies for raw data fragments of different data types include: For script code, after parsing it into the old and new versions of the abstract syntax tree, the tree edit distance is calculated and the edit operation sequence is encoded; For the mesh model in the geometric features, calculate the vertex position offset vector and the face index difference set; For parametric surfaces in geometric features, extract the changes in control point coordinates and surface metadata adjustment flags; For ordinary attributes, perform byte-level difference comparisons and record the changed fields and new values.
7. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, Semantic fingerprint consistency verification includes: After an application incremental update, the business domain local node recalculates the semantic fingerprint for the nodes covered by the minimum necessary synchronization subgraph. The semantic fingerprint is obtained by concatenating the node's normalized attribute byte stream and geometric feature vector and performing hash calculation. The recalculated semantic fingerprint is compared with the reference fingerprint extracted from the incremental synchronization data packet; If all data is consistent, the synchronization is considered successful and the local metadata is updated; if there are inconsistencies, a rollback operation is triggered and an alarm is issued.
8. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 5, characterized in that, Security verification includes: After receiving the incremental synchronization data packet, the local node in the business domain separates the data payload and digital signature. The hash value of the data payload is calculated using the same hash algorithm as the central model library; The digital signature is verified using a pre-stored central model library public key, and the verification result is compared with the hash value to verify the integrity and authenticity of the data packet.
9. The cross-domain digital twin synchronization method for an integrated digital asset model library according to claim 1, characterized in that, The current version metadata description should include at least the globally unique identifier of the model, the semantic version number, the modeling standard type, the semantic type of the root node, and the list of top-level components.
10. A cross-domain digital twin synchronization system integrating a digital asset model library, applied to the cross-domain digital twin synchronization method integrating a digital asset model library as described in any one of claims 1-9, characterized in that, This includes a central processing subsystem deployed on the centralized digital asset model library side and a local processing subsystem deployed on local nodes in the business domain. The central processing subsystem includes: The model metadata acquisition unit is used to acquire the current version metadata description of the target digital twin model; The structured parsing unit is used to parse the target model into a centrally standardized directed graph based on the unified semantic meta-model framework. The semantic difference detection unit is used to identify semantic change nodes by comparing the central and local normalized directed graphs using a model trained on a graph attention network. The minimum synchronization subgraph pruning unit is used to combine the static dependency graph and the dynamic execution context to prune the minimum necessary synchronization subgraph from the centrally standardized directed graph. An incremental packet generation unit is used to generate and sign incremental synchronization data packets based on the minimum necessary synchronization subgraph. The local processing subsystem includes: The local structured parsing unit is used to parse the local cache model copy into a local normalized directed graph; The consistency verification and update unit is used to perform security verification, difference injection, and semantic fingerprint consistency verification on the received incremental synchronization data packets.