LII:Are You a Laboratory Automation Engineer?

Title: Are You a Laboratory Automation Engineer?

Author for citation: Joe Liscouski, with editorial modifications by Shawn Douglas

License for content: Creative Commons Attribution 4.0 International

Publication date: 2006

Summary

The technology and techniques that are used in automating laboratory work have been documented for over 40 years. Work done under the heading of “laboratory automation” has progressed from pioneering work in data acquisition and instrument control, to instrumentation with integral computing and communications. If the field is to move forward, we need to organize the practices and education of those applying automation and computing technologies to laboratory work. This note is an opening to a dialog in the definition and development of the field of "laboratory automation engineering” (LAE).

In this article the following points will be considered:

• Definition of laboratory automation engineering (LAE)
• Laboratory automation as an engineering discipline
• Developments in laboratory automation
• Benefits of formalizing laboratory automation engineering
• Sub-disciplines within LAE
• Skills required
• What comes next

Introduction

There are many of us working on the use of automation technologies in scientific disciplines such as chemistry, high-throughput screening, physics, quality control, electronics, oceanography, and materials testing. Yet, given the diversity of applications, we have many characteristics in common. There are enough common traits and skills that we can declare a field of laboratory automation engineering (LAE). The establishment of this field of work benefits both the practitioner and those in need of their skills. In addition, we may finally come to the full realization of the rewards we expect from automation systems.

Laboratory automation engineering can be defined as the application of automation, information, computing, and networking technologies to solve problems in, or improve the practice of, a scientific discipline. As such, it fits the accepted definition of "engineering": the discipline dealing with the art or science of applying scientific knowledge to practical problems.

The common characteristics of LAE are:

• It is practiced in facilities where the focus is scientific in nature, including research and development, testing, and quality control activities.
• The end product of the work consists of information (e.g., initial and processed test data) and/or systems for managing and improving people’s ability to work with information (intermediate steps result in prepared samples or specimens).
• The automation practice draws upon robotics, mechanical and electrical engineering, data and information handling and management, information and networking technology, and the science that the automation is addressing.
• It requires the practitioners to be knowledgeable in both automation technologies and the discipline in which they are being applied.

LAE differs from other forms of automation engineering found in manufacturing and product production in several ways. First, modern manufacturing and production facilities are designed with automation as an integral part of the process. Laboratory automation is a replacement process: manual techniques, once they mature, are replaced with automated systems. Economics, and the need to improve process uniformity, drive the replacement. If a testing or quality control lab could be designed initially as a fully automated facility, it would be difficult to distinguish the automated facility from any other manufacturing facility aside from the point that its “product” is data rather than tangible materials. The second difference is the point just made: the results are ultimately data. LAE would result in systems and methods (e.g., high-throughput screening and combinatorial methods) that enable science to be pursued in ways that could not be done without automation.

Developments in laboratory automation

Laboratory automation was initiated by scientists with a need to do things differently. Whether it was to improve the efficiency of the work, to substitute intelligent control and acquisition systems for manual labor, or because it was the best or only way to implement an experimental system, automation eventually moved into the laboratory. Those doing the work had to be as well-versed in computing hardware and software as they were in their science. The choice of hardware and software, as well the development of the system, was in their hands.

The first generation of laboratory automation systems were concerned with interfacing instrument, sensors, and controllers to computers. Then came the control of experiments through robotics and direct interfacing with computer systems. A variety of experimental control software packages became available, as did laboratory information management systems (LIMS) and, in the last few years, electronic laboratory notebooks (ELNs).

If you have visited a conference in any discipline with a discussion on automation, it would appear that automation has seriously taken hold and most things are already automated or soon will be. One problem with this product array is the ability to integrate products from different vendors. Individual procedures are being addressed, but the movement of data and information within the lab and your ability to work with it is not as robust as it could be. Some vendors answer this need with comprehensive ELN systems in which their products are the hub of a lab's operations. Data is collected from instruments with local computing capability (e.g., the simple data translation of balances or similar devices) into their systems for storage, cataloging, analysis, etc. The movement is primarily one-way, but this is only the current generation of systems. The capabilities of today’s products generate new possibilities requiring upgrades to, or replacement of, these products.

The early automation models were driven by limitations in computing power, data storage, and communications. There was one experimental setup, with one system to provide automation. The next generation of laboratory automation has to replace previous models, and develop implementations that can be gracefully upgraded rather then replaced. This will require increased modularity and less dependence upon local-to-the-instrument systems for automation. Achieving it requires engineering systems, not just building products.

Today, data communication is readily available thanks to the development of communication standards. Storage is cheap and there is an abundance of computing capability available. Data analysis does not have to be done at the instrument. Instead, the data file with instrument parameters can be sent to a central system for cataloging, storage, analysis, and reporting, while still making the raw data readily available for further analysis as new data treatment techniques are developed. The dots in the automation map will be connected with bi-directional communications. The field needs people who are trained to do the work and to take advantage of the increased capabilities available to them.

Beyond the issues of experimental work lay the requirements of corporate information architectures. Laboratory systems are part of the corporate network, whether it is a for-profit company, a university, or a research organization. Laboratory computing does not stop at the door. The purpose of a laboratory is to create knowledge, information, and data. The purpose of laboratory automation is to assist in that development, making the process more successful, effective, and cost-efficient. This can be accomplished by engineering systems that have security built-in to protect them, while at the same time giving scientists access to their data wherever they need it. It also means designing systems that permit a graceful evolution, and continual improvement without disrupting the lab workings.

Too often we find corporate information technology (IT) departments at odds with those using computers in laboratory settings. On one side you hear “IT doesn’t understand our needs,” and on the other “we’re responsible for all corporate computing.” Both sides have a point. IT departments are responsible for corporate computing, and labs are part of the corporation. However, IT departments usually do not understand the computing needs of scientists; they do not speak the same language. IT-speak and science-speak do not readily connect and the issue will worsen as more instruments become network-ready. Specialized software packages used in laboratory work raise support issues for IT departments. IT would be concerned about who was going to support these programs and the effect they may have on the security of the corporation’s information network. LAE’s have the ability to bridge that gap.

About the author

Initially educated as a chemist, author Joe Liscouski (joe dot liscouski at gmail dot com) is an experienced laboratory automation/computing professional with over forty years of experience in the field, including the design and development of automation systems (both custom and commercial systems), LIMS, robotics and data interchange standards. He also consults on the use of computing in laboratory work. He has held symposia on validation and presented technical material and short courses on laboratory automation and computing in the U.S., Europe, and Japan. He has worked/consulted in pharmaceutical, biotech, polymer, medical, and government laboratories. His current work centers on working with companies to establish planning programs for lab systems, developing effective support groups, and helping people with the application of automation and information technologies in research and quality control environments.