How i3X Looks to Address Industry’s Interoperability Issues
Key Highlights
- Without a common platform API, developers must rebuild applications for each vendor's system, preventing scalable value creation across manufacturing.
- i3X binds to the information platform layer, such as HMI/SCADA systems, where raw OT data is already organized and contextualized.
- Early momentum is strong, with a free i3X Explorer tool already available and an overwhelmingly positive vendor response signaling growing adoption of the open API standard.
In any manufacturing facility, there’s one thing you can be assured of: devices and software from multiple suppliers. Even during times when vendors were focused on creating monolithic systems to control nearly every automation and control aspect in a plant, the reality was that systems from numerous suppliers were being used.
That’s why interoperability has been the goal of manufacturers for decades and has been a driving force behind technologies like OPC UA, MQTT and, increasingly, the adoption of open-source software.
Despite these efforts at enabling device and system interoperability, achieving it remains a complicated task in many instances. In response, CESMII, the non-profit institute focused on smart manufacturing education, workforce development and industry networking, has launched i3X, the Industrial Information Interoperability Exchange. According to CESMII, i3X is an open, common API initiative being developed to address industry’s interoperability challenge.
To learn more about i3X, Automation World spoke with Jonathan Wise (JW), chief technology architect at CESMII, for a recent episode of the Automation World Gets Your Questions Answered podcast. Following are a few highlights from our discussion.
AW: What is i3X, why is CESMII focused on developing this and how does it help manufacturers?
JW: i3X stands for Industry 3.0 exit and it addresses the things we think you need to have in a contextual manufacturing platform to meet the bar for Industry 4.0. We’re aiming at where the data has been organized and trying to standardize the programmer's interface for getting that back out.
There's a free tool called i3X Explorer that provides a ready visualization establishing that yes, this underlying implementation has the minimum requirements for Industry 4.0 or not.
As for how this benefits manufacturers, if you think about how we get value in almost any other kind of industry, it's at the app, right? The smartphone and its platform help deliver the value, but it's really when we launch an app that we get some sort of value out of having the phone. In the manufacturing space, we don't have a proliferation of apps because we don't have any sort of standardization of the platforms that can support the apps. So, if I wanted to build an application, I would have to choose a vendor whose platform I would target and build for that vendor. If my customer, a manufacturer, doesn't have that vendor's platform, I either can't deliver that value to them or I have to rewrite the application against whatever platform that manufacturer has. Then, when I go to another manufacturer, I’ll have the same problem.
This is why we don't have an app value creation layer rapidly propagating through our space. We have different platforms that have different sets of value against which I can create the end user value for manufacturers, but no way to rapidly repeat that, scale it, learn from it, iterate and create this proliferation of value-creating apps in our space. So that's the problem we're trying to solve. Essentially, we're trying to make it easier to create information value against the wide array of platforms available in the industrial space.
AW: How does i3X relate to or complement existing standards like OPCUA, MQTT or ISA 95? Is it meant to sit on top of them, replace them in certain contexts or coexist with them?
JW: It coexists with them. Each of those standards you mentioned has a different purpose and different set of strengths and weaknesses. ISA 95 is usually poorly plumbed for the value that it has. For example, a lot of folks stop at the asset hierarchy. Asset hierarchy is one of the sets of relationships that i3X can expose, but ISA 95, properly implemented, looks more like a graph. There's a whole bunch of additional relationships that industry software isn't doing a good job of exposing right now.
MQTT is a great transport method for quickly seeing data and performing some organization on that data in a hierarchical organization. But MQTT is a transport. It's not designed to be an information platform. There are a ton of other features that I want as an application developer on an information platform. OPC UA is maybe the closest if it were properly realized because it covers the full range of what we're trying to accomplish, but it does it in a lot of different parts. Those parts and the adoption of those parts vary by vendors. But it's a well thought out, comprehensive specification that can do everything we want to do and more.
In the manufacturing space, we don't have a proliferation of apps because we don't have any sort of standardization of the platforms that can support the apps.
The flip side to that is it can be challenging to build an application against OPC UA because you don't know exactly what you're going to get from the underlying implementation. And to meet its full bar there are a lot of specifications you have to have. So, we work closely with the OPC Foundation to carve off the subset of functionality we see as the minimum required set and make sure that was exposed in a standard, open way through i3X.
If you're adopting one or more of these standards, i3X is designed to snap on top of whatever you're using.
AW: What becomes possible with i3X that isn't feasible in today's API landscape?
JW: We've seen a really cool explosion in adaptations since we announced it. There's a free tool called i3X Explorer that provides a ready visualization establishing that yes, this underlying implementation has the minimum requirements for Industry 4.0 or not. It readily gives you a report card of what you have and what you need to have to complete this base set of functionality. What we hope it enables in the very near future is a proliferation of apps. We want to see apps that target i3X, not apps that target Rockwell Automation or Siemens or Inductive Automation, so that those apps become portable across platforms.
AW: With all the legacy systems that still exist in manufacturing across industries, how does i3X handle connectivity with those legacy OT systems that were never designed with modern APIs in mind?
JW: To be clear, we are not designing to bind to those directly. Most OT data sources are too primitive to meet the bar that i3X sets. But we are targeting the first place that you begin to establish context against those OT protocols. For example, you could accomplish this in an HMI/SCADA system where you're organizing tags into UDTs (user-defined types). It's always going to be, at least for the foreseeable future, a platform that coalesces and organizes data and establishes the context that we can bind to. I won't rule out some future where our OT data sources become rich and context aware enough to bind i3X to it, but for now we are targeting the information platform layer, not the automation layer.
We have different platforms that have different sets of value against which I can create the end user value for manufacturers, but no way to rapidly repeat that, scale it, learn from it, iterate and create this proliferation of value-creating apps in our space. So that's the problem we're trying to solve.
AW: CESMII notes that an overarching goal of i3X is to reduce vendor lock-in and enable a smart manufacturing app ecosystem. Are there any specific metrics or milestones that CESMII is using to measure whether i3X is achieving those goals?
JW: The first is server implementations. How many vendors that can contextualize data will expose the interface? All signs are really positive right now — there’s been an overwhelming response. The second metric will be applications. So, given that servers have this interface, we want to see if information value is being extracted from it by repeatable applications. We want to see the app ecosystem grow to those that are i3X-aware at the API level. It’s still too early to set a benchmark for that, but I'm optimistic.
More interoperability insights from Automation World:
About the Author
David Greenfield, editor in chief
Editor in Chief
Leaders relevant to this article: