This is Part 1 of a 3-part series on i3X and OPC UA. Part 2: One API Call to Rule Them All | Part 3: The Missing Safety Layer

i3X Meets OPC UA: When REST Meets Real-Time

Imagine you run a factory with 5 software platforms — a historian, an MES, SCADA, an ERP connector, and an AI analytics tool. Each has its own proprietary API. Connecting a new dashboard to all five means writing five custom integrations. Add a sixth platform? Five more adapters. This is the n×m integration problem, and at scale, it becomes unmanageable.

i3X (Industrial Information Interoperability eXchange) promises to fix this. But if you already use OPC UA, you might wonder: isn't this just reinventing the wheel? Are they competing?

The answer is no. They share the same DNA.

What is i3X? (The 30-second version)

i3X is an open-source REST API specification created by CESMII (the U.S. Smart Manufacturing Institute). If you're new to i3X, our practical introduction covers the fundamentals in depth. Here's the short version:

REST/JSON over HTTP — any developer who can call fetch() can use it.
Not a transport protocol — it doesn't replace OPC UA or MQTT. It's an access layer that sits above them.
Vendor-agnostic — write your application once, deploy against any compliant backend.
Contextualized data — responses include types, units, quality, and timestamps (the VQT model), not raw tag values.

The shared DNA

Both i3X and OPC UA are built on typed, hierarchical information models. This isn't a superficial similarity — it's a deep architectural alignment that makes translation between the two semantically lossless.

Concept	OPC UA	i3X
A "thing" in the model	Object / Variable Node	Element (Object Instance)
The schema of a thing	ObjectType / VariableType	ObjectType (with JSON Schema)
How things relate	Reference (HasComponent, Organizes)	Relationship (with RelationshipType)
Scoping definitions	Namespace (URI + index)	Namespace (URI + displayName)
A data point with context	DataValue (Value + StatusCode + Timestamps)	VQT (Value + Quality + Timestamp)
Historical data	HistoryRead service	`GET /objects/{elementId}/history`
Real-time streaming	Subscription + MonitoredItems	`/subscriptions/stream` (Server-Sent Events)

Both protocols organize data as graphs of typed, namespace-scoped nodes. Both carry quality and time alongside every value. Both support historical queries and real-time subscriptions. The conceptual mapping is nearly one-to-one.

Complementary layers, not competitors

Where they differ is not in what they model, but in who they serve:

  ┌──────────────────────────────────────────────────────┐
  │               IT / Cloud / AI                        │
  │  Dashboards, ML pipelines, data lakes, web apps      │
  │                                                      │
  │          ▲  i3X  (REST/JSON, SSE)                    │
  │          │  ─ HTTP, JSON — any language               │
  │          │  ─ OAuth / API keys                        │
  │          │  ─ Web-native, stateless                   │
  │          │                                            │
  │  ┌───────┴────────────┐                               │
  │  │   node-i3x      │  ← Sterfive's bridge         │
  │  │   Translation      │                               │
  │  │   Layer             │                               │
  │  └───────┬────────────┘                               │
  │          │                                            │
  │          ▼  OPC UA  (Binary/TCP, WebSockets)          │
  │          │  ─ X.509 certificates                      │
  │          │  ─ Deterministic real-time                 │
  │          │  ─ Rich OT semantics                       │
  │                                                      │
  │               OT / Shop Floor                        │
  │  PLCs, SCADA, DCS, robots, sensors                   │
  └──────────────────────────────────────────────────────┘

OPC UA excels at the OT layer: secure, session-based, real-time communication between machines and control systems. It speaks the language of PLCs.

i3X excels at the IT layer: accessible, stateless, cloud-native data consumption. It speaks the language of React dashboards, Python notebooks, and AI/ML pipelines.

Together, they form a full-stack industrial data architecture.

Sterfive's bridge: node-i3x

At Sterfive, we are building node-i3x — a TypeScript implementation of the i3X Beta API specification that translates OPC UA address spaces into clean REST/JSON endpoints. It can be integrated directly into your existing OPC UA server — no separate gateway needed.

The architecture follows a hexagonal DDD design:

Package	Role
`@node-i3x/core`	Pure domain — models, ports, services. Zero dependencies.
`@node-i3x/opcua-connector`	OPC UA adapter using node-opcua
`@node-i3x/rest-server`	Fastify REST routes — the i3X API surface
`@node-i3x/app`	Composition root — wires everything together

Licensing: node-i3x is dual-licensed. Use it freely under AGPL-3.0 for open-source projects, or acquire a commercial license for proprietary deployments with no copyleft obligations and dedicated support. An optional @sterfive/opcua-optimized-client module delivers up to 200% performance improvement through intelligent transaction batching and auto-healing connections.

What's next

So i3X and OPC UA share the same information-modeling DNA and complement each other perfectly at different layers. But i3X doesn't just mirror OPC UA — it does something genuinely better for data consumption.

In Part 2, we'll explore how a single REST call can give you the complete state of an entire machine — something that takes dozens of operations in native OPC UA. We'll also discover where this elegance starts to crack.

At Sterfive, we build node-i3x — the bridge that connects your OPC UA servers to the i3X ecosystem. Available as open source (AGPL-3.0) or with a commercial license for proprietary deployments. Talk to us to get started.