Task execution method, device and electronic device

Abstract

The application discloses a task execution method and device and electronic equipment. It relates to the technical field of task scheduling. The method comprises the following steps: writing a first task identifier into a first mapping table; sending a task execution instruction to a target device corresponding to the first task identifier; reading a second task identifier of the target device in a second mapping table; comparing whether the first task identifier and the second task identifier are the same; and in the case that the comparison result is that the first task identifier and the second task identifier are different, controlling the target device to switch from executing a second task corresponding to the second task identifier to executing the first task. The application solves the technical problem that, in the related art, when a task in a distributed system is processed, a device end cannot effectively process a key task of the system in a timely manner.

Description

Technical Field

[0001] This invention relates to the field of task scheduling technology, and more specifically, to a task execution method, apparatus, and electronic device. Background Technology

[0002] In distributed systems such as the Industrial Internet of Things (IIoT) and edge computing systems, the scheduling center needs to accurately distribute various task instructions to heterogeneous device terminals distributed throughout the system, requiring the devices to execute within a predetermined time window. This scenario is widely found in applications such as smart manufacturing production lines, smart building control, vehicle-to-everything (V2X) roadside equipment management, and agricultural IoT irrigation control. In related technologies, a typical task scheduling process is as follows: the scheduling center issues a start instruction to the target device at the scheduled start time of the task, and issues a stop instruction after the device completes execution, or the device proactively reports its completion status. However, in the above task scheduling process, when a device is executing a low-priority task, if a high-priority urgent task needs to be issued, the device may automatically determine the priority and process the task it determines to be of higher priority. However, the high-priority task determined by the device may not actually be a high-priority task, thus leading to the problem of high-priority critical tasks being blocked for a long time.

[0003] Therefore, in related technologies, when processing tasks in a distributed system, the device cannot handle critical system tasks in a timely and effective manner.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a task execution method, apparatus, and electronic device to at least solve the technical problem in the related art where the device cannot process critical system tasks in a timely and effective manner when processing tasks in a distributed system.

[0006] According to one aspect of the present invention, a task execution method is provided, comprising: writing a first task identifier into a first mapping table, wherein the first mapping table records task identifiers currently awaiting execution for one or more devices in a distributed system; sending a task execution instruction to a target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of a first task corresponding to the first task identifier; reading a second task identifier of the target device from a second mapping table, wherein the second mapping table records task identifiers currently being executed by the one or more devices; comparing whether the first task identifier and the second task identifier are the same; and, if the comparison result is that the first task identifier and the second task identifier are different, controlling the target device to switch from executing the second task corresponding to the second task identifier to executing the first task.

[0007] Optionally, writing the first task identifier into the first mapping table includes: obtaining the first priority of the first task and the second priority of the second task corresponding to the second task identifier already in the first mapping table; if the first priority is higher than the second priority, updating the second task identifier to the first task identifier.

[0008] Optionally, obtaining the first priority of the first task and the priority of the second task includes: taking the first task and / or the second task as target tasks, obtaining the time factor, health factor and resource factor of the target tasks; and determining the priority of the target tasks based on the time factor, the health factor and the resource factor.

[0009] Optionally, obtaining the time factor of the target task includes: obtaining the remaining waiting time of the target task and the task type of the target task, wherein the remaining waiting time is the difference between the planned start time of the task and the current time, and the task type includes an urgent task or a normal task; and determining the time factor of the target task based on the remaining waiting time and the task type.

[0010] Optionally, obtaining the health factor of the target task includes: obtaining the average response time of the target device responding to the scheduler multiple times, and the communication success rate of the target device communicating with the scheduler; and determining the health factor of the target task based on the average response time and the communication success rate.

[0011] Optionally, obtaining the resource factors of the target task includes: obtaining the expected execution time of the target task and the number of idle resources of the scheduler; and determining the resource factors of the target task based on the expected execution time and the number of idle resources.

[0012] Optionally, after comparing whether the first task identifier and the second task identifier are the same, the method further includes: if the comparison result is that the first task identifier and the second task identifier are the same, querying the execution status of the first task from the database; if the execution status is not completed, calculating the execution time of the first task; if the execution time exceeds a predetermined time, updating the execution status of the first task recorded in the database to execution failure.

[0013] Optionally, after controlling the target device to switch from executing the second task corresponding to the second task identifier to executing the first task, the method further includes: obtaining the update priority of the second task; if the update priority is lower than a preset threshold, updating the execution status of the second task recorded in the database to execution failure; if the update priority is higher than or equal to the preset threshold, storing the second task in the cache queue of the database, and after the first task is executed, retrieving the second task from the cache queue and controlling the target device to resume executing the second task.

[0014] Optionally, the first task and the second task are inspection tasks in which one or more devices in the distributed system inspect corresponding predetermined areas.

[0015] According to another aspect of the present invention, a task execution method is provided, comprising: receiving a task execution instruction sent by a scheduler, wherein the task execution instruction is used to instruct the execution of a first task identifier corresponding to a first task identifier, the first task identifier being a task identifier written in a first mapping table, the first mapping table recording task identifiers currently waiting to be executed by one or more devices in a distributed system; and receiving a task switching instruction sent by the scheduler, wherein the task switching instruction is used to instruct the execution of the first task instead of a second task corresponding to a second task identifier in a second mapping table, the second mapping table recording task identifiers currently being executed by the one or more devices, the first task identifier being different from the second task identifier.

[0016] According to another aspect of the present invention, a task execution apparatus is provided, comprising: a writing module, configured to write a first task identifier into a first mapping table, wherein the first mapping table records task identifiers currently awaiting execution by one or more devices in a distributed system; a sending module, configured to send a task execution instruction to a target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of a first task corresponding to the first task identifier; a reading module, configured to read a second task identifier of the target device from a second mapping table, wherein the second mapping table records task identifiers currently being executed by the one or more devices; a comparison module, configured to compare whether the first task identifier and the second task identifier are the same; and a control module, configured to control the target device to switch from executing the second task corresponding to the second task identifier to executing the first task if the comparison result is that the first task identifier and the second task identifier are different.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, including a stored executable program, wherein the executable program, when running, controls the device where the computer-readable storage medium is located to perform the above-described task execution method.

[0018] According to another aspect of the present invention, an electronic device is provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the task execution method described above when it runs.

[0019] According to yet another aspect of the present invention, a computer program product is provided, which, when executed by a processor, implements the steps of any of the methods described above.

[0020] In this embodiment of the invention, a first mapping table and a second mapping table are maintained in the scheduler's memory, and conflicts are detected by comparing the task identifiers corresponding to the same device in the two tables. Through task conflict detection, preemption decision-making, and cyclic confirmation and distribution based on database status on the scheduler side, the scheduler actively arbitrates the task execution rights at the device level, and achieves the purpose of reliable delivery and automatic remedy of task instructions. This achieves the technical effect of improving the response speed of critical tasks and the overall scheduling reliability of the system, and solves the technical problem in related technologies where the device cannot process critical tasks of the system in a timely and effective manner when processing tasks in a distributed system. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0022] Figure 1 This is a flowchart of a task execution method according to an embodiment of the present invention;

[0023] Figure 2 This is a flowchart of another task execution method according to an embodiment of the present invention;

[0024] Figure 3 This is a structural block diagram of a task execution device according to an embodiment of the present invention;

[0025] Figure 4 This is a structural block diagram of another task execution device according to an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] This application is primarily applied to various distributed systems, such as scenarios where a scheduling center (generally referred to as a scheduler) needs to issue task instructions to widely distributed terminal devices with varying hardware, and where high requirements are placed on the reliability of task execution and the response speed to emergency tasks. For example, it can be applied to intelligent manufacturing production lines, where the scheduling center issues production instructions to heterogeneous devices on the production line, such as Automated Guided Vehicles (AGVs), robotic arms, Programmable Logic Controllers (PLCs), and conveyor motors. At a certain point in time, a situation arises requiring emergency order insertion, such as when the production line experiences material shortages or malfunctions. The scheduler can immediately seize AGVs performing ordinary handling tasks, forcing them to perform emergency replenishment tasks to prevent production line downtime. This solution effectively ensures the accurate and reliable delivery of critical control commands (such as emergency stop and start), preventing equipment malfunctions or missed actions due to network fluctuations. For example, it can be applied to intelligent buildings and building automation scenarios. In such scenarios, the dispatch center manages air conditioning units, lighting controllers, elevators, access control systems, etc., distributed throughout the building. When a fire alarm occurs at a certain point in time, the dispatcher can forcibly interrupt the air conditioning or elevator tasks that are running in "normal energy-saving mode" and immediately issue "evacuation mode" or "fire linkage" commands. This effectively achieves compatibility of multi-protocol devices, shields the differences between devices of different brands and protocols, and thus effectively achieves unified dispatch.

[0029] According to an embodiment of the present invention, a method embodiment for a task execution method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0030] Figure 1 This is a flowchart of a task execution method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0031] Step S102: Write the first task identifier into the first mapping table, wherein the first mapping table records the task identifiers of one or more devices in the distributed system that are currently waiting to be executed;

[0032] As an optional embodiment, the execution subject of this method can be a terminal or a server used for task scheduling. For example, when applied to a terminal for task scheduling, it can easily implement task processing in relatively simple distributed system scenarios. Alternatively, when applied to a server, it can utilize the server's abundant computing resources or a larger and more accurate task processing model, thereby enabling more accurate scheduling of tasks in a larger distributed system. As an example, in this embodiment, the execution subject of this method is a scheduler in a distributed system.

[0033] It should be noted that the types of terminals mentioned above can be various, such as mobile terminals with certain computing capabilities or fixed computer devices with identification capabilities. Similarly, the types of servers mentioned above can also be various, such as local servers or virtual cloud servers. Servers, based on computing power, can be single computer devices or computer clusters integrating multiple computer devices.

[0034] As an optional embodiment, the aforementioned first task identifier is used to identify a first task, which is a task to be executed in the distributed system. The distributed system includes various terminal devices, and different terminal devices can be used to execute different tasks. The specific terminal device executing which task is determined by the scheduler in the distributed system. For example, the first task is assigned by the scheduler to a target device in the distributed system for execution. In this embodiment of the invention, the first task is the task that the scheduler assigns to the target device for priority processing.

[0035] As an optional embodiment, the aforementioned first mapping table records the task identifiers currently awaiting execution for one or more devices in the distributed system. That is, the first mapping table is used to record the task identifiers currently awaiting execution for each device, allocated by the scheduler. Since the task identifiers currently awaiting execution for each device recorded in the first mapping table are allocated by the scheduler, and the scheduler allocates these tasks based on the current state of the entire distributed system, the task identifiers currently awaiting execution for each device have global applicability across the entire distributed system. The first mapping table represents the scheduler's final scheduling target for a particular device. Regardless of the intermediate processes, the value stored in the first mapping table is the task the scheduler wants the device to currently execute. When a new task arrives in the first mapping table, the scheduler first updates this table, indicating that the scheduler has decided to allow the device to execute this new task.

[0036] It should be noted that one or more devices in the aforementioned distributed system can be distributed across various locations within the distributed system. These devices can be heterogeneous, meaning they differ in hardware architecture, operating system, communication protocol, processing power, or software environment, but can all connect to the distributed system and execute corresponding tasks. These devices can be at the network edge, directly facing the user, or in the physical world; they are typically the executors of the tasks.

[0037] Step S104: Send a task execution instruction to the target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier;

[0038] As an optional embodiment, the aforementioned target device refers to a terminal device in a distributed system that receives unified scheduling from the scheduler for task execution. After the scheduler completes its task scheduling decision, it determines the corresponding target device based on the task allocation result and sends a task execution instruction to that target device. Upon receiving the task, the target device can execute the corresponding task based on its local resource status, operating environment, and scheduling strategy, and during task execution, it will provide feedback to the scheduler regarding device status, task progress, and execution results.

[0039] It should be noted that the target device can be of various types, such as a server, edge node, compute node, terminal device, virtual machine, container instance, or other device with computing capabilities, as long as the target device can receive tasks issued by the scheduler and perform corresponding processing.

[0040] As an optional embodiment, the above-mentioned task execution instruction is a control signal issued by the scheduler to notify the target device to start the execution process of the first task.

[0041] Step S106: Read the second task identifier of the target device from the second mapping table, wherein the second mapping table records the task identifiers of one or more devices currently executing;

[0042] As an optional embodiment, the aforementioned second task identifier is used to identify a second task, which is a task being executed in the distributed system. This second task is a task that has been assigned by the scheduler to a target device in the distributed system and is currently being executed.

[0043] As an optional embodiment, the second mapping table records the task identifiers currently being executed by one or more devices in the distributed system. That is, the second mapping table is used to record the task identifiers assigned by the scheduler to each device and currently being executed by each device. Since the second mapping table records the task identifiers currently being executed by each device, the table can have two states: empty or containing values. Regardless of the state, the value stored in the second mapping table is the task that the scheduler has assigned to the target device and is currently executing.

[0044] It should be noted that when the scheduler reads the task identifier of the target device in the second mapping table, if it is empty, it directly writes the task identifier of the first mapping table into the task identifier of the second mapping table. At this time, the first task identifier and the second task identifier are consistent.

[0045] It's important to note that "awaiting execution" means the scheduler has identified the target task as the current priority task, i.e., the task status has already been issued to the device. "Executing" means the scheduler sends the corresponding task execution instruction to the device, and the device continuously reports the task execution status during execution, with the scheduler confirming whether the task has been completed. "Waiting to execute" indicates the scheduler has generated a scheduling decision and written the task identifier into the first mapping table, signifying that this task is the latest scheduling intent for the current device; at this point, the task may not have been issued yet. "Executing" means the task identifier already exists in the second mapping table, indicating that the task has entered the scheduler's active distribution and confirmation process. This includes not only the actual task execution status on the device side but also intermediate active states such as after the task instruction has been issued, or just issued but not yet in the active confirmation process, waiting for device feedback, or undergoing status retransmission.

[0046] Step S108: Compare whether the first task identifier and the second task identifier are the same;

[0047] The two mapping tables above distinguish between two task states: the first mapping table records tasks "awaiting execution," representing the scheduler's latest intent; the second mapping table records tasks "currently executing," representing the active processes the scheduler is currently monitoring. Comparing the first and second task identifiers essentially compares the "latest scheduling intent" with the "current active state." If they match, it indicates the scheduling intent has been implemented and is consistent with the currently active task; if they differ, it indicates the scheduler has generated a new scheduling intent (new task), while the device is still in the active processing flow of the old task, thus creating a conflict.

[0048] In step S110, if the comparison result shows that the first task identifier and the second task identifier are different, the control target device switches from executing the second task corresponding to the second task identifier to executing the first task.

[0049] As an optional embodiment, if the comparison result shows that the first task identifier and the second task identifier are different, it indicates that the urgent first task to be processed is not the currently processed second task. In order to handle the more urgent and critical task, it is necessary to control the target device to interrupt the processing of the second task and switch to the more urgent first task. By controlling the target device to switch task processing, high-priority tasks can bypass or interrupt low-priority tasks without waiting for the device to make its own judgment, effectively realizing the efficient scheduling function of the scheduler.

[0050] As an optional embodiment, writing the first task identifier into the first mapping table can be done in various ways. For example, the following processing method can be used: obtain the first priority of the first task and the second priority of the second task corresponding to the second task identifier already in the first mapping table; if the first priority is higher than the second priority, update the second task identifier to the first task identifier. The aforementioned priority refers to task priority. Task priority is a parameter used to characterize the urgency and importance of different tasks in a distributed system. The scheduler determines the task scheduling order, execution details, and resource allocation strategy based on task priorities. The first priority refers to the priority corresponding to the first task identifier, and the second priority refers to the priority corresponding to the second task identifier. Based on the above processing, updating and writing the first task identifier corresponding to the higher-priority first task into the first mapping table can ensure that the previously prioritized urgent and critical first task is processed first.

[0051] It should be noted that the terms "first" and "second" in this example are used only to distinguish different objects or steps, and do not indicate any difference in their order of priority, execution, or importance.

[0052] As an optional embodiment, when the scheduler obtains the first priority of the first task and the second priority of the second task, it can perform quantitative calculations based on the multi-dimensional feature parameters of each task. For example, the scheduler can obtain the feature parameters of the first task and the second task respectively. The feature parameters include, but are not limited to: time dimension parameters (such as remaining waiting time, task type, etc.), device status dimension parameters (such as communication health, etc.), and resource dimension parameters (such as expected execution time and system idle resources, etc.). Then, the priority of the first task and the second task is determined based on the feature parameters.

[0053] As an optional implementation, after obtaining the first priority and the second priority, the scheduler performs a comparison operation: if the first priority is higher than the second priority, it indicates that the business urgency or global importance of the first task (new task) is higher than that of the second task (old task) currently waiting to be executed. At this time, the scheduler updates the second task identifier recorded in the first mapping table to the first task identifier, thereby establishing the first task as the latest scheduling intention of the current target device on the scheduler side, preparing for sending task execution instructions for the first task to the target device; if the first priority is not higher than the second priority, the second task identifier in the first mapping table remains unchanged, and the original scheduling order is maintained to avoid unnecessary task switching overhead.

[0054] Optionally, obtaining the first priority of the first task and the priority of the second task can be done in various ways. For example, the first task and / or the second task can be taken as the target task, and the time factor, health factor and resource factor of the target task can be obtained; the priority of the target task can be determined based on the time factor, health factor and resource factor.

[0055] As an optional implementation, the scheduler uses a multi-dimensional index fusion approach when determining task priorities to comprehensively assess the urgency and feasibility of tasks within the current distributed system. Specifically, the scheduler extracts three key dimension factors reflecting task urgency, equipment reliability, and resource efficiency for the first task and / or the second task (referred to as the target task): a time factor, a health factor, and a resource factor.

[0056] As an optional implementation, the time factor is used to quantify the urgency of a task in the time dimension, determined based on the remaining waiting time and task type. For example, a short remaining waiting time or an urgent task type usually indicates a higher priority scheduling requirement in the time dimension. The health factor is used to quantify the stability of the communication link between the target device and the scheduler and the device status. For example, the faster the target device responds and the more stable the communication, the higher its health level, and the higher the corresponding health factor, which helps the scheduler determine the reliability of instruction issuance. The resource factor is used to quantify the matching degree between the task execution's occupation of system resources and the system's current carrying capacity. For example, a short expected execution time for the target task or sufficient idle resources in the current system indicates that the task is easily accepted by the system, corresponding to a high resource factor.

[0057] The scheduler assesses the time sensitivity of a task by obtaining its remaining waiting time (i.e., the difference between the scheduled start time and the current time) and the task type (e.g., urgent or normal). A shorter remaining waiting time or a more urgent task type generally indicates a higher priority scheduling requirement in terms of time. The specific time factor calculation logic will be explained in detail in subsequent embodiments.

[0058] The scheduler assesses the online health status of the target device by acquiring its keep-alive communication records (including response time and communication success markers) over a specified time period. Faster device responses and more successful communications indicate higher health, and a higher corresponding health factor. This helps the scheduler determine the reliability of command issuance. The specific health factor calculation logic will be explained in detail in subsequent embodiments.

[0059] The scheduler assesses resource efficiency by obtaining the estimated execution time of the target task and the current amount of idle resources in the system (such as CPU, memory, or bandwidth remaining). A higher resource factor indicates that the task is more likely to be accepted by the system when the estimated execution time is short or when there are ample idle resources. The specific logic for calculating the resource factor will be explained in detail in subsequent embodiments.

[0060] It should be noted that, to more accurately quantify task priority, after obtaining the time factor, health factor, and resource factor of the target task, the scheduler can perform relevant calculations on these three factors to obtain a value used to evaluate task priority. For example, the product of the three factors can be directly used as the scheduling priority of the target task, which represents the priority value of the task. Based on this dynamic calculation mechanism, the scheduling priority not only reflects the urgency of the task in the time dimension but also comprehensively considers the health status of the equipment and the degree of resource matching. This multi-dimensional integrated evaluation ensures that the preemption decision not only responds promptly but also takes into account the overall system operating efficiency, thereby achieving globally optimal task scheduling.

[0061] Optionally, when obtaining the time factor of the target task, the following methods can be used: obtain the remaining waiting time of the target task and the task type of the target task, wherein the remaining waiting time is the difference between the planned start time of the task and the current time, and the task type includes urgent tasks or normal tasks; determine the time factor of the target task based on the remaining waiting time and the task type.

[0062] As an optional implementation, to quantify the demand intensity for prioritizing the scheduling of the target task in the current distributed system, the scheduler determines the time factor by obtaining the remaining waiting time of the target task and the task type.

[0063] As an optional implementation, the remaining waiting time is the difference between the task's planned start time and the current system time. This parameter directly reflects the urgency of the task's approaching its scheduled execution time. For example, when the remaining waiting time is greater than zero, it indicates that the task has not yet reached its planned start time, and its urgency is relatively low; when the remaining waiting time is equal to zero or less than zero, it indicates that the task has reached or exceeded its planned start time, and its urgency is significantly increased, usually meaning that the task needs to be scheduled for execution immediately, otherwise it may cause critical tasks to time out.

[0064] As an optional implementation, task type is used to characterize the urgency of a task in terms of business logic. In this embodiment, task types mainly include urgent tasks and ordinary tasks. For example, for urgent tasks, the scheduler tends to assign them a higher time factor, especially when the remaining waiting time approaches zero, the time factor usually jumps to a high value (such as a forced preemption value) to ensure that urgent tasks can immediately obtain the highest scheduling priority; for ordinary tasks, the scheduler dynamically adjusts the time factor according to changes in the remaining waiting time. Typically, as the remaining waiting time decreases, the time factor shows an increasing trend (e.g., through a logarithmic growth model), so that ordinary tasks closer to the planned start time have a larger time factor value, thereby obtaining a higher priority in resource competition.

[0065] For example, the time factor can be calculated as follows: if the target task is an urgent task and the remaining waiting time is greater than zero, the time factor is a fixed high value; if the remaining waiting time is zero, the time factor is a forced preemption value, and the forced preemption value is greater than the fixed high value, where the remaining waiting time is the difference between the planned start time of the target task and the current time; if the target task is a normal task, the time factor is obtained based on the remaining waiting time according to a predetermined calculation method, for example, it can be calculated based on a pre-defined logarithmic function model of the remaining waiting time.

[0066] As an optional implementation, the scheduler executes different time factor calculation logic based on two task types: urgent tasks and normal tasks. The specific steps are as follows:

[0067] When a target task is marked as an urgent task, the scheduler determines its remaining waiting time, falling into two categories: If the remaining waiting time is greater than zero, it indicates that the urgent task has not yet reached its planned start time, but due to its urgency, the scheduler sets its time factor to a fixed high value. This fixed high value ensures that the urgent task enjoys higher scheduling priority before its due date, distinguishing it from ordinary tasks. If the remaining waiting time is equal to zero, it indicates that the urgent task has reached or exceeded its planned start time, and the scheduler sets its time factor to a forced preemption value. This forced preemption value is greater than the aforementioned fixed high value. By assigning a higher forced preemption value, the scheduler ensures that the urgent task has an absolute advantage in priority comparison, thereby triggering a preemption mechanism for low-priority tasks currently being executed, ensuring that urgent instructions can be issued and executed immediately.

[0068] When a target task is marked as a regular task, the scheduler dynamically calculates the time factor based on the remaining waiting time. For example, the scheduler can use a pre-defined logarithmic function model, with the remaining waiting time as the independent variable, to calculate the time factor. Typically, the logarithmic function model exhibits monotonically increasing properties (e.g., constructed from the reciprocal of the remaining time), and the calculated time factor value increases as the remaining waiting time decreases (i.e., the closer the task is to its scheduled start time). This method embodies a near-time-priority scheduling strategy, allowing regular tasks that are about to time out to receive higher priority, thus preventing task timeout failure.

[0069] In a preferred embodiment, the time factor for a typical task can be calculated using the following logarithmic function model:

[0070]

[0071] in, As a time factor, To preset the baseline duration, The remaining waiting time, It is the natural logarithm. The time factor reaches its maximum value under this calculation method when the remaining waiting time approaches zero.

[0072] Optionally, the health factors of the target task can be obtained by: obtaining the average response time of the target device in multiple responses to the scheduler, and the communication success rate between the target device and the scheduler; and determining the health factors of the target task based on the average response time and the communication success rate.

[0073] As an optional implementation, to quantify the stability of the communication link between the target device and the scheduler and the device's current online health status, the scheduler can determine health factors by periodically collecting keep-alive communication records. These keep-alive communication records include: the target device's average response time and communication success rate.

[0074] As an optional implementation, the average response time reflects the speed at which the target device processes instructions or responds to requests. The scheduler calculates the time difference between when the target device receives an instruction or heartbeat packet from the scheduler and returns a response within a specified time period (e.g., in the most recent N keep-alive interactions or task instruction interactions). The average response time is obtained by calculating the arithmetic mean of these multiple response times. Generally, a shorter average response time corresponds to a higher health factor value, indicating a faster device response, a smoother communication link, and a more active device state.

[0075] As an optional implementation, the communication success rate reflects the reliability of the communication link. The scheduler counts the total number of communication requests sent to the target device within the same specified time period, and the number of times a valid response is successfully received from the target device. The communication success rate is obtained by calculating the ratio of the successful requests to the total number of requests. Generally, a higher communication success rate corresponds to a larger health factor value, indicating fewer packet losses, timeouts, or connection interruptions, and better device stability.

[0076] Optionally, the resource factors of the target task can be obtained in the following ways: obtain the expected execution time of the target task and the amount of idle resources of the scheduler; determine the resource factors of the target task based on the expected execution time and the amount of idle resources.

[0077] As an optional implementation, in order to quantify the matching degree between the system resource occupancy of task execution and the current system capacity, the scheduler can determine the resource factor by obtaining the expected execution time and the amount of idle resources.

[0078] As an optional implementation, the estimated execution time refers to the time estimated by the scheduler from the start to the completion of the target task based on the task type, historical execution data, or task description. This parameter reflects the scale of computing and time resources occupied by the task. Generally, the shorter the estimated execution time and the larger the resource factor value, the less system resources the task consumes, the higher the execution efficiency, and the easier it is to complete within a limited resource window.

[0079] As an optional implementation, the amount of idle resources refers to the total amount of system resources currently available to the scheduler, such as remaining CPU computing power, remaining memory space, remaining network bandwidth, or remaining storage I / O capacity. This parameter reflects the current resource sufficiency of the system. Generally, the more idle resources there are, the larger the resource factor value, indicating that the current system load is lower and the ability to accept new tasks is stronger. When determining the resource factor of a target task based on the expected execution time and the amount of idle resources, the expected execution time and the amount of idle resources can be normalized to obtain the resource factor of the target task.

[0080] Optionally, after comparing whether the first task identifier and the second task identifier are the same, the method further includes: if the comparison result shows that the first task identifier and the second task identifier are the same, querying the execution status of the first task from the database; if the execution status is not "execution completed", calculating the execution time of the first task; if the execution time exceeds a predetermined time, updating the execution status of the first task recorded in the database to "execution failed".

[0081] As an optional implementation, a database refers to a data storage structure used to store and manage task status information, recording the current execution status of each task in the distributed system. Task status information reflects the task's execution progress and lifecycle status.

[0082] As an optional implementation, execution status refers to information used to characterize the current execution status of the target task, reflecting the stage in the task's lifecycle. Execution status includes, but is not limited to, executing status, execution completed status, and execution failed status.

[0083] As an optional implementation, execution duration refers to the actual execution time of the target task from the start of execution to the current time, which reflects the duration of execution of the target task.

[0084] As an optional embodiment, the predetermined duration refers to the planned execution time of the target task pre-set based on the task requirements, which is used to limit the time range within which the target task is expected to be completed.

[0085] Optionally, after the target device switches from executing the second task corresponding to the second task identifier to executing the first task, the method further includes: obtaining the update priority of the second task; if the update priority is lower than a preset threshold, updating the execution status of the second task recorded in the database to execution failure; if the update priority is higher than or equal to the preset threshold, storing the second task in the cache queue of the database, and after the first task is executed, retrieving the second task from the cache queue and controlling the target device to resume executing the second task.

[0086] As an optional implementation, when the scheduler detects that the scheduling value of the target task (first task) is higher than the scheduling value of the currently executing task (second task), the scheduler issues a command to control the target device to switch tasks. After the scheduler has confirmed and issued execution control for the first task, the scheduler needs to evaluate the subsequent processing strategy for the interrupted task (second task) to avoid resource waste or service interruption.

[0087] Specifically, after triggering the task switching action, the scheduler obtains the updated priority of the second task at the current moment (for example, it can also calculate the current priority of the second task based on the time, health, and resource factors mentioned above). Then, the obtained updated priority is compared with the system's preset priority threshold to determine the final state of the second task, including two scenarios: abandoning the low-value task and retaining the high-value task, as follows:

[0088] If the update priority of the second task is lower than the priority threshold, it indicates that the task has low business importance at the current moment, or its execution value is insufficient to support its continued waiting after interruption. The scheduler updates the execution status of the second task recorded in the database to execution failure, thereby releasing related resources (such as database records, memory-mapped tables, and logical resources) and avoiding resource waste.

[0089] If the update priority of the second task is higher than or equal to a preset threshold, it indicates that the task has high business importance. The scheduler stores the information of the second task in the database's cache queue and suspends it. After the first task is completed, the scheduler retrieves the second task from the cache queue and controls the target device to resume execution of the second task. This mechanism effectively avoids business interruptions caused by emergency task preemption and improves resource utilization. It also enables dynamic task scheduling based on the real-time changing priorities of tasks.

[0090] Optionally, the first task and the second task can be various tasks. For example, they can be inspection tasks in a distributed system where one or more devices inspect a predetermined area. Of course, the first task and the second task mentioned above can also be various other types of tasks, which will not be listed here.

[0091] The aforementioned inspection task refers to the task of instructing the target device by the scheduler to go to a designated physical or logical area to collect data, monitor status, or detect anomalies in the objects, equipment, or environment within that area.

[0092] Specifically, the main entities performing inspection tasks are terminal devices in the distributed system (such as AGVs, robotic arms, mobile robots, fixed cameras, or sensor nodes). Their tasks include, but are not limited to: physical object inspection, such as dispatching AGVs to warehouse shelving areas to check the presence, quantity, and packaging of goods; equipment status inspection, such as dispatching mobile robots or inspection robots to periodically patrol fixed equipment (such as motors, pumps, valves, and conveyors) on factory production lines, collecting operational data such as temperature, vibration, and noise to determine if the equipment is malfunctioning; environmental / safety inspection, such as dispatching drones or fixed monitoring nodes to patrol the factory environment to detect smoke, flames, leaks, or other safety hazards; and process compliance inspection, such as dispatching equipment to check whether critical steps in the production process are performed according to standards. By executing such inspection tasks, the scheduler can achieve automated, periodic, or trigger-based monitoring of distributed resources in the distributed system, thereby improving the system's automation level and operational efficiency.

[0093] In this embodiment of the invention, another task execution method is also provided. Figure 2 This is a flowchart of another task execution method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0094] Step S202: Receive a task execution instruction sent by the task scheduler. The task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier. The first task identifier is a task identifier written into the first mapping table. The first mapping table records the task identifiers that one or more devices in the distributed system are currently waiting to be executed.

[0095] Step S204: Receive a task switching instruction sent by the task scheduler. The task switching instruction is used to indicate that the execution of the second task corresponding to the second task identifier in the second mapping table is switched to the execution of the first task. The second mapping table records one or more task identifiers being executed by the device. The first task identifier is different from the second task identifier.

[0096] exist Figure 2 The illustrated embodiment provides a task execution method described from the target device (such as AGV, PLC, edge computing node, etc.) side in a distributed system. It should be noted that the aforementioned "first mapping table" and "second mapping table" are mainly used to define the decision logic of the task scheduler and the business context of the instructions. In practical applications, the target device, as the receiver and executor of the instructions, executes the corresponding actions based on the specific instructions issued by the scheduler after determining the results based on the aforementioned first and second mapping tables.

[0097] Based on the above steps, the target device receives the task execution command and task switching command sent by the scheduler and performs the corresponding operations. For example, when the target device receives the task execution command, if there is no task currently running, it directly loads and executes the task in the command; when the target device receives the task switching command, it indicates that the scheduler has determined that the new task has a higher priority than the currently executing second task. At this time, the target device immediately suspends the execution of the current task, releases relevant resources, and begins executing the first task, allowing the scheduler to synchronize the global scheduling intent based on the target device's execution status. Through this mechanism, the device does not need to implement complex scheduling algorithms; it only needs to respond to commands to quickly switch from low-priority tasks to high-priority tasks, thereby reducing the resource consumption of the device while ensuring real-time system response.

[0098] In conjunction with the above embodiments and optional embodiments, an optional implementation method is also provided.

[0099] In distributed systems within related technologies, there are two main types of task scheduling schemes. The first is an asynchronous delivery scheme based on message queues. The scheduler encapsulates task instructions as messages and publishes them to middleware. Devices subscribe and consume these messages, and the scheduler only sends the message without confirming whether the device actually receives or executes it. The second is a pull scheme based on periodic polling. The scheduler writes tasks to a shared database, and devices periodically poll and pull tasks belonging to their own device for execution, then execute them themselves. Based on these two types, a scheme based on a dual record of message queue and database status has also been proposed. In this scheme, the scheduler creates a database execution record and marks it as delivered when a task reaches its predetermined time. Simultaneously, it sends instructions to the message queue. After consuming the message, the device executes it and updates its status via an application programming interface (API) callback. The scheduler periodically scans tasks whose status has not been updated for a long time and marks them as timed out and failed.

[0100] However, the above task scheduling schemes have some technical flaws. First, the scheduler cannot obtain closed-loop confirmation of task execution. For example, in message queue-based schemes, the scheduler considers the task successfully dispatched after issuing the instruction, but due to network interruptions, device process restarts, or insufficient resources, the device may not actually receive the instruction or may fail to execute it after receiving it, resulting in a discrepancy between the task status recorded by the scheduler and the actual execution status of the device. Second, there is a lack of arbitration mechanisms for task conflicts and preemption at the device level. When a device is executing a low-priority task, if a high-priority urgent task needs to be issued, the relevant technologies cannot allow the scheduler to actively interrupt the currently executing task. Although some schemes allow the device to determine the priority itself, the device lacks global scheduling information and finds it difficult to make reasonable decisions, resulting in critical tasks being blocked for a long time. Third, there is a lack of automatic recovery paths for instruction issuance failures. In relevant technologies, when message sending fails, only logs are usually logged or alarms are triggered, requiring manual intervention. In unattended scenarios, tasks often miss the execution time window. Fourth, some solutions maintain the task status in the scheduler process memory. After the scheduler restarts, the memory status is lost, resulting in the task status being suspended or repeatedly sent.

[0101] To address the aforementioned issues, the scheduler needs to achieve reliable delivery of task instructions and accurate synchronization of device states with limited communication overhead in a distributed environment characterized by unreliable networks and uncertain device states. Simultaneously, it must maintain the task occupancy state at the device level without introducing heavyweight dependencies such as distributed locks, and ensure the atomicity of state transitions in preemptive scenarios. This requires striking a balance between the scheduler's lightweight design and reliability guarantees. Distributed locks are a method used in distributed systems to control mutual exclusion access to shared resources by multiple processes (or threads). They ensure that only one node (server / process) can execute code or modify data at any given time in a distributed environment, preventing concurrency conflicts.

[0102] Based on the above considerations, in this optional embodiment, two mapping tables are maintained in the scheduler's memory, with device names as keys and task identifiers as values. The first mapping table records the latest task identifiers waiting to be executed for each device. When a new task is scheduled to a device, the device's record in the first mapping table is updated with the new task's identifier. The second mapping table records the task identifiers currently in the distribution process for each device. The scheduler detects task conflicts by comparing whether the task identifiers of the same device in the two mapping tables are consistent, and triggers preemption arbitration when they are inconsistent, thereby achieving proactive management of device execution rights.

[0103] It should be noted that the first mapping table mentioned above can be understood as the waiting dispatch table, and the second mapping table can be understood as the dispatching table. The first mapping table records the latest task identifier that each device currently expects to execute. It records the global intent of the entire distributed system and represents the scheduler's final scheduling target for a particular device. Regardless of the intermediate process, the value stored in this table is the task that the scheduler wants the device to currently execute. The second mapping table records the task identifier that each device is currently in the instruction issuance, confirmation, or retransmission process. It identifies active processes and represents the task that the scheduler is currently processing. Only tasks listed in this table will be sent instructions, have their status queried, or be retransmitted by the scheduler.

[0104] After the delayed (or immediate) scheduling of a task is completed, the scheduler writes the current task identifier into the first mapping table, then sends a task start command to the target device and enters a cyclical confirmation process. In each round of confirmation, the scheduler first reads the task identifier of the device from the second mapping table. If it is empty, the value in the first mapping table is written synchronously. If it is not empty and is inconsistent with the current value in the first mapping table, preemption arbitration is triggered. The core of arbitration lies in the scheduling priority evaluation based on multi-dimensional factors: the scheduler obtains the task's time factor (based on remaining waiting time and task type), health factor (based on average device response time and communication success rate), and resource factor (based on expected execution time and number of idle resources), and determines the task's scheduling priority based on the product of the three. The scheduler compares the scheduling priority of the new task with that of the preempted task. If the new task has a higher value, preemption is performed. After preemption, the scheduler evaluates the update priority of the preempted task. If it is lower than a preset threshold, it is marked as failed to release resources. If it is higher than or equal to the preset threshold, it is stored in the database cache queue and suspended until the current task is completed and execution resumes. The arbitration logic is as follows: If the current value of the device in the first mapping table is equal to the task identifier of the current round of distribution, it means that the current task is a newly arrived task. The second mapping table is updated to the same value and distribution continues. If the current value of the device in the first mapping table is not equal to the task identifier of the current round of distribution, it means that the current task has been overwritten by a new task. The system clears the record of the device in both mapping tables, updates the status of the current task in the database to failure, and immediately terminates the distribution of the current task.

[0105] If the task is not preempted, the scheduler waits at fixed intervals and then queries the database to check the execution status of the current task. If it is still incomplete, the instruction is resent at fixed intervals and the next round of confirmation begins. If it changes to "in execution" or "completed," the task is considered successfully distributed, the loop is exited, and the task identifier is recorded in the sent set. The loop confirmation has a total time limit; if it times out, the task is considered to have failed, the mapping table is cleaned, and the database status is updated to "failed."

[0106] After the task start instruction is successfully distributed, the scheduler waits for the estimated execution time before issuing the task end instruction and updating the database status to "completed". The end instruction is sent only once and is not resent.

[0107] Based on the above optional implementation, a dual mapping table structure (a table of devices waiting to be dispatched and a table of devices currently being dispatched, i.e., the first and second mapping tables mentioned above) maintained in the scheduler's memory, along with a comparison mechanism between the two tables, enables proactive arbitration of task execution rights at the device level. When a new task is scheduled to a device that is in the dispatch process, the scheduler does not need to wait for feedback from the device or actively release it. It can quickly detect conflicts and make a preemption decision on the scheduler side by comparing the values ​​of the two tables. Combined with a scheduling priority evaluation based on three factors: time, health, and resources, the preempted task is automatically marked as failed, and the new task is seamlessly dispatched. Compared with related technologies that rely on the device to determine priority or passively release resources due to timeout, this optional implementation can move the detection and arbitration of task conflicts from the device side to the scheduler side, resulting in a faster response speed. It does not depend on the device's cooperation capabilities, and the device side does not need to implement any preemption logic, thus possessing good versatility and compatibility.

[0108] Furthermore, a cyclical confirmation mechanism based on database status field queries ensures reliable task instruction distribution. Instead of using "successful transmission" as the completion marker after sending an instruction, the scheduler repeatedly queries the database for task status at fixed intervals, using the actual execution status written by the device as the final confirmation of successful distribution. This upgrades the distribution logic from "one-way transmission" to a closed loop of "send-confirm-retransmission." For instruction loss or execution failure caused by network interruptions, device process restarts, or other reasons, the system has automatic recovery capabilities without manual intervention. Simultaneously, the cyclical confirmation has a time window limit, preventing permanent resource occupation due to infinite waiting. Compared to related technologies where the scheduler relies solely on device-initiated callbacks or checks only a single timeout threshold, this alternative implementation achieves observability and proactive control of device execution status on the scheduling side in a lightweight manner without introducing additional infrastructure such as message queues.

[0109] Furthermore, this embodiment introduces an intelligent task recovery mechanism based on scheduling priority. After a task switch is triggered, the scheduler evaluates the update priority of the interrupted task (the second task): if it is lower than a preset threshold, it is marked as an execution failure to release resources; if it is higher than or equal to the preset threshold, it is stored in a cache queue and suspended until the first task is completed and execution resumes. This mechanism ensures emergency task response while avoiding unwarranted interruptions of high-value services, achieving a balance between overall system efficiency and business continuity.

[0110] In this optional implementation, an intelligent warehouse AGV scheduling system is used as an example for illustration.

[0111] In a large automated warehouse, there are multiple AGV devices (Automated Guided Vehicles, i.e., "device terminals" responsible for material handling) and a scheduler. The AGV devices have local computing capabilities, can receive task instructions, and maintain a simple "task queue" locally. The scheduler is responsible for issuing task instructions to the AGVs.

[0112] Task A (Low Priority): Move goods X from area A to area B. Estimated time: 10 minutes. Task B (High Priority / Urgent): Emergency replenishment; deliver goods Y directly from area C to the production line entrance. Estimated time: 5 minutes. The production line is about to run out of materials; if goods are not delivered within 5 minutes, the entire production line will stop.

[0113] The scheduler issues task A to an AGV device (i.e., the target device). The AGV device receives task A and begins execution locally. At this point, the AGV device's local task queue only contains task A. Then, the production line issues an urgent request, and the scheduler immediately generates task B. Due to network fluctuations or scheduling policies, task B is issued to the AGV device a few seconds later than task A. In related technologies, the "self-judgment" logic on the device side (AGV device) is: the AGV device has received task B. The AGV device's simple local logic is: "I am currently executing task A, and task B is new. But I don't have global information; I don't know if task B is truly more urgent than A (or it might just be treating tasks with larger IDs as higher priority, or processing them randomly)." The AGV device doesn't know that task A is already halfway through execution, nor does it know the production line downtime risk associated with task B. It can only process it according to a simple "first-come, first-served" or "task ID sorting" approach. Therefore, the AGV device decides to complete the current task A first, and then execute task B. It returns a status to the scheduler: "Busy, estimated completion time in 10 minutes." Task A then continued execution, taking 10 minutes. Task B was blocked for 10 minutes. The production line was shut down for 10 minutes while waiting for goods Y, resulting in significant economic losses.

[0114] In this example, the AGV device (device-side) makes an error by "self-judging" due to a lack of global scheduling information. The global implications of the task are particularly important: the AGV device is unaware that task B is associated with the high-cost consequence of "production line downtime." Regarding the remaining value of task A: the scheduler might know that the goods X for task A can be delivered later, or that other AGV devices can replace them, while task B cannot be delayed. However, from a global perspective, interrupting task A and immediately executing task B minimizes the total loss. But the AGV device cannot see this global view.

[0115] To address this issue, in this optional implementation, when the scheduler decides to assign a high-priority task B, it finds that the AGV device is currently executing task A (by querying the database or memory status). The scheduler directly executes the preemption logic. It updates the database, marking task A's status as "failed / interrupted" and task B's status as "assigned / high priority." It sends an instruction to the AGV device: "Immediately stop the current task A and execute the new task B." Alternatively, if seamless switching is supported, the instruction for task B is directly issued, overwriting the record for task A in the memory mapping table. The device only needs to execute: Upon receiving the instruction, the AGV device does not need to determine priority; it simply executes: "Stop the old task and execute the new task." Even if the AGV device is currently moving goods X, it must immediately stop and turn to retrieve goods Y. Therefore, task B begins execution within minutes, and the production line does not stop. Task A is marked as failed and can subsequently be rerouted by the scheduler or assigned to other idle AGV devices.

[0116] In the above "intelligent warehouse AGV" scenario (the AGV is executing a low-priority task A, and the scheduling center needs to issue a high-priority task B), the triggering preemption arbitration logic in this optional implementation is explained below.

[0117] The scheduler attempts to assign a high-priority "task B" to the AGV that is "currently executing task A".

[0118] Step 1: New task arrival and mapping table update (preparation phase).

[0119] The AGV device is currently executing task A. Two mapping tables are maintained in the scheduler's memory. The first mapping table (waiting for assignment table): {"AGV_01": "Task_A"}, records that the AGV device's latest task waiting to be executed is A; the second mapping table (assigning in progress table): {}. Because task A has already been successfully assigned and entered the execution phase, the device may be empty in the second mapping table, or if a new task arrives at some point before task A is assigned, the specific timing needs to be considered. Note: Preemption mainly occurs when "a new task arrives, and the device is in the 'assigning in progress' or 'just assigned but not yet confirmed as completed' window" or "the scheduler actively initiates preemption." Assume that although task A has started execution, the scheduler has not yet received "completed" feedback, or the scheduler believes it can be forcibly interrupted. Therefore, in this optional implementation, the triggering scenario is: when task B arrives, the scheduler finds that the AGV device already has task A in the "first mapping table".

[0120] The scheduler decides to issue task B. The scheduler updates the value of the AGV device in the first mapping table to Task_B. At this time, the first mapping table becomes: {"AGV_01": "Task_B"}.

[0121] Step 2: Enter the distribution process and loop confirmation (trigger phase).

[0122] The scheduler begins the dispatch process for Task B. The scheduler writes Task_B to the second mapping table (dispatch table in progress): {"AGV_01": "Task_B"}. The scheduler sends the instruction "Execute Task B" to the AGV device. The scheduler enters a loop confirmation process, awaiting feedback from the AGV device.

[0123] Step 3: Detect conflict (the moment arbitration is triggered).

[0124] In each round of the cyclical confirmation, the scheduler executes the following logic: Read the second mapping table: The scheduler checks the value of the AGV device in the second mapping table. Comparison logic: If the value of the device in the second mapping table is not empty (indicating that a task was previously being distributed or has just been distributed and is in the confirmation window), and it is inconsistent with the current value in the first mapping table. Assume that during the execution of task A, the second mapping table in the scheduler's memory may still contain a record of task A (if task A was recently issued and is in the "distributing / confirming" state), or the scheduler detects through some mechanism that the device is still occupied by task A. When task B is issued, the scheduler finds that the device still has a record of the old task (Task A) in the "distributing table," or finds an abnormal device status during the confirmation of Task B. Current value of the first mapping table: Task_B (because it has just been updated to a new task). Current value of the second mapping table: If Task_A is still present in the second mapping table at this time (for example, task A was just issued and has not yet fully entered the "execution" confirmation, or the system is designed to have an independent distribution window for each task), then Task_A ≠ Task_B. Therefore, preemptive arbitration was triggered.

[0125] Step 4: Execute the preemptive decision (arbitration enforcement).

[0126] The scheduler checks: "Is the current value of this device (Task_B) in the first mapping table equal to the task identifier (Task_B) dispatched in this round?" Yes, they are equal. This means that the task currently being processed is the newly arrived task B, while Task_A in the second mapping table is the old task.

[0127] The scheduler updates the device's record in the second mapping table to Task_B (overwriting the old Task A record or clearing the Task A record). The scheduler immediately terminates the Task A distribution / acknowledgment process. If Task_A is a normal transport task with a scheduling priority below the threshold, the scheduler updates the status of Task_A in the database to "failed" (or "preempted"); if Task_A is transporting the only critical spare part in the entire plant with a scheduling priority above the threshold, the scheduler stores Task_A in the buffer queue. After Task_B completes execution, the scheduler retrieves Task_A from the buffer queue and controls AGV-01 to resume execution. During this process, the scheduler continues to distribute Task_B (sending instructions and waiting for acknowledgment).

[0128] Step 5: Final Result.

[0129] The AGV device receives the instruction to execute Task_B. The scheduler queries the database during a loop of confirmation. If the AGV device executes Task_B and updates its status to "Executing," the scheduler determines that Task_B has been successfully dispatched.

[0130] Therefore, based on the above processing, a high-priority task (the newly arrived task B) can bypass or interrupt a low-priority task (the ongoing task A) without waiting for the device to make its own judgment.

[0131] In combination with the above optional embodiments, this application has the following beneficial effects:

[0132] (1) A device-level task preemption arbitration mechanism based on dual mapping table comparison is implemented. The scheduler maintains a waiting device table and a device being dispatched table in memory. Both tables use the device name as the key and the task identifier as the value. The task conflict is detected by comparing the task identifiers of the same device in the two tables in real time. If they are inconsistent, the scheduler will actively execute the preemption decision to realize centralized arbitration of the device execution right.

[0133] (2) A reliable task instruction distribution mechanism based on database status cyclic query is implemented. After sending a task instruction, the scheduler does not take successful sending as the end point, but periodically queries the status field of the task in the database. The actual status written by the device is used as the final confirmation of successful distribution, forming a closed loop of "send-confirmation-retransmission". The cyclic confirmation has a total time limit. If the timeout is exceeded, the distribution will be automatically judged as failed and the scheduler memory status will be cleaned up.

[0134] (3) A linkage processing method for preemption arbitration and reliable distribution in the task distribution process was implemented. In each round of cyclic confirmation, the scheduler embeds preemption detection into the confirmation process, so that while the task is waiting for the device feedback, it can sense in real time whether there is a new task preemption. The preempted task immediately terminates the distribution and updates the database status, realizing the atomicity of preemption response and status synchronization.

[0135] In this embodiment of the invention, a task execution device is provided. Figure 3 This is a structural block diagram of a task execution device according to an embodiment of the present invention, such as... Figure 3 As shown, the device includes: a writing module 32, a sending module 34, a reading module 36, a comparison module 38, and a control module 30. The device will be described below.

[0136] The writing module 32 is used to write a first task identifier into a first mapping table, wherein the first mapping table records task identifiers that one or more devices in the distributed system are currently waiting to be executed; the sending module 34, connected to the writing module 32, is used to send a task execution instruction to the target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier; the reading module 36, connected to the sending module 34, is used to read the second task identifier of the target device from the second mapping table, wherein the second mapping table records task identifiers that one or more devices are currently executing; the comparison module 38, connected to the reading module 36, is used to compare whether the first task identifier and the second task identifier are the same; the control module 30, connected to the comparison module 38, is used to control the target device to switch from executing the second task corresponding to the second task identifier to executing the first task if the comparison result is that the first task identifier and the second task identifier are different.

[0137] In this embodiment of the invention, another task execution device is also provided. Figure 4 This is a structural block diagram of another task execution device according to an embodiment of the present invention, such as... Figure 4 As shown, the device includes a first receiving module 42 and a second receiving module 44. The device will be described below.

[0138] The first receiving module 42 is used to receive a task execution instruction sent by the task scheduler, wherein the task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier, the first task identifier being a task identifier written in the first mapping table, the first mapping table recording the task identifiers currently waiting to be executed by one or more devices in the distributed system; the second receiving module 44 is connected to the first receiving module 42 and is used to receive a task switching instruction sent by the task scheduler, wherein the task switching instruction is used to instruct the execution of the first task instead of the second task corresponding to the second task identifier in the second mapping table, the second mapping table recording the task identifiers currently being executed by one or more devices, the first task identifier being different from the second task identifier.

[0139] In this embodiment of the invention, a computer-readable storage medium is also provided, including a stored executable program, wherein the executable program controls the device where the computer-readable storage medium is located to execute the above-described task execution method when it runs.

[0140] In another embodiment of the present invention, an electronic device is provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the task execution method described above when it runs.

[0141] In this embodiment of the invention, a computer program product is further provided, wherein when the computer program is executed by a processor, it implements the steps of any of the methods described above.

[0142] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0143] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0144] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0147] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0148] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A task execution method, characterized in that, include: Write the first task identifier into the first mapping table, wherein the first mapping table records the task identifiers of one or more devices in the distributed system that are currently waiting to be executed; Send a task execution instruction to the target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier; Read the second task identifier of the target device from the second mapping table, wherein the second mapping table records the task identifiers that the one or more devices are executing; Compare whether the first task identifier and the second task identifier are the same; If the comparison result shows that the first task identifier and the second task identifier are different, the target device is controlled to switch from executing the second task corresponding to the second task identifier to executing the first task.

2. The method according to claim 1, characterized in that, The step of writing the first task identifier into the first mapping table includes: Obtain the first priority of the first task, and the second priority of the second task corresponding to the second task identifier in the first mapping table; If the first priority is higher than the second priority, the second task identifier is updated to the first task identifier.

3. The method according to claim 2, characterized in that, The step of obtaining the first priority of the first task and the priority of the second task includes: Using the first task and / or the second task as the target task, obtain the time factor, health factor and resource factor of the target task; The priority of the target task is determined based on the time factor, the health factor, and the resource factor.

4. The method according to claim 3, characterized in that, The step of obtaining the time factor of the target task includes: Obtain the remaining waiting time of the target task and the task type of the target task, wherein the remaining waiting time is the difference between the planned start time of the task and the current time, and the task type includes urgent task or normal task; The time factor of the target task is determined based on the remaining waiting time and the task type.

5. The method according to claim 3, characterized in that, The acquisition of the health factors for the target task includes: The average response time of the target device to the scheduler over multiple responses is obtained, as well as the communication success rate between the target device and the scheduler. Based on the average response time and the communication success rate, the health factors of the target task are determined.

6. The method according to claim 3, characterized in that, The acquisition of the resource factors for the target task includes: Obtain the estimated execution time of the target task and the amount of idle resources available in the scheduler; Based on the estimated execution time and the amount of idle resources, the resource factor of the target task is determined.

7. The method according to claim 1, characterized in that, After comparing whether the first task identifier and the second task identifier are the same, the method further includes: If the comparison result shows that the first task identifier and the second task identifier are the same, query the database to check the execution status of the first task. If the execution status is "not completed", the execution time of the first task is calculated. If the execution time exceeds the predetermined time, the execution status of the first task recorded in the database will be updated to execution failure.

8. The method according to claim 1, characterized in that, After controlling the target device to switch from executing the second task corresponding to the second task identifier to executing the first task, the method further includes: Obtain the update priority of the second task; If the update priority is lower than a preset threshold, the execution status of the second task recorded in the database will be updated to execution failure. If the update priority is higher than or equal to the preset threshold, the second task is stored in the cache queue of the database, and after the first task is completed, the second task is retrieved from the cache queue, and the target device is controlled to resume the execution of the second task.

9. The method according to any one of claims 1 to 8, characterized in that, The first task and the second task are inspection tasks in which one or more devices in the distributed system inspect corresponding predetermined areas.

10. A task execution method, characterized in that, include: The system receives a task execution instruction sent by the scheduler, wherein the task execution instruction is used to instruct the execution of a first task corresponding to a first task identifier, the first task identifier being a task identifier written into a first mapping table, and the first mapping table recording task identifiers currently waiting to be executed for one or more devices in the distributed system; The system receives a task switching instruction sent by the scheduler, wherein the task switching instruction is used to indicate that the execution of the first task is switched from the second task corresponding to the second task identifier in the second mapping table. The second mapping table records the task identifiers that the one or more devices are currently executing, and the first task identifier is different from the second task identifier.

11. A task execution device, characterized in that, include: The writing module is used to write the first task identifier into the first mapping table, wherein the first mapping table records the task identifiers of one or more devices in the distributed system that are currently waiting to be executed; The sending module is used to send a task execution instruction to the target device corresponding to the first task identifier, wherein the task execution instruction is used to instruct the execution of the first task corresponding to the first task identifier; The reading module is used to read the second task identifier of the target device in the second mapping table, wherein the second mapping table records the task identifiers that the one or more devices are executing; The comparison module is used to compare whether the first task identifier and the second task identifier are the same; The control module is used to control the target device to switch from executing the second task corresponding to the second task identifier to executing the first task when the comparison result is that the first task identifier and the second task identifier are different.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the task execution method according to any one of claims 1 to 10.

13. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the task execution method according to any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 10.

Images