An analytics system needs to query production data from OSIsoft PI, Ignition Historian, and Siemens MindSphere simultaneously – but each platform speaks a different API language. The Unified Namespace (UNS) handles horizontal integration exceptionally well: real-time events flow via MQTT or NATS between OT and IT systems. However, the UNS lacks a standardized interface for structured, query-based data access from the IT side (pull access). i3X by CESMII aims to close exactly this gap – as an open API specification that exposes heterogeneous manufacturing platforms through a unified query interface.
Why i3X? The n×m Integration Problem
The API landscape in modern manufacturing environments is fragmented. OSIsoft PI uses the PI Web API, Ignition Historian exposes its own RESTful API, Siemens MindSphere relies on proprietary endpoints. As a result, integration effort scales quadratically with each new platform or IT application added: five platforms × five IT systems means 25 custom integrations to build and maintain.
The UNS with MQTT and NATS solves horizontal IT/OT integration well: events flow in real time across the UNS via pub/sub. What’s missing is a standardized query interface for IT systems that need to retrieve historical production data in a structured way. For this pull access, every IT system today must be developed against the native API of the respective platform – whether that’s a UNS or an IT platform.
What is i3X by CESMII?
i3X by CESMII – short for “Common Contextual Manufacturing Information API” – is an open API specification for standardized data access across heterogeneous manufacturing platforms. Platform vendors are intended to implement i3X so that IT systems can subsequently access all compatible systems through a single, unified interface. i3X is developed by CESMII (Clean Energy Smart Manufacturing Innovation Institute), a US-based institute focused on smart manufacturing.
| What i3X is | What i3X is NOT |
|---|---|
| API Specification (RFC): i3X defines which endpoints, query patterns, and data structures manufacturing platforms should expose – eliminating the need for custom adapters per data source. | Not a transport protocol: MQTT, OPC UA, and NATS move data between systems. i3X defines how applications query that data – it does not replace transport protocols. |
| Contextualized data: i3X operates on already-processed data with ISA-95 context (e.g., from the Unified Namespace), not on raw shopfloor data. | Not a message broker: NATS or MQTT brokers mediate pub/sub messages within the Unified Namespace (UNS). i3X operates one layer above – on the data access layer sitting on top of those brokers. |
| Application layer focus: Designed for IT systems (analytics, BI tools, ML pipelines) querying historical data – not for OT real-time control. | Not a replacement for the Unified Namespace: The Unified Namespace is a publish/subscribe architecture with message brokers at its core. i3X can be used within a UNS as an API gateway layer, but does not define ISA-95 context itself. |
Development Status (as of 2026)
The specification is currently in pre-alpha. It is a Request for Comments (RFC), not a production-ready implementation. A demo instance is available on GitHub.
Where does i3X standardize? – Positioning in the Data Access Model
To understand where i3X intervenes, the Data Access Model by Matthew Parris provides a useful frame: it divides IT/OT interoperability into six layered levels – from L0 (transport: e.g., TCP/IP) to L5 (objects: semantic data models). True plug-and-play interoperability requires consistency across all levels. For a full overview, see: IT/OT Interoperability in the UNS – Fundamentals. 
i3X by CESMII builds on existing transport standards and aims to standardize the upper layers consistently – precisely where heterogeneous IT platforms diverge today. As a result, IT systems can query OSIsoft PI, Ignition, or any other i3X-compatible platform using identical queries – without platform-specific adapter development.
Target Audiences for i3X
Two groups benefit directly:
- Application developers (primary): Analytics engineers, ML engineers, and dashboard specialists who need portable integrations without platform-specific custom adapters
- Platform vendors (secondary): Historian vendors and industrial IoT platforms that improve their interoperability and market adoption by implementing i3X
i3X vs. Message Broker vs. OPC UA – at a Glance
The table below illustrates that i3X by CESMII does not compete with existing protocols – it addresses a complementary layer.
Illustrative example: NATS transports temperature events in real time for monitoring or streaming analytics applications. i3X enables standardized queries against the UNS namespace and individual data points such as “temperature” for pull-based applications – for instance, a maintenance system reading the current state of a quality queue (e.g., open inspection lots). Both patterns coexist within the same UNS stack and serve distinct use cases.
| Aspect | i3X | OPC UA | Message Broker (e.g., NATS) |
|---|---|---|---|
| Type | API specification (RFC) | Industrial communication standard | Pub/sub protocol |
| Standardized levels | L2–L5 | L0–L5 | L0–L1 |
| Domain | IT | OT | IT/OT |
| Communication pattern | Pull (request/response) | Client/server + pub/sub | Push (pub/sub) |
| Latency | Seconds (query-based) | < 1 ms – 50 ms (profile-dependent) | < 10 ms |
| Real-time target | No real-time (analytics, reporting, data access) | Soft to hard real-time (profile-dependent) | Near-real-time (event streaming) |
| Position in UNS | IT layer (API) | Edge / OT layer | UNS core |
| Status (2026) | Pre-alpha | Widely adopted | Widely adopted |
i3X in the Unified Namespace (UNS) Stack
i3X is not a replacement for the Unified Namespace (UNS) – it is the missing API layer on top of it. The stack model below shows its positioning.
Each layer has a clearly separated responsibility (details in the article Middleware Architecture in the Unified Namespace (UNS)):
- IT Layer: MES, ERP, analytics – the consumers. Use data for business logic, reporting, and AI models.
- i3X API Layer: Standardized, query-based pull access for IT systems to historical and contextualized production data.
- Message Broker (NATS/MQTT): Single source of truth (SSOT) for all real-time data.
- Data Harmonization Layer: Normalizes units, adds ISA-95 context, validates schemas.
- Protocol Converters (Edge Gateways): Translates OPC UA, Modbus, S7 → NATS/JSON or MQTT/JSON.
- OT Layer: PLCs, sensors, drives – the data source. Speak proprietary protocols.
The key distinction: i3X is neither a message broker nor a communication protocol. It does not replace the UNS – it extends it as a standardized query interface for IT systems accessing stored, contextualized production data.
When is i3X the Right Choice?
i3X is the right choice when…
- Multi-vendor environment: OSIsoft PI, Ignition Historian, and MindSphere run in parallel – a central analytics application needs to access all three without building three separate integrations
- Portable application development: The same predictive maintenance app needs to run across multiple customers with different platforms – one i3X integration instead of five proprietary adapters
- Brownfield integration: Legacy systems with proprietary APIs need to be abstracted for modern IT applications without touching the OT layer
- Multi-site analytics: Global OEE dashboards aggregate production data across sites through a single API – independent of local platform decisions
Not suitable when…
- Event-driven architectures: High-throughput scenarios (>1,000 messages/sec) for event streaming remain the UNS’s domain via pub/sub mechanisms.
- Real-time control (< 50 ms): For closed-loop control, the UNS or direct PLC communication remains the right choice – i3X is query-based and therefore unsuitable for latency-critical control paths
- Single-platform environments: With only one platform, the native API is more direct and simpler – the overhead of an abstraction layer only pays off with multiple sources
- Production deployment planned: The pre-alpha status (as of 2026) means significant breaking changes are to be expected before a stable release
Best Practices for i3X Implementation
| Do | Avoid |
|---|---|
| Layered architecture: Position i3X as an additional layer above the UNS core – NATS for real-time events, i3X for structured queries. | i3X for real-time control: The query-based pull model is unsuitable for latency-critical control – MQTT and direct PLC communication remain the right tools here. |
| API versioning: Apply semantic versioning (e.g., i3x/v1, i3x/v2) – breaking changes only with a major version bump. | Production use before stable release: Account for pre-alpha status; RFC changes expected through Q1 2026 – track development at github.com/cesmii/i3X. |
| Secure authentication: Enforce OAuth 2.0 / JWT for all i3X API access; configure role-based access control (RBAC) per application and user role. | i3X as a UNS replacement: The UNS remains the architectural foundation – i3X extends it as an API layer, it does not replace it. |
Conclusion
i3X by CESMII closes the gap that MQTT and NATS deliberately leave open: standardized, query-based data access for IT systems across heterogeneous manufacturing platforms. It addresses the n×m integration problem at levels L2–L5 of the Data Access Model – precisely where heterogeneous APIs generate complexity today. Three key takeaways:
- Complementary, not competing: i3X extends
MQTT/NATSwithin the UNS – push for events, pull for structured queries - L2–L5 standardization: i3X by CESMII targets mapping, encoding, values, and objects – the layers where fragmentation originates today
- Pre-alpha caveat: The potential is clear; the specification is still under active development.
