Lab Automation Scheduling Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a fixed sequence keep getting built instead of a scheduler?

Because the specification people write is a sequence. When a team describes what they want, they describe the steps: seal, incubate, add reagent, wash, read. The steps are the easy part and what a developer can quote against confidently. What determines whether a schedule is feasible is the constraint set, and that lives as undocumented knowledge in the automation engineer's head.

A minimum delay is easy, you wait. A maximum delay changes the nature of the problem, because committing the reader to one plate now can make a later plate infeasible, and infeasible means scrap. That is a constrained optimisation problem, not a queue, and an ordered list with wait states cannot represent it at all. It runs happily until an assay with a read window arrives, then starts losing plates in a way that looks like bad luck.

The fix starts before the quote. Write the constraints down: for each step, the resource required, the duration with its realistic variance, and the minimum and maximum delay from the preceding step. Include resource rules that are not durations, such as a washer that must not run a different buffer without a purge, or an incubator holding twelve plates only in the right stack format. Then ask how the scheduler handles a maximum delay when honouring it would make a later plate infeasible. If the answer is a fixed sequence with wait states, they are building a macro recorder.

What goes wrong with plate identity, run history and existing method definitions?

Plate identity is the one that bites first. Barcodes get misread, a plate gets relabelled after a reformat, and a daughter plate produced from four parents has a lineage that exists only in a technician's notebook. When a result looks wrong six weeks later, the answer has to come from provenance records rather than memory, and systems that record the run but not the plate cannot answer it.

Existing method definitions are the second problem. Your current methods are expressed in the incumbent product's own language, often as sequences with embedded timing assumptions and vendor specific device calls. Translating them is a rewrite that surfaces every assumption nobody documented, it takes longer than teams expect, and it belongs in the plan as a named task rather than an afternoon.

Historic run data is the third and the honest answer is usually to leave it where it is. Reader output files on a workstation with meaning encoded in folder names are not a migratable dataset, and timing history cannot be reconstructed because the timestamps recorded were the intended ones.

The practical approach: record plate level provenance from the first run of the new system, with every operation carrying its actual timestamp and the resource used. Rewrite your two or three highest volume assays properly rather than converting all of them, and archive historic files with a manifest and a documented cutover date.

Why do the instrument drivers and informatics handoff break after launch?

Drivers break on change, and change is constant on a working cell. A vendor pushes an update and the application you were automating moves a window. A reader firmware update alters a response string that was being parsed. An instrument is replaced with a newer model of the same product and the command set is not identical. None of that is exotic and all of it stops the cell.

The category is honest about difficulty if you ask the right question. Some devices offer a modern interface. Some expose a software development kit that only runs on a specific Windows version. Some are driven by sending commands over a serial port and parsing a response designed for a human to read. Some can only be controlled through their own application, and that last category is where projects die, because it is fragile by construction.

Informatics handoff fails more quietly. Reader output is pushed into your laboratory information management system, a field mapping changes, and results land against the wrong plate or stop landing while the cell runs on perfectly.

The fixes are structural. Insist on a device abstraction layer presenting one internal interface upward while speaking each instrument's own language downward, so replacing a reader does not touch the scheduler. When buying new instruments, insist on SiLA 2 support, because a compliant device is far cheaper to integrate. Then treat every driver as versioned code with a smoke test that runs the device through its basic operations before a shift starts, and alert when informatics ingest volume drops rather than waiting for someone to notice missing data.

What happens when error recovery and regulated use are not covered?

A gripper misses a plate at 2am. What most products do is stop and alert. What you need is a decision: which plates are still inside their timing windows and can be rescheduled, which are past them and must be marked scrap, and what happens to the partially complete run data. Recovery logic is specific to your assays and almost never in the box, so when it is left out of a build the answer defaults to a scientist reconstructing the cell state by hand in the middle of the night.

The second half of that failure is state reconciliation. After a fault, the system's model of where every plate sits no longer matches physical reality, and without an explicit reconciliation step someone restarts the run and the arm reaches for a nest that is not empty.

Regulated use changes the whole shape of a project. A cell in a research setting and a cell in a quality control laboratory are not the same build, because the second carries audit trail and validation obligations that have to be designed in rather than added. If there is any chance your cell moves into regulated work, raise it during scoping.

The fix is a per assay recovery policy expressed as configuration: what is recoverable, what is scrap, who is notified and how. Record scrapped plates deliberately, with the cause, because most laboratories have no idea what scheduling failures cost them until it is measured, and that number is usually what justifies the next phase of work.

Should you build custom or configure what you already own?

Buy, and be glad of it, if your cell is largely single vendor, every device you own is already in the driver library, and your assays tolerate loose timing. Biosero Green Button Go has a broad driver library and handles heterogeneous cells. HighRes Cellario is strong where HighRes hardware sits at the centre. Thermo Scientific Momentum is capable and well established. You will be running in weeks rather than months and the licence costs less than a build.

The gaps that push toward a build are specific rather than general dissatisfaction. Driver coverage for the instrument you actually have, since every library has holes: an older reader, a device your own engineering group built, equipment from a vendor with a small installed base. Scheduling expressiveness, when your assay needs hard maximum delays, resource exclusivity rules, capacity limits and mid run human intervention points at once. And recovery, when what should happen after a failure depends on the assay rather than a generic rule. Build when two or more of those are true, when throughput on existing hardware has direct financial value, or when you operate several cells and want one scheduling and provenance layer rather than three vendor consoles.

How do hidden costs get into the quote?

The dominant one is instrument driver work and it is priced wrongly more often than anything else. In our experience it is the largest single line in a workcell project, and the estimate should be per instrument model, not per instrument count. Ask for a per model breakdown before you sign anything, and ask which of the four difficulty levels each device falls into: modern interface, vendor development kit, serial command set, or automating a vendor application.

Assays with hard timing windows are the second, because they turn the scheduler from a queue into a solver. Multiple cells sharing plates or a hotel are the third, since cross cell coordination is not a discount. Regulated use is the fourth and largest.

What keeps the number down is deliberate narrowness. One cell, the instruments you already own, and the two or three assays that account for most of your plate volume. The slowest projects we see try to cover every assay and every device at once, which delays the moment the scheduler proves itself on real runs.

What separates a build that works from one that fails here?

The builds that work plan with realistic durations and re-plan on every completion event. An instrument that usually takes 90 seconds and occasionally takes 140 will break a schedule built on the mean, so the scheduler has to hold duration with variance and adjust as reality diverges rather than cascading a failure through the rest of the day. That rolling horizon approach is also where throughput gain comes from on hardware you already own, because dead time between operations gets filled instead of baked into a fixed sequence.

They also give a scientist at 2am something readable. A run console showing what is running, what is at risk of missing a window, and what has failed, without training, is what determines whether a fault becomes a recovered run or a lost night.

The builds that fail treat the scheduler as the whole project and leave provenance, recovery and informatics handoff to a later phase that never gets funded. They also skip the modelling exercise that proves the design. Before committing, ask a developer to model your two highest volume assays and show the projected schedule against your real constraints. If the projection cannot be produced, the constraints are not understood well enough to build against.

Settle ownership before kickoff, in writing: the repository, the drivers and the infrastructure accounts. At Digital Heroes the client owns the code from the first commit. Driver ownership matters more here than elsewhere, because those drivers are reusable every time you replace an instrument, and losing them means paying for the same integration twice.