Walk into almost any automated lab and you will find instruments from several vendors expected to work as one system: a liquid handler from one company, a reader from another, a mover, a sealer, a storage unit, each speaking its own native dialect. The promise of automation is that they cooperate. The reality, without deliberate effort, is a set of islands connected by manual steps and brittle custom scripts. Interoperability is the work of turning those islands into a system, and it rests on a simple idea: if instruments and software agree on a common language, they can be combined freely instead of only in the pairings a single vendor chose to support.
This is an orientation to why interoperability matters, what a standard like SiLA contributes, and why the same vendor-neutral thinking applies to the liquid classes that run on all this hardware. The theme throughout is that openness is not a philosophical preference; it is what keeps a lab free to choose the best instrument for each job.
The cost of a siloed lab
When every instrument speaks only its own language, integration becomes a series of private bridges, and the costs compound quietly.
- Lock-in: it becomes easier to buy the next instrument from the vendor you already have, not because it is better but because it will talk to the others, which narrows your choices over time.
- Brittle integration: custom connections between two specific instruments break when either is updated, and maintaining them is a permanent tax on the automation team.
- Trapped data: results and methods live in vendor-specific formats that are awkward to move, compare, or archive in one place.
- Wasted expertise: staff learn one vendor deeply and start to see the world through it, which makes the lock-in self-reinforcing.
What SiLA and its kind provide
SiLA, standardization in lab automation, is an effort to give instruments a common way to be controlled and to exchange data, so that a scheduler can drive a device from any conforming vendor through the same interface. Alongside data formats like AnIML for results, the goal is a lab where a device can be swapped for a competitor without rewriting the whole integration, because both present the same standardized face to the software above them. You do not need to implement the standard yourself to benefit from it; you need to prefer instruments and software that speak it, so your lab accumulates interoperable parts rather than islands.
Liquid classes are part of the interoperability problem
It is easy to think of interoperability as a hardware and scheduling matter and stop there, but the method layer has the same problem. A liquid class expressed only in one vendor's proprietary format is another silo: it cannot be read, compared, or reused on another platform, so the knowledge of how to handle a difficult liquid stays trapped with the instrument it was written for. A vendor-neutral way to express what a class means, its liquid, its volumes, its tip and dispense intent, separated from the vendor-specific numbers, is the method-layer counterpart to what SiLA does for control. It lets the calibration knowledge move even when the hardware does not.
Interoperability is what keeps a lab free to buy the best instrument for each job rather than the one that happens to talk to the others. It applies to your methods as much as your machines.