Interoperability
Speak your plant's language, not ours.
InnovaEdge adopts, configures and monitors your fleet, and interoperability is what happens to that data next. Most platforms make you export it and model it again somewhere else. Here the model that configures the device is the same model served to your plant systems — one namespace, not a mapping exercise you maintain by hand.
CESMII i3X 1.0 server · OPC UA NodeSet import & export · W3C WoT export · Sparkplug B egress
01 — The interop surface
Six ways in and out of the namespace.
Every claim below comes straight from the capability registry, including the one that has not shipped yet.
CESMII i3X 1.0 server
A full i3X 1.0 server including subscriptions over SSE, with value writeback to devices through settables. Not an export — a live interface your plant systems talk to. Each tenant's type library gets its own namespace URI, so an outside consumer can tell one organisation's types from another's instead of every tenant authoring into one shared identifier.
OPC UA NodeSet & i3X import
Bring an existing i3X namespace or OPC UA NodeSet2 in and its object types register alongside your own. An i3X import carries each type's schema; a NodeSet2 XML brings the type names, so variables and hierarchy are still modelled here.
OPC UA NodeSet2 export
The twin model exported as a standards-conformant OPC UA NodeSet2 information model.
W3C WoT Thing Description export
Devices described as W3C Web of Things Thing Descriptions, so a consumer that speaks WoT needs no InnovaEdge-specific knowledge.
Sparkplug B / UNS egress
Publish into a Unified Namespace as Sparkplug B, on demand or continuously, so InnovaEdge slots into a plant architecture instead of demanding to be its centre.
Kafka northbound egress
Landing telemetry produced to your own Kafka cluster, table by table, under a topic prefix you choose. A per-table cursor on the ingest timestamp advances only after a produce succeeds, so a broker outage replays the window rather than losing it — at-least-once, which means a consumer has to tolerate seeing a row twice.
Modbus RTU authoring & register discovery
Modbus RTU authored as an acquisition workload — bus, station range, timing, and read blocks whose register map can be pasted in from a spreadsheet — and compiled for each device family when the table is published. A dry run reports what one cycle costs on the target you pick and states that the FOX adapter expands a block into individual station and register reads; active serial execution on the Linux adapter is still gated on hardware certification. A batched sweep probes a register range station by station, keeps only the registers that answered, and promotes those into a draft profile whose signals preview their decoded value from a sample through the same transform vocabulary the device runs.
OPC UA client ingest Planned
Read from existing OPC UA servers, closing the loop on plant-floor sources that are not MQTT devices.
02 — Why a server, not an export
Writeback makes us a participant, not a leaf.
An export is a one-way snapshot: it goes stale the moment something changes. The i3X server carries live subscriptions over Server-Sent Events, so a client sees a value change as it happens, and it carries writeback to devices through settables — a client can set a value and the device actually moves.
Subscriptions
A plant system opens a subscription and streams changes over SSE instead of polling. It stays current without asking.
Writeback
Settable properties accept a write from an i3X client and carry it through to the device config-push path. That is the moat: of the platforms we have evaluated — IoT application platforms, fleet telematics SaaS and plant-floor UNS tools — none ships closed-loop configuration down to constrained edge hardware.
Not a silo
Any i3X client — or an AI agent that speaks i3X — browses and reads the same information model it would against Ignition, SMIP, or any other conformant platform. Nothing about talking to us requires knowing us.
03 — Namespace as type library
The twin defines the types. Interoperability just exposes them.
There is no separate interoperability model to keep in sync. The i3X namespace, the OPC UA NodeSet2 export and the WoT Thing Description are all generated straight from the equipment and location types you define once, in the digital twin.
04 — The honest boundary
Reading a live OPC UA server is the one gap.
Moving the model is largely solved today: hand us a vendor's OPC UA NodeSet2 XML and its object types register as first-class i3X types alongside your own — the type names come across, while variables and hierarchy are still modelled here, so this saves the inventory rather than the whole build; an i3X namespace import additionally carries each type's schema; publish your twin the same way out as a standards-conformant NodeSet2. What we do not yet run is an OPC UA client against your existing OPC UA server to read its live values — that's the one item on this page marked planned, closing the loop on plant-floor sources that are not MQTT devices in the first place.
Where to go next
The UDI contract
The open device interaction contract and its conformance runner.
Supported devices
Which hardware is sovereign, native, bridged or telemetry-only — and which is not reached at all.
Pricing
Four tiers, the metered device floor, and what is included in each.
Bring your namespace, not a spreadsheet.
Tell us what your plant already speaks — i3X, an OPC UA NodeSet, or neither yet — and we'll show you the namespace live.