This Breaks the Entire Industrial Software Model

Context and problem statement

CESMII (the U.S. Smart Manufacturing Institute) presented a live, vendor-collaborative demo that illustrated an approach to break the traditional “stovepipe” industrial software model — vendor lock‑in, nonportable integrations, and many proprietary APIs.

Main thesis: manufacturing is still operating in an Industry 3.0 reality of siloed systems. To realize Industry 4.0 value (and reduce cost/time to implement smart manufacturing), you must standardize data types (profiles), unify namespaces, and provide a common API so apps can be written once and run across platforms.

Key technological concepts

Smart Manufacturing Profiles (type definitions)

• Profiles are rules that describe what data should look like (type safety). Without them, consumers must code defensively against mismatched types (e.g., integer vs float).
• CESMII chose OPC UA node sets (OPC UA Part 5) as a canonical language for profiles, though other formats (UDTs, JSON Schema) are acceptable for end users.
• Profiles act as the contract/pointer for data governance: data payloads should include a reference to the profile/namespace URI so consumers can validate and interpret data.

Namespace vs address space

• Address space (for example, MQTT topics) shows structure but not the governing rules.
• Explicit namespaces/metadata pointing to profiles are required to make address-space data reliably consumable.

Knowledge layer / knowledge graph

• Facts = governed, typed data in the address space.
• Knowledge = relationships between facts (for example, “When temperature rises, quality drops”).
• Capture workforce knowledge in graph databases, markdown docs, or knowledge-graph tools so AI/analytics can leverage it.

API chaos → need for a common API

• Multiple vendors exposing different APIs forces app developers to rewrite apps for each platform.
• Proposed solution: a common, app-centric API that exposes discovery (types/namespaces), live data, historical data, and subscription/notification semantics.

I3X — Industrial Information Interoperability Exchange

What it is

An industry-driven common API specification (RFC-style initiative led by CESMII members) to expose unified namespaces and standardized access to live/historical data and type information.

Core functions exposed by I3X (examples shown in demos)

• Explore/discovery endpoints: enumerate namespaces, types, objects, and hierarchies.
• Query endpoints: retrieve last-known values and historical data.
• Subscribe endpoints: subscribe to changes/events.
• Update/sync capabilities: app-centric operations for state changes and synchronization.

Design principle: support the 80/20 rule — unify the common 80% so apps are portable while allowing vendors to keep unique 20% features.

Adoption model: vendors keep their backend implementations but implement the I3X API to expose interoperable access.

Reference client and developer tools

I3X Explorer (Ace Technologies)

• A cross‑platform, free, open-source “MQTT Explorer on steroids” reference client.
• Capabilities: discover namespaces/types/objects; show hierarchy, live values, history, and relationship graphs; indicate whether smart manufacturing profiles are applied and where to find them (namespace URI).
• Code and installers available on GitHub and acetechnologies.net. Community contributions encouraged.

Other developer resources

• connect.cesmi.org/i3x
• i3x.dev / GitHub
• I3X Python client library (available)
• Workshops and hands‑on sessions (e.g., noon Room A during the event)

Vendor/product demos and features shown

• Inductive (Ignition)

  • Built a converter to import OPC UA node set profiles into Ignition UDTs, instantiate objects, map to PLC tags, and expose them via an I3X endpoint.
  • Demonstrated hierarchies, live values, history, and alarm relationships via I3X.

• HighByte

  • Edge-deployed contextualization/modeling engine that creates namespaces and hydrates models (can import OPC UA/node sets).
  • Demonstrated pipeline: TimeBase historian → HighByte contextualization → I3X delivery (live + historical).
  • Alpha support for I3X; functionality will evolve with the spec.

• Flow Software (TimeBase historian)

  • Free, high‑performance time-series historian (claimed installs and performance: up to 1M tags & 200k writes/sec in some systems).
  • Wrapped REST APIs around functionality and added I3X endpoints for discovery, query/history, and subscribe.
  • Historical data serves as the “at‑rest” source for I3X query endpoints.

• AWS (IoT SiteWise)

  • Ingested namespaces and time-series data into SiteWise for modeling, hierarchies, transforms/metrics, and anomaly detection.
  • SiteWise used as a cloud time-series store and queried via an I3X-style client.

• Mendix (Siemens) app

  • Example app using I3X to pull cross-vendor/site data for production scheduling and visibility.

• Other contributors referenced

  • Rockwell Automation, Siemens, Yokogawa, Dattos, Skellig, JPI, Litmus, Thread (knowledge graph on Ignition), Ace Technologies.

Demonstration highlights and practical outcomes

• The “prove-it” virtual factory demo showed multiple vendors interoperating in weeks by:
  • Applying CESMII Smart Manufacturing Profiles (node sets) to payloads.
  • Implementing I3X endpoints to expose discovery, live, and historical data.
  • Using I3X Explorer to visualize hierarchy, types, live values, history, and relationships.
• Result: apps and low-code tools can consume the same API across vendors, enabling portability and reducing the need for custom glue between platforms.

Near-term guidance: vendors should implement import/export of node sets and I3X endpoints; end users should demand profile-aligned payloads and I3X access instead of buying siloed systems.

Guides, tutorials, next steps & community resources

• Download and try I3X Explorer (open source) to inspect your broker and verify whether namespaces/profiles are applied.
• Developer portals and repos: connect.cesmi.org/i3x, i3x.dev/GitHub.
• Use the I3X Python client library to build apps.
• Attend workshops and hands-on sessions where the spec and tools are evolving.
• Recommendations for implementers:
  • Apply CESMII Smart Manufacturing Profiles (or equivalent typed schemas).
  • Expose namespace URIs in messages.
  • Implement I3X explore/query/subscribe endpoints.
  • Capture knowledge/relationships into a graph or structured docs to enable AI/analytics.

Strategic analysis and implications

• Standardizing profiles plus a common API (I3X) can materially reduce integration cost and time, accelerate app development, and enable OT/IT convergence.
• Capturing workforce knowledge and modeling relationships is required for higher-order analytics and AI; profiles and a unified namespace make that tractable.
• The approach preserves vendor differentiation (20%) while unifying the common data and access surface (80%), enabling an app ecosystem rather than vendor-locked stacks.

Main speakers and sources

• John Dyck — CEO, CESMII
• Jonathan (John) Wise — Chief Technology Architect, CESMII
• Matthew Paris — I3X leader / community contributor
• Craig Egan — Founder & Chief Engineer, Ace Technologies (I3X Explorer)
• Travis — Inductive (Ignition) representative
• Graham Welton — Flow Software (TimeBase historian)
• Aaron — CTO, HighByte
• Scott — AWS representative (SiteWise integration)
• Todd Malone — SCADA/HMI/historian expert
• Tony Huffman — Georgia-Pacific (end‑user / early adopter)
• Additional contributors: Dylan, Sam Elsner (Litmus), Walker (event organizer), Rockwell Automation, Siemens, Yokogawa, Dattos, Skellig, JPI

Bottom line / call to action

• I3X + Smart Manufacturing Profiles aim to “break the industrial software model” by providing a common API and typed profiles so apps can run across vendors and sites without custom glue.
• Action items:
  • Developers: try I3X Explorer and the Python client.
  • Vendors: implement import/export of node sets and I3X endpoints.
  • Manufacturers: demand profile-aligned payloads and I3X support instead of buying new silos.