Lab automation software judged on who can change it a year later: what scheduling layers do that an instrument's own control software cannot, why robotic lab automation and a lab automation robot fail on integration rather than on mechanics, where bioprocess software and bioprocess automation impose recipe management and batch records that a research scheduler never had, what an automatic tube labeler quietly fixes in sample identity, and how to keep drivers, methods and data paths from becoming a dependency on one supplier

Specifying the layer

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.

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 robot 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.

Browse by service class

• Compare Gene synthesis on advertised prices