Real-time system task scheduling resource allocation risk defense method and device

Abstract

The invention discloses a real-time system task scheduling resource allocation risk defense method and device, and relates to the technical field of real-time system resource scheduling. The method comprises the steps of obtaining task data submitted to a system, and constructing a task dependency topological graph with dynamic characteristics based on task description, code logic and interface calling information of the task data; in a task initialization stage, resource pre-allocation is performed according to a task dependency topological graph and resource demand information of each task; in the task execution process, task state changes are captured through a system monitoring service, task resource allocation risks are evaluated, the task dependency topological graph is updated according to state capture and risk evaluation results, and task resource allocation is adjusted based on the updated task dependency topological graph. According to the invention, through dynamic management of the whole life cycle of the task, a full-link anti-overload and anti-hunger solution is provided for real-time system scheduling, and the method is especially suitable for high-complexity industrial scenes.

Description

Technical Field

[0001] This application relates to the field of real-time system resource scheduling technology, specifically to a method and apparatus for risk defense in real-time system task scheduling resource allocation. Background Technology

[0002] In traditional real-time operating systems, task scheduling and resource allocation are mostly limited to a single dimension, such as the method for preventing low-priority tasks from starving in a multi-task system disclosed in Chinese patent document CN112764904A. This approach allocates resources based solely on task priority or the order of resource requests, ignoring the complex dependencies between tasks and the unique resource requirements exhibited by tasks at different lifecycle stages. While it can guarantee task deadlines, it often suffers from one or more of the following defects in both static and dynamic aspects: failure to consider dependencies between tasks, leading to blocking of critical path tasks; lack of global resource dependency prediction, making it difficult to cope with sudden system loads; reliance on periodic detection, failing to respond in real time to sudden changes during task execution; failure to dynamically allocate tasks based on hardware characteristics, leading to resource waste or overload; and the isolation of task creation, execution, and termination stages, making it difficult to form a closed-loop optimization. Summary of the Invention

[0003] This application aims to disclose a method and apparatus for risk defense in real-time system task scheduling and resource allocation, so as to achieve efficient resource allocation in multi-task systems.

[0004] To achieve the above objectives, this application adopts the following technical solution: Firstly, a method for mitigating risks in real-time system task scheduling and resource allocation is disclosed, including: The system acquires task data submitted to the system and constructs a dynamic task dependency topology graph based on the task description, code logic, and interface call information. In the graph structure of the task dependency topology graph, each node represents a specific task, and its attributes include task ID, task type, and resource requirement information. Directed edges represent the dependencies between tasks, and the attributes of the edges include the dependency type and the corresponding weight. During the task initialization phase, resources are pre-allocated based on the task dependency topology and the resource requirements of each task. During task execution, the system monitoring service captures changes in task status and assesses the risks of task resource allocation. Based on the status capture and risk assessment results, the task dependency topology is updated, and task resource allocation is adjusted based on the updated task dependency topology.

[0005] In one example, during the initial stage of task submission to the system, code parsing technology and semantic analysis algorithms are used to scan the task's description file, code logic, and interface call information. This includes identifying data dependencies between tasks, mining control dependencies, and identifying potential temporal dependencies through in-depth analysis of the task execution logic.

[0006] In one example, dependency weights are calculated using the following method: W dependcy = α× D data / Sum{D i, 0...i} + β × I critical / I total + γ ×U irreplaceable / U sum In the formula, W dependcy Let be the dependency weights, α, β, and γ be the weight coefficients, and satisfy α + β + γ = 1; D data For the amount of data transferred between tasks, Sum{D i, 0...i} represents the total amount of data transferred between all related tasks; I critical I represents the contribution of dependencies to the realization of key system functions. total This is the total contribution of all dependencies to the system's critical functions; U irreplaceable To score the degree of non-substitutability of the dependency, U sum It is the sum of the scores for the irreplaceability of all dependencies.

[0007] In one example, during the task initialization phase, the machine learning model is used to assess the rationality of the resource requirements at the start of the task based on the task type, estimated execution time, and initial resource request information, using historical data of similar tasks.

[0008] In one example, task resource allocation risks include the risk of starvation. The following method is used to determine whether a task is likely to starve: T wait >λ× ΣT j-expected In the formula, T wait This represents the time a task waits for resources, where λ is the time coefficient, and T is the time. j-expected The estimated execution time of tasks 0 to j on which the task depends.

[0009] In one example, the starvation risk value R is calculated using the following method. starve : R starve = ω × T wait / T deadline+ ψ×Σ(1 - P l-progress ) / P l-total + θ ×R system-used / R system-total Where ω, ψ, and θ are weighting coefficients, and ω + ψ + θ = 1; T wait T represents the duration during which a task waits for resources. deadline The deadline for the task; P l-progress P represents the execution progress of the l-th task that the task depends on. l-total To depend on the overall task progress; R system-used R represents the amount of resources currently used by the system. system-total This represents the total system resources.

[0010] In one example, task resource allocation risk includes the risk of resource overload. The following method is used to determine whether a task is likely to overload: R usage > µ × Σ R k-requierd × W k-dependency In the formula, R usage R represents the current actual resource usage of the task, µ is the resource usage coefficient, and R k-requierd W represents the resource requirements of task k, which are related to the task. k-dependency This represents the dependency weight between the task and its dependent task k.

[0011] In one example, the burst risk value R is calculated using the following method. overload : R overload = α×△R usage / △T + β×(R usage - R expected ) / R expected + γ× Σ(R m-shortage / R m-required ) In the formula, α, β, and γ are weighting coefficients, and α + β + γ = 1; ΔR usage / △T represents the growth rate of task resource usage; R usage R represents the current resource usage of the task. expected R represents the expected resource usage for the task. m-shortage R represents the resource shortage of the m-th task affected by the task. m-required This represents the resource requirements of the m-th affected task.

[0012] Secondly, a risk defense device for real-time system task scheduling and resource allocation is disclosed, comprising: The graph construction module is configured to: obtain task data submitted to the system, and construct a task dependency topology graph with dynamic characteristics based on the task description, code logic and interface call information of the task data; wherein, in the graph structure of the task dependency topology graph, each node represents a specific task, and its attributes include task ID, task type and resource requirement information, and directed edges represent the dependency relationship between tasks, and the edge attributes include dependency relationship type and corresponding weight. The resource pre-allocation module is configured to: pre-allocate resources during the task initialization phase based on the task dependency topology and the resource requirements of each task; The risk assessment module is configured to: capture changes in task status through system monitoring services during task execution, assess the risk of task resource allocation, update the task dependency topology based on the status capture and risk assessment results, and adjust task resource allocation based on the updated task dependency topology.

[0013] Thirdly, a system includes a real-time end and a non-real-time end. The real-time end includes the aforementioned device. The system logs collected by the real-time end are sent to the non-real-time end in the form of message data. Multiple analysis and calculation models are configured on the non-real-time end to analyze and calculate the message data sent by the real-time end, and the analysis and calculation results are sent to the real-time end in the form of message data.

[0014] Beneficial effects: This application provides a full-link anti-overload and anti-starvation solution for real-time system scheduling by dynamically managing the entire task lifecycle. Simultaneously, by integrating task dependency topology and resource allocation, this application enables multi-dimensional scheduling optimization and refined usage across different application scenarios. Furthermore, through phased resource isolation, dynamic priority compensation, and cross-phase feedback, this application systematically solves resource conflict problems in real-time task scheduling, making it suitable for high-performance computing and high-reliability scenarios.

[0015] Other features and advantages of this application will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the real-time system task scheduling resource allocation risk defense method according to an embodiment of this application; Figure 2 This is a schematic diagram of the system composition implemented based on a hybrid deployment framework. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] To address the task scheduling problems in real-time operating systems, such as the "overload" (high-priority tasks excessively consuming resources) and "starvation" (low-priority tasks unable to execute for extended periods) issues caused by resource contention in embedded systems (e.g., industrial automation control, automotive real-time systems, edge computing nodes), this application discloses a method for mitigating resource allocation risks in real-time system task scheduling by combining task dependency relationships, phased management of task lifecycles, dynamic resource isolation, and priority adaptive compensation. Figure 1 As shown, it includes the following steps: Step S1: Obtain the task data submitted to the system, and construct a task dependency topology graph with dynamic characteristics based on the task description, code logic and interface call information of the task data. In the initial stage of task submission to the system, code parsing techniques (such as using disassembler objdump to query call relationships) and semantic analysis algorithms (such as static code scanning, lexical analyzers, etc.) are used to comprehensively scan the task description file, code logic, and interface call information. This includes: identifying common data dependencies between tasks, such as the output of data processing task A serving as the input of data analysis task B; uncovering control dependencies, such as in an automated production process, where the equipment can only start running tasks after the equipment start task is completed; and identifying potential temporal dependencies through in-depth analysis of task execution logic, such as certain tasks that must be executed sequentially in a specific order.

[0019] To more accurately measure the tightness and importance of task dependencies, task dependency weights are quantified: strong data dependencies that directly determine the task execution result are assigned higher weights. For example, in an error correction and recognition system, the dependency between the data preprocessing task and the error correction and recognition algorithm task, which directly affects the accuracy of error correction and recognition, can have its dependency weight set in the higher range of 0.8-1.0. Conversely, for relatively loose dependencies that only indirectly affect task execution, the weights are set in the lower range of 0.2-0.4.

[0020] The determination of task dependency weights is not arbitrary, but rather calculated by comprehensively considering multiple key factors, including the amount of data transfer between tasks, the degree of irreplaceability of the dependency relationship, and the criticality to the implementation of the core functions of the overall system. For example, the calculation formula is: W dependcy = α× D data / Sum{D i, 0...i} + β × I critical / I total + γ ×U irreplaceable / U sum In the formula, W dependcy α represents the task dependency weight, used to measure the strength of the dependency relationship; α, β, and γ are weight coefficients. These coefficients are not fixed, but can be flexibly adjusted according to the characteristics and needs of the actual application scenario, and satisfy α + β + γ = 1. D data For the amount of data transferred between tasks, Sum{D i, 0...i} represents the total amount of data transfer between all related tasks, and the ratio between the two reflects the importance of this dependency at the data transfer level; I critical I represents the contribution of this dependency to the realization of key system functions. total This is the total contribution of all dependencies to the key functions of the system. The ratio of the two is used to measure the relative importance of the dependency in the realization of the system functions. U irreplaceable Rate the degree of non-substitutability of this dependency, for example, setting the rating range to 1-100, where 100 represents complete non-substitutability. sum It is the sum of the irreplaceability scores of all dependencies, and the ratio of the two is used to comprehensively evaluate the uniqueness and importance of the dependency in the entire dependency system.

[0021] Based on task dependencies and quantified weight data, a dynamic task dependency topology graph is constructed. In this graph structure, each node represents a specific task, with attributes including: task ID, facilitating accurate task identification and tracking by the system; task type, describing the task's function and nature; and resource requirements, detailing the task's resource needs (such as CPU computing power, memory capacity, network bandwidth, etc.) during execution. Directed edges represent the dependencies between tasks, with attributes including dependency type (e.g., data dependency, control dependency, timing dependency) and corresponding weights. Taking a software development project as an example, requirements analysis tasks, design tasks, coding tasks, and testing tasks each constitute independent nodes, and their dependencies are tightly connected by directed edges, forming an organic whole that clearly demonstrates the logical connections and degrees of dependency between various tasks in the software development process.

[0022] Step S2: In the task initialization phase, resources are pre-allocated based on the task dependency topology and the resource requirements of each task. For example, the system first uses a machine learning model (such as logistic regression) to assess the rationality of the resource requirements at the start of a task based on information such as task type (compute-intensive / IO-intensive), estimated execution time, and initial resource requests, using historical data of similar tasks (e.g., the number of tasks triggering "overload" or "starvation" events each day shows a gradually decreasing trend over a period of time). For instance, for a new task, the system refers to the resource usage of similar tasks in the past to determine whether its requested CPU resources and memory capacity are within a reasonable range. If resources are scarce, the system will prioritize ensuring the resource needs of tasks on the critical path, appropriately reduce resource allocation for non-critical tasks, and provide a compensation mechanism, such as prioritizing replenishment when resources become available later. For example, on edge devices with limited hardware resources, when multiple tasks start simultaneously and resources are limited, the initial memory request for a regular data backup task can be adjusted from 200kb to 50kb, and this adjustment is recorded. When system memory becomes available, it is prioritized for replenishment.

[0023] The determination of the critical path can leverage mature topology sorting and critical path analysis algorithms. Through in-depth analysis of the task dependency topology graph, the system accurately identifies the sequence of key tasks that decisively impacts the execution efficiency and results of the entire task flow. Taking image text recognition as an example, tasks such as image segmentation, content extraction, and text correction constitute the critical path. The successful execution of these tasks directly affects the quality and efficiency of image text recognition. Therefore, the system prioritizes allocating sufficient CPU computing resources and ample memory resources to tasks on these critical paths to ensure their efficient operation.

[0024] Step S3: During task execution, the system monitoring service captures changes in task status and assesses the risk of task resource allocation. Based on the status capture and risk assessment results, the task dependency topology is updated, and the task resource allocation is adjusted based on the updated task dependency topology. As tasks progress, if the task dependency topology changes for various reasons, the system can detect and adjust resource allocation in real time. If a non-critical task gains the opportunity to execute ahead of schedule due to the early completion of its dependent tasks, and system resources are relatively abundant at this time, the system will promptly allocate some idle resources to the task, effectively improving the overall utilization rate of resources and avoiding resource waste.

[0025] The dependency topology nodes and their dependencies are stored in a database for real-time updates. During task execution, any change in task status—whether it's early completion, delay, failure, or temporary adjustments to resource requirements—is detected by the system monitoring services (e.g., CPU usage, memory usage, I / O, task monitoring, system logs) and triggered an update to the task dependency topology. Utilizing real-time monitoring data and an event-driven model, the system can quickly and accurately modify the node status in the dependency topology, such as updating the task status from "in execution" to "completed" or "failed." Simultaneously, edge attributes are adjusted accordingly. If a critical task experiences a delay due to insufficient resources, the system automatically updates its status in the dependency topology and reassesses the dependencies and weights of subsequent tasks affected by it. This dynamic update process provides the latest, most accurate, and most timely information for subsequent resource allocation and task scheduling decisions, ensuring the system can always make reasonable resource allocations and task arrangements based on the actual progress of tasks.

[0026] To fundamentally and effectively prevent resource allocation risks, such as task starvation and overload, the system continuously and closely monitors the resource waiting time of tasks in the dependency topology graph.

[0027] To address the task starvation issue, for tasks that have been waiting for resources for an extended period (exceeding a preset time) and have close dependencies on other tasks, the system will automatically prioritize their resource allocation to ensure they can acquire the necessary resources as quickly as possible, thus advancing task execution. Alternatively, the system may reclaim some resources from tasks with excessively high resource utilization (exceeding a preset value) but not on the critical path in the task flow, and reallocate them reasonably to meet the resource needs of waiting tasks.

[0028] For example, the following algorithm is used to determine whether a task is likely to starve: T wait >λ× ΣT j-expected In the formula, T wait λ represents the time a task waits for resources and is an important indicator of task starvation; λ is a time coefficient, which is not fixed but can be dynamically adjusted according to the real-time system load and the characteristics of the task itself to adapt to different system operating environments and task requirements; T j-expected The estimated execution time of tasks 0 to j on which the task depends.

[0029] When the above formula is true, the system can accurately determine that the task is at risk of starvation, and then take corresponding preventive measures in a timely manner to ensure the smooth execution of the task.

[0030] Furthermore, to quantify the risk of starvation, considering task waiting time, the execution progress of dependent tasks, and the current system resource allocation, the starvation risk value R is calculated using the following algorithm. starve : R starve = ω × T wait / T deadline + ψ×Σ(1 - P l-progress ) / P l-total + θ ×R system-used / R system-total Where ω, ψ, and θ are weighting coefficients, which can be flexibly adjusted according to the real-time system application scenario and task characteristics, and ω + ψ + θ = 1; T wait T represents the duration during which a task waits for resources. deadline The deadline for the task; P l-progress P represents the execution progress of the l-th task that the task depends on. l-total To depend on the overall task progress; R system-used R represents the amount of resources currently used by the system. system-total This represents the total system resources.

[0031] When the risk of starvation is R starve When the threshold is exceeded, the task is deemed to be at risk of starvation, and the higher the value, the higher the risk of starvation.

[0032] To address the issue of task overload, when the system detects that a task's resource consumption far exceeds the reasonable range determined by its dependencies, its resource usage is restricted. For example, from a system hardware perspective, the CPU utilization cap is lowered to prevent excessive CPU resource consumption; memory allocation is limited to prevent unrestrained memory consumption. Simultaneously, the resources released through these restrictions are promptly allocated to tasks that urgently require them, thus creating a virtuous cycle of rational resource allocation within the system and effectively ensuring stable system operation. Understandably, software resources, such as semaphores and mutexes, representing data usage relevant to actual business needs, must also be considered here.

[0033] For example, the following algorithm is used to determine whether a task is likely to overload: R usage > µ × Σ R k-requierd × W k-dependency In the formula, R usageThis represents the current actual resource usage of the task, reflecting the task's resource occupancy; µ is the resource usage coefficient, which is determined by comprehensively considering factors such as the total system resources and task priority to ensure the accuracy and rationality of the judgment; R k-requierd The resource requirements of dependent task k related to this task are defined, thus clarifying the actual resource needs of the dependent task; W k-dependency The dependency weight between the task and its dependent task k reflects the tightness of their dependency relationship.

[0034] When this formula holds true, it indicates that the task may be overloaded, and the system will intervene to adjust its resource allocation and maintain the stable operation of the system.

[0035] Furthermore, to quantify the risk of resource overload, considering the growth trend of task resource usage, the degree of matching between resource consumption and task priority, and the impact on the allocation of resources to other tasks, the risk of resource overload R is calculated using the following algorithm. overload : R overload = α×△R usage / △T + β×(R usage - R expected ) / R expected + γ× Σ(R m-shortage / R m-required ) In the formula, α, β, and γ are weighting coefficients, which are adjusted according to the actual situation of the system, and α + β + γ = 1; ΔR usage / △T represents the growth rate of task resource usage; R usage R represents the current resource usage of the task. expected R represents the expected resource usage for the task. m-shortage R represents the resource shortage of the m-th task affected by this task. m-required This represents the resource requirements of the m-th affected task.

[0036] When the risk value R is exceeded overload When the threshold is exceeded, the task is deemed to be at risk of overload, and the higher the value, the greater the risk of overload.

[0037] For example, during task execution, the system logs output resource usage data for the task, including CPU utilization, memory read / write frequency, network bandwidth usage, and actual business data. The data update frequency can be specified in real time by transmitting messages externally (e.g., from a non-real-time end), depending on the scenario. Simultaneously, the system tracks task execution progress; if the task is executed in stages, it records the completion status of each stage in real time, and the monitoring program provides real-time feedback on the progress percentage of each stage.

[0038] For example, during task execution, the priority is dynamically adjusted based on task resource utilization efficiency and execution progress deviation. If task resource utilization is high and execution progress is ahead of schedule, the priority is increased; conversely, if resource waste is severe and progress is lagging, the priority is decreased.

[0039] For example, during task execution, based on monitoring data from different task phases, if the task execution progress lags behind and resource demands increase reasonably, resources are promptly allocated from lower-priority tasks. For instance, if a monitoring task experiences a surge in data processing volume and slows down execution, the system automatically allocates some CPU and network resources from the information publishing task to the monitoring task.

[0040] During the end phase, including when a task is completed or terminated abnormally, all occupied resources are reclaimed, the system resource pool is updated, and the actual execution time and total resource usage of the task are recorded. Resource utilization efficiency during task execution is analyzed, and based on the analysis results, future resource allocation strategies for similar tasks are optimized. For example, if a certain type of task repeatedly has more than a preset value (e.g., 30%) of resources remaining at the end, then this task type is marked, and the initial resource allocation is reduced the next time this type of task is started.

[0041] In addition, after the task is completed, the priority of similar tasks is adjusted based on the execution results: tasks that are successfully and efficiently completed will have their priority increased when they are launched again; tasks that terminate abnormally or have extremely poor resource utilization will have their priority decreased.

[0042] If the priority of a task is adjusted multiple times during execution, the adjustment trajectory is recorded, generating a complete task lifecycle with a DNA-like significance, providing a reference for subsequent dynamic task priority adjustment models.

[0043] The task is marked at each stage of its entire lifecycle. Based on system logs and message data, the historical data obtained from these markings is transmitted to a non-real-time terminal for processing to generate a task profile, providing training and decision-making data samples for the model.

[0044] By adopting the above solution, the real-time system task scheduling resource allocation risk defense method disclosed in this application has the following technical effects: (1) By dynamically managing the entire lifecycle of the task, it provides a full-link anti-overload and anti-starvation solution for real-time system scheduling, which is especially suitable for highly complex industrial scenarios.

[0045] (2) By integrating task dependency topology and resource allocation, multi-dimensional scheduling optimization can be achieved, and the usage of different application scenarios can be refined.

[0046] (3) By implementing phased resource isolation, dynamic priority compensation and cross-phase feedback, the resource conflict problem in real-time task scheduling is systematically solved, which is suitable for high-performance computing and high-reliability scenarios.

[0047] Furthermore, this solution can be implemented based on a hybrid deployment framework, such as... Figure 2 As shown, the non-real-time computing model and model output tasks are completed by the non-real-time end (edge ​​node). The system logs collected by the real-time system are sent to the non-real-time end in the form of message data. Multiple computing models are configured on the non-real-time end to complete the analysis and calculation of task relationship topology, task life cycle, semantic analysis, etc., and the analysis and calculation results are sent to the real-time end (real-time system) in the form of message data.

[0048] Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications can still be made to the specific implementation of this application or equivalent substitutions can be made to some technical features without departing from the spirit of the technical solution of this application, and all such modifications and substitutions should be covered within the scope of the technical solution claimed in this application.

Claims

1. A method for mitigating risks in real-time system task scheduling and resource allocation, characterized in that, include: The system acquires task data submitted to the system and constructs a dynamic task dependency topology graph based on the task description, code logic, and interface call information. In the graph structure of the task dependency topology graph, each node represents a specific task, and its attributes include task ID, task type, and resource requirement information. Directed edges represent the dependencies between tasks, and the attributes of the edges include the dependency type and the corresponding weight. During the task initialization phase, resources are pre-allocated based on the task dependency topology and the resource requirements of each task. During task execution, the system monitoring service captures changes in task status and assesses the risks of task resource allocation. Based on the status capture and risk assessment results, the task dependency topology is updated, and task resource allocation is adjusted based on the updated task dependency topology.

2. The method according to claim 1, characterized in that, In the initial stage of task submission to the system, code parsing technology and semantic analysis algorithms are used to scan the task description file, code logic and interface call information, including: identifying data dependencies between tasks, mining control dependencies, and identifying potential temporal dependencies through in-depth analysis of task execution logic.

3. The method according to claim 2, characterized in that, The dependency weights are calculated using the following method: W dependcy = α× D data / Sum{D i, 0...i } + β × I critical / I total + γ × U irreplaceable / THE sum In the formula, W dependcy Let be the dependency weights, α, β, and γ be the weight coefficients, and satisfy α + β + γ = 1; D data For the amount of data transferred between tasks, Sum{D i, 0...i } represents the total amount of data transferred between all related tasks; I critical I represents the contribution of dependencies to the realization of key system functions. total This is the total contribution of all dependencies to the system's critical functions; U irreplaceable To score the degree of non-substitutability of the dependency, U sum It is the sum of the scores for the irreplaceability of all dependencies.

4. The method according to claim 1, characterized in that, During the task initialization phase, based on the task type, estimated execution time, and initial resource request information, a machine learning model is used to assess the rationality of the resource requirements at the start of the task, using historical data of similar tasks.

5. The method according to claim 1, characterized in that, Task resource allocation risks include the risk of starvation. The following methods are used to determine whether a task is likely to starve: T wait >λ× ΣT j-expected In the formula, T wait This represents the time a task waits for resources, where λ is the time coefficient, and T is the time. j-expected The estimated execution time of tasks 0 to j on which the task depends.

6. The method according to claim 5, characterized in that, The starvation risk value R is calculated using the following method. starve : R starve = ω× T wait / T deadline + ψ×Σ(1 - P l-progress ) / P l-total + θ ×R system-used / R system-total Where ω, ψ, and θ are weighting coefficients, and ω + ψ + θ = 1; T wait T represents the duration during which a task waits for resources. deadline The deadline for the task; P l-progress P represents the execution progress of the l-th task that the task depends on. l-total To depend on the overall task progress; R system-used R represents the amount of resources currently used by the system. system-total This represents the total system resources.

7. The method according to claim 1, characterized in that, Task resource allocation risks include the risk of resource overload. The following methods are used to determine whether a task is likely to be overloaded: R usage > µ × Σ R k-requierd × W k-dependency In the formula, R usage R represents the current actual resource usage of the task, µ is the resource usage coefficient, and R k-requierd W represents the resource requirements of task k, which are related to the task. k-dependency This represents the dependency weight between the task and its dependent task k.

8. The method according to claim 7, characterized in that, The risk of bursting (R) is calculated using the following method. overload : R overload = α×△R usage / △T + β×(R usage - R expected ) / R expected + γ× Σ(R m-shortage / R m-required ) In the formula, α, β, and γ are weighting coefficients, and α + β + γ = 1; ΔR usage / △T represents the growth rate of task resource usage; R usage R represents the current resource usage of the task. expected R represents the expected resource usage for the task. m-shortage R represents the resource shortage of the m-th task affected by the task. m-required This represents the resource requirements of the m-th affected task.

9. A risk defense device for real-time system task scheduling and resource allocation, characterized in that, include: The graph construction module is configured to: obtain task data submitted to the system, and construct a task dependency topology graph with dynamic characteristics based on the task description, code logic and interface call information of the task data; wherein, in the graph structure of the task dependency topology graph, each node represents a specific task, and its attributes include task ID, task type and resource requirement information, and directed edges represent the dependency relationship between tasks, and the edge attributes include dependency relationship type and corresponding weight. The resource pre-allocation module is configured to: pre-allocate resources during the task initialization phase based on the task dependency topology and the resource requirements of each task; The risk assessment module is configured to: capture changes in task status through system monitoring services during task execution, assess the risk of task resource allocation, update the task dependency topology based on the status capture and risk assessment results, and adjust task resource allocation based on the updated task dependency topology.

10. A system comprising a real-time terminal and a non-real-time terminal, wherein the real-time terminal includes the apparatus according to claim 9, wherein system logs collected by the real-time terminal are sent to the non-real-time terminal in the form of message data, and multiple analysis and calculation models are configured on the non-real-time terminal for analyzing and calculating the message data sent by the real-time terminal, and the analysis and calculation results are sent to the real-time terminal in the form of message data.

Images