Laboratory operation system and method based on experimental process modularization

Abstract

The present invention relates to a laboratory operation system and method based on experimental process modularization, wherein, according to an execution order of a plurality of job objects generated from a plurality of job scripts in which are recorded the names of a plurality of modules selected by a user from among a plurality of modules, the modules being obtained by grouping a plurality of unit processes performed in a laboratory and modularizing same into respective experimental processes, experimental processes of the plurality of modules are performed for each job object, on the basis of process conditions of the experimental processes of the plurality of modules presented by each job object, thereby enabling the user to have a desired experiment performed automatically without user intervention simply by discriminately selecting some of the plurality of modules.

Description

Laboratory operation system and method based on experimental process modularization

[0001] It relates to systems and methods for operating a laboratory.

[0002] Due to the frequent occurrence of fires and explosions resulting from various laboratory experiments, active research and development is underway on unmanned laboratories, where experiments can be conducted without personnel present, to ensure the safety of laboratory users. Existing unmanned laboratory operating systems utilize platforms built by sequentially arranging a small number of experimental processes tailored to specific applications. However, while these platforms are suitable for conducting experiments for a single user, they are static systems, with only a small number of experimental processes tailored to a specific application. Consequently, they have difficulty conducting diverse experiments reflecting the diverse applications of multiple users.

[0003] The present invention provides a laboratory operation system and method that allows multiple unit processes to be modularized into individual experimental processes, enabling the user to automatically perform desired experiments without user intervention simply by selecting a module, while also enabling multiple users to quickly complete desired experiments. The present invention is not limited to the technical challenges described above, and other technical challenges may be derived from the following description.

[0004] A laboratory operation system according to one aspect of the present invention comprises: an interface node for generating a job script in which the names of each of a plurality of modules selected by a user from among a plurality of modules modularized into each experimental process by collecting a plurality of unit processes performed in a laboratory are recorded; a master node for generating a plurality of job objects corresponding to the plurality of job scripts from a plurality of job scripts including the generated job scripts and scheduling the execution order of the plurality of generated job objects; and a plurality of module nodes for performing an experimental process of each of the plurality of modules for each job object based on the process conditions of the experimental process of each of the plurality of modules suggested by each of the job objects according to the execution order of the plurality of job objects.

[0005] The above master node can schedule the execution order of the plurality of job objects created based on the amount of available resources of at least one experimental device used in the experimental process of the module to be executed first among the plurality of modules of each job object.

[0006] The above master node can schedule the execution order of the plurality of generated job objects according to the order in which the plurality of generated job objects satisfy the condition for the amount of available resources of each of at least one experimental device used in the experimental process of the module to be executed first.

[0007] The above master node can schedule the execution order of the plurality of generated job objects according to the order in which the plurality of generated job objects satisfy the conditions of the amount of available resources of each of at least one experimental device used in the experimental process of the module to be executed first and whether the module to be executed first owns a task that causes a bottleneck.

[0008] The master node includes a job scheduler that schedules the execution order of the plurality of created job objects by repeating the process of storing a plurality of job IDs assigned to the plurality of job objects in a waiting queue according to the creation order of the plurality of job objects, and moving and storing a job ID that first satisfies a condition for the amount of available resources of at least one experimental device used in the module to be executed first among the plurality of job IDs stored in the waiting queue to an executing queue, and at least one job object to which at least one job ID stored in the execution queue is assigned can be executed in the order in which the at least one job ID is stored in the execution queue.

[0009] The above job scheduler may include a job trigger that schedules the execution order of the plurality of generated job objects by repeating the process of moving and storing, in the execution queue, the job ID that first satisfies the conditions of the amount of available resources of at least one experimental device used for the module to be executed first and whether the module to be executed first owns a task causing a bottleneck, among the plurality of job IDs stored in the waiting queue.

[0010] The method further includes a resource management unit that receives information of each module node including the amount of available resources of at least one experimental device used in the experimental process of each module performed by each module node from each module node, and updates the amount of available resources of at least one experimental device used in the experimental process of each module performed by each module node according to the information of each module mode received, and the job scheduler can repeat the process of reading out the amount of available resources of at least one experimental device used in the module to be executed first from the information of each module node updated by the resource management unit, and moving and storing the job ID that first satisfies the condition for the amount of available resources read out to the execution queue.

[0011] The above interface node selects a model that presents process conditions of an experimental process of each of the selected plurality of modules according to information input by a user, and generates a job script in which process conditions of each experimental process according to the selected model are recorded, and the master node generates a job object including the selected model, and determines the process conditions of the experimental process of each of the plurality of modules presented by the model included in the generated job object as the process conditions of the experimental process of each of the plurality of modules of the generated job object.

[0012] The above master node can determine the values ​​of multiple process parameters of each experimental process recorded in the generated job script as the values ​​of multiple process parameters of each experimental process of the selected multiple modules, if the selected model is a manual model that manually determines the process conditions of each experimental process of the selected multiple modules and presents the manually determined process conditions.

[0013] The above master node can determine the values ​​of multiple process parameters of each experimental process predicted by an artificial intelligence model corresponding to the automatic model as the values ​​of multiple process parameters of each experimental process of the selected multiple modules, if the selected model is an automatic model that automatically determines the process conditions of each experimental process of the selected multiple modules and presents the automatically determined process conditions.

[0014] The master node includes a job scheduler that generates a job object including the generated model and the process database by generating the selected model and generating a process database in which information representing the experimental process of each of the selected plurality of modules is recorded, and the information representing the experimental process of each of the selected plurality of modules may include an execution order of the plurality of modules according to information input by a user and an execution order of the plurality of tasks for each module.

[0015] The master node may further include a task generation unit that generates a plurality of task recipes corresponding to recipes of a plurality of unit processes corresponding to experimental processes of each of the plurality of selected modules based on process conditions suggested by a model of the generated job object and information recorded in a process database of the generated job object; and a task scheduler that starts or stops the execution of a unit process according to each of the plurality of task recipes generated for each of the plurality of selected modules based on the amount of available resources of at least one experimental device used in the experimental process of each of the plurality of selected modules.

[0016] The master node may further include a task generation unit that generates a task recipe corresponding to a recipe of each of a plurality of unit processes of an experimental process of each of the selected plurality of modules for each of the plurality of tasks of each module based on process conditions suggested by a model of the generated job object and information recorded in a process database of the generated job object; and a task scheduler that determines execution or stop of each task according to each of the plurality of task recipes generated for each of the selected plurality of modules based on the amount of available resources of at least one experimental device used in the experimental process of each of the selected plurality of modules.

[0017] The above master node may further include an action translation unit that determines a plurality of actions of at least one experimental device used in each task recipe based on the resource amount of at least one experimental device allocated to each task determined by the above execution and the process conditions recorded in the task recipe of each task determined by the above execution; and an action scheduler that schedules the execution order of the determined plurality of actions based on whether the same experimental device is used simultaneously in the execution process of different job objects.

[0018] Among the plurality of module nodes, one module node that performs an experimental process of one module among the plurality of modules of each job object receives, from the master node, a plurality of action names listed in the execution order of the plurality of actions for each task of the one module and information for executing actions corresponding to the plurality of action names, and executes actions corresponding to the plurality of action names in the order in which the plurality of action names are listed according to the information for executing the actions corresponding to the plurality of action names, thereby performing the experimental process of the one module.

[0019] A laboratory operation method according to another aspect of the present invention comprises the steps of: generating a job script in which the names of each of a plurality of modules selected by a user from among a plurality of modules modularized into each experimental process by collecting a plurality of unit processes performed in a laboratory are recorded; generating a plurality of job objects corresponding to the plurality of job scripts from a plurality of job scripts including the generated job scripts and scheduling the execution order of the plurality of generated job objects; and performing an experimental process of each of the plurality of modules for each job object based on the process conditions of the experimental process of each of the plurality of modules suggested by each of the job objects according to the execution order of the plurality of job objects.

[0020] According to another aspect of the present invention, a computer-readable recording medium having recorded thereon a program for executing the above laboratory operation method on a computer is provided.

[0021] By performing the experimental process of each of the multiple modules for each job object based on the process conditions of the experimental process of each of the multiple modules presented by each job object according to the execution order of the multiple job objects generated from the multiple job scripts in which the names of each of the multiple modules selected by the user are recorded, the user can automatically perform the experiment desired by the user without the user's intervention by simply selecting some of the multiple modules modularized into each experimental process by collecting multiple unit processes performed in the laboratory.

[0022] By scheduling the execution order of multiple job objects based on the available resource amount of at least one experimental device used in the experimental process of the module to be executed first among multiple modules of each job object, the resources of multiple experimental devices placed in the laboratory can be optimally distributed and used so that multiple experiments desired by multiple users can be completed quickly.

[0023] By scheduling the execution order of multiple job objects in an order that satisfies the conditions of the amount of available resources of each of at least one experimental device used in the experimental process of the module to be executed first and whether the module to be executed first owns a task that causes a bottleneck, the time delay caused by the task that causes a bottleneck can be minimized, thereby reducing the time required for completing multiple experiments.

[0024] By scheduling the execution order of multiple job objects by repeatedly storing multiple job IDs assigned to multiple job objects in a waiting queue according to the creation order of multiple job objects, and moving and storing the job ID that first satisfies the condition of the amount of available resources of at least one experimental device used in a module to be executed first among multiple modules of each job object among the multiple job IDs stored in the waiting queue to an execution queue, modules of a certain job object and modules of another job object can be executed in parallel. As a result, the time required to complete multiple experiments can be significantly reduced.

[0025] In particular, by repeating the process of moving and storing the job ID that first satisfies the conditions of the amount of available resources of at least one experimental device used for the module to be executed first among the multiple job IDs stored in the waiting queue and whether the module to be executed first owns a task causing a bottleneck, the execution order of multiple job objects can be scheduled so that a lower priority job object can be executed first in a section delayed due to a bottleneck of a certain task. As a result, the time required for multiple experiments to be completed can be further reduced. The effect is not limited to the above-described effect, and other effects may be derived from the following description.

[0026] Figure 1 is a schematic diagram of an experimental process modularization structure according to one embodiment of the present invention.

[0027] Figure 2 is a configuration diagram of a laboratory operation system according to one embodiment of the present invention.

[0028] Figure 3 is a flowchart of a laboratory operation method according to one embodiment of the present invention.

[0029] Figures 4a and 4b show examples of job scripts according to the manual model of the present embodiment.

[0030] Figures 5a and 5b show examples of job scripts according to the automatic model of the present embodiment.

[0031] Figure 6 is a configuration diagram of the master node (2) illustrated in Figure 2.

[0032] Figure 7 is a configuration diagram of the job scheduler (21) illustrated in Figure 3.

[0033] Figure 8 is a table listing several commands that can be input to the interface node (1) illustrated in Figure 2.

[0034] Figure 9 is a flowchart of the operation of the job scheduler (21) illustrated in Figure 6.

[0035] Figure 10 is a flowchart of the operation of the job trigger (212) illustrated in Figure 7.

[0036] Figure 11 is a flowchart of the operation of the job modeler (213) illustrated in Figure 7.

[0037] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The present invention relates to a laboratory operation system and method that modularizes multiple unit processes into individual experimental processes, thereby enabling a user to automatically perform desired experiments without user intervention simply by selecting a module, while also enabling multiple users to quickly complete multiple desired experiments. Hereinafter, such methods and devices will be referred to simply as "laboratory operation system" and "laboratory operation method."

[0038] Figure 1 is a schematic diagram of the modularization of an experimental process according to one embodiment of the present invention. A wide variety of experiments are performed in laboratories. A variety of experimental devices are equipped to perform these experiments. Typically, multiple experimental jobs, designated by multiple users, are performed simultaneously in laboratories. In this embodiment, each experimental job represents a combination of multiple experimental processes that can achieve the experimental results desired by the user. Hereinafter, each experimental job designated by each user will be referred to simply as a "job."

[0039] The same experimental device is often used for different experimental processes. If a device is being used for one experimental process, it cannot be used for another experimental process. Therefore, to ensure rapid completion of multiple experimental processes, the execution order of multiple experimental processes must be appropriately scheduled. Typically, the execution order of multiple experimental processes is scheduled by the laboratory manager or user. The laboratory of this embodiment is an unmanned laboratory where the execution order of multiple experimental processes is automatically scheduled and experiments are conducted without personnel. According to this embodiment, not only is the execution order of multiple experimental processes automatically scheduled, but the information required for the execution of each experimental process is also automatically determined.

[0040] In order to automate these various experimental processes, in this embodiment, a combination of multiple unit processes frequently used in a laboratory is bundled into a single experimental process, thereby modularizing the combination of multiple unit processes into a single module. In other words, each module of this embodiment means that multiple unit processes performed in a laboratory are modularized into each experimental process. According to this embodiment, a combination of multiple unit processes for performing a specific experiment in a laboratory becomes a module corresponding to the experimental process for that specific experiment, and a combination of multiple modules selected by a user becomes an experimental task desired by the user. Referring to Fig. 1, the modules of this embodiment are classified into a synthesis module for performing a synthesis process, a preprocessing module for performing a preprocessing process, an analysis module for performing an analysis process, and a measurement module for performing a measurement process.

[0041] Examples of synthesis modules include a module representing an experimental process for synthesizing nanoparticles based on a solution process, a module representing an experimental process for synthesizing crystal structures based on a powder process, etc. Examples of pretreatment modules include a module representing an experimental process for washing particles, a module representing an experimental process for producing electrochemical catalyst ink, etc. Examples of analysis modules include a module representing an experimental process for performing XRD (X-Ray Diffraction) analysis, a module representing an experimental process for performing UV-Vis spectroscopy analysis, etc. Examples of measurement modules include a module representing an experimental process for performing thermochemical measurements, a module representing an experimental process for performing electrochemical measurements, etc.

[0042] Referring to Fig. 1, in this embodiment, the experimental process of each module is composed of multiple tasks. Each task in this embodiment represents each unit process. Each unit process in this embodiment represents each of the multiple processes that constitute each experimental process for each experimental process, and is designed based on the process unit that exists in common among the multiple experimental processes corresponding to the multiple modules. For example, a module representing an experimental process for synthesizing nanoparticles based on a solution process may be composed of multiple tasks representing a chemical vessel transfer process, a solution injection process, a synthesis reaction process, etc.

[0043] A module representing an experimental process for synthesizing a crystal structure based on a powder process may be comprised of multiple tasks representing a chemical vessel transfer process, a powder injection process, a heating reaction process, etc. A module representing an experimental process for washing particles may be comprised of multiple tasks representing a chemical vessel transfer process, a solvent injection process, a centrifugation process, a solvent removal process, etc. A module representing an experimental process for producing an electrochemical catalyst ink may be comprised of multiple tasks representing a chemical vessel transfer process, a solvent and binder injection process, a sonication process, a stirring process, etc.

[0044] A module representing an experimental process for performing XRD analysis may be comprised of multiple tasks representing a chemical vessel transfer process, a powder injection process, a specimen preparation process, a specimen measurement process, a specimen removal process, etc. A module representing an experimental process for performing thermochemical measurements may be comprised of multiple tasks representing a measurement solvent injection process, a nitrogen purging process, a catalyst ink loading process, a measurement process, a reactor cleaning process, etc.

[0045] Referring to Fig. 1, in this embodiment, each unit process corresponding to a task is composed of multiple actions. For example, in a module representing an experimental process for synthesizing nanoparticles based on a solution process, a task representing a chemical container transfer process may be composed of an action for opening the entrance of a chemical container storage, an action for a robotic arm to pick up a chemical container, an action for a robotic arm to position the chemical container over a stirrer, etc. In this module, a solution injection process may be composed of an action for setting a pump operation value, an action for positioning a solution dispenser over a stirrer, an action for operating a pump, etc.

[0046] In a module representing an experimental process for washing particles, a task representing a chemical vessel transfer process may include an action for transferring a chemical vessel holder, an action for a robotic arm to pick up a chemical vessel, and an action for a robotic arm to place the chemical vessel on a stirrer. In this module, a centrifugation process may include an action for opening a centrifuge, an action for a robotic arm to place a chemical vessel on the centrifuge, an action for closing the centrifuge, and an action for operating the centrifuge at a preset rpm.

[0047] Each action is expressed as data for controlling the actions of experimental devices such as robots, pumps, and centrifuges. Control of the actions of experimental devices can be achieved through dynamic control, such as controlling the movement of a robot, or static control, such as setting the RPM value of a centrifuge. Each task is expressed as a set of multiple action data, and each module is expressed as a set of multiple task data.

[0048] FIG. 2 is a block diagram of a laboratory operation system according to one embodiment of the present invention, and FIG. 3 is a flowchart of a laboratory operation method according to one embodiment of the present invention. Referring to FIG. 2, the laboratory operation system according to the present embodiment is composed of an interface node (1), a master node (2), and a plurality of module nodes (3). In the present embodiment, each of the plurality of nodes is implemented as a separate computer, and the plurality of nodes communicate with each other through a network. Some of the plurality of nodes may be implemented as a single computer. For example, the interface node (1) and the master node (2) may be implemented as a single computer. Hereinafter, the laboratory operation system and the laboratory operation method according to the present embodiment will be described with reference to FIGS. 2 and 3.

[0049] In step 10, the interface node (1) checks whether information for creating a job script has been input by the user. If the result of the check in step 10 indicates that the information for creating a job script has been input by the user, the process proceeds to step 20. Otherwise, the process returns to step 10. In step 20, the interface node (1) generates a job script based on the information entered by the user in step 10. In step 30, the interface node (1) checks whether the user has logged in to any one of multiple job sessions. In this embodiment, multiple job sessions are provided so that multiple users can simultaneously access the interface node (1) and create job scripts. If the result of the check in step 30 indicates that the user has logged in, the process proceeds to step 40. Otherwise, the process returns to step 10.

[0050] In the process of repeating steps 10 to 30, the user continuously inputs information for creating a job script into the interface node (1) before logging in, thereby completing the job script desired by the user. In this way, in step 20, the interface node (1) selects multiple modules corresponding to some of the multiple modules that are modularized into each experimental process by collecting multiple unit processes performed in the laboratory according to the information entered by the user, and generates a job script in which the names of each of the multiple modules selected by the user and the process conditions of each of the experimental processes of each of the multiple modules selected by the user are recorded. The process conditions of each of the experimental processes of each of the multiple modules selected by the user can be said to be the process conditions of each experimental process indicated by each of the names of the multiple modules.

[0051] According to this embodiment, a user can automatically perform an experiment desired by the user without the user's intervention by simply selecting some of the modules from among the multiple unit processes performed in the laboratory and modularizing them into each experimental process.

[0052] In this embodiment, the model that presents the process conditions of the experimental process of each module is classified into a manual model (manual mode 1) and an automatic model (automatic mode 1) depending on whether the process conditions of each experimental process are determined manually by the user or automatically by an artificial intelligence model. The automatic model is further classified into several types of artificial intelligence models. The format of the job script changes depending on which type of model is selected among the several types of models that present the process conditions of each experimental process. That is, the interface node (1) selects a model that presents the process conditions of each experimental process of multiple modules selected based on the information input by the user, and generates a job script that records the process conditions of each experimental process according to the selected model.

[0053] Figures 4a and 4b illustrate examples of job scripts according to the manual model of this embodiment, and Figures 5a and 5b illustrate examples of job scripts according to the automatic model of this embodiment. The process conditions of the experimental process of each module refer to various conditions that must be set in order to perform the execution process. Representative examples of the process conditions of each experimental process include values ​​of multiple process parameters used in each experimental process, such as the concentration, volume, and injection rate of various solutions used in each experimental process. In this embodiment, the manual model refers to a model that manually determines the process conditions of each experimental process of multiple modules selected by the user and presents the manually determined process conditions. The automatic model refers to a model that automatically determines the process conditions of each experimental process of multiple modules selected by the user and presents the automatically determined process settings.

[0054] The job script of this embodiment has a hierarchical structure in the form of a JSON (JavaScript Object Notation) file. Regardless of the model type, the first layer, which is the top layer of the job script, consists of a metadata layer in which metadata for each job for each user is recorded, an algorithm layer in which algorithm information of a model that presents process conditions for the experimental process of each module is recorded, and a process layer in which process condition information for each experimental process of multiple modules used in each job for each user is recorded. Regardless of the model type, the second layer of the metadata layer records the experiment title, the user's group, and the log file level of "DEBUG" or "INFO."

[0055] In the job script of the manual model illustrated in Figures 4a and 4b, the second layer of the algorithm hierarchy records "Manual" in the "model" field, indicating that the model selected by the user is a manual model. The total number of experiments is recorded in "totalExperimentNum," and the values ​​of at least one process parameter that the user wishes to experiment with are recorded in "inputParams." Each process condition is composed of a dictionary, and is recorded in the format "{task name}={process parameter name}" within a process condition.

[0056] In the job script of the manual model illustrated in Figures 4a and 4b, the second layer of the process hierarchy, "Synthesis," records information on the module corresponding to synthesis. That is, the module names such as "BatchSynthesis" and "FlowSynthesis" are recorded in the third layer, and the order of the module names becomes the execution order of the modules. Additional module names can be added here. The fourth layer, "fixedParams," records the value of at least one process parameter that the user wants to fix. The fifth layer, "{Module Name}=Sequence," records the task order of each module. In the fifth layer, the value of each process parameter that the user wants to fix in each task of each module is recorded in the format "{Task Name}={Process Parameter Name}."

[0057] Likewise, in the third layer of "Preprocess" in the second layer, the names of modules corresponding to preprocessing, such as washing, catalyst ink manufacturing, etc. are recorded. Similarly, in the third layer of "Characterization" in the second layer, the names of modules corresponding to analysis, such as UV-Vis analysis, etc. are recorded. Similarly, in the third layer of "Evaluation" in the second layer, the names of modules corresponding to measurement, such as RDE (Rotating Disk Electrode) measurement, electrode measurement, etc. The remaining information of "Preprocess," "Characterization," and "Evaluation" in the second layer are also recorded in the same hierarchical structure as the second layer "Synthesis." In this way, the process layer records the execution order of multiple modules, the execution order of multiple tasks for each module, and process conditions fixed by the user.

[0058] In the job script of the automatic model illustrated in Figures 5a and 5b, the second layer of the algorithm hierarchy records "BayesianOptimization," which indicates that the model selected by the user is an automatic Bayesian optimization model. Instead of the Bayesian optimization model, the name of another type of artificial intelligence model, such as "DecisionTree" or "AdaBoost," may be recorded. In the second layer, "batchSize" records the number of repetitions of each experimental process performed in one cycle. "totalCycleNum" records the total number of cycles performed in each experimental process. "verbose" records the visualization steps for the progress of each experimental process, such as 0, 1, or 2. "randomState" records the random number required for learning the artificial intelligence model. "sampling" records the initial sampling values ​​before predicting the process parameter values ​​of the artificial intelligence model. In the third layer, "samplingMethod" records the sampling method, and "samplingNum" records the initial sampling number.

[0059] In the second layer, "acq" records the design factors of the acquisition function for recommending the following process parameter values. In the third layer, "acqMethod" records the type of acquisition function. For example, it can be any one of "ei" (Expected Improvement), "ucb" (Upper Confidence Bound), and "es" (Entropy Search). In "acqSampler", the sampling type of the acquisition function is recorded. For example, it can be any one of "greedy" and "capitalism." In "acqhyperparamater", the hyperparameters of the acquisition function are recorded. In the fourth layer, if acqMethod is ucb, "acqhyperparamater" becomes "kappa", and if acqMethod is ei, "acqhyperparamater" becomes "xi".

[0060] In the second layer, "loss" contains information about the loss function used by the user to evaluate the material synthesized according to the present embodiment. In the third layer, "lossMethod" contains the type of loss function. In "lossTarget" contains information about the material properties desired by the user as experimental results. In the fourth layer below, the name of the task from which the property is extracted is stored. For example, the name of the task for obtaining absorbance, "GetAbs," can be stored. In the fifth layer, "Property" contains the value of the property targeted by the user. For example, the overvoltage and current density of a catalyst, or the maximum absorption wavelength of nanoparticles for displays can be stored. In the "Ratio" layer, the weight of the loss function is stored. The key value of the sixth layer varies depending on the property that can be extracted from the fourth layer.

[0061] In the second layer, "prange" records the range of process parameter values ​​set by the user. The AI ​​model predicts the values ​​of the process parameters within this range. The key is recorded in the format "{task name}={process variable name}", and the range of process parameter values ​​follows the format [{minimum value}, {maximum value}, {value interval}]. In "initParameterList", the values ​​of the process parameters that the user unconditionally wants to execute are recorded. In "constraints", the constraint range of the process design based on the AI ​​model is recorded, and it is recorded in the format "{task name}={process parameter name}". The process layer is identical to the job script of the manual model illustrated in Figures 4a and 4b, and the description of Figures 4a and 4b will be replaced.

[0062] FIG. 6 is a configuration diagram of the master node (2) illustrated in FIG. 2. Referring to FIG. 6, the master node (2) is composed of a job scheduler (21), a resource management unit (22), a task generation unit (23), a task scheduler (24), an action translation unit (25), an action scheduler (26), a packet transmission unit (27), a packet reception unit (28), and storage (29). FIG. 7 is a configuration diagram of the job scheduler (21) illustrated in FIG. 3. Referring to FIG. 7, the job scheduler (21) is composed of a job ID generator (211), a job trigger (212), and a job modeler (213). Since it takes a considerable amount of time until the execution of multiple experimental processes according to one job script is completed, the laboratory operation system according to the present embodiment supports parallel processing of multiple job scripts at the request of multiple users. To illustrate parallel processing of multiple job scripts, Fig. 7 also shows an interface node (1) in addition to a job scheduler (21).

[0063] In step 40, the interface node (1) assigns at least one thread number from among the multiple thread numbers of the multi-thread pool to each of at least one user logged in in step 30. One thread number is assigned to each user. This embodiment can process multiple commands input from multiple users in parallel by using Python's multi-thread pool. By doing so, this embodiment can process multiple job scripts generated based on information input from multiple users in parallel. In step 50, the interface node (1) checks whether a command has been input from a user to whom a thread number has been assigned in step 40. If the check result in step 50 indicates that a command has been input from a user, the process proceeds to step 60. Otherwise, the process waits until a command is input from a user.

[0064] Fig. 8 is a table listing various commands that can be input into the interface node (1) illustrated in Fig. 2. Referring to Fig. 8, a user can input any one of the commands "qstat", "qsub", "qdel", "qhold", "qrestart", and "qlogout" into the interface node (1). An administrator of the laboratory operation system according to the present embodiment can input any one of the commands "ashutdown", "areboot", and "updateNode" into the interface node (1). The operation of the master node (2) according to each command is described in Fig. 8.

[0065] At step 60, the interface node (1) calls the job scheduler function corresponding to the command input from the user at step 50 for the master node (2). At step 70, the master node (2) executes the job scheduler function called by the interface node (1) at step 60. At step 80, the master node (2) returns the execution result of the job scheduler function at step 70 to the interface node (1). For example, when the interface node (1) calls the job scheduler function corresponding to the "qstat" command input from the user, the master node (2) executes the job scheduler function by monitoring the job IDs stored in the entire queue and returns the monitoring result.

[0066] At step 90, the interface node (1) checks whether the user has logged out of the job section. If the user has logged out, the process ends. Otherwise, the process returns to step 50. After calling the job scheduler function at step 60, the interface node (1) checks whether the user has logged out at step 90. If the user is still logged in, it checks whether a command has been entered by the user. This process is repeated until the user logs out.

[0067] The interface node (1) receives "qsub" input from the user. <filename> <modetype>"When calling the job scheduler function corresponding to the command, the master node (2) executes the job scheduler function by having multiple module nodes (3) perform experiments according to the job script, and returns the results of the experiments. The interface node (1) executes the "qdel" input from the user.<job id> "When the job scheduler function corresponding to the command is called, the master node (2) executes the job scheduler function by deleting the job ID from the holding queue and returns a result indicating the deletion of the job ID.

[0068] The interface node (1) receives the "qhold" input from the user.<job id> "When the job scheduler function corresponding to the command is called, the master node (2) executes the job scheduler function by moving and storing the job ID from the executing queue to the holding queue, and returns the result notifying the holding of the job ID. The interface node (1) returns the "qrestart" input from the user.<job id> "When the job scheduler function corresponding to the command is called, the master node (2) moves the job ID from the holding queue to the execution queue and stores it, thereby executing the job scheduler function and returning a result notifying the restart of the job ID. When the interface node (1) calls the job scheduler function corresponding to the "qlogout" command input by the user, the master node (2) executes the logout of the user and returns a result notifying the logout.

[0069] As described above, the user qsubs the job script generated in step 20 to the interface node (1) to submit it to the master node (2). <filename> <modetype>You can enter: Here, <filename>refers to the user-named file name for the job script generated in step 20, <modetype>refers to a string indicating whether the experiment conducted according to the job script generated in step 20 is in virtual experiment mode or actual experiment mode. In this case, in step 70, the master node (2) executes the job scheduler function by having multiple module nodes (3) perform the experiment according to the job script generated in step 20, and each module node (3) performs the experiment according to the job script generated in step 20 according to the instructions of the master node (2) and transmits the result of the experiment to the master node (2).

[0070] To be more specific, in step 71, the master node (2) generates multiple job objects corresponding to multiple job scripts from multiple job scripts including job scripts generated by the interface node (1). The master node (2) generates one job object from one job script. That is, the interface node (1) can generate each of multiple job scripts according to information input by each of multiple users, and the master node (2) can generate each of multiple job objects from each of the multiple job scripts. Each job object suggests an experiment using a combination of multiple modules, but may also suggest an experiment using a single module.

[0071] In step 72, the master node (2) schedules the execution order of the plurality of job objects generated in step 71. According to the present embodiment, the master node (2) schedules the execution order of the plurality of job objects generated in step 71 based on the available resource amount of at least one experimental device used in the experimental process of the module to be executed first among the plurality of modules of each job object generated in step 71. Here, the available resource amount of each experimental device means the remaining resource amount currently available among the total resource amount of each experimental device. For example, if a certain experimental device is a stirrer that can be equipped with a total of 10 vials and the stirrer is currently equipped with 3 vials, the total resource amount of the experimental device is 10, and the available resource amount is 7.

[0072] In this way, by scheduling the execution order of multiple job objects based on the available resource amount of at least one experimental device used in the experimental process of the module to be executed first among multiple modules of each job object, the resources of multiple experimental devices placed in the laboratory can be optimally distributed and used so that multiple experiments desired by multiple users can be completed quickly.

[0073] In step 73, the plurality of module nodes (3) perform the experimental processes of the plurality of modules indicated by the process database of each job object based on the process conditions of the respective experimental processes of the plurality of modules suggested by the model of each job object according to the execution order of the plurality of job objects scheduled by the master node (2) in step 72. Subsequently, each module node (3) transmits the execution results of each experimental process to the master node (2). In step 80, the master node (2) receives the execution results of each experimental process from each module node (3) and returns the execution results of each experimental process to the interface node (1) as the execution results of the job scheduler function in step 70. Here, the plurality of modules indicated by the process database of each job object means the plurality of modules indicated by the plurality of module names recorded in the process database of each job object.

[0074] Fig. 9 is a flowchart of the operation of the job scheduler (21) illustrated in Fig. 6. Referring to Fig. 9, the operation of the job scheduler (21) illustrated in Fig. 6 proceeds in the following order. In step 91, the job modeler (213) receives a command "qsub" from the interface node (1). <filename> <modetype>"The job script generated in step 20 is input. In step 92, the job ID generator (211) checks whether the job ID can be generated. In this embodiment, the job ID is the ID of the job object assigned to the job object, and since a number in a preset range, for example, one number from 1 to 100, is sequentially assigned to the job object, if all numbers in the preset range are used, it becomes impossible to generate the ID of the job object.

[0075] As a result of the verification in step 92, if the generation of the job object ID is impossible, the process proceeds to step 93, and if possible, to step 94. In step 93, the job ID generator (211) initializes the job ID so that the job ID can start from the first number among the numbers in the preset range. For example, the job ID generator (211) can initialize the job ID to "1". In step 94, the job ID generator (211) generates the job ID as any one of the numbers excluding the number already generated as the job ID.

[0076] In step 95, the job modeler (213) creates a job object from the job script created in step 20, and assigns the job ID created by the job ID generator (211) in step 94 to the job object created in this manner. The job modeler (213) creates a model corresponding to the model name recorded in the "model" of the second layer of the algorithm layer of the job script created in step 20, that is, a model selected according to the information entered by the user, as a model that presents the process conditions of the experimental process of each of the plurality of modules, and creates a process database in which information representing the experimental process of each of the plurality of modules selected by the user is recorded, thereby creating a job object composed of the model created in this manner and the process database. The model creation of the job object will be described in detail below with reference to FIG. 11.

[0077] The job modeler (213) extracts a process hierarchy from the job script generated in step 20. Subsequently, the job modeler (213) reads information representing the experimental process of each of the plurality of modules from the process hierarchy extracted in this way, and creates a process database composed of information representing the experimental process of each of the plurality of modules. In this embodiment, the information representing the experimental process of each of the plurality of modules is composed of the execution order of the plurality of modules according to the information input by the user, the execution order of the plurality of tasks for each module, and the process conditions fixed by the user. Here, the process conditions fixed by the user mean the process conditions directly input by the user so that they cannot be changed by the model of the job object, i.e., the plurality of process parameter values.

[0078] In step 96, the job modeler (213) maps the job object generated in step 95 and the job ID assigned to the job object and stores them in the job storage. The job storage is a part of the storage (29) for storing job objects. In step 97, the job modeler (213) stores the job ID generated by the job ID generator (211) in step 94 in a waiting queue. In the waiting queue of the present embodiment, the job ID assigned to each job object is stored whenever each job object is generated. Steps 91 to 96 are repeated whenever a job script is generated by the user. In this way, the job modeler (213) generates a plurality of job objects from a plurality of job scripts, and stores a plurality of job IDs assigned to the plurality of job objects in the waiting queue according to the generation order of the plurality of job objects.

[0079] In step 98, the job trigger (212) determines a job ID that satisfies the job object execution condition among the multiple job IDs stored in the waiting queue. Here, the job object execution condition for each job ID stored in the waiting queue means the condition of the amount of available resources of at least one experimental device used for the module to be executed first among the multiple modules of the job object to which each job ID is assigned and whether the module to be executed first owns a task that causes a bottleneck. In step 99, the job trigger (212) checks whether the job ID determined in step 98 exists. If the check result in step 99 shows that the job ID determined in step 98 exists, the process proceeds to step 910. Otherwise, the process waits until a job ID that satisfies the job object execution condition is determined. In step 910, the job trigger (212) moves the job ID determined in step 98 from the waiting queue to the execution queue and stores it.

[0080] As described above, if a job ID stored in the waiting queue does not satisfy the job object execution condition, the job ID will be continuously stored in the waiting queue. As long as there is at least one job ID stored in the waiting queue, steps 98 to 910 are continuously repeated, and eventually, the job ID will meet the job object execution condition and be stored in the execution queue. The operation of the job trigger (212) in steps 98 to 910 will be described in detail in the description below with reference to FIG. 10.

[0081] The job trigger (212) repeats the process of moving and storing, in the execution queue, the job ID that first satisfies the conditions of the amount of available resources of at least one experimental device used for the module to be executed first among the multiple modules presented by each job object to which each job ID is assigned among the multiple job IDs stored in the waiting queue and whether the module to be executed first owns a task that causes a bottleneck. The process of selecting the job object to be executed first among the multiple job objects to which the multiple job IDs stored in the waiting queue are assigned is repeated.

[0082] The job trigger (212) reads the amount of available resources of at least one experimental device used for the module to be executed first among the multiple modules presented by each job object to which each job ID is assigned from the information of each module node (3) updated by the resource management unit (22), and moves the job ID that first satisfies the condition of whether the read available resource amount and the module to be executed first own a task that causes a bottleneck to the execution queue, and repeats the process. The job trigger (212) schedules the execution order of the multiple job objects generated in step 95 through this iterative process.

[0083] As described above, scheduling the execution of multiple job objects by moving job IDs from the wait queue to the run queue allows modules from one job object to be executed in parallel with modules from another job object. As a result, the time required to complete multiple experiments can be significantly reduced.

[0084] The execution queue stores at least one Job ID that satisfies the job object execution conditions among the Job IDs stored in the waiting queue. When a Job ID is moved from the waiting queue to the execution queue, the Job ID is deleted from the waiting queue. When the experimental processes of multiple modules represented by the Job object to which a Job ID stored in the execution queue is assigned are all completed, the Job ID is deleted from the execution queue. When at least one Job ID is stored in the execution queue, at least one Job object to which at least one Job ID stored in the execution queue is assigned is executed in the order in which at least one Job ID is stored in the execution queue, as described below. In other words, the experimental processes of each of the multiple modules represented by the Job object to which each Job ID is assigned are performed in the order in which the at least one Job ID is stored in the execution queue.

[0085] In this way, the job trigger (212) schedules the execution order of the plurality of job objects generated in step 95 in the order in which the plurality of job objects generated in step 95 satisfy the conditions regarding the amount of available resources of at least one experimental device used in the experimental process of the module to be executed first among the plurality of modules presented by each job object to which each job ID is assigned and whether the module to be executed first owns a task that causes a bottleneck. That is, the job trigger (212) schedules the execution order of the plurality of job objects generated in step 95 in the order in which the plurality of job objects generated in step 95 satisfy the conditions regarding the amount of available resources of at least one experimental device used in the experimental process of the module to be executed first among the plurality of modules presented by each job object to which the job ID is assigned and whether the module to be executed first owns a task that causes a bottleneck.

[0086] In step 911, the job modeler (213) determines the process conditions of the experimental process of each of the multiple modules presented by the model of the job object to which the job ID stored in the execution queue is assigned as the process conditions of the experimental process of each of the multiple modules of the job object created in step 20. If the job ID stored in the execution queue is the job ID assigned to the job object created in step 20, the job modeler (213) determines the process conditions of the experimental process of each of the multiple modules presented by the model of the job object to which the job ID stored in the execution queue is assigned as the process conditions of the experimental process of each of the multiple modules of the job object created in step 20.

[0087] According to the above, the model of the job object is classified into a manual model and an automatic model. If the model of the job object is a manual model, the job modeler (213) determines the values ​​of the multiple process parameters of each experimental process recorded in the job script generated in step 20 as the values ​​of the multiple process parameters of each experimental process of each of the multiple modules selected by the user. Here, the values ​​of the multiple process parameters of each experimental process recorded in the job script generated in step 20 are the process conditions of each experimental process of each of the multiple modules presented by the manual model of the job object to which the job ID stored in the execution queue is assigned, and the multiple modules selected by the user are the multiple modules indicated by the multiple module names recorded in the job script generated in step 20.

[0088] If the model of the job object is an automatic model, the job modeler (213) determines the values ​​of the multiple process parameters of each experimental process predicted by the artificial intelligence model corresponding to the automatic model of the job object generated in step 95 as the values ​​of the multiple process parameters of each experimental process of each of the multiple modules selected by the user. Here, the values ​​of the multiple process parameters of each experimental process predicted by the artificial intelligence model are the process conditions of each experimental process of each of the multiple modules suggested by the automatic model of the job object to which the job ID stored in the execution queue is assigned, and the multiple modules selected by the user are the multiple modules indicated by the multiple module names recorded in the job script generated in step 20.

[0089] In step 912, the job scheduler (21) reads out the execution order of multiple modules, the execution order of multiple tasks for each module, and the process conditions fixed by the user from the process database of the job object to which the job ID stored in the execution queue is assigned. In step 913, the job scheduler (21) transfers all information of the experimental process of multiple modules represented by the job object, which is composed of the process conditions set in step 911, the execution order of multiple modules read out in step 912, the execution order of multiple tasks for each module, and the process conditions, to the task generator (23). The execution order of multiple modules is expressed in the order of multiple module names, the execution order of multiple tasks for each module is expressed in the order of multiple task names, and the process conditions for each module are expressed in the order of multiple process parameter values ​​for each module.

[0090] Fig. 10 is a flowchart of the operation of the job trigger (212) illustrated in Fig. 7. Referring to Fig. 10, the operation of the job trigger (212) proceeds in the following order. In step 101, the job trigger (212) sets the value of the index "i" to the initial value "1". Here, the index "i" indicates the rank of the job ID in the waiting queue. When multiple job IDs are stored in the waiting queue, the rank of each of the multiple job IDs is determined in the order in which the multiple job IDs are stored. When a job ID is deleted from the waiting queue, the rank of the job ID corresponding to the next rank of the job ID is increased by one level.

[0091] In step 102, the job trigger (212) reads the name of the module to be executed first among the multiple modules of the job object to which the job ID of the i-th rank in the waiting queue is assigned from the job storage. In the example illustrated in Fig. 10, the name of module A is read from the job storage. In step 103, the job trigger (212) checks whether the available resource amount of at least one experimental device used in the experimental process of the module having the name read in step 102 is "0". The condition that the available resource amount of at least one experimental device used in a certain experimental process is "0" is satisfied if the available resource amount of any one of the at least one experimental device used in the experimental process is "0". As a result of the check in step 103, if the available resource amount of at least one experimental device used in the experimental process of the module having the name read in step 102 is "0", the process proceeds to step 104. Otherwise, the process proceeds to step 106.

[0092] In step 104, the job trigger (212) increases the value of the index "i" by 1. In step 105, the job trigger (212) checks whether the job ID of the i-th rank exists in the waiting queue. If the job ID of the i-th rank exists as a result of the check in step 105, the process returns to step 102. If the job ID of the i-th rank does not exist, the process returns to step 101, initializes the index "i", and checks again the job object having the job ID corresponding to the first order in the waiting queue. If the process returns to step 102, the available resource amount of at least one experimental device to be used for the module to be executed first among the multiple modules of the job object to which the job ID of the next order is assigned is checked.

[0093] In step 106, the job trigger (212) checks whether the module with the name read in step 102 owns a task that causes a bottleneck. If the result of the check in step 106 indicates that the module owns a task that causes a bottleneck, the process proceeds to step 107. Otherwise, the process proceeds to step 1010. A bottleneck in this embodiment refers to a phenomenon in which a unit process corresponding to a task consumes a time exceeding a preset threshold time, thereby causing a delay in the execution of other tasks that are executed subsequent to the task. An example of such a bottleneck is a reaction process in which a considerable amount of time is required for a chemical reaction desired by a user to be completed after mixing several substances.

[0094] In step 107, the job trigger (212) checks whether the module with the name read in step 102 is executing a task that causes a bottleneck. If the result of the check in step 107 shows that the module is executing a task that causes a bottleneck, the process proceeds to step 1010. Otherwise, the process proceeds to step 108. In step 108, the job trigger (212) increases the value of the index "i" by 1. In step 109, the job trigger (212) checks whether the job ID of the ith rank exists in the waiting queue. If the result of the check in step 109 shows that the job ID of the ith rank exists, the process returns to step 102. If the job ID of the ith rank does not exist, the process returns to step 101. In step 1010, the job trigger (212) moves the job ID of the ith rank from the waiting queue to the execution queue and stores it. At step 1011, the job trigger (212) instructs the resource management unit (22) to update the amount of available resources for each experimental device.

[0095] According to the operation of the job trigger (212) illustrated in FIG. 10, by scheduling the execution order of multiple job objects by considering the amount of available resources of at least one experimental device used for the module to be executed first and the condition of whether the module to be executed first owns a task that causes a bottleneck, the resources of multiple experimental devices are optimally distributed while the time delay due to the task that causes a bottleneck is minimized, so that the time required for multiple experiments to be completed can be reduced. In addition, by allowing a lower priority job object to be executed first in a section delayed due to a bottleneck of a task, the time required for multiple experiments to be completed can be further reduced.

[0096] Fig. 11 is a flowchart of the operation of the job modeler (213) illustrated in Fig. 7. Referring to Fig. 11, the operation of the job modeler (213) proceeds in the following order. In step 111, the job modeler (213) extracts an algorithm layer from the job script generated in step 20. In step 112, the job modeler (213) checks the model name recorded in "model" among the second layer of the algorithm layer extracted in step 111. As a result of the check in step 112, if the model name recorded in "model" is "Manual", the process proceeds to step 113, and if the model name recorded in "model" is "Automatic", the process proceeds to step 116.

[0097] In step 113, the job modeler (213) allocates a portion of the storage space (29) for the job ID assigned to the job object in step 95 as a space for storing the process conditions of each experimental process of multiple modules of the job object to which the job ID was assigned in step 95. The storage space allocated in this way becomes the space used by the job object to which the job ID is assigned. In step 114, the job modeler (213) reads the process conditions input by the user from the algorithm layer extracted in step 111. Examples of the process conditions input by the user include the total number of experiments and multiple process parameter values ​​that the user wants to experiment with.

[0098] In step 115, the job modeler (213) creates a manual model corresponding to the model name recorded in "model" of the second layer of the algorithm layer extracted in step 111, and determines the process conditions read out in step 114 as the process conditions of the experimental processes of each of the multiple modules of the job object to which the job ID is assigned in step 95 according to the manual model created in this way. In this embodiment, the manual model is a type of mapping function that maps multiple process parameter values, which are the process conditions read out in step 114, one-to-one to multiple process parameter values ​​of the experimental processes of each of the multiple modules of the job object to which the job ID is assigned in step 95.

[0099] In step 116, the job modeler (213) allocates a portion of the storage space (29) for the job ID assigned to the job object in step 95 as a space for storing the process conditions of each experimental process of multiple modules of the job object to which the job ID was assigned in step 95. In step 117, the job modeler (213) reads the constraints of the process conditions set by the user from the algorithm layer extracted in step 111. Examples of constraints of the process conditions set by the user include the range of process parameter values ​​set by the user among the information recorded in the job script illustrated in FIGS. 5a and 5b, the values ​​of process parameters that the user unconditionally wants to execute, and the constraint range of the process design based on the artificial intelligence model.

[0100] In step 118, the job modeler (213) creates an artificial intelligence model corresponding to the model name recorded in "model" of the second layer of the algorithm layer extracted in step 111. The job modeler (213) can create an artificial intelligence model by copying an artificial intelligence model corresponding to the model name recorded in "model" of the second layer of the algorithm layer among various types of artificial intelligence models stored in the storage (29). The artificial intelligence model copied in this way is an artificial intelligence model before being optimized according to the present embodiment. Subsequently, the job modeler (213) reads out the values ​​of hyperparameters for optimizing the artificial intelligence model created in this way from the algorithm layer extracted in step 111.

[0101] Examples of hyperparameter values ​​for optimizing an artificial intelligence model include information recorded in "batchSize", "totalCycleNum", "verbose", "randomState", "sampling", "samplingMethod", "samplingNum", "acqMethod", "acqSampler", "acqhyperparamater", "lossMethod", "lossTarget", and "Property" among the information recorded in the job script illustrated in FIGS. 5a and 5b. If the model name recorded in "model" among the second layer of the algorithm layer extracted in step 111 is "BayesianOptimization", the job modeler (213) can create an artificial intelligence model by copying the surrogate model and acquisition function stored in the storage (29). In the following, this embodiment will be described assuming that an artificial intelligence model consisting of a surrogate model and an acquisition function has been created.

[0102] In step 119, the job modeler (213) compares the number of samplings among the hyperparameter values ​​read in step 118 with the number of learning unit data accumulated and stored in the storage (29) so far. If the comparison result in step 119 shows that the number of samplings is greater than the number of learning unit data accumulated and stored in the storage (29) so far, the process proceeds to step 1110. If the comparison result in step 119 shows that the number of learning unit data accumulated and stored in the storage (29) so far is greater than the number of samplings, the process proceeds to step 1111.

[0103] In step 1110, the job modeler (213) randomly generates values ​​of multiple process parameters within a range that satisfies the constraints of the process conditions read out in step 117, and determines the values ​​of the multiple process parameters generated in this way as process conditions of each experimental process of multiple modules of the job object to which the job ID is assigned in step 95. For example, the job modeler (213) generates multiple sets of all possible multiple process parameters within the range of process parameter values ​​set by the user for at least one material property value recorded in "Property" of the job script generated in step 20.

[0104] In step 1111, the job modeler (213) ranks the multiple loss values ​​calculated in step 1116 by evaluating the multiple loss values ​​calculated in step 1116 using the acquisition function. Subsequently, the job modeler (213) determines the multiple process parameter values ​​corresponding to the highest-ranked loss among the multiple losses calculated in step 1116 among the multiple sets of values ​​of the multiple process parameters generated in step 1116 as the process conditions of the experimental process of each of the multiple modules of the job object to which the job ID is assigned in step 95.

[0105] In step 1112, the job modeler (213) transmits the process conditions of the experimental process of each of the multiple modules of the job object to which the job ID was assigned in step 95 to the task generator (23). In step 1113, when the job modeler (213) receives a combination of multiple process parameter values ​​and at least one material property value from the module node (3) through the packet receiver (28), the job modeler (213) stores the combination of the multiple process parameter values ​​and at least one material property value received in this way as new learning unit data in the storage (29). Here, examples of the material property values ​​include current density, absorbance, etc., and the material property values ​​vary depending on the type of the measurement module or analysis module that output them.

[0106] In step 1114, the job modeler (213) extracts learning unit data having at least one property value corresponding to at least one property value recorded in "Property" of the job script generated in step 20 from among the plurality of learning unit data stored in the storage (29), and calculates a loss value between at least one property value of the learning unit data extracted in this way and at least one property value recorded in "Property" of the job script generated in step 20 using the loss function of "lossMethod" of the job script generated in step 20.

[0107] In step 1115, the job modeler (213) inputs multiple process parameter values ​​of the learning unit data extracted in step 1114 into the surrogate model of the automatic model generated in step 118, and trains the surrogate model so that the loss value calculated in step 1114 is output from the surrogate model into which multiple process parameter values ​​are input.

[0108] In step 1116, the job modeler (213) generates multiple sets of values ​​of multiple process parameters that satisfy the constraints of the process conditions read out in step 117 for at least one property value recorded in "Property" of the job script generated in step 20. For example, the job modeler (213) generates multiple sets of all possible multiple process parameters within the range of process parameter values ​​set by the user for at least one property value recorded in "Property" of the job script generated in step 20. Each set of values ​​of the multiple process parameters is a value of multiple process parameters of multiple experimental processes for obtaining at least one property value recorded in "Property" of the job script generated in step 20. Next, the job modeler (213) obtains multiple loss values ​​for multiple sets of values ​​of multiple process parameters by repeating the process of obtaining the loss of each set from the output of the surrogate model by inputting each set of values ​​of the multiple process parameters generated in this way into the surrogate model.

[0109] The resource management unit (22) periodically receives information of each module node (3) consisting of the amount of available resources, setting information of the experimental devices, and status information of the experimental devices used in the experimental process of each module performed by each module node (3) from each module node (3) through the packet receiving unit (28). The resource management unit (22) updates the amount of available resources, setting information, and status information of the experimental devices used in the experimental process of each module performed by each module node (3) according to the information of each module node (3) received periodically in this manner, thereby always managing the amount of available resources, setting information, and status information of all experimental devices as the latest information.

[0110] When the resource management unit (22) receives an instruction to update the information of each module node (3) from the job scheduler (21), it can request the information of each module node (3) to each module node (3). In this case, each module node (3) transmits the information of each module node (3) according to the request of the resource management unit (22), and the resource management unit (22) updates the information of each module node (3) according to the information of each module node (3) transmitted in this manner. When there is a request from the job scheduler (21), the task generation unit (23), and the task scheduler (24), the resource management unit (22) transmits the available resource amount, setting information, and status information of each experimental device to the job scheduler (21), the task generation unit (23), and the task scheduler (24).

[0111] The task generation unit (23) generates a plurality of task recipes corresponding to recipes of a plurality of unit processes of the experimental processes of each of the plurality of modules of each job object based on the process conditions presented by the model of each job object generated by the job scheduler (21), the process conditions fixed by the user among the information recorded in the process database of each job object, and the setting information of each experimental device updated by the resource management unit (22), for each of the plurality of modules of each job object. In this way, the task generation unit (23) generates a task recipe for each name of each task recorded in the process database of each job object. Here, the plurality of modules of each job object means a plurality of modules indicated by a plurality of module names recorded in the process database of each job object as a plurality of modules selected by each user for each job object.

[0112] The unit process corresponding to each task, which experimental device is used and through what procedure the experiment is performed, is stored in each module node (3) for each task name. Therefore, when the process conditions are determined for each task, execution of each task by each module node (3) becomes possible. For example, assuming that there is a job object that executes the "Batch Synthesis" → "UV-Vis" module, the task order of the "Batch Synthesis" module is recorded in the process database and has the order of "Add Solution" → "Heat" → "React". First, the information that must be recorded in the "Add Solution" task is the reagent name, reagent volume, reagent concentration, and reagent dispensing speed. The task generation unit (23) generates the task recipe of "Add Solution" by extracting the corresponding information from the process conditions suggested by the model of each job object and the process conditions fixed by the user among the information recorded in the process database of each job object.

[0113] The information to be recorded in the "Heat" task is the heating temperature. The task generation unit (23) generates the "Heat" task recipe by extracting the corresponding information from the process conditions suggested by the model of each job object and the process conditions fixed by the user among the process information recorded in the process database of each job object. The information to be recorded in the "React" task is the heating time. The task generation unit (23) generates the "React" task recipe by extracting the corresponding information from the process conditions suggested by the model of each job object and the process conditions fixed by the user among the information recorded in the process database of each job object.

[0114] The task sequence of the "UV-Vis" module is recorded in the process database, and has the sequence "PrepareSample" → "GetAbsorbance". First, the information to be recorded in the "Prepare Sample" task is the type and amount of the sample. The task generation unit (23) generates the task recipe of "Prepare Sample" by extracting the corresponding information from the process conditions suggested by the model of each job object and the process conditions fixed by the user among the information recorded in the process database of each job object. The information to be recorded in the "Get Absorbance" task is the measurement hyperparameter. The task generation unit (23) generates the task recipe of "Prepare Sample" by extracting the corresponding information from the process conditions suggested by the model of each job object and the process conditions fixed by the user among the information recorded in the process database of each job object.

[0115] The task scheduler (24) schedules the execution order of tasks based on the execution order of tasks for each module among the information recorded in the process database of each job object, and proceeds with or stops the execution of each task according to each of the plurality of task recipes generated for each of the plurality of modules of each job object based on the available resource amount and experimental device status information of at least one experimental device used in the experimental process of each of the plurality of modules of each job object. The task scheduler (24) determines whether to execute each of the plurality of task recipes generated by the task generation unit (23) for each job object generated by the job scheduler (21) based on the available resource amount and experimental device status information of each experimental device updated by the resource management unit (22).

[0116] The task scheduler (24) checks the status of at least one experimental device to be used for the module to be executed first among the multiple modules of each job object. If the status of at least one experimental device to be used for the module to be executed first among the multiple modules of a job object is abnormal, the task scheduler (24) temporarily suspends the execution of the job object. Otherwise, the task scheduler (24) checks the amount of available resources of at least one experimental device to be used for the module to be executed first among the multiple modules of each job object. An example of an abnormal status of an experimental device may be a failure of the experimental device.

[0117] As a result of checking the amount of available resources of at least one experimental device used for the module to be executed first among multiple modules of each job object, if the amount of available resources of at least one experimental device used for the module to be executed first among multiple modules of a job object is “0”, the task scheduler (24) temporarily suspends the execution of the job object. Here, suspension of the execution of a job object means suspension of the execution of all tasks of the multiple modules of the job object.

[0118] Otherwise, the task scheduler (24) checks whether the number of experiments to be executed in the job object is greater than the available resources of at least one experimental device to be used for the module to be executed first. If the number of experiments to be executed in the job object is less than the available resources of at least one experimental device to be used for the module to be executed first, the task of the module to be executed first is allocated the amount of resources that the task wants to consume among the available resources of the experimental device, and the execution of the task is determined.

[0119] If the number of experiments to be executed in the job object is greater than the available resources of at least one experimental device to be used for the module to be executed first, the task scheduler (24) performs the available resource amount comparison process as described above for each of at least one previously paused job object, and determines whether to execute the task recipe for each of at least one previously paused job object based on the result. The same process as described above is repeated for the next module to be executed after the module to be executed first among the multiple modules of the job object.

[0120] The action translation unit (25) determines multiple actions of at least one experimental device used in each task recipe based on the amount of resources of at least one experimental device allocated to each task determined to be executed by the task scheduler (24) and the process conditions recorded in the task recipe of each task determined to be executed by the task scheduler (24). The action of a certain experimental device means an action set based on the amount of resources allocated to each task and the process conditions recorded in the task recipe. In this way, the action translation unit (25) functions to translate the unit process of each task into multiple actions by dividing the unit process of each task into the actions of at least one experimental device used to execute each task.

[0121] For example, the task called "Add Solution" in the "Batch Synthesis" module is subdivided into three actions: pump initialization → solution dispenser movement → pump discharge. The task information and resources recorded in the task recipe are distributed to the three actions. The pump initialization action uses the pump address value from the experimental device setting value recorded in the "Add Solution" task recipe. Next, the solution dispenser movement action uses the location information regarding the amount of resources received from the resource management unit (22). Next, the pump discharge action uses the solution type, solution volume, solution concentration, and solution discharge speed values ​​recorded in the "AddSolution" task recipe. The process of extracting the information required to perform the action in the task recipe, i.e., the action information, is preset for each task and stored in each module node (3). As described above, each action information is determined based on the amount of resources allocated to each task and the process conditions recorded in the task recipe.

[0122] The action scheduler (26) schedules the execution order of multiple actions based on whether the same experimental device is used simultaneously during the execution of different job objects and whether the paths of different experimental devices overlap during the execution of different job objects. Here, the simultaneous execution of different job objects means that the experimental process of a certain module of a certain job object and the experimental process of a certain module of another job object are performed simultaneously. This situation can occur if the module to be executed first in a certain job object and the module to be executed first in another job object both satisfy the job object execution conditions without a large time difference. An example of a case where the paths of multiple different experimental devices overlap is a case where two robot arms collide with each other.

[0123] First, the action scheduler (26) receives the status of all experimental devices of a specific module containing the action to be currently executed from the resource management unit (22). Next, the action scheduler (26) identifies the experimental devices required to execute the action. Next, the action scheduler (26) checks whether the experimental devices identified in this manner and the currently operating experimental devices are the same or whether their paths overlap. If the experimental devices identified in this manner and the currently operating experimental devices are the same or their paths overlap, the action is temporarily suspended and waits until the problem is resolved. Otherwise, the information about the action is transmitted to the packet transmission unit (27). Each action information transmitted to the packet transmission unit (27) consists of a job ID, at least one experimental device name, each action name, each action information, and a mode type.

[0124] The packet transmission unit (27) collects at least one experimental device name, each action name, each action information, and mode type for each job ID from various action information received from the action scheduler (26). Then, the packet transmission unit (27) generates a plurality of packets including a combination of the job ID, at least one experimental device name, a plurality of action names, a plurality of action information, and a mode type, and transmits the plurality of packets generated in this way to each module node (3) via a network based on TCP / IP (Transmission Control Protocol / Internet Protocol) communication. The packet in the present embodiment means a packet having a TCP / IP format.

[0125] Each of the plurality of module nodes (3) receives a plurality of packets from the master node (2) through a network based on TCP / IP communication, and extracts a combination of a job ID, at least one experimental device name, a plurality of action names, a plurality of action information, and a mode type from the received packets. Here, the job ID is a job ID assigned to each job object, and the at least one experimental device name is a name of an experimental device used in the experimental process of each of the plurality of modules of each job object. The plurality of action names are a plurality of action names listed according to the execution order of a plurality of actions scheduled by the action scheduler (26), the plurality of action information is information for executing the plurality of actions, and the mode type indicates whether it corresponds to a virtual experiment or an actual experiment.

[0126] Among the plurality of module nodes A to H, a module node (3) that performs an experimental process of a module among the plurality of modules of each job object receives from the master node (2) a plurality of action names listed in the execution order of the plurality of actions for each task of the module and information for executing the actions corresponding to the plurality of action names, and executes the actions corresponding to the plurality of action names in the order in which the plurality of action names are listed according to the information for executing the actions corresponding to the plurality of action names, thereby performing the experimental process of the module.

[0127] When each of the plurality of module nodes (3) completes the execution of the experimental process of each module, it generates a combination of a plurality of process parameter values ​​used in the execution of the experimental process of each module and at least one material property value corresponding to the execution result of the experimental process of each module as the result of the execution of the experimental process of each module, and generates a plurality of packets including the combination of a plurality of process parameter values ​​and at least one material property value. Then, each of the plurality of module nodes (3) transmits the plurality of packets generated in this way to the master node (2) through a network based on TCP / IP communication. In addition, each of the plurality of module nodes (3) periodically transmits to the master node (2) information of each module node (3) consisting of the amount of available resources of each of at least one experimental devices used in the experimental process of each module performed by each module node (3), experimental device setting information, and experimental device status information using the TCP / IP packet communication.

[0128] The packet receiving unit (28) receives multiple packets from each module node (3) through a TCP / IP communication-based network, and extracts a combination of multiple process parameter values ​​and at least one material property value from the received packets, or extracts information of each module node (3) consisting of the available resource amount of each of at least one experimental device used in the experimental process of each module, experimental device setting information, and experimental device status information. The combination of multiple process parameter values ​​and at least one material property value is stored in the storage (29). The information of each module node (3) is transmitted to the resource management unit (22). The interface node (1) can output a combination of multiple process parameter values ​​and at least one material property value to the user, and the master node (2) can use this for learning a surrogate model.

[0129] Meanwhile, the laboratory operation method according to one embodiment of the present invention as described above can be written as a program executable on a computer processor, and can be implemented on a computer that records and executes the program on a computer-readable recording medium. The computer includes all types of computers that can execute programs, such as desktop computers, laptop computers, smartphones, and embedded computers. In addition, the structure of data used in one embodiment of the present invention as described above can be recorded on a computer-readable recording medium through various means. The computer-readable recording medium includes storage media such as RAM, ROM, SSD (Solid State Drive), magnetic storage media (e.g., floppy disks, hard disks, etc.), and optical reading media (e.g., CD-ROMs, DVDs, etc.).

[0130] The present invention has been described above, focusing on preferred embodiments thereof. Those skilled in the art will appreciate that the present invention can be implemented in modified forms without departing from its essential characteristics. Therefore, the disclosed embodiments should be considered illustrative rather than limiting. The scope of the present invention is set forth in the claims, not the foregoing description, and all differences within the scope equivalent thereto should be construed as being encompassed by the present invention.< / modetype> < / filename> < / modetype> < / filename> < / modetype> < / filename> < / modetype> < / filename>

Claims

1. An interface node that generates a job script in which the names of each of the multiple modules selected by the user are recorded among the multiple unit processes performed in the laboratory and modularized into each experimental process; A master node that generates a plurality of job objects corresponding to the plurality of job scripts from a plurality of job scripts including the generated job scripts and schedules the execution order of the plurality of generated job objects; and A laboratory operation system characterized in that it includes a plurality of module nodes that perform the experimental processes of each of the plurality of modules for each job object based on the process conditions of the experimental processes of each of the plurality of modules presented by each job object according to the execution order of the plurality of job objects.

2. In paragraph 1, A laboratory operation system characterized in that the master node schedules the execution order of the plurality of job objects created based on the amount of available resources of at least one experimental device used in the experimental process of the module to be executed first among the plurality of modules of each job object.

3. In paragraph 2, A laboratory operation system characterized in that the master node schedules the execution order of the plurality of generated job objects in the order in which the plurality of generated job objects satisfy the conditions for the amount of available resources of each of at least one experimental device used in the experimental process of the module to be executed first.

4. In paragraph 3, A laboratory operation system characterized in that the master node schedules the execution order of the plurality of generated job objects in the order in which the plurality of generated job objects satisfy the conditions of the amount of available resources of each of at least one experimental device used in the experimental process of the module to be executed first and whether the module to be executed first possesses a task that causes a bottleneck.

5. In paragraph 3, The above masternode is A job scheduler is included that schedules the execution order of the plurality of job objects created by repeating the process of storing a plurality of job IDs assigned to the plurality of job objects in a waiting queue according to the creation order of the plurality of job objects, and moving and storing the job ID that first satisfies the condition for the amount of available resources of at least one experimental device used in the module to be executed first among the plurality of job IDs stored in the waiting queue to an executing queue. A laboratory operation system, characterized in that at least one job object to which at least one job ID stored in the execution queue is assigned is executed in the order in which the at least one job ID is stored in the execution queue.

6. In paragraph 5, The above job scheduler A laboratory operation system characterized in that it includes a job trigger that schedules the execution order of the plurality of generated job objects by repeating the process of moving and storing, in the execution queue, the job ID that first satisfies the conditions of the amount of available resources of at least one experimental device used for the module to be executed first and whether the module to be executed first owns a task causing a bottleneck among the plurality of job IDs stored in the waiting queue.

7. In paragraph 5, A resource management unit further includes a resource management unit that receives information of each module node including the amount of available resources of at least one experimental device used in the experimental process of each module performed by each module node from each module node, and updates the amount of available resources of at least one experimental device used in the experimental process of each module performed by each module node according to the received information of each module node. A laboratory operation system characterized in that the job scheduler reads the available resource amount of at least one experimental device used for the module to be executed first from the information of each module node updated by the resource management unit, and repeats the process of moving and storing the job ID that first satisfies the condition for the read available resource amount to the execution queue.

8. In paragraph 1, The above interface node selects a model that presents the process conditions of each experimental process of the selected plurality of modules according to information entered by the user, and generates a job script in which the process conditions of each experimental process according to the selected model are recorded. A laboratory operation system characterized in that the master node creates a job object including the selected model, and determines the process conditions of the experimental process of each of the plurality of modules presented by the model included in the created job object as the process conditions of the experimental process of each of the plurality of modules of the created job object.

9. In paragraph 8, A laboratory operation system characterized in that the master node determines the values ​​of multiple process parameters of each experimental process recorded in the generated job script as the values ​​of multiple process parameters of each experimental process of the selected plurality of modules, if the selected model is a manual model that manually determines the process conditions of each experimental process of the selected plurality of modules and presents the manually determined process conditions.

10. In paragraph 8, A laboratory operation system characterized in that the master node automatically determines the process conditions of the experimental processes of each of the selected plurality of modules, and if the selected model is an automatic model that presents the automatically determined process conditions, determines the values ​​of the plurality of process parameters of each experimental process predicted by the artificial intelligence model corresponding to the automatic model as the values ​​of the plurality of process parameters of the experimental processes of each of the selected plurality of modules.

11. In paragraph 10, The above masternode is A job scheduler that generates a job object including the generated model and the process database by generating the selected model and generating a process database in which information representing the experimental process of each of the selected plurality of modules is recorded, A laboratory operation system characterized in that the information representing the experimental process of each of the plurality of selected modules includes the execution order of the plurality of modules according to information input by the user and the execution order of the plurality of tasks for each module.

12. In paragraph 11, The above masternode is A task generation unit that generates a plurality of task recipes corresponding to recipes of a plurality of unit processes corresponding to the experimental processes of each of the plurality of selected modules, based on the process conditions presented by the model of the generated job object and the information recorded in the process database of the generated job object; and A laboratory operation system further comprising a task scheduler that starts or stops the execution of a unit process according to each of a plurality of task recipes generated for each of the plurality of selected modules according to the amount of available resources of at least one experimental device used in the experimental process of each of the plurality of selected modules.

13. In paragraph 12, The above masternode is A task generation unit that generates a task recipe corresponding to each recipe of each of the plurality of unit processes of the experimental process of each of the selected plurality of modules for each of the plurality of tasks of each module based on the process conditions presented by the model of the generated job object and the information recorded in the process database of the generated job object; and A laboratory operation system further comprising a task scheduler that determines execution or suspension of each task according to each of a plurality of task recipes generated for each of the plurality of selected modules according to the amount of available resources of at least one experimental device used in the experimental process of each of the plurality of selected modules.

14. In paragraph 13, The above masternode is An action translation unit that determines multiple actions of at least one experimental device used for each task recipe based on the resource amount of at least one experimental device allocated to each task determined by the above execution and the process conditions recorded in the task recipe of each task determined by the above execution; and A laboratory operation system further comprising an action scheduler that schedules the execution order of the determined plurality of actions depending on whether the same experimental device is used simultaneously during the execution of different job objects.

15. In paragraph 14, A laboratory operation system characterized in that one module node performing an experimental process of one of the plurality of modules of each job object among the plurality of module nodes receives from the master node a plurality of action names listed in the execution order of the plurality of actions for each task of the one module and information for executing actions corresponding to the plurality of action names, and performs the experimental process of the one module by executing actions corresponding to the plurality of action names in the order in which the plurality of action names are listed according to the information for executing the actions corresponding to the plurality of action names.

16. A step of generating a job script in which the names of each of the multiple modules selected by the user among the multiple modules modularized into each experimental process by collecting multiple unit processes performed in the laboratory are recorded; A step of generating a plurality of job objects corresponding to the plurality of job scripts from a plurality of job scripts including the generated job scripts and scheduling the execution order of the plurality of generated job objects; and A laboratory operation method characterized by including a step of performing an experimental process of each of the plurality of modules for each job object based on the process conditions of the experimental process of each of the plurality of modules presented by each job object according to the execution order of the plurality of job objects.

17. A computer-readable recording medium recording a program for executing the method of Article 16 on a computer.

Images