Intelligent Robots-The Next Step in Laboratory Automation - American

Northfield, MN 55057. The Next. Step in. Laboratory. Automation. A/C INTERFACE. Laboratory robotics had its originsin devices constructed to perform s...
1 downloads 0 Views 13MB Size
SET A TUBE ÏK.INDEX = 1 GOÎ 'GETTUBE.SUB FILL' TUBE WITH REAGENT l ?YR.N = "C" SOL.VOL: GOSUBADDSOL.: SOLUTION Ml)

Intelligent Robots The Next Step in Laboratory Automation

T. L. Isenhour and S. E. Eckert Department of Chemistry Kansas State University Manhattan, KS 66506

J. C. Marshall

Department of Chemistry St. Olaf College Northfield, MN 55057

Laboratory robotics had its origins in devices constructed to perform specific and generally invariant mechanical tasks in the laboratory. Examples of laboratory automation are well known and include automatic titrators, sample collectors, and autoanalyzers. These devices will always have a place in the analytical laboratory, because they can be optimized for a specific repetitive task. But automated devices are limited and can perform only those specific tasks for which they were designed. With the advent of inexpensive microelectronics and microcomputers, it is now possible to build flexible automated devices. These developments have led to programmable laboratory automation devices, which we now call robots. Programmable laboratory robots can be taught to perform a series of tasks within the domain of their mechanical capabilities. The use of such devices is having a major impact on how we perform routine laboratory procedures. The programmable robot of today, like its early electromechanical counterpart, is usually dedicated to a single task. Detailed programming is required for even the simplest of tasks. No laboratory robot can yet carry out an order such as "Titrate three 25-mL aliquots of the sample with HC1," an instruction that we would expect a laboratory technician to perform without supervision. Programming a robot to perform even a common task (such as a titration) requires hundreds of steps and may take days or even weeks to perfect. 0003-2700/89/0361-805A/$01.50/0 © 1989 American Chemical Society

lytical laboratory environment. Another important step in laboratory automation will be achieved when standard chemical procedures, written in natural language, can be parsed into unit laboratory operations. Unit operations could then be selected and translated by an expert system to produce a set of primitive instructions for a laboratory robot. The combination of expert systems and robotics has the potential to perform an order such as "Titrate three 25-mL aliquots of the sample with H O . " In this article we will summarize our recent work related to the development of the Analytical Director. The Analytical Director project seeks to combine laboratory robots with expert system control programs that have a knowl-

A/C I N T E R F A C E We believe that the next step in bringing the laboratory robot to its full potential will require control programs that use artificial intelligence. Expert systems, knowledge-based systems that can effectively represent and apply factual knowledge in specific areas of human expertise, seem ideally suited to the supervision of a robot. A laboratory robot under expert system supervision would be able to carry out the functions of a human expert in the ana-

edge base about analytical chemistry and the ability to use that knowledge.

The laws of robotics The robot is revolutionizing laboratory work, particularly in high-volume industrial analytical labs. Increases in sample volume, reliability, and efficiency are well documented. However, there are several problems that anyone contemplating using laboratory robots should consider. In our work on the An-

ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989 · 805 A

A/C

INTERFACE

alytical Director project, we examined some of these problems by using a robot to perform the classical inorganic qualitative analysis scheme. This study resulted in some purposely overstated "laws" of laboratory robotics. 1. It will take a laboratory robot much longer to perform any nonroutine, complicated task than it would a skilled technician. In our initial study of laboratory robotics we critically examined the difficulties in performing the classical qualitative analysis scheme with a Zymate laboratory robot (Zymark Corp., Hopkinton, MA). The time required for the analysis of two Group I samples was about 4 h. Because a manual implementation of this analysis requires much less time to perform, we studied ways to minimize the time required by a laboratory robot. In general, the ability of robot manipulators to perform complex multistep procedures in a cost-effective way will depend on the availability of effective general strategies for optimization. Some of the problems that make optimization difficult are inherent in the design of the Zymate system used in this work. The Zymate robotic arm moves through a series of operator-defined absolute positions. Because the movement is from absolute position to absolute position, the controller does not "know" where the arm is between positions. Time is wasted in moving to "safe positions" to avoid collisions with other objects in the work space. Another factor in the Zymate design that must be considered is the servo motor control of the arm. The three servo motors operating the motions of the arm (in/out, up/down, and rotation) run at fixed speeds. The first two motions are fast, whereas the rotation is quite slow. Thus fixed stations on the table that are frequently used together should be as close as possible. As seen in Figure 1, this is difficult to do with a large number of stations. Some steps in complicated procedures require a great deal of programming. Very often these are actions that technicians, as parallel processors, do easily and quickly. A good example is the complete dissolution of a precipitate. Typically, instructions to a human technician are: Check the test tube for the presence of a precipitate; if a precipitate is present, shake the tube to see if it will dissolve; if it does not dissolve, continue adding reagent and shaking until the precipitate is gone. (A technician may even decide to heat the tube for dissolution.) Many of these steps may be performed by a technician almost simultaneously; but for the robot, each step must be performed

separately. It must pick up the tube, move to the detector, and check for any precipitate. If a precipitate is detected, the robot would then add the reagent, move the tube to the vortex mixer, stir the solution, and then place the tube in the centrifuge. After centrifugation, the robot must return to the precipitate detector and check for remaining solid. If present, the procedure must be repeated. If heating is an option, that must also be included in the program along with the criterion for performing that option. At any time during the procedure, a technician can stop when the precipitate is dissolved. For the robot, this procedure will terminate only at points where the check for a precipitate has been programmed. For different samples, this could be at different points. Frequently, some modifications of the analysis procedure are necessary, because procedures that are designed for humans are not generally optimum for robot manipulation. For example, a modification was necessary to separate the mercurous cation in Group I. Although the procedure requires a complete separation of the lead and silver from the mercury, this is not absolutely necessary for a technician. After addition of NH 4 OH to the residue (possibly containing AgCl, Hg2Cl2, and residual P b C y , the resulting solution should contain all the silver and any residue should contain all the mercury. A white residue could indicate incomplete separation of lead and/or silver; a technician could confirm this by noting the color of the precipitate, but the precipitate detector used in this work cannot distinguish between a white precipitate and a black one, so the best solution to this problem is to separate the cations completely. Residue is washed at each precipitation step, and more reagent is added when needed. These extra steps increased the time required for analysis significantly. The decision must also be made whether to perform operations in series or in parallel. Humans usually operate in parallel, executing the same step on several samples at a time. In some cases, the robot also does best working in parallel. For example, the same reagent can be added to several samples at the same time; if the robot has to change hands to add the reagent, this is certainly the best strategy. However, if the reagent were to be added from a fixed solvent delivery station, the samples might best be processed one at a time, in a serial manner. Parallel programming, whether of samples or of entire tests, increases efficiency in some cases, but loss of versatility makes it less efficient in other

806 A · ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989

cases. For example, in the case of a group of cations, confirmation tests were left until the very end. Once all the cations were separated, the proper reagent was added to each tube. The solutions were mixed, centrifuged, and checked for the confirming precipitate, and the results stored as an array for further reference. Although this procedure was efficient in cases when a majority of the ions were present, it did not allow for the efficient handling of a sample that was, for example, pure water. Finding the optimum combination of parallel and serial operation is a difficult problem. 2. When a laboratory robot is left to function unattended for a long period of time, something disastrous will happen almost immediately after the last observer leaves. The long-term reliability of any multistep procedure is likely to be low unless extreme care is taken to ensure almost perfect reliability for each step. If, for example, a procedure contains 100 steps and the reliability of each step is 99%, the probability of one or more failures in the procedure is more than 60%. Even if the reliability of each of the 100 steps is 99.99%, there is still about a 1% chance of failure. Furthermore, such failures not only could result in the loss of a single sample, but could create some condition in the robot's environment that would cause all subsequent procedures to fail until corrective action was taken. There are few sights more pathetic than a laboratory robot, its work space awash with spilled solvents and littered with broken containers, moving empty-handed yet faithfully about its appointed tasks. 3. A gross of supposedly identical containers to be used in a robotic procedure will come in 144 unique configurations. In normal laboratory operations, small variations in the size and shape of containers is not a problem. In multistep continuous robotics procedures, however, nearly perfect uniformity of containers is required. During our preliminary investigation using the qualitative analysis scheme, the detection of precipitates proved troublesome. The photodiode sensor was capable of determining the presence of large amounts of precipitate but had much more difficulty in detecting small amounts of crystalline precipitate. This problem was primarily caused by the inconsistency of the thickness of the sample tubes, especially the thickness of the bottoms. It was therefore necessary to compare the value of the readings at several positions on each tube rather than only at the center and the bottom. The size problem is also

A/C

INTERFACE

manifested by containers not being picked up, solvent delivery errors, and capping station failures. Although most problems resulting from nonuniform container size can be solved by checks built into the control program, the amount of time required for these checks can substantially increase the time required to perform a procedure. 4. The item needed for the next step in the procedure is always on the other side of the robot's environment. Space utilization in robotics procedures is very important. A typical fixed-base laboratory robot must arrange everything in a highly constricted work space. For example, the Zymate robot operates in a cylindrical work space constrained by a 60-cm reach and a 56-cm elevation, with the center of this cylinder occupied by the robot itself. In a laboratory of rectangular work spaces and rectangular instruments, the robot is an anomaly. Great care must be given to the placement and grouping of the apparatus in this limited space to ensure the minimum amount of wasted motion as the robot moves from station to station. Unfortunately, the most efficient arrangement of equipment is likely to vary with each procedure. As procedures become more and more complex, the space allocation problem becomes more and more difficult and in some instances impossible to solve without additional hardware. This problem has led to the development of trackmounted robots and dynamically allocated work spaces. An alternative strategy is to use multiple robots that can pass materials and samples back and forth. Kramer and Fuchs (1) have described what is perhaps the most novel implementation of robot-torobot communication—a computercontrolled toy train. Although the above laws have purposely overstated the difficulties inherent in laboratory robotics, the successful automation of any procedure requires careful development and extensive testing. The Analytical Director project The Analytical Director project is a major effort in our laboratory. The goal is to build a system to control laboratory robots that can design, test, and implement their own analytical procedures. A primary emphasis of this work is to use expert system techniques to store chemical information and to make decisions based on this information. The initial step in the Analytical Director project was to design a flexible robot control language. Analytical Ro-

bot Telecommunications Software (ARTS) (2) was developed to give the research scientist flexible and adaptive control of laboratory robots and instruments and to allow direct control of the robot and its resources with an expert system. As a stand-alone program, ARTS is a complete laboratory control language that can interpret commands in either interactive or batch modes. ARTS can also be an extension of other software in either a master or a slave mode. As master, ARTS can call on other software to perform certain tasks; in the slave mode, it can act as a sensory extension of the calling software that is envisioned to be an expert system. The ARTS interpreter is written in the C programming language and uses Reverse Polish notation. A set of commands that is specific to the ARTS environment is given in Table I. The most nonstandard command is the EVAL command, which allows a string (or string variable) received from an external source (or generated in ARTS) to be executed. The EVAL command provides adaptive programming capabilities. The LDEF command can be used to load a file containing system defaults. ARTS loads a default file when it is first executed but

Table I.

allows a different default file to be loaded at any time. The SDEF command saves the current defaults to a disk file. The ECHO command is used to turn on or off the echoing of routine commands on screen as they are being executed. The ASSIST command is a debugging tool for communication between ARTS and laboratory instruments; it can be used to echo the values sent on the communication lines to ensure that proper formats are being used. The QUIT command can be executed in batch or interactive mode to return to the operating system. Alternatively, the F5 key can be used in interactive mode to exit ARTS. The F l key is used to toggle the display of the mnemonic command menu on the upper portion of the screen. When the menu is present, a command can be highlighted by using the arrows, page up, page down, home, and end keys. Once highlighted, the command can be placed on the command line by pressing the F4 key. The F6 key can be used to produce a stream-oriented file. Values typed in or extracted from the mnemonic menu are directed to a specified file. The file is closed the second time the F6 key is pressed; the resulting file can then be executed as a routine.

Commands used in ARTS

Operating System Commands CD COPY DEL DIR EDIT REN

Changes default drives and/or directory; can also be used to display current drive and directory Copies a disk file to a different disk file Deletes disk file(s) Lists directory Invokes a user-specified editor Renames a disk file

Memory Management Commands DEF DEFS DISP ERA

Defines numeric variables Defines string variables Displays all variables in memory Erases variables from memory storage

Additional ARTS Commands and Function Keys EVAL SDEF LDEF ECHO ASSIST QUIT F1 F2 F4 F5 F6 F9 F10

Executes a string or variable containing string Saves default values to a disk file Loads default values from a disk file Toggles echo of subroutine command lines Displays activity on communication lines Returns control to operating system Displays mnemonic commands Activates DOS shell Accesses highlighted mnemonic command Leaves ARTS (same function as QUIT) Creates a stream-oriented file Accesses default values Interrupts active routines

808 A · ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989

The F9 key is used to gain access to a series of menus to set system and instrumental defaults. The F10 key is used to interrupt execution of a routine. Once the F10 key is pressed, a message is displayed on the screen, and the user can stop the execution of the routine, step one line at a time through the routine, enter a series of commands, or continue the execution of the current routine. Instrument commands fall into four categories: those that send parameters to instruments, those that receive data from instruments, those that send parameters and receive data, and those that cause the instrument to perform an action. Table II contains some characteristic examples of these categories. Commands in the first category can be used to pass information, such as the grip tension for a robot hand or the parameters needed to collect a spectrum. The second category is used when instruments return data that can be used in conditional statements or, as in the examples, stored in variables for later use. The first example of this category shows how the weight of a sample is returned by a balance and stored as the first entry of array WEIGHT. The second of these examples stores the number of scans for a spectrum in the variable MEASUREMENTS. Combinations of the previous two commands are shown in the third category of commands. In the first example of this type, the time is returned from clock 4 and stored in the variable T I M E , whereas in the second example, the absorbance value at 750 nm is stored in the variable ABSORBANCE. The last category of commands only requires that the command be sent to the instrument; the examples in this category show commands that control a syringe station, MLS, and collect a reference spectrum on a spectrophotometer, REFERENCE. Information about the number of parameters to be sent, the direction of data transfer, and the instrument to which the command is to be sent is required to communicate with any laboratory instrument. The variety of commands implemented by ARTS allows the user to exploit the full power of a microcomputer to control laboratory equipment. ARTS is capable of controlling any type of programmable laboratory instrument or robot, although it was originally used to control a Zymate I robot. Control is implemented using RS 232 communication links between the microcomputer and the laboratory instruments. The methods of communicating with different instruments vary with the manufacturer; for this reason, a menu is used to define the communica-

Table II. Instrument commands Commands that send parameters GRIP = 100 MEASURE 1,0, 0,0 Commands that receive data WEIGHT (1) = WEIGH MEASUREMENTS = NMEAS Commands that send parameters and receive data TIME = CLOCK (4) ABSORBANCE = VALUE (750) Commands that perform an action MLS REFERENCE

tion protocol necessary for each instrument. Parameters such as baud rate and parity must be specified, stored in a file, and used to control communication with the instruments. A robot is operated as just another instrument in the system. Some commercial laboratory robots use predefined positions in their normal operations; these positions are defined by using a teaching method supplied with the robot. During the teaching process, the robot is positioned at a point in its field of influence. The user supplies this position with an ASCII name, which is used to access it. These position names, along with other robot control commands, can be grouped into routines to perform tasks such as picking up a test tube. Line numbers are only used when needed for a GOTO statement. Routines can be combined to perform complete analyses. To facilitate communication with instruments, a look-up table is used. The table allows the user to give a simple mnemonic definition to a complex sequence of commands that contain the number of parameters to be sent, the direction of data transfer, and the communication port to use for the instrument. In addition to simplifying commands, this method also allows the program to check for the proper number and type of parameters to be sent. The error checking of incorrect argument lists helps the user in debugging experimental procedures. As a convenience, a menu with a list of command mnemonics can be displayed at the top of the screen. Along with the command, the communication port is displayed to show to which instrument the command is directed.

The mnemonic definitions are stored in an ASCII file in the format: MNEMONIC, COMMUNICATION PORT, NUMBER OF ARGUMENTS, ARGUMENTS Each mnemonic definition takes one line of the file. The argument list is used to notify ARTS of the direction of communication (to or from the instrument) and the type of argument (string, floating point number, integer, array of strings, array of floating point numbers, or array of integers). If the argument is a valid string or number, it is sent to the instrument, as follows: MLS, 1,1, 301 In this example, the mnemonic MLS is used to send one parameter, 301, to a robot using communication port 1. If data are to be returned from an instrument, the argument consists of a " ? " followed by a one-letter specifier (F— floating point, D—integer, S—string, AS—array of strings, AF—array of floats, or AD—array of integers) to determine the type of data returned from the instrument. The following entry NMEAS, 2, 2, NMEAS, ?D is used to send one argument, NMEAS, to a spectrophotometer and to receive data from the spectrophotometer using communication port 2. The data from the instrument are evaluated as integers. When the type consists of an array, the number of members immediately precedes AS, AD, or AF. For commands that need to have parameters evaluated during execution, a "*" precedes the type description. One such command is GRIP, for which the grip tension follows the mnemonic name. The file entry would be GRIP, 1, 2,100, *F wherein two arguments are to be sent to the robot through communication port 1. The first argument is a 100 and is used by the robot to issue a grip command. The robot expects a second argument to be sent specifying the tension of the grip; this parameter is evaluated by ARTS as a floating point number. A final example of the four types of commands given in Table II consists of sending a command and a parameter and then receiving data from the instrument, as in: VALUE, 2, 3, VALUE, *D, ?F When the "VALUE(750)" is issued in the ARTS program, the string "VALUE" is sent to a spectrophotometer. The 750, representing the wavelength in nanometers, is evaluated as an integer and is transmitted. The transmission of these commands causes the

ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989 · 809 A

A/C

INTERFACE User interface and system controller

Control instruments Experimental conditions

Analyze standards and unknowns

Figure 2. Hierarchy of the complexometric expert system.

Figure 1. Layout of laboratory robot system.

spectrophotometer to return the absorbance at 750 nm to ARTS. The data received are evaluated as floating point numbers. The mnemonic definitions allow ARTS to communicate with laboratory instruments and to notify the user when an incorrect number of parameters has been entered. The ability of ARTS to work in conjunction with external software increases the versatility of laboratory control. The researcher is no longer limited by the instrument control software, because external software can be incorporated into ARTS. The artificial intelligence driven robotic system

The next step in the Analytical Director project is to introduce artificial intelligence supervision. We have demonstrated the automation of a complexometric titration using an expert system control program (3). The layout for the laboratory robot system is shown in Figure 1, and the outline of the expert system is shown in Figure 2. The top-level program contains the user interface and controls the execution of the subsystems that determine the appropriate experimental conditions, control analytical instrumentation, and analyze standards and unknowns. Communication between the user and the expert system is accomplished through menus and queries. The user can describe the sample to be analyzed, including potential interferences, by choosing the appropriate responses from the menus. Any additional infor-

mation required to perform the titration is sought by the expert system in the knowledge base. Information determined by the expert system to be necessary, but not available from either user input or from the knowledge base, will generate queries to the user for such information. Information acquired in this fashion will automatically be added to the system knowledge base for future use. An analysis problem is processed by first determining whether the same problem has been solved previously. If a solution exists, the experimental conditions are recalled and used. If the problem has not previously been encountered, a set of heuristic rules based on conditional stability constants is used to limit the set of possible solutions. From the constrained set of solutions, one possible solution is extracted. The system will then check a file of past experiments to determine if the chosen solution previously failed to produce adequate results. If so, an alternate solution is sought. Any unverified experimental conditions are tested against standard solutions prior to the titrations. Thus it is feasible to design and carry out a rather complex analytical procedure using a laboratory robot under expert system supervision. The decisions made are based on chemical theory, data collected from actual experiments, and user input. The ability of the user to set experimental parameters allows the expert system to learn from instruction. Because the expert system keeps a record of past experi-

810 A · ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989

ments, it is able to learn as the system is used. This expert system was designed to perform direct complexometric titrations. With modifications, various other types of titrations—including stepwise, indirect, and replacement—could be incorporated. Knowledge collected by an expert system can easily be transferred to a different expert system, thus allowing almost instantaneous teaching. The system can also be used to teach humans by displaying experimental conditions to the user. Since all data collected by the system are archived, procedures that once were rarely used are now routine. Temporal optimization of robots

The automation of complex procedures envisioned in the Analytical Director project requires consideration of both task scheduling and resource allocation. Most laboratory procedures can be broken down into a series of tasks. Each task requires certain resources, reagents, equipment, instruments, or personnel. The order in which the tasks are completed is important, because it will affect the overall completion time of the procedure. Scheduling, queuing, and network theories have been devised to maximize the efficiency of one or more procedures by sequencing tasks and allocating resources (4-6). Programming robotic systems to run laboratory procedures efficiently is both tedious and time-consuming. Furthermore, robot systems are expensive. As a consequence, once an effective robot program is obtained, the programmer is often reluctant to modify it. For variable or one-of-a-kind procedures, the time required to program laboratory robotic systems will likely exceed the time required for the chemist to do the procedure manually. For this reason, current robot applications in the laboratory are usually limited to nonvarying procedures repetitiously applied to a large number of samples.

Variable robotic procedures would be feasible if efficient robot programs could be developed rapidly. The Temporal Optimizer of Robotic Task Sequences (TORTS) expert system has been developed as a programming aid for versatile and facile robot program development (7, 8). An advantage of the TORTS system is that a programmer can quickly evaluate a robotic program configuration on a computer without using the actual robotic system. For variable robotic programs t h a t execute different procedures based on test results acquired at run time, each procedure may be optimized separately. The TORTS system was devised to maximize the productivity of a laboratory procedure, shorten the robotic program development time, and acquire knowledge of robotic systems. This expert system is a critical step in the development of the Analytical Director project (9). The robotic system paradigm

The optimization of complex robotic procedures is a formidable problem. The TORTS system will generate robot task schedules for which no constraints are violated, and the start and finish times are predicted for each task. Many task schedules can thus be evaluated, because computer simulation is much faster than running and timing robotic procedures. The best task schedule can be defined as the one producing the shortest project completion time. Cases may arise for which other constraints must be met at the cost of longer completion times. For this discussion, a useful definition of a task is the generalized subrou-

Table III. Section of a robotic program written in ARTS REM R E M * * * GET A TUBE REM RACK.INDEX = 1 GOSUB GETTUBE.SUB REM REM * * * FILL TUBE WITH REAGENT REM SYR.N = " C " SOL.VOL = 3.0 GOSUB ADDSOL.SUB REM REM * * * MIX SOLUTION REM MIXTIME = 120 GOSUB MIX.SUB REM

tine, which in turn may be a collection of subroutines. A robot may be easily programmed to handle diverse laboratory procedures if a generalized set of subroutines is built. Table III contains a section of a robotic program written in the ARTS control language (2). Table IV is an example of a generalized subroutine to mix a solution in a tube for a specified amount of time. The generalized subroutines are customized for a specific need by setting global variables in the main program. The global variable, MIXTIME, in Table III and Table IV specifies the time the vortex mixer is to run. If a robot control module could direct and queue robot commands to more than one module, tasks could be executed simultaneously. Most laboratory robotic control systems allow only one module to be controlled at a time; commands cannot be sent and queued at each module. Instead, the programmer is required to merge commands manually to execute tasks concurrently. TORTS allows multiple-task optimization in anticipation of robots that will allow true task concurrency. The TORTS system requires the user to specify task and orientation times and, optionally, lock times and timing constraints. The task times will

Table IV. Generalized subroutine REM MIX. SUB REM REM * * * ROUTINE TO PLACE A TUBE IN VORTEX, MIX, AND REMOVE TUBE REM IF FREE (MIXTIME) THEN MIXTIME = 15 REM REM * * * PLACE TUBE IN VORTEX REM CLEAR. VORTEX OVER.VORTEX IN.VORTEX REM REM * * * RELEASE THE TUBE REM GRIP = 120 REM VORTEX.ON SLEEP (MIXTIME) VORTEX.OFF REM REM * * * REMOVE TUBE FROM VORTEX REM GRIP = 35 OVER.VORTEX CLEAR.VORTEX

vary for different applications, may have to be measured for each different procedure, and are independent of sequencing. An optimum sequence should be obtainable, although the predicted times will depend on the accuracy of the programmer's estimates for task times. The orientation time is the time required for the robot to move from the completion of a task to the start of a subsequent task. Lock time specifies the time penalty for interrupting a process. An example is the time required to stop the centrifuge to add more tubes while centrifugation is in progress. Finally, tasks may have timing constraints; a minimum or maximum time must elapse before a successive task is initiated. Such constraints are crucial for kinetic studies. Optimization

The TORTS system uses a depth first search of the space of feasible solutions. The depth first search is directed by heuristics and expert strategies (10, 11). Figure 3 outlines the optimization procedure. Solutions are generated one at a time. Each improved solution lowers the upper bound on the predicted completion time. Each time an improved solution is found or the upper bound is exceeded, the system will backtrack and try an alternative feasible task. The optimization is completed when all feasible task sequences have been evaluated and the system backtracks to the top. The TORTS system can expand a single sample procedure into a multiple-sample or duty cycles procedure. This step of the optimization occurs after an optimum task sequence is obtained for the single-sample procedure. Optimizing multiple-sample proce-

Figure 3. Flow chart for the exploration of the solution search space in TORTS.

ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989 · 811 AA

A/C

INTERFACE

dures allows the duty cycles to overlap, which further minimizes the total completion time. Each task of a single procedure will form a parallel task for the additional duty cycles. All the tasks will be coded by a unique integer, but parallel tasks are identified by their Primitive Identifier (PI) as shown in Table V. Expanding a single procedure to multiple procedures also relaxes the constraint of the logical sequence of procedures. Consequently, the larger the number of duty cycles optimized, the greater the potential time savings. The correct choice of the number of duty cycles to be optimized is important because the search space will increase exponentially with the number of duty cycles. The run time for the TORTS system will also increase because of the search of the entire solution space and the validation of the optimum task sequence. Another consideration is the turnaround time for each procedure. If a delay in the completion of a single procedure is not allowable, the optimum task sequence would be to run each procedure serially. For proce-

Table V.

dures that require many samples or duty cycles, efficient patterns of task sequences may be obtained from optimizations of a reduced number of duty cycles. The robot programmer needs to follow this pattern while programming the robot to perform the larger number of duty cycles. An enzyme assay was chosen to evaluate the TORTS system because the timing of the spectrophotometric measurements is crucial to the analysis. The assay is the activity determination for liver alcohol dehydrogenase (12). The method is based on spectrophotometric measurement of the amount of nicotinamide adenine dinucleotide (NAD) undergoing reduction in 3 min at a pH of 9.6 in the presence of excess alcohol. The time estimates of the optimized task sequences are in good agreement with experimental results, as shown in Table V. Database considerations in expert systems Integral to the Analytical Director project is the knowledge base of chemical information used by the system to de-

Predicted and experimental start times Times (s)

Level

Task

1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 22 14 13 15 14 16 15 17 16 18 17 19 18 20 19 21 20 22 21 23 23 24 24 25 25 26 26 Project Completion Time

PI

Predicted

Experimental

1 2 1 2 1 2 1 2 9 10 11 12 9 13 1 2 1 2 1 2 1 2 10 11 12 13

0.0 4.9 32.2 37.1 64.4 69.3 96.6 101.5 128.8 270.4 492.6 623.6 643.8 786.8 1016.3 1021.2 1048.5 1053.4 1080.7 1085.6 1112.9 1117.8 1151.7 1373.9 1504.9 1567.3 1795.6

0.3 ± 0.0 5.1 ± 0 . 2 32.4 ± 0.2 37.5 ± 0.2 64.8 ± 0.2 69.5 ± 0.2 96.1 ± 0.2 100.6 ± 0 . 2 129.3 ± 0.2 271.2 ± 1.1 492.0 ± 1.3 623.1 ± 1.6 644.1 ± 1.8 787.0 ± 2.3 1017.4 ± 2.3 1022.0 ± 2.3 1049.6 ± 2.2 1054.5 ± 2.2 1081.9 ± 2.3 1086.5 ± 2.3 1113.4 ± 2 . 2 1117.9 ± 2 . 2 1151.9 ± 2 . 2 1375.2 ± 2 . 6 1506.4 ± 2.5 1565.6 ± 2.7 1793.6 ± 3 . 1

Note. The experimental results wereobtained from six runs.

812 A · ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989

sign, store, and reason about analytical procedures. We have used object-oriented programming strategies that allow all data objects, quantitative and qualitative, to be represented as objects and to be manipulated directly. Expert system methods theoretically are capable of classifying such data objects on the basis of randomly organized rules that characterize them. This process may be conceptualized as traversing a logic tree. However, in complex problems, the rules used to span the information in the knowledge base must be efficiently organized or the rule structure will become unmanageable in size and logical complexity. Recent work (13) suggests that the ID3 (14-16) algorithm is useful for establishing efficient rules for knowledgebase interrogation. The knowledge base used by an expert system can be most efficiently represented as a set of rules based on the minimal decision tree spanning the data. The root node of this tree is the attribute that minimizes the number of branches from the root. Each branch from the root node contains a different value of the root attribute. Each branch required from these secondlevel nodes may be branched further using attributes different from the previous attributes used to split the data. If more than one attribute is used to describe the data, the decision tree will not be unique. As the number of attributes used to describe the data increases, the number of possible decision trees also increases. In complex data sets, this proliferation demonstrates the critical importance of the most efficient structure for the decision tree. The ID3 algorithm can be used to determine classification trees t h a t minimize the number of tests needed to classify objects based on information theory and the entropy of classification. As a simple demonstration of this operation, IR data are given in Table VI for substituted benzenes. Although this is admittedly a very simple classification problem, it does not differ in principle from more complex classification problems. The ID3 algorithm creates the decision tree shown in Figure 4. Furthermore, the PROLOG implementation of this algorithm writes syntactically correct PROLOG rules that can be used to span the database. Standard robotics method—the next step Our work on the Analytical Director project has demonstrated expert system control of laboratory robots. The next desirable step would be the transition from the description of an analyti-

cal procedure to the actual perfor­ mance of that procedure by an auto­ mated laboratory robot. This will require several developments that have not yet taken place. A formal model of

Table VI. tree

the chemical analysis domain is re­ quired if a computer system is to de­ sign, plan, manage, and ultimately con­ trol the actions of a robot during the performance of a laboratory procedure.

Data for benzene substitution used to generate decision

Compound name

Degree of substitution

toluene m-xylene o-xylene p-xylene 1,2,3-trimethylbenzene 1,2,4-trimethylbenzene 1,3,5-trimethylbenzene 1,2,3,4-tetramethylbenzene 1,2,3,5-tetramethylbenzene 1,2,4,5-tetramethylbenzene pentamethylbenzene

mono meta ortho para 1,2,3-trl 1,2,4-tri 1,3,5-tri 1,2,3,4-tetra 1,2,3,5-tetra 1,2,4,5-tetra penta

IR absorption ranges (cm 650699

700749

750799

800849

S S

S W

W

W

w w w w s w w w w

s w s w w w s w w

s s s s w w s w w w

w w w w s s s w w w

') 850899 W W W

w w M W W S M S

Note. Absorption is denoted by W (weak), M (medium), and S (strong ,

I

w

I 1,3,5-

I

tri

I s

I

meta

tri

Figure 4. Decision tree generated from data in Table VI.

I W I para

I

Such a formal model will include a state space representation of the robo­ tic table layout and a set of primitive actions that perform operations in that state space. The ARTS programming language provides an adequate frame­ work for accomplishing this robotics programming goal. The more difficult problem is map­ ping chemical procedures into the ro­ botic environment so as to accomplish the desired task. To date, little atten­ tion has been given to the formal representation of chemical procedures. One approach, a Symbolic Synoptic System for Analytical Chemistry (SSSAC) (17), appears to have attract­ ed little attention. However, we are currently studying the use of natural language parsing to map chemical pro­ cedures directly into robotics proce­ dures. Although the solution of the nat­ ural language parsing of laboratory procedures is not yet feasible in the general case, recent developments in natural language interpretation (18) indicate that chemical procedures writ­ ten in a simple, prescribed syntax could be interpreted automatically. The goal of this work is the standard robotics method. Standard reference materials have been used for many years to help individual laboratories test the reliability of their analytical procedures, but no scheme has been de­ veloped to guarantee that complex an­ alytical procedures performed by a ro­ bot would give the same results in dif­ ferent laboratories. The standard robotics method t h a t we envision would allow a method to be transferred from one laboratory to another and would ensure the same quality of re­ sults in each lab. The success of the standard robotics method project will require that a stan­ dard set of primitive robot unit opera­ tions be defined for each laboratory envi­ ronment. The text of a procedure, writ­ ten in the prescribed syntax, could then be mapped onto the primitive robot op­ erations. The operations so mapped would constitute the standard robotics method. Laboratories equipped with Analytical Director units could transfer procedures and not lose quality control because of technician inconsistency from laboratory to laboratory. References

I s 1 1,2,3,4tetra

(1) Kramer, G. W.; Fuchs, P. L. In Advances in Laboratory Automation—Ro­ botics; Strimaitis, J. R.; Hawk, G. L., Eds.; Zymark Corporation: Hopkinton, MA, 1988; Vol. 4. (2) Schlieper, W. Α.; Isenhour, T. L.; Mar­ shall, J. C. J. Chem. Inf. Comput. Sci. 1987,27(3), 137-43. (3) Schlieper, W. Α.; Isenhour, T. L.; Mar­ shall, J. C. Anal. Chem. 1988, 60, 1142. (4) French, S. Sequencing and Scheduling:

ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989 · 813 A

A/C

INTERFACE

An Introduction to the Mathematics of the Job-Shop; John Wiley and Sons: New York, 1982. (5) Cooper, R. B. Introduction to Queuing Theory; North Holland: New York, 1981. (6) Phillips, D. T. Fundamentals of Net­ work Analysis; Prentice-Hall: Englewood Cliffs, NJ, 1981. (7) Harrington, P. B.; Isenhour, T. L. Pre­ sented at the Pittsburgh Conference, At­ lantic City, NJ, March 1986; paper 1008. (8) Harrington, P. B.; Isenhour, T. L. Pre­ sented at the Pittsburgh Conference, At­ lantic City, NJ, March 1987; paper 1136. (9) Isenhour, T. L. J. Chem. Inf. Comput. Sci. 1985,25, 292. (10) Nilsson, N. J. Principles of Artificial Intelligence; Tioga Publishing Company: Palo Alto, CA, 1980. (11) Pearl, J. Heuristics; Addison-Wesley: Reading, MA, 1984. (12) Methods in Enzymology; Colowick, S. P.; Kaplan, N. 0., Eds.; Academic Press: New York, 1955; p. 495. (13) Schlieper, W. Α.; Isenhour, T. L.; Mar­ shall, J. C. J. Chem. Inf. Comput. Sci., in press. (14) Quinlan, J. R. In Machine Learning— An Artificial Intelligence Approach; Michalski, R. S.; Carbonaell, J. G.; Mitchell, T. M., Eds.; Tioga Publishing Company: Palo Alto, CA, 1983. (15) Thompson, B.; Thompson, W. Byte 1986, 22(12), 149. (16) Derde, M. Anal. Chem. 1987,59,1868. (17) Kateman, G. Fresenius Z. Anal. Chem. 1978,293, 338. (18) Rettig, M.; Bates, M. A. I. Expert 1988, 3(7), 41.

T. L. Isenhour (left) is dean of arts and sciences at Kansas State University. He received his B.S. degree in chemistry from the University of North Carolina in 1961 and his Ph.D. from Cornell University under the direction of George H. Morrison in 1965. He has been a member of the faculties of the University of Washington, the University of North Carolina, and Utah State University. J. C. Marshall (center) has been a member of the faculty of St. Olaf College for 28 years. He received his B.S. degree in chemistry from Luther College (Decorah, IA) in 1956 and his Ph.D. from the University of Iowa under the direction of Alex Popov in 1960. He carried out postdoctoral work with I. M. Kolthoff from 1960 through 1961 and worked with Charles N. Reilly from 1969 through 1970. He has since worked in collaboration with T. L. Isenhour. S. E. Eckert (right) is currently completing her Ph.D. in chemistry at Kansas State University under the direction of T. L. Isenhour. She received her B.S. degree in chemistry from Eastern Illinois University in 1977 and worked as an instrument chemist at Sterling Drugs and as an assistant analyst at Warner Lambert.

RENT Analytical Instruments

/ Free Instrument delivery & setup in selected areas. • GC.MSD.FTIR.AA.ICP.LC·!!? • Choose from many major manufacturers • Lease or rent-to-own. • New Catalog of Chromatography Supplies.

-1-800-551-2783

On-Site® Instruments ENVIRORENTAL™ 689 North James Road

Columbus, Ohio 43219-1837

(614)237-3022 CIRCLE 120 ON READER SERVICE CARD

814 A · ANALYTICAL CHEMISTRY, VOL. 61, NO. 13, JULY 1, 1989

Electrochemical Surface Science Molecular Phenomena at Electrode Surfaces

A

major work bringing together the three interrelated disciplines of electrochemistry, surface sci­ ence, and metal-cluster chemistry. Emphasizes the most recent and criti­ at EX*" cal advancements in electrochemical research. Offers detailed descriptions fiat**** on the use of ultrahigh vacuum sur­ face spectroscopic methods in the study of the electrode-solution inter­ face. Reports recent advances in the adaptation of new experimental tech­ niques, from scanning tunneling microscopy to electrochemical problems. Investigates the critical aspects of in situ vibrational spectroscopy and reviews various electrode processes such as the electrochemical reactivity of polymer deposits, C0Z methanation, and surface organometallic chemistry. Provides 36 chapters covering a broad but balanced range of important topics written by recognized experts in the field. An invaluable resource for students and active researchers in electrochemistry, surface science, chemical engineering, and catalysis. Manuel P. Soriaga, Editor. Texas A&M University Developed from a symposium sponsored by the Division of Colloid and Surface Chemistry of the American Chemical Society ACS Symposium Series No. 378 553 pages (1988) Clothbound ISBN 0-8412-1542-1 LC 88-26311 US & Canada $94.95 Export $113.95 Order from: American Chemical Society, Distribution Office Dept. 04 1155 Sixteenth St., N.W., Washington, DC 20036

800-227-5558

or CALL TOLL FREE (in Washington, D.C. 872-4363) and use your credit card!