i3X and OPC UA β a practical introduction
If you work in manufacturing IT, you've probably heard about i3X β the new open API standard from CESMII. You may have also heard it described as "OPC UA for IT people" or "a simpler alternative to OPC UA." Both descriptions are misleading.
This article explains what i3X actually is, how it relates to OPC UA, and where each fits in a modern manufacturing architecture.
What problem does i3X solve?
Modern factories run dozens of software platforms: historians, MES, ERP, SCADA, analytics tools, AI engines. Each one has a proprietary API. When you need to connect a new analytics tool to three existing platforms, you write three custom integrations. Add a fourth platform, and you write three more.
This is the nΓm integration problem: the number of custom integrations grows quadratically as you add systems. At scale, it becomes unmanageable.
i3X solves this by defining a common, vendor-neutral REST API that any platform can implement. Write your analytics tool once against the i3X API, and it works on any compliant platform β no custom adapters.
What is i3X, exactly?
i3X stands for Industrial Information Interoperability eXchange. It is an open-source API specification (MIT license) coordinated by CESMII, the U.S. Smart Manufacturing Institute. As of mid-2026, i3X is in Release Candidate status.
Key characteristics:
- REST/JSON over HTTP β standard web technologies that any IT developer can use.
- Query-based β applications pull data on demand, unlike MQTT which pushes data via events.
- Vendor-agnostic β the same API works across any compliant platform (historian, MES, cloud).
- Contextualized data β responses include data types, units, quality, and timestamps (the VQT model), not just raw values.
i3X is not a transport protocol. It does not replace OPC UA or MQTT. It is an access layer β a standardized way to query industrial data that has already been collected and modeled.
How does i3X relate to OPC UA?
This is the key question, and the answer is straightforward: i3X builds on OPC UA's information modeling, but provides a simpler access mechanism.
| Layer | OPC UA | i3X |
|---|---|---|
| Information model | OPC UA Part 5 β types, instances, references, namespaces | Reuses OPC UA modeling concepts via SM Profiles |
| Transport | OPC UA TCP, HTTPS, WebSockets, PubSub | HTTP/REST (JSON) |
| Access pattern | Client/Server (session-based) + PubSub | Stateless REST queries |
| Discovery | Browse the address space at runtime | Query by profile type |
| Security | X.509 certificates, signing, encryption | OAuth 2.0 / API keys |
| Target audience | Automation engineers, device manufacturers | IT developers, data scientists |
| Complexity | High β requires OPC UA SDKs and expertise | Low β any HTTP client works |
Think of it this way:
- OPC UA is the deep, real-time backbone that connects machines, PLCs, and SCADA systems. It provides the semantic model (the "dictionary") and the secure transport.
- i3X is the developer-friendly API that lets IT applications (dashboards, AI, analytics) consume that same data without learning the full OPC UA stack.
They are complementary, not competing.
What are SM Profiles?
SM Profiles (Smart Manufacturing Profiles) are the link between i3X and OPC UA. An SM Profile is a standardized data template that defines the attributes, data types, and structure of a manufacturing asset β for example, a pump, a conveyor, or an injection molding machine.
SM Profiles are built using OPC UA Part 5 information modeling. Many are derived from existing OPC UA Companion Specifications (PackML, Euromap, PADIM). This means the semantic model is consistent whether you access data via OPC UA Client/Server or via the i3X REST API.
The CESMII SM Profile Designer lets you create, share, and reuse profiles through their Smart Manufacturing Marketplace.
A practical architecture
Here is how OPC UA and i3X fit together in a real manufacturing architecture:
Layer 1: Shop floor (OPC UA)
OPC UA servers run on edge devices and connect directly to PLCs, sensors, and machines. They expose structured address spaces using Companion Specifications. This layer handles real-time control, alarming, and secure machine-to-machine communication.
Layer 2: Edge / Platform (OPC UA + i3X)
An industrial platform (historian, edge analytics, or UNS) collects data from OPC UA servers. It stores the data with full context β types, units, quality, timestamps. The platform implements the i3X API to expose this data to higher-level applications.
Layer 3: Enterprise / Cloud (i3X)
IT applications β dashboards, AI/ML pipelines, MES, ERP connectors β consume data via i3X REST calls. They don't need OPC UA SDKs, session management, or certificate handling. A simple HTTP GET returns typed, contextualized JSON.
When to use what
| Scenario | Use |
|---|---|
| Connecting to PLCs and industrial devices | OPC UA |
| Real-time control and alarming | OPC UA |
| Secure machine-to-machine communication | OPC UA |
| Building analytics dashboards | i3X |
| Feeding AI/ML pipelines with manufacturing data | i3X |
| Integrating MES or ERP with shop floor data | i3X (query) + OPC UA (transport) |
| Defining a vendor-neutral data model | SM Profiles (built on OPC UA) |
| Making data portable across platforms | i3X |
What i3X does not do
It is important to be clear about the boundaries:
- i3X does not replace OPC UA for real-time control. You cannot call a PLC method or subscribe to alarms via i3X.
- i3X does not define a transport protocol. Data still needs to be collected via OPC UA, MQTT, or other means before it can be queried through i3X.
- i3X does not replace the need for information modeling. Without a well-defined SM Profile (typically built with OPC UA concepts), the data returned by i3X would lack the context that makes it valuable.
Current status
As of June 2026, i3X is in Release Candidate status. The specification is open-source under an MIT license. A working group including Rockwell Automation, Siemens, Microsoft, AWS, and Inductive Automation is actively developing it. Developer resources are available at i3x.dev and on CESMII's GitHub.
It is still early. Production deployments are limited to pilot programs within CESMII member organizations. But the direction is clear: OPC UA remains the semantic and transport backbone, while i3X becomes the standardized IT access layer.
Key takeaways
- i3X is not a replacement for OPC UA. It is a REST API layer that sits on top of OPC UA-modeled data.
- SM Profiles are the bridge. They use OPC UA information modeling to define data contracts that both OPC UA and i3X can serve.
- OPC UA for OT, i3X for IT. Use OPC UA where you need real-time, secure, session-based communication. Use i3X where you need lightweight, stateless data access for web-scale applications.
- The nΓm problem is real. If you're writing custom integrations for every platform-application pair, i3X is worth evaluating.
References
- CESMII β Smart Manufacturing Innovation Institute. cesmii.org
- i3X Developer Portal β Open API specification and documentation. i3x.dev
- CESMII GitHub β SM Profile Designer and i3X resources. github.com/cesmii
- OPC Foundation β OPC UA Specification Part 5: Information Model. opcfoundation.org
- CESMII β Smart Manufacturing Marketplace. marketplace.cesmii.net
At Sterfive, we build the OPC UA infrastructure that feeds systems like i3X. Our tools β node-opcua, OPC UA Modeler, and Omni-Edge β create the semantic models and real-time data pipelines that make i3X queries meaningful. Talk to us if you're designing an architecture that bridges OT and IT.