A method and system for multi-task automated collaborative control of instruments
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-20
- Publication Date
- 2026-08-14
AI Technical Summary
S3:结合任务安全等级、实时性需求及执行时长计算各任务优先级;
[0016]本发明通过明确仪表运行状态间的跳转条件及互斥规则,避免不同任务同时抢占硬件资源;且结合任务安全等级、实时性需求及执行时长计算各任务优先级,对仪表运行状态进行精细化划分和约束,有效避免高优先级任务和低优先级任务冲突,对硬件资源的利用更加充分,提高运行效率。
Smart Images

Figure CN122570100A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of instrument automation, specifically to a method and system for multi-task automated collaborative control of instruments. Background Technology
[0002] Industrial instrumentation automation systems are an integral part of industrial production processes. They need to simultaneously undertake multiple concurrent tasks such as data acquisition, real-time control, fault protection, and remote communication. Different tasks have significantly different requirements for response time and resource consumption. Among them, fault protection and real-time control have extremely high requirements for system real-time performance and stability.
[0003] Currently, existing industrial instrument multi-task scheduling generally adopts a fixed priority scheduling strategy, that is, each task is pre-assigned a fixed priority, and the scheduler strictly executes tasks according to the order of priority. At the same time, the state management logic of existing systems is relatively simple, only distinguishing between basic states such as running and stopped, without fine-grained division and constraints on the instrument's operating state. This leads to: This can easily lead to different tasks competing for hardware resources simultaneously, which can cause problems such as control command disorder and data acquisition distortion, affecting the reliability of system operation.
[0004] When low-priority tasks (such as remote communication and data archiving) occupy a large amount of resources for a long time, it will cause high-priority tasks (such as fault protection and real-time control) to have delayed response or even be blocked, which cannot meet the high security requirements of industrial scenarios.
[0005] Alternatively, when high-priority tasks are idle, low-priority tasks may not be able to occupy the idle resources in time, resulting in a waste of hardware resources such as CPU, memory, and I / O interfaces; at the same time, frequent preemption by high-priority tasks may also cause low-priority tasks to be unable to execute for a long time, affecting the overall operating efficiency of the system. Summary of the Invention
[0006] In view of this, the present invention proposes a multi-task automated collaborative control method for instruments, comprising the following steps: S1: Initialize the instrument operating environment; S2: Divide the instrument operating states and define the jump conditions and mutual exclusion rules between the instrument operating states; S3: Calculate the priority of each task by combining the task's security level, real-time requirements, and execution time; S4: Combining the current operating status constraints of the instrument with the dynamic priority of each task, dynamically allocate instrument hardware resources and execute corresponding tasks, and dynamically update priorities according to a preset period during task execution.
[0007] Furthermore, in step S2, the instrument operating status includes standby status, data acquisition status, real-time control status, fault alarm status, and remote communication status. Each instrument operating status is triggered by the corresponding instrument operating task or signal.
[0008] Furthermore, in step S2, the transition conditions between instrument operating states include: Standby state transitions to data acquisition state: A data acquisition task request is received and no real-time control task or fault alarm task is triggered; Data acquisition status transitions to real-time control status: A real-time control task request is received and the task has a higher priority than the current data acquisition task; The data acquisition status or real-time control status jumps to the fault alarm status: a fault signal is detected and the fault signal value exceeds the preset fault threshold. Fault alarm status transitions to standby status: The fault protection task has been completed and the fault signal has returned to the normal range; The system transitions from standby or low-load real-time control to remote communication mode when a remote communication task request is received but no higher-priority task is triggered. The remote communication status transitions to data acquisition status, real-time control status, or fault alarm status when a higher priority task request is received.
[0009] Furthermore, in step S2, the mutual exclusion rules between states include: The fault alarm status is mutually exclusive with all other statuses. Real-time control status, data acquisition status, and remote communication status are mutually exclusive.
[0010] Furthermore, in step S3, the formula for calculating task priority is: ; in, P As a priority indicator, S For mission safety level, R To meet the real-time requirements of the task, L For task execution time, α , β , c S 、R、L The weight coefficients and satisfy α + β + c =1; The task's real-time requirements R The task execution duration L is the reciprocal of the maximum allowable delay time for the task, and is the ratio of the estimated task execution duration to the instrument's preset time slice length.
[0011] Furthermore, in step S3, the weighting coefficients are dynamically adjusted according to the instrument's operating conditions: When the instrument's CPU utilization exceeds the preset high load threshold, the task execution time is increased. L The weighting coefficient γ is used to reduce the weighting coefficient for real-time requirements. β ; When a fault signal is detected, increase the mission safety level. S The weighting coefficient α reduces the task execution time. L Weighting coefficients c .
[0012] Furthermore, step S4 includes: S41: Divide all tasks to be executed into a first priority queue and a second priority queue, and sort them in descending order of priority index within the queue; Among them, fault protection tasks and real-time control tasks are assigned to the first priority queue, while data acquisition tasks, remote communication tasks, and standby tasks are assigned to the second priority queue. S42: Determine if there are any pending tasks in the first priority queue. If so, execute them in descending order of priority within the first priority queue. After all tasks in the first priority queue have been executed, execute the pending tasks in the second priority queue. If not, execute the pending tasks in the second priority queue directly. During task execution, check if any new pending tasks appear in the first and second priority queues. Specifically, if a new task to be executed is detected in the first priority queue during the execution of a task in the first priority queue, and its priority index is higher than that of the currently executing task, then the current task is paused and the newly generated task is executed. If a new task is detected in the first priority queue while a task in the second priority queue is being executed, the current task will be paused and the newly detected task will be executed instead.
[0013] Furthermore, in step S4, the dynamic allocation of instrument hardware resources adopts a priority-based resource allocation algorithm. The resource allocation ratio is positively correlated with the task priority, and the calculation formula is as follows: , in, Res i For the first i Resource allocation for each task Res total This represents the total hardware resources of the instrument. P i For the first i The priority of each task. n This indicates the total number of tasks currently in progress.
[0014] Furthermore, the instrument multi-task automated collaborative control method also includes: Monitor task execution time in real time, set a timeout timer for each task in execution, pause the timed-out task and mark it as an abnormal task when the task execution timeout occurs, and prioritize the execution of high-priority tasks in the ready queue. When a task is submitted, all required resources are pre-allocated. The task checks for cyclical waiting relationships between tasks and resources at preset intervals. If such relationships exist, the task is paused and resources are reclaimed in order of priority from low to high.
[0015] Accordingly, the present invention also proposes an instrument multi-task automated collaborative control system for implementing the above method, comprising: The task management module is used to initialize the instrument operating environment, including configuring instrument operating parameters, registering instrument tasks, and initializing the extended finite state machine and task queue. The state management module is used to divide the instrument's operating state by extending the finite state machine, define the transition conditions and mutual exclusion rules between each state, and update the current operating state of the instrument in real time based on task execution feedback. The scheduling management module is communicatively connected to the status management module and the task management module, and is used to calculate the priority of each task by combining the task security level, real-time requirements and execution time, and generate hybrid scheduling instructions. The resource allocation module is communicatively connected to the scheduling management module and is used to dynamically allocate instrument hardware resources and execute corresponding tasks according to the hybrid scheduling instructions, and to reclaim resources after the task is completed. The monitoring and early warning module is used to monitor task timeouts, resource status, and prevent deadlocks.
[0016] This invention avoids different tasks from simultaneously occupying hardware resources by clearly defining the transition conditions and mutual exclusion rules between instrument operating states. Furthermore, by combining the task security level, real-time requirements, and execution duration to calculate the priority of each task, the instrument operating states are finely divided and constrained, effectively avoiding conflicts between high-priority and low-priority tasks, making fuller use of hardware resources, and improving operating efficiency. Attached Figure Description
[0017] Figure 1 This is a schematic diagram of a multi-task automated collaborative control method for instruments according to the present invention; Figure 2 This is a schematic diagram of the composition of a multi-task automated collaborative control system for instruments according to the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable the reader to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments.
[0019] In the following description, certain specific details are set forth for the purpose of illustrating various disclosed embodiments in order to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the art will recognize that embodiments may be practiced without one or more of these specific details. In other instances, well-known apparatuses, structures, and techniques associated with this application may not have been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.
[0020] Unless the context requires otherwise, throughout the specification and claims, the word “comprising” and its variations, such as “including” and “having”, shall be understood to have an open, inclusive meaning, that is, to be interpreted as “including, but not limited to”.
[0021] The embodiments of this application will be described in detail below with reference to the accompanying drawings to provide a clearer understanding of the purpose, features, and advantages of this application. It should be understood that the embodiments shown in the drawings are not intended to limit the scope of this application, but are merely for illustrating the essential spirit of the technical solution of this application.
[0022] Throughout this specification, references to "an embodiment" or "an embodiment" indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, the appearance of "in an embodiment" or "an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, or characteristic may be combined in any manner in one or more embodiments.
[0023] Industrial instrumentation automation systems are an integral part of industrial production processes. They need to simultaneously undertake multiple concurrent tasks such as data acquisition, real-time control, fault protection, and remote communication. Different tasks have significantly different requirements for response time and resource consumption. Among them, fault protection and real-time control have extremely high requirements for system real-time performance and stability.
[0024] Currently, existing industrial instrument multi-task scheduling generally adopts a fixed priority scheduling strategy, that is, each task is pre-assigned a fixed priority, and the scheduler strictly executes tasks according to the order of priority. At the same time, the state management logic of existing systems is relatively simple, only distinguishing between basic states such as running and stopped, without fine-grained division and constraints on the instrument's operating state. This leads to: This can easily lead to different tasks competing for hardware resources simultaneously, which can cause problems such as control command disorder and data acquisition distortion, affecting the reliability of system operation.
[0025] When low-priority tasks (such as remote communication and data archiving) occupy a large amount of resources for a long time, it will cause high-priority tasks (such as fault protection and real-time control) to have delayed response or even be blocked, which cannot meet the high security requirements of industrial scenarios.
[0026] Alternatively, when high-priority tasks are idle, low-priority tasks may not be able to occupy the idle resources in time, resulting in a waste of hardware resources such as CPU, memory, and I / O interfaces; at the same time, frequent preemption by high-priority tasks may also cause low-priority tasks to be unable to execute for a long time, affecting the overall operating efficiency of the system.
[0027] In view of this, the present invention proposes a method for multi-task automated collaborative control of instruments, such as... Figure 1 As shown, it includes the following steps: S1: Initialize the instrument operating environment; S2: Divide the instrument operating states and define the jump conditions and mutual exclusion rules between the instrument operating states; S3: Calculate the priority of each task by combining the task's security level, real-time requirements, and execution time; S4: Combining the current operating status constraints of the instrument with the dynamic priority of each task, dynamically allocate instrument hardware resources and execute corresponding tasks, and dynamically update priorities according to a preset period during task execution.
[0028] This invention avoids different tasks from simultaneously occupying hardware resources by clearly defining the transition conditions and mutual exclusion rules between instrument operating states. Furthermore, by combining the task security level, real-time requirements, and execution duration to calculate the priority of each task, the instrument operating states are finely divided and constrained, effectively avoiding conflicts between high-priority and low-priority tasks, making fuller use of hardware resources, and improving operating efficiency.
[0029] In step S1, the initialization of the instrument operating environment includes: configuring the instrument operating parameters, registering the instrument tasks and initializing the extended finite state machine and task queue.
[0030] Furthermore, in step S2, the instrument's operating status includes: Standby state: The instrument has no tasks to execute, only maintains basic operation, has the lowest resource utilization, and is the default initial state; Data acquisition status: The instrument is performing data acquisition tasks, occupying I / O interfaces and memory, but not performing control or alarm tasks; Real-time control status: The instrument performs real-time control tasks, occupying the CPU and control interface, and can perform low-frequency data acquisition tasks in parallel under low load; Fault alarm status: When the instrument detects fault signals such as over-temperature or over-pressure, it prioritizes fault protection and suspends all low-priority tasks. Remote communication status: The instrument performs remote communication tasks, occupying the communication interface and memory, and only executes when there are no high-priority tasks.
[0031] Furthermore, in step S2, the transition conditions between instrument operating states include: Standby state transitions to data acquisition state: A data acquisition task request is received and no real-time control task or fault alarm task is triggered; Data acquisition status transitions to real-time control status: A real-time control task request is received and the task has a higher priority than the current data acquisition task; The data acquisition status or real-time control status jumps to the fault alarm status: a fault signal is detected and the fault signal value exceeds the preset fault threshold. Fault alarm status transitions to standby status: The fault protection task has been completed and the fault signal has returned to the normal range; The system transitions from standby or low-load real-time control to remote communication mode when a remote communication task request is received but no higher-priority task is triggered. The remote communication status transitions to data acquisition status, real-time control status, or fault alarm status when a higher priority task request is received.
[0032] Furthermore, in step S2, the transition conditions between instrument operating states include: Standby state transitions to data acquisition state: A data acquisition task request is received and no real-time control task or fault alarm task is triggered; Data acquisition status transitions to real-time control status: A real-time control task request is received and the task has a higher priority than the current data acquisition task; The data acquisition status or real-time control status jumps to the fault alarm status: a fault signal is detected and the fault signal value exceeds the preset fault threshold. Fault alarm status transitions to standby status: The fault protection task has been completed and the fault signal has returned to the normal range; The system transitions from standby or low-load real-time control to remote communication mode when a remote communication task request is received but no higher-priority task is triggered. The remote communication status transitions to data acquisition status, real-time control status, or fault alarm status when a higher priority task request is received.
[0033] The reason for setting the jump conditions in this invention is that data acquisition is a basic but non-urgent task and should not preempt more important control or fault handling resources. Remote communication, as a secondary auxiliary task of the instrument, can only be executed when idle or when the real-time control task load is very low. Regardless of whether it is in acquisition or control mode, as long as a fault signal exceeding the threshold such as over-temperature or over-pressure is detected, the system will immediately jump to the fault alarm state. Building upon this, we further define a mutual exclusion condition, which is the state in which simultaneous actions cannot be performed: The fault alarm status is mutually exclusive with all other statuses. Real-time control status, data acquisition status, and remote communication status are mutually exclusive.
[0034] Furthermore, in step S3, the formula for calculating task priority is: ; in, P As a priority indicator, S For mission safety level, R To meet the real-time requirements of the task, L For task execution time, α , β , c S 、R、L Positive weight coefficients and satisfying α + β + c =1; The task's real-time requirements R The task execution duration L is the reciprocal of the maximum allowable delay time for the task, and is the ratio of the estimated task execution duration to the instrument's preset time slice length.
[0035] Security level and real-time requirements contribute positively to priority, ensuring that high-security and high-real-time tasks receive higher priority; task execution time contributes negatively to priority, preventing long-running tasks from occupying resources for extended periods.
[0036] Furthermore, the weighting coefficients are dynamically adjusted based on the instrument's operating conditions: When the instrument's CPU utilization exceeds the preset high load threshold, the task execution time is increased. L The weighting coefficient γ is used to reduce the weighting coefficient for real-time requirements. β This can prioritize suppressing long-running tasks, alleviate CPU load pressure, and prevent the system from experiencing overall response stagnation due to resource exhaustion; When a fault signal is detected but has not yet exceeded the preset fault threshold, the task safety level is increased. S The weighting coefficient α reduces the task execution time. L Weighting coefficients c,Prioritize high-security-level tasks, respond to potential faults in advance, and complete risk management before fault escalation; if the fault exceeds the preset threshold, directly jump to the fault alarm state.
[0037] In one embodiment, the following evaluation metrics are specifically defined: Task safety level S: Represents the safety level during task execution. The preset scoring range is 1-10 points. The higher the score, the higher the safety level. For example, fault protection S=10, real-time control S=8, data acquisition S=6, and remote communication S=4. Task real-time requirement R: Characterizes the task's requirement for response time, with units of 1 / ms. The larger the R value, the higher the real-time requirement. The calculation formula is: ,in This is the maximum allowed delay time for the task; Task execution duration L: Represents the time required to execute a task, expressed as the ratio of the estimated execution time to the time slice length. The smaller the L value, the higher the task execution efficiency. The calculation formula is: ,in Estimate the execution time (ms) for the task. The time slice length (ms) The default values for the weighting coefficients can be set as follows: α =0.5, β =0.3, c =0.2, prioritizing security level and real-time performance.
[0038] Step S4 includes: S41: Divide all tasks to be executed into a first priority queue and a second priority queue, and sort them in descending order of priority index within the queue; Tasks such as fault protection and real-time control, which are directly related to production safety and process stability, are placed in the first queue; auxiliary tasks such as data acquisition and remote communication are placed in the second queue, so as to prevent non-critical tasks from taking up core resources from the beginning.
[0039] S42: Determine if there are any pending tasks in the first priority queue. If so, execute them in descending order of priority within the first priority queue. After all tasks in the first priority queue have been executed, execute the pending tasks in the second priority queue. If not, execute the pending tasks in the second priority queue directly. During task execution, check if any new pending tasks appear in the first and second priority queues. Specifically, if a new task to be executed is detected in the first priority queue during the execution of a task in the first priority queue, and its priority index is higher than that of the currently executing task, then the current task is paused and the newly generated task is executed. If a new task is detected in the first priority queue while a task in the second priority queue is being executed, the current task will be paused and the newly detected task will be executed instead.
[0040] When executing tasks, a preemptive scheduling method is used for high-priority queues. As soon as a new task enters the queue, the low-priority task being executed is immediately paused, and resources are given to the critical task. For low-priority queues, a time-slice rotation method is used. When there are no high-priority tasks, the tasks in the queue take turns using CPU resources.
[0041] Furthermore, in step S4, the dynamic allocation of instrument hardware resources adopts a priority-based resource allocation algorithm. The resource allocation ratio is positively correlated with the task priority, and the calculation formula is as follows: , in, Res i For the first i Resource allocation for each task Res total This represents the total hardware resources of the instrument. P i For the first i The priority of each task. n This indicates the total number of tasks currently in progress.
[0042] The higher the priority of a task, the larger its share of resource allocation, and the more hardware resources such as CPU and memory it can obtain. Instead of allocating resources to tasks in a fixed manner, the allocation is adjusted in real time based on the priority of all tasks. When the instrument conditions change or the task priorities are updated, the resource allocation will also be updated synchronously. This avoids the problem of insufficient resources for high-priority tasks and also avoids the waste of idle resources.
[0043] Furthermore, during task execution, the task execution time is monitored in real time, and a timeout timer is set for each executing task. When a task times out, the timed-out task is paused and marked as an abnormal task, and high-priority tasks in the ready queue are executed first. When a task is submitted, all required resources are pre-allocated. The task checks for cyclical waiting relationships between tasks and resources at preset intervals. If such relationships exist, the task is paused and resources are reclaimed in order of priority from low to high.
[0044] Accordingly, this invention also proposes an instrument multi-task automated collaborative control system for implementing the above method, such as... Figure 2 As shown, it includes: The task management module is used to initialize the instrument operating environment, including configuring instrument operating parameters, registering instrument tasks, and initializing the extended finite state machine and task queue. The state management module is used to divide the instrument's operating state by extending the finite state machine, define the transition conditions and mutual exclusion rules between each state, and update the current operating state of the instrument in real time based on task execution feedback. The scheduling management module is communicatively connected to the status management module and the task management module, and is used to calculate the priority of each task by combining the task security level, real-time requirements and execution time, and generate hybrid scheduling instructions. The resource allocation module is communicatively connected to the scheduling management module and is used to dynamically allocate instrument hardware resources and execute corresponding tasks according to the hybrid scheduling instructions, and to reclaim resources after the task is completed. The monitoring and early warning module is used to monitor task timeouts, resource status, and prevent deadlocks.
[0045] The monitoring and alerting module sets a timeout timer for each executing task, with the initial value being the maximum allowable delay time for that task. The timer decrements by 1 every 1ms the task executes. When the timer reaches zero, if the task has not yet been completed, it is determined that the task has timed out. The monitoring and early warning module immediately sends a timeout warning signal to the scheduling and management module, and at the same time records the information of the timed-out task, including the task type, execution duration, and resource consumption. Upon receiving an early warning signal, the scheduling management module immediately suspends timed-out tasks, marks them as abnormal tasks, places them in the blocking queue, and prioritizes the execution of high-priority tasks in the ready queue. If the timed-out task is a high-priority task such as fault protection, emergency scheduling is initiated to reallocate more resources and restart the task. If the task still times out after two restarts, a system alarm is triggered, and staff are notified to intervene.
[0046] The solutions provided by the embodiments of this application have been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.
[0047] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0048] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
Claims
1. A method for multi-task automated collaborative control of instruments, characterized in that, Includes the following steps: S1: Initialize the instrument operating environment; S2: Divide the instrument operating states and define the jump conditions and mutual exclusion rules between the instrument operating states; S3: Calculate the priority of each task by combining the task's security level, real-time requirements, and execution time; S4: Combining the current operating status constraints of the instrument with the dynamic priority of each task, dynamically allocate instrument hardware resources and execute corresponding tasks, and dynamically update priorities according to a preset period during task execution.
2. The instrument multi-task automated collaborative control method according to claim 1, characterized in that, In step S2, the instrument operating status includes standby status, data acquisition status, real-time control status, fault alarm status and remote communication status. Each instrument operating status is triggered by the corresponding instrument operating task or signal.
3. The instrument multi-task automated collaborative control method according to claim 2, characterized in that, In step S2, the transition conditions between instrument operating states include: Standby state transitions to data acquisition state: A data acquisition task request is received and no real-time control task or fault alarm task is triggered; Data acquisition status transitions to real-time control status: A real-time control task request is received and the task has a higher priority than the current data acquisition task; The data acquisition status or real-time control status jumps to the fault alarm status: a fault signal is detected and the fault signal value exceeds the preset fault threshold. Fault alarm status transitions to standby status: The fault protection task has been completed and the fault signal has returned to the normal range; The system transitions from standby or low-load real-time control to remote communication mode when a remote communication task request is received but no higher-priority task is triggered. The remote communication status transitions to data acquisition status, real-time control status, or fault alarm status when a higher priority task request is received.
4. The instrument multi-task automated collaborative control method according to claim 2, characterized in that, In step S2, the mutual exclusion rules between states include: The fault alarm status is mutually exclusive with all other statuses. Real-time control status, data acquisition status, and remote communication status are mutually exclusive.
5. The instrument multi-task automated collaborative control method according to claim 1, characterized in that, In step S3, the formula for calculating task priority is: ; in, P As a priority indicator, S For mission safety level, R To meet the real-time requirements of the task, L For task execution time, α , β , γ S , R, L The weight coefficients and satisfy α + β + γ =1; The task's real-time requirements R The task execution duration L is the reciprocal of the maximum allowable delay time for the task, and is the ratio of the estimated task execution duration to the instrument's preset time slice length.
6. The instrument multi-task automated collaborative control method according to claim 5, characterized in that, In step S3, the weighting coefficients are dynamically adjusted according to the instrument's operating conditions: When the instrument's CPU utilization exceeds the preset high load threshold, the task execution time is increased. L The weighting coefficient γ is used to reduce the weighting coefficient for real-time requirements. β ; When a fault signal is detected, increase the mission safety level. S The weighting coefficient α reduces the task execution time. L Weighting coefficients γ .
7. The instrument multi-task automated collaborative control method according to claim 1, characterized in that, Step S4 includes: S41: Divide all tasks to be executed into a first priority queue and a second priority queue, and sort them in descending order of priority index within the queue; Among them, fault protection tasks and real-time control tasks are assigned to the first priority queue, while data acquisition tasks, remote communication tasks, and standby tasks are assigned to the second priority queue. S42: Determine if there are any pending tasks in the first priority queue. If so, execute them in descending order of priority within the first priority queue. After all tasks in the first priority queue have been executed, execute the pending tasks in the second priority queue. If not, execute the pending tasks in the second priority queue directly. During task execution, check if any new pending tasks appear in the first and second priority queues. Specifically, if a new task to be executed is detected in the first priority queue during the execution of a task in the first priority queue, and its priority index is higher than that of the currently executing task, then the current task is paused and the newly generated task is executed. If a new task is detected in the first priority queue while a task in the second priority queue is being executed, the current task will be paused and the newly detected task will be executed instead.
8. The instrument multi-task automated collaborative control method according to claim 1, characterized in that, In step S4, the dynamic allocation of instrument hardware resources adopts a priority-based resource allocation algorithm. The resource allocation ratio is positively correlated with the task priority, and the calculation formula is as follows: , in, Res i For the first i Resource allocation for each task Res total This represents the total hardware resources of the instrument. P i For the first i The priority of each task. n This indicates the total number of tasks currently in progress.
9. The instrument multi-task automated collaborative control method according to claim 1, characterized in that, Also includes: Monitor task execution time in real time, set a timeout timer for each task in execution, pause the timed-out task and mark it as an abnormal task when the task execution timeout occurs, and prioritize the execution of high-priority tasks in the ready queue. When a task is submitted, all required resources are pre-allocated. The task checks for cyclical waiting relationships between tasks and resources at preset intervals. If such relationships exist, the task is paused and resources are reclaimed in order of priority from low to high.
10. A multi-task automated collaborative control system for instruments, characterized in that, include: The task management module is used to initialize the instrument operating environment, including configuring instrument operating parameters, registering instrument tasks, and initializing the extended finite state machine and task queue. The state management module is used to divide the instrument's operating state by extending the finite state machine, define the transition conditions and mutual exclusion rules between each state, and update the current operating state of the instrument in real time based on task execution feedback. The scheduling management module is communicatively connected to the status management module and the task management module, and is used to calculate the priority of each task by combining the task security level, real-time requirements and execution time, and generate hybrid scheduling instructions. The resource allocation module is communicatively connected to the scheduling management module and is used to dynamically allocate instrument hardware resources and execute corresponding tasks according to the hybrid scheduling instructions, and to reclaim resources after the task is completed. The monitoring and early warning module is used to monitor task timeouts, resource status, and prevent deadlocks.