i3X — A Promising Step Toward Easier Industrial Data Access
The US Smart Manufacturing Institute, CESMII, is developing a new initiative called i3X (Industrial Information Interface eXchange), which has recently emerged in the industrial data space and has also caught our attention. The idea behind it is excellent: make OT data easier to consume by IT, and bring context along with the data, not just the raw values. That is a goal we have been pushing with customers for years, and any serious attempt at it is welcome.
But let’s start with the actual background of this initiative and why it exists. OPC UA is mature, technically excellent, and broadly adopted, but it is also large. Implementing it properly requires SDKs, most commonly commercial ones, to get a proper, up-to-date implementation, along with certificates, profiles, and a real understanding of the information model. In practice, because OPC UA is demanding for implementers and requires significant effort to build a proper server, it leads to a tendency to implement only part of the spec. The point of i3X is to address these burdens by making implementation easier and using REST, which is more familiar to IT developers.
If we look under the hood of i3X, it takes the best ideas from OPC UA, such as the VQT (Value-Quality-Timestamp) model, namespaces, types, and instances. It also includes a MonitoredItem-style subscription model. All use HTTP and JSON encoding, which should make it easy for everyone to implement.
Where i3X stands today
At the time of writing, i3X is still in beta, so it will certainly evolve before the actual release. It already implements a lot, but the main differences to the OPC UA scope are:
- Method calls are not part of the spec. In OPC UA, a node can expose callable methods, such as start(), stop(), and abort(), with arguments and return values. i3X has no equivalent for this use case yet.
- OPC UA has an Alarms & Conditions model, which is distinct from the standard subscription model and includes acknowledgment and metadata. The i3X standard subscription does not address this use case properly.
- Plus, numerous smaller parameters that are still powerful in many use cases, such as aggregates over history, deadband filtering, sampling interval controls, and bulk writes, are still missing from i3X.
These limitations define where i3X fits naturally today. On the OT-IT data exchange and cloud integrations, but not in PLC-to-SCADA or PLC-to-MES integration, where methods, alarms, and events are frequently used. That is a good fit, and it leaves OPC UA where it is strongest.
Adoption and implementation coverage will eventually decide everything
As discussed in the beginning, OPC UA carries a burden: even after adoption, implementations seldom use the full feature set. i3X is a far simpler interface, so can we expect every implementation to cover everything and avoid the same issue? On paper yes, but in practice the picture is more mixed.
i3X is rather simple and straightforward and should be easy to implement, but the Namespace and ObjectType concepts are not that straightforward, and they seem to be missing from many initial implementations. This matters, because ObjectType is the reason i3X exists. Without it, you have a JSON API for tags, which does not solve the real problem we have been working on for years: getting industrial data out of systems with context, not as raw numbers. A pump is a pump. It has speed, current, state, and maintenance history, and the semantics of those should be the same regardless of vendor.
The OPC UA community has been building exactly this for years through OPC UA Companion Specifications, and CESMII has done excellent work in gathering OPC UA NodeSet2 information models into the Smart Manufacturing Profile library for use with i3X. Without the ability to query data by ObjectType, i3X is, to my mind, rather unusable, and this is where I would like to see the i3X community focus next. Supporting data contextualization through NodeSet2 models and querying by ObjectType should, in my view, be mandatory for any implementation to be considered i3X-compliant. The beef is the semantics, not the transportation; that’s something we already have numerous ways of handling.
How we are approaching this at Prosys
At Prosys OPC, we have implemented the full i3X interface in Prosys Forge, our Industrial DataOps platform and OPC UA server aggregator. Forge already handles the harmonization, modeling, and security work that any serious DataOps layer must do, and i3X turns out to be a natural extension of the same information model. The same OPC UA information models that Forge serves via OPC UA are also exposed via i3X, so the semantics remain consistent across both interfaces. A consumer that prefers REST and JSON gets almost the same contextualized data (not the same, as there is a small loss between the OPC UA model and the JSON encoding) as one that uses native OPC UA, without having to redo the modeling work. We expect many of our customers to take the i3X interface in action already this year.
Conclusions
i3X is a promising initiative and a step in the right direction. The design choices are pragmatic, the scope is reasonable, and the underlying ideas are based on OPC UA’s twenty years of development. The next phase, moving from a working beta to a meaningful cross-vendor standard, depends mostly on what happens with ObjectTypes and shared information models. That is the part worth investing in.
We will be following its development closely and contributing where we can. If you are evaluating i3X for your own factory or platform and want to talk through how it fits with an OPC UA-based DataOps strategy, get in touch.
Pyry Grönholm
CEO
Email: pyry.gronholm@prosysopc.com