Lab Automation and Robotic Workcell Scheduling Software: Why One Timing Conflict Ruins a Whole Plate Run

Why scheduling is the actual constraint on an automated workcell

A workcell is an expensive object. Two liquid handlers, a plate hotel, two incubators, a washer, a multimode reader, a sealer, a peeler and a robotic arm to move plates between them is a capital purchase that arrives with a business case about throughput. Then the throughput is set entirely by software, and specifically by whether the scheduler can keep the arm and the instruments busy without ever violating a timing constraint.

The failure mode is specific and painful. A cell based assay has a reagent addition followed by an incubation that must be read between 28 and 32 minutes later. The scheduler committed the reader to another plate at minute 29. The arm now holds a plate with nowhere to put it, or worse, the plate sits on the deck and gets read at minute 41. That plate is scrap. If it was a 1536 well screen using a reagent that costs more than the technician's day, the loss is real, and it is not visible in any report because nobody records scrapped runs.

The second failure mode is silent underuse. The cell runs at forty percent of what the hardware could do because the schedule is static, written as a fixed sequence by whoever set it up, and it leaves the reader idle while the arm waits for an incubator door. Nobody notices, because it still finishes the plates by the end of the day. Then someone asks why the screen is taking six weeks.

What Green Button Go, Cellario and Momentum actually leave to you

These are the three serious products in the category and they are genuinely good. 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, particularly around Thermo equipment. None of them is a poor product, and for a lot of cells the correct decision is to buy one.

The gaps show up in three places. The first is drivers for the specific instrument you have. Every vendor product ships a driver library, and every library has holes: an older reader, a bespoke device built by your own engineering group, a piece of equipment from a vendor with a small installed base, an analytical instrument nobody expected to see on a workcell. Adding a driver is a vendor project with a quotation and a queue, and your screen is waiting.

The second is the scheduling model itself. Most commercial schedulers optimise plate throughput under simple constraints. What they express less well is your particular assay's hard timing windows, resource exclusivity rules such as a washer that must not run a different buffer without a purge, capacity limits like an incubator that holds twelve plates but only if they are in the right stack format, and human intervention points where a scientist adds something by hand mid run. When your assay needs all four, you end up expressing them as manual sequence hacks and losing the optimisation entirely.

The third is what happens after a failure. A gripper misses a plate at 2am. What the product does is stop and alert. What you need is a decision: which plates are still recoverable, which are past their window and should be marked scrap, which can be rescheduled, and what the system does with the partially complete run data. Recovery logic is deeply specific to your assays and it is almost never in the box.

Timing constraints are the requirement people write down last

When teams specify a scheduler, they describe the sequence of steps. The steps are the easy part. What determines whether the schedule is feasible is the constraint set, and it is usually undocumented tribal knowledge held by the automation engineer.

A serious build models constraints explicitly. Each step has a duration with variance, a required resource, and optionally a minimum and maximum delay from a previous step. That maximum is the one that matters: an incubation with an upper bound turns scheduling from a queueing problem into a constrained optimisation problem, because committing a resource now can make a later plate infeasible. Constraint programming handles this comfortably at workcell scale, and a solver that plans over a rolling horizon with re planning on every completion event gives you dynamic scheduling rather than a fixed sequence. The practical outcome we see is throughput improvement on the same hardware, because dead time between operations gets filled.

The other half is honesty about variance. An instrument that usually takes 90 seconds and occasionally takes 140 will break a schedule built on the mean. The scheduler should plan with realistic durations and re plan when reality diverges, rather than assume determinism and then cascade a failure through the rest of the day.

Drivers are unglamorous and they are most of the work

Anyone who has integrated instruments knows the shape of this. Some devices offer a modern interface. Some expose a vendor 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 that was designed for a human. Some can only be controlled by their own application, so integration means automating that application, which is fragile and everyone hates it.

Standards help where they exist. SiLA 2 gives a common device interface and modern instruments increasingly support it, and OPC UA appears on the industrial side of things. Neither covers a full mixed vendor cell today, so a real build ends up with a driver layer that presents one internal interface upward while speaking whatever each device needs downward. Getting that abstraction right is what makes the system survive the day you replace the reader.

Budget honestly here. In our experience driver work is the largest single line in a workcell scheduling project, and the estimate should be per device model, not per device count. Ask any vendor or developer for a per model breakdown before you sign anything.

What a custom build must include

• A device abstraction layer with one internal interface, and per model drivers underneath it.
• Process definitions where each step carries resource, duration with variance, and minimum and maximum delay constraints.
• A dynamic scheduler that re plans on every completion event rather than executing a fixed sequence.
• Resource models that reflect reality: incubator capacity and stack format, exclusivity rules, purge and wash requirements between incompatible runs.
• Manual intervention points that pause the schedule cleanly and resume without invalidating downstream timing.
• Error recovery with per assay policy: what is recoverable, what is scrap, who is notified and how.
• Plate level provenance recording every operation with actual timestamps, so a questionable result can be checked against what really happened.
• A run console that a scientist at 2am can read without training, showing what is running, what is at risk and what failed.
• Data handoff that pushes reader output and run metadata into your informatics system rather than leaving files on a workstation.

What it costs and how long it takes

Across the automation and control projects Digital Heroes has delivered, a first release covering your device drivers, a constraint aware scheduler and a run console runs $100,000 to $220,000 and ships in 14 to 22 weeks. A full platform adding error recovery policies, plate provenance, run history and informatics handoff runs $250,000 to $600,000 across 10 to 18 months.

What pushes the number up specifically on a workcell: the number of distinct instrument models, which is the dominant term. Devices with no modern interface, where control means driving vendor software. Assays with hard timing windows, since those turn the scheduler from a queue into a solver. Multiple cells that share plates or share a hotel. Regulated use, if the cell sits in a quality control laboratory rather than research, because then audit trail and validation apply. What keeps it down: one cell, the instruments you already own, and starting with the two or three assays that account for most of your plate volume.

Build versus buy, stated plainly

Buy Green Button Go, Cellario or Momentum if your cell is largely single vendor, every device you own is already in their driver library, and your assays tolerate loose timing. You will be running in weeks rather than months and the licence is cheaper than a build. That covers a lot of workcells and there is no shame in it.

Build when two or more of these are true. Your cell mixes three or more vendors including something bespoke or old, so driver gaps are already costing you. Your assays have hard maximum delay windows and you are losing plates. You are running the same screening cascade thousands of times and a throughput improvement on existing hardware has direct financial value. Your recovery from a failure is a scientist deciding by hand at 2am and you want that policy encoded. Or you operate several cells and want one scheduling and provenance layer across all of them rather than three vendor consoles.

How to choose a developer for workcell scheduling software

Ask them how they model a maximum delay between two steps, and what the scheduler does 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, not a scheduler, and your timing sensitive assays will fail on it.

Ask which instruments they have actually driven, by vendor and model, and how. Serial command sets, vendor software development kits, SiLA 2 and driving a vendor application are four different difficulty levels and the last one is where projects die. Ask for a per model estimate rather than an overall integration line.

Ask what happens when the arm drops a plate. A credible answer covers safe stop, state reconciliation with the physical cell, a per assay recovery decision and a record of what was scrapped. An answer that stops at an alert email means you will be reconstructing the cell state by hand.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the drivers and the infrastructure accounts. At Digital Heroes the code is yours from the first commit. Drivers matter here more than anywhere else, because they are the part you paid for and the part you will need again the next time you buy an instrument.