Lab and factory interoperability has already been standardised three times — SiLA 2 shipped version 1.0 in 2019, OPC UA LADS was released in January 2024, ROS 2 is the de facto middleware for anything with joints — and instruments still arrive with a vendor SDK and a PDF. That history is the reason to be sceptical of a fourth specification, and also the reason Anthropic's Model Hardware Standard is interesting: it is the only one of the four that tries to write down what the machine must not be asked to do, in a form a caller can read, and to enforce it in the driver regardless of which model is driving.
At a glance
Four specifications that look like competitors on a feature list and were designed for different callers. Sorted by what each one assumes about whoever is issuing the command.
| Standard | Origin | Built for | Assumes the caller… |
|---|---|---|---|
| SiLA 2 | SiLA consortium; v1.0 in 2019 | Lab instruments, gRPC-based, feature-oriented | …is integration software written by someone who read the manual |
| OPC UA LADS | OPC Foundation; released January 2024 | Laboratory and analytical devices, on industrial OPC UA | …is another machine on a plant network |
| ROS 2 | Open Robotics ecosystem; de facto standard | Robots — nodes, topics, actions, controllers | …is a planner that already knows the kinematics |
| MHS | Anthropic; research preview, late August 2026 | Agents operating devices they have never seen | …is a model that will otherwise guess |
SiLA 2 — deep dive
A clean design that arrived slowly
SiLA is the lab-native answer: a consortium founded in 2008, a second-generation specification built on gRPC and Protocol Buffers, and a model in which a device advertises features — typed commands and properties, with defined errors — that a client discovers and calls. It is a good design and an approachable one for a software team, which is exactly what a laboratory integration group needs.
What eleven years bought
SiLA 2 version 1.0 landed in 2019, eleven years after the consortium formed, and the installed base still reflects that pace: a modest set of instruments from a limited number of manufacturers, with most of the market reached through wrappers rather than native support. This is the single most important fact about lab-automation standards and it applies to all of them — the specification was never the hard part. Getting a few hundred instrument vendors to ship conformant firmware, and to keep shipping it, is the hard part, and it is a commercial problem rather than a technical one.
OPC UA LADS — deep dive
Inheriting an installed base instead of building one
LADS takes the opposite route. Rather than a lab-specific protocol, it is a companion specification on top of OPC UA — the information-modelling and transport framework that industrial automation already runs on — released in January 2024. That inheritance is the entire strategic argument: OPC UA brings certificates, an address space, state machines, historical access and a vendor ecosystem that has been shipping conformant devices for years, and LADS supplies the laboratory-device vocabulary on top.
Modelled for a machine, not a reader
What you get is a rich, addressable description of a device: its components, its functional units, its state machines, its properties. What you do not get is an account of what a caller should not attempt. OPC UA's information model can hold engineering units and ranges where a vendor chose to populate them, but the semantics are oriented towards a SCADA client or a LIMS integration that has already been configured by an engineer. It is a language for saying what exists, not for saying what would be a mistake.
ROS 2 — deep dive
The one with real adoption, and a different shape
ROS 2 is not a device standard at all, which is why comparing it feels slightly unfair and is still necessary — it is where most people who actually move things with software already are. Its abstractions are nodes, topics, services and actions over a pub/sub middleware, with hardware reached through a controller stack rather than addressed directly. Anything with joints has a description file declaring links, joints and their limits, and the controller enforces those limits on every command.
Limits exist here, as numbers for a solver
That last point matters for the comparison, because ROS 2 is the incumbent that comes closest to encoding an envelope: joint limits, velocity and effort ceilings, collision geometry. But they are expressed for a motion planner, not for a caller trying to understand the device — there is no field that says this stage will crack a slide if you drive it past 40 mm with a plate loaded. And the scope is one robot cell configured by a roboticist, not a heterogeneous bench of instruments from eight vendors.
MHS — deep dive
What is actually new
Announced as a research preview in late August 2026, MHS defines how a device describes itself, how it is addressed, and which limits the driver itself enforces. The driver translates between the operating system and the device with primitives as plain as read and write, and it emits a reference file covering what the device can measure, what can be adjusted, and what safety limits will be enforced — populated in natural language, either by the person who owns the hardware or by an agent that interviews them about the setup. Anthropic frames it as a complement to MCP rather than a competitor: if MCP is how an agent reaches software tools, MHS is the missing layer beneath it.
The evidence so far, and what it is evidence of
The preview went out with partners spanning cloud, robotics and manufacturing — AWS, Universal Robots and Hugging Face among them — with open-sourcing planned after further safety evaluation. The published pilots are the usual shape for a preview: Genentech coordinating a protein assay across a liquid handler, a robotic arm and a plate reader; Carnegie Mellon reporting drug-discovery experiments running roughly three times faster. Integration time is claimed to fall from weeks or months to hours or minutes. Read those as existence proofs rather than benchmarks — they establish that the model works end-to-end on real hardware, and they say nothing yet about the tenth vendor, the awkward instrument, or the second year.
Cross-cutting comparison
All four solve addressing; only adoption decides anything
Line the four up on the axis they share and they are close to interchangeable: each gives you a way to discover a device, name its capabilities and issue typed commands with defined errors. SiLA 2 does it in gRPC, LADS in an OPC UA address space, ROS 2 in topics and actions, MHS in read/write against a driver. None of these differences will decide a purchase. What decides it is whether the instrument in front of you speaks the thing at all — and on that axis ROS 2 wins in robotics, LADS is inheriting a plant-floor ecosystem it did not have to build, SiLA 2 has spent a decade at modest coverage, and MHS starts at zero with a research preview and a shim story.
Only one of them writes down what the machine must not do
This is the whole argument for a fourth standard, and it is a better argument than "the existing ones are fragmented". SiLA 2, LADS and ROS 2 were designed for machine-to-machine control, where the entity issuing commands is software written by an engineer who read the manual, so the physical envelope could safely stay in the manual — in vendor firmware, in a configuration a roboticist tuned, in the tacit knowledge of the person who runs the bench. A model driving an unfamiliar instrument has none of that context and will produce a confident, plausible, wrong command. Moving the payload ceiling, the travel range and the temperature limit into a machine-readable description that the driver enforces is the correct response to that failure mode, and it is a response none of the incumbents had reason to design.
A driver-enforced limit is not a safety function
Here is where a promising architecture gets oversold, usually by people summarising it rather than by the people who built it. A limit in a driver is ordinary software in the command path: it stops a bad instruction becoming a bad motion, and it fails the way software fails — bugs, crashes, a bypass by anything that talks to the hardware underneath it, and total dependence on whoever typed the numbers into the device description. A rated protective function is a different object. The 2025 revision of ISO 10218 — parts 1 and 2, replacing the 2011 editions and absorbing the collaborative-application content previously in ISO/TS 15066 — made functional-safety requirements more explicit and added cybersecurity requirements alongside them, and protective functions of this kind are expected to reach a defined performance level with a redundant architecture, precisely so they still act when the control system is the thing that failed. Both layers are worth having. Only one of them stops the machine when the driver is the problem, and a programme that conflates them has an impressive-looking control that stops nothing.
When to pick which
| Situation | Pick | Because |
|---|---|---|
| Moving a robot arm, today, under your own planner | ROS 2 | The drivers, the controllers and the people already exist; nothing else is close on adoption. |
| Regulated plant or QC lab already running OPC UA | OPC UA LADS | You inherit certificates, historians and a vendor ecosystem instead of building one. |
| Instrument vendor asked which lab protocol to implement | SiLA 2, or both | Lab-native and pleasant to implement; the two camps are increasingly framed as complementary. |
| An agent will drive equipment it was not configured for | MHS, over whatever you already run | It is the only one of the four that carries the envelope in a form the caller can read. |
| Anything where the worst case is a person, not a plate | None of the above, first | Rated protective functions and stop circuits are a separate layer and come before the protocol conversation. |
FAQ
Does MHS replace SiLA 2, LADS or ROS 2?
No, and treating it as a replacement is how a lab ends up with a fifth integration to maintain. MHS is positioned below MCP and above the device; the useful question is whether it bridges cleanly to the control planes an estate already runs, and demonstrating those bridges is one of the conditions for taking it seriously.
Is MHS available to use now?
Not generally. It went out in late August 2026 as a research preview to a selected group of partners across science, robotics, electronics and manufacturing, with open-sourcing stated as the intention after further safety evaluation and no committed date. Plan on the assumption that a production dependency is a 2027 conversation.
Is the limit enforcement model-independent?
That is the design claim — limits are enforced by the driver on the device, not by the model — and it is the claim most worth testing independently. The evaluation to run is the same envelope under a different model, a different orchestrator and a third-party driver, then again with the driver deliberately crashed mid-command.
Why does natural-language device description matter at all?
Because the failure mode being addressed is a caller with no context. A schema tells a model what fields exist; a sentence explaining that the arm cannot reach the back-left rack when the lid is on tells it what will break. That information has historically lived in a manual and in the head of the person who runs the bench, and it is the part no existing device standard collects.
What should a lab do about this in the next six months?
Nothing structural. Write down, per device, the envelope you would put in such a description — travel, payload, temperature, what must never run unattended — because that document is useful with or without a new standard, and it is the input any of these systems needs. Then build the stop authority and the run records described in physical actuation safety, which are protocol-independent and are the part that carries the risk.
Further reading
On this wiki:
- Physical actuation: safety without undo — running an agent whose actions cannot be rolled back.
- What is MCP — the layer MHS is designed to sit beneath.
- The interoperability problem — why every agent ecosystem reinvents discovery.
- Capability discovery — how an agent learns what a counterparty can do.
- Kill switches — stop authority that does not depend on the stack it is stopping.
Project sources:
- Previewing the Model Hardware Standard — Anthropic
- OPC UA LADS — OPC Foundation
- SiLA standard — SiLA consortium
- ROS 2 documentation
- ISO 10218-1:2025 — robotics safety requirements