For most of the last three decades, a laboratory’s software lived in silos almost as rigid as its physical bench space. That separation is dissolving — not because vendors decided it should, but because an open communication standard finally made it technically possible.
To understand why that matters, it helps to be precise about what each system actually does, because the terms get used loosely even inside laboratories that run all three.
A Laboratory Information Management System (LIMS) is, at its core, a system of record for samples and workflow. It tracks what a sample is, where it is in the testing process, what tests have been ordered against it, who is responsible for each step, and what the results were — functioning as the backbone against which a laboratory’s operational and compliance activity gets organised. An Electronic Lab Notebook (ELN), by contrast, is built around documentation of scientific work itself: methods, protocols, observations, the narrative of what a scientist actually did and why, in a form more analogous to a structured, searchable, auditable diary than a workflow tracker. Connected instruments are the third piece — analytical hardware (chromatographs, spectrometers, balances, sequencers) wired directly into software so that readings flow into a system of record automatically, rather than being transcribed by hand from an instrument’s display screen into a LIMS or notebook entry.
Historically, these three categories were built, sold, and operated as separate products, often by separate vendors, frequently unable to talk to one another without custom, expensive, brittle integration work. A laboratory might run a LIMS from one company, an ELN from another, and instruments from a dozen manufacturers, each with its own proprietary output format — and stitching them together was, for a long time, a bespoke engineering project rather than a configuration exercise.
Why the Wall Is Actually Coming Down
The convergence now underway is often described in vendor marketing as simply a matter of modern platforms being “unified” or “integrated” — language that makes it sound like a product decision. The more accurate, and more interesting, explanation is structural: an open, vendor-neutral communication standard has matured enough to make convergence technically straightforward rather than a custom-engineering burden.
That standard is called SiLA — Standardisation in Laboratory Automation — now in its second major version, SiLA 2. Built on modern web technologies (gRPC over HTTP/2, with Protocol Buffers as the data format), SiLA 2 defines what’s called a Feature Definition Language: a machine-readable, typed description of exactly what commands and data an instrument or software service can offer, and how to call them. In practical terms, this means a SiLA 2-compliant instrument can describe its own capabilities to any SiLA 2-compliant software system automatically, without a programmer manually mapping one vendor’s output format to another’s input requirements — the kind of undocumented, one-off mapping work that has historically made laboratory system integration slow and fragile. For the transfer and long-term storage of the analytical data itself, SiLA 2 pairs with a separate ASTM standard called AnIML (Analytical Information Markup Language), which represents completed measurement results in a structured, audit-trail-friendly format suited to regulated environments.
This is a meaningfully different story from “the vendors decided to work together.” A peer-reviewed analysis of laboratory automation standards published in Clinical Chemistry traces the lineage back further: the American Society for Testing and Materials had attempted to standardise instrument-to-computer communication as early as the 1990s, through a standard known as ASTM 1394, but that early effort focused narrowly on process instructions and never solved the deeper problem — that different instruments, even performing similar functions, used incompatible command sets, different connection architectures, and inconsistent error-handling, making genuine plug-and-play integration impractical. SiLA 2 is best understood as the standard that finally addressed that deeper compatibility problem directly, rather than working around it.
A Convergence With Real Boundaries
It would be a mistake, though, to read this convergence as complete, or as evidence that laboratory software has become a solved problem. A recent academic analysis of agent-to-instrument protocols, examining SiLA 2’s actual technical scope, found real limits: the standard’s capability descriptions are fixed at design time, with no mechanism for a system to negotiate capabilities at runtime, no structured way to express physical safety limits or hazard classifications, and — notably, given how much of the industry conversation now centres on artificial intelligence — no provisions at all for AI or large-language-model integration. SiLA 2 solved the instrument-to-software communication problem. It was never designed to solve the very different problem of software reasoning intelligently about what an instrument’s data means.
That distinction matters for what comes next in this Cover Story. The convergence of LIMS, ELN, and connected instruments into shared platforms is a real, technically grounded shift, not a marketing narrative — but it describes the plumbing getting better connected, not the emergence of intelligence sitting on top of that plumbing. Those are two separate developments, frequently blurred together in vendor language, and worth keeping apart. The next question — what artificial intelligence is actually doing inside that now better-connected laboratory, as opposed to what it is being marketed as doing — is where this story turns next.
– Sonali Chowdary Kollu
