Abstract
Today, the automation of pharmaceutical labs has become increasingly important due to more complex drug discovery techniques. While it substantially improves the drug discovery process, most robotics systems still require manual tuning by a pharmaceutical researcher. These robotics systems contain a controller, which manages workflow by using a simple procedural programming language and a simple scheduler.
At ReTiSoft we believe that these robotics systems should be seamlessly modified to accept declarative specifications from a pharmaceutical researcher, in particular, the robotics systems should only be notified about the microplate processing time at each station. In this paper, we will describe the limitations of current pharmaceutical robotics systems. Then, we will define a computational model of the problem, and introduce the architectural design of our “declarative” robotics system simulator. Finally, Section 4 outlines the inherent benefits of our research.
MOTIVATIONS
Recent literature [CL96] indicates that pharmaceutical Research and Development (R&D) investments are constantly increasing despite escalating costs, shorter product cycles and concerns over health care cost containment. Companies recognize that highly productive research processes and customer driven R&D allow them to remain competitive in this fast-paced market. In particular, the use of computers and automation in drug discovery has become increasingly important due to more complex drug discovery techniques [D92], [M96]. While it substantially improves the drug discovery process, most robotics systems still require manual tuning by a pharmaceutical researcher in order to optimize the processing of an assay. Not only does this manual tuning require a lot of trials, but it also blurs the boundary between positive and negative trials.
Existing robotics systems contain a system controller which manages their workflow by using a simple scheduler and a simple procedural laboratory language. The scheduler is focused on maintaining a uniform sample history during drug discovery. For example, it will always move a robot to the closest station which contains a microplate ready to be moved forward. However, the scheduler does not anticipate “better moves” which can lead to reduced processing time for each assay. For example, it may be better for the robot to wait at the current station for the microplate's processing to finish rather than travel to another station to move its microplate forward. Also, current robotics systems do not verify the number of microplates allowed at each station, thus leaving this task to the researcher performing an assay. Additionally, the researcher is burdened with the tedious task of specifying an assay using a procedural laboratory language.
We believe that these robotics systems should accept declarative specifications from the pharmaceutical researcher. In particular, they should only be notified about the microplate's processing time at each station and other external environmental factors, such as robot speed, distance between microplate processing stations, etc. These kinds of specifications along with a suitable scheduler would produce significant improvements in assay processing time.
COMPUTATIONAL MODEL
To characterize the problem domain, we define a computational model which allows us to achieve the above mentioned goals. We define an assay as the process of fetching all of the microplates from an input carousel, placing them on subsequent stations, processing them on these stations, and finally depositing the microplates on an output carousel. The term workcell is used to describe the environment required for the development of an assay; that is robot travelling speed, distances between stations, number of microplates, and microplate processing time at each station [Del97].
The following assumptions are made about the workcell configurations allowed by our robotics system simulator:
The input carousel, processing stations and output carousel are placed along a straight line in a well defined order.
Each station can process only one microplate at a time, but it can hold up to ‘k’ microplates.
All of the microplates used in an assay are the same size and are subjected to the same processing procedure at a particular station.
The tending robot may move with two speeds; a slower speed with a microplate and a faster speed with no microplate.
Given the above assumptions, we optimized the robotics system scheduler by minimizing the end-to-end processing time of an assay.
SOFTWARE ARCHITECTURE
Based on the limitations of current robotics systems, presented in Section 1, and the computational model, defined in Section 2, we developed a “declarative” robotics system simulator with an optimized scheduler. In this section, we will give a brief overview of the high level architectural design (see Figure 1) of our simulator and show how it can be seamlessly integrated with existing robotics systems.
Simulator Architectural Design The above system architecture shows four subsystems: Abstract Data Types (ADT), Schedule Optimizer (SO), Schedule Translator (ST), and Graphical User Interface (GUI). The ADT subsystem provides required data structure operations to the SO subsystem, which determines optimized robot movements according to workcell parameter values. The GUI handles input from the pharmaceutical researcher through the GUI facade and initiates a corresponding operation through the GUI handler. These two modules separate the applications logic from the GUI details [NP97]. With the help of the GUI the pharmaceutical researcher may select the optimization method to be used by the scheduler, start/stop the optimization algorithm, provide declarative specifications of a drug discovery process and start/stop the drug discovery simulation. To seamlessly integrate our robotics system simulator with current robotics systems, our architecture includes the ST subsystem which accepts an optimized schedule from the GUI handler and feeds a specific laboratory language to the system controller.
The scheduler and GUI were written in Java and compiled under the Linux Operating System (OS) with version 1.1.8 of the Java compiler. The simulator has also been tested in Macintosh and Windows NT environments.
CONCLUDING REMARKS
In this paper, we proposed a declarative method for specifying robot operations in laboratory robotics systems. We argued that the pharmaceutical researcher should specify “what” needs to be done, instead of specifying “how” an assay should be produced, in this way no human involvement, such as manual performance tuning, during the development of an assay is required. The following are some of the benefits of our “declarative” approach to specifying assay processing with pharmaceutical robotics systems. Note that all of these features, except connectivity to assay protocol databases, have been implemented in the software prototype of our robotics system simulator:
Declarative assay specifications
A 25–35% improvement in the processing time of an assay over current pharmaceutical schedulers
No need for manual robot tuning
Makes laboratory automation possible without extensive re-training of researchers
Enables connectivity to assay protocol databases
Eenables assay protocol experimentation by varying stations processing times
Embedded safety routines
Possibility of monitoring optimized robot movements before an assay begins
Seamless integration of the optimized scheduler into existing robotics systems
We are very encouraged with our results and believe that our work is an important step in the incorporation of declarative specifications within existing laboratory robotics systems.