Discrete simulation task scheduling method based on conditional waiting mechanism

Abstract

The invention relates to the technical field of industrial simulation and automatic control, in particular to a discrete simulation task scheduling method based on a conditional waiting mechanism, which compiles a waiting task script by using a common equipment preset condition library, simplifies the compiling process of the waiting task script, and improves the scheduling efficiency. Through cooperation of multi-condition combined scheduling, priority management, millisecond-level time control and a deadlock and timeout processing mechanism, system stability is guaranteed, industrial complex scene requirements are met, the problems that script programming is complex, complex condition processing capacity is weak, reliability is insufficient and the like in existing industrial simulation task scheduling are solved, and the industrial simulation task scheduling efficiency is improved. The scheduling efficiency, flexibility and reliability of the discrete simulation system are improved, and the control capability closer to the actual production process is provided for the industrial simulation system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of industrial simulation and automation control, and particularly relates to a discrete simulation task scheduling method based on a conditional waiting mechanism. BACKGROUND

[0002] In today's world where the complexity of production systems continues to rise, multi-device collaboration, multi-process linkage, and multi-condition constraint scenarios are becoming increasingly common. In a production line, the execution of an assembly task may depend on multiple conditions such as the availability of parts, the completion of previous processes, and the availability of quality inspection equipment. In a logistics scheduling scenario, the sorting of goods may require the simultaneous satisfaction of multiple conditions such as the arrival of a transport vehicle, the release of a storage space, and the availability of a sorting robot. As intelligent manufacturing develops towards flexibility and intelligence, the flexibility, real-time performance, and ease of use of the conditional waiting function, which is a core control mechanism of industrial simulation systems, are becoming increasingly important.

[0003] In a discrete simulation system, the efficiency and accuracy of task scheduling directly affect the reliability of simulation results, especially in scenarios involving multi-task parallelism, resource dependency, and condition triggering. Traditional scheduling methods still have the following shortcomings:

[0004] Complex waiting condition processing is difficult: In existing simulation systems, the definition of task waiting conditions requires a large amount of underlying code to be written, and there is a lack of standardized condition library support, resulting in low script writing efficiency, poor reusability, and difficulty in adapting to diverse conditions such as device status, process dependency, and resource constraints in industrial scenarios.

[0005] Lack of flexibility in scheduling mechanism: For tasks with a delay, it is difficult to support complex time expressions, and there is a risk of deadlock and resource management problems. In particular, in multi-task parallelism, the conditional dependencies between tasks may cause deadlocks, and long-waiting tasks occupy system resources, lack effective deadlock detection and resource cleanup mechanisms, and have poor task state management precision, lack of accurate tracking of the entire life cycle of tasks, and difficulty in implementing task state rollback and simulation process analysis. SUMMARY

[0006] To solve the above technical problems in the prior art, the present application provides a discrete simulation task scheduling method based on a conditional waiting mechanism.

[0007] To solve the above technical problems, the present application provides the following technical solution: a discrete simulation task scheduling method based on a conditional waiting mechanism, the discrete simulation task scheduling method comprising the following steps:

[0008] S1, write a waiting task script using a commonly used device preset condition library to write a waiting condition;

[0009] S2, the waiting task script code is parsed, compiled, simulated, and the task type in the waiting task script is identified, and the waiting task type includes conditional waiting task and time delay waiting task;

[0010] S3, an independent thread is allocated for the processed waiting task script code, so that the waiting task script enters an asynchronous processing flow; the main simulation thread is not affected by the execution of the waiting task script and continues to advance according to the simulation clock, thereby ensuring the continuity of the simulation process;

[0011] S4, the waiting task type is identified, and differentiated scheduling logic is executed according to the waiting task type, and deadlock detection and processing are performed, thereby ensuring efficient and reliable execution of the task;

[0012] S5, in the discrete simulation advancing process, the task state is recorded, the deadlock is detected in an event-driven manner, the deadlock is removed according to the priority order of the task, the task with low priority is terminated, and if there is no priority difference, the task that enters the waiting state after being removed.

[0013] Preferably, in the step S1, the preset condition library of the commonly used device includes a standardized condition template, a rule analysis module, and a self-defined extension module, wherein the standardized condition template includes a device state condition, a process dependency condition, and a resource constraint condition commonly seen in an industrial simulation scene;

[0014] When a user writes a script, the standardized condition template and the rule analysis module in the library are called to convert a condition expression into executable logic, multiple condition templates support combination using logical operators, and the self-defined extension module provides an open interface to support a user in defining a new condition by writing a condition function and automatically including the new condition in the preset condition library of the commonly used device for management.

[0015] Preferably, in the step S3, the main simulation thread includes: maintaining a simulation event table to drive the simulation clock in an event-driven manner;

[0016] scheduling a core simulation task, core business logic such as process execution, device state updating, and material flow; listening to event triggers such as device state changes, task state changes to completion or timeout, and resource release; coordinating the clock synchronization of the asynchronous task scheduling thread and the core simulation flow to ensure the overall timing consistency and flow continuity of the simulation scene.

[0017] Preferably, in the step S4, when the task type is identified as a conditional waiting task, the following steps are performed:

[0018] S41a, according to the judgment condition of the waitUntil function registered in the waiting task script, a wake-up order strategy is determined, a timeout processing threshold is given, and a unique condition UUID identifier is generated for the association between the task and the condition.

[0019] The wake-up sequence strategy is that the thread queue of the same condition waiting task adopts the FIFO or LIFO strategy, and the strategy between the waiting tasks is the priority wake-up, and the priorities of the same waiting task are the same;

[0020] S42a, using the condition identifier, establishing a bidirectional index between the conditions and the tasks, including a forward index and a reverse index, to quickly query the conditions associated with the tasks and the tasks dependent on the conditions, updating the task state to a new state, and recording a timestamp;

[0021] S43a, when the script of the task is executed for the first time, performing a first condition state evaluation, if the condition is met, the task is directly executed, the task state is updated to a completed state, and a timestamp is recorded; if the condition is not met, the script thread is suspended, the task state is updated to a waiting state, and a timestamp is recorded;

[0022] S44a, in the main simulation loop, when a new event is triggered and the simulation state is changed, re-evaluating the condition state; when the condition is met, the waiting task is woken up to continue execution, the task state is updated to a completed state, and a timestamp is recorded; when the condition is not met and a timeout threshold is reached, the task is ended, the task state is updated to a timeout state, and a timestamp is recorded.

[0023] Preferably, in the step S4, when it is identified that the task type is a delay waiting task, the following steps are performed:

[0024] S41b, parsing the time expression in the waitUntil function in the waiting task script to define a delay time period and a cron complex time, calculating a task trigger time, generating a delay waiting task, updating the task state to a new state, and recording a timestamp;

[0025] S42b, inserting the delay waiting task into a delay queue based on a minimum heap, the minimum heap taking the task trigger time as a key to ensure that the earliest triggered task can be efficiently obtained each time, updating the task state to a waiting state, recording a timestamp, and triggering the delay task according to the simulation system clock to provide millisecond-level precision;

[0026] S43b, when the simulation clock time reaches the trigger time, the corresponding thread is woken up, the task state is updated to a completed state, and a timestamp is recorded; if there is a task that has not been processed beyond the trigger time, the timeout task is removed, the task state is updated to a timeout state, and a timestamp is recorded.

[0027] Preferably, in the step S41a, both Boolean value and custom function are supported for registering dynamic evaluation conditions, logical dependency between conditions is analyzed, circular dependency between conditions is detected based on the resource allocation graph algorithm, deadlock is identified and a warning is issued, that is, a task is regarded as a process, simulation resources such as devices, buffers, and results of previous processes are regarded as resource nodes, a task-resource allocation graph is constructed, the graph is traversed, and if at least one closed loop is found, it is determined that there is a deadlock.

[0028] Preferably, in the steps S43a and S44a, event triggering is used as a driving force, dynamic evaluation conditions are evaluated, false wake-up is prevented through secondary evaluation conditions, the same conditions are required for the two evaluations, and logical dependency between conditions is analyzed, and if circular dependency is detected, a warning is issued and recorded.

[0029] Preferably, in the step S41b, a task trigger time is calculated, if the time expression is a delay time period, a simulation time after the delay time period is calculated based on the current simulation time, and the time is the task trigger time; if the time expression is a cron time expression, a task trigger time is calculated based on the current simulation time and the periodicity threshold condition given by the user.

[0030] Preferably, in the step S5, the task state includes a new state, a waiting state, a completed state, and a timeout state, and a timestamp is recorded when the task state changes.

[0031] Events that can drive deadlock detection include resource conflicts when a new task is created and occasional events in the simulation process.

[0032] The task-resource allocation graph is traversed, possible waiting deadlocks are identified and removed, and when the deadlocks are removed, the tasks, resources, and dependency chains involved in the deadlocks are recorded, low-priority tasks are terminated and resources are released, the allocation graph is updated, and it is confirmed that the deadlock loop has been removed; if there is still a deadlock, the next low-priority task is terminated according to the priority, and this process is repeated until the deadlock is completely removed.

[0033] Preferably, in the step S5, a thread queue of tasks in the waiting state is maintained according to the thread wake-up order, thread resources that have completed waiting are automatically cleaned up, and when the thread resources are cleaned up, the task state is updated, local resources are released, a thread destruction interface is called, and the corresponding thread handle is removed from the thread queue, long-term blocked tasks are identified, and a timeout strategy is executed when the waiting time exceeds a preset threshold, and an urgent task queuing mechanism based on priority is supported.

[0034] Compared with the prior art, the present application has the following beneficial effects:

[0035] The application uses a common device preset condition library to write a waiting task script, simplifies the waiting task script writing process, and guarantees system stability through multi-condition combination scheduling, priority management, millisecond-level time control, and deadlock and timeout processing mechanisms, adapts to industrial complex scene requirements, solves the problems of complex script programming, weak complex condition processing capability, and insufficient reliability in existing industrial simulation task scheduling, improves the scheduling efficiency, flexibility, and reliability of the discrete simulation system, and provides the industrial simulation system with a control capability closer to the actual production process. BRIEF DESCRIPTION OF DRAWINGS

[0036] Fig. 1 A discrete simulation task scheduling method flowchart of the application;

[0037] Fig. 2 A simplified workshop schematic diagram of the application;

[0038] Fig. 3 A workshop simulation result Gantt chart of the application. DETAILED DESCRIPTION

[0039] The above and other technical features and advantages of the application will be further described in conjunction with the drawings and embodiments, but the following embodiments are only preferred embodiments of the application, not all.

[0040] Embodiment one:

[0041] As shown in the Figs. 1-3 The application provides a discrete simulation task scheduling method based on a condition waiting mechanism, which comprises the following steps:

[0042] S1, a waiting task script is written, and a common device preset condition library is used to write a waiting condition;

[0043] S2, the waiting task script code is parsed, compiled, and simulated, the task type in the waiting task script is identified, and the waiting task type includes two types of condition waiting tasks and delay waiting tasks;

[0044] S3, an independent thread is allocated for the processed waiting task script code, so that the waiting task script enters an asynchronous processing flow; the main simulation thread is not affected by the execution of the waiting task script, and continues to advance according to the simulation clock, ensuring the continuity of the simulation process;

[0045] S4, the waiting task type is identified, differential scheduling logic is executed according to the waiting task type, and deadlock detection and processing are performed, ensuring efficient and reliable task execution;

[0046] S5 records the task status during the discrete simulation process, performs event-driven deadlock detection, resolves deadlocks according to task priority, terminates lower priority tasks, and if there is no priority distinction, the task enters a waiting state after resolution.

[0047] In this embodiment, in step S1, the commonly used equipment preset condition library includes a standardized condition template, a rule parsing module, and a custom extension module. The standardized condition template includes common equipment state conditions, process dependency conditions, and resource constraint conditions in industrial simulation scenarios.

[0048] When users write scripts, they call the standardized condition templates and rule parsing modules in the library to convert condition expressions into executable logic. Multiple condition templates can be combined using logical operators to meet the needs of multiple constraint scenarios. The custom extension module provides an open interface, allowing users to define new conditions by writing condition functions, which are then automatically included in the commonly used device preset condition library for management.

[0049] In this embodiment, in step S3, the main simulation thread, which is the core control thread of the discrete simulation system, is responsible for coordinating the overall simulation process. Specifically, it includes: maintaining the simulation event table and using events to drive the simulation clock; scheduling core simulation tasks and core business logic such as process execution, equipment status updates, and material flow; listening for event triggers, such as equipment status changes, task status changes to completion or timeout, and resource release; and coordinating the synchronization of the asynchronous task scheduling thread with the clock of the core simulation process to ensure the overall timing consistency and process continuity of the simulation scenario.

[0050] In this embodiment, in step S4, the basis for identifying the task type is the input parameter of the waitUntil function in the waiting script. When the input parameter of the waitUntil function is a boolean value or a custom function (which can be written using a preset condition library or with completely custom condition content), it is determined to be a conditional waiting task; when the input parameter of the waitUntil function is a Long time period or a cron expression (including periodic termination conditions), it is a delayed waiting task.

[0051] By binding the waitUntil function with a library of preset conditions for common devices, integrating a deadlock detection mechanism, and coordinating with periodic delay tasks, simulation efficiency and reliability are improved.

[0052] In this embodiment, in step S4, when the task type is identified as a conditional wait task, the following steps are performed:

[0053] S41a, Based on the judgment condition of the waitUntil function in the registered waiting task script, determine the wake-up order strategy, give the timeout processing threshold, and generate a unique condition UUID identifier for the association between the task and the condition;

[0054] The wake-up order strategy is as follows: the wake-up strategy for the queue of threads waiting for tasks under the same condition is FIFO or LIFO, and the strategy between waiting tasks is priority wake-up, with the same waiting task having the same priority.

[0055] S42a: Using condition identifiers, a bidirectional index is established between conditions and tasks, including forward and reverse indexes, to quickly query the tasks associated with the conditions and the conditions that the tasks depend on, update the task status to the new status, and record the timestamp.

[0056] A forward index uses a condition identifier as the key to store a list of all task thread IDs that depend on that condition.

[0057] An inverted index stores a list of all condition identifiers that the task depends on, using the task thread ID as the key.

[0058] S43a, When the script for this task is executed for the first time, an initial conditional state evaluation is performed. If the conditions are met, the task is executed directly, the task status is updated to the completed state, and a timestamp is recorded. If the conditions are not met, the script thread is suspended, the task status is updated to the waiting state, and a timestamp is recorded.

[0059] S44a, in the main simulation loop, when a new event is triggered and the simulation state changes, the condition state is re-evaluated; when the condition is met, the waiting task is woken up to continue execution, the task state is updated to the completed state, and a timestamp is recorded; when the condition is not met and the timeout threshold is reached, the task is terminated, the task state is updated to the timeout state, and a timestamp is recorded.

[0060] In this embodiment, in step S4, when the task type is identified as a delayed waiting task, the following steps are performed:

[0061] S41b: Parse the time expression in the waitUntil function of the waiting task script, define the delay time period and cron complex time (periodic task execution time), calculate the task trigger time, generate the delayed waiting task, update the task status to the new status, and record the timestamp;

[0062] S42b inserts the delayed waiting task into a min-heap-based delay queue. The min-heap uses the task trigger time as the key to ensure that the earliest triggered task can be retrieved efficiently each time, the task status is updated to the waiting state, the timestamp is recorded, and the delayed task is triggered according to the simulation system clock, providing millisecond-level accuracy.

[0063] S43b: When the simulation clock time reaches the trigger time, the corresponding thread is woken up, the task status is updated to the completed state, and the timestamp is recorded; if there are tasks that have not been processed after the trigger time, the timed-out tasks are removed, the task status is updated to the timed-out state, and the timestamp is recorded.

[0064] In this embodiment, step S41a supports registering dynamic evaluation conditions using both Boolean values ​​and user-defined functions. It analyzes the logical dependencies between conditions, detects circular dependencies between conditions based on the "resource allocation graph algorithm," identifies deadlocks, and issues warnings. Specifically, it treats tasks as processes and simulation resources such as devices, buffers, and results of previous processes as resource nodes, constructs a task-resource allocation graph, and traverses the graph. If at least one closed loop is found, such as task A occupying resource 1 and waiting for resource 2, or task B occupying resource 2 and waiting for resource 1, then a deadlock is determined.

[0065] In this embodiment, both steps S43a and S44a are driven by event triggering, dynamically evaluate the conditions, and verify them through secondary evaluation to prevent false wake-ups. The requirements for the two evaluations are the same. At the same time, the logical dependencies between the conditions are analyzed. If a circular dependency is detected, a warning is issued and recorded.

[0066] In this embodiment, in step S41b, the task trigger time is calculated. If the time expression is a delay period, the simulation time after the delay period is calculated based on the current simulation time, and this time is the task trigger time. If the time expression is a cron time expression, the task trigger time is calculated based on the current simulation time and the period deadline condition given by the user.

[0067] In this embodiment, in step S5, the task status includes new status, waiting status, completed status, and timeout status, and a timestamp is recorded when the task status changes.

[0068] Events that can drive deadlock detection include resource conflicts discovered when a new task is created and occasional events during the simulation process, such as deadlock caused by the requested resource being occupied by another task and the task requesting the resource, equipment failure, or sudden release of resources.

[0069] Traverse the task-resource allocation graph, identify and resolve potential deadlocks. When resolving a deadlock, record the tasks, resources, and dependency chains involved, terminate low-priority tasks and release resources, update the allocation graph, and confirm that the deadlock cycle has been resolved. If a deadlock still exists, continue to terminate the next low-priority task according to priority until the deadlock is completely resolved.

[0070] Maintain a queue of waiting tasks according to the thread wake-up order, automatically clean up the thread resources of completed waiting threads. During cleanup: update the task status, release local resources, call the thread destruction interface, and remove the corresponding thread handle from the thread queue. Identify long-blocked tasks and execute a timeout policy when the waiting time exceeds a preset threshold.

[0071] Supports a priority-based emergency task queue-jumping mechanism.

[0072] Example 2:

[0073] like Fig. 2 As shown, batch processing of three types of parts, A, B, and Z, needs to be completed. The process route needs to be determined. The system includes an inlet buffer zone, nine processing stations and corresponding buffer zones, and an outlet. Each processing station can process each process of the three types of parts, A, B, and Z. The process and duration are shown in Table 1.

[0074] Table 1. Process Data of Machining Parts

[0075]

[0076] At the start of the simulation, each of machining stations 2 to 9 has one Z part in the process of being processed. Machining station 2 has 30 minutes of remaining processing time, machining station 3 has 31 minutes of remaining processing time, and machining stations 4 to 9 have 55 minutes of remaining time. Two types of parts, A and B, are waiting in the entrance buffer zone. There are 5 A parts and 6 B parts.

[0077] Constraints: After processing, the parts automatically enter the buffer zone of the corresponding processing station, ignoring the logistics transportation method and time; the same process must be executed continuously in the same processing station without interruption or switching; when the processing station is busy, the parts to be processed must not be moved into the processing station; when the workstation is idle and there are two types of part tasks, A and B, waiting at the same time, priority queueing is supported, with type A part tasks having higher priority than type B part tasks; after part Z is processed, it is moved to the exit after a 1-minute delay.

[0078] S1. Based on the system's library of commonly used equipment preset conditions, a simulation script is written. It calls the "equipment status conditions" and "process dependency conditions" templates from the library, combines them into composite conditions, sets priorities and timeout thresholds, uses time intervals for delay expressions, and performs script parsing and task type identification. The script pseudocode is as follows:

[0079] Conditional waiting script for part A's operation:

[0080] waitUntil(station n idle && station n completed previous process, priority=high, timeout=60min);

[0081] Conditional waiting script for part B's operation:

[0082] waitUntil(station n idle && station n completed previous process, priority=low, timeout=60min);

[0083] Delay script after Z part is completed:

[0084] waitUntil (fixed delay = 1 minute).

[0085] S2 analyzes, compiles, and simulates the waiting task script code to identify the task type in the waiting task script. The analysis results show that the tasks for parts A and B are conditional waiting tasks, and the subsequent tasks for part Z are delayed waiting tasks.

[0086] S3 initializes the thread pool, which contains 20 threads. According to the event-driven principle of discrete simulation, when the simulation process calls a script task, a thread is allocated to the script task, and the asynchronous processing flow is entered. The main simulation thread advances the clock.

[0087] S4, conditions for parts A and B await task scheduling:

[0088] S41a, the conditional wait module registers a conditional expression, sets the wake-up strategy to FIFO, sets the timeout threshold to 60 minutes, and generates conditional identifiers cond_A and cond_B;

[0089] S42a, use condition identifiers to establish a two-way index between conditions and tasks, the task management module sets the task status to "new" and records the simulation clock timestamp (T0).

[0090] S43a, initial evaluation and thread suspension. The initial state of processing station 1 is idle, and there are no preceding processes for both types of parts A and B at this time. Therefore, all conditions are met. Part A has a higher priority and enters processing station 1. After the script is executed, the task management module sets the task status to "complete" and records the simulation clock timestamp (T0).

[0091] Release the script thread back to the thread pool. Since processing station 1 is occupied, the condition is no longer met. The task management module suspends the task thread of part B, sets its status to "waiting", and records the simulation clock timestamp (T0).

[0092] S44a, advances the simulation process and performs dynamic evaluation of conditional states:

[0093] After the first part of type A is completed in process A1, the simulation time is (T0+30 minutes). The script is called to try to confirm the processing workstation of process A2. Since all 9 processing stations are busy at this time, the script thread is suspended and the status is set to "waiting". The simulation clock timestamp (T0+30 minutes) is recorded.

[0094] After processing station 2 completes the process of part Z, the status of processing station 2 changes to "idle" and there is no preceding process. At this time, there are waiting tasks for parts A and B in the task management module. Since part A has a higher priority than part B, the priority queueing mechanism is executed to perform secondary condition verification of the first part task of part A. If the condition is met, the waiting thread is awakened and enters processing station 2 to perform process A2. The task of part B remains in the waiting state.

[0095] During the simulation process, when an event is triggered, timeout checks are performed on all conditionally waiting task threads in the "waiting" state. If the timeout exceeds the threshold, the task is abandoned, the task status is updated to "timeout" and the timestamp is updated, and the user is notified. At the same time, deadlock detection and resolution are performed, and low-priority tasks are terminated. This process continues until the processing of parts of types A and B is completed.

[0096] S4, Z part delay waiting task scheduling:

[0097] S41b, parse the delay time expression of the Z part task, calculate the trigger time. Taking workstation 2 as an example, the delay task trigger time is: T0 + 30 minutes + 1 minute = T0 + 31 minutes. Create the delay task.

[0098] S42b, insert the task into the min-heap queue, with the earliest triggered task at the top of the heap, set its status to "waiting", and record the simulation clock timestamp (T0).

[0099] S43b, advance the simulation process. Taking workstation 2 as an example, when the simulation clock reaches T0+31 minutes, the task "Z part move out of the exit" is detected to be triggered, the corresponding thread is woken up, the "move to exit" operation is executed, the task is removed from the queue, the task status is set to "complete", and the simulation clock timestamp (T0+31 minutes) is recorded.

[0100] During the simulation, when an event is triggered, the queue of delayed waiting tasks is checked. If any task has not been executed within the time limit, the task is discarded, the task status is updated to "timeout" and the timestamp is updated, and the user is notified.

[0101] The above description is merely a preferred embodiment of the present invention and is illustrative rather than restrictive. Those skilled in the art will understand that many changes, modifications, and even equivalents can be made within the spirit and scope defined by the claims of the present invention, all of which will fall within the protection scope of the present invention.

Claims

1. A discrete simulation task scheduling method based on a conditional waiting mechanism, characterized in that, The discrete simulation task scheduling method comprises the following steps: S1, a waiting task script is written, and a common device preset condition library is used to write a waiting condition; S2, the waiting task script code is processed through analysis, compilation and simulation, the task type in the waiting task script is identified, and the waiting task type comprises a condition waiting task and a time delay waiting task; S3, an independent thread is allocated for the processed waiting task script code, and the waiting task script enters an asynchronous processing flow; the main simulation thread is not affected by the execution of the waiting task script and continues to advance according to the simulation clock, thereby ensuring the continuity of the simulation process; S4, the waiting task type is identified, and differentiated scheduling logic is executed according to the waiting task type, and deadlock detection and processing are performed, thereby ensuring efficient and reliable execution of the task; S5, in the discrete simulation advancing process, the task state is recorded, the deadlock is detected in an event-driven manner, the deadlock is removed according to the priority order of the task, the task with low priority is terminated, and if there is no priority difference, the task is removed and then enters the waiting state.

2. The discrete simulation task scheduling method based on a conditional waiting mechanism according to claim 1, characterized in that, In the step S1, the common device preset condition library comprises a standardized condition template, a rule analysis module and a self-defined extension module, wherein the standardized condition template comprises a device state condition, a process dependence condition and a resource constraint condition commonly seen in an industrial simulation scene; When a user writes a script, the standardized condition template and the rule analysis module in the library are called to convert a condition expression into executable logic, a plurality of condition templates support combination using a logical operator, and the self-defined extension module provides an open interface to support the user in defining a new condition by writing a condition function and automatically incorporating the new condition into the common device preset condition library for management.

3. The discrete simulation task scheduling method based on condition waiting mechanism according to claim 1, characterized in that, In the step S3, the main simulation thread comprises: maintaining a simulation event table to drive the simulation clock in an event-driven manner; scheduling a core simulation task; listening to event triggering; coordinating the clock synchronization between the asynchronous task scheduling thread and the core simulation flow, thereby ensuring the overall timing consistency and flow continuity of the simulation scene.

4. The discrete simulation task scheduling method based on condition waiting mechanism according to claim 1, characterized in that, In the step S4, when the task type is identified as a condition waiting task, the following steps are executed: S41a, a wake-up order strategy is determined according to the judgment condition of the waitUntil function registered in the waiting task script, a timeout processing threshold is given, and a unique condition UUID identifier is generated for the association between the task and the condition; The wake-up order strategy is that the thread queue wake-up strategy of the same condition waiting task is FIFO or LIFO, and the strategy between the waiting tasks is priority wake-up, and the priority of the same waiting task is the same; S42a, a condition identifier is used to establish a bidirectional index between the condition and the task, including a forward index and a reverse index, to quickly query the task associated with the condition and the condition relied on by the task, update the task state to a new state, and record a timestamp; S43a, when the script of the task is executed for the first time, a first condition state evaluation is performed, if the condition is satisfied, the task is directly executed, the task state is updated to a completed state, and a timestamp is recorded; if the condition is not satisfied, the script thread is suspended, the task state is updated to a waiting state, and a timestamp is recorded; S44a, in the main simulation cycle, when a new event triggers and the simulation state changes, re-evaluate the condition state; when the condition is met, wake up the waiting task to continue execution, update the task state to the completed state, and record the timestamp; when the condition is not met and the timeout threshold is reached, end the task, update the task state to the timeout state, and record the timestamp.

5. The method of claim 1, wherein the condition-based waiting mechanism is based on a condition of a task. In the step S4, when the task type is identified as a delay waiting task, the following steps are performed: S41b, parse the time expression in the waitUntil function in the waiting task script, define the delay time period and cron complex time, calculate the task trigger time, generate a delay waiting task, update the task state to the new state, and record the timestamp; S42b, insert the delay waiting task into the delay queue based on the minimum heap, the minimum heap takes the task trigger time as the key to ensure that the earliest triggered task can be efficiently obtained each time, update the task state to the waiting state, record the timestamp, trigger the delay task according to the simulation system clock, and provide millisecond-level precision; S43b, when the simulation clock time reaches the trigger time, wake up the corresponding thread, update the task state to the completed state, and record the timestamp; if there are tasks that have not been processed beyond the trigger time, remove the timeout task, update the task state to the timeout state, and record the timestamp.

6. The discrete simulation task scheduling method based on condition waiting mechanism according to claim 4, characterized in that, Wherein, In the step S41a, both Boolean values and custom functions are supported to register dynamic evaluation conditions, the logical dependency between conditions is analyzed, and the Resource Allocation Graph Algorithm is used to detect circular dependencies between conditions to identify deadlocks and issue warnings, i.e., the task is treated as a process, and simulation resources such as devices, buffers, and previous process results are treated as resource nodes to construct a task-resource allocation graph, which is traversed, and if at least one closed loop is found, it is determined to be a deadlock.

7. The discrete simulation task scheduling method based on condition waiting mechanism according to claim 4, characterized in that, In the steps S43a and S44a, event triggering is used as the driving force to dynamically evaluate conditions, and a secondary evaluation of conditions is used to prevent false wake-ups, the same conditions are required for both evaluations, and the logical dependency between conditions is analyzed, and if a circular dependency is detected, a warning is issued and recorded.

8. The discrete simulation task scheduling method based on condition waiting mechanism according to claim 5, characterized in that, In the step S41b, the task trigger time is calculated, if the time expression is a delay time period, the simulation time after the delay time period is calculated based on the current simulation time, and the time is the task trigger time; If the time expression is a cron time expression, the task trigger time is calculated based on the user-provided periodicity cutoff condition and the current simulation time.

9. The method of claim 1, wherein the condition-based waiting mechanism is based on a condition of a task. In the step S5, the task state includes a new state, a waiting state, a completed state, and a timeout state, and the timestamp is recorded when the task state changes; Events that can drive deadlock detection include resource conflicts when a new task is created and occasional events during the simulation process; Traverse the task-resource allocation graph, identify and resolve possible waiting deadlocks, and when resolving: record the tasks, resources, and dependency chain involved in the deadlock, terminate low-priority tasks and release resources, update the allocation graph, and confirm that the deadlock loop has been resolved; if there is still a deadlock, continue to terminate the next low-priority task according to the priority until the deadlock is completely resolved.

10. The method of claim 1, wherein the method further comprises: In the step S5, the thread queue of the tasks in the waiting state is maintained according to the thread wake-up order, the thread resources that have completed the waiting are automatically cleaned up, and when the cleaning is performed, the task state is updated, the local resources are released, the thread destruction interface is called, the corresponding thread handle is removed from the thread queue, the tasks that are blocked for a long time are identified, and the timeout strategy is executed when the waiting time exceeds a preset threshold; and the emergency task queuing mechanism based on the priority is supported.

Images