Business process visualization simulation method

Abstract

This invention discloses a business process visualization simulation method, specifically relating to the field of business process visualization technology. It constructs a task dependency graph and task paths, calculates the task causality strength factor (CIF) and time drift tolerance (TDT) based on historical log data, records task event sequences during simulation, and determines in real time whether tasks exhibit causal relationship disorder. When three conditions are met—early task execution, offset exceeding TDT, and CIF exceeding a set threshold—it is identified as a causal disorder event, and dynamic adjustment processing is initiated. Simultaneously, the detection results and adjustment feedback are visualized in real time, a causal consistency scoring model is constructed, and process structure optimization suggestions are output. This method has advantages such as high error recognition accuracy, flexible adjustment mechanism, and closed-loop feedback path, making it suitable for modeling and simulation platforms for various complex business processes.

Description

Technical Field

[0001] This invention relates to the field of business process visualization technology, and more specifically to a business process visualization simulation method. Background Technology

[0002] Business process visualization and simulation methods refer to the clear graphical representation of an enterprise's or organization's business processes, combined with simulation technology to analyze the process's operation. This method helps users intuitively understand each stage of the process, resource allocation, and execution logic, and predicts the process's performance under different conditions through simulation, thereby assisting in optimizing decision-making, improving efficiency, and identifying potential problems.

[0003] In existing technologies, when simulated tasks are executed dynamically in chronological order, the causal chain of events may become disordered. This often occurs in concurrent simulations or complex processes (such as those containing nested sub-processes or parallel tasks). Due to defects in the scheduling mechanism, the system may erroneously trigger certain tasks prematurely, causing subsequent tasks to be executed before the preceding tasks are completed. This can lead to logical contradictions, distorted simulation results, and chaotic animation playback, and in severe cases, it can affect the reliability of the entire process performance analysis and optimization judgment. Summary of the Invention

[0004] The purpose of this invention is to provide a business process visualization simulation method to address the shortcomings of the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a business process visualization simulation method, comprising: Based on a pre-defined process description language, the dependencies between various business tasks are analyzed to form a task dependency graph and generate task paths; Quantify the dependence strength of any target task on one or more of its predecessor tasks, and calculate the task causality strength factor (CIF) between each pair of tasks based on historical process data; Define the allowable offset range of task execution time relative to theoretical execution time during the simulation process, and calculate the time drift tolerance (TDT). Record the event sequence during the process simulation, including the actual execution time of the task, the completion status of the preceding task, and the resource scheduling status; Real-time causal consistency assessment is performed. When the execution time of any task is earlier than the completion time of its predecessor task and earlier than the expected sequence, exceeding the set TDT, and its corresponding CIF is higher than the set threshold, it is judged as a causal relationship disorder event. Dynamic adjustments are made based on the causal disorder determination results, including withdrawing the target task, rearranging the scheduling order, triggering compensation sub-processes, or marking the corresponding process instance as a failure record. The evaluation results and processing feedback are visualized in real time, and the causal consistency score and process optimization suggestions are output during the simulation process.

[0006] Preferably, the step of forming a task dependency graph and generating task paths specifically includes: The input business process model is parsed using a pre-defined process description language; Based on the parsing results, business task nodes, gateway nodes and their connection relationships are extracted, and a unique identifier ID is assigned to each node to establish a structured data representation; Construct a task dependency graph in the form of a directed acyclic graph, with the business task nodes as vertices in the graph and the execution order logic relationship between tasks as edges; Based on the task dependency graph, a depth-first traversal algorithm or a topological sorting algorithm is used to generate all feasible task execution paths, and these paths are stored as a set of task paths.

[0007] Preferably, the calculated task causality strength factor (CIF) specifically includes: The execution time, task status, instance identifier, and inter-task dependency information of each task are extracted from the historical business process execution logs to form a time-series execution dataset for modeling. The log data includes fields such as process instance ID, task start and finish time, and task execution result. For any target task and one or more of its prerequisite tasks, its dependency characteristics are calculated based on statistical analysis methods, including: the degree of influence of the average execution time of the prerequisite tasks on the start time of the target task; the probability of changes in the state of the target task in the event of failure or delay of the prerequisite tasks; and the maximum time delay and frequency of cooperation between the prerequisite tasks and the target task. Based on multiple influencing factors, a causal strength calculation model is constructed to quantitatively score task pairs. The scoring methods include normalized mutual information, Granger causal analysis, or a dependency factor weighted model based on logistic regression, generating a task causal strength factor (CIF).

[0008] Preferably, the set time drift tolerance (TDT) includes: The offset between the actual start time and the theoretical execution time of the same task in multiple process instances is collected from the historical process execution log. The theoretical execution time is calculated based on the average completion time of the preceding tasks in the task path and the standard process duration. Statistical analysis of the offset is performed to construct a task-level time offset distribution model, which includes the offset mean, standard deviation, range and outlier distribution information. Based on the time offset distribution model, a time drift tolerance interval (TDT) is set for each task.

[0009] Preferably, the real-time causal consistency assessment specifically includes: During the simulation, task execution events are monitored, and the actual execution time of each task is compared with the completion time of all its predecessor tasks. If the actual start time of a task is found to be earlier than the completion time of any predecessor task, it is recorded as a time-preceding conflict event. For tasks that have time-preceded conflicts, the time offset value of the task is further calculated, which is the offset of the actual execution time relative to the theoretical execution time. If the offset value exceeds the time drift tolerance (TDT) range set for the task, it is marked as time drift exceeding the limit. The task causality strength factor (CIF) between the retrieved task and its predecessor task is determined. If the CIF is higher than a set threshold, it indicates that the task has a strong dependency on its predecessor task. When all three conditions are met, the task is determined to have a causal consistency anomaly, a causal relationship disorder event record is generated, and a preset exception handling mechanism is triggered.

[0010] Preferably, the dynamic adjustment process based on the causal disorder determination result includes: Once a causal disorder event is determined to exist in a task, the execution status of the task is immediately frozen, its execution context is traced back, the task is withdrawn from the current run queue, and its allocated resources are released. Based on the constructed task dependency graph and the current process status, the affected task subgraphs are topologically reordered, and the task scheduling order is rearranged to ensure that the prerequisite dependencies of all tasks to be executed are satisfied before scheduling. If the logical interruption caused by the task withdrawal cannot be resolved by rescheduling, the corresponding compensation subprocess will be triggered. When an unrecoverable malfunction or a failure in the process logic structure occurs consecutively, the current process instance is marked as a failure record, and its process instance ID, malfunction path, affected tasks and triggering conditions are recorded, and it is removed from the simulation result statistics.

[0011] Preferably, the real-time visualization of the evaluation results and processing feedback includes: During the simulation execution, a causal consistency monitoring view is generated in real time based on the task event sequence and the causal disorder detection results; The dynamic adjustment measures during the handling of chaotic events are displayed in a graphical manner in a synchronized manner; A causal consistency scoring model is constructed, which comprehensively analyzes the proportion of tasks that meet causal constraints, the frequency of disorder events, the length of the disorder impact path, and the recovery success rate during task execution, and generates a normalized score value as an overall process consistency evaluation indicator. Based on the scoring results and the distribution characteristics of disorder events, combined with a predefined optimization rule base, optimization suggestions are output for specific process structures, including task path adjustment, resource configuration improvement, node merging, or scheduling strategy replacement.

[0012] The technical effects and advantages provided by the present invention in the above technical solution are as follows: 1. This invention, by introducing key parameters such as a causal consistency assessment mechanism, a time drift tolerance (TDT) model, and a task causality strength factor (CIF), achieves accurate identification and dynamic correction of potential task execution errors in process simulation. Through real-time monitoring of event sequences, multi-dimensional judgment of causal conflicts, and a compensation sub-process triggering mechanism, it effectively ensures the logical consistency and operational stability of process simulation, providing highly reliable and controllable simulation support for complex business processes.

[0013] 2. This invention also visualizes the evaluation results and processing feedback, constructs a causal consistency scoring model, and outputs structural optimization suggestions based on disordered distribution characteristics, thus realizing a closed-loop feedback mechanism from simulation execution to result analysis and process optimization. Compared with existing technologies, this invention not only improves the intelligence and adaptability of process modeling but also enhances the interpretability, scheduling flexibility, and optimization guidance value of the simulation system, possessing broad application prospects. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0015] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0017] For examples, please refer to Figure 1 As shown, the business process visualization simulation method described in this embodiment includes: Based on a pre-defined process description language, the dependencies between various business tasks are analyzed to form a task dependency graph and generate task paths; Quantify the dependence strength of any target task on one or more of its predecessor tasks, and calculate the task causality strength factor (CIF) between each pair of tasks based on historical process data; Define the allowable offset range of task execution time relative to theoretical execution time during the simulation process, and calculate the time drift tolerance (TDT). Record the event sequence during the process simulation, including the actual execution time of the task, the completion status of the preceding task, and the resource scheduling status; Real-time causal consistency assessment is performed. When the execution time of any task is earlier than the completion time of its predecessor task and earlier than the expected sequence, exceeding the set TDT, and its corresponding CIF is higher than the set threshold, it is judged as a causal relationship disorder event. Dynamic adjustments are made based on the causal disorder determination results, including withdrawing the target task, rearranging the scheduling order, triggering compensation sub-processes, or marking the corresponding process instance as a failure record. The evaluation results and processing feedback are visualized in real time, and the causal consistency score and process optimization suggestions are output during the simulation process.

[0018] In the field of business process simulation, process modeling is the foundation of the entire simulation system, directly determining the accuracy of subsequent simulation, causal reasoning, resource scheduling, and performance evaluation.

[0019] This method is based on a standardized parsing process, including: Process description language: refers to a standardized modeling language used to describe the logic of business processes. Common examples include BPMN (Business Process Model and Notation), Petri nets, and UML activity diagrams.

[0020] Task Node: Refers to the basic execution unit in the process that has actual business operation meaning, such as "submitting an order" or "approving an application". Each task node will be assigned a unique identifier (Task_ID).

[0021] Task Dependency Graph: A directed acyclic graph (DAG) with task nodes as vertices and logical dependencies between tasks as edges, used to represent the sequence and logical structure of tasks in a process.

[0022] Task Path: Starting from the process start node, the task execution sequence is formed by connecting task nodes sequentially according to the edges in the dependency graph until the process ends, reflecting the set of possible execution paths of the process.

[0023] The process description file is written in a structured language and includes task nodes, event nodes, gateway nodes, and their connection information.

[0024] Taking BPMN XML as an example, through parsing <bpmn:task> 、 <bpmn:sequenceflow> 、 <bpmn:exclusivegateway>Extract task name, ID, and preceding / following connections from elements such as these; Use open-source BPMN parsing tools (such as bpmn.io or Camunda BPMN Parser) to parse node attributes and generate node object structures.

[0025] For each parsed <bpmn:task>The element generates a Task_Node object, which contains the following attributes: Task_ID: A unique identifier; Task_Name: Task name; Predecessors[]: An array of predecessor task IDs; Successors[]: An array of successor task IDs; right <bpmn:sequenceflow>The elements are parsed to extract task connection pairs and construct logical edges between tasks.

[0026] For example, if there exists <bpmn:sequenceflow id="Flow_1" sourceref="Task_A" targetref="Task_B">If , it means that Task_A is the prerequisite task for Task_B, and the edge relationship (Task_A→Task_B) is recorded.

[0027] Treat all task nodes as vertices in a directed graph, and the dependencies between nodes as edges; Check for loops. If a closed loop is detected, refuse to proceed to the simulation process. The "Tarjan strongly connected component algorithm" can be used for graph loop detection. Ensure that the graph structure conforms to the property of a directed acyclic graph, which facilitates subsequent traversal and path calculation.

[0028] Based on the DAG structure, a topology sorting algorithm or a depth-first search (DFS) algorithm is used to enumerate all feasible paths from the starting task node until the ending node.

[0029] Example implementation steps: Initialize an empty path list Path_List[]; Start DFS from all nodes without predecessors (starting nodes); Each time a child node is recursively visited, the path is accumulated. When a node with no successor (the end node) is reached, the complete path is added to Path_List[]. Return all paths as a set of task paths.

[0030] Each path will be used for task scheduling and causal evaluation during the simulation process.

[0031] Obtain process execution logs recorded in historical business process systems to form a modeling dataset. Log data typically comes from BPM systems (such as Camunda, Activiti, SAP BPM) or business middleware log systems.

[0032] Each log record should contain at least the following fields: Process Instance ID String Used to distinguish different process execution instances Task ID String Unique identifier for task nodes in corresponding business process modeling Task Name String Optional, for visualization purposes Start time Timestamp The actual time when the task starts execution Completion Time Timestamp Actual time of task completion Execution result Enumeration type For example, success, failure, exception, timeout, etc. List of prerequisite task IDs array The modeling system provides the dependencies between tasks. The above data are aggregated to form a multidimensional time-series dataset LogDataset, which can be represented using a table structure or an event stream structure. Subsequent steps will extract relevant statistical features from it.

[0033] For any pair of tasks (prerequisite task → target task), it is necessary to extract its dependency behavior characteristics during actual execution from the LogDataset, specifically including the following three aspects: The degree of impact on execution time (time dependency) is used to assess whether the execution time of the preceding task affects the start time of the target task.

[0034] Calculate the target task start time minus the predecessor task completion time for each process instance to obtain the "interval time distribution"; If the completion time of the preceding task is delayed, will the target task also be delayed synchronously? Use Pearson correlation coefficient or mutual information measure to perform correlation analysis on time series.

[0035] Specifically: Calculate the time difference sequence ΔT for each process instance; The normalized mutual information calculation method is adopted, and is defined as follows: Normalized mutual information = mutual information value / mean entropy; Entropy represents the uncertainty of the distribution of time difference, while mutual information measures the information dependence between the pre-task and the target task; the higher the value, the stronger the dependence.

[0036] State response probability (abnormal transitivity) is used to measure whether the failure or delay of the preceding task increases the probability of the target task failing.

[0037] Specifically: Construct the conditional probability matrix: P(success_target | success_predecessor); P(success_target | fail_predecessor); By comparing the difference ΔP between the two, the larger the difference, the more significant the impact of the anomaly in the preceding task on the target task; the anomaly propagation relationship can be modeled using a logistic regression model.

[0038] For example, if the probability of the target task failing increases to 0.65 when the preceding task fails, while it is only 0.12 under normal circumstances, it indicates that there is a strong abnormal dependency.

[0039] Maximum time delay and frequency of coordination (structural coordination) are used to assess whether two tasks often "co-occur" or have a strict maximum response time window.

[0040] Specifically: The frequency with which the task pair exists simultaneously in the statistical process instance (the frequency of collaboration). Calculate its maximum response time delay, defined as: the latest start time of the target task in the process - the earliest completion time of the preceding task; If the maximum response time tends to stabilize in most instances, it indicates that there is a strong time-constrained coupling between the two.

[0041] The CIF calculation for each task pair will take into account the following characteristics: F1 Execution time mutual information normalization value (0~1) F2 State response probability difference (ΔP) F3 Normalized value of cooperative frequency (occurrence frequency) F4 Maximum time delay normalization value (contrarian indicator) This method can use one of the following three algorithms or a combination thereof: The normalized mutual information model is suitable for scenarios where tasks are strongly temporally coupled; all features are standardized and then weighted averaged, and the weights can be set based on expert experience; CIF = w1 × F1 + w2 × F2 + w3 × F3 + w4 × (1 - F4). The Granger causality test model, based on the predictive power of time-series data, determines the existence of Granger causality if the preceding task sequence can significantly improve the predictive power of the target task's start time; it is applicable to determining the coupling between time-continuous tasks.

[0042] The logistic regression weighted model uses the target variable as the label of "strong / weak coupling between tasks"; the F1 ~ F4 features are used as input to train the logistic regression model, and the output probability value is used as CIF.

[0043] The CIF value is defined in the range [0, 1] and represents the strength of the causal dependency between tasks: CIF ≥ 0.8: Strong dependency, cannot be skipped or executed in advance; 0.5 ≤ CIF < 0.8: Moderate dependency, can be adjusted through conditional checks; CIF < 0.5: Weak dependency, can be executed in parallel or the order can be ignored.

[0044] The TDT (Time Series Dataset) is set up based on the statistical modeling results of historical process execution data. First, business logs from the actual operation process need to be collected from the process system to form a time series dataset for calculating offsets and modeling.

[0045] The log data must include the following key fields: Process Instance ID (Instance_ID): A unique execution process that identifies the same process; Task ID (Task_ID): Identifies each task node in the process; Actual Start Time (Actual_Start_Time): The actual time the task occurs within the process instance; Predecessor_Tasks: Defines the direct predecessor nodes of this task; Predecessors_Actual_End_Times: The time records of when the pre-tasks were completed in this instance.

[0046] This data can be obtained from the process instance execution logs exported by standard BPM engines (such as Camunda, Activiti, jBPM).

[0047] To calculate the offset of a task, its theoretical execution time must first be defined, which is the point in time when the task should be scheduled for execution under the "ideal process execution state".

[0048] Theoretical execution time is defined as follows: For any task Task_T, its theoretical execution time T_theory in the process instance can be calculated as follows: take the average (or weighted average) completion time of all preceding tasks in the historical process; add the delay duration (Delay_T) set for the current task in the standard process template, such as the response time required by the SLA.

[0049] The formula is expressed as: Theoretical execution time (T_theory) = Average pre-completion time (T_pred_avg) + Standard process delay (Delay_T); where T_pred_avg is the maximum or weighted average of the completion times of all pre-tasks in the current instance, and Delay_T is the preset business processing buffer time.

[0050] The drift is the difference between a task's actual start time and its theoretical execution time. For task T in process instance i, the drift is defined as: Drift_T(i) = Actual_Start_Time_T(i) - T_theory(i); a positive drift indicates that the task is executed late; a negative drift indicates that the task is executed early; the larger the absolute value of the drift, the more serious the deviation of the task's time from the theoretical trajectory.

[0051] Iterate through multiple historical process instances, extract Drift_T(i) for each task node, and form a task-level time drift sample set Drift_Samples_T[].

[0052] For example, suppose there is a task T that appears in 100 process instances, calculate 100 offset values, and use them as the data basis for subsequent modeling.

[0053] For Drift_Samples_T[], standard statistical methods are used for modeling, and the following key metrics are extracted: Average offset μ_T (average value); Offset standard deviation σ_T; Maximum offset range (range); Histogram and box plot of offset value distribution (for visualization); The proportion of outliers (e.g., the number of individuals exceeding 3σ / total number of samples).

[0054] The above statistics are used to determine the execution time fluctuation characteristics of the task and are the direct basis for TDT settings.

[0055] The purpose of TDT (Task Dependency Test) is to define an allowable offset range at the task level, used to determine during simulation whether the actual execution of the task remains within the tolerable range. The method for defining this range includes the following steps: Strategy 1: Confidence Interval Method (Recommended): Utilizing the statistical properties of the normal distribution, the TDT interval is set as: TDT_T = [μ_T - k × σ_T, μ_T + k × σ_T]; where: μ_T is the average drift of task T; σ_T is the standard deviation; k is the confidence factor, commonly 2 (95% confidence interval) or 3 (99.7% confidence interval); TDT_T is the acceptable time offset range for task T. Example: If the average drift time of a task is 3 seconds and the standard deviation is 1.2 seconds, then the TDT is [0.6 seconds, 5.4 seconds], meaning that if the actual offset exceeds this interval, it will be considered as potentially indicating a timing disorder.

[0056] Strategy 2: Percentile Coverage Method. Based on the distribution of offset values ​​in the sample, the TDT is set to cover 90% or 95% of the historical offset values. The 5th and 95th percentiles of the offset values ​​are calculated; TDT_T = [P5, P95] is defined; this is suitable for task nodes with non-normal offset distributions.

[0057] An "event sequence" refers to a set of task-related events that occur sequentially in chronological order during simulation. Each event contains key data related to changes in the state of a specific task or resource. Event sequences not only reflect the true dynamic trajectory of the process but also provide data support for subsequent time drift determination, causal chain analysis, and resource utilization statistics.

[0058] Each event record is abstracted into a standardized data object SimEvent, which includes the following fields: Event timestamp (Event_Timestamp): The time the event was triggered in the simulation system, in milliseconds; Task ID (Task_ID): A unique identifier for the business task associated with this event; Process Instance ID (Instance_ID): The identifier of the process instance to which it belongs, ensuring that the event is clearly attributed; Event type (Event_Type): such as task start (Start), task completion (Complete), resource allocation (Allocate), resource release (Release), etc.; Predecessor Status List (Predecessor_Status[]): The completion status of each predecessor task before the task starts execution (e.g., completed, in progress, not started); Actual start time and actual end time (Actual_Start, Actual_End): If the event type is start or end, record the actual running time of the task; Resource usage (Resource_Assignment): Records the resource ID, resource type, quantity, etc. used when this task is executed; Scheduling policy flag (Scheduling_Flag): Indicates which scheduling policy was used to generate this schedule, such as FIFO, priority, preemption, etc.

[0059] All events are sorted in ascending order using timestamps as indexes to form a complete event sequence SimEventLog[]. After the simulation is completed, it can be exported as a table or database for subsequent analysis.

[0060] This method embeds an event listener module within the simulation engine to listen for and record the following key behaviors: Task scheduling event listener: When a task is scheduled to the execution queue, record its scheduling time and required resources; Task execution event listener: Record the start time when the task officially starts, and read the status of all preceding tasks; Task completion event listener: Write the actual completion time when the task is completed; Resource allocation and release event monitoring: When a task starts and finishes, the resource allocation and release behaviors are recorded respectively, forming a resource lifecycle tracking chain.

[0061] The event listening module, as a subsystem of the simulation engine, works in conjunction with the scheduling module and adopts an asynchronous non-blocking structure to ensure that event logging does not affect simulation performance.

[0062] During the simulation engine's operation, the system captures task scheduling and execution events in real time through the integrated event listener component, including information such as the actual start time of the task, task ID, and process instance ID.

[0063] When the simulation engine schedules a task to enter the execution state, it records its actual execution time (Actual_Start_Time). At the same time, query the completion time (Actual_End_Times) of all direct preceding tasks (Predecessor_Tasks) of this task in the current process instance.

[0064] For the currently executing task T, the time-ahead conflict judgment rule is defined as follows: If there exists any preceding task P that satisfies Actual_Start_Time(T) < Actual_End_Time(P), it means that the task started executing before its dependent upstream task was completed, violating the basic causal order constraint. In this case, the system records a causal time violation event.

[0065] If a time-preceding conflict occurs in a task, the system further determines whether the task deviates significantly from its theoretical execution time in order to distinguish between "acceptable minor out-of-order execution" and "serious early execution".

[0066] Theoretical execution time calculation method: For task T, its theoretical execution time (T_theory) is calculated as follows: T_theory = max{Actual_End_Time(P1), Actual_End_Time(P2), ..., Actual_End_Time(Pn)} + Delay_T; where: P1 to Pn are all directly preceding tasks of T; Delay_T is the buffer delay defined for this task in the standard process template; if Delay_T is not explicitly set, the default value is 0.

[0067] Offset calculation: Drift_T = Actual_Start_Time(T) - T_theory; Drift_T > 0 indicates task delay; Drift_T < 0 indicates task execution ahead of schedule; the larger the absolute value, the more significant the time offset.

[0068] Time Drift Tolerance (TDT) Judgment: Each task establishes a TDT interval in the historical process data, for example: TDT_T = [μ_T - 2σ_T, μ_T + 2σ_T]; where: μ_T is the historical offset mean; σ_T is the standard deviation; the interval range is adjustable to adapt to different industry tolerance standards. If Drift_T < TDT_T[0], that is, the offset is earlier than the lower bound of the TDT interval, it means that the task has been executed ahead of schedule and the magnitude has exceeded the acceptable range of the system. The system marks it as a Temporal Drift Exceeding event.

[0069] If a task occurs with a time conflict and the offset exceeds the limit, it is also necessary to determine whether the task has a strong dependency on its predecessor task, that is, whether the premature execution of the error will cause a business logic conflict.

[0070] The task causality strength factor (CIF) was derived from historical data modeling during the system initialization phase and is stored in the dependency matrix: CIF(Task_T, Task_P) ∈ [0, 1]; the higher the value, the stronger the dependency; the maximum CIF value of the task and all its predecessor tasks are used for the judgment.

[0071] Set the system threshold: CIF_Threshold = 0.8; If there exists P∈Predecessors(T) such that CIF(T, P) > CIF_Threshold; This indicates that task T has a strong causal dependency on task P, and executing T prematurely will lead to errors in the process logic or inconsistencies in the system state.

[0072] When all three of the following conditions are met: The actual execution time is earlier than the completion time of any preceding task; Execution time offset exceeds TDT range; The CIF value between the current task and any preceding task is higher than a set threshold. The system determines that the task has a causal consistency violation and immediately performs the following operations: Generate a Causal Disorder Event record, which includes fields such as Task ID, Process Instance ID, Offset Value, Preceding Task ID, and Corresponding CIF Value; Record the data in the simulation log system Violation_Log[]; Send a trigger signal to the exception handling module to perform operations such as dynamic scheduling rollback, task pause, resource reallocation, or insertion of compensation subprocesses.

[0073] When the causal consistency assessment module detects that a task T has the following conditions: The actual start time is earlier than the completion time of any preceding task; The offset exceeds the time drift tolerance (TDT) set for the task. The causal strength factor (CIF) of any preceding task is greater than a set threshold (e.g., 0.8). The system classifies this event as a "serious causal disorder" and immediately triggers the freeze process.

[0074] The freeze process includes: marking the execution status of task T as "Frozen," preventing it from passing its status to downstream tasks; removing T from the current run queue (Active_Task_Queue); revoking T's event records in the system and preserving a snapshot of the context data; and releasing the resources occupied by T, such as manpower, equipment, and processing units, returning them to the resource pool for scheduling by other tasks. This process is completed through an engine-level scheduling interface, ensuring that the freeze process is non-blocking and thread-safe.

[0075] Based on the directed acyclic graph (DAG) structure of the current process model, a local subgraph G_sub containing task T and its downstream tasks is extracted to analyze the impact of task rearrangement on downstream tasks. G_sub = {T, T1, T2, ..., Tn}, where each Ti is a task dependent on T, and n is the total number of tasks; Extract all unfinished task nodes from this subgraph; Perform a topological sort on the subgraph to generate a new scheduling order.

[0076] The topological sorting algorithm is as follows: Establish the mapping relationship between the construction task and the preceding task; Calculate the in-degree of all tasks; Start by traversing the tasks with an in-degree of 0, and sequentially add them to the scheduling sequence; If all the prerequisite tasks for a task are already in the queue, then the task can be executed.

[0077] For a frozen task T, it will be re-entered into the scheduling queue after its predecessor task is completed. For downstream task Ti, recalculate its earliest executable time; If scheduling fails due to time delay or resource conflict, the scheduling will be delayed and the waiting status will be recorded. All rescheduled tasks must be re-verified for TDT compliance to avoid cascading errors.

[0078] If any of the following situations occur after a task is cancelled, it indicates that the process logic has been interrupted and cannot be automatically repaired: The downstream tasks of task T have been partially executed; After the dependency graph is rearranged, logical islands are formed (without any path reachable); The frozen task is a critical process node or gateway task, and path connectivity cannot be restored even after reordering.

[0079] The system will trigger a compensation subprocess to replace the business function of the task or restore the integrity of the process logic.

[0080] The compensation process can be automatically generated or invoked in the following ways: Call predefined compensation templates (such as exception approval, manual review, emergency handling, etc.) from the business modeling platform; Dynamically select compensation strategies based on task classification and exception type; Instantiate the compensation process as a separate process instance and embed it into the current process context; The task execution information of the compensation process is also included in the event log system for unified management.

[0081] If two or more unrecoverable malfunctions occur consecutively in the same process instance, or if one of the following situations occurs: The cause-and-effect disorder of the task failed to be successfully restored through the compensation mechanism more than three times; Task dependency graph rearrangement failed; topology sequence could not be reconstructed. The compensation process failed or the process convergence conditions could not be met. If the process instance Instance_ID is then classified as a structurally invalid instance, the instance is marked as "Invalid" and written to the process instance control table (Instance_Control_Table). Its key parameters are recorded, including the process instance ID, the ID of the first malfunctioning task, the affected path, and the CIF and TDT judgment values. It is then removed from subsequent statistical reports, including performance evaluation, efficiency analysis, and resource utilization, for reference by the subsequent anomaly log analysis module for backtracking and modeling optimization.

[0082] This method uses a flowchart visualization engine and an event-driven update mechanism to present the task execution status, error detection results, and processing feedback in a graphical manner in real time during the simulation process.

[0083] Based on the process modeling diagram, the following visualization elements are dynamically overlaid: Task status color coding: Green for normally executing tasks; Yellow for withdrawn tasks; Red for tasks with causal inconsistencies; Blue for tasks replaced by compensation. Timeline view: The horizontal timeline displays the planned and actual execution times of all tasks; shows the degree of offset; task node hover information pop-up: displays the corresponding Causality Intensity Factor (CIF) value, Time Drift Tolerance (TDT) range, offset value, conflict status, compensation flag, etc. for the task; Event Log Panel: Real-time scrolling display of malfunction events and their processing logs; records task ID, process instance ID, trigger time, and handling measures. All simulation events and malfunction detection results are written to the event queue; the visualization renderer listens for queue change events and refreshes the screen; supports high-performance rendering using HTML5 Canvas or WebGL engines, supporting large-scale task graph rendering; supports user interaction, such as process replay, task location, and highlighting of malfunction paths.

[0084] To evaluate the overall causal consistency level of the simulation process during execution, this method designs a task-level scoring model that quantifies the local consistency state of each process instance and summarizes it into a global score.

[0085] The consistency score is defined as follows: N_total: the total number of tasks in the process instance; N_valid: the number of tasks that meet the causal order requirements; N_disorder: the number of tasks judged as causally disordered; P_recovered: the proportion of disordered tasks that were successfully repaired (e.g., rearranged or compensated); L_disorder_avg: the average influence depth of the disordered path (i.e., the average number of downstream tasks affected by the disordered task); then the causal consistency score Score_causal of the process instance is defined as: Score_causal = (N_valid / N_total) × α + P_recovered × β - L_disorder_avg × γ; where: α, β, and γ are weighting coefficients, with default settings of α = 0.5, β = 0.3, and γ = 0.2; Score_causal ranges from 0 to 1, with a higher consistency being closer to 1.

[0086] The above metrics are automatically calculated after each process instance simulation is completed; All scoring results are written to CausalScore_Table and associated with information such as process model, execution parameters, and number of malfunction events; It supports exporting rating reports, visual rating trend charts, rating distribution charts, and other charts.

[0087] This method analyzes the scoring results and the characteristics of malfunction events, and combines the process structure diagram and scheduling records to propose targeted optimization suggestions.

[0088] The system has a built-in process optimization rule library that combines scoring dimensions and the causes of errors to execute rule matching and output suggestions.

[0089] Optimization suggestion types include, but are not limited to: Path structure optimization: If the errors are concentrated at the intersection of parallel tasks, it is recommended to split the path or add synchronization nodes; Resource configuration adjustment: If the problem is caused by resource contention, it is recommended to increase the number of resource instances or switch to priority scheduling; Task merging or splitting: If high CIF tasks frequently become disordered, it is recommended to merge the preceding and target tasks into atomic tasks; Scheduling strategy replacement: Suggestions for replacing strategies such as FIFO with priority scheduling or cause-effect graph-based scheduling; Optimization suggestions for the compensation process template: If the compensation process frequently fails to trigger, prompt the user to adjust the compensation strategy or delay the triggering time.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.< / bpmn:sequenceflow> < / bpmn:sequenceflow> < / bpmn:task> < / bpmn:exclusivegateway> < / bpmn:sequenceflow> < / bpmn:task>

Claims

1. A business process visualization simulation method, characterized by: include: Based on a pre-defined process description language, the dependencies between various business tasks are analyzed to form a task dependency graph and generate task paths; Quantify the dependency strength of any target task on one or more of its predecessor tasks, and calculate the task causality strength factor (CIF) between each task pair based on historical process data, including: The execution time, task status, instance identifier, and inter-task dependency information of each task are extracted from the historical business process execution logs to form a time-series execution dataset for modeling. The logs include the following fields: process instance ID, task start and end time, and task execution result. For any target task and one or more of its prerequisite tasks, its dependency characteristics are calculated based on statistical analysis methods, including: the degree of influence of the average execution time of the prerequisite tasks on the start time of the target task; the probability of changes in the state of the target task in the event of failure or delay of the prerequisite tasks; and the maximum time delay and frequency of cooperation between the prerequisite tasks and the target task. Based on multiple influencing factors, a causal strength calculation model is constructed to quantitatively score task pairs. The scoring methods include normalized mutual information, Granger causal analysis, or a dependency factor weighted model based on logistic regression, generating a task causal strength factor (CIF). The normalized mutual information dependency factor weighted model is expressed as: CIF=w1×F1+w2×F2+w3×F3+w4×(1-F4); where F1 is the normalized value of mutual information during execution time, F2 is the difference in probability of state response, F3 is the normalized value of coordination frequency, F4 is the normalized value of maximum time delay, and w1, w2, w3, and w4 are set weights. Define the allowable offset range of task execution time relative to theoretical execution time during simulation, and calculate the Time Drift Tolerance (TDT), including: The offset between the actual start time and the theoretical execution time of the same task in multiple process instances is collected from the historical process execution log. The theoretical execution time is calculated based on the average completion time of the preceding tasks in the task path and the standard process duration. Perform statistical analysis on the offsets, and calculate the mean offset and standard deviation of the offsets respectively; Based on the average offset and standard deviation of the offset, a time drift tolerance (TDT) is set for each task using the confidence interval method. Record the event sequence during the process simulation, including the actual execution time of the task, the completion status of the preceding task, and the resource scheduling status; Real-time causal consistency assessment is performed. When the execution time of any task is earlier than the completion time of its predecessor task and earlier than the expected sequence, exceeding the set TDT, and its corresponding CIF is higher than the set threshold, it is judged as a causal relationship disorder event. Dynamic adjustments are made based on the causal disorder determination results, including withdrawing the target task, rearranging the scheduling order, triggering compensation sub-processes, or marking the corresponding process instance as a failure record. The evaluation results and processing feedback are visualized in real time, and the causal consistency score and process optimization suggestions are output during the simulation process.

2. The business process visualization simulation method according to claim 1, characterized in that: in, The process of forming a task dependency graph and generating task paths specifically includes: The input business process model is parsed using a pre-defined process description language; Based on the parsing results, business task nodes, gateway nodes and their connection relationships are extracted, and a unique identifier ID is assigned to each node to establish a structured data representation; Construct a task dependency graph in the form of a directed acyclic graph, with the business task nodes as vertices in the graph and the execution order logic relationship between tasks as edges; Based on the task dependency graph, a depth-first traversal algorithm or a topological sorting algorithm is used to generate all feasible task execution paths, and these paths are stored as a set of task paths.

3. The business process visualization simulation method according to claim 2, characterized in that: The real-time causal consistency assessment specifically includes: During the simulation, task execution events are monitored, and the actual execution time of each task is compared with the completion time of all its predecessor tasks. If the actual start time of a task is found to be earlier than the completion time of any predecessor task, it is recorded as a time-preceding conflict event. For tasks that have time-preceded conflicts, the time offset value of the task is further calculated, which is the offset of the actual execution time relative to the theoretical execution time. If the offset value exceeds the time drift tolerance (TDT) range set for the task, it is marked as time drift exceeding the limit. The task causality strength factor (CIF) between the retrieved task and its predecessor task is determined. If the CIF is higher than a set threshold, it indicates that the task has a strong dependency on its predecessor task. When all three conditions are met, the task is determined to have a causal consistency anomaly, a causal relationship disorder event record is generated, and a preset exception handling mechanism is triggered.

4. The business process visualization simulation method according to claim 3, characterized in that: The dynamic adjustment process based on the causal disorder determination result includes: Once a causal disorder event is determined to exist in a task, the execution status of the task is immediately frozen, its execution context is traced back, the task is withdrawn from the current run queue, and its allocated resources are released. Based on the constructed task dependency graph and the current process status, the affected task subgraphs are topologically reordered, and the task scheduling order is rearranged to ensure that the prerequisite dependencies of all tasks to be executed are satisfied before scheduling. If the logical interruption caused by the task withdrawal cannot be resolved by rescheduling, the corresponding compensation subprocess will be triggered. When an unrecoverable malfunction or a failure in the process logic structure occurs consecutively, the current process instance is marked as a failure record, and its process instance ID, malfunction path, affected tasks and triggering conditions are recorded, and it is removed from the simulation result statistics.

5. The business process visualization simulation method according to claim 4, characterized in that: The real-time visualization of evaluation results and processing feedback includes: During the simulation execution, a causal consistency monitoring view is generated in real time based on the task event sequence and the causal disorder detection results; The dynamic adjustment measures during the handling of chaotic events are displayed in a graphical manner in a synchronized manner; A causal consistency scoring model is constructed, which comprehensively analyzes the proportion of tasks that meet causal constraints, the frequency of disorder events, the length of the disorder impact path, and the recovery success rate during task execution, and generates a normalized score value as an overall process consistency evaluation indicator. Based on the scoring results and the distribution characteristics of disorder events, combined with a predefined optimization rule base, optimization suggestions are output for specific process structures, including task path adjustment, resource configuration improvement, node merging, or scheduling strategy replacement.

Images