Stage visual effect task execution and monitoring method and system based on priority scheduling

Abstract

The present application relates to the field of computer task scheduling, and particularly relates to a stage visual effect task execution and monitoring method and system based on priority scheduling. The method comprises: obtaining a stage visual effect task set, task dependency data, equipment resource state data, event trigger data, timing constraint data and priority rule data, and analyzing to generate task node information and equipment resource basic information; constructing a task dependency relationship graph and establishing resource occupation state information, and generating task resource constraint information; screening a schedulable task set that meets the dependency and has available equipment resources, calculating task scheduling priority and generating a task execution scheduling scheme; issuing equipment control instructions based on a task trigger event sequence, and updating the task execution plan and the task trigger event sequence according to the task execution state information. The present application effectively improves the continuity of the stage visual effect task execution link and the task abnormal scheduling capability.

Description

Technical Field

[0001] This invention relates to the field of computer task scheduling, and in particular to a method and system for executing and monitoring stage visual effects tasks based on priority scheduling. Background Technology

[0002] In the field of computer task scheduling and stage visual effects control technology, existing solutions for multi-channel stage visual effects tasks typically rely on the coordinated operation of a central control unit, stage control terminal, real-time rendering unit, projection unit, LED display unit, spatial audio unit, ambient light control unit, and equipment control interface. These solutions generally execute tasks such as projection screen switching, LED zone display, real-time rendering, ambient light switching, and spatial audio synchronization according to preset program segments, performance timecodes, manual triggering instructions, or equipment control procedures. The execution status on the equipment side is recorded through operating status parameters, equipment feedback data, or calibration feedback data.

[0003] Existing solutions can typically handle basic visual effects equipment control and status feedback in scenarios with a single program segment or a small number of tasks. However, in large-scale performances or immersive stage spaces, multiple stage visual effects tasks often involve pre-execution, synchronous triggering, resource mutual exclusion, and time offset relationships. The same projection channel, LED display zone, media server, real-time rendering node, or equipment control interface may also be occupied by multiple tasks consecutively or overlapping. If existing solutions only execute according to a fixed time sequence, multi-threaded task distribution, or manually configured rules, it is easy to encounter situations such as the separation of task dependencies from equipment resource status, discontinuity between task triggering conditions and actual execution status, and difficulty in writing back equipment feedback data to subsequent task processing links.

[0004] Existing solutions often rely on pre-set performance flows, fixed task queues, single device status feedback, or safety monitoring results for processing. When stage visual effects tasks time out, fail, become unresponsive, have missing trigger events, or experience resource conflicts, there is a lack of stable connection between the status of preceding tasks, the status of device resources, and the execution plan of subsequent tasks. This can easily lead to unexecuted tasks continuing to use the original execution order or trigger queue, resulting in inconsistencies between the task execution status and the device resource usage status.

[0005] For the joint processing of task dependency graphs, resource occupancy status information, and task execution status information under concurrent multi-channel stage visual effects tasks, existing technologies still have shortcomings, such as difficulty in linking task dependencies, resource occupancy, event triggering, and anomaly feedback. Therefore, it is necessary to address the issue of how to form a dynamically rescheduled task execution plan and task triggering event sequence based on task dependency graphs, resource occupancy status information, and task execution status information under concurrent multi-channel stage visual effects tasks, focusing on the execution and monitoring of stage visual effects tasks. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method for executing and monitoring stage visual effects tasks based on priority scheduling, comprising: S1. Acquire multi-source data, perform task data parsing, and generate task node information and basic equipment resource information; the multi-source data includes stage visual effects task sets, task dependency data, equipment resource status data, event triggering data, timing constraint data, and priority rule data; S2. Construct a task dependency graph based on the task node information, the task dependency data, and the device resource basic information; establish resource occupancy status information between the task nodes in the task dependency graph and the corresponding device resources; and generate task resource constraint information. S3. Based on the task resource constraint information, the timing constraint data and the priority rule data, filter the set of schedulable tasks that meet the dependencies and have available device resources, calculate the task scheduling priority and sort them, and generate a task execution scheduling scheme. S4. Generate a task trigger event sequence based on the task execution scheduling scheme and the event trigger data, issue device control instructions according to the event trigger conditions and the synchronization clock, associate the device feedback data with the task node, and generate task execution status information. S5. Based on the task execution status information, identify abnormal conditions in task execution, update the task dependency graph and the resource occupancy status information, recalculate the task scheduling priority for unexecuted tasks, and generate an adjusted task scheduling plan and an updated task triggering event sequence.

[0007] Furthermore, the task node information includes task identifier, task type, program segment, target equipment resources, estimated execution time, time window, task priority level, equipment resource requirements, and failure handling strategy; the task type includes projection screen switching task, LED zone display task, real-time rendering task, ambient light switching task, spatial audio synchronization task, material preloading task, calibration parameter loading task, and program switching task.

[0008] Furthermore, the task dependency graph includes task nodes and dependency edges; the dependency edges include preceding dependency edges, synchronous dependency edges, mutually exclusive dependency edges, and time offset dependency edges; the preceding dependency edge is written with the preceding task identifier, the synchronous dependency edge is written with the synchronization error tolerance, the mutually exclusive dependency edge is written with the mutually exclusive device resource identifier, and the time offset dependency edge is written with the offset time. The construction task dependency graph includes: The task node information is grouped; Generate a preceding dependency edge based on the preceding task identifier in the task dependency data; For multiple task nodes that need to be executed within the same synchronization error tolerance in the same program segment, generate synchronization dependency edges and write the synchronization error tolerance into the synchronization dependency edges; For multiple task nodes with the same target device resources and overlapping execution periods, mutually exclusive dependency edges are generated based on the mutually exclusive device resource identifiers; For task nodes with predetermined sequential offsets, generate time offset dependency edges and write the offset time into the time offset dependency edge.

[0009] Furthermore, the basic equipment resource information includes equipment identifier, equipment type, channel identifier, resource status, and control interface identifier; the resource occupancy status information includes task identifier, equipment identifier, channel identifier, occupancy start time, occupancy end time, and resource occupancy lock status. The establishment of resource occupancy status information includes: reading the target device resources, estimated execution time and time window from the task node information, reading the device identifier and channel identifier from the device resource basic information, and determining the device identifier, channel identifier, occupancy start time and occupancy end time occupied by each task node; The start time of occupation is taken from the trigger time in the time window, and the end time of occupation is obtained by adding the estimated execution duration to the start time of occupation. The task resource constraint information includes the task dependency graph, the resource occupancy status information, the dependency edge status, the resource occupancy lock status, and the resource occupancy conflict marker.

[0010] Furthermore, the set of schedulable tasks that satisfies dependencies and has available device resources includes: reading the preceding dependency status of task nodes in the task dependency graph; reading the resource occupancy lock status of the corresponding device resources in the resource occupancy status information; and writing task nodes whose preceding dependency status is completed and whose resource occupancy lock status is idle into the set of schedulable tasks.

[0011] Furthermore, the calculation and sorting of task scheduling priorities includes: reading the task priority level, remaining execution time, time window, preceding task delay time, resource waiting time, and device feedback information of each task node in the schedulable task set; generating the task scheduling priority of each task node according to the priority rule data; and sorting the schedulable task set according to the task scheduling priority.

[0012] Furthermore, the task execution scheduling scheme includes task execution order, task triggering conditions, target device resources, resource occupation time period, task scheduling priority, synchronization error tolerance, and status monitoring location; the task triggering event sequence includes event identifier, task identifier, trigger time, triggering conditions, synchronization clock identifier, device control command, and feedback field.

[0013] Furthermore, the triggering conditions include performance timecode triggering, program segment start triggering, pre-task completion triggering, interactive instruction triggering, and manual confirmation triggering; the equipment control instructions include task identifier, equipment identifier, channel identifier, control action, trigger time, synchronization error tolerance, and feedback field.

[0014] Furthermore, the task execution status information includes task identifier, device resource identifier, instruction issuance time, feedback reception time, execution result, and error code; the task execution abnormal conditions include task timeout, task failure, device unresponsiveness, resource occupation conflict, missing trigger event, and synchronization error exceeding the threshold; when the task execution abnormal conditions are met, the task plan version, event queue version, device feedback data, and rescheduling reason are recorded.

[0015] Furthermore, a stage visual effects task execution and monitoring system based on priority scheduling includes: a task data parsing module, a task constraint construction module, a task scheduling module, an event trigger execution module, a status monitoring module, and a task reordering module; the system is used to implement the method described in any of the above embodiments.

[0016] The key innovations of this invention include: (1) Parse the stage visual effects task set into task node information, and construct a task dependency relationship graph based on task dependency data. At the same time, establish resource occupancy status information between task nodes and corresponding equipment resources, and generate task resource constraint information containing task dependency relationship and equipment resource occupancy status.

[0017] (2) Based on task resource constraint information, timing constraint data and priority rule data, filter the set of schedulable tasks that meet the dependencies and have available device resources, calculate the task scheduling priority of the set of schedulable tasks and sort them, and generate a task execution scheduling scheme that includes task execution order, task triggering conditions, target device resources and synchronization error tolerance.

[0018] (3) Generate a task trigger event sequence based on the task execution scheduling scheme and event trigger data, issue equipment control instructions according to the event trigger conditions and the synchronization clock, associate the equipment feedback data with the task node to generate task execution status information, update the task dependency graph and resource occupation status information after identifying abnormal conditions of task execution, and generate an adjusted task scheduling plan and an updated task trigger event sequence.

[0019] The following are its main beneficial effects: (1) To address the problem of separating task dependency relationship from equipment resource status in the existing solution, task resource constraint information is formed by combining task dependency relationship graph and resource occupancy status information, so that stage visual effect tasks have both task order constraints and equipment resource occupancy constraints before entering subsequent sorting, thereby reducing the situation where task triggering and equipment resource status are inconsistent.

[0020] (2) To address the problem that fixed task queues are difficult to match the on-site state when multiple stage visual effects tasks are executed concurrently in the same program segment, the task execution scheduling scheme can form a task execution order based on dependency state, resource state and timing constraints by filtering the schedulable task set and sorting the task scheduling priority.

[0021] (3) To address the problem that device feedback data is difficult to write back to the subsequent task processing link, the task execution status information is generated by associating device feedback data with task nodes, and the task dependency graph and resource occupancy status information are updated under abnormal conditions, so that unexecuted tasks can form an adjusted task scheduling plan and an updated task trigger event sequence. Attached Figure Description

[0022] Figure 1 A flowchart illustrating the priority-based scheduling method for stage visual effects task execution and monitoring provided in this application embodiment; Figure 2 This is a structural block diagram of a priority-based scheduling-based stage visual effects task execution and monitoring system provided in an embodiment of this application. Detailed Implementation

[0023] Example 1: Refer to Figure 1 This is a flowchart illustrating the stage visual effects task execution and monitoring method based on priority scheduling provided in an embodiment of the present invention. The process may include at least steps S1-S5: S1. Receive stage visual effects task set, task dependency data, device resource status data, event trigger data, timing constraint data and priority rule data, parse the task data of the stage visual effects task set, and generate task node information and device resource basic information. S2. Construct a task dependency graph based on the task node information, the task dependency data, and the device resource basic information; establish resource occupancy status information between the task nodes in the task dependency graph and the corresponding device resources; and generate task resource constraint information. S3. Based on the task resource constraint information, the timing constraint data and the priority rule data, filter the set of schedulable tasks that meet the dependencies and have available device resources, calculate the task scheduling priority and sort them, and generate a task execution scheduling scheme. S4. Generate a task trigger event sequence based on the task execution scheduling scheme and the event trigger data, issue device control instructions according to the event trigger conditions and the synchronization clock, associate the device feedback data with the task node, and generate task execution status information. S5. Based on the task execution status information, identify abnormal conditions in task execution, update the task dependency graph and the resource occupancy status information, recalculate the task scheduling priority for unexecuted tasks, and generate an adjusted task scheduling plan and an updated task triggering event sequence.

[0024] S1. Receive stage visual effects task set, task dependency data, device resource status data, event trigger data, timing constraint data and priority rule data, parse the task data of the stage visual effects task set, and generate task node information and device resource basic information.

[0025] In this embodiment, S1 is executed by the task data parsing module in the stage visual effects control system. The task data parsing module is deployed in the central control unit, task scheduling server, or edge control node, and is communicatively connected to the network communication unit, device control interface module, and field control terminal. The task data parsing module receives stage visual effects task sets from performance program configuration files, performance scripts, visual effects control engineering files, or the centralized control platform, and simultaneously receives task dependency data, device resource status data, event trigger data, timing constraint data, and priority rule data. The stage visual effects task set is the basic processing object of this method, and it includes multiple tasks from the following categories: projection screen switching task, LED zone display task, real-time rendering task, ambient light switching task, spatial audio synchronization task, material preloading task, calibration parameter loading task, and program switching task.

[0026] Upon receiving the set of stage visual effects tasks, the task data parsing module first reads the task identifier, task type, program segment, target equipment resources, estimated execution time, time window, task priority level, equipment resource requirements, and failure handling strategy for each stage visual effects task. It then aggregates multiple stage visual effects tasks within the same program segment according to their task identifiers. The task type distinguishes the corresponding visual effects equipment actions, the program segment defines the task's position within the performance flow, and the target equipment resources indicate the projection channels, LED display zones, media servers, real-time rendering nodes, spatial audio units, ambient light control units, or equipment control interfaces required for subsequent execution. The task priority level is retrieved from priority rule data and serves as an input field for subsequent calculations of task scheduling priority.

[0027] The device resource status data comes from the visual effects equipment's operational status feedback, device resource list, control interface registration records, and current occupancy records. In this step, the device resource status data is parsed into basic device resource information. This basic information includes device identifier, device type, channel identifier, resource status, and control interface identifier. The device type is used to distinguish between projection units, LED display units, real-time rendering units, spatial audio units, ambient light control units, media servers, and network communication units. The resource status includes idle, occupied, unavailable, and waiting-to-be-released states. The control interface identifier is used to mark the device control interface invoked when subsequent device control commands are issued.

[0028] The event triggering data comes from the performance timecode system, program segment control terminal, interactive command input terminal, manual confirmation terminal, and pre-task receipt records. The timing constraint data includes trigger time, execution window, synchronization error tolerance, and allowed waiting time. The priority rule data includes rules for reading task priority levels, rules for calculating remaining task execution time, rules for reading pre-task delay time, rules for accumulating resource waiting time, and rules for referencing device feedback information. When reading the above data, the task data parsing module associates data from different sources according to task identifiers and program segment identifiers to generate task node information corresponding to the stage visual effects task.

[0029] In one implementation, when parsing the performance program configuration file, the task data parsing module registers the material preloading task, projection screen switching task, LED zone display task, spatial audio synchronization task, and ambient light switching task in program segment A as different task nodes. The target device resources for the material preloading task are the media server and the real-time rendering node; the target device resource for the projection screen switching task is the projection channel; the target device resource for the LED zone display task is the LED display zone; the target device resource for the spatial audio synchronization task is the spatial audio unit; and the target device resource for the ambient light switching task is the ambient light control unit. The task data parsing module writes the task identifier, task type, program segment, target device resource, and time window of the above tasks into the task node information, and writes the device identifier, channel identifier, and resource status of the corresponding device resources into the device resource basic information.

[0030] In this step, if the stage visual effects task set contains missing task identifiers, missing program segments, or mismatched target device resources, the task data parsing module will write the corresponding task to a pending review status and write the missing fields to the task execution log. If the device resource status data contains multiple control interface identifiers corresponding to the same device identifier and the interface statuses are inconsistent, the task data parsing module will retain the original interface records and mark the device resource status as pending confirmation. If the event trigger data and timing constraint data have inconsistent program segment identifiers, the task data parsing module will retain the task node information but mark the corresponding task's trigger condition as pending verification. The above anomaly markers are output along with the task node information for subsequent task dependency graph construction and candidate task filtering.

[0031] The output of S1 is task node information and basic equipment resource information. The task node information records the task identifier, task type, program segment, target equipment resources, estimated execution duration, time window, task priority level, equipment resource requirements, and failure handling strategy for the stage visual effects task. The basic equipment resource information records the equipment identifier, equipment type, channel identifier, resource status, and control interface identifier. The task node information and the basic equipment resource information are passed to the task dependency graph construction module and the resource management module, serving as input for S2 to construct the task dependency graph and establish resource occupancy status information.

[0032] S2. Construct a task dependency graph based on the task node information, the task dependency data, and the device resource basic information. Establish resource occupancy status information between the task nodes in the task dependency graph and the corresponding device resources, and generate task resource constraint information.

[0033] In this embodiment, S2 is jointly executed by the task dependency graph construction module and the resource management module. The task dependency graph construction module receives the task node information generated in S1 and reads the preceding task identifier, synchronization task identifier, mutually exclusive device resource identifier, and offset time recorded in the task dependency data. The resource management module receives the basic device resource information generated in S1 and establishes a device resource index according to the device identifier, device type, channel identifier, and resource status. The task dependency graph construction module and the resource management module associate data through the task identifier, target device resource, and program segment to form task resource constraint information that can be read by the subsequent task scheduling module.

[0034] The task dependency graph includes task nodes and dependency edges. The task nodes are derived from task node information generated by S1. The dependency edges include prerequisite dependency edges, synchronization dependency edges, mutual exclusion dependency edges, and time offset dependency edges. Prerequisite dependency edges contain a prerequisite task identifier, used to record the prerequisite task state that a task node must satisfy before entering the schedulable task set. Synchronization dependency edges contain synchronization error tolerances, used to record the relationship between multiple task nodes referenced by the task trigger event sequence within the same trigger window. Mutually exclusive dependency edges contain mutually exclusive device resource identifiers, used to record the mutual exclusion occupancy relationship of multiple task nodes on the same projection channel, LED display partition, media server, real-time rendering node, or device control interface. Time offset dependency edges contain offset times, used to record the trigger time offset relationship between ambient light switching tasks, spatial audio synchronization tasks, or projection screen switching tasks.

[0035] When constructing the task dependency graph, the module first groups the task node information according to the program segment to which they belong, and then generates preceding dependency edges based on the preceding task identifiers in the task dependency data. For multiple task nodes in the same program segment that need to be executed within the same synchronization error tolerance, the module generates synchronization dependency edges and writes the synchronization error tolerance into these edges. For multiple task nodes with the same target device resources and overlapping execution periods, the module generates mutually exclusive dependency edges based on mutually exclusive device resource identifiers. For task nodes with predetermined sequential offsets, the module generates time offset dependency edges and writes the offset time into these edges. The resulting task dependency graph contains both the execution relationships between task nodes and retains the constraint entry points of task nodes on device resources.

[0036] When establishing resource occupancy status information, the resource management module reads the device resource requirements from the task node information and the resource status from the device resource basic information. The resource occupancy status information includes the task identifier, device identifier, channel identifier, occupancy start time, occupancy end time, and resource occupancy lock status. For projection screen switching tasks, the resource management module writes the channel identifier of the corresponding projection channel based on the target device resources. For LED zone display tasks, the resource management module writes the device identifier and channel identifier of the LED display zone. For real-time rendering tasks and material preloading tasks, the resource management module writes the device identifiers of the media server and real-time rendering node, and forms a resource occupancy period based on the expected execution duration and time window. For ambient light switching tasks and spatial audio synchronization tasks, the resource management module writes the control interface identifiers of the corresponding ambient light control unit and spatial audio unit.

[0037] In one implementation, the material preloading task in program segment A serves as a prerequisite for both the projection screen switching task and the LED zone display task. The task dependency graph construction module establishes prerequisite dependency edges between the task nodes corresponding to the material preloading task and the task nodes corresponding to the projection screen switching task, and also establishes prerequisite dependency edges between the same material preloading task and the LED zone display task. The projection screen switching task and the LED zone display task need to be triggered within the same synchronization error tolerance; the task dependency graph construction module establishes synchronization dependency edges between the two task nodes. If both the projection screen switching task and the real-time rendering task occupy the same real-time rendering node, the resource management module writes the real-time rendering node into the resource occupancy status information of the two task nodes and generates a corresponding resource occupancy lock status.

[0038] In this step, if a prerequisite task identifier cannot be matched in the task node information within the task dependency data, the task dependency graph construction module marks the corresponding dependency edge as an invalid dependency edge and marks the corresponding task node as pending review. If the time windows of multiple task nodes corresponding to a synchronization dependency edge do not overlap, the task dependency graph construction module records synchronization error tolerance conflicts. If the resource management module reads that the resource status of the target device resource is unavailable, it marks the resource occupancy lock status of the resource occupancy status information as unavailable and writes this mark into the task resource constraint information. If the occupancy periods of multiple task nodes for the same device resource overlap, the resource management module retains the original occupancy periods of each task node and writes the resource occupancy conflict mark into the task resource constraint information.

[0039] The output of S2 is task resource constraint information. This information includes a task dependency graph, resource occupancy status information, dependency edge status, resource occupancy lock status, and resource occupancy conflict flags. This constraint information is passed to the task scheduling module as input for S3 to filter the set of schedulable tasks, calculate task scheduling priorities, and generate a task execution scheduling scheme. The task nodes and dependency edges in the task dependency graph are still referenced in subsequent steps (S5), and their status is updated after abnormal task execution conditions are identified.

[0040] In one specific embodiment: In S2, a task dependency graph is constructed based on the task node information, the task dependency data, and the device resource basic information. Resource occupancy status information is established between the task nodes in the task dependency graph and the corresponding device resources, and task resource constraint information is generated.

[0041] The task dependency graph construction module receives task node information from the task data parsing module and reads the preceding task identifier, synchronous task identifier, mutually exclusive device resource identifier, and offset time recorded in the task dependency data. The resource management module receives basic device resource information and establishes a device resource index according to device identifier, device type, channel identifier, and resource status. The task dependency graph construction module first groups the task node information according to the program segment it belongs to. Within the same program segment, it generates four types of dependency edges based on the task dependency data: preceding dependency edges (writing the preceding task identifier), synchronous dependency edges (writing the synchronization error tolerance), mutually exclusive dependency edges (writing the mutually exclusive device resource identifier), and time offset dependency edges (writing the offset time). To transform the above dependencies into a form that can be quantitatively calculated by the subsequent task scheduling module, the task dependency graph construction module introduces Formula ① to construct a dependency weight matrix. Formula ① extracts the dependency type parameters between each pair of task nodes from the task dependency data, uniformly quantifying the four constraints—preceding, synchronous, mutually exclusive, and time offset—into directed weighted edges, thus forming the algebraic expression of the task dependency graph. Formula ① is defined as follows:

[0042] in: From task node Point to task node The dependency weight, with a single dimension, has a range of values. The larger the value, the more tasks are performed. For the task The stronger the dependency or the stricter the constraint, the more algebraic the representation of the task dependency graph, calculated using formula ①.

[0043] : Task node index, value ,in This represents the total number of task nodes within the current program segment. The statistics are derived from the task identifier list in the task node information.

[0044] : Task node index, meaning the same as .

[0045] The baseline weight coefficient of the preceding dependency edge, with a dimension of one, is extracted from the dependency weight configuration field in the priority rule data.

[0046] : Pre-dependency indicator function, when the task dependency data contains "task" It is a task The value of "preceding task" is 1 if the record is set to this value, and 0 otherwise. This record is read from the preceding task identifier field in the task dependency data.

[0047] The baseline weight coefficient of the synchronous dependency edge, with a dimension of one, is extracted from the dependency weight configuration field in the priority rule data.

[0048] Synchronization dependency indicator function, when task and tasks Edges belonging to the same synchronization dependency relationship and The value is 1 if the condition is met, and 0 otherwise. The records for synchronous dependency edges are derived from the synchronous task identifier field in the task dependency data.

[0049] :Task The synchronization error tolerance, in milliseconds, is extracted from the synchronization error tolerance field written in the synchronization dependency edge.

[0050] The baseline weight coefficient for mutually exclusive dependency edges, with a dimension of one, is extracted from the dependency weight configuration field in the priority rule data.

[0051] : Mutual exclusion dependency indicator function, when task and tasks The value is 1 if the target device resources belong to the same mutex device resource identifier record, and 0 otherwise. The mutex device resource identifier is read from the mutex device resource identifier field in the task dependency data.

[0052] Resource conflict penalty factor, with a dimension of one, is obtained by mapping the resource status field of the corresponding device identifier in the device resource basic information: if the resource status is "occupied" or "unavailable", the value is 2; if it is "idle", the value is 1; if it is "waiting to be released", the value is 1.5.

[0053] The baseline weight coefficient for time-offset dependency edges, with a dimension of one, is extracted from the dependency weight configuration field in the priority rule data.

[0054] : Time offset dependency indicator function, when the task dependency data records the time offset from the task To the mission The value is 1 for the offset time and 0 otherwise. This record is read from the offset time field in the task dependency data.

[0055] Offset time, in milliseconds, extracted from the offset time field written in the time offset dependency edge. It can be positive or negative; a positive value indicates a positive task. In the mission Delay after completion Triggered in milliseconds; negative values ​​indicate early triggering.

[0056] Data source mapping: Extract the preceding task identifier, synchronization task identifier, mutual exclusion device resource identifier, and offset time from the "task dependency data," and map them respectively to... , , and The resource status field extracted from "Equipment Resource Basic Information" is mapped to... Dependency weight coefficients are extracted from "priority rule data". .

[0057] Simple numerical example: Suppose there are 3 task nodes in program segment A: Task 1 (material preloading), Task 2 (projection screen switching), and Task 3 (LED zone display). Task dependency data record: Task 1 is a prerequisite task for Task 2 ( Task 1 is a prerequisite for Task 3. Task 2 and Task 3 have a synchronization dependency. Synchronization error tolerance (milliseconds), Task 2 and Task 3 mutually exclude each other from using the same projection channel ( The device resource status is "idle". ), with no time offset dependency. Take .but , , , .

[0058] The dependency weight matrix output by formula ① The non-zero elements in the matrix record the constraint strength between task nodes. This matrix, as the core algebraic representation of the task dependency graph, is passed to the resource management module for subsequent association of resource occupancy status information.

[0059] The dependency weight matrix generated by formula ① The resource management module begins establishing resource occupancy status information. It reads the target device resources, estimated execution duration, and time window from the task node information, as well as the device identifier, channel identifier, and control interface identifier from the basic device resource information. For each task node... The resource management module determines the device identifier occupied based on its target device resources. and channel signage And based on the trigger time in the time window and expected execution time Calculate the start time of occupation and the end time of occupation To quantify the degree of conflict in resource occupancy among multiple tasks on the same device, the resource management module introduces Formula ② to calculate the overlap matrix of occupancy periods. Formula ② uses the start and end times of each task's occupancy to calculate the time overlap length between any two tasks on the same device resource. This overlap will serve as the direct basis for subsequent judgments on resource occupancy locking status and conflict flags. Formula ② is defined as follows:

[0060] in: Task Node and task nodes The length of overlap in the time periods occupied by the same device resources, in milliseconds, with a range of values. The result is calculated using formula ② and is used to quantify the degree of resource competition.

[0061] : Task node index, same as formula ①.

[0062] : Task node index, same as formula ①.

[0063] This function returns the maximum value among the arguments specified in parentheses. Ensure that the overlap length is non-negative.

[0064] : Minimum value function, returns the minimum value among the parameters in parentheses.

[0065] :Task The end time of occupation, in milliseconds, is determined by... The calculation yielded, where To occupy the start time, This is the estimated execution time. The trigger time is taken from the time window in the task node information (such as the performance timecode or the offset after the start of the program segment). Extracted from the expected execution time field of the task node information.

[0066] :Task The end time of occupation, in milliseconds, has the same meaning as... .

[0067] :Task The start time of occupation, in milliseconds, is taken from the trigger time field of the time window in the task node information.

[0068] :Task The start time of occupation, in milliseconds, has the same meaning as... .

[0069] : Same device indication function, when task and tasks The value is 1 if the target device resource points to the same device identifier, and 0 otherwise. The device identifier is read and matched from the device identifier field in the device resource basic information.

[0070] Data source mapping: Estimated execution time extracted from "task node information" and the trigger time in the time window jointly determined and The equipment identifier is extracted from the "Equipment Resource Basic Information" for construction. .

[0071] Simple numerical example: Continuing with tasks 1, 2, and 3 above, let the time window trigger time be: Task 1 milliseconds, estimated execution time milliseconds, therefore milliseconds; Task 2 millisecond, millisecond, milliseconds; Task 3 millisecond, millisecond, Milliseconds. Tasks 2 and 3 use the same projection device, therefore... .calculate Milliseconds. Task 1 and Task 2 use different devices. Therefore The overlap matrix output by formula ② The time competition level of each pair of tasks on the same device was recorded. Subsequently, the resource management module applied the dependency weights from formula ①. Overlap with Formula ② By associating these factors, a comprehensive constraint strength is generated for each task node. Formula ③ is introduced for this purpose, which applies to each task node. Aggregate all pointers Dependency weights and all related to The overlap of related resource usage is used to quantify the task. The overall constraint level in the task dependency graph and resource occupancy status information, and the strength of this constraint, will be used in subsequent steps to determine the urgency of task scheduling and the risk of resource conflicts. Formula ③ is defined as follows:

[0072] in: Task Node The comprehensive constraint strength, dimensionless, with a range of values. The larger the value, the more tasks are performed. The stronger the pre-dependency constraints and resource consumption conflicts, the better. This is calculated using formula ③ and written into the task resource constraint information.

[0073] : Task node index, value , the same as formula ①.

[0074] :right From 1 to Summation, This represents the total number of task nodes within the current program segment, calculated from the task identifier list in the task node information.

[0075] The task node obtained from formula ① Point to task node The dependency weight. When hour .

[0076] : Constant 1, dimensionless.

[0077] :right From 1 to Sum.

[0078] The task obtained from formula ② With the task The overlap of the occupied time periods, in milliseconds.

[0079] The same device indication function, defined in formula ②, is used to determine the task. and tasks Does it occupy the same device resources?

[0080] : Sum of index variables, and Both are task node indices, with different values. .

[0081] Data source mapping: Formula ③ directly references the output of Formula ① and the output of formula ② .

[0082] Simple numerical example: Continuing with tasks 1, 2, and 3 above, calculate... First take , , (From formula ①) Then calculate. : hour , hour (No overlap in the same tasks) hour and Therefore, the sum is 100. The same calculation applies. , .but Comprehensive constraint strength vector middle, Calculated (No dependency pointing to Task 1) and Symmetrically, we get 7880. This vector is written into the task resource constraint information for subsequent steps to identify highly constrained tasks.

[0083] Obtaining the comprehensive constraint strength vector Then, the task dependency graph construction module and the resource management module jointly generate the remaining fields of the task resource constraint information: dependency edge status, resource occupancy lock status, and resource occupancy conflict flag. The dependency edge status is determined according to formula ①. Initialization checks for whether the value is greater than zero and the actual completion status of prerequisite dependencies. During initial construction, the state of all prerequisite dependency edges is set to "incomplete," the state of synchronization dependency edges is set to "pending synchronization," the state of mutual exclusion dependency edges is set to "available," and the state of time offset dependency edges is set to "offset pending trigger." Initialization of resource occupancy lock status requires consideration of mutual exclusion dependencies and the overlap of occupancy periods. Therefore, Formula ④ is introduced. This formula determines whether each pair of tasks should generate a resource lock based on the mutual exclusion dependency indicator and the overlap of occupancy periods, and outputs the lock status value of the current task on each device resource. Formula ④ is defined as follows:

[0084] in: Equipment Resources The resource occupancy lock status boolean value, which takes the value 0 (idle) or 1 (locked). Calculated by formula ④, it is written into the resource occupancy lock status field in the task resource constraint information.

[0085] The equipment resource index is determined by the list of equipment identifiers in the basic equipment resource information.

[0086] The logical OR operator, for... From 1 to Iterate through, if any If the condition is met, the result is 1 (true); otherwise, it is 0.

[0087] The logical OR operator, for... Iterating over all is not equal to Task node index.

[0088] : Mutually exclusive dependency indicator function, as defined in formula ①.

[0089] : Same device indication function, defined in the same formula ②.

[0090] The logical OR operator connects two subexpressions.

[0091] The logical OR operator, for... Iterating over all is not equal to Task node index.

[0092] Indicative function, when the overlap is calculated by formula ② The value is 1 if it is greater than 0, and 0 otherwise.

[0093] : Function indicating device occupancy by a task, when the task... Target device resources pointing to devices The value is 1 if the condition is met, and 0 otherwise. Device matching is based on the device identifier in the device resource basic information.

[0094] Total number of task nodes, same as formula ③.

[0095] These are all task node indexes, with the same meaning as before.

[0096] Data source mapping: Mutual device resource identifier from "Task Dependency Data"; and Matching device identifiers from "Basic Equipment Resource Information"; From formula ②.

[0097] Simple numerical example: Device resources For projection channel 1, both task 2 and task 3 occupy this device. , Furthermore, Task 2 and Task 3 have a mutual exclusion dependency. ),at the same time For Logical OR condition is true: Include When it is 1, Include When it is 1, both or later with Multiplying them together gives 1, therefore (Locked). For devices that are not occupied by any tasks or have no conflicts, .

[0098] The resource occupancy and locking state vector output by formula ④ Conflict markers between dependency edge states and resource usage (by...) and The data structure, which includes a task dependency graph (containing task nodes and algebraic representations of four types of dependency edges), is packaged together with the generated markers to form task resource constraint information. Resource occupancy status information (including device identifier, channel identifier, and occupancy start time for each task) End time of occupation Resource occupancy locked state The task resource constraint information, including dependency edge status, resource occupancy lock status, and resource occupancy conflict markers, is passed to the task scheduling module as input for S3 to filter the set of schedulable tasks, calculate task scheduling priorities, and generate task execution scheduling schemes. Simultaneously, task nodes and dependency edges in the task dependency graph are referenced in subsequent S5, and their states are updated after abnormal task execution conditions are identified. The technical effect of this section is that by quantifying the four types of dependency edges in the task dependency data into a weighted dependency matrix and associating it with the time period overlap in the resource occupancy status information, structured task resource constraint information containing dependency edge status, resource occupancy lock status, and conflict markers is generated. This provides a directly readable algebraic constraint basis for subsequent priority scheduling and abnormal task scheduling. This association modeling method allows candidate task selection to consider both dependency satisfaction and resource availability, unlike separate schemes that only consider task order or only device status.

[0099] S3. Based on the task resource constraint information, the timing constraint data and the priority rule data, filter the set of schedulable tasks that meet the dependencies and have available device resources, calculate the task scheduling priority and sort them, and generate a task execution scheduling scheme.

[0100] In this embodiment, S3 is executed by the task scheduling module. The task scheduling module receives the task resource constraint information generated in S2 and reads the timing constraint data and priority rule data. The task resource constraint information provides task nodes, dependency edges, resource occupancy status information, resource occupancy lock status, and resource occupancy conflict flags. The timing constraint data provides the trigger time, execution window, and synchronization error tolerance. The priority rule data provides the value rules for task priority level, remaining task execution time, preceding task delay time, resource waiting time, and device feedback information. Based on the above inputs, the task scheduling module generates a set of schedulable tasks and calculates the task scheduling priority for the task nodes in the set.

[0101] The schedulable task set is a set of task nodes selected from the task dependency graph. The task scheduling module reads the pre-dependency status of each task node in the task dependency graph and the resource occupancy lock status of the corresponding device resource in the resource occupancy status information. When the pre-dependency status is completed and the resource occupancy lock status is idle, the task scheduling module writes the corresponding task node into the schedulable task set. When the pre-dependency status is incomplete, pending review, or invalid, the corresponding task node remains in a waiting state. When the pre-dependency status is completed but the resource occupancy lock status is occupied, unavailable, or there is a resource occupancy conflict, the corresponding task node is not written into the schedulable task set for the current round, and the cumulative record of resource waiting time is retained.

[0102] When calculating task scheduling priorities, the task scheduling module reads the task priority level, remaining execution time, time window, preceding task delay time, resource waiting time, and device feedback information for each task node in the schedulable task set. The remaining execution time is determined by the current synchronization clock time and the end time of the task time window. The preceding task delay time is read from the preceding task's execution status information or task plan version record. The resource waiting time is the cumulative waiting time before the resource's locked state changes from occupied to idle. The device feedback information comes from the previous round's task execution status information or from the running status field in the device resource status data. The task scheduling module matches and sorts these fields according to priority rule data to generate the task scheduling priority for each task node.

[0103] In one implementation, the schedulable task set simultaneously includes projection screen switching tasks, LED zone display tasks, and ambient light switching tasks. The projection screen switching task has a higher priority level, and its time window is close to its end time; the LED zone display task has a synchronization dependency edge with the projection screen switching task; the ambient light switching task has a time offset dependency edge with the projection screen switching task. After reading the above dependencies, the task scheduling module sorts the projection screen switching task and the LED zone display task as the same synchronization group, and generates a corresponding trigger offset for the ambient light switching task based on the time offset dependency edge. If the resource waiting time of the real-time rendering node has been written into the task resource constraint information, the task scheduling module uses this field as input for calculating the task scheduling priority.

[0104] The task execution scheduling scheme includes task execution order, task triggering conditions, target device resources, resource occupation time period, task scheduling priority, synchronization error tolerance, and status monitoring location. The task execution order is formed by sorting the set of schedulable tasks. The task triggering conditions are derived from event triggering data and a task dependency graph. The target device resources and resource occupation time period are derived from resource occupation status information. The task scheduling priority is derived from the sorting result of the task scheduling module. The synchronization error tolerance is derived from synchronization dependency edges or timing constraint data. The status monitoring location corresponds to the collection fields of subsequent task execution status information and is used to indicate the task identifier, device resource identifier, and feedback field that need to be associated when the device feedback data is transmitted back.

[0105] In this step, if the schedulable task set is empty, the task scheduling module reads the prerequisite dependencies and resource occupancy lock status of waiting task nodes and generates a waiting status record. If multiple task nodes in the schedulable task set have the same task scheduling priority, the task scheduling module re-sorts them according to the time window end time, resource waiting time, and task identifier. If the device feedback information of a task node indicates that the target device resource is unavailable, the task scheduling module removes the task node from the current round of schedulable task set and writes the device feedback information to the status monitoring position of the task execution scheduling scheme. If the priority rule data version is inconsistent with the rule version in the task node information, the task scheduling module retains the previous version of the priority rule data and writes a version inconsistency marker in the task execution log.

[0106] The output of S3 is a task execution scheduling scheme. This scheme is passed to the event queue module as input for S4 to generate the task trigger event sequence. The task execution order, task triggering conditions, target device resources, resource occupancy time period, task scheduling priority, synchronization error tolerance, and status monitoring location from the task execution scheduling scheme are written into the event identifier, task identifier, trigger time, triggering condition, synchronization clock identifier, device control command, and feedback fields of the task trigger event sequence, respectively. The planned version of the task execution scheduling scheme is also written to the task execution log and serves as the object of version replacement or version correction when S5 generates the adjusted task scheduling plan.

[0107] S4. Based on the task execution scheduling scheme and the event triggering data, generate a task triggering event sequence, issue device control instructions according to the event triggering conditions and the synchronization clock, associate the device feedback data with the task node, and generate task execution status information.

[0108] In this embodiment, S4 is jointly executed by the event queue module, the device control interface module, and the status monitoring module. The event queue module receives the task execution scheduling scheme generated in S3 and reads the event trigger data. The device control interface module receives the task trigger event sequence formed by the event queue module and issues device control commands according to the event trigger conditions and the synchronization clock. The status monitoring module receives the device feedback data returned by the visual effects device and associates the device feedback data with the task node to generate task execution status information.

[0109] The task trigger event sequence includes an event identifier, a task identifier, a trigger time, a trigger condition, a synchronization clock identifier, a device control command, and a feedback field. The event identifier is used to mark a trigger event. The task identifier comes from a task node in the task execution scheduling scheme. The trigger time comes from timing constraint data and resource occupancy periods in the task execution scheduling scheme. The trigger condition includes performance timecode triggering, program segment start triggering, pre-task completion triggering, interactive command triggering, and manual confirmation triggering. The synchronization clock identifier is used to mark the synchronization clock source referenced by this task trigger event sequence. The device control command includes a task identifier, device identifier, channel identifier, control action, trigger time, synchronization error tolerance, and a feedback field.

[0110] When generating a task trigger event sequence, the event queue module first reads the task nodes according to the task execution order in the task execution scheduling scheme, and then generates event identifiers based on the task trigger conditions. For tasks triggered by performance timecodes, the event queue module writes the performance timecode into the trigger time. For tasks triggered by the start of a program segment, the event queue module writes the program segment start event into the trigger conditions and writes the current program segment identifier into the event identifier. For tasks triggered by the completion of a preceding task, the event queue module reads the task execution status information corresponding to the preceding task and generates a trigger record when the execution result of the preceding task is completed. For tasks triggered by interactive instructions, the event queue module reads the instruction identifier and trigger time from the interactive instruction and associates them with the corresponding task identifier. For tasks triggered by manual confirmation, the event queue module reads the confirmation identifier returned by the manual confirmation terminal and writes the confirmation identifier into the trigger conditions.

[0111] When the device control interface module issues device control commands, it first reads the synchronization clock identifier and trigger time from the task trigger event sequence, and then reads the corresponding task's device identifier, channel identifier, control action, synchronization error tolerance, and feedback field. If the current synchronization clock time enters the trigger window corresponding to the trigger time, and the event trigger condition is consistent with the trigger condition in the task trigger event sequence, the device control interface module sends the device control command to the control interface of the target visual effects device. For projection screen switching tasks, the device control command is written to the projection channel and control action. For LED zone display tasks, the device control command is written to the LED display zone and control action. For real-time rendering tasks, the device control command is written to the real-time rendering node and rendering control action. For spatial audio synchronization tasks, the device control command is written to the spatial audio unit and synchronization error tolerance. For ambient light switching tasks, the device control command is written to the ambient light control unit and control action.

[0112] When the status monitoring module collects device feedback data, it reads the task identifier, device identifier, and feedback field written by the device control interface module when issuing commands. The device feedback data includes control command receipts, operating status parameters, feedback reception time, execution result, and error code. The status monitoring module associates the device feedback data with the task identifier in the task node information and writes it into the task execution status information. The task execution status information includes the task identifier, device resource identifier, command issuance time, feedback reception time, execution result, and error code. For multiple task nodes with synchronous dependency edges, the status monitoring module also reads the synchronization error tolerance and writes the feedback reception time of multiple task nodes into the same synchronization status record.

[0113] In one implementation, the task triggering event sequence includes a projection screen switching task and an LED zone display task. Both tasks share the same synchronization clock identifier and synchronization error tolerance. The event queue module generates corresponding event identifiers and task identifiers, and outputs two device control commands to the device control interface module. When the synchronization clock enters the trigger window, the device control interface module sends device control commands to the projection unit and the LED display unit, respectively. The status monitoring module receives the control command acknowledgments returned by the projection unit and the execution results returned by the LED display unit, and associates the two device feedback data with the corresponding task nodes, generating task execution status information including task identifier, device resource identifier, command issuance time, feedback reception time, execution result, and error code.

[0114] In this step, if the triggering condition in the task triggering event sequence is not met within the triggering window, the event queue module marks the corresponding event identifier as a missing triggering event. If the synchronization clock identifier cannot be read, the event queue module caches the corresponding task node and writes the synchronization clock exception to the task execution log. If the device control interface module does not receive device feedback data within the waiting time corresponding to the preset feedback field after issuing the device control command, the status monitoring module writes the feedback reception time to a null value state and marks the execution result as no device response. If the error code in the device feedback data does not match the control action in the device control command, the status monitoring module retains the original error code and writes the device feedback data to a pending review state.

[0115] The output of S4 is task execution status information. This information is passed to the exception handling module as input for S5 to identify abnormal conditions in task execution. The task identifier, device resource identifier, instruction issuance time, feedback reception time, execution result, and error code in the task execution status information are used to identify task timeout, task failure, device unresponsiveness, resource conflict, missing trigger event, and synchronization error exceeding the threshold, respectively. The event queue version of the task trigger event sequence is written to the task execution log and is used as the update object when S5 generates an updated task trigger event sequence.

[0116] S5. Based on the task execution status information, identify abnormal conditions in task execution, update the task dependency graph and the resource occupancy status information, recalculate the task scheduling priority for unexecuted tasks, and generate an adjusted task scheduling plan and an updated task triggering event sequence.

[0117] In this embodiment, S5 is executed by the exception handling module and the task rescheduling module. The exception handling module receives the task execution status information generated in S4 and identifies exceptions according to the task execution exception conditions. The task rescheduling module receives the exception event data generated by the exception handling module and reads the task dependency graph, resource occupancy status information generated in S2, and the task execution scheduling scheme generated in S3. The task rescheduling module updates the task dependency graph and resource occupancy status information based on the exception event data, recalculates the task scheduling priority for unexecuted tasks, and generates an adjusted task scheduling plan and an updated task trigger event sequence.

[0118] The abnormal conditions for task execution include task timeout, task failure, device unresponsiveness, resource occupation conflict, missing trigger event, and synchronization error exceeding the threshold. When the exception handling module identifies a task timeout, it reads the instruction issuance time, feedback reception time, and estimated execution duration from the task execution status information, matches the feedback reception time with the end time corresponding to the estimated execution duration, and generates a task timeout flag. When the exception handling module identifies a task failure, it reads the execution result and error code, matches the error code with the failure handling strategy, and generates a task failure flag. When the exception handling module identifies a device unresponsiveness, it reads whether the feedback reception time is null and combines it with the device resource identifier to generate a device unresponsiveness flag. When the exception handling module identifies a resource occupation conflict, it reads the occupation period and resource occupation lock status of the same device resource from the resource occupation status information, and generates a resource occupation conflict flag. When the exception handling module identifies a missing trigger event, it reads the trigger conditions and actual trigger records from the task trigger event sequence, and generates a missing trigger event flag. When the exception handling module identifies that the synchronization error exceeds the threshold, it reads the synchronization error tolerance in the synchronization dependency edge and the feedback reception time of multiple task nodes to generate a synchronization error exceeding the threshold flag.

[0119] After generating exception event data, the exception handling module transmits the exception event data to the task rescheduling module. The exception event data includes task identifier, device resource identifier, exception type, exception occurrence time, error code, and affected dependency edge identifiers. The task rescheduling module updates the task dependency graph based on the exception event data. For task nodes that fail or time out, the task rescheduling module writes the task status of that task node to the failure or timeout state and updates the preceding dependency edges originating from that task node. For task nodes with missing trigger events, the task rescheduling module writes the event identifier corresponding to that task node to the pending trigger state. For synchronization task groups where the synchronization error exceeds the threshold, the task rescheduling module updates the synchronization status in the synchronization dependency edges and writes the unexecuted tasks in the synchronization task group into the affected task scope.

[0120] When updating resource occupancy status information, the task rescheduling module reads the device resource identifier from the exception event data and the occupancy period from the resource occupancy status information. For device resources that are unresponsive, the task rescheduling module updates the corresponding resource occupancy lock status to unavailable and releases resource occupancy records unrelated to that device resource. For device resources with resource occupancy conflicts, the task rescheduling module reads multiple task identifiers and occupancy periods corresponding to the same resource and marks the resource occupancy status information corresponding to unexecuted tasks as pending rescheduling. In cases where a task fails but the device resource has been released, the task rescheduling module updates the corresponding resource occupancy lock status to idle and adds unexecuted tasks with prerequisite dependencies to the candidate rescheduling scope.

[0121] When recalculating the scheduling priority of unexecuted tasks, the task reordering module reads the updated task dependency graph, updated resource occupancy status information, and unexecuted tasks and priority rule data from the original task execution scheduling scheme. The module filters affected unexecuted tasks and reads the task priority level, remaining execution time, time window, predecessor task delay time, resource waiting time, and device feedback information for each unexecuted task. For unexecuted tasks affected by abnormal tasks, the module re-determines whether they should be included in the schedulable task set based on the updated predecessor dependency status and resource occupancy lock status. Unexecuted tasks included in the schedulable task set have their scheduling priorities recalculated according to the priority rule data and are reordered to form an adjusted task scheduling plan.

[0122] The adjusted task scheduling plan includes the updated task execution order, task triggering conditions, target device resources, resource occupancy time periods, task scheduling priority, synchronization error tolerance, and status monitoring location. The event queue module generates an updated task triggering event sequence based on the adjusted task scheduling plan. The updated task triggering event sequence includes updated event identifiers, task identifiers, trigger times, triggering conditions, synchronization clock identifiers, device control commands, and feedback fields. For completed tasks, the updated task triggering event sequence retains their execution records and does not generate new device control commands. For unexecuted tasks, the updated task triggering event sequence is rearranged according to the updated trigger times and triggering conditions. For tasks marked as skipped, retried, or degraded, the updated task triggering event sequence writes the corresponding failure handling strategy field.

[0123] In one implementation, the material preloading task is marked as timed out in S4. The exception handling module generates a timeout flag based on the instruction issuance time, feedback reception time, and error code in the task execution status information and writes the flag into the exception event data. After reading the task dependency graph, the task rescheduling module identifies that both the projection screen switching task and the LED zone display task use the aforementioned material preloading task as a prerequisite task. The task rescheduling module updates the state of the prerequisite dependency edge and reads the resource occupancy and locking status of the media server and the real-time rendering node. If the resource status corresponding to the backup media server is idle, the task rescheduling module updates the target device resource of the material preloading task to the backup media server and recalculates the task scheduling priority of this task and subsequent projection screen switching tasks, LED zone display tasks, and ambient light switching tasks. The adjusted task scheduling plan is passed to the event queue module, and an updated task trigger event sequence is generated.

[0124] In this step, if the exception handling module cannot match the error code in the task execution status information to the failure handling policy, it will write the corresponding task node to a pending review status and retain the unaffected task execution order in the original task execution scheduling scheme. If resource usage conflicts still exist after the update, the task rescheduling module will keep the conflicting tasks in a waiting state and record the rescheduling reason. If the time window for the unexecuted task has ended, the task rescheduling module will write the task to a skipped, retry, or pending manual confirmation status according to the failure handling policy. If the task plan version and the event queue version are inconsistent, the task rescheduling module will record the task plan version, event queue version, device feedback data, and rescheduling reason, and write the updated task trigger event sequence version to the task execution log.

[0125] The output of S5 is the adjusted task scheduling plan and the updated task triggering event sequence. The adjusted task scheduling plan is passed to the event queue module to replace or correct the plan segments corresponding to unexecuted tasks in the original task execution scheduling scheme. The updated task triggering event sequence is passed to the device control interface module for issuing device control commands in subsequent rounds according to the event triggering conditions and synchronization clock. The task plan version, event queue version, device feedback data, and rescheduling reason are written to the task execution log and are associated with task node information, task dependency graph, and resource occupancy status information.

[0126] In one specific embodiment: In S5, based on the task execution status information, abnormal conditions of task execution are identified, the task dependency graph and the resource occupancy status information are updated, the task scheduling priority of unexecuted tasks is recalculated, and an adjusted task scheduling plan and an updated task triggering event sequence are generated.

[0127] The exception handling module receives task execution status information from the status monitoring module. This data includes task identifier, device resource identifier, instruction issuance time, feedback reception time, execution result, and error code. It also reads the estimated execution duration and failure handling strategy from the task node information, as well as the triggering conditions and actual triggering records from the task triggering event sequence. The task rescheduling module reads the task dependency graph generated by S2 (including pre-dependency edges, synchronization dependency edges, mutual exclusion dependency edges, time offset dependency edges, and their states), resource occupancy status information (including device identifier, channel identifier, occupancy period, and resource occupancy lock status), and the task execution scheduling scheme generated by S3 (including task execution order, task scheduling priority, synchronization error tolerance, etc.). To quantify the six types of abnormal conditions (task timeout, task failure, device unresponsiveness, resource occupancy conflict, missing trigger event, and synchronization error exceeding the threshold) into a computable rescheduling priority, the exception handling module introduces formula ⑤ to calculate the severity score of each abnormal event. Formula ⑤ adopts a weighted summation structure, which uniformly maps the exception type, exception occurrence time, error code severity level, and number of affected dependency edges into numerical values, thereby solving the practical problem that "different exception types have different degrees of impact on the execution of subsequent tasks, and need to be uniformly quantified to determine the rescheduling order".

[0128] Formula⑤

[0129] in: : Abnormal events The severity score is dimensionless and ranges from [value range missing]. The result, calculated using formula ⑤, is written into the "Rescheduling Urgency" field of the exception event data.

[0130] : Abnormal event index. Each abnormal event corresponds to an abnormality that occurs on a task node or a device resource. It is generated by the abnormality handling module when identifying abnormal conditions.

[0131] : Anomaly type weight coefficient, with a dimension of one, extracted from the anomaly weight configuration table in the priority rule data.

[0132] : Exception type getter function, when an exception event occurs. The value is 3 for "Task Timeout" or "Task Failure", 4 for "Device Not Responding", 2 for "Resource Occupation Conflict", 1 for "Missing Trigger Event", and 2 for "Synchronization Error Exceeds Threshold". This value is obtained by the exception handling module based on the error code and exception marker in the task execution status information, and has a dimension of one.

[0133] Error code weight coefficient, with a dimension of one, is extracted from the error code severity level table in the priority rule data.

[0134] The error code severity level function is used by the exception handling module to read the error code field from the task execution status information and match it with the level mapping in the failure handling strategy (e.g., error code E001 is mapped to 3, and E002 is mapped to 2), with a dimension of one.

[0135] : Exponential decay function, with natural constant With the base as the index is It has one dimension.

[0136] Time decay factor, the reciprocal of the time decay factor in milliseconds. The value is 0.01, extracted from the attenuation parameter in the priority rule data.

[0137] The time difference between the time of the exception and the current system clock, in milliseconds, is calculated by the exception handling module, which reads the exception occurrence time field (taken from the instruction issuance time or feedback reception time) and calculates the difference between the current time and the time of the exception occurrence.

[0138] The dependency edge influence coefficient, with a single dimension, is extracted from the priority rule data.

[0139] : Affected by abnormal events The number of dependency edges that affect, among which This is the set of affected dependency edges. The task reordering module iterates through all preceding dependency edges originating from the abnormal task node in the task dependency graph, as well as the synchronization dependency edges and mutual exclusion dependency edges to which the task node resides, and adds the dependency edges whose state needs to be updated to this set. The summation result is an integer with a dimension of one.

[0140] Dependency edge index, traversal .

[0141] : Affected by abnormal events The set of dependency edges that influence.

[0142] Data source mapping: Error codes, instruction issuance time, and feedback reception time extracted from "task execution status information" are mapped to... and Extracted from "priority rule data" Extract the set of affected dependency edges from the "task dependency graph". .

[0143] Simple numerical example: Suppose a task times out exception ( ), Error code E001 corresponds to , Time difference of anomaly occurrence millisecond, Then the exponent term Number of affected dependency edges , .but .

[0144] Formula ⑤ outputs a severity score for each anomalous event. This score is written into the "Rescheduling Urgency" field in the abnormal event data. To further normalize the combined impact of multiple abnormal events into the update priority of resource occupancy status information, the task rescheduling module introduces formula ⑥, which uses soft maximum mapping to integrate the severity of multiple abnormal events on the same device resource into a resource rescheduling priority factor.

[0145] Formula 6 addresses the practical problem that "the same device resource may be affected by multiple anomalies at the same time (such as resource occupation conflicts and device unresponsiveness), and the order of resource occupation lock status updates needs to be comprehensively determined."

[0146] Formula⑥

[0147] in: Equipment Resources The resource rescheduling priority factor, with a dimension of one, has a value range of... The result is calculated using formula ⑥ and is used to determine the order of resource occupancy lock status updates.

[0148] The equipment resource index is determined by the list of equipment identifiers in the basic equipment resource information.

[0149] Regarding equipment resources The sum of the exponential severity of all abnormal events. For the natural constant An exponential function with base 0, outputting formula ⑤ The mapping is a positive number with a dimension of one.

[0150] : Occurs in device resources The collection of all abnormal events is obtained by the exception handling module based on the device resource identifier field in the abnormal event data.

[0151] Minimal positive numbers (e.g.) This prevents the denominator from being zero and the dimension from being one.

[0152] For all device resources The sum of the exponential severity of all the abnormal events and above is used as the normalized denominator. Traverse all device resource indexes.

[0153] Device resource index, and They have the same meaning, but are only used for iteration.

[0154] Data source mapping: determined by the device resource identifier field in "Abnormal Event Data" and formula ⑤. Together constitute And the exponential term.

[0155] Simple numerical example: Assuming device resources There are two abnormal events on (projection channel 1). , ,but Assume the sum of the severity scores across all global device resources is 5000. ,but Formula ⑥ outputs the resource rescheduling priority factor. Together with the affected dependency edge identifiers in the abnormal event data, they form a "rescheduling trigger vector". This vector is passed to the dependency graph update submodule and resource occupancy status information update submodule of the task reordering module, as input for updating the task dependency graph and resource occupancy status information in the second step of S5.

[0156] The severity score of the abnormality obtained from formula ⑤ The resource rescheduling priority factor obtained from formula ⑥ The task reordering module begins updating the task node states and dependency edge states in the task dependency graph. For each exception event... The task reordering module calculates the state update weight of dependency edges based on the anomaly type and the identifier of the affected dependency edge, using Formula ⑦. Formula ⑦ uses a linear combination method to integrate the anomaly severity, resource priority, and the original weight of the dependency edge, thereby determining the magnitude by which each dependency edge should be set to the "failed," "pending trigger," or "offset correction" state. This formula addresses the issue that "different anomalies have different degrees of impact on different types of dependency edges (preceding, synchronization, mutual exclusion, time offset), requiring quantification of the update magnitude to maintain task dependencies." Figure 1 The practical problem of "consistency".

[0157] Formula⑦

[0158] in: Dependency edge State update weights, with a single dimension and a range of values. The value calculated by formula ⑦ determines whether a dependency edge should be marked as "invalid", "pending trigger", or "offset correction".

[0159] : Dependency edge index, traversing all preceding dependency edges, synchronous dependency edges, mutually exclusive dependency edges, and time offset dependency edges in the task dependency graph.

[0160] Dependency edge The baseline weights are derived from formula ① in step S2. The corresponding edges are given, and the dimension is one.

[0161] : Dependency edge type adjustment coefficient, when the dependency edge The value is 2.0 for a preceding dependency edge, 1.5 for a synchronous dependency edge, 3.0 for a mutually exclusive dependency edge, and 1.0 for a time offset dependency edge. The values ​​are extracted from the dependency edge type coefficient table in the priority rule data and are all of one dimension.

[0162] Formula ⑤ outputs the severity score of the anomaly.

[0163] The maximum severity score among all current abnormal events, obtained by the exception handling module after calculating all abnormal events, with a dimension of one.

[0164] Synchronous adjustment coefficients, with a single dimension, are extracted from priority rule data.

[0165] : The resource rescheduling priority factor output by formula ⑥.

[0166] : Synchronize dependency indicator function, when the dependency edge The value is 1 if it is a synchronous dependency edge, and 0 otherwise, with a unit of one. This value comes from the synchronous task identifier field in the task dependency data.

[0167] Data source mapping: The dependency weight matrix is ​​taken from the "task dependency graph" and calculated by formula ①. and Taken from "priority rule data"; Taken from the Synchronization Task Identifier field in "Task Dependency Data".

[0168] Simple numerical example: Let the exception event be a task timeout. , The ratio is 0.82075; the affected edges are those with preceding dependencies. ,That , ,and Not a synchronous dependency edge ( ),but If this value is greater than 0, the task reordering module updates the state of the preceding dependency edge to "invalid" (because an abnormal task timeout prevents subsequent tasks from relying on this task to complete), and records the updated dependency edge state. For synchronous dependency edges, if the exception is a synchronization error exceeding the threshold, then... ,set up , Then the second item This further amplifies the updated weights. Formula ⑦ outputs the dependency edge states to update the weights. The update log is written to the task dependency graph, triggering a synchronous adjustment of resource occupancy status information. Subsequently, the task reordering module uses formula ⑧ to calculate the new locking status of each device resource in the resource occupancy status information.

[0169] Formula ⑧ employs a combination of logical judgment and weighted fusion, integrating the resource priority from Formula ⑥, the dependency edge update weights from Formula ⑦, and the release flags from the task execution status information to output a binary lock status update decision. This formula addresses the problem of "precisely determining whether device resources should remain locked, released, or marked as unavailable after an anomaly occurs."

[0170] Formula⑧

[0171] in: Equipment Resources The updated resource occupancy lock status boolean value takes the value of 0 (idle) or 1 (locked). Calculated using formula ⑧, the resource occupancy status information is written back.

[0172] : Boolean value of resource occupancy lock status before update, read from the resource occupancy lock status field in the resource occupancy status information, with a value of 0 or 1.

[0173] : Logical OR operator.

[0174] Regarding equipment resources All related dependency edges If formula ⑦ Greater than the locking threshold If the result is positive, the characteristic function takes the value of 1; otherwise, it takes the value of 0. Finally, a logical OR is performed on the entire set.

[0175] : with equipment resources The set of all related dependency edges, that is, the edges involving the device resource among all mutually exclusive or synchronous dependency edges in the task dependency graph, is obtained by the task reordering module traversing the task dependency graph according to the device resource identifier.

[0176] Indicator function, when It takes the value 1 when it is active and 0 otherwise, and has a dimension of one.

[0177] The lock threshold, with a unit of one and a value of 3.0, is extracted from the rescheduling threshold table in the priority rule data.

[0178] : Logical AND operator.

[0179] : Logical NOT operator.

[0180] Regarding equipment resources All tasks that can release resources Release its indicator function Perform a logical OR.

[0181] In terms of equipment resources The set of completed and releasable tasks is determined by the task reordering module by reading the execution result field (if the result is "complete" or "failed" and the failure handling strategy is "release resources") from the task execution status information and the resource occupation end time from the resource occupation status information.

[0182] : Task node index, belonging to a set .

[0183] :Task The resource release indicator function, when the task The value is 1 when the execution result is "complete" or "failed and release allowed", and 0 otherwise. It comes from the parsing of task execution status information by the exception handling module.

[0184] Data source mapping: The resource occupancy lock status is taken from the "Resource Occupancy Status Information"; It is constructed from the mutually exclusive dependency edges and synchronous dependency edges in the "task dependency graph"; Taken from "priority rule data"; and The results are taken from the "Task Execution Status Information" field, specifically the execution result field and the failure handling strategy field.

[0185] Simple numerical example: Assume the old locked state of projection channel 1. (Locked). There is a mutually exclusive dependency edge among the related dependency edges. ,but If the condition is met, take 1. At the same time, check the release task set: Task 2 has been completed and the release flag has been set. ,but The result after negation is 0. Finally... This means that resources are released. If no task is released, then... The resource remains locked. Formula ⑧ outputs the new resource occupancy and locking status. The resource occupancy status information is written back, replacing the original resource occupancy lock status field. At this point, both the task dependency graph and the resource occupancy status information have been updated. The output products are the updated task dependency graph (including dependency edge state vectors) and the updated resource occupancy status information (including new lock status). This data is passed to the task scheduling priority recalculation submodule of the task reordering module as input for the third step of S5 to recalculate the task scheduling priority of unexecuted tasks.

[0186] The task reordering module receives the updated task dependency graph and updated resource usage status information, and then filters out the set of affected unexecuted tasks. For each unexecuted task The task reordering module reads the task priority level. Remaining execution time of the task (i.e., the end time of the time window minus the current synchronization clock time), and the delay time of the preceding task. (Extracted from the updated state of the preceding dependency edges; if the preceding task fails or times out, the delay is set to the remaining execution time of the task), resource waiting time. (Obtain the current locked status and estimated release time of the device resources from the resource occupancy status information, and calculate the difference between the current time and the release time), as well as device feedback information. (Read the validity flag of the most recent device feedback from the task execution status information). To address the practical problem of "how to integrate multi-dimensional influencing factors into a new task scheduling priority after an anomaly occurs, so that unexecuted tasks can be reordered according to the latest constraints," the task reordering module introduces formula ⑨. Formula ⑨ uses a weighted exponential form to combine the inherent attributes of the task with the dynamic impact of the anomaly, outputting a new task scheduling priority value.

[0187] Formula⑨

[0188] in: Task not performed The updated task scheduling priority, with a unit of one, has a value range of [value range missing]. The result is calculated using formula ⑨ and used to sort and form the updated task execution order.

[0189] : Unexecuted task index, belonging to the task set affected by the exception. .

[0190] :Task The task priority level, with a unit of one, is extracted from the task priority level field in the task node information, and its value range is usually from 1 to 10.

[0191] The criticality index weight, with a single dimension, is extracted from the priority rule data.

[0192] : Reference value for time window length, in milliseconds. It is the maximum value or preset value (e.g., 10000 milliseconds) of the time window length of all tasks in the current program segment, extracted from the timing constraint data.

[0193] :Task The remaining execution time of the task, in milliseconds, is calculated from the difference between the current synchronization clock time and the end time of the task time window. If it is less than 0, it is set to 1 millisecond.

[0194] The remaining time index weight, with a dimension of one, is extracted from the priority rule data.

[0195] Exponential function, expressed as a natural constant As the base.

[0196] Delay weight coefficient, with a single dimension, is extracted from the priority rule data.

[0197] :Task The delay time of the preceding task, in milliseconds, is extracted from the delay status of the preceding dependency edges in the updated task dependency graph. If the preceding task is not delayed, the value is 0.

[0198] The linear weight of resource waiting time, with a single dimension, is extracted from the priority rule data.

[0199] :Task The resource waiting time, in milliseconds, is calculated by obtaining the current locked state and estimated release time of the device resource from the updated resource occupancy status information, and calculating the difference between the current time and the release time. If the resource is idle, the value is 0.

[0200] : Penalty coefficient for equipment feedback information, dimensionless, range of values Extracted from priority rule data.

[0201] :Task The device feedback information validity flag is set to 0 when the most recent device feedback is normal, and 1 when the device does not respond or the feedback is abnormal. It is obtained by mapping from the error code field in the task execution status information.

[0202] Data source mapping: Taken from "task node information"; Taken from "time series constraint data"; Calculated from the end time of the time window in the "task execution scheduling scheme" and the current synchronization clock; Delay status of preceding dependency edges taken from the updated "Task Dependency Graph"; The resource occupancy lock status and estimated release time are taken from the updated "Resource Occupancy Status Information"; The feedback reception time and error code are taken from the "Task Execution Status Information".

[0203] Simple numerical example: Suppose no task has been executed. Task priority level , ,but Remaining execution time for the task millisecond, millisecond, ,but Pre-task delay time millisecond, exponent term Resource waiting time millisecond, ,but Equipment feedback information ,but .final Formula 9 outputs As the new task scheduling priority for each unexecuted task, it is written into the "Task Scheduling Priority" field of the updated task execution scheduling scheme. Subsequently, the task rescheduling module... All unexecuted tasks are sorted in descending order to form the updated task execution order. To align the updated task execution order with the event triggering conditions, the task reordering module introduces formula ⑩ to calculate the updated trigger time for each unexecuted task. Formula ⑩ uses a forward propagation approach, starting from the first unexecuted task, sequentially accumulating its estimated execution time and synchronization error tolerance, and considering the offset of time offset dependency edges, thereby generating a sequence of task triggering events that matches the updated order.

[0204] Formula⑩

[0205] in: Task not performed The update trigger time, in milliseconds, represents the time since the base time. The initial absolute time offset. Calculated using formula ⑩, this is written into the "Trigger Time" field of the updated task trigger event sequence.

[0206] : Task index not executed, executed in the order of updated tasks (by...) (In descending order) Numbering starts from 1.

[0207] : Current rescheduling reference time, in milliseconds. It is the first alignment time after the current synchronization clock time or the time of the exception, and is read from the synchronization clock identifier field by the event queue module.

[0208] : Regarding the tasks assigned All previously unexecuted tasks The sum of the expected execution times. For the task The estimated execution time, in milliseconds, is extracted from the estimated execution time field of the task node information.

[0209] : Assigned to task Previous unexecuted task index, value range arrive .

[0210] : Regarding the task All participating synchronous dependency edges The updated synchronization error tolerance is summed. For the task The set of all synchronous dependency edges involved; For synchronous dependency edges The updated synchronization error tolerance, in milliseconds, is read from the updated task dependency graph.

[0211] : Synchronous dependency edge index, belonging to .

[0212] : Regarding the task All time offset dependency edges involved Sum the updated offset times. For the task The set of all time-offset dependency edges involved; For time-off dependency edges The updated offset time, in milliseconds, is read from the updated task dependency graph.

[0213] : Time offset dependency edge index, belonging to .

[0214] Data source mapping: The updated synchronization error tolerance and offset time are taken from the updated task dependency graph. The time of occurrence of the anomaly is taken from either the "Synchronization Clock Identifier" or the "Abnormal Event Data".

[0215] Simple numerical example: Let's say the first unexecuted task in the updated task order. If the summation term is empty, then the summation term will be empty. ,set up If the time is milliseconds, then the trigger time is 1000 milliseconds. Second task. Let the estimated execution time of task 1 be... Milliseconds, Task 2 participates in a synchronization dependency edge, and its synchronization error tolerance after update. Milliseconds, no time offset, then millisecond.

[0216] Formula 10 outputs the updated trigger time. The "Trigger Time" field is written into the updated task trigger event sequence, and together with the event identifier, task identifier, trigger condition, synchronization clock identifier, device control command, and feedback fields, forms a complete task trigger event sequence. Finally, the task rescheduling module will adjust the task scheduling plan (including task execution order, task trigger conditions, target device resources, resource occupancy time period, and new task scheduling priority) to... Synchronization error tolerance, status monitoring location) and updated task trigger event sequence (including updated trigger time) The output is sent to the event queue module to replace the plan segment corresponding to the unexecuted task in the original task execution scheduling scheme, and to allow the device control interface module to issue device control commands in subsequent rounds according to the new triggering conditions and synchronization clock.

[0217] The technical effects of this section are as follows: Formula ⑤ quantifies the severity of six types of abnormal conditions; Formula ⑥ normalizes them into resource priorities; Formulas ⑦ and ⑧ update the dependency edge state and resource occupancy lock state, respectively; and Formulas ⑨ and ⑩ recalculate task scheduling priorities and generate aligned event trigger times, thus constructing a complete algebraic closed loop from anomaly identification to new plans / queues. This link differs from existing technologies that only provide feedback through alarms or obstacle avoidance, achieving structured and interconnected updates of task dependency graphs, resource occupancy status information, and task trigger event sequences.

[0218] Example 2: Figure 2 A structural block diagram of a stage visual effects task execution and monitoring system based on priority scheduling according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include: The task data parsing module 01 is used to receive stage visual effects task sets, task dependency data, equipment resource status data, event triggering data, timing constraint data, and priority rule data. It parses the stage visual effects task sets to generate task node information and basic equipment resource information. Specifically, the task data parsing module receives the stage visual effects task sets from performance program configuration files, performance scripts, visual effects control project files, or centralized control platforms through a data access interface, and reads the task dependency data, equipment resource status data, event triggering data, timing constraint data, and priority rule data. The task data parsing module performs task identifier reading, task type identification, program segment aggregation, target equipment resource matching, and task priority level registration on the stage visual effects task sets, writing tasks such as projection screen switching, LED zone display, real-time rendering, ambient light switching, spatial audio synchronization, material preloading, calibration parameter loading, and program switching into the task node information. Based on the equipment resource status data, the task data parsing module reads the equipment identifier, equipment type, channel identifier, resource status, and control interface identifier to form the basic equipment resource information. When a task identifier is missing, target device resources are mismatched, or resource statuses are inconsistent, the task data parsing module writes the corresponding task node into a pending review status and retains the original input fields. The task data parsing module provides the task node information and the basic device resource information to the task constraint construction module. The task identifier, program segment, and device resource requirements in the task node information serve as inputs for constructing the task dependency graph and establishing resource occupancy status information.

[0219] The task constraint construction module 02, connected to the task data parsing module, is used to construct a task dependency graph based on the task node information, the task dependency data, and the device resource basic information. It establishes resource occupancy status information between the task nodes in the task dependency graph and their corresponding device resources, generating task resource constraint information. Specifically, the task constraint construction module receives the task node information and the device resource basic information from the task data parsing module, and reads the preceding task identifier, synchronization error tolerance, mutually exclusive device resource identifier, and offset time from the task dependency data. The task constraint construction module writes the task identifier from the task node information into the task node, the preceding task identifier into the preceding dependency edge, the synchronization error tolerance into the synchronization dependency edge, the mutually exclusive device resource identifier into the mutually exclusive dependency edge, and the offset time into the time offset dependency edge, thereby forming the task dependency graph. The task constraint construction module reads the device identifier, channel identifier, resource status, and control interface identifier based on the device resource basic information, and establishes resource occupancy status information between the task nodes in the task dependency graph and their corresponding device resources. The resource occupancy status information records the task identifier, device identifier, channel identifier, occupancy start time, occupancy end time, and resource occupancy lock status. When the preceding task identifier cannot be matched, there is a synchronization error tolerance conflict, or the device resource is unavailable, the task constraint construction module writes the corresponding dependency edge status, resource occupancy lock status, or resource occupancy conflict flag into the task resource constraint information. The task constraint construction module provides the task resource constraint information to the task scheduling module, and the task dependency graph and resource occupancy status information in the task resource constraint information are invoked by the task scheduling module.

[0220] The task scheduling module 03, connected to the task constraint construction module, is used to filter a set of schedulable tasks whose dependencies are satisfied and whose device resources are available, based on the task resource constraint information, the timing constraint data, and the priority rule data. It calculates and sorts the task scheduling priorities to generate a task execution scheduling scheme. Specifically, the task scheduling module receives the task resource constraint information from the task constraint construction module and reads the trigger time, execution window, and synchronization error tolerance from the timing constraint data. Simultaneously, it reads the task priority level reading rule, task remaining execution time calculation rule, preceding task delay time reading rule, resource waiting time accumulation rule, and device feedback information reference rule from the priority rule data. The task scheduling module reads the preceding dependency status of task nodes in the task dependency graph and reads the resource occupancy lock status of the corresponding device resources from the resource occupancy status information. Task nodes with a preceding dependency status of "completed" and a resource occupancy lock status of "idle" are written into the set of schedulable tasks. The task scheduling module reads the task priority level, remaining execution time, time window, preceding task delay time, resource waiting time, and device feedback information from the task nodes in the schedulable task set. It then generates a task scheduling priority according to the priority rule data and sorts the schedulable task set according to this priority. If the schedulable task set is empty, multiple task nodes have the same task scheduling priority, or the priority rule data versions are inconsistent, the task scheduling module writes a waiting status, a re-sorting record, or a version status record. The task execution scheduling scheme generated by the task scheduling module includes the task execution order, task triggering conditions, target device resources, resource occupation time period, task scheduling priority, synchronization error tolerance, and status monitoring location. The module then passes the task execution scheduling scheme to the event-triggered execution module for invocation.

[0221] The event triggering execution module 04, connected to the task scheduling module, is used to generate a task triggering event sequence based on the task execution scheduling scheme and the event triggering data, and to issue device control commands according to the event triggering conditions and the synchronization clock. Specifically, the event triggering execution module receives the task execution scheduling scheme from the task scheduling module and reads the performance timecode trigger, program segment start trigger, pre-task completion trigger, interactive command trigger, and manual confirmation trigger from the event triggering data. The event triggering execution module writes the task identifier, task triggering conditions, target device resources, resource occupation time period, and synchronization error tolerance from the task execution scheduling scheme into the task triggering event sequence, forming an event identifier, task identifier, trigger time, triggering condition, synchronization clock identifier, device control command, and feedback field. The event triggering execution module reads the synchronization clock identifier and trigger time from the task triggering event sequence, and when the event triggering condition matches the current triggering record, outputs the device control command to the device control interface of the corresponding visual effects device. The device control command includes a task identifier, device identifier, channel identifier, control action, trigger time, synchronization error tolerance, and feedback field. If the trigger condition is not met within the trigger window, the synchronization clock identifier is missing, or the device control interface status is abnormal, the event trigger execution module writes the corresponding event identifier into the waiting state or interface abnormal state, and retains the original trigger field in the task trigger event sequence. The event trigger execution module provides the status monitoring module with instruction issuance records, device identifier, channel identifier, task identifier, and feedback field, so that the status monitoring module can collect device feedback data and establish task node associations.

[0222] The status monitoring module 05, connected to the event-triggered execution module, is used to collect device feedback data, associate the device feedback data with the task node, and generate task execution status information. Specifically, the status monitoring module receives instruction issuance records, task identifiers, device identifiers, channel identifiers, and feedback fields from the event-triggered execution module, and receives device feedback data returned by the visual effects device through the device control interface. The device feedback data includes control instruction receipts, running status parameters, feedback reception time, execution result, and error code. The status monitoring module associates the device feedback data with the task node according to the task identifier and device resource identifier to generate the task execution status information. The task execution status information records the task identifier, device resource identifier, instruction issuance time, feedback reception time, execution result, and error code. For multiple task nodes with synchronous dependency edges, the status monitoring module reads the synchronization error tolerance and writes multiple feedback reception times into the same synchronization status record. When device feedback data is missing, feedback reception time is null, execution result is inconsistent with device control command, or error code cannot be matched, the status monitoring module retains the original device feedback data and writes the feedback missing status, device unresponsive status, or pending review status into the task execution status information. The status monitoring module provides the task execution status information to the task rescheduling module. The task identifier, device resource identifier, command issuance time, feedback reception time, execution result, and error code in the task execution status information serve as inputs for identifying abnormal conditions in task execution.

[0223] The task rescheduling module 06 is used to identify abnormal conditions in task execution based on the task execution status information, update the task dependency graph and the resource occupancy status information, recalculate the task scheduling priority for unexecuted tasks, and generate an adjusted task scheduling plan and an updated task trigger event sequence. Specifically, the task rescheduling module receives the task execution status information from the status monitoring module and calls the task dependency graph and the resource occupancy status information in the task constraint construction module. The task rescheduling module identifies task timeouts, task failures, device unresponsiveness, resource occupancy conflicts, missing trigger events, and synchronization errors exceeding thresholds based on task identifiers, device resource identifiers, instruction issuance time, feedback reception time, execution results, and error codes. After identifying abnormal conditions in task execution, the task rescheduling module updates the task node status and dependency edge status in the task dependency graph and updates the resource occupancy lock status, occupancy start time, and occupancy end time in the resource occupancy status information. The task rescheduling module reads the updated task dependency graph and updated resource usage status information, filters affected unexecuted tasks, recalculates task scheduling priorities using priority rule data, and generates an adjusted task scheduling plan based on the recalculated priorities. The task rescheduling module then generates an updated task trigger event sequence based on the adjusted task scheduling plan and returns this sequence to the event trigger execution module. If task execution anomalies cannot be matched with the failure handling strategy, the time window for unexecuted tasks expires, or resource usage conflicts still exist in the updated resource usage status information, the task rescheduling module writes a pending review status, a skipped status, or a waiting status, and records the task plan version, event queue version, device feedback data, and the reason for rescheduling.

Claims

1. A method for executing and monitoring stage visual effects tasks based on priority scheduling, characterized in that, include: S1. Acquire multi-source data, perform task data parsing, and generate task node information and basic equipment resource information; the multi-source data includes stage visual effects task sets, task dependency data, equipment resource status data, event triggering data, timing constraint data, and priority rule data; S2. Construct a task dependency graph based on the task node information, the task dependency data, and the device resource basic information; establish resource occupancy status information between the task nodes in the task dependency graph and the corresponding device resources; and generate task resource constraint information. S3. Based on the task resource constraint information, the timing constraint data and the priority rule data, filter the set of schedulable tasks that meet the dependencies and have available device resources, calculate and sort the task scheduling priorities, and generate a task execution scheduling scheme. S4. Generate a task trigger event sequence based on the task execution scheduling scheme and the event trigger data, issue device control instructions according to the event trigger conditions and the synchronization clock, associate the device feedback data with the task node, and generate task execution status information. S5. Based on the task execution status information, identify abnormal conditions in task execution, update the task dependency graph and the resource occupancy status information, recalculate the task scheduling priority for unexecuted tasks, and generate an adjusted task scheduling plan and an updated task triggering event sequence.

2. The method according to claim 1, characterized in that, The task node information includes task identifier, task type, program segment, target equipment resources, estimated execution duration, time window, task priority level, equipment resource requirements, and failure handling strategy; the task types include projection screen switching tasks, LED zone display tasks, real-time rendering tasks, ambient light switching tasks, spatial audio synchronization tasks, material preloading tasks, calibration parameter loading tasks, and program switching tasks.

3. The method according to claim 1, characterized in that, The task dependency graph includes task nodes and dependency edges; the dependency edges include preceding dependency edges, synchronization dependency edges, mutual exclusion dependency edges, and time offset dependency edges; the preceding dependency edge writes the preceding task identifier, the synchronization dependency edge writes the synchronization error tolerance, the mutual exclusion dependency edge writes the mutual exclusion device resource identifier, and the time offset dependency edge writes the offset time. The construction task dependency graph includes: The task node information is grouped; Generate a preceding dependency edge based on the preceding task identifier in the task dependency data; For multiple task nodes that need to be executed within the same synchronization error tolerance in the same program segment, generate synchronization dependency edges and write the synchronization error tolerance into the synchronization dependency edges; For multiple task nodes with the same target device resources and overlapping execution periods, mutually exclusive dependency edges are generated based on the mutually exclusive device resource identifiers; For task nodes with predetermined sequential offsets, generate time offset dependency edges and write the offset time into the time offset dependency edge.

4. The method according to claim 1, characterized in that, The basic equipment resource information includes equipment identifier, equipment type, channel identifier, resource status, and control interface identifier; the resource occupancy status information includes task identifier, equipment identifier, channel identifier, occupancy start time, occupancy end time, and resource occupancy lock status. The establishment of resource occupancy status information includes: reading the target device resources, estimated execution time and time window from the task node information, reading the device identifier and channel identifier from the device resource basic information, and determining the device identifier, channel identifier, occupancy start time and occupancy end time occupied by each task node; The start time of occupation is taken from the trigger time in the time window, and the end time of occupation is obtained by adding the estimated execution duration to the start time of occupation. The task resource constraint information includes the task dependency graph, the resource occupancy status information, the dependency edge status, the resource occupancy lock status, and the resource occupancy conflict marker.

5. The method according to claim 1, characterized in that, The set of schedulable tasks that satisfy the dependencies and have available device resources includes: reading the preceding dependency status of the task nodes in the task dependency relationship graph; reading the resource occupancy lock status of the corresponding device resources in the resource occupancy status information; and writing the task nodes whose preceding dependency status is completed and whose resource occupancy lock status is idle into the set of schedulable tasks.

6. The method according to claim 1, characterized in that, The calculation and sorting of task scheduling priorities includes: reading the task priority level, remaining execution time, time window, delay time of preceding tasks, resource waiting time and device feedback information of each task node in the schedulable task set; generating the task scheduling priority of each task node according to the priority rule data; and sorting the schedulable task set according to the task scheduling priority.

7. The method according to claim 1, characterized in that, The task execution scheduling scheme includes task execution order, task triggering conditions, target device resources, resource occupation time period, task scheduling priority, synchronization error tolerance, and status monitoring location; the task triggering event sequence includes event identifier, task identifier, trigger time, triggering conditions, synchronization clock identifier, device control command, and feedback field.

8. The method according to claim 7, characterized in that, The triggering conditions include performance timecode triggering, program segment start triggering, pre-task completion triggering, interactive instruction triggering, and manual confirmation triggering; the equipment control instructions include task identifier, equipment identifier, channel identifier, control action, trigger time, synchronization error tolerance, and feedback field.

9. The method according to claim 1, characterized in that, The task execution status information includes task identifier, device resource identifier, instruction issuance time, feedback reception time, execution result, and error code; the task execution abnormal conditions include task timeout, task failure, device unresponsiveness, resource occupation conflict, missing trigger event, and synchronization error exceeding the threshold; when the task execution abnormal conditions are met, the task plan version, event queue version, device feedback data, and rescheduling reason are recorded.

10. A stage visual effects task execution and monitoring system based on priority scheduling, characterized in that, include: Task data parsing module, task constraint construction module, task scheduling module, event-triggered execution module, status monitoring module, and task reordering module; The system is used to implement the method described in any one of claims 1-9.

Images