Laboratory automation software: what the scheduler owns, which instrument drivers exist, and how the automation layer meets the system of record

Evaluating the two layers

1. Bring the instrument list to the first call. Ask specifically which of your makes and models have supported drivers, at what firmware, and what a new driver costs and takes. An unsupported instrument is either an integration project or an exclusion from the workflow, and both are better known before the contract.
2. Scheduling, and what it optimises. A real scheduler manages resource conflicts, timed dependencies and variable durations, and the interesting question is what it does when a step overruns. Ask whether timings are guaranteed or best effort, because assays with time-critical incubations need the first.
3. Error recovery is the whole value. Ask what happens when a tip is missed, a plate is not where it should be, or an instrument reports a fault mid-run. Whether the system can pause, let a person intervene and resume without losing the batch is what separates genuine walk-away operation from supervised automation.
4. Simulation before hardware. The ability to develop and dry-run a method without occupying the deck saves an enormous amount of instrument time and is a sign of a mature product. Ask to see a method built and simulated during the evaluation rather than watching a prepared demonstration.
5. The boundary with the system of record. Decide what the automation layer holds and what it hands to the laboratory information system, and make sure sample identity crosses that boundary without transcription. A run whose results cannot be traced to registered samples has automated the pipetting and broken the record.

Who will write and maintain the methods

Automation platforms are configured by someone, and the skills to do it well are specific and not universal in a laboratory. Establish whether the vendor writes your methods, trains your staff, or both, and what happens when the trained person moves on.

Ask how methods are version controlled and whether a change can be reviewed before it reaches a production run. Automation without change control produces failures that are very hard to diagnose after the fact.

What to prove during evaluation

Run one of your own real methods end to end on your own instruments, including a deliberate failure. A demonstration on the vendor's equipment with the vendor's method proves the product works; it does not prove it works here.

Measure the whole cycle time including setup and teardown rather than the run time alone. Automation that saves minutes in the run and adds them in preparation is common and is usually discovered after purchase.

Common questions

What does laboratory automation software do?

It drives instruments through a defined method and schedules the resources, timings and dependencies of a run, handling errors and recording what happened. The driver layer talks to instruments; the scheduler decides the order.

Will it work with my existing instruments?

Only where drivers exist for those makes, models and firmware versions. Ask for the list explicitly, and for the cost and timeline of any driver that has to be written.

Does automation software replace a LIMS?

No. The automation layer runs the instruments; the laboratory information system holds sample identity, methods, results and the audit trail. They meet at a boundary that must carry sample identity without transcription.

What should I test during an evaluation?

One of your own methods, on your own instruments, end to end, including an induced failure so you can see how recovery works. Measure the whole cycle time rather than the run time.

Browse by service class

• Compare Gene synthesis on advertised prices