Lab automation software judged on who can change it a year later

Specifying the layer above the lab automation robots

1. List every instrument and confirm a driver exists. Ask for named, supported drivers for each instrument you intend to integrate, and ask who maintains them when the instrument's own software updates. An instrument without a maintained driver is an instrument outside the automation.
2. Establish who writes methods after handover. If method editing requires the vendor, every subsequent change is a change order with a lead time. Look for an editor a scientist can be trained on, and make training part of the purchase rather than an option.
3. Design the data path before the workflow. Decide where results land, in what format, and how they reach the laboratory system. Automation that produces files in a folder nobody parses has moved the manual work rather than removed it.
4. Separate scheduling from execution. A scheduler that optimises across instruments is a different product from the control software that drives one. Understand which layer you are buying, because a scheduler without device control still needs the drivers underneath it.
5. Add recipe and batch record control where the process is regulated. Manufacturing automation must hold recipes under version control and produce a batch record that ties parameters, deviations and results to a lot. Research schedulers do not do this, and retrofitting it is not realistic.
6. Fix sample identity at the physical layer. Automated identity depends on labels that machines can read reliably in the conditions they will meet, including cold and solvent exposure. A labeller and a barcode standard are unglamorous and prevent the failure mode that ruins automated runs.

Lock in happens at the driver layer

Whoever maintains the instrument drivers effectively controls what can be added to the cell. If those drivers are proprietary and unavailable to anyone else, the automation can only grow in the direction that supplier chooses.

Ask explicitly what happens if you add an instrument from another maker in two years, and get the answer in the proposal. It is the question that determines whether the investment stays useful.

Automating a bad process makes it faster

The most common regret is automating a workflow that was never rationalised, which produces the same inconsistencies at higher speed and with less visibility. Simplify and standardise the manual process first, then automate the version that works.

That sequencing also produces a much better requirements document, because the people writing it have just had to describe exactly what they do.

Chemical lab software, and the four systems it can mean

In a chemistry laboratory the phrase covers four different purchases. A LIMS tracks samples, tests and results. An electronic laboratory notebook records what a chemist did and why. A chromatography data system runs the instruments and holds the raw data under its own audit trail. And a chemical inventory or ELN-linked registry tracks substances, structures and safety information. They overlap at the edges and integrate badly when bought separately, so the question to answer first is which of the four is the system of record for a result.

An automated pipette system, and where it sits between a handle and a deck

Between a motorised pipette and a full liquid handling deck sits a class of bench units: a fixed head that fills a plate from a reservoir, a small cartesian robot with one or eight channels, or a plate-to-plate transfer station. They earn their place where the protocol is repetitive but the throughput does not justify a deck, and they remove the two errors a person actually makes, a skipped well and a drifting volume. The questions are the deck positions offered, whether the tips are ones you already stock, and whether the software can be driven by the LIMS or only by its own screen.

Common questions

What is the commonest cause of a stalled automation project?

An instrument that will not integrate, usually because its vendor provides no supported driver or restricts remote control. Confirm integration for every device before committing, with a demonstration rather than an assurance.

Should the scheduler come from the robotic lab automation supplier?

Not necessarily. Independent scheduling layers integrate across brands and reduce lock in; a supplier's own layer is usually simpler where the whole cell is from one maker. The deciding question is what else you will connect later.

Is validation required for research automation?

Not as such, but if the output supports a regulated decision, the electronic record expectations apply to the automation software as much as to the laboratory system. Deciding this early avoids an expensive retrofit.

How much training does a laboratory need?

At least two people able to write and debug methods, not one. Automation dependent on a single individual stops working when that person changes jobs, which is the quietest and most common failure in this category.

Does clinical lab automation need different software from research?

It needs the same scheduler and a great deal more record keeping: a result that leaves the laboratory as a report has to carry who approved it, on which instrument and against which calibration, and the software has to make an audit trail that cannot be switched off. The scheduling problem is the easier half in both settings.

Browse by service class

• Compare Gene synthesis on advertised prices