OPC UA Meets the Web of Things: Why OPC 10101 Is the Integration Shift Your Factory Has Been Waiting For

Most industrial integration projects start the same way: a good idea, a tight deadline, and a custom middleware layer that only two people in the building truly understand. Six months later, that middleware is load bearing infrastructure that nobody wants to touch.

OPC UA was already solving half of this problem, giving machines a structured, secure, vendor neutral language. But there was always a second half: getting that machine data into the hands of cloud platforms, analytics systems, and IT developers without rewriting the integration stack every time something changed.

That second half now has a formal answer. OPC 10101; the OPC Foundation's official Binding for Web of Things standardizes the bridge between industrial information models and modern API-driven architectures. It was released in January 2026, and it changes what "integration" means in practice.

The Gap That Kept Getting Patched

OPC UA gives every data point in your plant a name, a type, a unit of measurement, and a place in a logical hierarchy. A conveyor speed isn't just 82.4, it's Objects/Line3/Conveyor/Speed, typed as a double, measured in metres per minute, with a defined access level and a historical record. That context is what makes OPC UA genuinely useful rather than just another data pipe.

The problem was that getting that context out of the OPC UA Address Space and into a web application, a cloud dashboard, or a data science pipeline required custom translation work. Someone had to map NodeIds to API endpoints, invent a JSON schema, and maintain the connector as both sides evolved. Every new consumer of machine data meant another integration project.

OPC 10101 replaces those custom bridges with a standardized contract: a WoT Thing Description (TD),  a machine-readable JSON-LD document that describes exactly how to find, access, and interact with an industrial asset through web-native interfaces.

What a Thing Description Actually Does

Think of a Thing Description as the machine's own API documentation, except it's structured, machine-readable, and generated directly from the OPC UA model rather than written by hand.

For every asset described under OPC 10101, the TD captures:

• Where to connect - the OPC UA server endpoint, formatted as a standard URI (opc.tcp://192.168.1.100:4840)

• What data is available - each UA Variable becomes a readable, writable, or observable property with its NodeId, BrowsePath, data type, and engineering unit

• What actions can be invoked - UA Methods become callable actions with typed input and output schemas

• What events to watch - alarms, state changes, and process events are described as subscribable event affordances

• What security is required - the security scheme, certificate requirements, and supported authentication modes are declared in the TD itself

The mapping is deterministic. A UA Variable exposed as readable and writable in the OPC UA Address Space becomes a property with readOnly: false in the TD. A UA Method becomes an action. A UA Object becomes the Thing itself, grouping its Variables and Methods underneath. There is no interpretation required - the specification defines the transformation

How OPC UA Services Map to Web Operations

This is where OPC 10101 earns its technical credibility. It doesn't just give machines a JSON wrapper, it formally aligns WoT interaction models with OPC UA's native service layer:A developer calling thing.readProperty("conveyorSpeed") is triggering a real OPC UA Read service against the correct NodeId, with the correct session, handling the subscription lifecycle and security negotiation behind the scenes. The abstraction is clean, but nothing is lost underneath it.

Security Is Not Diluted

Anytime industrial data moves toward web-facing architectures, the security question comes up immediately and rightfully so. OPC 10101 addresses this by keeping OPC UA's security model intact rather than replacing it.

The specification defines dedicated security schemes that a TD can declare. The recommended default for production environments is the auto scheme the WoT client

What the web application does	What OPC UA actually executes
Read a property	OPC UA Read Service
Write a property	OPC UA Write Service
Subscribe to a property	OPC UA MonitoredItem Subscription
Invoke an action	OPC UA Call Service
Listen for an event	OPC UA Event Subscription

connects to the OPC UA server, reads its advertised endpoint security policies, and automatically selects the strongest available option. Your existing OPC UA PKI, your X.509 certificates, your message signing and encryption configuration; none of it changes. The WoT layer sits on top of it, not around it.

For environments where explicit control is required, the specification also supports fully declared security configurations, including specific MessageSecurityMode levels (Sign, SignAndEncrypt) and authentication token types.

What Changes for Your OT and IT Teams

For OT engineers, the underlying machinery hasn't changed. OPC UA still provides the information model, the security, the historian integration, the real-time subscriptions. What changes is that the data you've already structured and secured is now accessible to a much broader set of tools and teams without any additional custom work on your side.

For IT developers and data engineers, the experience is fundamentally different from what industrial data access has traditionally looked like. Instead of learning OPC UA client libraries, understanding NodeId syntax, or working around session management quirks, they interact with industrial assets using the same patterns they use for any other API. The Thing Description tells them what's available. The WoT runtime handles the OPC UA connection. The data comes back typed, named, and in a format their tools already understand.

For the people making architectural decisions, the more important shift is this: integration work that used to be a recurring custom engineering project becomes a standards-conformant, repeatable implementation. New consumers of machine data don't require new integration projects. They require a WoT-compliant client and a TD. That's a fundamentally different cost model.

A Few Things to Get Right in Implementation

Getting the architecture right from the start avoids common issues at scale:

Use namespace URIs, not namespace indexes. Namespace indexes in OPC UA are server-local values that can change. The nsu= format (namespace URI) in Thing Description hrefs is portable across servers and won't break if the server configuration changes.

Generate Thing Descriptions, don't hand-author them. For anything beyond a proof of concept, TDs should be generated programmatically from nodeset files or live Address Space Browse results. The mapping from OPC UA to WoT is well-defined enough to automate, and manual authoring at scale introduces errors that are difficult to trace.

Decide early where the WoT runtime runs. For latency-sensitive control loops and local dashboards, the WoT Servient belongs at the edge. For cloud analytics and enterprise reporting, it can run further up the stack. The Thing Description is identical either way only the deployment changes.

The Bigger Picture

OPC UA already established that industrial data doesn't have to be locked inside proprietary silos. OPC 10101 extends that principle one step further: industrial assets don't have to be locked inside OPC UA-specific tooling either.

The result is a plant floor that speaks to cloud platforms, analytics engines, digital twins, and enterprise systems using the same open standards those systems were built for — without giving up the semantic richness or security guarantees that industrial environments require.

If you're evaluating where OPC 10101 fits in your architecture, or looking to move from custom integration layers to a standards-based approach, our team at Eclatron works across the full OT-IT integration stack. Get in touch to discuss where to start.

Frequently Asked Questions

Does using the Web of Things make my machines less secure? 

Actually, it can make them more secure. Older protocols often had no security at all. By using OPC UA and WoT, you're adding layers of modern, bank-level encryption and strict user controls.

Will my real-time control be affected by web traffic?

 No, because the two layers are kept separate. Your machines still talk to each other at high speeds for critical tasks. The API layer is for monitoring and analysis, so it won't interfere with split-second machine timing.

Is it expensive to switch to an API-based system? 

It's often cheaper than the alternative. Proprietary software can cost a fortune in licensing. By using open standards like the OPC UA protocol and web APIs, you can use more affordable tools and reduce long-term costs.

Do I need a team of web developers to manage this? 

While you'll need some expertise to set it up, the goal of this technology is to make it easier to manage. Once the APIs are running, your existing team will find it much simpler to use than old-fashioned, complicated industrial software.