Laboratory Automation Orchestration: The SiLA 2 and Lab-as-Code Software Layer

A self-driving lab is only as good as the software that keeps its robots from colliding, its samples from getting lost, and its assays from timing out mid-cycle. The hardware is the easy part to photograph and the hard part to coordinate. Laboratory automation orchestration is the control plane that turns a room full of heterogeneous instruments — liquid handlers from one vendor, plate readers from another, a robotic arm, a mobile transport robot, an incubator with its own firmware — into a single programmable machine that executes an experiment from a declarative description. Without that layer you have expensive islands of automation joined by human hands carrying microplates.

This piece is a reference architecture for that layer as it exists in 2026: the connectivity standards (SiLA 2 and the OPC UA LADS companion specification), the device-driver and abstraction tier, the scheduler that allocates finite instruments across competing time-constrained assays, the experiment queue and workflow engine, and the lab-as-code discipline that makes protocols versioned, reviewable, and reproducible.

What this covers: the orchestration problem, SiLA 2 versus OPC UA LADS versus proprietary drivers, list versus dynamic scheduling, lab-as-code protocol definitions, ELN/LIMS integration, state management, error recovery, and the failure modes that quietly ruin runs.

Non-advisory note: this is a systems-architecture and industry analysis for software and automation engineers. It is not lab-bench safety guidance or scientific-method advice; validate any protocol against your own instruments, safety review, and regulatory obligations.

Context and Background

Lab automation is not new — plate-based screening robots have run since the 1990s, and Standardization in Lab Automation (SiLA) began its first-generation work in 2009. What changed is the ambition. The self-driving lab closes a loop: a design-of-experiments or machine-learning agent proposes the next experiment, the lab executes it unattended, results feed back, and the agent proposes again. That loop only holds together if execution is deterministic, observable, and recoverable. A human can improvise around a jammed tip or a mislabeled plate; an autonomous loop running overnight cannot.

Two forces collide in this space. The first is heterogeneity. A working lab rarely buys all its instruments from one vendor, and vendors ship their own control software, SDKs, and file formats. The second is the FAIR-data mandate — findable, accessible, interoperable, reusable — which regulators, funders, and pharma quality systems increasingly expect. Orchestration sits precisely at the intersection: it must speak to every instrument and it must emit clean, structured, provenance-rich data.

The incumbents are the big scheduling suites — Tecan’s control environment, Hamilton’s VENUS, and vendor-neutral schedulers like those historically sold as Green Button Go or Momentum. These are powerful but often closed, GUI-driven, and hard to put under version control. The open-source and standards-based stack — SiLA 2, the OPC UA LADS companion specification, PyLabRobot, the Opentrons Python Protocol API — is what makes lab-as-code practical. This reference architecture leans on the open stack because it is the one you can inspect, test, and reason about. For the closed-loop control theory that sits above orchestration, see our self-driving lab architecture guide.

The Reference Architecture: Five Layers From Protocol to Pipette

Laboratory automation orchestration decomposes cleanly into five layers, each with a narrow contract to the layers above and below. From top to bottom: a protocol layer where experiments are written as code, a workflow engine that holds the experiment queue and expands protocols into task graphs, a scheduler that assigns tasks to instruments in time, a device-abstraction layer that presents every instrument through a uniform interface, and the connectivity drivers — SiLA 2 servers, OPC UA LADS nodes, or vendor adapters — that translate abstract commands into wire protocol. A cross-cutting state store tracks samples, resources, and run history, and connects out to the ELN and LIMS.

Figure 1: The five-layer orchestration stack. Protocols flow down into a queue, the scheduler allocates instruments, and the device-abstraction layer routes commands to SiLA 2, OPC UA LADS, or vendor drivers while a state store tracks samples.

Read Figure 1 as a request pipeline. A protocol enters the workflow engine as a declarative description. The engine expands it into a directed task graph and places runnable tasks in the experiment queue. The scheduler pulls ready tasks, checks resource availability and timing constraints, reserves the instruments it needs, and dispatches commands through the device-abstraction layer. That layer does not know or care whether the plate reader speaks SiLA 2 or OPC UA — it holds a driver that does. Every state transition is written to the state store so that sample location, resource ownership, and run progress are always queryable. The clean seam between abstraction and driver is what lets you swap a Hamilton STAR for a Tecan Fluent without rewriting a protocol.

Why the abstraction seam is the whole game

The single most important design decision in the stack is where you draw the line between “what the experiment wants” and “how a specific instrument does it.” Draw it well and protocols become portable, testable, and durable across hardware refreshes. Draw it badly — leaking vendor-specific coordinates, timings, or error codes into protocol code — and every instrument change becomes a rewrite. PyLabRobot’s design thesis is exactly this: one hardware-agnostic interface with pluggable backends, so the same aspirate and dispense calls target a Hamilton STAR, a Hamilton Vantage, a Tecan Freedom EVO, or an Opentrons OT-2 by changing only the backend object. That is the abstraction seam made concrete.

The scheduler is not the workflow engine

A recurring confusion is treating scheduling and workflow orchestration as one thing. They are not. The workflow engine answers “what steps does this experiment consist of, and in what dependency order?” The scheduler answers “given ten experiments competing for one plate reader and two arms, which task runs on which instrument at which second?” The first is a graph-expansion and state-machine problem. The second is a constraint-satisfaction and resource-allocation problem, often with hard real-time deadlines. Conflating them produces schedulers that cannot reason about cross-experiment contention and workflow engines that stall the moment two protocols want the same device.

State is a first-class citizen, not a side effect

Autonomous runs fail at 3 a.m. with no human watching. The only way to recover gracefully is to have written down, durably and continuously, where every sample is, which instrument holds which resource, and how far each task has progressed. The state store is therefore not a log you consult after the fact — it is the authoritative record the scheduler and recovery logic read on every decision. Treat it as an event-sourced ledger: append immutable state transitions, derive current state by folding over them, and you get free audit trails, replay, and crash recovery.

Connectivity Standards: SiLA 2 vs OPC UA LADS vs Proprietary Drivers

The device-driver layer is where standards fights get real. In 2026 there are three credible ways to talk to an instrument, and most labs run a mix of all three.

SiLA 2 — Standardization in Lab Automation, second generation — is a service-oriented standard built on gRPC. It serializes payloads with Protocol Buffers and transports them over HTTP/2 (with QUIC on the roadmap in some implementations). An instrument exposes a SiLA Server; an orchestrator acts as a SiLA Client. Capabilities are described in a Feature Definition Language (FDL), an XML schema that declares a feature’s Commands, Properties, and metadata. The specification separates a stable Core part from a Mapping part that projects each feature onto concrete .proto definitions, so every command, property, and client-metadata item becomes one or more gRPC RPCs in a language-agnostic way.

SiLA 2’s most important design idea is the distinction between unobservable and observable commands. An unobservable command is a simple request/response RPC — good for “get temperature.” An observable command models a long-running operation: you initiate it, receive a CommandConfirmation carrying a CommandExecutionUUID, then subscribe to an ExecutionInfo stream that reports status and estimated remaining time, optionally subscribe to intermediate responses, and finally fetch the result by UUID. Discovery is handled with zeroconf/mDNS so servers announce themselves on the network, and transport security uses TLS. For payloads above 2 MB the standard defines a separate Binary Transfer mechanism rather than stuffing large blobs into a single message. Reference implementations include the open sila_python library and the royalty-free open-source Tecan SiLA2 SDK.

Figure 2: A SiLA 2 observable command. The scheduler initiates the command, receives a UUID, subscribes to the ExecutionInfo stream for progress, and retrieves the result by UUID when the instrument finishes.

Figure 2 shows why the observable-command pattern matters for orchestration. Because the scheduler holds a UUID and a live progress stream, it can display accurate ETAs, detect stalls, and make preemption decisions without polling blindly. The instrument owns the truth about its own progress and streams it upward. This is a far better fit for time-constrained assays than fire-and-forget calls that give you nothing until they either return or time out.

OPC UA LADS takes a different route. LADS — the Laboratory and Analytical Device Standard, published as OPC 30500 — is an official Companion Specification of OPC UA, the industrial-automation backbone. Instead of gRPC services it models a device as an information model in the OPC UA address space, with two views: a Hardware View describing physical components (useful for asset management and serviceability) and a Functional View describing operational data for monitoring, control, and orchestration. LADS exposes a defined set of high-level scenarios: monitoring and control, notifications, program and results management, asset management, and maintenance. Its lineage is the factory floor, so it inherits OPC UA’s mature security model, pub/sub, and its natural bridge to MES and Industry 4.0 systems.

Proprietary drivers are the third path and, honestly, still the most common for exotic or older instruments. A vendor SDK — a DLL, a serial protocol, a REST endpoint, a Python wrapper — gives you full fidelity to the instrument’s features but zero portability and often no formal capability description. The pragmatic architecture wraps each proprietary SDK behind the same device-abstraction interface as the standards-based drivers, so the rest of the stack never sees the difference. That is exactly how PyLabRobot’s Opentrons backend works: it drives the OT-2 through the Opentrons HTTP API under a uniform interface.

Here is the decision matrix most teams actually need:

Dimension	SiLA 2	OPC UA LADS (OPC 30500)	Proprietary SDK
Transport	gRPC over HTTP/2, Protocol Buffers	OPC UA binary / TCP, pub/sub	Vendor-specific (DLL, serial, REST)
Capability description	FDL (XML) features, commands, properties	OPC UA information model, Hardware + Functional views	Usually none formal
Discovery	zeroconf / mDNS	OPC UA discovery / GDS	Manual configuration
Security	TLS	OPC UA security profiles, certificates	Varies, often weak
Long-running ops	Observable commands with ExecutionInfo stream	Program management + notifications	Ad hoc polling
Lineage / ecosystem	Life-science lab automation	Industrial automation, MES / I4.0	Single vendor
Portability	High across compliant servers	High across compliant nodes	None
Best fit	New lab instruments, self-driving labs	Analytical devices bridging to factory / MES	Legacy or niche hardware

The honest architectural read: SiLA 2 and OPC UA LADS are complementary more than competitive. SiLA 2 is command-and-control ergonomics for lab workflows; LADS is rich device modeling with an industrial security and interoperability heritage. Several vendors are shipping both, and mapping efforts between the two exist. Do not architect for a winner-take-all outcome — architect the abstraction layer so it can hold a SiLA 2 driver, a LADS driver, and a proprietary wrapper side by side. Legacy SiLA 1, by contrast, was a different, more rigid design and is being superseded; treat it as a migration source, not a target.

Lab-as-Code: Declarative, Versioned, Reviewable Protocols

The phrase lab-as-code borrows directly from infrastructure-as-code, and the analogy is precise. Instead of a technician clicking through a GUI to configure a run — an act that is unversioned, unreviewable, and irreproducible — the experiment is expressed as code in a version-controlled repository. That code is diffable, peer-reviewable, testable in simulation, and re-runnable byte-for-byte. When a result is questioned six months later, you check out the exact protocol commit that produced it.

There are two broad flavors of lab-as-code. The first is an imperative Python SDK where you write procedural steps against a hardware-agnostic API. PyLabRobot is the leading open example: a pure-Python, hardware-agnostic library for liquid handlers, plate readers, pumps, scales, and heater-shakers that runs atomic commands interactively in a Jupyter notebook or the REPL, cutting iteration time from minutes to seconds. The Opentrons Python Protocol API is the vendor equivalent — you write a .py protocol that the Opentrons app or API server executes. The second flavor is a declarative protocol description — YAML, JSON, or a purpose-built DSL — that states what should happen and lets the workflow engine decide how. Declarative forms are easier to validate, schedule, and reason about; imperative forms are more expressive and easier to write interactively. Mature stacks often use both: a declarative outer protocol that references imperative steps.

A minimal PyLabRobot-style protocol makes the point concretely:

from pylabrobot.liquid_handling import LiquidHandler
from pylabrobot.liquid_handling.backends import HamiltonSTARBackend
from pylabrobot.resources import STARDeck, TIP_CAR_480, PLT_CAR_L5MD

# The backend is the only vendor-specific line.
lh = LiquidHandler(backend=HamiltonSTARBackend(), deck=STARDeck())
await lh.setup()

tips = lh.deck.get_resource("tip_carrier")["A1"]
source = lh.deck.get_resource("plate_carrier")["A1"]
dest = lh.deck.get_resource("plate_carrier")["A2"]

# Atomic, portable commands. Swap the backend and this runs elsewhere.
await lh.pick_up_tips(tips["A1:H1"])
await lh.aspirate(source["A1:H1"], vols=50.0)
await lh.dispense(dest["A1:H1"], vols=50.0)
await lh.drop_tips()

Note the property that matters: only the backend line names Hamilton. Change it to an OpentronsBackend and the same aspirate/dispense logic runs on an OT-2. That is lab-as-code delivering portability through the abstraction seam.

On the standards side, a SiLA 2 feature sketch shows how the connectivity layer describes itself. Conceptually, an FDL feature is XML that declares commands and properties; a simplified fragment reads:

<Feature Identifier="PlateReading" Category="analysis">
  <Command Identifier="MeasureAbsorbance" Observable="Yes">
    <Parameter Identifier="Wavelength"><DataType><Basic>Integer</Basic></DataType></Parameter>
    <Response Identifier="OpticalDensity"><DataType><Basic>Real</Basic></DataType></Response>
    <IntermediateResponse Identifier="WellProgress"><DataType><Basic>Integer</Basic></DataType></IntermediateResponse>
  </Command>
  <Property Identifier="CurrentTemperature" Observable="Yes">
    <DataType><Basic>Real</Basic></DataType>
  </Property>
</Feature>

Because that FDL maps deterministically to .proto files and gRPC RPCs, any compliant client can drive the instrument without a hand-written driver. The feature definition is the contract. This is the mechanism that makes SiLA 2 instruments interchangeable at the protocol level.

Versioning and reproducibility

Protocols under version control unlock the practices software teams take for granted: pull requests with peer review before a protocol touches real reagents, semantic versioning so a published result cites assay-v2.3.1, continuous integration that runs the protocol against a simulated deck on every commit, and rollback to a known-good version when a change misbehaves. For autonomous-science pipelines that generate hundreds of protocol variants under an optimizer, this is not optional hygiene — it is the only way to keep the provenance graph intact. Our write-up on Bayesian optimization for autonomous experiments depends on exactly this reproducibility to trust the objective values it optimizes against.

The Scheduler: List vs Dynamic Scheduling, Resources, and Deadlock

The scheduler is the hardest component to get right and the one that most distinguishes a toy demo from a production self-driving lab. Its job: take runnable tasks with dependencies, resource requirements, and timing constraints, and produce an assignment of tasks to instruments over time that is feasible, high-throughput, and safe.

Figure 3: A dynamic scheduler’s per-task decision loop. Ready tasks wait for free resources, must satisfy their time window, and pass a deadlock-risk check before the scheduler reserves instruments and dispatches the command.

The classic split is list scheduling versus dynamic scheduling. List (or static) scheduling computes the entire timetable up front: given the full set of experiments and instrument capacities, it solves an optimization problem and produces a fixed timeline. It maximizes throughput when everything runs to plan and gives you a predictable end time — invaluable for a fixed batch of screening plates. Its weakness is brittleness: the moment an instrument runs long, a tip pickup fails, or a new high-priority experiment arrives, the precomputed plan is stale and re-solving mid-run is expensive.

Dynamic scheduling makes decisions at runtime. As each task becomes ready, the scheduler checks current resource availability, validates timing constraints against the wall clock, and dispatches when it can — exactly the loop in Figure 3. It absorbs disruption gracefully and handles open-ended experiment queues where new work arrives continuously, which is the norm for a self-driving lab under an active optimizer. Its cost is lower peak throughput and weaker end-time guarantees, because greedy local decisions can leave the machine less densely packed than an optimal static plan. Most production systems are hybrid: a static plan for the known batch, a dynamic layer that repairs it as reality diverges.

Here is the decision matrix:

Property	List / static scheduling	Dynamic scheduling
When decided	Entirely up front	At runtime, per ready task
Throughput on plan	Higher, near-optimal packing	Lower, greedy packing
Disruption tolerance	Poor, replan is costly	High, absorbs delays naturally
End-time predictability	Strong	Weak
Open-ended queues	Poorly suited	Native fit
Best for	Fixed known batches	Self-driving labs, mixed priorities

Resource allocation and time-constrained assays

Beyond task ordering, the scheduler owns resource allocation. Instruments, gripper arms, deck positions, and transport robots are finite and often exclusive — two tasks cannot hold the same plate reader. Many assays add hard timing constraints: a cell-based readout must occur within a tight window after reagent addition, an incubation must last a minimum time, a kinetic measurement must sample at fixed intervals. A scheduler that treats these as soft preferences will silently corrupt results. Time-constrained steps must be modeled as hard constraints that gate dispatch, and the scheduler must reserve downstream instruments before starting an upstream time-critical step, so it never begins a reaction it cannot finish reading in time.

Deadlock and starvation

Because tasks acquire multiple exclusive resources — an arm to move a plate, the destination instrument, a free deck slot — the scheduler faces the classic conditions for deadlock: two tasks each holding one resource and waiting for the other. Figure 3’s deadlock-risk check is where a production scheduler runs a wait-for-graph cycle test or applies resource-ordering to prevent circular waits, rolling back and releasing when it detects risk. The dual hazard is starvation: a low-priority task that never wins contention because higher-priority work keeps arriving. Aging — gradually raising a waiting task’s effective priority — is the standard remedy. Neither problem shows up in a two-instrument demo; both are inevitable at scale.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes of laboratory automation orchestration are specific, and every one of them has ruined an overnight run somewhere.

Instrument timeouts. An instrument that stops streaming ExecutionInfo — because its firmware hung, its network dropped, or it is genuinely stuck — looks identical to one that is merely slow. Set timeouts too tight and you abort healthy long assays; too loose and a hung instrument holds the whole schedule hostage. The mitigation is layered: liveness heartbeats separate from progress, per-command expected-duration bounds, and a supervisor that can safely abort and requeue. SiLA 2’s observable commands help because the ExecutionInfo stream carries estimated remaining time, giving the supervisor a baseline to judge against.

Collisions. A robotic arm moving a plate into a deck position occupied by another plate is a physical crash — bent grippers, spilled samples, a down day. Orchestration cannot fully prevent this without accurate world state, which is why the state store must reflect physical reality, not intended reality. If the software thinks a slot is empty because a prior move was recorded as complete but the plate never actually landed, the next move collides. Interlocks and motion-planning collision checks are the last line of defense; correct state is the first.

Sample-tracking loss. The worst silent failure is a run that completes and produces data attributed to the wrong sample. A mislabeled barcode, an uncommitted state transition after a crash, or an off-by-one in a plate-reformatting step can permanently sever the link between a result and its sample. This is why sample tracking must be transactional: the physical move and the state update either both commit or both roll back, and every sample carries an immutable identifier verified by barcode or vision at hand-off points.

Scheduling starvation and priority inversion. As covered above, greedy schedulers starve low-priority work and can invert priorities when a low-priority task holds a resource a high-priority task needs. These are not exotic — they are the default behavior of a naive scheduler under load.

Stale or partial state after a crash. If the orchestrator process dies mid-task, recovery depends entirely on how state was persisted. An event-sourced ledger with a durable checkpoint lets you reconstruct exactly where you were; a mutable in-memory state does not survive the crash at all. The anti-pattern is keeping run state in RAM and writing only summary logs — you cannot resume from a summary.

Figure 4: Error recovery with hold-and-resume. Timeouts retry with backoff, collisions trigger a safe-stop interlock, lost samples are quarantined, and unrecoverable states hold at a checkpoint for human review before resume or rollback.

Figure 4 is the recovery discipline every serious orchestrator implements. Not all errors are equal: a transient timeout deserves a bounded retry with exponential backoff; a collision must trigger an immediate safe-stop through the interlock system, not a retry; a suspected sample-tracking loss must quarantine the affected samples rather than proceed. When automated recovery is unsafe or ambiguous, the correct behavior is hold-and-resume — checkpoint the full run state, pause, and surface the decision to a human. This is where human-in-the-loop and safety interlocks stop being buzzwords: the interlock is a hardware-enforced boundary the software cannot override, and the human review gate is a first-class scheduler state, not an exception handler bolted on later.

Digital Twins, Simulation, and Human-in-the-Loop

A mature orchestration stack ships with a digital twin of the lab — a simulation of the deck, instruments, and timing that runs the exact same protocol code against virtual hardware. This is the CI test bed for lab-as-code: every protocol commit runs in simulation before it ever touches reagents, catching collisions, timing violations, and resource conflicts for free. PyLabRobot and Opentrons both support simulation modes precisely so protocols can be validated without hardware. A good twin models not just geometry but timing and stochastic failure, so the scheduler can be stress-tested against instrument delays and error injection before deployment. The same twin doubles as a what-if planner: estimate throughput for a proposed batch, or check whether a new instrument relieves a bottleneck, without touching the physical lab. For how simulation feeds broader autonomous pipelines, see our autonomous materials discovery pipeline reference.

Human-in-the-loop is not a failure of automation — it is a deliberate design choice for steps where the cost of an autonomous mistake exceeds the cost of a pause. Approval gates before consuming scarce reagents, review of anomalous results before they feed an optimizer, and mandatory sign-off on safety-relevant transitions all belong in the orchestrator as explicit workflow states with their own audit trail.

ELN and LIMS Integration: Closing the Data Loop

Orchestration that produces data no system can find has failed the FAIR test. The ELN (Electronic Lab Notebook) captures experimental intent, context, and human observations; the LIMS (Laboratory Information Management System) manages samples, inventory, and results at scale. The orchestrator sits between them and the instruments, and its job is to keep the whole chain consistent: a sample registered in the LIMS is the same sample the scheduler moves and the same sample the result attaches to.

Integration is bidirectional. Inbound, the LIMS supplies the sample manifest and metadata that a protocol consumes — which wells hold which samples, what tests each requires. Outbound, the orchestrator writes structured results, instrument metadata, timestamps, and full provenance back to the LIMS and ELN. The hard part is identity and provenance: every result must carry the sample ID, the protocol version, the instrument serial, the operator or agent, and the exact time, so the data is reproducible and auditable. This is where the state store earns its keep again — it is the source of truth the LIMS integration reads from, not a parallel record that can drift. Both SiLA 2 (FAIR-oriented by design) and OPC UA LADS (with its program-and-results-management scenario) are built to emit this structured provenance rather than opaque instrument files.

Practical Recommendations

Build the abstraction seam first and defend it ruthlessly. The single highest-leverage decision is a clean device-abstraction interface that hides whether an instrument speaks SiLA 2, OPC UA LADS, or a proprietary SDK. Everything above it — scheduler, workflow engine, protocols — should be testable against a simulator with zero real hardware. If your protocol code names vendor coordinates or error codes, the seam has leaked; fix it before you scale.

Treat protocols as software from day one: version control, peer review, semantic versioning, and CI against a digital twin. Make state event-sourced and durable so any crash is recoverable and every result is auditable. Model time-constrained steps and exclusive resources as hard constraints, not preferences, and build deadlock detection and starvation aging into the scheduler before you have ten instruments, not after.

A pragmatic adoption checklist:

Pick standards deliberately: prefer SiLA 2 or OPC UA LADS for new instruments; wrap legacy hardware behind the same abstraction interface.
Separate scheduler from workflow engine: one allocates instruments in time, the other expands protocols into task graphs.
Make the state store authoritative: event-sourced, durable, the single source for scheduling, recovery, and LIMS.
Simulate before you run: every protocol passes the digital twin in CI before touching reagents.
Classify errors by recovery type: retry, safe-stop, quarantine, or hold-for-human — never a single generic handler.
Enforce interlocks in hardware: safety boundaries the software cannot override.
Carry provenance end to end: sample ID, protocol version, instrument serial, timestamp on every result.

Frequently Asked Questions

What is laboratory automation orchestration?

Laboratory automation orchestration is the software control plane that coordinates heterogeneous lab instruments — liquid handlers, plate readers, robotic arms, mobile robots — so they execute an experiment as one programmable system. It spans a protocol layer, a workflow engine holding the experiment queue, a scheduler that allocates instruments across time and constraints, a device-abstraction layer, and connectivity drivers such as SiLA 2 or OPC UA LADS. A cross-cutting state store tracks samples and resources and connects to the ELN and LIMS, making autonomous, recoverable, reproducible runs possible.

How does SiLA 2 differ from OPC UA LADS?

SiLA 2 is a life-science lab-automation standard built on gRPC and Protocol Buffers over HTTP/2, describing instrument capabilities as FDL features with commands and properties, and offering observable commands for long-running operations. OPC UA LADS (OPC 30500) is a Companion Specification of industrial OPC UA that models a device as an information model with Hardware and Functional views, inheriting OPC UA’s security and MES interoperability. They are complementary: SiLA 2 excels at command-and-control ergonomics for lab workflows; LADS excels at rich device modeling and bridging to factory and Industry 4.0 systems.

What is lab-as-code?

Lab-as-code applies infrastructure-as-code discipline to experiments: protocols are written as version-controlled code rather than configured through a GUI. That makes them diffable, peer-reviewable, testable in simulation, and reproducible byte-for-byte. It comes in imperative form — Python SDKs like PyLabRobot or the Opentrons Protocol API — and declarative form, using YAML, JSON, or a DSL that a workflow engine interprets. The payoff is provenance: a published result cites the exact protocol commit that produced it, which is essential for autonomous pipelines that generate many protocol variants.

What is the difference between list and dynamic scheduling?

List (static) scheduling computes the full timetable up front, maximizing throughput and giving a predictable end time for a fixed batch, but it is brittle when reality diverges from the plan. Dynamic scheduling decides at runtime as each task becomes ready, absorbing disruptions and handling open-ended queues naturally at the cost of lower peak throughput and weaker end-time guarantees. Most production self-driving labs run a hybrid: a static plan for the known batch and a dynamic repair layer that reschedules as instruments run long or new high-priority work arrives.

How do self-driving labs recover from errors overnight?

They classify errors by recovery type and act accordingly. Transient instrument timeouts trigger bounded retries with exponential backoff; collisions trigger an immediate safe-stop through hardware interlocks rather than a retry; suspected sample-tracking loss quarantines the affected samples. When automated recovery is unsafe or ambiguous, the orchestrator holds and resumes — it checkpoints full run state, pauses, and surfaces the decision to a human review gate. This depends on durable, event-sourced state so that after any crash the run can be reconstructed and resumed rather than lost.

Why is the device-abstraction layer so important?

The abstraction layer is where you separate what an experiment wants from how a specific instrument does it. A clean seam makes protocols portable across hardware — the same aspirate and dispense calls run on a Hamilton STAR or an Opentrons OT-2 by changing only a backend — and testable against a simulator with no real hardware. A leaky seam, where vendor coordinates, timings, or error codes reach protocol code, turns every instrument swap into a rewrite. It is the single design decision that most determines whether the stack survives a hardware refresh.

Laboratory Automation Orchestration: SiLA 2 and Lab-as-Code (2026)