'Talking to Instruments': What a New Paper Says About Device Integration

Lab device interfaces have been overlooked for a long time. From a lab's perspective, integrators took care of that somehow in the background, leading to very costly projects and ever-expanding project scope and timelines.

So academics had no choice but to hack away and build it themselves, while the industry gradually built up internal teams to develop and maintain drivers. Everyone was (and to a large extent still is) doing the same work over and over again, but the business case wasn't large enough for a major change in how the industry works as a whole.

Why? Because this is a far more complex problem than you might think at first glance, and the return for solving this complexity was not large enough for any of the individual stakeholder groups facing the pain. Plus the problem was often too hard to put into numbers.

Hence device communication and control standards were slow, but steady, in terms of adoption.

AI is the tailwind we needed. It became clear that the bottleneck in scientific discovery has shifted to validation in the lab, and to lab automation and ultimately connectivity, interoperability, and a common language and model to describe the lab. Device interfaces are a good portion of that.

We need to build a lab infrastructure that provides surfaces for AI to operate safely within this complex environment. Device connectivity and the interfaces involved are thus super important for us, and dear to my heart.

Which is why I’m excited to be one of the co-authors on a brand-new paper called ‘Talking to Instruments: Device-Integration Standards for Self-Driving Laboratories’.

Willi Gottstein led the group of nearly 50 contributing experts from the Acceleration Consortium, SiLA Consortium, the LADS OPC UA working group, Merck, Argonne, BAM, EPFL, and more.

Read the preprint edition on ChemRxiv.

Key Findings: Glue Code and Custom Integrations

Most lab equipment is still built for a person sitting at a Graphical User Interface (GUI) of a vendor software.

Getting it into an autonomous workflow means custom glue code that rarely survives a move to another lab, let alone being shared and reused by colleagues or the industry. In fact, one nanomaterials lab in our review had no API at all, so it faked keyboard and mouse input against the vendor's software.

For this paper, we analyzed the source code of 17 open-source orchestrators.

While many of them are actively working to integrate support for the SiLA standard, only a small minority use a formally governed device standard at present.

The rest write their own drivers, so the same instrument gets integrated again for every orchestrator. Here’s the full list of orchestrators we looked at:

AlabOS; ARES OS 2.0; Bluesky + Ophyd; Chemios; ChemOS 2.0; EOS; GLAS; HELAO-async; IvoryOS; MADSci; MINERVA-OS; NIMO; OChRA; OCTOPUS; PLACE; RoboChem-Flex / OmniPlatypus; UniLabOS.

I know where these orchestrators are coming from. During my PhD time at TUM Munich, I was in the same position. I had to build a dynamic scheduler for a bioprocessing workcell with a liquid handler operating 48 bioreactors at the same time, while managing larger-scale bioreactors and periphery as well.

No software existed for that and that is how I got involved in standardisation. The fancy term Self-Driving Lab didn't exist back then, but the problem did.

Cables and transport protocols mostly work. The gap sits one layer up, where every vendor invents its own commands, parameter conventions, and error messages. And in most cases, doesn’t expose or document them properly.

Interfaces are treated as second-class citizens by vendors, and I can understand why: there are too many cooks in the kitchen, too many opinions. Hardware vendors need requirements that they can develop against.

Customers, software vendors, and integrators all have different requirements and building an interface that suits the needs of all of them is quite a project that requires intricate expertise how the devices will be used and integrated in all of those scenarios.

The Standards That Already Exist

SiLA 2 and OPC UA LADS are the closest existing standards to what autonomous labs need. SiLA 2 is our default suggestion for multi-instrument academic labs.

In regulated pharma, where audit trails and enterprise integration matter, both are good options. The paper also covers REST, ROS 2, EPICS, and MCP, and where each one fits.

And of course, with big players such as Anthropic entering this space with their Model Hardware Standard (MHS), things are set to accelerate even further.

However, do not think that MHS will solve the integration and interface problem. MHS requires a well-defined interface, and someone putting in the work to build and test it.

Testing is actually most of the work, and that requires device access and access to all models, firmware versions, and configurations of a device.

It's another way the interface is exposed, and is complementary to standards like SiLA and OPC UA, rather than a replacement. I saw a lot of false hope already.

A 21-Point Scorecard for Buyers

The part I'm most excited about is the Autonomous-Ready Scorecard: 21 criteria written in MUST and SHOULD language, each with a test that buyers can run during a pilot.

Fail one of the five critical criteria and the instrument is out, however well it scores elsewhere. One of them goes after API paywalls and contracts that stop labs from publishing their own driver code.

Here are all 21. Criteria 1 to 5 are critical, 6 to 18 are important, and 19 to 21 only apply when a robot or other machine works with the instrument.

1. Programmatic control over the network (CRITICAL). The orchestrator can drive the instrument through a documented, supported network endpoint. If the connection drops, it can reconnect and see where the running operation stands.
2. Strong typing with units and constraints (CRITICAL). Every input and output has a type, unit, allowed range and precision that software can read. The instrument validates values at runtime and reports which defaults it applied.
3. Structured error reporting (CRITICAL). Errors are declared up front and come back as typed objects with a message, context and a timestamp. Software can act on them without parsing free text.
4. Open API access (CRITICAL). Baseline API access for autonomous use comes with the instrument, with no deployment royalties on top. Labs can reuse and publish the integration code they write themselves.
5. Results retrievable through the control interface (CRITICAL). Outcomes, measurement data and metadata come back over the API, with no vendor GUI involved (Ideally not even some intermediary software). Each result is clearly linked to the run that produced it.
6. Runtime self-description. The instrument reports what it can do while it runs. That description matches the firmware, hardware and modules actually installed.
7. Observable command and property state. Long-running commands report status and progress while other calls keep working. Orchestrators can subscribe to property changes and events.
8. Reference client implementation. The vendor ships a working client, a generated client or protocol examples. The examples cover both a basic call and a realistic workflow.
9. Concurrent-access discipline. Only one controller holds the instrument at a time, through atomic locking or a documented exclusion rule. Ownership, lease timeouts and reconnect behavior are all specified.
10. Machine-readable device and readiness state. The instrument exposes named operational states such as idle, busy or error. The recovery paths between those states are machine-readable too.
11. Durable, addressable results. Results have stable IDs tied to the run and survive a restart. Partial results from interrupted runs stay retrievable where that applies.
12. Instrument self-state. Calibration and qualification status, usage counters and configuration are readable through the API. So are out-of-spec warnings.
13. Versioning discipline. Labs can pin a version, and the vendor publishes its versioning and deprecation policy. Support commitments match how the instrument is deployed.
14. Simulation or emulation mode. A drop-in simulator lets teams build and test workflows without the hardware. Configurable fault injection means error handling gets tested too.
15. Control-loss observability. The instrument detects and reports when it loses its controlling session. Any automatic response to that loss stays configurable.
16. Error recovery taxonomy. Each error says whether it is transient, what it did to the run and what state the instrument is now in. It also gives a recovery class and flags any physical motion involved.
17. Conformance and certification. The vendor provides version-specific evidence that the interface conforms to its protocol. The same goes for the device model it implements.
18. Operating-system independence. The interface is reachable over the network from any OS, or runs on an open server OS. Host dependencies and support windows are disclosed.
19. Automated load and unload. A machine can load and unload labware, with documented handoff points and collision geometry. The instrument signals in a machine-readable way when it is ready or done.
20. Access and motion-readiness coordination. Door, motion and labware-presence states are accurate and consistent with each other. Where applicable, a local signal tells a robot when it can safely reach in.
21. Safety-event participation. Hardware emergency stops are latched and reported, and clearing them follows defined behavior. The orchestrator can also trigger a timed, controlled shutdown.

→ If you buy instruments, put the scorecard into your next RFP.

→ And if you build instruments, treat it as a spec for what labs will ask you for.

What About AI Agents?

As we all hopefully know by now, an LLM agent driving an instrument through MCP is only as safe as the interface beneath it. Don't get me started on device state and the context a device is used in…

Agents change who sends the commands. The need for typed, observable, versioned interfaces remains the same, however.

Why This Matters

Device integration is the work UniteLabs does every day.

We connect instruments from different vendors to one control and data layer and build a digital model of the lab and all its entities above that, and we maintain open-source SiLA 2 tooling that other teams build on (see our docs for more info on connector development).

Every instrument that ships with a typed, documented, open interface is one we can integrate once and reuse in every lab that runs it.

Every instrument without one sends our customers back to custom glue code, with all the cost and fragility the paper describes. So the more instruments pass the scorecard, the faster labs can automate, and the safer it becomes to hand control to software and AI agents. It also lets us focus on the intelligent layer that sits above. We do not want to be building connectors on the scale we are today in 10 years' time.

This also ties straight back to the UniteLabs ‘Lab of the Future’ manifesto, which declares that a lab exists to create data, and that control and data are to be treated as one thing and should run on the same infrastructure.

Neither principle holds up if every instrument speaks its own dialect. It's also why more pharma teams are telling us they want out of vendor lock-in (see here).

What's Coming Next

We want to test the paper’s scorecard on real instruments, so we’ll be running a global hackathon with the Acceleration Consortium and the SiLA Consortium, taking place on 20–22 October in multiple locations around the world, including the UniteLabs HQ in Munich.

If you work on device integration, come join us: Register here.

And if you’re interested in building your own self-driving lab, drop us a line.

Credits

Thanks must go to my fellow co-authors:

Willi Gottstein, Matthias Arnold, Sina Barazandeh, Joseph S Brown, Keith A. Brown, Ivano E. Castelli, Patrick Courtney, Basita Das, Martin Fitzner, Tobias Ginsburg, Aldair E. Gongora, Sang Soo Han, Annica Heyne, Georg Hinkel, Kedar Hippalgaonkar, Sergei V. Kalinin, Nicholas Kleiner, Christian Knittl-Frank, Jose Lugo-Martinez, Benji Maruyama, Pascal Miéville, Ankush Kumar Mishra, Timothy Noël, Ozlem Ozcan, Noah Paulson, Ilja Porohovoj, Mark Z. Porter, Zekun Ren, Harmen M. van Rossum, Bastian Ruehle, Samuel Vitor Saraiva, Elia Savino, Philippe Schwaller, Woosuck Shin, Joshua W. Sin, Eric T. Sletten, Arthur Sloan, Tomasz M. Stawski, Casey Stone, Ryo Tamura, Dean Thomas, Tejs Vegge, Robert Waelder, Ilya Yakavets, Hyuk Jun Yoo, Naruki Yoshikawa, and Sergio Pablo-García.