A digital and intelligent operation twin driving multi-state linkage closed loop optimization control method and system

Abstract

The application provides a digital operation twin driving multi-state linkage closed-loop optimization control method and system, comprising: obtaining the effective time node of each version from the blueprint version library of the digital operation twin platform, and the starting time and current execution progress of the running state business instance; determining the blueprint version identifier referred to by the initial execution of each business instance according to the effective time node and the starting time of each version; continuously collecting activity logs during the execution of the business instance and recording the time stamp of each log, comparing the log time stamp with the effective time node of the blueprint version identifier one by one, and determining the version attribution identifier corresponding to each log in the effective period when the log is generated; at the version switching point, according to the activity node definition in the compliance criteria of the old and new blueprint, an interface path between the old and new activity nodes is established, and a continuous judgment criterion covering before and after the switching point is generated.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a closed-loop optimization control method and system for multi-state linkage driven by digital intelligent operation twins. Background Technology

[0002] In the field of digital operations, building digital twin systems to achieve real-time monitoring and dynamic optimization of business processes has become a key means to improve enterprise operational efficiency and compliance. This process emphasizes accurate mapping of business operation status and continuous model-based control. Current common optimization methods focus on increasing the update frequency of business process blueprints (hereinafter referred to as blueprints) in order to quickly respond to rule changes and thus enhance the agility of process governance. However, these methods often overlook the fact that there are a large number of long-cycle task instances in actual business operations. Once these instances are started, they will continue to run in the system for weeks or even months. Business process blueprints are frequently updated to adapt to new regulations, but the entire execution process of those long-cycle instances that have already started and have not yet ended is divided under different versions of blueprint rules. The lifecycle of long-cycle business instances naturally spans the effective time periods of multiple blueprint versions. For example, a contract approval process instance that lasts for several months encounters a version update of the approval rules during its operation. The first half of its operation log is generated according to the old version of the rules, while the second half follows the new version of the rules. When the system performs a compliance review on this complete instance afterward, it faces the problem of inconsistencies in the compliance benchmark models referenced by the two log entries. This inconsistency is not a simple data difference, but a fundamental break in the rule logic. This makes it impossible for the system to use a single, consistent standard to judge the compliance of the entire instance's execution path, nor can it confirm whether its activity sequence maintained the necessary integrity at version switch points. Therefore, ensuring that long-cycle business instances spanning multiple blueprint versions receive continuous and consistent compliance judgment benchmark coverage throughout the entire process, avoiding rule reference breaks caused by version iterations, and thus truly improving the effectiveness of compliance supervision in digital operations, becomes a key issue that must be addressed to achieve closed-loop optimization control. Summary of the Invention

[0003] This invention provides a closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins, mainly including: Obtain the effective time nodes of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time nodes and start times of each version, determine the blueprint version identifier referenced by the initial execution of each business instance. During the execution of business instances, activity logs are continuously collected and the timestamps of each log are recorded. The log timestamps are compared one by one with the effective time nodes of the blueprint version identifier to determine the version to which each log belongs within the effective period when it is generated. Extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combine the current execution progress to determine whether the business instance crosses the version switch point. If so, extract the log segments within the preset time window before and after the corresponding switch point to form a log set to be judged. Based on the version ownership identifier of each log segment in the log set to be judged, obtain the old and new version blueprint compliance guidelines before and after the switch point from the blueprint version library respectively. At the version switch point, based on the activity node definitions in the old and new version blueprint compliance guidelines, establish a connection path between the old version activity nodes and the new version activity nodes, and generate continuous judgment criteria covering the switch point before and after. The continuous judgment criteria are used to evaluate the path compliance of the complete activity logs of cross-version surviving instances. It is determined whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria. Those that fall within the set are marked as compliant, and those that do not are marked as non-compliant. The path compliance evaluation results are then written back to the digital operation twin platform.

[0004] Furthermore, obtaining the effective time nodes of each version, as well as the startup time and current execution progress of the running business instance, from the blueprint version library of the digital operation twin platform includes: Retrieve the release number, effective start time, and expiration end time of each blueprint version from the blueprint repository; Construct the effective time interval for each blueprint version based on the effective start time and the expiration end time; Arrange the effective time intervals in chronological order to form a version time series; For the aforementioned version time series, the release number corresponding to each effective time interval is associated to form a version timeline with version identifiers.

[0005] Furthermore, based on the effective date and start time of each version, the blueprint version identifier referenced for the initial execution of each business instance is determined, including: Obtain the instance number and startup time of the running service instance; Compare the startup time with each effective time interval in the version time series one by one; If the startup time falls within a certain effective time interval, the release number corresponding to the effective time interval will be determined as the blueprint version identifier initially referenced by the business instance.

[0006] Furthermore, the process of continuously collecting activity logs and recording the timestamps of each log entry during the execution of the business instance, comparing the log timestamps with the effective time nodes of the blueprint version identifier one by one, and determining the version attribution identifier corresponding to each log entry within the effective period at the time of its generation, includes: Real-time collection of activity logs during the execution of business instances, recording the time of generation of each log as a timestamp; Extract the activity node number and instance number from the activity log to form a log set with timestamps; Obtain the effective time range of each blueprint version from the version time series; Compare the timestamp of each log entry in the log set with the effective time interval one by one; If the timestamp of a log entry falls within a certain effective time interval, the blueprint version identifier corresponding to the interval will be determined as the version attribution identifier of the log entry.

[0007] Furthermore, the time point at which the version ownership identifier of two adjacent logs changes is extracted and marked as a version switch point. Based on the current execution progress, it is determined whether the business instance crosses the version switch point. If so, log segments within a preset time window before and after the corresponding switch point are extracted to form a log set to be judged, including: The activity logs are arranged in order of timestamp, and the version attribution identifiers of adjacent logs are compared one by one. If two adjacent logs have different version ownership identifiers, then the timestamp of the latter log is marked as the version switching point; Obtain the current execution progress timestamp of the business instance and compare it with the version switch point; If the current execution progress timestamp is later than the version switching point, then the business instance is determined to have crossed the switching point; For business instances that span multiple switching points, a preset time window is extended forward and backward from the version switching point. All log segments whose timestamps fall within the time window are extracted from the activity logs to form a set of logs to be judged.

[0008] Furthermore, based on the version attribution identifier of each log segment in the log set to be judged, the compliance criteria for the old and new versions of the blueprints before and after the switch point are obtained from the blueprint repository, including: Extract the version ownership identifier of each log segment from the set of logs to be judged, and distinguish the old version ownership identifier before the switch point from the new version ownership identifier after the switch point based on the time relationship between the version ownership identifier and the version switch point. Based on the old version ownership identifier and the new version ownership identifier, retrieve the corresponding old version blueprint compliance guidelines and new version blueprint compliance guidelines from the blueprint version repository.

[0009] Furthermore, at the version switch point, based on the activity node definitions in the old and new version blueprint compliance guidelines, a connection path is established between the old version activity nodes and the new version activity nodes, generating continuous judgment criteria covering the period before and after the switch point, including: Extract the exit pointer of the active node from the blueprint version guidelines before the switch point and mark it as the old version termination node; Extract the entry point of the activity node from the blueprint version guidelines after the switch point and mark it as the new version's starting node; By comparing the exit direction of the old version termination node with the entry direction of the new version start node, the consistency of business semantics is determined. Establish a connection path between the old version termination node and the new version start node based on the business semantic consistency; The connection path is combined with the judgment rules before and after the switching point to form a continuous judgment criterion covering the period before and after the switching point.

[0010] Furthermore, the method also includes: extracting the names of active nodes before the switching point in the old blueprint and the exit directions of the active nodes before the switching point, retrieving the names of active nodes after the switching point in the new blueprint and their entry points, analyzing the connection routes of the active nodes on both sides at the business semantic level, and establishing a connection path and a draft of continuity judgment criteria between the old version termination node and the new version starting node.

[0011] Furthermore, the method of using continuous judgment criteria to evaluate the path compliance of the complete activity logs of cross-version surviving instances, determining whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria, marking those that fall within the set as compliant and those that do not as non-compliant, includes: Obtain the complete activity logs of the business instance, extract the activity node numbers in chronological order, and form the instance activity path sequence; Compare the sequence of activity paths in the instance with the set of allowed transitions in the continuity determination criteria; Determine whether the transfer direction between adjacent nodes in the instance activity path sequence falls into the allowed transfer set; If all transfer directions fall within the allowed transfer set, then the business instance is marked as compliant; If a transfer direction does not fall within the allowed transfer set, the business instance is marked as non-compliant.

[0012] This invention provides a closed-loop optimization control system for multi-state linkage driven by digital intelligent operation twins, mainly comprising: The version identifier determination module is used to obtain the effective time node of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time node and start time of each version, the blueprint version identifier referenced by the initial execution of each business instance is determined. The log attribution determination module is used to continuously collect activity logs and record the timestamp of each log during the execution of business instances. It compares the log timestamp with the effective time node of the blueprint version identifier one by one to determine the version attribution identifier corresponding to each log in the effective period when it was generated. The switch point extraction module is used to extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combined with the current execution progress, it is determined whether the business instance crosses the version switch point. If so, the log segments within the preset time window before and after the corresponding switch point are extracted to form a set of logs to be judged. Based on the version ownership identifier of each log segment in the set of logs to be judged, the old and new version blueprint compliance guidelines corresponding to the switch point are obtained from the blueprint version library respectively. The transition criteria generation module is used to establish a transition path between old and new version activity nodes at the version switch point based on the activity node definitions in the old and new version blueprint compliance criteria, and generate continuous judgment criteria covering the switch point. The compliance assessment module is used to assess the path compliance of the complete activity logs of cross-version surviving instances using continuous judgment criteria. It determines whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria. Those that fall within the set are marked as compliant, and those that do not are marked as non-compliant. The path compliance assessment results are then written back to the digital operation twin platform.

[0013] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a closed-loop optimization control method and system for multi-state linkage driven by digital intelligent operations twins. It proposes a complete solution to the path compliance issues caused by blueprint version switching during cross-version execution of business instances. This invention accurately locates the version switch point by identifying the blueprint version identifier corresponding to the business instance at startup, combined with dynamic comparison of log timestamps and version effective periods, and extracts log segments before and after the switch point to construct the connection path and continuity judgment criteria between the old and new blueprints. It focuses on solving the challenge of evaluating the compliance of activity paths for cross-version existing instances. This invention establishes continuity judgment criteria by analyzing the business semantic inheritance between the old version's termination node and the new version's start node, ensuring the compliance of instance paths during version switching. Finally, the evaluation results are written back to the platform, achieving closed-loop optimization control. Its core technical effect is to ensure the execution continuity and compliance of business instances in a multi-version environment, improving the adaptability and stability of digital intelligent operations. Attached Figure Description

[0014] Figure 1 This is a flowchart of a closed-loop optimization control method for multi-state linkage driven by a digital intelligent operation twin according to the present invention.

[0015] Figure 2 This is a schematic diagram of a closed-loop optimization control method for multi-state linkage driven by a digital intelligent operation twin according to the present invention.

[0016] Figure 3 This is another schematic diagram of a closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to the present invention.

[0017] Figure 4 This is a schematic diagram of the structure of a closed-loop optimization control system for multi-state linkage driven by digital intelligent operation twins according to the present invention. Detailed Implementation

[0018] To further understand the content of this invention, a detailed description of the invention is provided in conjunction with the accompanying drawings and embodiments. The specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0019] like Figures 1-4 This embodiment of a closed-loop optimization control method and system for multi-state linkage driven by digital intelligent operation twins may specifically include: S101. Obtain the effective time node of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time node and start time of each version, determine the blueprint version identifier referenced by the initial execution of each business instance.

[0020] The release number, effective start time, and expiration end time of each blueprint version are retrieved from the blueprint version library of the digital operations twin platform. The instance number and start time of running business instances are collected. An effective interval sequence for each version is constructed based on the effective start time and expiration end time, and this sequence is arranged chronologically to form a version timeline. The start time of each business instance is obtained, and it is compared one by one with each effective interval in the version timeline. If the start time falls within a certain effective interval, the release number of the blueprint version corresponding to that effective interval is used as the blueprint version identifier referenced for the initial execution of the business instance.

[0021] In one implementation, the blueprint version repository of the digital operations twin platform stores the release number, effective start time, and expiration end time of each blueprint version. The effective start time indicates the point at which the blueprint version begins to be applicable to business instance execution, and the expiration end time indicates the point at which the blueprint version ceases to be applicable. Based on the effective start time and expiration end time of each blueprint version, an effective interval corresponding to that version is constructed, and all effective intervals of all versions are arranged sequentially in ascending order of their effective start times to form a version timeline.

[0022] Specifically, each running service instance in the twin platform has a unique instance number and a corresponding startup time, which records the specific time when the instance is triggered to execute.

[0023] In one embodiment, the startup time of the business instance is compared with each effective interval in the version timeline to determine whether the startup time falls between the start and end times of a certain effective interval. If the startup time falls within a certain effective interval, the blueprint version release number corresponding to that effective interval is determined as the blueprint version identifier referenced by the initial execution of the business instance, thereby clarifying the blueprint compliance guidelines followed by the instance during the startup phase.

[0024] Another method to determine the blueprint version identifier is to retrieve the release number, effective start time, and expiration end time of each blueprint version from the twin platform, collect the instance number, start time, current activity node number, and list of completed activity nodes of the running business instance, identify the version effective range to which each instance's start time belongs, and determine the blueprint version identifier initially referenced by the instance.

[0025] The release number, effective start time, and expiration end time of each blueprint version are retrieved from the blueprint version repository of the twin platform. Based on these start and end times, an effective interval for each blueprint version is defined, and these intervals are arranged chronologically to form a version effective interval sequence. The instance number, start time, current activity node number, and list of completed activity nodes of the running business instance are collected. The start time is compared with each effective interval in the version effective interval sequence to identify the target effective interval into which the start time falls. Based on the blueprint version release number corresponding to the target effective interval, this release number is determined as the initial blueprint version identifier referenced by the business instance, and an association record is established between the current activity node number and the list of completed activity nodes and this blueprint version identifier.

[0026] In one implementation, the blueprint version library of the digital operations twin platform stores basic information about multiple blueprint versions. Each blueprint version has a unique release number and records its effective start time and expiration end time. The effective start time indicates the point at which the blueprint version begins to constrain the execution of business instances, and the expiration end time indicates the point at which the version ceases to be applicable. Based on the effective start time and expiration end time of each blueprint version, an effective interval covered by that version is defined, which is a time period that is closed on the left and open on the right. The effective intervals of all blueprint versions are arranged sequentially according to their effective start times from earliest to latest, forming a version effective interval sequence. This sequence reflects the sequential relationship of each version in the time dimension.

[0027] Specifically, each running business instance is assigned a unique instance number in the twin platform, and the instance's startup time, current activity node number, and list of completed activity nodes are recorded. The startup time is the specific point in time when the instance is triggered to enter the execution state, the current activity node number identifies the process node position that the instance is executing, and the list of completed activity nodes records all node numbers that the instance has completed from startup to the current time.

[0028] In one embodiment, the start time of the business instance is compared one by one with each effective interval in the version effective interval sequence to determine whether the start time falls between the start and end times of a certain effective interval. If the start time falls within a certain effective interval, the effective interval is marked as the target effective interval. Further, based on the blueprint version release number corresponding to the target effective interval, the release number is determined as the blueprint version identifier initially referenced by the business instance. At the same time, an association record is established between the current activity node number and the list of completed activity nodes and the blueprint version identifier, so that the execution progress information of the instance is bound to its initially referenced blueprint version, which facilitates tracing the compliance guidelines followed during the instance's operation.

[0029] S102. During the execution of business instances, continuously collect activity logs and record the timestamp of each log. Compare the log timestamp with the effective time node of the blueprint version identifier one by one to determine the version to which each log belongs within the effective period when it is generated.

[0030] During the execution of business instances, activity logs are continuously collected, recording the generation time of each log as a timestamp. Simultaneously, the activity node number and instance number corresponding to each log are extracted to form a set of activity logs with timestamps. The effective start time and expiration end time corresponding to each blueprint version identifier are obtained from the blueprint version repository. Based on these effective start times and expiration end times, effective period intervals for each version are constructed and arranged chronologically to form a version effective period sequence. The timestamp of each log in the activity log set is compared one by one with each effective period interval in the version effective period sequence. If the timestamp of a log falls within a certain effective period interval, the blueprint version identifier corresponding to that effective period interval is determined as the version attribution identifier of that log.

[0031] In one implementation, after a business instance is started in the twin platform, it enters the execution state. During the execution process, an activity log is generated for each operation completed at an activity node. Each activity log includes the time when the operation was generated, the activity node number to which it belongs, and the corresponding instance number. The time when the operation was generated is recorded as the timestamp of the log, which is used to identify the position of the log in the time dimension.

[0032] Specifically, the twin platform continuously monitors running business instances. When an instance transitions from one active node to the next, it automatically captures the execution actions of that node and writes them to the log, forming a timestamped set of activity logs. Each log entry in this set carries precise time information about when it was generated. Further, it retrieves the effective start time and expiration end time corresponding to each blueprint version identifier from the blueprint version repository. The effective start time indicates the point at which the blueprint version begins to be applicable to business instance execution, and the expiration end time indicates the point at which the version ceases to be effective. Based on these two times, an effective period interval for each version is defined. This interval is a left-closed, right-open time period. All effective period intervals for all versions are arranged sequentially from earliest to latest effective start time, forming a version effective period sequence.

[0033] In one embodiment, for each log entry in the activity log set, its timestamp is extracted and compared one by one with each effective period interval in the version effective period sequence. The comparison process adopts a traversal approach, sequentially determining whether the timestamp is greater than or equal to the start time of a certain effective period interval and less than the end time of that interval. If the timestamp meets the above conditions, it is determined that the log's generation time falls within that effective period interval. Based on the above determination results, the blueprint version identifier corresponding to the effective period interval is determined as the version attribution identifier of the log, thereby clarifying the blueprint compliance standard version followed by each activity log when it is generated, and realizing the version attribution traceability of each activity log during the execution of business instances.

[0034] S103. Extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combine the current execution progress to determine whether the business instance crosses the version switch point. If so, extract the log segments within the preset time window before and after the corresponding switch point to form a log set to be judged. Based on the version ownership identifier of each log segment in the log set to be judged, obtain the old and new version blueprint compliance guidelines corresponding to the switch point from the blueprint version library.

[0035] The activity logs are arranged in timestamp order. The version ownership identifiers of adjacent log entries are compared one by one. If the version ownership identifiers of adjacent log entries are inconsistent, the timestamp of the later log entry is extracted as the version switch point and marked. The current execution progress timestamp of the business instance is obtained and compared with the version switch point. If the current execution progress timestamp is later than the version switch point, the business instance is determined to have crossed a version switch point. For business instances that cross version switch points, a preset time window is extended forward and backward from the version switch point. All log segments whose timestamps fall within this time window are extracted from the activity logs, forming a set of logs to be judged. The preset time window length W is calculated as W = 10 + D * 2, where D is the log density, i.e., the number of log entries in the window divided by the number of minutes, in minutes. The version ownership identifiers of each log segment are extracted from the set of logs to be judged. Based on the chronological relationship between the version ownership identifier and the version switch point, the old version ownership identifier before the switch point and the new version ownership identifier after the switch point are distinguished. Based on the old version ownership identifier and the new version ownership identifier, retrieve the corresponding old version blueprint compliance guidelines and new version blueprint compliance guidelines from the blueprint version repository.

[0036] In one embodiment, the log segments before the switch point are verified using the old version of the blueprint compliance criteria, and the compliance score S1 is calculated as the number of matching items divided by the total number of items; the log segments after the switch point are verified using the new version of the blueprint compliance criteria, and the compliance score S2 is calculated as the number of matching items divided by the total number of items; if S1 > 0.8 and S2 > 0.8, the business instance is determined to be compliant, otherwise it is not compliant.

[0037] In one implementation, the activity logs are arranged in ascending order of timestamps, forming an ordered log sequence. For two adjacent logs in the ordered log sequence, their respective version attribution identifiers are extracted and compared to determine whether the version attribution identifiers of the preceding and following logs are consistent.

[0038] Specifically, if the version attribution identifiers of two adjacent logs are inconsistent, it indicates that a blueprint version change has occurred between these two logs. In this case, the timestamp of the latter log is extracted as the version switch point and marked. The version switch point represents the critical moment when the blueprint compliance guidelines referenced by the business instance during execution transition from one version to another. If a business instance undergoes multiple blueprint version changes within its complete execution cycle, there will be multiple version switch points. Further, the current execution progress timestamp of the business instance is obtained, which records the execution time of the instance's current active node. The current execution progress timestamp is compared with the version switch point. If the current execution progress timestamp is later than the version switch point, it is determined that the business instance crosses a version switch point, meaning that the execution process of the instance crosses the boundary of the blueprint version change. For business instances that cross version switch points, preset time windows are extended forward and backward from the version switch point. The preset time window is a pre-defined time length used to define the log coverage area near the switch point. Extract all log segments whose timestamps fall within the time window from the activity log. These log segments include old version logs before the switch point and new version logs after the switch point, which together constitute the log set to be judged.

[0039] It should be noted that the logs in the set to be judged cover activity records before and after the version switch point, reflecting the execution trajectory of business instances during the version transition, thereby supporting the compliance judgment of cross-version business instances. In one implementation, the set of logs to be judged contains activity logs before and after the version switch point, and each log carries its version attribution identifier. The version attribution identifier of each log segment is extracted from the set of logs to be judged. Based on the time relationship between the timestamp of each log and the version switch point, the version attribution identifiers carried by logs with timestamps earlier than the version switch point are classified as old version attribution identifiers, and the version attribution identifiers carried by logs with timestamps later than or equal to the version switch point are classified as new version attribution identifiers.

[0040] Specifically, the blueprint repository stores compliance guidelines for each blueprint version. These guidelines define the permitted paths and constraints for business instance execution activities under that version. The old version's compliance guidelines are retrieved from the blueprint repository based on the old version's ownership identifier, and the new version's compliance guidelines are retrieved from the blueprint repository based on the new version's ownership identifier.

[0041] In one embodiment, the old version of the blueprint compliance guidelines and the new version of the blueprint compliance guidelines correspond to the business execution specifications of the two stages before and after the version switch point, and the two together constitute the criteria for judging the compliance of cross-version business instances.

[0042] S104. At the version switch point, based on the activity node definitions in the old and new version blueprint compliance guidelines, establish a connection path between the old version activity node and the new version activity node, and generate continuous judgment criteria covering the period before and after the switch point.

[0043] The old version blueprint compliance guidelines extract the node names and exit points of each activity node before the version switch point, marking nodes with exit points as old version termination nodes. The new version blueprint compliance guidelines extract the node names and entry points of each activity node after the version switch point, marking nodes with entry points as new version start nodes, forming an old version node exit set and a new version node entry set. For each exit point in the old version node exit set, entry points with the same business semantics are retrieved one by one from the new version node entry set, identifying the correspondence between old version termination nodes and new version start nodes at the business process level, resulting in a node correspondence table. Based on the node correspondence table, a connection path is established between the old version termination node and the new version start node, defining the allowed node transfer directions in the cross-version execution path. This connection path is used as the node transfer rule at the version switch point, and sequentially concatenated with the judgment rules before the switch point in the old version blueprint compliance guidelines and the judgment rules after the switch point in the new version blueprint compliance guidelines to generate continuous judgment rules covering both before and after the switch point.

[0044] In one implementation, both the old and new versions of the blueprint compliance guidelines include definitions for each activity node in the business process. The activity node definition includes the node name, the node's entry point, and its exit point. The exit point indicates the downstream node to which the node is allowed to flow after execution, and the entry point indicates the upstream node source that the node is allowed to receive. The node names and exit points of each activity node before the version switch point are extracted from the old blueprint compliance guidelines. The last executed node in the process with an exit point is marked as the old version termination node, forming the old version node exit set.

[0045] Specifically, the node names and entry points of each activity node after the version switch point are extracted from the new blueprint compliance guidelines. The node that executes first in the process and has an entry point is marked as the new version's starting node, forming a new version node entry set. The old version node exit set and the new version node entry set record the boundary node information on both sides of the version switch point. Further, for each exit point in the old version node exit set, the entry point in the new version node entry set is searched one by one to determine whether they have the same business semantics. The criteria for determining business semantics include the type of business action carried by the node, the node's functional positioning in the process, and the category of business objects processed by the node. If the exit point of the old version termination node and the entry point of the new version starting node are consistent at the above-mentioned business semantic level, then a correspondence is identified between them, and this correspondence is recorded in the node correspondence table.

[0046] In one embodiment, the node mapping table uses the old version's ending node as an index to record the corresponding new version's starting node.

[0047] For example, in the old version of the blueprint compliance guidelines, the approval completion node terminated at the version switch point, and its exit point was the execution initiation of the next stage. In the new version of the blueprint compliance guidelines, the execution preparation node started at the version switch point, and its entry point was the approval completion of the previous stage. Both refer to the flow and connection between approval and execution in terms of business semantics. Therefore, the approval completion node and the execution preparation node are written as a pair of correspondences in the node correspondence table.

[0048] It should be noted that each pair of correspondences in the node correspondence table represents a node transfer allowed during cross-version execution. Based on the node correspondence table, a connection path is established between the old version's terminating node and the new version's starting node. The connection path is expressed in the form of directed edges, with the starting point being the old version's terminating node and the ending point being the new version's starting node, and the direction indicating the permitted direction of execution flow.

[0049] For example, the process of establishing a connection path involves traversing all correspondences in the node correspondence table and creating a directed edge for each correspondence, pointing from the old version's terminating node to the new version's starting node. If multiple correspondences exist in the node correspondence table, the connection path contains multiple directed edges, forming a set of allowed node transfers covering the version switch point. The connection path defines the allowed node transfer directions for a business instance's activity path when crossing a version switch point; node transfers not covered by the connection path will be considered non-compliant execution deviations.

[0050] In one possible implementation, the connection path is used as the node transfer rule at the version switch point. The old blueprint compliance guidelines contain decision rules prior to the switch point, defining the allowed transfer paths between old active nodes. The new blueprint compliance guidelines contain decision rules after the switch point, defining the allowed transfer paths between new active nodes. The decision rules prior to the switch point, the node transfer rules defined by the connection path, and the decision rules after the switch point are concatenated in chronological order.

[0051] Understandably, the concatenated judgment rules form a continuous judgment criterion covering the entire execution cycle of a business instance. The first part of the continuous judgment criterion corresponds to the activity path constraints of the old blueprint, the middle part corresponds to the cross-version transfer constraints at the version switch point, and the last part corresponds to the activity path constraints of the new blueprint. The three parts of the rules are linked together, ensuring that cross-version business instances have clear compliance judgment criteria at any execution time, thereby achieving continuous compliance coverage for long-cycle business instances during version change processes.

[0052] Extract the names of the active nodes before the switching point in the old blueprint and their exit points, retrieve the names of the active nodes after the switching point in the new blueprint and their entry points, analyze the connection routes of the active nodes on both sides at the business semantic level, and establish a connection path and a draft of the continuity judgment criteria between the old version's termination node and the new version's starting node.

[0053] Extract the names and exit points of active nodes before the version switch point from the old blueprint. Mark the nodes with exit points at the end of the process as old version termination nodes, forming an old version termination node set. Extract the names and entry points of active nodes after the version switch point from the new blueprint. Mark the nodes with entry points at the beginning of the process as new version start nodes, forming a new version start node set. For the old version termination node set and the new version start node set, compare the consistency of the exit points of the old version termination nodes with the entry points of the new version start nodes at the business semantic level. The criteria for determining business semantic consistency include business action type, functional positioning, and processing object category. If the business semantics of the exit points and entry points are consistent, a connection route is determined, resulting in a node connection route table. Based on the node connection route table, establish a connection path between the old version termination nodes and the new version start nodes. Sequentially concatenate this connection path with the judgment rules before the old version blueprint switch point and the judgment rules after the new version blueprint switch point to form a draft of continuous judgment criteria.

[0054] In one implementation, both the old and new blueprints contain definition information for each activity node in the business process. The activity node definition information includes the node name, the node's position and order in the process, the node's exit direction, and the node's entry direction. The exit direction indicates the downstream node direction to which the node is allowed to flow after execution, and the entry direction indicates the upstream node source direction that the node is allowed to receive. The names of all activity nodes before the version switch point are extracted from the old blueprint. The extracted nodes are traversed, and nodes located at the end of the process and having an exit direction are identified. These nodes are marked as old version termination nodes, and all old version termination nodes are aggregated to form an old version termination node set.

[0055] Specifically, the old version termination node refers to the critical node where, before the version switch point, the business instance is about to enter the new version's effective cycle after reaching this node. The exit direction of this node indicates the old version process's expected next execution direction and is a key anchor point connecting to the new version process. Further, the names of each activity node after the version switch point and their corresponding entry points are retrieved from the new version blueprint. The retrieved nodes are traversed, and nodes located at the beginning of the process and having entry points are identified and marked as new version starting nodes. All new version starting nodes are then aggregated to form a new version starting node set. The new version starting node refers to the entry node that is executed first when the business instance enters the new version process after the version switch point. The entry point of this node indicates the new version process's expectation of the upstream source.

[0056] In one embodiment, the old set of termination nodes and the new set of starting nodes are compared one by one. During the comparison, the business semantic information carried by the exit points of the old termination nodes is extracted, and the business semantic information carried by the entry points of the new starting nodes is also extracted. The extraction of business semantic information is based on three dimensions: business action type, functional positioning, and processing object category. Business action type refers to the nature of the business operation performed by the node, such as approval, review, issuance, and archiving. Functional positioning refers to the role that the node plays in the overall process, such as process initiation, intermediate processing, and process termination. Processing object category refers to the type attribute of the business data or documents operated by the node.

[0057] It should be noted that the determination of business semantic consistency adopts a dimension-by-dimensional comparison method. For the exit direction of the old version's termination node and the entry direction of the new version's start node, the values ​​of the two are compared in three dimensions: business action type, functional positioning, and processing object category. If the values ​​of all three dimensions are consistent, it is determined that the two are consistent at the business semantic level, and it is determined that there is a connection route between the old version's termination node and the new version's start node, and this connection route is recorded in the node connection route table.

[0058] For example, in the old blueprint, the contract approval completion node serves as the old version's termination node at the version switch point, with its exit pointing to the business action type of execution initiation, its function as process connection, and its processing object category as contract text. In the new blueprint, the contract execution preparation node serves as the new version's starting node at the version switch point, with its entry point also accepting the business action type of execution initiation, its function as process connection, and its processing object category as contract text. Upon comparison, the values ​​in all three dimensions are consistent, therefore it is determined that there is a connection route between the contract approval completion node and the contract execution preparation node, and this correspondence is written into the node connection route table.

[0059] In one possible implementation, the node succession route table uses the old version's terminating node as an index field and records its corresponding new version's starting node. Each record in the node succession route table represents a set of allowed node transfer relationships across versions.

[0060] Understandably, a connection path is established between the old version's terminating node and the new version's starting node based on the node transfer route table. This connection path is expressed as a directed connection, with the starting point being the old version's terminating node and the ending point being the new version's starting node. The direction indicates the permitted direction of the execution flow. If there are multiple records in the node transfer route table, the connection path contains multiple directed connections, covering all allowed node transfer scenarios at the version switch point.

[0061] Preferably, the connection path is used as the node transfer rule at the version switch point, and it is concatenated with the judgment rules before the switch point in the old version blueprint and the judgment rules after the switch point in the new version blueprint in chronological order. The resulting draft of the continuous judgment criteria consists of three parts: the first part is the old version judgment rule, the middle part is the cross-version transfer rule defined by the connection path, and the last part is the new version judgment rule. The draft of the continuous judgment criteria covers the complete path of a business instance from the old version execution stage, through the version switch point, to the new version execution stage, so that cross-version business instances have clear compliance judgment criteria at any execution time.

[0062] S105. Use the continuous judgment criteria to perform path compliance assessment on the complete activity logs of cross-version existing instances, determine whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria, mark those that fall within the set as compliant, mark those that do not fall within the set as non-compliant, and write back the path compliance assessment results to the digital operation twin platform.

[0063] Obtain the complete activity log of the cross-version persistent instance, and extract the activity node numbers of each record in the activity log in chronological order to form an instance activity path sequence. Compare the instance activity path sequence with the allowed transfer set in the continuity judgment criteria one by one to determine whether the transfer direction between adjacent nodes in the path sequence falls within the allowed transfer set. If all transfer directions fall within the allowed transfer set, the instance is marked as compliant; if at least one transfer direction does not fall within the allowed transfer set, the instance is marked as non-compliant. The compliance or non-compliance mark is used as the path compliance assessment result and written back to the instance record of the corresponding business instance in the digital operation twin platform.

[0064] In one implementation, a cross-version persistent instance refers to a business instance that has undergone a blueprint version switch during execution. Its complete activity log records all activity node information executed by the instance from startup to the current moment. The complete activity log of the cross-version persistent instance is obtained and arranged in ascending order of timestamps. The activity node number corresponding to each log record is extracted sequentially to form an instance activity path sequence. The instance activity path sequence represents the activity nodes sequentially traversed by the business instance during execution in the form of an ordered list.

[0065] Specifically, the continuity judgment criteria include a permissible transfer set, which defines the allowed transfer directions between activity nodes during the execution of a business instance. The permissible transfer set consists of three parts: judgment rules before the old blueprint switch point, cross-version transfer rules defined in the connection path, and judgment rules after the new blueprint switch point, covering the complete path range of instance execution. Further, the instance's activity path sequence is compared one by one with the permissible transfer set. The comparison process uses an adjacent node pairing method, sequentially extracting the numbers of two adjacent activity nodes in the path sequence and determining whether the transfer direction from the previous node to the next node exists in the permissible transfer set. If the transfer directions of all adjacent node pairs in the path sequence exist within the permissible transfer set, the instance's activity path is determined to comply with the constraints of the continuity judgment criteria, and the instance is marked as compliant.

[0066] In one embodiment, if at least one pair of adjacent nodes in the path sequence has a transfer direction that does not exist in the allowed transfer set, the activity path of the instance is determined to deviate from the execution trajectory allowed by the continuous determination criterion, and the instance is marked as non-compliant.

[0067] It should be noted that the compliance or non-compliance mark is used as the result of the path compliance assessment and written back to the instance record of the corresponding business instance in the digital operation twin platform. This enables the twin platform to present the compliance status of each cross-version existing instance in real time, supporting the continuous compliance supervision of long-cycle business instances.

[0068] This invention provides a closed-loop optimization control system for multi-state linkage driven by digital intelligent operation twins, mainly comprising: The version identifier determination module is used to obtain the effective time node of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time node and start time of each version, the blueprint version identifier referenced by the initial execution of each business instance is determined. The log attribution determination module is used to continuously collect activity logs and record the timestamp of each log during the execution of business instances. It compares the log timestamp with the effective time node of the blueprint version identifier one by one to determine the version attribution identifier corresponding to each log in the effective period when it was generated. The switch point extraction module is used to extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combined with the current execution progress, it is determined whether the business instance crosses the version switch point. If so, the log segments within the preset time window before and after the corresponding switch point are extracted to form a set of logs to be judged. Based on the version ownership identifier of each log segment in the set of logs to be judged, the old and new version blueprint compliance guidelines corresponding to the switch point are obtained from the blueprint version library respectively. The transition criteria generation module is used to establish a transition path between old and new version activity nodes at the version switch point based on the activity node definitions in the old and new version blueprint compliance criteria, and generate continuous judgment criteria covering the switch point. The compliance assessment module is used to assess the path compliance of the complete activity logs of cross-version surviving instances using continuous judgment criteria. It determines whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria. Those that fall within the set are marked as compliant, and those that do not are marked as non-compliant. The path compliance assessment results are then written back to the digital operation twin platform.

[0069] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins, characterized in that, The method includes: Obtain the effective time nodes of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time nodes and start times of each version, determine the blueprint version identifier referenced by the initial execution of each business instance. During the execution of business instances, activity logs are continuously collected and the timestamps of each log are recorded. The log timestamps are compared one by one with the effective time nodes of the blueprint version identifier to determine the version to which each log belongs within the effective period when it is generated. Extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combine the current execution progress to determine whether the business instance crosses the version switch point. If so, extract the log segments within the preset time window before and after the corresponding switch point to form a log set to be judged. Based on the version ownership identifier of each log segment in the log set to be judged, obtain the old and new version blueprint compliance guidelines corresponding to the switch point from the blueprint version library. At the version switch point, based on the activity node definitions in the old and new version blueprint compliance guidelines, establish a connection path between the old version activity nodes and the new version activity nodes, and generate continuous judgment criteria covering the switch point before and after. The continuous judgment criteria are used to evaluate the path compliance of the complete activity logs of cross-version surviving instances. It is determined whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria. Those that fall within the set are marked as compliant, and those that do not are marked as non-compliant. The path compliance evaluation results are then written back to the digital operation twin platform.

2. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, The process of obtaining the effective time nodes of each version, as well as the startup time and current execution progress of running business instances from the blueprint version repository of the digital operation twin platform, includes: Retrieve the release number, effective start time, and expiration end time of each blueprint version from the blueprint repository; Construct the effective time interval for each blueprint version based on the effective start time and the expiration end time; Arrange the effective time intervals in chronological order to form a version time series; For the aforementioned version time series, the release number corresponding to each effective time interval is associated to form a version timeline with version identifiers.

3. The closed-loop optimization control method and system for multi-state linkage driven by digital intelligent operation twins according to claim 2, characterized in that, Based on the effective date and start time of each version, determine the blueprint version identifier referenced for the initial execution of each business instance, including: Obtain the instance number and startup time of the running service instance; Compare the startup time with each effective time interval in the version time series one by one; If the startup time falls within a certain effective time interval, the release number corresponding to the effective time interval will be determined as the blueprint version identifier initially referenced by the business instance.

4. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, The process of continuously collecting activity logs and recording the timestamps of each log entry during business instance execution, comparing the log timestamps with the effective time nodes of the blueprint version identifiers one by one, determines the version attribution identifier corresponding to each log entry within its effective period at the time of its generation, including: Real-time collection of activity logs during the execution of business instances, recording the time of generation of each log as a timestamp; Extract the activity node number and instance number from the activity log to form a log set with timestamps; Obtain the effective time range of each blueprint version from the version time series; Compare the timestamp of each log entry in the log set with the effective time interval one by one; If the timestamp of a log entry falls within a certain effective time interval, the blueprint version identifier corresponding to the interval will be determined as the version attribution identifier of the log entry.

5. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, The process involves extracting the time point when the version ownership identifier of two adjacent log entries changes and marking it as a version switch point. Based on the current execution progress, it is determined whether the business instance crosses a version switch point. If so, log segments within a preset time window before and after the corresponding switch point are extracted to form a log set to be judged, including: The activity logs are arranged in order of timestamp, and the version attribution identifiers of adjacent logs are compared one by one. If two adjacent logs have different version ownership identifiers, then the timestamp of the latter log is marked as the version switching point; Obtain the current execution progress timestamp of the business instance and compare it with the version switch point; If the current execution progress timestamp is later than the version switching point, then the business instance is determined to have crossed the switching point; For business instances that span multiple switching points, a preset time window is extended forward and backward from the version switching point. All log segments whose timestamps fall within the time window are extracted from the activity logs to form a set of logs to be judged.

6. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, Based on the version attribution identifier of each log segment in the log set to be judged, retrieve the compliance guidelines for the old and new versions of the blueprints before and after the switch point from the blueprint repository, including: Extract the version ownership identifier of each log segment from the set of logs to be judged, and distinguish the old version ownership identifier before the switch point from the new version ownership identifier after the switch point based on the time relationship between the version ownership identifier and the version switch point. Based on the old version ownership identifier and the new version ownership identifier, retrieve the corresponding old version blueprint compliance guidelines and new version blueprint compliance guidelines from the blueprint version repository.

7. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, At the version switch point, based on the activity node definitions in the old and new version blueprint compliance guidelines, a connection path is established between the old and new version activity nodes, generating continuous judgment criteria covering the period before and after the switch point, including: Extract the exit pointer of the active node from the blueprint version guidelines before the switch point and mark it as the old version termination node; Extract the entry point of the activity node from the blueprint version guidelines after the switch point and mark it as the new version's starting node; By comparing the exit direction of the old version termination node with the entry direction of the new version start node, the consistency of business semantics is determined. Establish a connection path between the old version termination node and the new version start node based on the business semantic consistency; The connection path is combined with the judgment rules before and after the switching point to form a continuous judgment criterion covering the period before and after the switching point.

8. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, The method further includes: extracting the names of active nodes before the switching point in the old blueprint and the exit directions of the active nodes before the switching point, retrieving the names of active nodes after the switching point in the new blueprint and their entry points, analyzing the connection routes of the active nodes on both sides at the business semantic level, and establishing a connection path and a draft of continuity judgment criteria between the old version termination node and the new version starting node.

9. The closed-loop optimization control method for multi-state linkage driven by digital intelligent operation twins according to claim 1, characterized in that, The method of using continuous judgment criteria to evaluate the path compliance of the complete activity logs of cross-version surviving instances, determining whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria, marks those that fall within the set as compliant, and marks those that do not fall within the set as non-compliant, includes: Obtain the complete activity logs of the business instance, extract the activity node numbers in chronological order, and form the instance activity path sequence; Compare the sequence of activity paths in the instance with the set of allowed transitions in the continuity determination criteria; Determine whether the transfer direction between adjacent nodes in the instance activity path sequence falls into the allowed transfer set; If all transfer directions fall within the allowed transfer set, then the business instance is marked as compliant; If a transfer direction does not fall within the allowed transfer set, the business instance is marked as non-compliant.

10. A closed-loop optimization control system for multi-state linkage driven by digital intelligent operation twins, characterized in that, The system includes: The version identifier determination module is used to obtain the effective time node of each version, as well as the start time and current execution progress of the running business instance from the blueprint version library of the digital operation twin platform. Based on the effective time node and start time of each version, the blueprint version identifier referenced by the initial execution of each business instance is determined. The log attribution determination module is used to continuously collect activity logs and record the timestamp of each log during the execution of business instances. It compares the log timestamp with the effective time node of the blueprint version identifier one by one to determine the version attribution identifier corresponding to each log in the effective period when it was generated. The switch point extraction module is used to extract the time point when the version ownership identifier of two adjacent logs changes and mark it as the version switch point. Combined with the current execution progress, it is determined whether the business instance crosses the version switch point. If so, the log segments within the preset time window before and after the corresponding switch point are extracted to form a set of logs to be judged. Based on the version ownership identifier of each log segment in the set of logs to be judged, the old and new version blueprint compliance guidelines corresponding to the switch point are obtained from the blueprint version library respectively. The transition criteria generation module is used to establish a transition path between old and new version activity nodes at the version switch point based on the activity node definitions in the old and new version blueprint compliance criteria, and generate continuous judgment criteria covering the switch point. The compliance assessment module is used to assess the path compliance of the complete activity logs of cross-version surviving instances using continuous judgment criteria. It determines whether the instance activity path falls within the allowed transfer set defined by the continuous judgment criteria. Those that fall within the set are marked as compliant, and those that do not are marked as non-compliant. The path compliance assessment results are then written back to the digital operation twin platform.

Images