Controlling Lab Instruments From Your Browser: SiLA 2 Without the Integration Headache

TL;DR

Every instrument in your lab ships with its own proprietary software. None of them talk to each other. None of them integrate with your LIMS. Connecting them typically means hiring integrators, writing custom middleware, or living with disconnected silos. SiLA 2 (Standardization in Lab Automation) is an open industry standard that changes this: it defines a common protocol for how instruments expose their capabilities — commands, properties, errors — so any SiLA 2 client can discover, control, and monitor any SiLA 2 server, regardless of vendor. The standard uses gRPC over HTTP/2 with Protocol Buffers for efficient, type-safe communication, and its Feature Definition Language (FDL) allows instruments to describe themselves dynamically. AILabAssistant includes native SiLA 2 v1.1 support — so if your instrument speaks SiLA 2, you can connect to it, browse its features, execute commands, and monitor properties from your browser, without middleware or custom integration projects.

---

Here's a scene that plays out in laboratories every single day. You walk into the lab and count the screens. The plate reader has a laptop running the vendor's software — Windows only, naturally. The liquid handler has its own PC with a different application. The HPLC system has a third. The PCR thermocycler has a touchscreen that can't export data to anything except a USB stick. And the mass spectrometer has a proprietary workstation that nobody is allowed to touch because the last software update broke something and the vendor took three weeks to fix it.

None of these instruments know the others exist. None of them feed data into your LIMS automatically. And if you want to build a workflow that spans more than one instrument — run a protocol on the liquid handler, transfer samples, start an assay on the plate reader, pull the results into your project record — you do it manually. Walk to one screen, click buttons, write down a sample ID, walk to the next screen, type it in again. Maybe copy a CSV file to a shared drive and hope someone picks it up.

This is the state of laboratory instrumentation in 2026. Not because the instruments themselves are bad — they're extraordinarily capable. But because every vendor builds its own communication layer, its own data model, its own control interface, and none of them have any incentive to standardize. The result is that integrating instruments into a unified lab informatics environment is either prohibitively expensive or simply not done.

SiLA 2 exists to fix this.

What SiLA 2 Actually Is

SiLA stands for Standardization in Lab Automation. It's an international non-profit consortium (sila-standard.org) made up of instrument vendors, software companies, pharmaceutical firms, and research institutions. Their output is a specification — currently at version 1.1 — that defines how lab instruments and software should communicate.

The core idea is simple: separate what an instrument can do from how you control it.

In the SiLA 2 model, every instrument (or software service) runs a SiLA Server that exposes its capabilities as Features. A Feature is a bundle of functionality: the Commands you can execute (like "start a measurement" or "move to position"), the Properties you can read (like "current temperature" or "instrument status"), and the Data Types the instrument works with. Each Feature is formally described in a Feature Definition Language (FDL) document — an XML schema that a client can read to understand exactly what the instrument offers, what parameters each command accepts, and what data types it returns.

On the other side, a SiLA Client — your LIMS, your automation platform, your browser-based interface — connects to the server, reads the FDL to discover what's available, and interacts with the instrument using a standardized protocol.

The protocol itself is gRPC running over HTTP/2, with data serialized as Protocol Buffers. This is the same communication framework used by Google, Netflix, and most modern microservice architectures. It's fast, strongly typed, supports bidirectional streaming, and has mature libraries in every major programming language.

If this sounds like "USB for lab instruments" — that's roughly the right mental model. USB standardized how peripherals connect to computers. Before USB, you had serial ports, parallel ports, proprietary connectors, and driver compatibility nightmares. After USB, you plug something in and it works. SiLA 2 aims to be the equivalent for lab instrument communication.

Why the Current Situation Is as Bad as It Is

The instrument connectivity problem isn't caused by any single vendor being unreasonable. It's a structural issue with three interlocking causes.

Cause 1: Every vendor builds from scratch. When Thermo Fisher, Agilent, Beckman Coulter, or Hamilton develop a new instrument, each company designs its own communication interface. Maybe one uses REST APIs. Another uses TCP sockets with a proprietary binary protocol. A third uses OPC UA. A fourth ships a COM/DCOM interface that only works with specific Windows versions. There's no shared foundation, so even instruments that do essentially the same thing — like plate readers from two different manufacturers — expose their capabilities in completely different ways.

Cause 2: Integration is a revenue center. For many instrument and middleware companies, integration services are a significant business. A custom connector between your HPLC and your LIMS might cost $50,000–$200,000 in professional services. If instrument communication were standardized, that revenue stream would evaporate. This creates a structural disincentive against open protocols — not because individual engineers prefer closed systems, but because the business model depends on them.

Cause 3: Lab IT is underinvested. Most labs don't have dedicated IT staff. The "IT person" is a scientist who happened to be good with computers and got voluntold into the role. In that environment, the pragmatic solution is to accept vendor silos: each instrument runs its own software, data gets copied around on USB sticks and shared drives, and nobody attempts integration because the activation energy is too high. The problem is invisible until audit time, when tracing a result back through three instruments and two manual transcription steps becomes an exercise in forensic archaeology.

The result is that even well-funded laboratories — pharma QC labs, CROs, large academic research centers — often operate with essentially zero instrument-to-LIMS integration. The instruments are modern. The connectivity is pre-internet.

How SiLA 2 Solves This

SiLA 2 addresses the structural problem by defining the communication layer that vendors can implement instead of inventing their own. Three design decisions make it work in practice.

1. Dynamic Feature Discovery

When a SiLA 2 client connects to an instrument, it doesn't need to know in advance what the instrument does. The client calls the mandatory SiLAService Feature — which every SiLA 2 server must implement — and retrieves the server's identity, version, and list of available Features. For each Feature, the client can request the FDL document, which describes every Command, every Property, every Parameter, and every Data Type in machine-readable XML.

This means a single client implementation can interact with any SiLA 2 instrument — a plate reader, a liquid handler, a thermocycler, a centrifuge — without knowing at compile time what kind of instrument it's talking to. The client builds its interface dynamically from the FDL. Add a new instrument to your lab? If it speaks SiLA 2, your platform discovers its capabilities automatically.

2. Observable Commands and Property Subscriptions

Lab instruments frequently run operations that take minutes to hours — incubation cycles, chromatography runs, centrifugation protocols. SiLA 2 handles this with Observable Commands, which use a three-step RPC pattern:

1. Initiate: The client sends the command parameters. The server returns an execution UUID immediately — the call doesn't block.
2. Subscribe to progress: The client opens a server-streaming RPC using the execution UUID. The server sends status updates, progress percentages, and estimated remaining time as they become available.
3. Retrieve result: When the command completes, the client fetches the final result using the same execution UUID.

This is fundamentally different from the "send command → wait → get result" model that most instrument APIs use. It means your LIMS can track a 45-minute incubation cycle in real time — showing a progress bar, logging status transitions, and detecting failures as they happen — rather than polling periodically and hoping nothing went wrong between checks.

Property Subscriptions work similarly. Instead of repeatedly asking "what's the current temperature?" every few seconds (polling), you subscribe once and the server pushes updates whenever the value changes. This is more efficient, lower latency, and scales better when you're monitoring dozens of properties across multiple instruments.

3. Server-Initiated Connections

Most lab networks are behind NAT and firewalls. In the traditional client-initiated model, the client connects to the instrument server — which means the instrument needs an accessible IP address and the firewall needs to allow inbound connections on the gRPC port. In many lab environments, this is a non-starter: the IT department will not open inbound ports to instrument PCs, full stop.

SiLA 2 v1.1 added Server-Initiated Connection mode to solve this. In this mode, the instrument (server) initiates an outbound connection to the platform (client), establishing a bidirectional gRPC stream. Commands flow from the platform to the instrument through this stream; responses flow back. The instrument initiates the TCP connection, so no inbound firewall rules are needed.

This is a significant practical detail. Without server-initiated connections, deploying SiLA 2 in a real lab network often requires network infrastructure changes that lab managers have no authority to make.

4. A Proper Error Model

Anyone who's ever debugged an instrument integration knows the pain of generic error messages. "Error code 7." "Communication failure." "Unknown error." SiLA 2 specifies a structured error taxonomy with three distinct categories:

• ValidationError — the parameters you sent were invalid (wrong type, out of range, missing required field). The instrument tells you exactly which parameter failed and why.
• DefinedExecutionError — the command was valid but the instrument can't execute it for a known reason (door open, reagent empty, temperature out of range). These are errors the Feature designer anticipated and documented in the FDL.
• UndefinedExecutionError — something unexpected went wrong during execution. The instrument provides whatever diagnostic information it can.

Each error type carries structured metadata — not just a string message, but typed fields that a client can parse and act on programmatically. Your LIMS can distinguish between "the user made a typo in the volume parameter" and "the instrument arm is physically blocked" and respond differently to each.

Who's Actually Adopting SiLA 2?

SiLA isn't a paper standard. The consortium's membership includes instrument and software vendors you've heard of: Hamilton, Tecan, Beckman Coulter, Eppendorf, Thermo Fisher, Sartorius, BSSN Software, and several others. The full member list is public at sila-standard.org.

Adoption is strongest in life sciences automation — liquid handling, plate readers, incubators, and lab robotics. These are exactly the instrument categories where the vendor-lock-in problem is most acute: high-throughput labs that run multi-instrument workflows daily and where manual data transfer between systems is a genuine bottleneck.

The adoption curve is slower in analytical chemistry instrumentation (HPLCs, mass spectrometers, gas chromatographs), where established protocols like OPC UA and vendor-specific integrations have deeper roots. But the trend line is clear: new instruments are more likely to support SiLA 2 than old ones, and the labs buying them are increasingly asking about it.

If you're evaluating new instruments and standardized connectivity matters to you — and it should — ask your vendor directly: "Does this instrument support SiLA 2?" If the answer is no, ask when it will. The demand signal matters.

What This Looks Like in AILabAssistant

AILabAssistant includes native SiLA 2 v1.1 support as part of its Equipment Management module. The implementation follows the specification — gRPC-based communication with Protocol Buffers, full support for the SiLA 2 error taxonomy, observable command lifecycle, property subscriptions, binary transfer, metadata handling, and TLS security. Both client-initiated and server-initiated connection modes are supported.

Here's what you interact with:

Feature Browser. When you connect to a SiLA 2 instrument, the platform reads its FDL and displays every Feature the instrument exposes — commands, properties, data types, documentation. You don't need to know in advance what the instrument offers. The interface builds itself from the instrument's self-description.

Command Executor. Select a command, fill in the parameters (the platform generates typed input forms for all SiLA 2 data types — strings, integers, reals, booleans, dates, lists, structures, binaries, constrained values), and execute. For observable commands — the long-running operations that are common in lab automation — you get real-time progress tracking with visual status indicators and progress bars. Commands can be cancelled mid-execution.

Property Monitor. View instrument properties in real time. For observable properties, the platform subscribes to the instrument's update stream and displays values as they change — temperature curves, status transitions, sensor readings — with history tracking. For standard properties, you get on-demand reads.

Custom Dashboard Builder. This is where SiLA 2 integration feeds back into your daily workflow. You can attach instrument properties as widgets on a custom dashboard — choose from line charts, bar charts, scatter plots, area charts, pie charts, gauges, or heatmaps — configure axes and refresh intervals, and build a live monitoring view for your instrument fleet. A real-time temperature profile from your incubator next to the status of your liquid handler next to the progress of a plate reader assay — all in one browser tab.

Connection Configuration. Point the platform at your instrument's host and port, configure TLS if required, test the connection, and save. For instruments behind firewalls where inbound connections aren't possible, switch to server-initiated mode — the instrument connects out to the platform instead.

Because AILabAssistant is also a full LIMS, the instrument data doesn't exist in isolation. Command executions are automatically captured in the audit trail, so you have a complete record of what was run, when, by whom, and what came back. And since your equipment records, experiment logs, and sample tracking already live in the same platform, connecting the dots between an instrument run and the rest of your data is straightforward — no cross-referencing between disconnected systems.

What This Changes for Your Lab

If you're a lab manager or automation lead, here's the practical takeaway.

If you're buying new instruments, ask about SiLA 2 support. The more labs that ask, the faster vendors prioritize it. Check the SiLA consortium member list to see which vendors are already involved.

If you're planning an automation project, consider whether a SiLA 2-based approach makes sense versus a traditional point-to-point integration. The upfront investment in SiLA 2 infrastructure pays off when you add the second, third, and fourth instrument — each one connects the same way instead of requiring a new custom integration.

If you're already using AILabAssistant (or evaluating it), SiLA 2 support is built into the platform. You don't need a separate middleware product, a vendor-specific connector module, or a systems integrator. If your instrument speaks SiLA 2, you connect to it from the Equipment module and start working.

The broader trajectory is clear: the era of every instrument being an isolated island with proprietary software is ending. It's ending slowly, and it's ending unevenly across instrument categories, but it's ending. Standards like SiLA 2 are how it ends. The question for individual labs isn't whether to care about instrument interoperability — it's when.

We think the answer is now.

Want to see SiLA 2 instrument integration in action? Reach out at [email protected] or visit ailabassistant.com/demo to request a demo.

---

AILabAssistant's SiLA 2 v1.1 support — including protocol-compliant communication, observable command execution, property monitoring, custom dashboards, and both connection modes — is available as part of the Equipment Management module.