Chapter 1
Introduction

1.1 A Brief Story of Laboratory Automation

Through human history, there has always been a quest for automation. For instance, the water mill, which has been used by different ancient cultures, can be considered an example of mechanical automation in the general sense of replacing human labor with a more reliable and powerful alternative. By replacing human labor with a water mill, our ancestors achieved the following aims of automation: reduced production costs, increased production efficiency, and improved safety in the production process. With the industrial revolution, when powerful engines became available, automation in this general sense maximized production efficiency as never before in human history. Further development of electronics and computing brought automation to its present and familiar stage, in which finely controlled motors execute precise tasks emulating (and surpassing) human efforts, movement sensors open doors for people to pass through, and computer programs save works without users needing to remember doing that.

Scientific laboratories have adopted automation as its technology developed. The first documented solutions in laboratory automation were devised by scientists to improve their own work. Devices such as automated filters and siphons have been built by ingenious means since the late nineteenth century. With the advent of electronics, a wide range of new devices, such as conductivity meters, gas analyzers, pH meters, and automated titrators, became available. Soon after the Second World War, automation tended to become predominantly provided by specialized companies making the devices, due to the increased complexity in manufacturing. The exponential progress in computing then enabled the opening of the first fully automated laboratory by Dr Masahide Sasaki at the Kochi Medical School in Japan in the early 1980s. In the following decade, similar laboratories were opened in Japan, the United States, and Europe. The approach followed in such fully automated laboratories started becoming known as total laboratory automation (TLA).

TLA was and still is very expensive. Because of that, only a few laboratories, normally those involved in fields that can produce high financial returns, such as drug discovery, can afford to implement it. In order to make TLA more accessible for medium- and small-scale laboratories, the concept of modular automation was introduced in the late 1990s. Through this concept, smaller laboratories could purchase one or a few automated instruments and progressively upgrade them when money became available. A very recent development in modular automation that has the potential to reduce even further costs in laboratory automation is the adoption of open-source hardware, which has its blueprints freely available. Enabled by open-source microcontrollers, and open-source building devices such as three-dimensional (3D) printers, this technology enables users to build their own devices at a surprisingly low cost.

Modular automation, including open-source hardware, however, does not work in all situations because of the difficulty in integrating instruments built by different manufacturers. The negative effect of this lack of integration cannot be overemphasized. It has been recognized as a problem for more than 25 years, and attempts have been made to resolve it by means of standardization of the communication between instruments. Unfortunately, such standardization has never become widespread, and to date, it has remained difficult to integrate instruments built by different manufacturers. This book aims to present a way to overcome this limitation, and thus enable laboratories to implement automation at a much lower cost than by traditional means. The approach presented in this book is very simple and accessible for most professionals in laboratories even if they do not have a background in electronics or computing. It is also a very powerful approach, which overcomes virtually any lack of compatibility between instruments.

1.2 Approaches for Instrument Integration

As explained above, a fundamental aspect of laboratory automation is instrument integration, that is, the ability to make instruments work together. The following are the two ways to enable instrument integration.

1.2.1 The Usual Approach for Instrument Integration

Communication between laboratory instruments is usually implemented by a computer controlling one instrument, which in turn controls others (Figure 1.1). There is data interchange between the computer and the first instrument, and between instrument 1 and the other instruments. However, there is no direct communication between the computer and the instruments being controlled by instrument 1. In other words, only instrument 1 can be directly controlled by the computer and, consequently, by the user. An advantage of this approach is simplicity: the user only needs to operate a single program that controls the whole set of instruments.

Figure 1.1 Common approach to make instruments work together in a laboratory. Arrows show the paths for data exchange.

However, this approach also considerably limits options for users. For example, let us assume that instrument 2 breaks down and needs to be replaced. The user then finds an alternative to instrument 2, which performs better and costs less than the usual instrument supplied by the manufacturer of instrument 1. Ideally, the user should be able to connect this alternative instrument to instrument 1 and continue the work. In practice, however, this is not possible in most cases, because instrument 1 was built to communicate exclusively with instrument 2 and vice versa. Therefore, the user has no choice but to buy a second instrument 2.

1.2.2 Instrument Integration with Scripting

The limitation of the traditional approach of instrument integration (Figure 1.1) can be eliminated by scripting. As explained above, with scripting, the user coordinates the programs that control different instruments. This way, if the different instruments set up to work together have each a software interface, they can be integrated using scripting (Figure 1.2).

Figure 1.2 Instruments working together in a framework enabled by scripting. As in Figure 1.1, arrows indicate exchange of data.

In Figure 1.2, there is no direct communication between instruments; instead, the computer communicates with all instruments. It is important to note that this is conceptually different from the scenario in Figure 1.1, in which the computer controlled only instrument 1, and instrument 1 controlled the others.

In the example outlined earlier, the user needed to replace instrument 2. If the user finds a replacement for instrument 2, which has a program controlling it, he/she can readily make it work together with instrument 1 using the arrangement in Figure 1.2. To do so, the user does not need any knowledge of electronics or even advanced computing; scripting is all that is necessary. Thus, in our hypothetical history, the user could both save money and obtain a better instrument.

The example is hypothetical, but resembles the routine activities of a laboratory technician. It is common that when replacing a broken instrument the normal alternative is either too expensive or takes a long time to become available. In such cases, the damaged instruments could be replaced by cheaper and ready-to-use alternatives, by means of scripting. Two examples can be found among the reading suggestions at the end of this chapter. In one, the autosampler of a machine was coupled to a water analyzer, because the analyzer did not have an autosampler, and was not even designed to work with one. In the other case, a low-cost robotic arm (less than US$ 500) was used as autosampler for an automated titrator, rather than using the autosampler originally designed for that instrument, which would cost more than US$ 50 000.

Another aspect that gives an advantage to scripting is that it is not always possible to use one instrument to control several others (Figure 1.1). In most cases, instruments are designed to communicate with only another one. With scripting, there is no limit on the number of instruments that can be synchronized.

1.3 Scripting versus Standardization in Laboratory Automation

Scripting is not the first proposed solution for the problem of lack of compatibility between instruments. However, as will be explained below, it is the only one with real odds of solving this problem.

The usually proposed solution for the compatibility problem in laboratory automation is the adoption of standards. Such standards would mean that all instruments would communicate using the same protocols. This would make the integration of instruments very simple, and the problem of replacing instrument 2 (Figure 1.1) illustrated above would be very easily solved.

Although such a solution looks desirable, it is very difficult to be put in practice. A recent effort in this direction that stands out by its large magnitude is SiLA (Standards in Laboratory Automation). According to their website, http://www.sila-standard.org, SiLA is a consortium of several system manufacturers, software suppliers, system integrators, and pharmaceutical corporations, among others. There are several working groups composed of high-skilled experts dealing with device control and interfaces, command dictionary specification, data standard, process management system, and so on. If, on the one hand, it is impressive to see...