The work in lab automation can be divided into two segments marked by the introduction of software programmable systems going back to the days of the Intel 4004 (1971) and 8008 (1972) chips. While automation work using software had gone on before that, the cost of systems inhibited its widespread, commercial use. The available of inexpensive computing changed the industry.

Prior to that time, most commercial instrument automation relied on programmable controllers, the most common were timer-driven cams. Process chromatographs used timer cams to control automatic sampling, back-flush valves, and chart signal attenuation controls. With the advent of software programmable systems, instrument control, and data capture, processing capabilities became more extensive and began to significantly off-load post-processing work yielding real benefits to lab operations.

The design of instrument support systems varied with the vendor’s primary commercial focus: those that saw programmable systems as an extension of the instrument developed add-ons with limited functionality – in the chromatography market they developed integrator-based functionality. Vendors with a stronger background in computer systems developed products that took advantage of storage, display, control, and where available, multi-user, multi-instrument designs. Automation components were developed in response to bottlenecks in instrument use. For chromatography – a technique that received a good deal of attention:

• autosamplers were introduced to relieve the labor of sample injection into the chromatograph and allow the instrument to run unattended off-hours,
  
• computer / integrator systems were developed to handle the data processing which became significant with off-hours instrument runs,
  
• robotics systems were developed to prepare samples for instrument analysis.

The solution to one problem created backups that were solved with additional automation systems.

Perkin-Elmer in particular divided the laboratory world into two segments: instrument-computer data stations to service the instruments, and, Laboratory Information Management Systems (LIMS) to provide sample tracking / management information for testing laboratories. To a large extent vendor products and capabilities lead the customers in the laboratory automation / computing market by trying to anticipate what their needs.

At the same time, authors such as Ray Dessy (from VPI, now Virginia Tech) taught courses and published a series of articles in Analytical Chemistry that gave the market an idea of what would be possible with these new tools. Jonathan Titus wrote a series of columns in American Laboratory that showed scientists how to program low-cost computers for lab use. Based on their work, experimenters learned how digitize analog signals and then use software to acquire and process laboratory data.

During this time frame (1970’s – 1980’s) computer vendors marketed computers, operating systems, and software for the experimenter to make it easier to connect experiments to computer systems and do their work. As a result we saw two distinct lines of development emerge: the programmer-scientist, and, the instrument vendor (and independent consulting companies) developing products to address their perspective of the customers needs. Customers looked at products and tried to see how they would, or could be made, to solve the problems they were encountering: productivity, cost, sample throughput, etc.

Because of the history behind automation within the laboratory, we don’t have “laboratory automation” but rather the automation / computerization of functions and instrument stations within the lab. Vendors have a narrow focus on the techniques & products they specialize in, and the user community is similarly focused. There isn’t a universal view of lab operations except at the management level where the concerns are human resources, fiscal responsibility, and productivity; not technology development, integration, and management.

Laboratories, both in research and quality control, today depend upon automation and computers to get their work done. In the life sciences, applications such as high-throughput screening, and micro-titer plate assays require automation systems.

According to a recent (2008) Laboratory Automation survey by the Association for Laboratory Automation (http://www.labautopedia.org/mw/index.php/Main_Page) there is an expectation of increasing need for automation (section 3). The email announcing the survey’s availability dated January 20, 2009 carried the statement: ““Laboratory automation development is being increasingly outsourced to the commercial market,” said Steve Hamilton, Sanitas Consulting, Boulder, CO.” Data-life cycle management is also dependent on information systems, as is the ability to meet the requirements of regulatory agencies.

The end-result of these points is that laboratory managers have to do a better job of technology planning and management within their labs. Outsourcing isn’t going to be successful unless an overall plan is in place to show how the components and systems in labs fit together. In addition, there is an increasing need for the development of data interchange & communications standards to move the implementation of lab systems from isolated data stations and database systems, to more effective integrated laboratory wide systems: Integrated Laboratory Automation.

There are three elements needed to reach this Integrated Laboratory Automation goal:

• The development of data interchange / communications standards,
  
• Laboratory Management – and in some cases Senior Management at the Director level – taking on the responsibility for laying the policies and practices that provide the foundation for automation. This is on a par with the management oversight for any significant corporate information systems program.
  
• The development of Laboratory Automation Engineers who are trained in the science and technology of laboratory automation systems. These people need to be able to understand the science that underlies the labs work, be able to translate it into functioning systems and, be able to coordinate those systems so that where needed, they function as an integrated information environment.
  

This is the work that the Institute for Laboratory Automation has undertaken.