Experimental task scheduling method and device for intelligent laboratory

Abstract

The invention provides an experimental task scheduling method and device for an intelligent laboratory, and is applied to a server in a laboratory system of a target laboratory, and the method comprises the steps: obtaining an experimental task pool; determining a priority weight according to the task sensitivity level and the predicted time consumption of each experimental task; determining equipment execution information according to each task type; determining a task execution queue corresponding to each preset reference experimental device in the target laboratory according to the device execution information and the priority weight corresponding to the plurality of experimental tasks; and converting the task execution queue into an operation instruction sequence to control the experiment robot in the target laboratory to execute the experiment task through the reference experiment equipment. Thus, the server achieves the process from experimental task scheduling to robot driving equipment execution based on the equipment execution information and the priority weight, an end-to-end automatic process is constructed, the intellectualization of a target laboratory is improved, the equipment resource utilization rate is effectively increased, and the task execution period is shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automatic chemical experiment control systems, and in particular to an experiment task scheduling method and device for an intelligent laboratory. BACKGROUND

[0002] At present, laboratories have long relied on manual operation, and there are problems such as long experiment task completion period and many human errors. Automatic equipment is usually used to replace manual operation to complete experiment tasks, improve work efficiency, and reduce task failure probability.

[0003] However, the execution management of experiment tasks in the laboratory usually relies on manual planning for scheduling, which makes it difficult to dynamically adjust and optimize the scheduling plan, and further leads to low utilization of experimental equipment, increased risk of processing sensitive tasks, low overall experimental efficiency, poor management flexibility and safety. SUMMARY

[0004] The present application proposes an experiment task scheduling method and device for an intelligent laboratory, in order to realize the execution of the robot driving equipment from the experiment task scheduling, build an end-to-end automatic process, significantly reduce the manual intervention link, realize the full-process automatic closed loop, shorten the execution period of the experiment task, and improve the resource utilization rate of the equipment.

[0005] In a first aspect, an experiment task scheduling method for an intelligent laboratory is provided by an embodiment of the present application, which is applied to a server in a laboratory system of a target laboratory, and the method comprises:

[0006] An experiment task pool is obtained, the experiment task pool is used to store a set of to-be-executed experiment tasks and an attribute label associated with each experiment task in the set of experiment tasks, the attribute label comprises a task type, a task sensitivity level and a predicted time consumption of the corresponding experiment task, and the task sensitivity level is used to represent the sensitivity degree of the execution result of the corresponding experiment task on timeliness risk;

[0007] A priority weight is determined according to the task sensitivity level and the predicted time consumption of each experiment task;

[0008] Device execution information is determined according to each task type, the device execution information is used to indicate a multi-device cooperation sequence required for executing the corresponding experiment task, and a plurality of associated experiment devices corresponding to the multi-device cooperation sequence and a plurality of device running times, each associated experiment device corresponds to a device running time;

[0009] Based on the equipment execution information and priority weights corresponding to multiple experimental tasks, the task execution queue corresponding to each pre-set reference experimental device in the target laboratory is determined. The task execution queue is used to indicate the time for the corresponding reference experimental device to execute each experimental task. The reference experimental device includes associated experimental devices.

[0010] The task execution queue is converted into a sequence of operation instructions to control the experimental robot in the target laboratory to perform experimental tasks through the reference experimental equipment.

[0011] Secondly, embodiments of this application provide an experimental task scheduling device for intelligent laboratories, applied to a server in the laboratory system of the target laboratory, the device comprising:

[0012] The task acquisition unit is used to acquire the experimental task pool. The experimental task pool is used to store the set of experimental tasks to be executed and the attribute tags associated with each experimental task in the set. The attribute tags include the task type, task sensitivity level and estimated time of the corresponding experimental task. The task sensitivity level is used to characterize the sensitivity of the execution result of the corresponding experimental task to the timeliness risk.

[0013] The weight calculation unit is used to determine the priority weight based on the task sensitivity level and expected time of each experimental task;

[0014] The information acquisition unit is used to determine the device execution information according to each task type. The device execution information is used to indicate the multi-device collaboration sequence required to execute the corresponding experimental task, as well as the multiple associated experimental devices and the running time of the multiple devices corresponding to the multi-device collaboration sequence. Each associated experimental device corresponds to a device running time.

[0015] The task scheduling unit is used to determine the task execution queue corresponding to each pre-set reference experimental device in the target laboratory based on the equipment execution information and priority weights of multiple experimental tasks. The task execution queue is used to indicate the time for the corresponding reference experimental device to execute each experimental task.

[0016] The task execution unit is used to convert the task execution queue into a sequence of operation instructions to control the experimental robot in the target laboratory to perform experimental tasks through the reference experimental equipment.

[0017] Thirdly, embodiments of this application provide a server including a processor, a memory, and one or more programs, the one or more programs being stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps as described in the first aspect of embodiments of this application.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps in the first aspect of embodiments of this application.

[0019] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement some or all of the steps described in the first aspect of embodiments of this application.

[0020] As can be seen, in this embodiment of the application, the server constructs a complete closed-loop process for scheduling experimental tasks by sequentially executing three core links: dynamic priority evaluation of experimental tasks, multi-device collaborative scheduling, and data processing during the task execution phase. This ensures that high-efficiency experimental tasks have priority in obtaining resources, while prioritizing tasks with short execution times, thereby improving the resource utilization of the equipment, reducing the average waiting time of tasks, shortening the execution cycle of experimental tasks, and enhancing system responsiveness. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the structure of a laboratory system for a target laboratory provided in an embodiment of this application;

[0023] Figure 2 This is a flowchart illustrating an experimental task scheduling method for an intelligent laboratory provided in an embodiment of this application;

[0024] Figure 3 This is a visual schematic diagram of the login interface of a target laboratory intelligent scheduling system provided in an embodiment of this application;

[0025] Figure 4 This is a schematic diagram illustrating a scenario where a server determines device execution information, as provided in an embodiment of this application.

[0026] Figure 5 This is a schematic diagram of a scenario where a target laboratory performs an experimental task, provided in an embodiment of this application.

[0027] Figure 6 This is a functional unit block diagram of an experimental task scheduling device for an intelligent laboratory provided in an embodiment of this application;

[0028] Figure 7This is a functional unit block diagram of another experimental task scheduling device for intelligent laboratories provided in this application embodiment;

[0029] Figure 8 This is a structural block diagram of a server provided in an embodiment of this application. Detailed Implementation

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

[0031] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0032] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0033] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a laboratory system for a target laboratory provided in an embodiment of this application. For example... Figure 1As shown, the laboratory system 100 includes a server 110, reference experimental equipment 120, and experimental robots 130. The server 110 communicates with the reference experimental equipment 120 and the experimental robots 130. Researchers working in the target laboratory upload experimental tasks to the server 110. The experimental task pool stored in the server 110 is updated in real time to store a set of experimental tasks to be executed and the attribute tags associated with each experimental task in the set. Based on these attribute tags, the server 110 calculates the priority weights of the experimental tasks to be executed, and then, combined with the device execution information corresponding to the task type of each experimental task, matches the corresponding task execution queue for each reference experimental equipment 120 in the laboratory system 100 corresponding to the target laboratory. The server 110 converts the task execution queue into an operation command sequence that the experimental robots 130 can effectively recognize. The server 110 then issues the operation command sequence to control the experimental robots 130 to execute the experimental tasks in the experimental task pool through the reference experimental equipment 120. Each laboratory system 100 corresponds to one server 110, multiple reference experimental equipment 120, and multiple experimental robots 130. Each experimental task requires one or more associated experimental devices to perform collaboratively. The device type corresponding to the reference experimental device 120 includes the device type of the associated experimental devices for any experimental task. Each reference experimental device 120 is used to execute a reference execution operation in the corresponding experimental task. The experimental robot 130 assists in the collaborative control of multiple devices, specifically for transferring sample consumables between devices and carrying multimodal sensors to collect device status in real time. The reference experimental device 120 functions as a task execution terminal to realize single-process atomic operations, i.e., reference execution operations.

[0034] Based on this, this application provides a method for scheduling experimental tasks in an intelligent laboratory. The following is a detailed description of the embodiments of this application with reference to the accompanying drawings.

[0035] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for scheduling experimental tasks in an intelligent laboratory, provided in an embodiment of this application. The method is applied to server 110 in the laboratory system 100 of the target laboratory, and includes:

[0036] Step S201: Obtain the experimental task pool.

[0037] The experimental task pool stores the set of experimental tasks to be executed and the attribute tags associated with each experimental task in the set. The attribute tags include the task type, task sensitivity level, and estimated time of the corresponding experimental task. The task sensitivity level is used to characterize the sensitivity of the execution result of the corresponding experimental task to the timeliness risk.

[0038] In practical applications, the target laboratory's server can connect to the work devices of multiple researchers. Researchers can upload experimental tasks that need to be executed by the equipment through their work devices. The experimental task pool is then updated in real time to reflect newly uploaded tasks. Each experimental task is bound to an attribute tag so that the server can schedule tasks using this data, maximizing the resource utilization of the experimental equipment and ensuring the validity and timeliness of experimental results (some tasks are highly urgent and have strict time requirements; delayed execution may lead to practical issues with the experimental results).

[0039] For example, please refer to Figure 3 , Figure 3 This is a visual schematic diagram of the login interface of a target laboratory intelligent scheduling system provided in an embodiment of this application. For example... Figure 3 As shown, researchers in the target laboratory can authenticate their identity by logging into this interface to access the server's task pool and upload tasks to be performed. The login interface includes a background image with an authentication information input screen. This input screen includes the system name ("Target Laboratory Intelligent Scheduling System") and two input boxes: a user input box ("Please enter username") and a password input box ("Please enter password"). The user input box guides researchers to enter their registered username, and the password input box guides researchers to enter their registered password, which is stored in the server's authentication information database. The input boxes also include a verification code input box. Researchers enter the corresponding letters or numbers in the verification code displayed on the right for human verification. After entering the username, password, and verification code, researchers can authenticate their identity by selecting the login control below. The server verifies the information entered by the researcher using the authentication information database. If the verification is successful, the user is redirected to the next screen to upload the tasks to be performed by the required equipment.

[0040] The task sensitivity level essentially quantifies the risk tolerance of an experimental task to timeliness, indicating how quickly the value of experimental results decays over time. For example, based on task sensitivity level, experimental tasks can be categorized into high-sensitivity and low-sensitivity tasks. High-sensitivity tasks are those where execution delays would lead to result invalidation or significant loss (e.g., emergency testing, cell viability testing). Low-sensitivity tasks are those whose results are not time-sensitive (e.g., long-term stability monitoring, teaching demonstration experiments). The server schedules experimental tasks by obtaining their task sensitivity level and estimated execution time, specifically through priority weight calculations. Its practical significance lies in ensuring the timeliness of high-sensitivity tasks, thereby preventing medical accidents and improving the utilization rate of experimental equipment.

[0041] Step S202: Determine the priority weight based on the task sensitivity level and estimated time of each experimental task.

[0042] In one possible embodiment, priority weights are determined based on the task sensitivity level and estimated time consumption of each experimental task, including: converting the task sensitivity level corresponding to the currently processed experimental task into a target sensitivity coefficient according to a preset sensitivity level mapping rule; determining the average time consumption of tasks corresponding to the experimental task pool; determining the corresponding target time consumption coefficient based on the deviation direction between the estimated time consumption of the currently processed experimental task and the average time consumption; and determining the priority weights corresponding to the currently processed experimental task based on the weighted product formula of the target laboratory, the target time consumption coefficient, and the target sensitivity coefficient.

[0043] The average task time is determined by the total estimated time and total number of all experimental tasks. The deviation direction is used to characterize the relative level of the estimated time with respect to the average task time. The weighted product formula is used to indicate the weight of the time coefficient corresponding to the target time coefficient and the weight of the sensitivity coefficient corresponding to the target sensitivity coefficient. The weight of the time coefficient and the weight of the sensitivity coefficient are related to the equipment load status of the target laboratory under the current system time and the experimental scenario corresponding to the target laboratory. The priority weight is positively correlated with the task sensitivity level and negatively correlated with the estimated time.

[0044] The data processing mechanism in this embodiment includes sensitivity coefficient conversion and dynamic time-consuming adjustment, as well as calculating the priority weight of the experimental task based on the priority weight formula. Sensitivity coefficient conversion refers to quantifying the task sensitivity level into a target sensitivity coefficient using a preset sensitivity level mapping rule (e.g., high sensitivity = coefficient 1.0, medium sensitivity = 0.7, low sensitivity = 0.3), ensuring that highly sensitive tasks receive higher weights. Dynamic time-consuming adjustment refers to dynamically allocating target time-consuming coefficients by calculating the average time of the experimental task pool and comparing the deviation direction (higher / lower) between the current task's estimated time and the average (shorter time-consuming tasks have higher coefficients, longer time-consuming tasks have lower coefficients). The priority weight formula refers to dynamically adjusting the weight ratio between the time-consuming coefficient and the sensitivity coefficient based on the laboratory's real-time load status (high / low load) and the experimental scenario (formula example: priority weight = sensitivity coefficient * α (sensitivity coefficient weight) × time-consuming coefficient * β (time-consuming coefficient weight), where α and β are dynamically determined by the system load), making the weight allocation more aligned with actual needs.

[0045] For example, the server incorporates device load status as an adjustment factor to ensure that short-duration tasks are prioritized to improve efficiency when resources are scarce, and highly sensitive tasks are prioritized to reduce the risk of experimental results failure when resources are abundant. Application scenarios can include high-load laboratory scenarios and time-sensitive laboratory scenarios. In high-load laboratory scenarios, the server can increase the weight of the time consumption coefficient (increase the β value) to prioritize scheduling short tasks and improve device turnover. In time-sensitive laboratory scenarios, the server can increase the weight of the sensitivity coefficient (increase the α value) to ensure that highly sensitive tasks are executed first. Furthermore, medical laboratories require higher sensitivity weights, and industrial laboratories require higher time consumption weights. The specific data processing procedure can be: the server obtains the device load status of the target laboratory at the current system time; determines the device utilization rate and device idle rate of the target laboratory based on the real-time device load status, and then adjusts α and β based on the device utilization rate and device idle rate. (For example, when the device utilization rate is greater than or equal to a first preset value, β is increased and α is decreased; when the device idle rate is greater than a second preset value, α is increased and β is decreased).

[0046] As can be seen in this example, the server balances timeliness and efficiency by using the negative correlation between sensitivity coefficient and time consumption coefficient (highly sensitive short tasks have the highest weight), reduces the risk of experimental delays, and avoids long tasks from blocking the queue when the target laboratory is busy during system operation by adjusting the priority weights based on load adaptation.

[0047] In one possible embodiment, the task sensitivity level includes high sensitivity level, medium sensitivity level, and low sensitivity level; according to a preset sensitivity level mapping rule, the task sensitivity level corresponding to the currently processed experimental task is converted into a target sensitivity coefficient, including: if the task sensitivity level corresponding to the currently processed experimental task is high sensitivity level, then a preset first sensitivity coefficient is determined as the target sensitivity coefficient; if the task sensitivity level corresponding to the currently processed experimental task is medium sensitivity level or low sensitivity level, then the target project type and target department of the currently processed experimental task are obtained; according to a preset project-department weight mapping table, the target sensitivity factor corresponding to the currently processed experimental task is determined; the product of the basic sensitivity coefficient corresponding to the currently processed experimental task and the target sensitivity factor is determined as the target sensitivity coefficient.

[0048] The project-department weight mapping table indicates the first reference weight for each reference project type and the second reference weight for each reference department. The target sensitivity factor is the product of the first reference weight for the target project type and the second reference weight for the target department. The basic sensitivity coefficient corresponding to the medium sensitivity level is the second sensitivity coefficient, and the basic sensitivity coefficient corresponding to the low sensitivity level is the third sensitivity coefficient. The first sensitivity coefficient is greater than the second sensitivity coefficient, and the third sensitivity coefficient is greater than the second sensitivity coefficient.

[0049] The implementation principle of this embodiment lies in directly assigning high coefficients to highly sensitive tasks, ensuring that time-critical tasks (such as testing critically ill patients) are unconditionally prioritized, meeting the emergency response needs of medical scenarios. For medium / low-sensitivity tasks, a secondary weighting factor is introduced through a project-department weighting mapping table. This secondary dual factor includes project type weight (e.g., clinical diagnostic projects have a higher weight than research projects), department type weight (e.g., emergency department has a higher weight than general laboratory department), and a target sensitivity factor (multiplied by the basic sensitivity coefficient to obtain the target sensitivity coefficient).

[0050] Specifically, regarding weight allocation, the server can be configured according to the following rules to meet the needs of actual scenarios: clinical diagnostic projects have a higher weight than research projects; emergency / ICU-related tasks have a higher weight than general department tasks. The principle is that clinical diagnostic tasks (such as infectious disease screening) are assigned higher weights because they are directly related to patient treatment decisions, thus the weight allocated to research tasks is relatively lower. Furthermore, by automatically increasing the weights for tasks in departments such as the emergency department and ICU, experimental equipment can effectively respond to the time-sensitive pressures of clinical departments. In specific application scenarios, the above solution can enable cross-departmental collaborative experiments, assigning different sensitivity coefficients to the same low-to-medium sensitivity tasks in different departments to achieve task scheduling based on actual needs, meeting the time-sensitive requirements of different departments.

[0051] As can be seen in this example, the server establishes a two-layer mapping mechanism that combines a fixed coefficient for high sensitivity levels with dynamic adjustments for medium and low sensitivity levels. By using the product factor of project type and department weight, it achieves refined coefficient calibration for non-highly sensitive tasks, breaking through the rigid mapping limitation of traditional single sensitivity coefficients, improving the accuracy of determining target sensitivity coefficients, meeting the differentiated needs of tasks of the same level, enhancing the rationality of resource allocation, and conforming to actual management priorities.

[0052] In one possible embodiment, determining the corresponding target time consumption coefficient based on the deviation direction between the estimated time consumption of the currently processed experimental task and the average time consumption includes: obtaining a preset basic upper limit threshold corresponding to a short time consumption interval and a basic lower limit threshold corresponding to a long time consumption interval; if the deviation direction indicates that the estimated time consumption is higher than the average time consumption, then based on a preset threshold adjustment value, increasing the basic upper limit threshold and decreasing the basic lower limit threshold; if the deviation direction indicates that the estimated time consumption is lower than the average time consumption, then based on the threshold adjustment value, decreasing the basic upper limit threshold and increasing the basic lower limit threshold; based on the adjusted basic upper limit threshold and basic lower limit threshold, determining the target interval category to which the estimated time consumption of the currently processed experimental task belongs; and determining the reference time consumption coefficient corresponding to the target interval category as the target time consumption coefficient.

[0053] Among them, the lower threshold is greater than the upper threshold. The threshold adjustment value is determined by the equipment load status of the target laboratory. The target interval categories include short time interval, medium time interval and long time interval. The reference time coefficient corresponding to the long time interval is less than the reference time coefficient corresponding to the medium time interval, and the reference time coefficient corresponding to the medium time interval is less than the reference time coefficient corresponding to the short time interval.

[0054] The data processing in this embodiment includes dynamic interval adjustment and time consumption coefficient allocation. Dynamic interval adjustment involves widening the short-time interval (increasing the basic upper limit threshold) when the estimated time of the currently processed experimental task is higher than the average task time, thus forcing high-time tasks to fall into the long interval. When the estimated time of the currently processed experimental task is lower than the average task time, the long-time interval is widened (lowering the basic lower limit threshold) to prevent short tasks from being misjudged as long-time tasks, strictly defining tasks with short estimated times as short-time tasks. The logic of time consumption coefficient allocation is that the coefficient for the short-time interval is the highest (e.g., 1.2), the coefficient for the long-time interval is the lowest (e.g., 0.8), and the coefficient for the medium-time interval is in the middle (1.0), guiding the system to prioritize the processing of short tasks.

[0055] As can be seen in this example, the server applies a deviation-direction driven dynamic threshold reverse collaborative adjustment mechanism during data processing, and achieves accurate mapping of time consumption coefficients by reverse scaling of the boundary between high and low time consumption intervals.

[0056] In one possible embodiment, if the equipment utilization rate is greater than or equal to a preset utilization rate, the current load mode of the target laboratory is determined to be a high load mode; if the equipment utilization rate is less than the preset utilization rate, the current load mode is determined to be a low load mode.

[0057] The equipment utilization rate is determined by the equipment load status of the target laboratory, where the threshold adjustment value corresponding to the high load mode is greater than the threshold adjustment value corresponding to the low load mode.

[0058] The load mode determination refers to classifying tasks into high / low load modes based on whether the real-time utilization of the equipment (such as CPU utilization and robotic arm utilization) exceeds a preset threshold (e.g., 70%). Differentiated threshold adjustment means using larger adjustment values ​​(e.g., upper limit +20%, lower limit -20%) during high loads to significantly expand the range of short-duration tasks, and using smaller adjustment values ​​(e.g., upper limit -10%, lower limit +10%) during low loads to slightly relax the restrictions on long-duration tasks. The principle is that by linking load modes with adjustment ranges, aggressive optimization under resource constraints and conservative scheduling under resource constraints can be achieved. Increasing the range for determining short and long-duration tasks under high loads allows for higher priority of short-duration experimental tasks, thus fulfilling their execution requirements earlier and releasing equipment resource load.

[0059] As can be seen in this example, the server achieves dynamic scaling and adjustment of intensity based on device load status by applying a load-adaptive bidirectional dynamic threshold collaborative control mechanism. It also achieves accurate classification of time-consuming tasks and accurate resource adaptation by using short / long time interval thresholds driven by deviation direction to scale in the opposite direction.

[0060] Step S203: Determine device execution information based on each task type.

[0061] Among them, the device execution information is used to indicate the multi-device collaboration sequence required to execute the corresponding experimental task, as well as the multiple associated experimental devices and the running time of the multiple devices corresponding to the multi-device collaboration sequence. Each associated experimental device corresponds to a device running time.

[0062] For example, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario where a server determines device execution information, as provided in an embodiment of this application. Figure 4As shown, server 110 retrieves the attribute tags corresponding to the currently processed experimental tasks stored in the experimental task pool to obtain the corresponding task type. Server 110 then determines the device execution information corresponding to the currently processed experimental task based on the task type. The device execution information corresponding to different task types can be pre-recorded and stored by the experimenters in the server's preset task information database. The device execution information recorded in the task information database is used to indicate the execution order and running time of associated experimental devices 1 and 2 associated with the currently processed experimental task. For example, the currently processed experimental task requires associated experimental device 2 to first execute the corresponding reference execution operation (the corresponding device running time is estimated to be 30 minutes), and then associated experimental device 1 to execute the corresponding reference execution operation (the corresponding device running time is estimated to be 20 minutes). Different associated experimental devices have different device types, and the reference execution operations they execute are also different.

[0063] Step S204: Based on the equipment execution information and priority weights corresponding to multiple experimental tasks, determine the task execution queue corresponding to each pre-set reference experimental device in the target laboratory.

[0064] The task execution queue is used to indicate the time for the corresponding reference experimental equipment to execute each experimental task. The reference experimental equipment includes associated experimental equipment.

[0065] In one possible embodiment, before determining the task execution queue corresponding to each pre-set reference experimental device in the target laboratory based on the device execution information and priority weights corresponding to multiple experimental tasks, the method further includes: if a long-running task is detected in the experimental task set, determining whether the long-running task belongs to a decomposable task type based on the task type corresponding to the long-running task; performing a decomposition identification operation to determine a safe decomposition point for the multi-device collaboration order, associated experimental devices, and device running time corresponding to the long-running task that belongs to the decomposable task type; and decomposing the corresponding long-running task into multiple sub-tasks based on the identified safe decomposition point to update the experimental task set.

[0066] Among them, long-duration tasks are experimental tasks whose estimated duration exceeds the preset duration. The safe decomposition point meets any of the following conditions: the long-duration task is in thermodynamic equilibrium during the equipment operation time of the corresponding associated experimental equipment; the long-duration task is in the inactive substance settling period during the equipment operation time of the corresponding associated experimental equipment; the long-duration task is in the chemical quenching completed state during the equipment operation time of the corresponding associated experimental equipment. The priority weight of the subtask is associated with the corresponding long-duration task.

[0067] In this embodiment, the data processing performed by the server includes long task identification, decomposability assessment, and safe decomposition point detection. Long task identification marks tasks with an estimated duration exceeding a preset threshold (e.g., 2 hours) as long-duration tasks. Decomposability assessment determines whether decomposition is permissible based on task type (e.g., crystallization reaction, cell culture), allowing only tasks with low chemical / biological stability requirements to be split. Safe decomposition point detection involves splitting a task when any of the following conditions are met: thermodynamic equilibrium point (e.g., isothermal stage); inactive substance settling period (e.g., settling after centrifugation); completion of chemical quenching (e.g., after reaction termination). Decomposing long tasks effectively releases equipment downtime, preventing a single long-duration task from occupying a single experimental device for too long and affecting the normal execution of other experimental tasks. It supports the preemption of high-value tasks, immediate response to sudden high-priority tasks, reduces the impact of single long-duration task failures, improves task scheduling flexibility, and enhances equipment utilization. Furthermore, splitting long-duration tasks based on safe points ensures the integrity of experimental results, avoids interference from intermediate states, and guarantees the validity of experimental results.

[0068] For example, when the experimental task is an overnight culture experiment, it can be decomposed into two sub-tasks during the cell division interval: "daytime pretreatment" and "nighttime culture". Furthermore, when the experimental task involves multi-step synthetic reactions, the corresponding experimental task can be broken down into independent reaction units during the quenching phase.

[0069] As can be seen in this example, before allocating a corresponding task execution queue for each reference experimental task, the server performs a task decomposition operation on long-running experimental tasks. This can solve the problem of resource waste caused by exclusive use of equipment, support the preemption of high-value tasks, provide immediate response to sudden high-priority tasks, reduce the impact of failures of single long-running tasks, and improve the flexibility of the target laboratory in executing experimental tasks.

[0070] Step S205: Convert the task execution queue into an operation instruction sequence to control the experimental robot in the target laboratory to perform experimental tasks through the reference experimental equipment.

[0071] For example, please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating a scenario where a target laboratory performs an experimental task, as provided in an embodiment of this application. Figure 5As shown, the laboratory system 100 in the target laboratory can include multiple reference experimental devices and multiple experimental robots. Assume the experimental robots include experimental robot 1 and experimental robot 2. The reference experimental devices include reference experimental device 1, reference experimental device 2, and reference experimental device 3. Server 110 converts the task execution queue into an operation instruction sequence and issues it to the multiple experimental robots (i.e., experimental robot 1 and experimental robot 2) in the target laboratory. Laboratory robot 1 and laboratory robot 2 execute the corresponding received operation instruction sequence. The operation instruction sequence received by experimental robot 1 is "9:20 Deliver XXX to reference experimental device 1" and "9:50 Deliver XXX to reference experimental device 2", while the operation instruction sequence received by experimental robot 2 is "9:25 Deliver XXX to reference experimental device 3". Experimental robot 1 and experimental robot 2 will plan the necessary operation and movement trajectory according to the corresponding received operation instruction sequence, and share these to avoid collisions and duplicate execution of experimental tasks. Reference experimental device 1 will execute reference operation 1 during the period from 9:25 to 9:45 after experimental robot 1 completes the first operation instruction sequence. Reference experimental device 2 will execute reference operation 2 during the period from 9:55 to 10:20 after experimental robot 2 completes the second operation instruction sequence. Reference experimental device 3 will execute reference operation 3 during the period from 9:30 to 9:55 after experimental robot 2 completes the first operation instruction sequence.

[0072] In one possible embodiment, the task execution queue contains at least one reference execution operation to be performed by the corresponding reference experimental device. After converting the task execution queue into an operation instruction sequence to control the experimental robot in the target laboratory to perform experimental tasks through the reference experimental device, the method further includes: real-time monitoring and obtaining the task execution results and working status of each reference experimental device when performing the corresponding reference execution operation; when any task execution result is detected to be abnormal, determining the corresponding reference experimental device as the device to be adjusted, and judging whether the target execution operation corresponding to the task execution result is a recoverable operation: if the target execution operation is a recoverable operation, triggering a device self-healing operation, which is used to control the device to be adjusted to re-execute the target execution operation to obtain the task execution result when the working status of the device to be adjusted is normal; if the target execution operation is not a recoverable operation, triggering a task rollback operation, which includes determining that the task execution result corresponding to the target experimental task associated with the target execution operation is invalid, resubmitting the target experimental task to the experimental task pool, and terminating the execution of the reference execution operation corresponding to the target experimental task.

[0073] In practical applications, the monitoring equipment in the target laboratory can be sensors built into the corresponding reference experimental equipment (such as pressure / temperature / vision sensors) or sensors carried by the experimental robot to monitor equipment status and collect results. The server acquires the data collected by the monitoring equipment to collect task execution results and working status in real time. The rules for judging abnormal task execution results include: result abnormality and status abnormality. Result abnormality means that the actual output of the reference execution operation corresponding to the experimental task indicated by the task execution result is different from the reference output range, and status abnormality means that the working status indicates that the reference experimental equipment has malfunctioned.

[0074] Recoverable operations specifically refer to operations that support retrying without affecting the reliability of the experimental task's results. Specifically, this requires simultaneously satisfying the reversibility of the corresponding reference execution operation and the absence of state residue on the device (e.g., the device returning to its original position after obstacle avoidance reset). In the implementation process, the server can determine whether the corresponding reference execution operation is a recoverable operation using a pre-defined retryable operation table. The triggering operation corresponding to a recoverable operation is a device self-healing operation. Device self-healing operations are divided into device-level self-healing operations and system-level self-healing operations based on the strength of their self-healing capabilities. Device-level self-healing operations refer to the retry mechanism of the corresponding reference experimental device to re-execute the corresponding reference execution operation. System-level self-healing operations refer to the server controlling the experimental robot to activate a backup machine for switching to ensure high availability.

[0075] Furthermore, the determination of irreversible operations can be based on a preset database of irreversible points in the process. This database includes at least one of the following scenarios: plate contamination (e.g., sample cross-contamination), reagent denaturation (e.g., enzyme inactivation due to high temperature), and equipment deadlock (e.g., robotic arm jamming and unable to reset). Each of these irreversible operations corresponds to a different rollback operation. Specifically, the rollback operation for plate contamination could be to discard the current plate and activate a new one; the rollback operation for reagent denaturation could be to discard the reagent and replenish it with new reagent; and the rollback operation for equipment deadlock could be to transfer the sample to a backup device via a laboratory robot to execute the corresponding reference execution operation.

[0076] Specifically, task rollback operations can include the following types of operations: 1. Result invalidation, deleting some of the generated data; 2. Task reset, resubmitting the associated target experimental task to the experimental task pool; 3. Environmental cleanup, automatically starting the cleaning program (such as UV sterilization / rinsing the flow path).

[0077] Furthermore, the device self-healing operation triggered by recoverable operations can minimize interruptions (partial retries only) to resolve corresponding operation execution issues. The task rollback operation triggered by unrecoverable operations can prevent resource waste caused by executing experimental tasks with invalid results. Additionally, the task rollback operation uses environmental cleaning to eliminate residual contamination, ensuring the data validity of the rolled-back task, and a result invalidation mechanism prevents erroneous data from flowing into downstream analysis.

[0078] As can be seen in this example, the server determines in real time whether recoverable operations trigger device-level self-healing (retry) or unrecoverable operations trigger task-level rollback (result invalidation / task reset), thus constructing an anomaly handling closed loop and improving the intelligence of the target laboratory and the flexibility of data processing in the event of partial failures.

[0079] As can be seen, in this embodiment, the server dynamically generates priority weights based on the obtained task sensitivity level and estimated execution time, and achieves intelligent scheduling by combining the multi-device collaboration order. Furthermore, it improves equipment utilization through a safe decomposition mechanism for long-duration tasks; and employs a two-layer fault-tolerance system of device-level self-healing (obstacle avoidance and retry) and task-level rollback (contamination cleaning + task reset) to effectively handle operational anomalies. In addition, the load adaptive strategy executed by the server dynamically adjusts the scheduling logic according to the real-time device status, ensuring that highly sensitive tasks are executed first, significantly improving the reliability of the experimental process, the flexibility of resource utilization, and the system's anti-interference capability.

[0080] The following are embodiments of the apparatus of this application. These embodiments of the apparatus and the embodiments of the method of this application belong to the same concept and are used to execute the methods described in the embodiments of this application. For ease of explanation, only the parts related to the apparatus embodiments of this application are shown in the embodiments of this application. For specific technical details not disclosed, please refer to the description of the embodiments of the method of this application, which will not be repeated here.

[0081] This application provides an experimental task scheduling device for intelligent laboratories, applied to server 110 in the laboratory system 100 of the target laboratory. Specifically, the experimental task scheduling device for intelligent laboratories is used to execute the steps performed by server 110 in the above-described experimental task scheduling method for intelligent laboratories. The experimental task scheduling device for intelligent laboratories provided in this application may include modules corresponding to the respective steps.

[0082] This application embodiment can divide the experimental task scheduling device for intelligent laboratories into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. The module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0083] When dividing each function into modules according to its corresponding function. Figure 6 This is a functional unit block diagram of an experimental task scheduling device for an intelligent laboratory provided in an embodiment of this application; the experimental task scheduling device for an intelligent laboratory is applied to... Figure 1 The target laboratory is shown with a server 110 in the laboratory system 100. The experimental task scheduling device 60 for the intelligent laboratory includes: a task acquisition unit 601, used to acquire an experimental task pool, which stores a set of experimental tasks to be executed and attribute tags associated with each experimental task in the set. The attribute tags include the corresponding experimental task's task type, task sensitivity level, and estimated time consumption. The task sensitivity level characterizes the sensitivity of the execution result of the corresponding experimental task to timeliness risks; a weight calculation unit 602, used to determine the priority weight based on the task sensitivity level and estimated time consumption of each experimental task; and an information acquisition unit 603, used to determine equipment execution information based on each task type. The equipment execution information is used for… The system includes a multi-device collaboration sequence required to execute the corresponding experimental task, as well as multiple associated experimental devices and their running times corresponding to the multi-device collaboration sequence, with each associated experimental device corresponding to a device running time; a task scheduling unit 604 is used to determine the task execution queue corresponding to each reference experimental device in the target laboratory based on the device execution information and priority weights corresponding to multiple experimental tasks, and the task execution queue is used to indicate the time for the corresponding reference experimental device to execute each experimental task; a task execution unit 605 is used to convert the task execution queue into an operation instruction sequence to control the experimental robot in the target laboratory to execute experimental tasks through the reference experimental devices.

[0084] In one possible embodiment, in determining the priority weight based on the task sensitivity level and estimated time consumption of each experimental task, the weight calculation unit 602 is specifically used to: convert the task sensitivity level corresponding to the currently processed experimental task into a target sensitivity coefficient according to a preset sensitivity level mapping rule; determine the average task consumption time corresponding to the experimental task pool, the average task consumption time being determined by the total estimated time consumption and total number of all experimental tasks; determine the corresponding target consumption time coefficient based on the deviation direction between the estimated time consumption time of the currently processed experimental task and the average task consumption time, the deviation direction being used to characterize the relative high or low of the estimated time consumption time relative to the average task consumption time; and determine the priority weight corresponding to the currently processed experimental task based on the weighted product formula of the target laboratory, the target consumption time coefficient, and the target sensitivity coefficient, wherein the weighted product formula is used to indicate the consumption time coefficient weight corresponding to the target consumption time coefficient and the sensitivity coefficient weight corresponding to the target sensitivity coefficient, the consumption time coefficient weight and the sensitivity coefficient weight being associated with the equipment load status of the target laboratory under the current system time and the experimental scenario corresponding to the target laboratory, the priority weight being positively correlated with the task sensitivity level and negatively correlated with the estimated time consumption.

[0085] In one possible embodiment, the task sensitivity level includes high sensitivity level, medium sensitivity level, and low sensitivity level. Regarding converting the task sensitivity level corresponding to the currently processed experimental task into a target sensitivity coefficient according to a preset sensitivity level mapping rule, the weight calculation unit 602 is specifically used for: if the task sensitivity level corresponding to the currently processed experimental task is high sensitivity level, then determining a preset first sensitivity coefficient as the target sensitivity coefficient; if the task sensitivity level corresponding to the currently processed experimental task is medium sensitivity level or low sensitivity level, then obtaining the target project type and target department of the currently processed experimental task; determining the target sensitivity factor corresponding to the currently processed experimental task according to a preset project-department weight mapping table, wherein the project-department weight mapping table is used to indicate the first reference weight corresponding to each reference project type and the second reference weight corresponding to each reference department, and the target sensitivity factor is the product of the first reference weight corresponding to the target project type and the second reference weight corresponding to the target department; determining the product of the basic sensitivity coefficient corresponding to the currently processed experimental task and the target sensitivity factor as the target sensitivity coefficient, wherein the basic sensitivity coefficient corresponding to the medium sensitivity level is the second sensitivity coefficient, the basic sensitivity coefficient corresponding to the low sensitivity level is the third sensitivity coefficient, the first sensitivity coefficient is greater than the second sensitivity coefficient, and the third sensitivity coefficient is greater than the second sensitivity coefficient.

[0086] In one possible embodiment, regarding determining the corresponding target time consumption coefficient based on the deviation direction between the estimated time consumption of the currently processed experimental task and the average time consumption, the weight calculation unit 602 is specifically used to: obtain a preset basic upper limit threshold corresponding to a short time consumption interval and a basic lower limit threshold corresponding to a long time consumption interval, wherein the basic lower limit threshold is greater than the basic upper limit threshold; if the deviation direction indicates that the estimated time consumption is higher than the average time consumption of the task, then based on a preset threshold adjustment value, the basic upper limit threshold is increased and the basic lower limit threshold is decreased, wherein the threshold adjustment value is determined by the equipment load status of the target laboratory; if the deviation direction indicates that the estimated time consumption is lower than the average time consumption of the task, then based on the threshold adjustment value, the basic upper limit threshold is decreased and the basic lower limit threshold is increased; based on the adjusted basic upper limit threshold and basic lower limit threshold, determine the target interval category to which the estimated time consumption of the currently processed experimental task belongs, wherein the target interval category includes a short time consumption interval, a medium time consumption interval, and a long time consumption interval; determine the reference time consumption coefficient corresponding to the target interval category as the target time consumption coefficient, wherein the reference time consumption coefficient corresponding to the long time consumption interval is less than the reference time consumption coefficient corresponding to the medium time consumption interval, and the reference time consumption coefficient corresponding to the medium time consumption interval is less than the reference time consumption coefficient corresponding to the short time consumption interval.

[0087] In one possible embodiment, if the equipment utilization rate is greater than or equal to the preset utilization rate, it is determined that the current load mode of the target laboratory is in a high load mode, and the equipment utilization rate is determined by the equipment load status of the target laboratory; if the equipment utilization rate is less than the preset utilization rate, it is determined that the current load mode is in a low load mode, wherein the threshold adjustment value corresponding to the high load mode is greater than the threshold adjustment value corresponding to the low load mode.

[0088] In one possible embodiment, before determining the task execution queue corresponding to each pre-set reference experimental device in the target laboratory based on the device execution information and priority weights corresponding to multiple experimental tasks, the task scheduling unit 604 is further configured to: if a long-running task is detected in the experimental task set, determine whether the long-running task belongs to the decomposable task type according to the task type corresponding to the long-running task, where the long-running task is an experimental task whose estimated duration exceeds a preset duration; for the multi-device collaboration sequence, associated experimental devices, and device running time corresponding to the long-running task that belongs to the decomposable task type, perform a decomposition identification operation to determine a safe decomposition point, where the safe decomposition point satisfies any of the following conditions: the long-running task is in a thermodynamic equilibrium state during the device running time of the corresponding associated experimental device, the long-running task is in a static period of inactive substances during the device running time of the corresponding associated experimental device, or the long-running task is in a state of chemical quenching completion during the device running time of the corresponding associated experimental device; decompose the corresponding long-running task into multiple sub-tasks according to the identified safe decomposition point to update the experimental task set, where the sub-tasks are associated with the priority weights of the corresponding long-running tasks.

[0089] In one possible embodiment, the task execution queue contains at least one reference execution operation to be performed by the corresponding reference experimental device. After converting the task execution queue into an operation instruction sequence to control the experimental robot in the target laboratory to perform experimental tasks through the reference experimental device, the task execution unit 605 is further configured to: monitor and obtain the task execution results and working status of each reference experimental device when performing the corresponding reference execution operation in real time; when any task execution result is detected to be abnormal, determine the corresponding reference experimental device as the device to be adjusted, and determine whether the target execution operation corresponding to the task execution result is a recoverable operation: if the target execution operation is a recoverable operation, trigger the device self-healing operation, which is used to control the device to be adjusted to re-execute the target execution operation to obtain the task execution result when the working status of the device to be adjusted is normal; if the target execution operation is not a recoverable operation, trigger the task rollback operation, which includes determining that the task execution result corresponding to the target experimental task associated with the target execution operation is invalid, and resubmitting the target experimental task to the experimental task pool and terminating the execution of the reference execution operation corresponding to the target experimental task.

[0090] When using integrated units, such as Figure 7 As shown, Figure 7 This is a functional unit block diagram of another experimental task scheduling device for intelligent laboratories provided in this application embodiment. Figure 7 The experimental task scheduling device 60 for intelligent laboratories includes a processing module 702 and a communication module 701. The processing module 702 controls and manages the actions of the experimental task scheduling device 60, such as the steps of the task acquisition unit 601, weight calculation unit 602, information acquisition unit 603, task scheduling unit 604, and task execution unit 605, and / or other processes for executing the techniques described herein. The communication module 701 supports interaction between the experimental task scheduling device for intelligent laboratories and other devices. Figure 7 As shown, the experimental task scheduling device for intelligent laboratories may include a storage module 703, which is used to store the program code and data of the experimental task scheduling device for intelligent laboratories.

[0091] The processing module 702 can be a processor or server, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication module 701 can be a transceiver, RF circuitry, or a communication interface, etc. The storage module 703 can be a memory.

[0092] All relevant content in each scenario involved in the above method embodiments can be referenced from the functional descriptions of the corresponding functional modules, and will not be repeated here. The above-mentioned experimental task scheduling device 60 for intelligent laboratories can all perform the above-mentioned tasks. Figure 2 The method for scheduling experimental tasks in an intelligent laboratory is shown.

[0093] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions according to the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0094] Figure 8 This is a structural block diagram of a server provided in an embodiment of this application. For example... Figure 8As shown, server 110 may include one or more of the following components: processor 801, memory 802 coupled to processor 801, wherein memory 802 may store one or more computer programs 803, the one or more computer programs 803 being configured to implement the methods described in the above embodiments when executed by one or more processors 801.

[0095] Processor 801 may include one or more processing cores. Processor 801 connects to various parts of server 110 using various interfaces and lines, and performs various functions and processes data of server 110 by running or executing instructions, programs, code sets, or instruction sets stored in memory 802, and by calling data stored in memory 802. Optionally, processor 801 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). Processor 801 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 801 and may be implemented separately using a communication chip.

[0096] The memory 802 may include random access memory (RAM) or read-only memory (ROM). The memory 802 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 802 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may also store data created by the server 110 during use.

[0097] It is understood that server 110 may include more or fewer structural elements than those shown in the above block diagram, and this is not limited thereto.

[0098] This application also provides a computer storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements some or all of the steps of any of the methods described in the above method embodiments.

[0099] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments.

[0100] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

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

[0102] 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 network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can be physically comprised separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware or in the form of hardware plus software functional units.

[0104] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute partial steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes: a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, volatile memory, or non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM), etc., which are various media capable of storing program code.

[0105] While the present invention has been disclosed above, it is not limited thereto. Any person skilled in the art can easily conceive of variations or substitutions without departing from the spirit and scope of the present invention, and various modifications and alterations can be made, including combinations of the different functions and implementation steps described above, as well as software and hardware implementation methods, all of which are within the protection scope of the present invention.

Claims

1. A method for scheduling experimental tasks in an intelligent laboratory, characterized in that, A server applied in a laboratory system for a target laboratory, the method comprising: Obtain an experimental task pool, which stores a set of experimental tasks to be executed and attribute tags associated with each experimental task in the set. The attribute tags include the task type, task sensitivity level, and estimated time consumption of the corresponding experimental task. The task sensitivity level is used to characterize the sensitivity of the execution result of the corresponding experimental task to timeliness risk. Priority weights are determined based on the task sensitivity level and estimated time consumption of each experimental task. Device execution information is determined according to each task type. The device execution information is used to indicate the multi-device collaboration sequence required to execute the corresponding experimental task, as well as the multiple associated experimental devices and multiple device running times corresponding to the multi-device collaboration sequence. Each associated experimental device corresponds to one device running time. Based on the device execution information and priority weights corresponding to multiple experimental tasks, a task execution queue corresponding to each pre-set reference experimental device in the target laboratory is determined. The task execution queue is used to indicate the time for the corresponding reference experimental device to execute each experimental task. The reference experimental device includes the associated experimental device. The task execution queue is converted into an operation instruction sequence to control the experimental robot in the target laboratory to execute the experimental task through the reference experimental equipment.

2. The method according to claim 1, characterized in that, The process of determining priority weights based on the task sensitivity level and estimated time consumption of each experimental task includes: According to the preset sensitivity level mapping rules, the task sensitivity level corresponding to the experimental task being processed is converted into the target sensitivity coefficient; Determine the average task time corresponding to the experimental task pool. The average task time is determined by the total estimated time and total number of all experimental tasks. Based on the deviation direction between the estimated time of the current experimental task and the average time of the task, a corresponding target time coefficient is determined, wherein the deviation direction is used to characterize the relative level of the estimated time to the average time of the task. Based on the weighted product formula of the target laboratory, the target time consumption coefficient, and the target sensitivity coefficient, the priority weight corresponding to the experimental task currently being processed is determined. The weighted product formula is used to indicate the time consumption coefficient weight corresponding to the target time consumption coefficient and the sensitivity coefficient weight corresponding to the target sensitivity coefficient. The time consumption coefficient weight and the sensitivity coefficient weight are associated with the equipment load status of the target laboratory under the current system time and the experimental scenario corresponding to the target laboratory. The priority weight is positively correlated with the task sensitivity level and negatively correlated with the expected time consumption.

3. The method according to claim 2, characterized in that, The task sensitivity levels include high sensitivity, medium sensitivity, and low sensitivity; the step of converting the task sensitivity level corresponding to the currently processed experimental task into a target sensitivity coefficient according to a preset sensitivity level mapping rule includes: If the task sensitivity level corresponding to the experimental task being processed is the high sensitivity level, then the preset first sensitivity coefficient is determined as the target sensitivity coefficient; If the sensitivity level of the experimental task being processed is medium sensitivity level or low sensitivity level, then obtain the target project type and target department of the experimental task being processed. According to the preset project-department weight mapping table, the target sensitivity factor corresponding to the experimental task being processed is determined. The project-department weight mapping table is used to indicate the first reference weight corresponding to each reference project type and the second reference weight corresponding to each reference department. The target sensitivity factor is the product of the first reference weight corresponding to the target project type and the second reference weight corresponding to the target department. The product of the basic sensitivity coefficient corresponding to the experimental task being processed and the target sensitivity factor is determined to be the target sensitivity coefficient. The basic sensitivity coefficient corresponding to the medium sensitivity level is the second sensitivity coefficient, and the basic sensitivity coefficient corresponding to the low sensitivity level is the third sensitivity coefficient. The first sensitivity coefficient is greater than the second sensitivity coefficient, and the third sensitivity coefficient is greater than the second sensitivity coefficient.

4. The method according to claim 2, characterized in that, The step of determining the corresponding target time consumption coefficient based on the deviation direction between the estimated time consumption of the currently processed experimental task and the average time consumption of the task includes: Obtain the basic upper limit threshold corresponding to the preset short time interval and the basic lower limit threshold corresponding to the long time interval, wherein the basic lower limit threshold is greater than the basic upper limit threshold; If the deviation direction indicates that the estimated time is higher than the average time of the task, then based on a preset threshold adjustment value, the basic upper limit threshold is increased and the basic lower limit threshold is decreased, and the threshold adjustment value is determined by the equipment load status of the target laboratory. If the deviation direction indicates that the estimated time is lower than the average time of the task, then based on the threshold adjustment value, the basic upper limit threshold is reduced and the basic lower limit threshold is increased; Based on the adjusted basic upper limit threshold and the basic lower limit threshold, the target interval category to which the estimated time of the currently processed experimental task belongs is determined. The target interval category includes the short time interval, the medium time interval, and the long time interval. The reference time consumption coefficient corresponding to the target interval category is determined as the target time consumption coefficient. The reference time consumption coefficient corresponding to the long time interval is less than the reference time consumption coefficient corresponding to the medium time interval, and the reference time consumption coefficient corresponding to the medium time interval is less than the reference time consumption coefficient corresponding to the short time interval.

5. The method according to claim 4, characterized in that, If the equipment utilization rate is greater than or equal to the preset utilization rate, it is determined that the current load mode of the target laboratory is in a high load mode, and the equipment utilization rate is determined by the equipment load status of the target laboratory. If the device utilization rate is less than the preset utilization rate, the current load mode is determined to be in a low load mode, wherein the threshold adjustment value corresponding to the high load mode is greater than the threshold adjustment value corresponding to the low load mode.

6. The method according to any one of claims 1-5, characterized in that, Before determining the task execution queue corresponding to each pre-set reference experimental device in the target laboratory based on the device execution information and priority weights corresponding to multiple experimental tasks, the method further includes: If a long-running task is detected in the set of experimental tasks, then it is determined whether the long-running task belongs to a decomposable task type according to the task type corresponding to the long-running task. The long-running task is the experimental task whose expected time exceeds the preset time. For long-duration tasks belonging to the decomposable task type, the multi-device collaboration sequence, the associated experimental equipment, and the equipment running time, a decomposition identification operation is performed to determine a safe decomposition point. The safe decomposition point satisfies any one of the following conditions: the long-duration task is in thermodynamic equilibrium during the equipment running time of the corresponding associated experimental equipment; the long-duration task is in a period of inactive substance settling during the equipment running time of the corresponding associated experimental equipment; or the long-duration task is in a state of chemical quenching completion during the equipment running time of the corresponding associated experimental equipment. Based on the identified safe decomposition point, the corresponding long-running task is decomposed into multiple sub-tasks to update the experimental task set. The sub-tasks are associated with the priority weights of the corresponding long-running tasks.

7. The method according to any one of claims 1-5, characterized in that, The task execution queue contains at least one reference execution operation that the corresponding reference experimental device needs to perform; after converting the task execution queue into an operation instruction sequence to control the experimental robot in the target laboratory to perform the experimental task through the reference experimental device, the method further includes: Real-time monitoring and acquisition of the task execution results and working status obtained when each of the reference experimental devices performs the corresponding reference execution operation; When any of the task execution results is detected to be abnormal, the corresponding reference experimental equipment is identified as the equipment to be adjusted, and it is determined whether the target execution operation corresponding to the task execution result is a recoverable operation: If the target execution operation is a recoverable operation, then a device self-healing operation is triggered. The device self-healing operation is used to control the device to be adjusted to re-execute the target execution operation when the working status of the device to be adjusted is normal, so as to obtain the task execution result. If the target execution operation is not a recoverable operation, a task rollback operation is triggered. The task rollback operation includes determining that the task execution result corresponding to the target experimental task associated with the target execution operation is invalid, resubmitting the target experimental task to the experimental task pool, and terminating the execution of the reference execution operation corresponding to the target experimental task.

8. A task scheduling device for intelligent laboratories, characterized in that, A server used in a laboratory system for a target laboratory, the device comprising: The task acquisition unit is used to acquire an experimental task pool. The experimental task pool is used to store a set of experimental tasks to be executed and attribute tags associated with each experimental task in the set of experimental tasks. The attribute tags include the task type, task sensitivity level and estimated time consumption of the corresponding experimental task. The task sensitivity level is used to characterize the sensitivity of the execution result of the corresponding experimental task to the timeliness risk. The weight calculation unit is used to determine the priority weight based on the task sensitivity level and expected time of each experimental task. An information acquisition unit is used to determine device execution information according to each task type. The device execution information is used to indicate the multi-device collaboration sequence required to execute the corresponding experimental task, as well as the multiple associated experimental devices and multiple device running times corresponding to the multi-device collaboration sequence. Each associated experimental device corresponds to one device running time. The task scheduling unit is used to determine the task execution queue corresponding to each reference experimental device in the target laboratory based on the device execution information and priority weights corresponding to multiple experimental tasks. The task execution queue is used to indicate the time for the corresponding reference experimental device to execute each experimental task. The task execution unit is used to convert the task execution queue into a sequence of operation instructions to control the experimental robot in the target laboratory to execute the experimental task through the reference experimental equipment.

9. A server, characterized in that, The method includes a processor, a memory, a communication interface, and one or more programs, said programs being stored in the memory and configured to be executed by the processor, said programs including instructions for performing the steps of the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program for storing electronic data interchange is provided, wherein the computer program causes a computer to perform the method as described in any one of claims 1-7.

Images