A method and system for synchronizing the state of digital twins based on factor event-driven mechanisms

Abstract

This application relates to the field of big data processing technology and discloses a method and system for synchronizing the state of a digital twin based on factor event-driven processes. The method includes: establishing a factor object mapping table; establishing an instance object association table; collecting data streams of each running factor in real time, generating factor events including running factor identifiers and numerical changes, and writing them into an event queue; retrieving factor events from the event queue and generating state update events; determining the target digital twin instance and generating an instance update task; and performing atomic updates to obtain the updated state vector. This application constructs a two-layer directional propagation and instance-level merging update mechanism from running factors to device objects and then to digital twin instances. This transforms the original instance-by-instance distributed state synchronization process in high-concurrency scenarios into a process that enables directional positioning, merging, and centralized updating of digital twin instances affected by changes in running factors.

Description

Technical Field

[0001] The present invention relates to the technical field of big data processing, and more specifically, to a digital twin state synchronization method and system based on factor event driving. Background Art

[0002] As the information system of the financial industry continues to develop towards high concurrency, low latency and high availability, financial servers have been widely used in scenarios such as transaction processing, risk control calculation, account management, message distribution and data services. In order to improve the visualization monitoring ability and real-time management ability of the running state of financial servers, digital twin technology has begun to be applied to the running management scenario of financial servers. By establishing corresponding digital twin instances for running objects such as physical server nodes, virtual computing nodes, message processing nodes, data writing nodes or risk control verification nodes, the state parameters during the server operation are maintained and displayed.

[0003] In the prior art, for the synchronous update of the running state of financial servers, usually after the running data is collected, state judgment and state refresh are directly performed on each digital twin instance respectively, or the running data is distributed to each digital twin instance and then each digital twin instance completes the state update respectively. Such processing methods can meet the basic requirements when the number of instances is small and the running link is short. However, in the case of an increasing scale of the financial server cluster, an increasing number of running factor types and an increasing state update frequency, a single change of the same running factor often affects multiple device objects at the same time and further associates multiple digital twin instances; for such multi-object linkage updates caused by changes in shared running factors, the prior art lacks a state synchronization mechanism that can first perform directional positioning on the affected objects and then perform centralized merging on the associated instances, resulting in that the state synchronization process usually still needs to retrieve and update each digital twin instance one by one, and it is difficult to meet the low-latency state synchronization requirements in high-concurrency scenarios.

[0004] Therefore, there is an urgent need to provide a method to solve the technical problem of the lack of an efficient state synchronization mechanism when shared running factor changes cause multi-object and multi-instance linkage updates in the server running management scenario. Summary of the Invention

[0005] In order to overcome the defect that in the prior art, when shared running factor changes affect multiple device objects at the same time and further associate multiple digital twin instances, it is still necessary to retrieve, calculate and update each digital twin instance one by one, resulting in low state synchronization efficiency, and in order to achieve the purpose of directional positioning, aggregation and centralized update of digital twin instances affected by running factor changes, the present invention provides the following technical solutions:

[0006] In a first aspect, this invention discloses a factor event-driven digital twin state synchronization method, comprising:

[0007] Based on the mapping relationship between each operating factor and the device object, and the state response coefficient corresponding to each device object, a factor object mapping table is established;

[0008] Based on the association between each digital twin instance and the device object, establish an instance object association table;

[0009] The data stream of each operating factor is collected in real time. When the change in the value of any operating factor reaches the corresponding trigger threshold, a factor event including the operating factor identifier and the change in value is generated and written to the event queue.

[0010] Retrieve factor events from the event queue, determine the device objects affected by the factor events based on the running factor identifier and factor object mapping table in the factor events, determine the state increment corresponding to each device object based on the state response coefficient and numerical change of each device object, and generate state update events based on each device object and its corresponding state increment.

[0011] The target digital twin instance is determined based on the association table of device objects and instance objects involved in the status update event. Multiple status update events corresponding to the same target digital twin instance are written into the instance buffer, and the status increments of the same device object in the instance buffer are accumulated and merged to generate an instance update task.

[0012] The instance update task performs an atomic update on the state vector of the target digital twin instance to obtain the updated state vector.

[0013] Furthermore, the methods for constructing the event queue and handling events include:

[0014] Set the event queue as multiple sub-event queues;

[0015] The target sub-event queue corresponding to the factor event is determined based on the hash value of the running factor identifier, so that factor events corresponding to the same running factor are written into the same sub-event queue.

[0016] Multiple processing threads are used to retrieve factor events from multiple sub-event queues in parallel for processing, thus completing the parallel processing of factor events.

[0017] Furthermore, methods for merging multiple factor events of the same running factor include:

[0018] Detect multiple factor events corresponding to the same running factor within a preset event merging window;

[0019] The numerical changes in multiple factor events are accumulated and merged according to the chronological order of the events.

[0020] The factor events corresponding to different operating factors are merged independently.

[0021] The length of the event merging window is dynamically adjusted based on the depth of the event queue and the event processing rate of the processing thread to generate merged factor events.

[0022] Furthermore, methods for generating instance update tasks include:

[0023] When writing multiple state update events belonging to the same target digital twin instance to the instance buffer, a buffer entry is created using the digital twin instance identifier as the key.

[0024] When there are multiple state update events for the same device object in the same buffer entry, the state increments corresponding to the multiple state update events are accumulated and stored in chronological order.

[0025] After completing the writing of the state update event, iterate through the instance buffer and generate instance update tasks.

[0026] Furthermore, the concurrent write control methods for the instance buffer include:

[0027] The instance buffer is divided into multiple buffer partitions based on the hash value of the digital twin instance identifier;

[0028] Each buffer partition should be assigned an independent concurrent control unit;

[0029] Concurrent write control of the instance buffer is achieved by performing parallel writes to different buffer partitions through an independent concurrent control unit.

[0030] Furthermore, the methods for determining the trigger threshold include:

[0031] Statistical analysis of the fluctuation of the corresponding operating factor within the historical time window;

[0032] The trigger threshold for the corresponding operating factor is determined based on the volatility statistics, which include at least one of standard deviation, mean absolute deviation, or volatility.

[0033] By making the trigger threshold positively correlated with the fluctuation statistics, the trigger threshold of the corresponding operating factor can be obtained.

[0034] Furthermore, the method for performing atomic updates to the state vector of the target digital twin instance based on the instance update task includes:

[0035] Based on the device object identifier recorded in the instance update task, the storage location of the corresponding state parameter in the state vector is determined by combining the instance object association table.

[0036] Read the current status parameter value at the corresponding storage location;

[0037] The state increment in the instance update task is accumulated to the corresponding current state parameter value to obtain the updated state parameter value;

[0038] The updated values ​​of multiple state parameters are written back to the state vector at once, completing the atomic update.

[0039] Furthermore, the method also includes verifying and updating the version identifier, and the method for verifying and updating the version identifier includes:

[0040] Read the current version identifier corresponding to the target digital twin instance;

[0041] When writing back the updated state vector, verify whether the current version identifier is consistent with that when reading it;

[0042] Upon successful verification, the state vector is written back and the version identifier is incremented.

[0043] If the verification is inconsistent, the latest state vector and the latest version identifier are reread, and the update is re-executed based on the latest state vector to complete the verification and update of the version identifier.

[0044] Furthermore, the method also includes a status query response, the method for which the status query response includes:

[0045] When a status query request for any digital twin instance is received, the current status vector and current version identifier of the corresponding digital twin instance are returned.

[0046] When a status query request carries a version identifier, if the carried version identifier is inconsistent with the current version identifier, the current status vector and the current version identifier are returned, thus completing the status query response.

[0047] Secondly, this invention discloses a factor event-driven digital twin state synchronization system for implementing the factor event-driven digital twin state synchronization method. The system includes: a data storage module, an event monitoring module, an event processing module, a task merging module, and a state update module.

[0048] The data storage module is used to establish a factor object mapping table based on the mapping relationship between each operating factor and the device object, and the state response coefficient corresponding to each device object, and to establish an instance object association table based on the association relationship between each digital twin instance and the device object.

[0049] The event monitoring module is used to collect data streams in real time. When the change in the value of any running factor reaches the corresponding trigger threshold, it generates a factor event including the running factor identifier and the change in value and writes it to the event queue.

[0050] The event processing module is used to retrieve factor events from the event queue, determine the target device object according to the factor object mapping table, calculate the state increment based on the state response coefficient and the numerical change, and generate a state update event.

[0051] The task merging module is used to determine the target digital twin instance based on the instance object association table, write multiple state update events corresponding to the same target digital twin instance into the instance buffer, and accumulate and merge the state increments for the same device object to generate an instance update task.

[0052] The state update module is used to perform atomic updates on the state vector of the target digital twin instance based on the instance update task, so as to obtain the updated state vector.

[0053] Compared with related technologies, the present invention has the following beneficial effects:

[0054] This invention uses a factor object mapping table to direct changes in runtime factors to the scope of affected device objects, and then uses an instance object association table to further map the affected device objects to target digital twin instances. Based on this, multiple state update events corresponding to the same target digital twin instance are first aggregated and merged, and then atomic updates of the state vector are performed. This reconstructs the originally scattered per-instance processing path into a hierarchical propagation and centralized update path from runtime factors to device objects and then to digital twin instances. This solves the technical problem of lacking an efficient state synchronization mechanism when changes in shared runtime factors trigger multi-object and multi-instance linkage updates in server operation management scenarios, and improves the efficiency of state synchronization.

[0055] This invention accumulates and merges multiple factor events of the same running factor in chronological order within an event merging window, and dynamically adjusts the length of the event merging window according to the depth of the event queue and the event processing rate of the processing thread. While ensuring that the time sequence of changes of the same running factor is not disrupted, it enables the granularity of events entering the subsequent state propagation link to adapt to the real-time load of the system. This transforms high-frequency, fragmented factor fluctuations into event inputs that are more suitable for subsequent object mapping, instance aggregation, and atomic update processing, thereby improving the throughput stability and real-time performance of the entire state synchronization link in high-concurrency scenarios. Attached Figure Description

[0056] Figure 1 A flowchart illustrating the steps of the factor event-driven digital twin state synchronization method provided by this invention;

[0057] Figure 2 A logic diagram for determining whether there is a valid influence relationship between the running factor and the device object in the embodiments provided by the present invention;

[0058] Figure 3The data processing flowchart in the factor event-driven digital twin state synchronization system provided by this invention is shown. Detailed Implementation

[0059] 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.

[0060] Example 1

[0061] Please see Figure 1 As shown, this embodiment provides a factor event-driven digital twin state synchronization method, which can be applied to various application scenarios with requirements for operational factor monitoring, device object state propagation, and digital twin instance updates. These include server cluster operation management scenarios, data center infrastructure management scenarios, industrial operation monitoring scenarios, and other scenarios requiring digital twin state synchronization based on changes in operational status. To facilitate understanding of the technical solution of this application, the specific implementation process of this method is described below using a financial service provider operation management scenario as an example:

[0062] Step 1: Establish a factor object mapping table to record the operating factor identifier, the device object identifier affected by the corresponding operating factor, and the status response coefficient.

[0063] To facilitate understanding, the core concepts involved in this solution will be explained first. In this embodiment, namely the operation and management scenario of the financial service provider, the factor object mapping table is used to record the interaction relationship between the operation factor and the device object, including at least the operation factor identifier, the device object identifier affected by the corresponding operation factor, and the state response coefficient.

[0064] In this embodiment, the operating factor refers to the monitoring quantity that can reflect the changes in the operating status of the financial server and can have a direct or indirect impact on the operating status of the device object. The operating factor is based on data items that can be collected, quantified and continuously recorded in time series, and can come from operating data such as processing load, storage access, communication latency, message backlog, thread activity, abnormal alarms and configuration changes.

[0065] A device object refers to the smallest operating object in a financial server operation and management scenario that can carry status parameters and be independently monitored and updated. It can be any one of physical server nodes, virtual computing nodes, message processing nodes, data writing nodes, cache processing nodes, or risk control verification nodes.

[0066] The state response coefficient is used to characterize the direction and intensity of the influence of changes in operating factors on changes in the operating state of equipment. The state response coefficient can be positive or negative. A positive value indicates that the operating state of the equipment is in the same direction as the change in operating factors, while a negative value indicates that the operating state of the equipment is in the opposite direction to the change in operating factors. The larger the absolute value, the higher the intensity of the influence.

[0067] Before establishing the factor object mapping table, it is necessary to determine the scope of equipment objects and the scope of operating factors. The scope of equipment objects can be determined jointly by the operating resource ledger, deployment list, and monitoring access list, and a unique equipment object identifier is assigned to each equipment object. The scope of operating factors is determined by the data source of the monitoring access, and data items that meet the requirements of continuous sampling, clear unit, and complete timestamp are selected as candidate operating factors. A unique operating factor identifier is assigned to each operating factor. Through this process, the input of the factor object mapping table can be clearly defined as the fixed caliber of "operating factor identifier - equipment object identifier".

[0068] In this embodiment, the mapping relationship is established by combining direct acquisition association and dependency topology extension. Direct acquisition association is used to determine the source device object that the running factor first affects. If a certain running factor is directly acquired from a certain device object, a basic mapping relationship from the running factor to the device object is established first. For example, if the message queue length to be processed is directly acquired from the message processing node, a basic mapping relationship from the running factor to the message processing node is established first. Dependency topology extension is used to determine the associated device objects that the change in the running factor may continue to affect. If there is a call chain, message chain, or data write chain between the source device object and other device objects, the impact path of the running factor is extended to the relevant device objects according to the deployment topology and running dependencies.

[0069] To prevent uncontrolled expansion of the propagation range, propagation level thresholds and minimum association strength thresholds are pre-set when relying on topology expansion. The propagation level threshold is used to limit the maximum number of link layers that can be extended outward from the source device object, and the minimum association strength threshold is used to filter out occasional weakly associated links. The propagation level threshold can be determined based on the average call depth and link stress test results in the deployment topology, and the minimum association strength threshold is determined based on the link co-occurrence ratio in historical operation records.

[0070] In this embodiment, the propagation level threshold can be determined as follows: First, starting from the source device object, traverse the downstream dependent links in the deployment topology, and statistically analyze the distribution of link layers between each candidate device object and the source device object to obtain the average call depth; then, read the response retention rate corresponding to each link layer in the link stress test results, and stop taking values ​​downward when the response retention rate corresponding to a certain link layer is lower than the preset retention ratio; finally, the minimum link layer that is not lower than the average call depth and meets the response retention rate requirement is determined as the propagation level threshold.

[0071] The minimum association strength threshold can be determined as follows: Within a preset statistical window, count the number of times the candidate device object synchronously appears within the time delay window when the source device object-related events occur, and divide the number of synchronous occurrences by the total number of source device object-related events to obtain the link co-occurrence ratio; then count the baseline co-occurrence ratio between device objects with no direct dependency relationship, and add a preset safety margin to the baseline co-occurrence ratio to obtain the minimum association strength threshold; only when the link co-occurrence ratio corresponding to the candidate device object is not lower than the minimum association strength threshold, the candidate device object is retained in the candidate mapping range. In this way, the mapping relationship is not simply specified by experience, nor is it simply dependent on statistical results, but rather the candidate mapping range is established based on engineering dependencies.

[0072] To ensure the status response coefficients have a clear source, the sampling period, calibration time window, minimum effective sample size, correlation consistency threshold, response amplitude threshold, and time delay window are pre-defined when establishing the factor object mapping table. The sampling period is used to unify the sampling interval for running factor data and device object status data; the sampling period can be determined based on monitoring access capabilities. The calibration time window is used to limit the range of data participating in table creation; the calibration time window covers the entire operating cycle and includes peak and off-peak periods. The minimum effective sample size is used to eliminate accidental correlations caused by monitoring interruptions or insufficient data; the minimum effective sample size can be determined jointly based on the sampling period and calibration time window. The consistency threshold is used to determine whether a stable correspondence exists between the direction of change of operating factors and the direction of change of device object state. The consistency threshold is determined based on historical fault review records, stress test records, or manually labeled samples. The response amplitude threshold is used to filter out noise responses with excessively small amplitudes. The response amplitude threshold can be determined based on monitoring accuracy and the minimum identifiable change in state parameters. The time delay window is used to accommodate the propagation delay between changes in operating factors and changes in device object state. The time delay window can be determined based on the acquisition link delay, task scheduling cycle, and log writing cycle. The above preset values ​​can be set based on the sampling capacity, historical operating records, and noise level in the current deployment environment.

[0073] After determining the candidate mapping relationship, the state response coefficient is further calibrated. Specifically, the running factor data and the device object state data are first aligned according to the sampling period, and then missing values, abnormal jump values ​​and duplicate timestamps are cleaned. After the time alignment and data cleaning are completed, a master state parameter is assigned to each device object. The master state parameter is used to characterize the minimum feasible state change of the device object during the table building stage.

[0074] Please see Figure 2As shown, for message processing nodes, the main state parameter can be selected as either the message depth to be processed or the message processing latency; for data writing nodes, the main state parameter can be selected as either the write queue length or the write response time; for risk control verification nodes, the main state parameter can be selected as either the rule processing latency or the task backlog length. Subsequently, within the calibration time window, sample segments that have reached the correlation identification starting point value due to changes in the running factor are extracted, and it is observed whether the main state parameter of the corresponding device object undergoes a response change in the same direction within the time delay window.

[0075] The correlation identification starting point value is only used to identify observable influence relationships during the table construction phase. Its value is determined jointly based on the historical fluctuation distribution of the operating factor and the upper limit of the monitoring noise. Specifically, firstly, the distribution of changes between adjacent sampling points of the operating factor is statistically analyzed within the historical time window. Samples with changes not exceeding the upper limit of the monitoring noise are removed. Then, the smallest change that can stably trigger the observation of the main state parameter response of the equipment object is selected from the remaining change samples as the correlation identification starting point value. When the proportion of samples with consistent direction reaches the correlation consistency threshold, and the average normalized change amplitude of the main state parameter reaches the response amplitude threshold, it is determined that the operating factor has an effective influence relationship on the equipment object. Afterwards, the state response coefficient is calculated based on the normalized change amplitude in the effective sample segment. The state response coefficient can be obtained by weighted averaging of local response ratios. The weights are determined based on sample completeness, time alignment, and directional consistency. To avoid amplifying calculation results from extreme samples, upper and lower cutoff boundaries can be pre-set for the local response ratio. The cutoff boundaries are determined based on the operating boundary of the equipment object and the historical safety fluctuation range.

[0076] In this embodiment, the factor object mapping table adopts a storage method with the running factor identifier as the index key. Each running factor identifier corresponds to a set of device object records. Each device object record includes at least the device object identifier and the state response coefficient. The reason for adopting this storage method is that after receiving a factor event of a certain running factor in the subsequent running phase, all affected device objects can be located directly based on the running factor identifier, without having to traverse all device objects one by one to determine the association relationship. The state propagation entry point is constrained to the scope of affected device objects, providing a directly usable front-end data structure for subsequent generation of state update events and execution of instance-level merge updates.

[0077] Step one establishes a factor object mapping table, which separates the relationship between changes in the running factor and subsequent instance state updates into a first-level propagation relationship from the running factor to the device object. Subsequently, it is no longer necessary to perform a full scan of all digital twin instances every time the running factor changes. Instead, the affected device object is located first by the running factor identifier, and then the subsequent instance object association and instance update task generation process begins. As a result, the state synchronization path changes from per-instance processing to hierarchical propagation processing, which provides a foundation for reducing retrieval overhead, reducing redundant updates, and improving state synchronization efficiency in high-concurrency scenarios.

[0078] Step 2: Establish an instance object association table to record the association relationship between each digital twin instance and the device object.

[0079] After the factor object mapping table is established, the instance object association table is further established. In this embodiment, the instance object association table is used to characterize the attribution relationship and association scope between digital twin instances and device objects, and records at least the digital twin instance identifier and the device object identifier.

[0080] In the context of financial server operation and management, a digital twin instance refers to a continuously updated virtual state carrier built around a corresponding operational goal, operational link, or operational unit, used to carry the operational state changes of a group of interrelated device objects. The device object is the basic building block of the digital twin instance, and the digital twin instance is the execution object for subsequent state merging and state updates. By pre-establishing an instance object association table, the associated digital twin instance can be directly located after the affected device object is obtained, without having to check whether each digital twin instance contains the device object, thus providing a clear entry point for the generation of subsequent instance update tasks.

[0081] In this embodiment, the division of digital twin instances can be determined based on the functional boundaries, deployment boundaries, and state update boundaries in the financial server operation and management scenario. The functional boundaries are used to limit whether the device objects within the same digital twin instance serve the same operation target or the same processing link. The deployment boundaries are used to limit whether there are stable deployment dependencies or operation dependencies between device objects. The state update boundaries are used to limit whether there are state coupling relationships between device objects that need to be updated together.

[0082] To clearly define the division of digital twin instances, instance division rules, object inclusion rules, and shared object registration rules are pre-defined during the table creation phase. Instance division rules are used to determine under what circumstances multiple device objects can be classified into the same digital twin instance; object inclusion rules are used to determine whether a certain device object should be included in a certain digital twin instance; shared object registration rules are used to handle the situation where the same device object belongs to multiple digital twin instances simultaneously. All of the above rules are determined based on the deployment list, operation topology, call link records, and monitoring access relationships, and are not generated directly by manual subjective specification.

[0083] When determining the scope of digital twin instances, candidate instance categories can be first divided according to the operational objectives in the financial server operation and management scenario. Candidate instance categories may include any one of the following: transaction entry operation instance, risk control verification operation instance, message processing operation instance, data writing operation instance, or node-level operation instance. Subsequently, based on the deployment list and operation topology, the set of device objects corresponding to each candidate instance category is extracted from the scope of device objects determined in step one. If a device object satisfies both the functional association condition and the link association condition with a candidate instance category, then the device object is included in the corresponding digital twin instance.

[0084] Functional association conditions are used to determine whether a device object undertakes processing responsibilities under the corresponding instance category, while link association conditions are used to determine whether a device object is located within the main operational link of the corresponding instance category. To prevent uncontrolled expansion of the instance scope, a maximum link level and a minimum inclusion association degree can be pre-defined. The maximum link level limits the maximum number of dependency layers extending outward from the core device object, while the minimum inclusion association degree filters out edge device objects that have only weak dependencies but will not form stable linkages. The maximum link level is determined based on the operational topology depth and deployment structure, while the minimum inclusion association degree is determined based on the link occurrence frequency and operational linkage frequency in historical call records.

[0085] For the instance object association table, this embodiment uses a core device object determination plus association expansion method to establish digital twin instances. Specifically, one or more core device objects are first determined for each candidate instance category. The core device object refers to the device object that undertakes the main processing responsibilities in the candidate instance category and can directly represent the running status of the instance. For the transaction entry running instance, the core device object can be a message processing node; for the risk control verification running instance, the core device object can be a risk control verification node; for the data writing running instance, the core device object can be a data writing node. After determining the core device object, it is then expanded to other device objects with stable dependencies on the core device object according to the object inclusion rules, until the maximum link level is reached or the minimum inclusion association degree is no longer met. The reason for adopting this method is that the digital twin instance first needs to be established around a clear operation center, and then gradually absorb device objects that will form a stable linkage with the operation center, so that the instance object association table can cover the real operation link without causing the subsequent update scope to get out of control due to boundless expansion.

[0086] When registering associations, a unique digital twin instance identifier is assigned to each digital twin instance, and an association record of "Digital Twin Instance Identifier - Device Object Identifier" is written to the instance object association table. If a device object participates in multiple operational targets or multiple operational links simultaneously, multiple association records are allowed for that device object. That is, the same device object can belong to multiple digital twin instances at the same time. In this case, the device object is no longer split and copied, but its shared relationship is preserved through multiple association records. The reason for adopting the shared registration method is that in the scenario of financial server operation and management, message processing nodes, cache processing nodes, or network access nodes often serve multiple operational links simultaneously. If they are forcibly restricted to belonging to only one digital twin instance, it will lead to inconsistencies between subsequent state propagation and actual operational associations. To ensure the executability of shared registration, an object role field and an effective time field can be added to the association record. The object role field is used to distinguish between core device objects and extended device objects, and the effective time field is used to mark the activation time of the association, thereby supporting the adjustment of associations after subsequent deployment changes.

[0087] In addition to recording the association between digital twin instance identifiers and device object identifiers, the instance object association table can further record the mapping relationship of the storage location of the corresponding state parameters of each device object in the state vector. The storage location mapping relationship is used to characterize the position arrangement of the state parameters of a certain device object in the state vector of the corresponding digital twin instance. In specific implementation, after allocating the state parameter range for the digital twin instance, a unique storage location is assigned to the state parameters corresponding to each device object according to a pre-defined arrangement rule, and the digital twin instance identifier, device object identifier, state parameter identifier, and storage location are written into the instance object association table. The arrangement rule can be arranged in the order of device object identifiers or in the order of a combination of device object type and state parameter type, as long as it remains unique and stable in the current deployment environment.

[0088] In this embodiment, after the instance object association table is established, the state parameter range corresponding to the digital twin instance can also be registered synchronously. The state parameter range is used to characterize the operational state content that the digital twin instance needs to maintain during subsequent state updates. The state parameter range can be composed of the main state parameters of the associated device objects, or aggregated state parameters reflecting the overall operation of the instance can be added. For transaction entry operation instances, access queuing status, processing load status, and communication latency status can be registered; for risk control verification operation instances, rule processing status and task backlog status can be registered; for data writing operation instances, write queuing status and write response status can be registered. The reason for adopting this registration method is that when constructing the state vector and performing state updates, the corresponding state parameter range can be directly extracted based on the digital twin instance identifier, avoiding temporary splicing of state items during the operation phase.

[0089] Step two establishes an instance object association table, forming a second-layer propagation relationship from device objects to digital twin instances. After step one has completed the directional positioning of running factors to device objects, step two further constrains the affected device objects to the scope of associated digital twin instances. This provides a direct basis for subsequently writing multiple state update events corresponding to the same digital twin instance into the instance buffer and generating instance update tasks. Compared with the method of searching one by one for all digital twin instances, establishing an instance object association table first can reduce the subsequent instance matching scope and keep the path for shared device objects to participate in the updates of multiple digital twin instances clear, thus providing a foundation for state merging updates in high-concurrency scenarios.

[0090] Step 3: Collect data streams in real time. When the change in the value of any running factor reaches the corresponding trigger threshold, generate a factor event including the running factor identifier and the change in value and write it to the event queue.

[0091] After establishing the factor object mapping table and instance object association table, the next step is to perform data stream acquisition and factor event generation. This step converts the continuously arriving operational monitoring data into standard event units that can participate in subsequent state propagation processing. A data stream refers to a sequence of operational factor values ​​received continuously in chronological order of sampling time. Each data point includes at least the operational factor identifier, sampled value, and sampling time.

[0092] Factor events are structured records generated by changes in operating factors, used to characterize a valid change in an operating factor at a certain moment that meets the triggering conditions. The event queue is used to temporarily store factor events that have been generated but have not yet entered the subsequent propagation process, thereby decoupling the operating factor acquisition process from the subsequent state update process. By first converting changes in operating factors into factor events and then writing the factor events into the event queue, continuous data stream processing can be transformed into discrete event processing, providing a unified entry point for subsequent event-driven state propagation.

[0093] In this embodiment, the data stream collection object is consistent with the range of operating factors determined in step one. Each operating factor is bound to a unique operating factor identifier, sampling period, data unit, and valid value range. To ensure that the subsequent calculation of numerical change has a unified standard, the collected operating factor data is first subjected to standardized access processing. Standardized access processing includes timestamp verification, data unit verification, and value validity verification. Timestamp verification is used to ensure that the same operating factor data is accessed in chronological order. Data unit verification is used to ensure that the sampled values ​​of the same operating factor use a unified unit across different access sources. Value validity verification is used to determine whether the sampled value falls within the valid value range corresponding to the operating factor. If a sampled value lacks a timestamp, has a mismatched unit, or exceeds the valid value range, the sampled value is marked as invalid and discarded, and does not participate in the calculation of numerical change in the current step. Through this processing, it can be ensured that the generation of factor events is based on data that is chronologically ordered, has a unified unit, and is numerically valid.

[0094] To more accurately calculate numerical changes, in this embodiment, a sampling baseline value and a trigger baseline value can be maintained for each operating factor. The sampling baseline value is used to record the most recent valid sampled value and maintain sampling continuity. The trigger baseline value is used to record the reference value corresponding to the most recent factor generation event and serves as the trigger judgment baseline. The sources of the sampling baseline value and the trigger baseline value are determined according to the type of operating factor. For operating factors that change continuously, the sampling baseline value is the sampled value at the previous valid sampling time, and the trigger baseline value is the sampled value corresponding to the most recent trigger event or the baseline value at system initialization. For operating factors that change intermittently, the sampling baseline value is the most recent valid sampled value, and the trigger baseline value is the valid sampled value at the most recent trigger event. For operating factors that change configurations, the sampling baseline value is the most recent configuration snapshot value, and the trigger baseline value is the configuration value corresponding to the most recent trigger event.

[0095] The numerical change is determined based on the difference or degree of difference between the new sampled value and the trigger baseline value. If the operating factor is a numerical monitoring quantity, the numerical change is the result of subtracting the trigger baseline value from the new sampled value. If the operating factor is a status monitoring quantity, the status value is first mapped to a predefined status level value, and then the numerical change is determined based on the difference in status level values. If the operating factor is a configuration change monitoring quantity, whether a configuration item has changed and the number of changed items are used as the basis for determining the numerical change. In this way, different types of operating factors can be converted into a uniform and comparable numerical change.

[0096] Secondly, in this embodiment, a trigger threshold can be pre-set for each operating factor. The trigger threshold is used to determine whether a change in a certain operating factor meets the triggering condition for entering subsequent state propagation processing. The trigger threshold is different from the association identification starting value in step one. The association identification starting value is only used to identify whether there is a stable influence relationship between the operating factor and the device object during the table building stage, while the trigger threshold is used during the operation stage to determine whether the current sampling change needs to generate a factor event.

[0097] To avoid mixing the two preset values, the associated identification starting value is only used in the table building phase and does not participate in the event triggering judgment of the current step. The trigger threshold can be the initial configuration value in the deployment phase or the result determined dynamically. When the initial configuration value is used, the trigger threshold is jointly determined based on the historical fluctuation range, monitoring accuracy, and operation management requirements of the operating factor. In this embodiment, the historical change distribution of the operating factor can be statistically analyzed within a preset historical time window, and then the noise upper limit corresponding to the monitoring accuracy can be read. Combined with the minimum alarm granularity allowed by operation management, the smallest change that is greater than the noise upper limit and meets the minimum alarm granularity requirement can be selected as the initial trigger threshold. When the result is determined dynamically, the trigger threshold is corrected based on the fluctuation statistics within the historical time window. Regardless of which method is used, the trigger threshold is stored in a one-to-one correspondence with the operating factor identifier to ensure that the subsequent triggering judgment has a definite basis.

[0098] In this embodiment, the trigger threshold can be dynamically determined based on the volatility statistics of the corresponding operating factor within a historical time window. The volatility statistics are used to characterize the normal fluctuation range of the operating factor over a period of time, and can be at least one of standard deviation, mean absolute deviation, or volatility. In specific implementation, firstly, the effective sampling sequence of the corresponding operating factor is extracted within a preset historical time window, then the volatility statistics corresponding to the effective sampling sequence are calculated, and finally, the trigger threshold is determined according to a pre-set threshold mapping rule.

[0099] The threshold mapping rule can adopt a positive correlation, that is, when the fluctuation statistic increases, the trigger threshold increases accordingly; when the fluctuation statistic decreases, the trigger threshold decreases accordingly. The reason for adopting this method is that the normal fluctuation levels of different operating factors are different. By keeping the trigger threshold positively correlated with the fluctuation statistic, the trigger threshold can be adjusted according to the changes in the historical fluctuation characteristics of the operating factor, thereby reducing the probability of false triggering of short-term noise fluctuations.

[0100] When determining the trigger, the system first obtains a new sampled value of a certain operating factor and its corresponding trigger baseline value, calculates the corresponding numerical change, and then compares the numerical change with the trigger threshold corresponding to the operating factor. If the absolute value of the numerical change does not reach the trigger threshold, the change is determined to be insufficient to cause subsequent state propagation, no factor event is generated, and only the sampled baseline value is updated while the current trigger baseline value remains unchanged. If the absolute value of the numerical change reaches the trigger threshold, the change is determined to be a valid change, and the system enters the factor event generation process.

[0101] The reason for using a trigger threshold to filter out minor fluctuations is that running factor data usually fluctuates continuously. If every small change enters the subsequent processing, it will cause the number of events to increase rapidly, thereby increasing the pressure on subsequent state propagation and instance updates. By introducing a trigger threshold at the current step, noise fluctuations and invalid fluctuations can be filtered out at the entry point of running factor collection, while retaining the cumulative triggering capability of continuous small changes.

[0102] In this embodiment, when the numerical change of the running factor reaches the trigger threshold, a factor event is generated. The factor event includes at least the running factor identifier, the numerical change, and the event timestamp. In order to ensure that the subsequent event processing can maintain order and traceability, the event sequence number, event source, and trigger baseline value version information can also be further registered in the factor event.

[0103] The running factor identifier is used to find the corresponding record in the factor object mapping table in subsequent steps; the numerical change is used to calculate the state increment in subsequent steps in combination with the state response coefficient; the event timestamp is used to ensure that multiple factor events of the same running factor can enter the subsequent processing in the order of occurrence. After the factor event is generated, the new sampled value that triggered this event is written back as the new triggering reference value, and the sampled reference value is updated synchronously to ensure that the change of the running factor in the next run is calculated based on the reference value after the most recent confirmed effective change.

[0104] In this embodiment, the event queue is used to receive and cache the generated factor events. Each queue element in the event queue corresponds to a factor event. The elements in the queue are arranged in chronological order of the events. In order to ensure that the event writing process is smooth, the event queue has at least a write entry, a read exit, and a queue length statistics function. The write entry is used to receive newly generated factor events, the read exit is used for subsequent processing steps to retrieve factor events, and the queue length statistics function is used to represent the number of events to be processed, providing a basis for subsequent event merging window adjustments.

[0105] When a factor event is written to the event queue, the event timestamp of the currently generated event is first compared with the event timestamp of the most recently written event for that factor. If the event timestamp of the currently generated event is earlier than the event timestamp of the most recently written event, the corresponding event is marked as an out-of-order event and is reordered or discarded according to the preset out-of-order processing rules. If the event timestamp of the currently generated event is not earlier than the event timestamp of the most recently written event, it is directly written to the event queue to ensure that the factor events received in subsequent steps have a processable order in the time dimension.

[0106] To improve the parallelism of the factor event processing phase, the event queue is preferably set up as multiple sub-event queues. Each sub-event queue is used to cache a portion of factor events, and the corresponding processing thread performs the retrieval processing. In specific implementation, the queue allocation result is first calculated based on the running factor identifier, and then the currently generated factor event is written to the corresponding target sub-event queue. The queue allocation result can be determined by the running factor identifier and the preset allocation rule. The preset allocation rule preferably adopts a hash allocation method based on the running factor identifier, so that factor events corresponding to the same running factor identifier are written to the same sub-event queue.

[0107] Since multiple factor events of the same running factor usually need to maintain their time order in subsequent processing, writing them to different sub-event queues can easily increase the overhead of subsequent event reordering. Therefore, after the queue writing is completed, multiple processing threads retrieve factor events from multiple sub-event queues in parallel for processing. This changes the factor event processing process from single-queue serial processing to multi-queue parallel processing. In scenarios with a large number of running factors and a high event generation frequency, the processing pressure of a single event queue can be reduced.

[0108] To reduce the number of factor events caused by continuous small fluctuations within a short period of time, in this embodiment, it is preferable to perform a merging process on multiple factor events of the same running factor before the event enters subsequent processing. Specifically, firstly, a corresponding event merging window is maintained for each running factor, and multiple factor events corresponding to the running factor are detected within the same event merging window. If multiple factor events are detected, the numerical changes in the multiple factor events are accumulated and merged according to the event time sequence, and a merged factor event is generated. For factor events corresponding to different running factors, the merging process is performed independently, without cross-running factor mixing and merging.

[0109] To adapt the event merging window to the current processing load, its length can be dynamically adjusted based on the depth of the event queue and the event processing rate of the processing thread. When the depth of the event queue increases and the event processing rate of the processing thread is lower than the current event entry rate, the event merging window length is increased; when the depth of the event queue decreases and the event processing rate of the processing thread is higher than the current event entry rate, the event merging window length is decreased. In this way, the number of factor events entering the subsequent state propagation process can be reduced while maintaining the time order of events of the same running factor.

[0110] By executing step three, continuously running factor data is first converted into factor events with a unified structure and clear boundaries before entering the subsequent state propagation process. The significance of this approach is that subsequent steps no longer directly judge each item in the original monitoring data stream, but instead process factor events that have already undergone threshold filtering and structured encapsulation. This reduces the interference of raw data fluctuations on the subsequent state synchronization process. Simultaneously, the event queue separates the running factor acquisition process from the subsequent state propagation process, allowing changes in running factors to first enter a buffer and wait before sequentially participating in the subsequent device object location and instance update task generation processes, providing a foundation for stable state synchronization in high-concurrency scenarios.

[0111] Step 4: Retrieve factor events from the event queue, determine the target device object based on the factor object mapping table, calculate the state increment based on the state response coefficient and the numerical change, and generate a state update event.

[0112] After factor events are written to the event queue, the steps of factor event parsing, target device object determination, and state update event generation are further executed. This step is used to continue to propagate changes at the operational factor level to the device object level and form intermediate event results that can enter subsequent instance-level merging processing. A factor event represents a valid change in an operational factor that meets the triggering conditions at a certain moment. The factor object mapping table represents the calibrated influence relationship between operational factors and device objects. A state update event represents the state change result that a device object should undergo under the action of the current factor event. By converting factor events into state update events, the changes in operational factors and subsequent state updates of digital twin instances can be further refined into mergeable change units at the device object level, thereby providing a unified entry point for the subsequent aggregation of multiple state changes by digital twin instance.

[0113] In this embodiment, factor events in the event queue enter the processing procedure in chronological order. When a factor event is retrieved, the running factor identifier, numerical change, and event timestamp are read first. Then, the corresponding mapping record set is searched in the factor object mapping table based on the running factor identifier. After retrieving the factor event, an event validity check is performed. The event validity check includes running factor identifier existence verification, numerical change validity verification, and event chronological order verification. The running factor identifier existence verification is used to determine whether there is a mapping record corresponding to the running factor identifier in the factor object mapping table. The numerical change validity verification is used to determine whether the numerical change still falls within the allowed calculation range of the corresponding running factor. The event chronological order verification is used to determine whether the timestamp of the current factor event of the same running factor is later than or equal to the timestamp of the factor event that has completed the propagation process. If the current factor event fails any of the above checks, it will not enter the state increment calculation process of the current step. This processing method can prevent factor events without mapping sources, with abnormal values, or with reversed time sequences from entering the subsequent propagation path.

[0114] In this embodiment, each mapping record in the factor object mapping table includes at least the running factor identifier, the device object identifier, and the state response coefficient. Therefore, after completing the search based on the running factor identifier, the range of device objects affected by the current factor event can be directly obtained, and the found device object is the target device object. Compared with the method of traversing all device objects one by one and then determining whether they are affected, searching the mapping record based on the running factor identifier first can limit the processing scope of the current step to the mapping record set, reducing invalid matches from the propagation entry point.

[0115] To ensure the executable nature of the target device object determination result, after reading the mapping record set, it is necessary to further check the validity period status and device object availability status of each mapping record. If a mapping record has expired, or the corresponding device object is in a disabled, out-of-management, or not included in the current operation and management scope, then the mapping record is skipped, and its corresponding device object is not used as the target device object of the current factor event. After the above processing, the remaining device objects constitute the target device object set corresponding to the current factor event.

[0116] In this embodiment, after determining the target device object, the state increment is further calculated based on the state response coefficient and the numerical change in the factor event. The state increment refers to the amount of state change that the target device object's operating state should increase or decrease during this propagation process after the current factor event acts on it. Since the state response coefficient has been established according to a unified calibration standard in step one, the current step maintains the same standard as the table building stage when calculating the state increment. If the operating factor uses a normalized change in the state response coefficient calibration during the table building stage, the current step first converts the numerical change in the factor event into a normalized change consistent with the table building stage, and then determines the state increment in combination with the state response coefficient. If the operating factor uses a difference change under a unified dimension to participate in the state response coefficient calibration during the table building stage, the current step directly uses the current numerical change and the state response coefficient to calculate the state increment.

[0117] To calculate the state increment more accurately, this embodiment performs state increment calculation for each mapping record. Specifically, the numerical change is first read based on the current factor event, and then the state response coefficient corresponding to the target device object is read. The state increment is determined based on the directional and amplitude relationship between the two. In the minimum implementation, the state increment is determined by multiplying the state response coefficient by the numerical change. If the state response coefficient is positive, the state increment is in the same direction as the numerical change; if the state response coefficient is negative, the state increment is in the opposite direction to the numerical change. If the running factor uses normalized change to participate in the state response coefficient calibration during the table building stage, the current numerical change is first converted to the same normalized caliber as during the table building stage, and then the state increment is calculated.

[0118] To prevent instantaneous abnormal fluctuations from causing a single state increment to exceed the device object's operational boundary, a state increment truncation boundary is pre-set before calculating the state increment. This truncation boundary is determined based on the safe fluctuation range of the device object's corresponding master state parameters, the upper bound of normal changes within the most recent historical window, and the maximum allowable single update amplitude in the current deployment environment. In this embodiment, the state increment truncation boundary can first determine the theoretically allowable increment range based on the safe fluctuation range of the device object's corresponding master state parameters, then statistically analyze the upper bound of the single change distribution of the master state parameters within the most recent historical window, and finally compare the theoretically allowable increment range with the upper bound of the single change distribution, taking the smaller amplitude boundary as the state increment truncation boundary. If the calculated state increment exceeds the state increment truncation boundary, the state increment is truncated to the corresponding boundary value; if it does not exceed the state increment truncation boundary, the original calculation result is retained. This approach is adopted because the state response coefficient reflects a stable interaction relationship, while instantaneous peaks or sampling jitter may still occur during operation. By adding a state increment truncation boundary, the state increment output in the current step can be kept within the updateable range.

[0119] In this embodiment, in order to ensure that different types of device objects can be processed uniformly in the current step, the state increment preferentially adopts the standard state change caliber relative to the main state parameters of the device object. For message processing nodes, the state increment can characterize the degree of change in the depth of the message to be processed or the message processing latency; for data writing nodes, the state increment can characterize the degree of change in the write queue length or the write response time; for risk control verification nodes, the state increment can characterize the degree of change in the rule processing latency or the task backlog length.

[0120] The current step does not directly modify the actual state parameter values ​​of the target device object, but only outputs the state increment result corresponding to the current factor event. Since multiple state update events for different device objects or the same device object may be received in a short period of time under the same digital twin instance, if the state parameters are directly written back in the current step, the subsequent instance-level merging will lose its meaning. Therefore, the output of the current step is limited to state update events, and the instance state is not written back.

[0121] After obtaining the state increment, a state update event is further generated. This event characterizes a state change to be propagated for a specific target device object under the influence of the current factor event. The state update event includes at least the device object identifier, the state increment, and an event timestamp. To ensure traceability of the state increment source during subsequent instance-level merging, the running factor identifier and state response coefficient version information can be further recorded in the state update event. The device object identifier is used to locate the associated digital twin instance based on the instance object association table in subsequent steps. The state increment is used to merge multiple change results within the same digital twin instance in subsequent steps. The event timestamp ensures that multiple state update events maintain a consistent time order during merging. With this event encapsulation method, the output of the current step is no longer the original running factor data, nor is it an abstract influence relationship that has not yet been implemented. Instead, it is a standard intermediate event that has been bound to a specific device object and can directly participate in subsequent merging processing.

[0122] Step four further transforms factor events into state update events at the device object level, forming the actual propagation result from the running factor to the device object. The significance of this processing is that the current step no longer performs a full judgment on all device objects, nor does it directly modify the state of the digital twin instance at the current stage. Instead, it first completes targeted matching based on the factor object mapping table, and then outputs state update events that can enter subsequent merging processing. Thus, the running factor change is decomposed into multiple state change units that can be independently cached and merged by instance, providing direct input for the next step to aggregate multiple state update events by digital twin instance and generate instance update tasks. This provides a foundation for reducing repeated write-backs and improving state synchronization efficiency in high-concurrency scenarios.

[0123] Step 5: Determine the target digital twin instance based on the instance object association table, write multiple state update events corresponding to the same target digital twin instance into the instance buffer, and accumulate and merge the state increments for the same device object to generate an instance update task.

[0124] After obtaining the state update event in step four, the next steps are to determine the target digital twin instance, collect events within the instance, and generate instance update tasks. The purpose of this step is to continue to converge the state changes that have been located at the device object level to the digital twin instance level, so that the scattered state update events are collected and merged according to the digital twin instance before entering the final state write-back.

[0125] A state update event reflects a state change to be propagated for a device object under the influence of the current factor event. The instance object association table records the association between digital twin instances and device objects. The instance buffer is used to temporarily store state update events belonging to the same digital twin instance within the current processing cycle. By introducing the instance buffer and performing state increment merging within the instance before generating the instance update task, the previously scattered update process that might have been triggered multiple times for the same digital twin instance can be transformed into a centralized update process after aggregation, providing a prerequisite for reducing repeated write-backs in the future.

[0126] In this embodiment, the status update events output in step four are processed one by one. Each status update event includes at least a device object identifier, a status increment, and an event timestamp. Based on the device object identifier, the associated record is searched in the instance object association table to obtain one or more digital twin instance identifiers corresponding to the device object. The found digital twin instance is then the target digital twin instance corresponding to the current status update event. If the same device object is associated with only one digital twin instance, the current status update event is only written to the instance buffer entry corresponding to that digital twin instance. If the same device object is associated with multiple digital twin instances, the current status update event is written to the instance buffer entries corresponding to each target digital twin instance.

[0127] In financial server operation and management scenarios, some device objects may participate in multiple operation links at the same time. For example, a message processing node may participate in both the transaction entry operation instance and the risk control verification operation instance. If only a single ownership relationship is retained in the current step, the subsequent state changes of the digital twin instance will not be able to fully reflect the real operation association. Therefore, the multiple instance ownership relationships registered in the instance object association table need to be fully retained in the current step and participate in the subsequent aggregation.

[0128] For writing to the instance buffer, this embodiment constructs the instance buffer as a temporary storage structure with the digital twin instance identifier as the key. Each digital twin instance identifier corresponds to a buffer entry, and each buffer entry records at least the digital twin instance identifier and a set of temporary device object records. Each record in the set of temporary device object records includes at least the device object identifier, the state increment, and the most recent event timestamp. If a digital twin instance receives a state update event for the first time in the current processing cycle, a new buffer entry is first created based on the digital twin instance identifier, and then the current state update event is written to the buffer entry. If a buffer entry for the corresponding digital twin instance already exists in the instance buffer, no new entry is created; instead, the current state update event is written to the existing buffer entry. By using the digital twin instance identifier as the unique aggregation key and maintaining a set of temporary device object records within the buffer entry, it can be ensured that all subsequent state update events generated for the same digital twin instance first enter the same aggregation unit, providing a unified entry point for instance-level merging.

[0129] To improve the processing efficiency when multiple state update events are concurrently written to the instance buffer, the instance buffer can be divided into multiple buffer partitions according to the allocation result of the digital twin instance identifier. In specific implementation, the partition result is first calculated based on the digital twin instance identifier, and then the buffer entry of the corresponding digital twin instance is written to the target buffer partition. The partition result is preferably determined by a hash allocation method based on the digital twin instance identifier, so that the same digital twin instance identifier is always written to the same buffer partition. Each buffer partition is equipped with an independent concurrency control unit, and the corresponding concurrency control unit manages the writing, updating and reading process of the buffer entries in the buffer partition. The concurrency control unit can be implemented using mutual exclusion control, single write entry, or comparison-based update, as long as the orderliness of the update process of the buffer entries in the same buffer partition can be guaranteed. The reason for using buffer partitions and independent concurrency control units is that the state update events corresponding to different digital twin instances are independent of each other in most cases. By dividing the instance buffer into multiple buffer partitions, parallel writing of different buffer partitions can be supported, reducing concurrency contention on a single buffer.

[0130] In this embodiment, after writing to the instance buffer, it is also necessary to perform state increment merging on multiple state update events for the same device object within the same digital twin instance. Since the same device object under the same digital twin instance may receive multiple state update events continuously in a short period of time, these state update events may come from continuous factor events of the same running factor, or from the combined effect of different running factors on the same device object in a close time. If these state update events are not merged in the current step, but are all retained as is in the subsequent state write-back stage, the same device object in the same digital twin instance will be repeatedly updated, increasing the number of state vector reads and write-backs. Therefore, merging multiple state update events within the same digital twin instance and for the same device object in the current step is one of the key processing paths in the present invention.

[0131] To ensure the feasibility of state increment merging, within each buffer entry, the device object identifier is used as the secondary aggregation identifier. When writing a new state update event, it is first determined whether a temporary record corresponding to the same device object identifier already exists in the current buffer entry. If it does not exist, a new temporary record for the device object is directly created, and the current state increment and event timestamp are written. If it already exists, the event timestamp of the current state update event is compared with the most recent event timestamp in the existing temporary record.

[0132] If the current event timestamp is not earlier than the existing most recent event timestamp, the current state increment and the existing state increment are accumulated in chronological order, and the most recent event timestamp is updated to the current event timestamp. If the current event timestamp is earlier than the existing most recent event timestamp, the system is reordered or discarded according to the preset out-of-order processing rules. The reason for using chronological accumulation is that the state increment is essentially the propagation result of changes in the running factor at the device object level. The accumulation order should be consistent with the order in which the events occur to avoid distortion of the state change trajectory in the instance update task due to out-of-order writing.

[0133] In this embodiment, to prevent a single digital twin instance from accumulating too many state update events during the current processing cycle and affecting subsequent instance update tasks, an instance aggregation termination condition can be preset. The instance aggregation termination condition is used to determine when to stop writing state update events to the current buffer entry and convert the current buffer entry into an instance update task. The instance aggregation termination condition can be any one or a combination of the following: processing cycle termination condition, event count reaching the entry limit condition, or instance waiting time reaching the time limit condition.

[0134] The processing cycle end condition is used to generate instance update tasks uniformly after the status update events are processed within the current processing cycle; the event quantity reaching the item limit condition is used to trigger generation in advance when a single digital twin instance receives too many status update events; the instance waiting time reaching the time limit condition is used to avoid a digital twin instance being in the aggregation state for a long time and delaying the entry into the subsequent update process. Each aggregation end condition is set according to the maximum acceptable synchronization latency, average event density of instances, and buffer resource size in the operation and management scenario. By setting the instance aggregation end condition, the instance buffer can complete the necessary event merging without delaying subsequent status updates due to waiting indefinitely for more events.

[0135] In this embodiment, the processing cycle end condition can be calculated based on the maximum acceptable synchronization latency, the event number reaching the entry limit condition can be determined based on the instance average event density and instance buffer capacity, and the instance waiting time reaching the time limit condition can be obtained by subtracting the current step's average processing time from the maximum acceptable synchronization latency; when any collection end condition is met, the current buffer entry is triggered to be converted into an instance update task.

[0136] After the instance aggregation termination condition is met, an instance update task is generated. An instance update task is a centralized update unit for a specific target digital twin instance, used to carry all state change results to be written back for that digital twin instance within the current processing cycle. An instance update task includes at least a digital twin instance identifier, a set of device object change records, and a task generation time. Each record in the device object change record set includes at least a device object identifier, an accumulated state increment, and a recent event timestamp. If a digital twin instance involves multiple device objects within the current processing cycle, the instance update task contains multiple device object change records; if it involves only one device object, the instance update task contains only one device object change record. After generating the instance update task in this step, the previously scattered multiple state update events are transformed into a unified update entry point for the target digital twin instance, allowing the next step to directly read and execute state vector updates.

[0137] Step five further converges the state update events at the device object level into instance update tasks at the digital twin instance level, forming a collection and merging path from device objects to digital twin instances. The significance of this approach is that the state synchronization process no longer uses the method of multiple scattered write-backs for the same digital twin instance. Instead, it first completes instance-level collection and device object-level accumulation in the instance buffer, and then outputs the merging result as the instance update task. As a result, the subsequent state update stage no longer faces a large number of scattered state update events, but rather a centralized update unit that has already completed the merging within the instance. This provides a foundation for the next step of performing atomic updates of the state vector, reducing repeated write-backs, and improving the efficiency of concurrent state synchronization.

[0138] Step 6: Perform an atomic update on the state vector of the target digital twin instance based on the instance update task to obtain the updated state vector.

[0139] After the instance update task has been generated in step five, the state vector update step is further executed. The purpose of this step is to write the state change results that have been collected and merged according to the digital twin instance in the instance update task into the state vector of the corresponding target digital twin instance at once, thereby completing the state synchronization of the digital twin instance in the current processing cycle.

[0140] A state vector is a structured data carrier that carries the current operating state of a digital twin instance, including at least the current values ​​of the state parameters of each device object corresponding to the digital twin instance. Atomic update means that the update results of multiple state parameters for the same target digital twin instance take effect as a whole in the same write-back operation, or they do not take effect as a whole if the overall write-back is not completed. It is not allowed to complete only part of the state parameter write-back while other state parameters are not written back. The version identifier is used to characterize the update order of the state vector of the digital twin instance. It changes synchronously after each valid update of the state vector so that subsequent queries and concurrent update processes can identify whether the current state is the latest state. By adopting the instance update task-driven atomic update method in the current step, the multiple state change results that have been collected in the previous step can be updated in a centralized write-back, avoiding multiple scattered write-backs for the same digital twin instance.

[0141] In this embodiment, each instance update task includes at least a target digital twin instance identifier, a set of device object change records, and a task generation time. Each record in the set of device object change records includes at least a device object identifier, an accumulated state increment, and a recent event timestamp. The target digital twin instance identifier is used to locate the state vector that needs to be updated, the set of device object change records is used to determine the range of state parameters that need to be updated, and the task generation time is used to identify the generation time of the instance update task. The current step reads the current state vector and current version identifier of the corresponding digital twin instance based on the target digital twin instance identifier in the instance update task.

[0142] To ensure successful subsequent state write-back, the arrangement of state parameters in the state vector can be pre-fixed during deployment. For a digital twin instance, at least one storage location for corresponding state parameters should be reserved in the state vector for each associated device object. The state parameter storage locations can be arranged in order of device object identifier or in a combination of device object type and parameter type, as long as a unique and stable mapping relationship is maintained within the current deployment environment. After the instance update task enters this step, it needs to directly locate the state parameters to be updated. If the arrangement of state parameters changes frequently during operation, it may increase the location cost and affect the executability of the atomic update process.

[0143] The current step first establishes the set of state parameters to be written back corresponding to this update. Specifically, for each device object change record in the instance update task, the range of state parameters of the device object in the current digital twin instance is first determined based on the device object identifier, and then the current value of the corresponding state parameter is read from the current state vector. The method for determining the range of device object state parameters is consistent with the instance division criteria in the previous steps. Each device object corresponds to at least one main state parameter, which is used to carry over the state increment calculated in the previous steps.

[0144] In the implementation that uses an instance object association table to record the storage location mapping relationship, the current step first searches the instance object association table for the storage location of the corresponding state parameter of the device object in the current digital twin instance state vector based on the device object identifier in the instance update task. After finding the storage location, the current value of the state parameter is read from the corresponding storage location in the current state vector, and the state increment in the instance update task is added to the current value of the state parameter to obtain the updated state parameter value. If the instance update task contains multiple device object change records, their respective storage locations are searched, forming multiple updated state parameter values ​​to be written back in this instance. In this way, the device object change records in the instance update task can be directly associated with specific storage locations in the state vector, thus giving the atomic update process a clear location path.

[0145] In other implementations, multiple auxiliary state parameters can be extended based on the main state parameters, but the current steps still use the state increment in the instance update task as the unified write-back basis. The main state parameters constitute the minimum update scope of the current embodiment, while the auxiliary state parameters are used to refine the state expression in extended implementations. They do not affect the basic processing path of the current embodiment, which uses the main state parameters to complete the state vector update. If a device object change record in the instance update task corresponds to a device object that is no longer within the association range of the current digital twin instance, then the state write-back for that device object is not performed. Instead, the record is marked as invalid and removed from the set of state parameters to be written back. This process ensures that state changes in the instance update task only affect the range of state parameters actually maintained by the current digital twin instance.

[0146] After determining the set of state parameters to be written back, the updated state parameter values ​​are further calculated. During calculation, the current value of the state parameter corresponding to a specific device object is first read, and then the state increment from the device object's change record is added to the current value to obtain the updated state parameter value. If a device object corresponds to multiple state parameters in the current digital twin instance, the state increment is first allocated to the corresponding state parameters according to the parameter allocation rules pre-set during the deployment phase, and then the updated values ​​of each state parameter are obtained separately. The parameter allocation rules are used to limit how the state increment acts on multiple state parameters. The basis for setting these rules is the device object type, the meaning of the state parameters, and the state expression requirements under the operating scenario. For example, for a message processing node, the state increment can directly act on the primary state parameter of the message depth to be processed; for a risk control verification node, the state increment can act on the primary state parameter of the rule processing latency; for a device object that maintains both primary and auxiliary state parameters, the state increment can first be applied to the primary state parameter, and then the auxiliary state parameter can be corrected according to a pre-set proportional relationship.

[0147] To prevent a single instance update task from causing the status parameter to exceed the operating boundary, a status parameter update boundary is pre-set when calculating the updated status parameter value. The status parameter update boundary is used to limit the maximum allowable update range of a certain status parameter in a single write-back. The status parameter update boundary is determined jointly based on the monitoring value boundary corresponding to the status parameter, the historical safe operating range, and the allowable update amplitude in the current deployment environment. In this embodiment, the status parameter update boundary can first read the allowable upper and lower limits of the monitoring value corresponding to the status parameter, then calculate the upper limit of the distribution of the single update amount of the status parameter within the historical safe operating range, and then compare the maximum updatable amplitude corresponding to the allowable upper and lower limits with the upper limit of the single update amount distribution, and take the smaller value as the status parameter update boundary.

[0148] If the updated result of a certain state parameter exceeds the state parameter update boundary, the updated value of the state parameter is truncated to the corresponding boundary; if it does not exceed the state parameter update boundary, the original updated value is retained. The reason for this approach is that although the previous steps have already truncated the state increment, when multiple device object change records are applied to the same digital twin instance at the same time, individual state parameters may still cross the safety range due to cumulative write-back. By further limiting the state parameter update boundary in the current step, the state vector write-back result can be kept within a range that is interpretable, demonstrable, and can continue to participate in subsequent processing.

[0149] In this embodiment, after calculating the update values ​​of all state parameters to be written back, an atomic update is performed. The atomic update is achieved by first forming a complete new state vector copy in memory, which includes all updated state parameter values ​​involved in this instance update task as well as the remaining state parameter values ​​that have not been modified by this task; then, the original state vector is replaced by the new state vector copy in a single write-back operation.

[0150] If the current deployment environment uses a transactional storage mechanism, the state parameter values ​​can be written back and the version identifier updated within the same transaction. If the current deployment environment uses a shared memory approach, the state vector can be replaced all at once through mutual exclusion control, a single write entry, or a comparison-and-replace approach. Regardless of the specific implementation, this step requires that all state parameter update results corresponding to the same instance update task take effect as a whole in the same update action, and it is not allowed to write back a portion of the state parameters first and then postpone writing back the rest.

[0151] In this embodiment, after the atomic update of the state vector is completed, the version identifier is updated synchronously. The version identifier can be generated using a monotonically changing identifier value. The version identifier can be an incrementing integer or an ordered identifier value generated in chronological order, as long as the update order is distinguishable within the same digital twin instance. In this embodiment, the former is preferred. Specifically, the current version identifier is read synchronously when reading the current state vector. After the atomic update is completed, the version identifier is updated to the next identifier value corresponding to the current version identifier, and the updated version identifier and the updated state vector are written together.

[0152] Since state vector changes not only require numerical state synchronization, but also need to retain the position of this state synchronization in chronological order, so that subsequent queries, cache refreshes and concurrent updates can identify whether the current state has been overwritten by a new instance update task. If the state vector is written back but the version identifier is not updated synchronously, the subsequent processing cannot accurately distinguish whether the state is the latest result.

[0153] In the current step, since the version identifier write-back and the state vector write-back maintain the same commit boundary, the version identifier is only updated when the state vector completes a valid write-back. If the current instance update task is determined to be an invalid task, a conflicting task, or a task without valid state changes before the write-back, the version identifier will not be updated. A task without valid state changes means that all device object change records in the instance update task are determined to be invalid records, or all updated values ​​are consistent with the corresponding state parameter values ​​in the current state vector. The reason for adopting this approach is that the version identifier should reflect the actual order of state changes. If the version identifier is updated when there are no actual state changes, it will increase the number of invalid version changes in subsequent queries and concurrency control.

[0154] To adapt to high-concurrency update scenarios, this embodiment adds a version consistency check in the current step. Specifically, after reading the current state vector and the current version identifier, a new state vector and target version identifier to be written back are first formed locally. Before writing back, it is compared whether the version identifier in the current storage is still equal to the version identifier at the time of reading. If they are consistent, a one-time write-back of the state vector and version identifier is performed. If they are inconsistent, it means that the state vector of the digital twin instance has been updated by other instance update tasks during the calculation of this instance update task. At this time, the latest state vector and the latest version identifier are read again, and the update result of this instance update task is recalculated based on the latest state vector to ensure the temporal consistency of the state vector update result in the concurrent update scenario.

[0155] In this embodiment, after the state vector and version identifier are updated, a state query request can also be responded to. Specifically, when a state query request for any digital twin instance is received, the current state vector and current version identifier of the corresponding digital twin instance are first read based on the digital twin instance identifier in the state query request. Then, the current state vector and current version identifier are returned as the query result. If the state query request further carries a version identifier, the version identifier is first compared with the current version identifier. When the two are consistent, it indicates that the state version held by the requesting side is consistent with the current state version, and only the version consistency result or the current version identifier can be returned. When the two are inconsistent, the current state vector and current version identifier of the corresponding digital twin instance are returned.

[0156] Step 6 finally converts the instance update task into the centralized write-back result of the target digital twin instance state vector, completing the synchronization from the change of the running factor to the digital twin instance state. The significance of this processing is that the instance collection path formed in the previous steps is truly implemented as a centralized write-back through atomic updates in this step, thus avoiding multiple scattered updates to the same digital twin instance. At the same time, the version identifier is synchronously updated when the state vector is written back, so that the state change of the digital twin instance not only has the current value result but also has the update order information that can be used for subsequent queries and concurrency control. Therefore, the entire method forms a continuous and reproducible technical path from running factor collection, factor event generation, device object positioning, instance-level collection to state vector atomic update, providing a complete implementation basis for low-latency state synchronization in the high-concurrency financial server operation management scenario.

[0157] To sum up, by using the factor object mapping table, the change of the running factor is directionally constrained to the range of affected device objects, and then through the instance object association table, the affected device objects are further mapped to the target digital twin instance. On this basis, multiple state update events corresponding to the same target digital twin instance are first collected and merged, and then the state vector atomic update is performed, thus reconstructing the originally scattered per-instance processing path into a hierarchical propagation and centralized update path from the running factor to the device object and then to the digital twin instance. Therefore, the technical problem of lacking an efficient state synchronization mechanism when shared running factor changes cause multi-object and multi-instance linked updates in the server operation management scenario is solved, and the efficiency of state synchronization is improved.

[0158] Furthermore, multiple factor events of the same running factor are accumulated and merged in chronological order within the event merging window, and the length of the event merging window is dynamically adjusted according to the depth of the event queue and the event processing rate of the processing thread. On the premise of ensuring that the chronological order of the same running factor change is not destroyed, the granularity of the event entering the subsequent state propagation link can adaptively change with the real-time load of the system, thus converting high-frequency and fragmented factor fluctuations into event inputs that are more suitable for subsequent object mapping, instance collection, and atomic update processing, improving the throughput stability and real-time performance of the entire state synchronization link in the high-concurrency scenario.

[0159] Embodiment 2

[0160] Please refer to Figure 3 As shown in the figure, this embodiment provides a digital twin state synchronization system based on factor event drive, which is used to implement the digital twin state synchronization method based on factor event drive disclosed in Embodiment 1. The synchronization system includes a data storage module, an event monitoring module, an event processing module, a task merging module, and a state update module.

[0161] The data storage module is used to establish a factor object mapping table based on the mapping relationship between each operating factor and the device object, and the state response coefficient corresponding to each device object, and to establish an instance object association table based on the association relationship between each digital twin instance and the device object.

[0162] The event monitoring module is used to collect the data stream of each running factor in real time. When the change in the value of any running factor reaches the corresponding trigger threshold, a factor event including the running factor identifier and the change in value is generated and written to the event queue.

[0163] The event processing module is used to retrieve factor events from the event queue, determine the device objects affected by the factor events based on the running factor identifier and factor object mapping table in the factor events, determine the state increment corresponding to each device object based on the state response coefficient and numerical change of each device object, and generate a state update event based on each device object and its corresponding state increment.

[0164] The task merging module is used to determine the target digital twin instance based on the association table of device objects and instance objects involved in the status update event, write multiple status update events corresponding to the same target digital twin instance into the instance buffer, and accumulate and merge the status increments of the same device object in the instance buffer to generate an instance update task.

[0165] The state update module is used to perform atomic updates on the state vector of the target digital twin instance based on the instance update task, and obtain the updated state vector.

[0166] Since this system uses the factor event-driven digital twin state synchronization method in Example 1, it has the same effect, which will not be repeated here.

[0167] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention 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 the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A digital twin state synchronization method based on factor event-driven methods, characterized in that, include: Based on the mapping relationship between each operating factor and the device object, and the state response coefficient corresponding to each device object, a factor object mapping table is established; Based on the association between each digital twin instance and the device object, establish an instance object association table; The data stream of each operating factor is collected in real time. When the change in the value of any operating factor reaches the corresponding trigger threshold, a factor event including the operating factor identifier and the change in value is generated and written to the event queue. Retrieve factor events from the event queue, determine the device objects affected by the factor events based on the running factor identifier and factor object mapping table in the factor events, determine the state increment corresponding to each device object based on the state response coefficient and numerical change of each device object, and generate state update events based on each device object and its corresponding state increment. The target digital twin instance is determined based on the association table of device objects and instance objects involved in the status update event. Multiple status update events corresponding to the same target digital twin instance are written into the instance buffer, and the status increments of the same device object in the instance buffer are accumulated and merged to generate an instance update task. The instance update task performs an atomic update on the state vector of the target digital twin instance to obtain the updated state vector.

2. The digital twin state synchronization method based on factor event-driven approach according to claim 1, characterized in that, The methods for constructing event queues and handling events include: Set the event queue as multiple sub-event queues; The target sub-event queue corresponding to the factor event is determined based on the hash value of the running factor identifier in the factor event, and factor events corresponding to the same running factor are written into the same sub-event queue. Multiple processing threads are used to retrieve factor events from multiple sub-event queues in parallel for processing, thus completing the parallel processing of factor events.

3. The factor event-driven digital twin state synchronization method according to claim 2, characterized in that, Methods for merging multiple factor events for the same running factor include: Detect multiple factor events corresponding to the same running factor within a preset event merging window; The numerical changes in multiple factor events are accumulated and merged according to the chronological order of the events. The factor events corresponding to different operating factors are merged independently. The length of the event merging window is dynamically adjusted based on the depth of the event queue and the event processing rate of the processing thread to generate merged factor events.

4. The factor event-driven digital twin state synchronization method according to claim 1, characterized in that, Methods for generating instance update tasks include: When writing multiple state update events belonging to the same target digital twin instance to the instance buffer, a buffer entry is created using the digital twin instance identifier as the key. When there are multiple state update events for the same device object in the same buffer entry, the state increments corresponding to the multiple state update events are accumulated and stored in chronological order. After completing the writing of the state update event, iterate through the instance buffer and generate instance update tasks.

5. The factor event-driven digital twin state synchronization method according to claim 4, characterized in that, The concurrent write control methods for the instance buffer include: The instance buffer is divided into multiple buffer partitions based on the hash value of the digital twin instance identifier; Each buffer partition should be assigned an independent concurrent control unit; Concurrent write control of the instance buffer is achieved by performing parallel writes to different buffer partitions through an independent concurrent control unit.

6. The factor event-driven digital twin state synchronization method according to claim 1, characterized in that, Methods for determining the trigger threshold include: Statistical analysis of the fluctuation of the corresponding operating factor within the historical time window; The trigger threshold for the corresponding operating factor is determined based on the volatility statistics, which include at least one of standard deviation, mean absolute deviation, or volatility. By making the trigger threshold positively correlated with the fluctuation statistics, the trigger threshold of the corresponding operating factor can be obtained.

7. The factor event-driven digital twin state synchronization method according to claim 1, characterized in that, Methods for performing atomic updates to the state vector of the target digital twin instance based on the instance update task include: Based on the device object identifier recorded in the instance update task, the storage location of the corresponding state parameter in the state vector is determined by combining the instance object association table. Read the current status parameter value at the corresponding storage location; The state increment in the instance update task is accumulated to the corresponding current state parameter value to obtain the updated state parameter value; The updated values ​​of multiple state parameters are written back to the state vector at once, completing the atomic update.

8. The digital twin state synchronization method based on factor event-driven approach according to claim 1, characterized in that, The method also includes the verification and updating of the version identifier, and the method for verifying and updating the version identifier includes: Read the current version identifier corresponding to the target digital twin instance; When writing back the updated state vector, verify whether the current version identifier is consistent with that when reading it; Upon successful verification, the state vector is written back and the version identifier is incremented. If the verification is inconsistent, the latest state vector and the latest version identifier are reread, and the update is re-executed based on the latest state vector to complete the verification and update of the version identifier.

9. The digital twin state synchronization method based on factor event-driven approach according to claim 8, characterized in that, The method also includes a status query response, the method for which the status query response includes: When a status query request for any digital twin instance is received, the current status vector and current version identifier of the corresponding digital twin instance are returned. When a status query request carries a version identifier, if the carried version identifier is inconsistent with the current version identifier, the current status vector and the current version identifier are returned, thus completing the status query response.

10. A factor event-driven digital twin state synchronization system, used to implement the factor event-driven digital twin state synchronization method according to any one of claims 1-9, characterized in that, The system includes: The data storage module is used to establish a factor object mapping table based on the mapping relationship between each operating factor and the device object, and the state response coefficient corresponding to each device object, and to establish an instance object association table based on the association relationship between each digital twin instance and the device object. The event monitoring module is used to collect the data stream of each running factor in real time. When the change in the value of any running factor reaches the corresponding trigger threshold, a factor event including the running factor identifier and the change in value is generated and written to the event queue. The event processing module is used to retrieve factor events from the event queue, determine the device objects affected by the factor events based on the running factor identifier and factor object mapping table in the factor events, determine the state increment corresponding to each device object based on the state response coefficient and numerical change of each device object, and generate a state update event based on each device object and its corresponding state increment. The task merging module is used to determine the target digital twin instance based on the association table of device objects and instance objects involved in the status update event, write multiple status update events corresponding to the same target digital twin instance into the instance buffer, and accumulate and merge the status increments of the same device object in the instance buffer to generate an instance update task. The state update module is used to perform atomic updates on the state vector of the target digital twin instance based on the instance update task, so as to obtain the updated state vector.

Images