Was ist i3X? Der Standard, der Fertigungsdaten KI-fähig macht

i3X (Industrial Information Interoperability eXchange) ist CESMIIs offene, herstellerunabhängige API-Spezifikation, um kontextualisierte Fertigungsdaten über eine einzige Schnittstelle abzufragen. Version 1.0 wurde am 9. Juni 2026 auf GitHub getaggt und am 18. Juni 2026 angekündigt, getragen von 44 Technologieanbietern aus der Fertigung. Sie soll das API-Chaos beenden, das Fertigungsdaten daran hindert, KI-fähig zu sein. Wenn Sie bereits Konnektivität über OPC UA oder Kepware betreiben, legt i3X die KI-fähige Abfrageschicht obendrauf. Sie ersetzt nicht, was Sie haben.

Teil unserer Serie zu KI für die Fertigung. Weiterlesen: Unified Namespace · Prädiktive vs. generative KI in der Produktion

Ich fange mit dem Moment an, in dem mir das konkret wurde. Acht angebundene Systeme, überall Live-Dashboards, und ich konnte trotzdem nicht sagen, welcher Auftrag lief, als das Werkzeug wegdriftete. Vernetzt und blind. Genau diese Lücke, zwischen Daten haben und mit ihnen eine Frage beantworten können, soll i3X schließen. Wenn Sie bereits OPC UA oder einen Unified Namespace betreiben, ist die nützliche Frage nicht, was i3X abstrakt ist. Sie lautet, wo i3X in das passt, was Sie schon haben. Darum geht es im Rest dieses Textes.

Das API-Chaos: die Vermehrung von Datensilos in der Fertigung

i3X existiert, weil ein Werk mit fünf Datenplattformen und fünf IT- oder KI-Anwendungen auf bis zu fünfundzwanzig einzelne Integrationen kommen kann, das n-mal-m-Problem, oft als „API-Chaos” beschrieben. Jeder Historian, jedes MES, jedes Qualitätssystem und jedes Instandhaltungswerkzeug spricht seine eigene proprietäre API. Verbinden Sie fünf Quellen mit fünf Verbrauchern, und Sie pflegen fünfundzwanzig fragile, handgebaute Brücken, von denen jede bricht, sobald ein Anbieter seine Schnittstelle ändert. i3X ist eine Initiative für eine offene, gemeinsame API und eine Antwort auf eine wachsende Interoperabilitätsherausforderung in modernen Fertigungsarchitekturen, in denen jeder Plattformanbieter und jeder Lösungsanbieter seine eigene Schnittstelle ausliefert. Für Anwendungsentwickler, die mit mehreren Anbietern arbeiten, bringt jedes neue System zusätzliche Integrationskomplexität, die Innovation ausbremst.

An einer Stelle irrt die Branche beharrlich. Sie gibt den Protokollen die Schuld. Falsches Ziel. Protokolle sind seit Jahren gelöst. Ein anständiges Team liest Daten aus fast jeder SPS, jedem Historian und jeder Datenbank in einer Woche. Dass das Anbinden einer Maschine immer noch Monate dauert, liegt nicht am Kabel. Es liegt daran, dass jede Anwendung die Daten anders geformt, benannt und kontextualisiert braucht, und dass sich niemand auf eine gemeinsame Art geeinigt hat, danach zu fragen.

„Eine Maschine anzubinden dauert immer noch Monate, und die ganze Branche gibt weiter den Protokollen die Schuld. Falsches Ziel. Protokolle sind seit Jahren gelöst.”

Genau das blockiert KI. Ein großes Sprachmodell oder ein autonomer Agent ist nur so gut wie die Daten, die er erreichen und denen er trauen kann. Wenn jede Quelle rohe, unkontextualisierte Tags hinter einer eigenen API bereitstellt, läuft Ihre KI-Strategie auf einem Datenfundament, das nie dafür ausgelegt war, und deshalb bleiben so viele KI-Projekte in der Fertigung im Pilot-Fegefeuer stecken. Die Vermehrung von Datensilos über heterogene Software-Stacks hinweg ist keine Unannehmlichkeit. Sie ist das, was zwischen Ihrem Werk und der Portabilität von Anwendungen steht, und zwischen Ihrem Werk und KI.

Verbindungen verhalten sich außerdem anders, als die meisten Business Cases annehmen. Sie addieren sich nicht, sie multiplizieren sich. Die zehnte Integration schlägt die erste, weil sie neun andere hat, mit denen sie sich verknüpfen lässt. Jagen Sie stattdessen reiner Abdeckung hinterher, bekommen Sie eine Wand grüner Linien, die nichts beantworten.

Was ist i3X? Der Industrial Information Interoperability eXchange

i3X, der Industrial Information Interoperability eXchange, ist eine offene, herstellerunabhängige Definition einer gemeinsamen API von CESMII (The Smart Manufacturing Institute). Sie standardisiert, wie jede Anwendung auf kontextualisierte Fertigungsinformationen zugreift, gleich welche Plattform darunter liegt. CESMII hat sie im Juni 2026 zu einer finalen 1.0 geführt; Spezifikation und Werkzeuge liegen auf der offiziellen i3X-Seite und auf GitHub. Weil i3X herstellerunabhängig ist, funktioniert eine dafür geschriebene Anwendung plattformübergreifend weiter, was skalierbare Interoperabilität ergibt statt eines Stapels einmaliger Integrationen.

CESMII ist ungewöhnlich deutlich bei der Absicht. In eigenen Worten existiert die gemeinsame API, um den Zugang zu Daten zur Commodity zu machen, während Plattformanbieter sich weiterhin über ihre Fähigkeiten unterscheiden können. Das erwartete Ergebnis ist eine Vielzahl portabler Apps, so wie gemeinsame Geräte-APIs App-Stores hervorgebracht haben statt einer Bibliothek von Treibern.

Am schnellsten versteht man i3X darüber, was sie nicht ist:

• Sie ist kein Transportprotokoll. Sie holt keine Bytes von einer SPS. OPC UA, MQTT und ihresgleichen tun das bereits gut.
• Sie ist kein Message Broker. Sie ersetzt weder Ihren Event-Bus noch Ihren Unified Namespace.
• Sie ist weder Historian noch Datenbank. Sie speichert Ihre Daten nicht.

i3X ist die standardisierte Abfrageschicht, die über all dem liegt. Binden Sie Ihr Dashboard, Ihr BI-Werkzeug oder Ihren KI-Agenten einmal an den i3X-Standard an, und es funktioniert weiter, wenn Sie die Middleware oder den Broker darunter austauschen. Binden Sie es stattdessen an das proprietäre Format eines Anbieters, binden Sie jedes Mal neu an, wenn dieser Anbieter seine Meinung ändert. Dieser eine Wechsel, von vielen proprietären APIs zu einer offenen und kontextualisierten, ist der ganze Punkt.

Wie i3X funktioniert: eine herstellerunabhängige gemeinsame API

i3X definiert einen Grundsatz an Server-Primitiven, gruppiert in vier Fähigkeiten: Erkundung, Abfrage, Aktualisierung und Abonnement. Erkundungs-, Abfrage- und Abonnementmethoden sind für einen konformen Server verpflichtend, die Aktualisierung ist optional. Zusammen bilden sie den Kern, der einer Anwendung einen vorhersagbaren, typisierten Umgang mit dem Informationsmodell eines Werks gibt:

• Die Namensräume entdecken, die ein Server bereitstellt.
• Objekttypdefinitionen erkunden, um zu wissen, wie ein „Fertigungsauftrag” oder eine „Maschine” tatsächlich aussieht.
• Konkrete Instanzen dieser Objekte abrufen.
• Durch die hierarchischen Beziehungen zwischen ihnen navigieren.
• Werte abfragen, aktuelle wie historische.
• Änderungen und Ereignisse abonnieren.
• Aktuelle oder historische Werte aktualisieren, sofern der Server das unterstützt.

Dieser Satz an Primitiven ist der technische Grund, warum i3X „KI-fähig” genannt wird. Ein KI-Agent will keinen Schwall anonymer Tags. Er muss entdecken, was existiert, Typ und Bedeutung jedes Objekts verstehen, die Beziehungen dazwischen ablaufen und sowohl den Live-Wert als auch dessen Historie abrufen, alles über einen konsistenten Vertrag. Strukturierter, auffindbarer, typisierter Zugriff ist das, was rohe Daten in etwas verwandelt, worüber ein Modell schlussfolgern kann, statt darum herum zu halluzinieren. Das fehlende Stück war nie die Verkabelung. Es ist die Kante, die Verbindung, die aus einem Messwert eine Tatsache macht, und die fügt erst Bedeutung hinzu.

Eine Grenze gehört klar gesagt, weil sie jedes Projekt prägt. Das Update-Primitiv schreibt Werte, aktuelle oder historische. Die Spezifikation definiert keine Operationen, um Objekttypen, Objekte oder Beziehungen anzulegen, zu ändern oder zu löschen. Das Modellieren bleibt vollständig bei der Plattform, und deshalb wiegt die Frage, wer Ihr Modell schreibt, schwerer als die, welche Plattform es ausliefert.

i3X trägt außerdem mit, woher ein Typ stammt. Die Metadaten jedes Objekts enthalten typeNamespaceUri und sourceTypeId, beide Pflichtfelder, sodass ein Client einen Typ bis zu seiner Ursprungsdefinition zurückverfolgen kann, ob das eine OPC-UA-Companion-Spezifikation, ein ISA-95-Namensraum oder die Definition eines Anbieters ist. Der Zeiger ist standardisiert. Was kein Teil der Spezifikation leistet: Sie verpflichtet zwei Standorte nicht, auf dieselbe Definition zu zeigen, und prüft nicht, ob die referenzierte Definition eingehalten wurde.

i3X Explorer und Werkzeuge für Entwickler

Um die Spezifikation herum gibt es echtes Werkzeug. ACE Technologies veröffentlicht den offiziellen, plattformübergreifenden i3X Explorer, einen GUI-Client zum Durchsuchen des Adressraums jedes konformen i3X-Servers. Es gibt einen öffentlichen Demo-Endpunkt mit Swagger-Seite, einen quelloffenen MCP-Server (dazu unten mehr), und das 1.0-Release bringt eine OpenAPI-Spezifikation, eine Python-Client-Bibliothek und eine Conformance Test Suite mit, die eine Implementierung mit einem von vier Urteilen bewertet: volle 1.0-Konformität, 1.0-Konformität mit unreifem Typsystem, 1.0-Kompatibilität oder nicht konform.

Das zweite Urteil ist das interessante. Eine Implementierung kann jeden Test der Suite bestehen und trotzdem als Trägerin eines dünnen Typsystems markiert werden. Damit räumt CESMII im eigenen Werkzeug ein, dass eine konforme API und eine modellierte API zwei verschiedene Dinge sind. Spezifikation und Referenzmaterial liegen im öffentlichen GitHub von CESMII, wo auch Governance und das Open-Source-Beitragsmodell zu Hause sind.

i3X vs. OPC UA: wo welcher Standard hingehört

i3X ersetzt OPC UA nicht. OPC UA holt Daten an der Edge von den Maschinen, und i3X standardisiert, wie IT- und KI-Anwendungen bereits kontextualisierte Daten darüber abfragen. Sie arbeiten auf verschiedenen Schichten und lösen verschiedene Probleme.

Wenn Sie heute OPC-UA-Konnektivität betreiben, sehr oft über Kepware, lautet Ihre eigentliche Frage, ob i3X Ihre bestehende OPC-UA-Schicht ersetzt. Tut sie nicht. Sie ergänzt sie. OPC UA macht weiter, was es gut kann: zuverlässige Echtzeiterfassung aus der Fertigung. i3X sitzt darüber als anwendungsseitige Abfrageschnittstelle, sodass es dem Analytik-Stack und den KI-Agenten egal wird, aus welchem Historian oder Broker die Daten kamen. Ihre Investition an der Edge bleibt genau dort, wo sie ist.

Das Datenzugriffsmodell: wo i3X im Stack sitzt

CESMII verortet i3X in dem, was sie das Data Access Model nennt, und vergleicht den i3X-Stack mit dem hinter einem gewöhnlichen Webbrowser. Der Vergleich lohnt sich. Ein Browser holt keine Bytes vom Festplattencontroller, er bittet eine klar definierte Schicht darüber um ein Dokument. i3X spielt dieselbe Rolle für Fertigungsinformationen. OPC UA und MQTT leisten die Schwerarbeit auf den unteren, Edge-nahen Schichten, und i3X arbeitet darüber, wo Daten bereits Struktur und Bedeutung erhalten haben. Die Spezifikation sagt ausdrücklich, dass Informationen, die die API erreichen, zuvor durch Kontextualisierungsfunktionen verarbeitet worden sein sollen. So gesehen löst sich die Gegenüberstellung „i3X gegen OPC UA” auf. Sie sind Nachbarn im selben Stack, keine Rivalen um dieselbe Sprosse.

i3X und der Unified Namespace: die fehlende Abfrageschicht

Ein Unified Namespace übernimmt ereignisgetriebenes Publish-Subscribe in Echtzeit über MQTT oder NATS. i3X ergänzt die standardisierte Abruf- und Abfrageschnittstelle, die ein UNS für IT- und Analytiksysteme nie leisten sollte. Beide ergänzen sich, aber hier steckt eine Feinheit, die die meisten Erklärungen auslassen, und sie ist für KI enorm wichtig.

Ein Unified Namespace ist wirklich gut für Telemetrie: eine Temperatur, eine Maschinenlast, ein Zykluszähler, wo der neueste Wert den alten schlicht ersetzt. Der Ärger beginnt, wenn derselbe einzelne Baum auch als alleinige Quelle der Wahrheit für Transaktionsdaten behandelt wird, also Fertigungsaufträge, Rezeptversionen, Chargenaufzeichnungen und Qualitätsergebnisse. Solche Daten haben ein Leben. Eine als gut gebuchte Schicht wird zwei Tage später verschrottet, wenn die Qualität nachzieht. Der Datensatz entsteht, wird korrigiert, manchmal storniert, und seine Historie ist der ganze Sinn (mehr dazu in From Signal to Structure). Kippen Sie beide Datenarten in einen Last-Value-Namensraum, und die Telemetrie sieht gut aus, während die Transaktionsdaten still verrotten.

„MQTT behält nur den letzten Wert. Ein Auftrag ist kein letzter Wert. Seine Historie ist der ganze Sinn.”

Es gibt noch ein tieferes Problem. Selbst wenn ein Broker einen Wert einwandfrei zustellt, kann er Ihnen nicht sagen, dass der Wert richtig ist. Zwei Systeme publizieren. Eines sagt, die Charge hatte 100, das andere 240. Der Broker reicht beide mit sauberem Zeitstempel weiter und sagt nie, welches falsch liegt. Zustellung war längst gelöst. Wahrheit nicht. Sauber ist nicht dasselbe wie wahr, und ein Diagramm, das eine Keynote gewinnt, muss trotzdem eine Bestellung an einem Dienstag überstehen.

Deshalb ist i3X mehr als Bequemlichkeit. Sie gibt IT, Analytik und KI eine standardisierte Abfrageschnittstelle auf kontextualisierte Daten, aktuelle wie historische, mit intakten Beziehungen, die über dem Message Broker sitzt statt an seiner Stelle. Ein Einbaum-UNS ist ein hervorragender Telemetriebus und eine schlechte Quelle der Wahrheit. Von oben nach unten gelesen sieht der Stack so aus: IT- und KI-Clients, dann die i3X-API-Schicht, dann der Message Broker im Kern Ihres UNS, dann Datenharmonisierung und Protokollkonverter und schließlich die OT-Ebene.

i3X und KI: die Verbindung zu MCP (Model Context Protocol)

Wenn MCP die Grammatik ist, mit der ein KI-Agent sich an eine Datenquelle anbindet, dann ist i3X der Wortschatz der Fabrik: die geteilten Definitionen dessen, was ein Fertigungsauftrag, eine Charge oder eine Maschine tatsächlich ist. Zusammen machen sie Fertigungsdaten für KI-Agenten nutzbar. Das Model Context Protocol ist ein offener Standard, um KI-Agenten mit Werkzeugen und Daten zu verbinden, und i3X gibt dieser Verbindung etwas Sinnvolles zu besprechen.

Die beiden passen bewusst zusammen. i3X 1.0 kommt mit einem offiziellen MCP-Server, veröffentlicht auf GitHub und npm, der gegen jeden konformen i3X-Endpunkt arbeitet. Eine Frage in natürlicher Sprache lässt sich gegen ein echtes Werk beantworten: Der Agent entdeckt das Modell, fragt die Daten ab und liefert eine Antwort, die im Kontext des Werks verankert ist. HighByte hat ein ähnliches Ergebnis aus anderer Richtung gezeigt. In der öffentlichen Demonstration verbindet sich ein in Microsoft Foundry gebauter Agent allein über die i3X-OpenAPI-Spezifikation mit dem i3X-Server im HighByte Intelligence Hub und arbeitet ohne jede Sonderintegration mit modellierten Werksdaten.

Hier zählt auch Disziplin, und hier verwende ich den Begriff DefensibleAI. Machen Sie die Schicht darunter falsch, und die KI darüber gibt flüssige, selbstsichere Antworten auf Daten, die einander still widersprechen; beim ersten Einspruch gegen eine Empfehlung lässt sich nicht zeigen, wie sie zustande kam. Setzen Sie KI auf ein System, das das Was protokolliert hat, aber nie das Warum, und der Agent erbt denselben blinden Fleck. Die Reihenfolge, auf der ich bestehe, ist einfach. Erst Trennung, dann Entdeckung, zuletzt Intelligenz. i3X macht die Entdeckungsschicht vertrauenswürdig, damit die Intelligenzschicht rechenschaftsfähig ist.

„Die KI darüber gibt flüssige, selbstsichere Antworten auf Daten, die einander still widersprechen. Und beim ersten Einspruch gegen eine Empfehlung lässt sich nicht zeigen, wie sie zustande kam. Erst Trennung. Dann Entdeckung. Zuletzt Intelligenz.”

Von der Beta zu i3X 1.0: Versionsverlauf und Lieferumfang

i3X ging im April 2026 von der Beta in eine vollständige 1.0-Spezifikation über, getaggt am 9. Juni und angekündigt am 18. Juni 2026. Dieses Datum zählt. Viel Material, das noch online kursiert, beschreibt i3X als „Alpha” oder Vorabversion. Das stimmt nicht mehr. Sie ist finalisiert und heute implementierungsbereit.

Das 1.0-Paket liefert den vollständigen Werkzeugkasten, um eine echte Implementierung zu bauen und zu prüfen:

• Implementierungsleitfaden
• OpenAPI-Spezifikation
• Conformance Test Suite
• Aktualisierter i3X Explorer
• Python-Client-Bibliothek
• MCP-Server
• SDK-Dokumentation

Eines sollten Sie noch wissen, bevor Sie darum herum planen. CESMII hat erklärt, dass die API-Definition jetzt stabil ist und dass bis zur Einsetzung eines neuen Mandats Ende 2026, mit dem die Arbeit an vNext beginnt, nur Dokumentations- und Demo-Themen bearbeitet werden. Änderungen an der Spezifikation und neue Funktionen gehen in vNext. Für ein Projekt, das jetzt startet, heißt das: Die Schnittstelle bewegt sich dieses Jahr nicht unter Ihnen weg, und es gibt ein benanntes Fenster für die Dinge, die Sie sich anders gewünscht hätten.

1.0 geht also deutlich über ein Whitepaper hinaus. Es ist eine Spezifikation mit Werkzeugen, Tests und Referenzclients, um in Produktion zu gehen. Für einen aufkommenden Standard ist das ungewöhnlich vollständig, und genau das macht den Bau auf i3X zu einer vernünftigen Wette.

Wer setzt i3X ein? Anbieter, Ökosystem und reale Implementierungen

Die 1.0-Ankündigung nennt 44 Technologieanbieter aus der Fertigung hinter dem Standard. Der Hintergrund der Spezifikation benennt die Plattformen, aus denen ihre Mitwirkenden kommen: HighByte, Inductive Automation, Rockwell Automation, Siemens und ThinkIQ, mit mehr als fünfzig Jahren gemeinsamer Erfahrung in Software für Fertigungsinformationen. Zur Arbeitsgruppe gehören außerdem AWS, Microsoft, Georgia-Pacific und GE Appliances, was verhindert, dass daraus die Marketingschicht eines einzelnen Anbieters wird. Unter den laufenden Implementierungen stellt HighByte einen i3X-Server aus seinem Intelligence Hub bereit, über den Anwendungen modellierte Daten durchsuchen, lesen, schreiben und abonnieren können. Der oben erwähnte i3X Explorer von ACE Technologies gibt Entwicklern einen fertigen Client, um solche Server zu testen.

Einen Standard zu unterstützen und ihn auszuliefern sind zwei verschiedene Zählungen. Öffentlich überprüfbare i3X-Schnittstellen sind noch deutlich seltener als die 44 in der Ankündigung genannten Anbieter, was wenige Monate nach einem 1.0-Release normal ist und bei der Planung gut zu wissen.

Die Aufmerksamkeit der Analysten ist gefolgt. Colin Masson von der ARC Advisory Group hat eine ausführliche Analyse dazu veröffentlicht, wie i3X die Lücke im Context Engineering industrieller Data Fabrics schließt, und in der 1.0-Ankündigung merkte Matthew Littlefield von LNS Research an, dass i3X gleichzeitig von Technologieanbietern implementiert und von Endanwendern eingesetzt wird.

Wer steht hinter CESMII und dem Smart Manufacturing Mindset?

CESMII, The Smart Manufacturing Institute, ist das US-amerikanische Institut für intelligente Fertigung. 2016 gegründet und vom US-Energieministerium finanziert, verfügt das gemeinnützige Konsortium über eine Investitionszusage von insgesamt 201 Millionen US-Dollar aus DOE-Mitteln sowie öffentlichen und privaten Beiträgen. Programmatischer und administrativer Sitz ist die UCLA, und es gehört zum Netzwerk Manufacturing USA. i3X ist ein Ergebnis des breiteren Smart-Manufacturing-Programms dieses Konsortiums, und deshalb wird sie als offener Standard verwaltet statt von einem einzelnen Unternehmen besessen. CESMII fasst diese Arbeit in dem zusammen, was sie den Smart Manufacturing Mindset nennt, und i3X ist darin das Interoperabilitätsstück.

i3X in Ihren bestehenden OT/IT-Stack bringen: ein praktischer Einführungsweg

Für einen Hersteller, der bereits OPC-UA-Konnektivität betreibt, sehr oft über Kepware, bedeutet die Einführung von i3X, eine kontextualisierte Abfrageschicht obendrauf zu legen, nicht den OT-Stack neu zu bauen. Hier hören die meisten Erklärungen auf, und hier beginnt die eigentliche Arbeit. Das ist der Weg, den wir mit Kunden in unseren Digital-Manufacturing-Projekten gehen:

1. Bewerten Sie die Reife Ihrer Konnektivität. Kartieren Sie, was Sie schon haben: Historians, einen Unified Namespace, Erfassung über OPC UA und Kepware. i3X setzt voraus, dass zuverlässige Datenerfassung bereits existiert. Sie reißt sie nicht heraus.
2. Kontextualisieren Sie die Daten mit Informationsmodellen. Aus rohen Tags wird Bedeutung durch Modelle. Nutzen Sie CESMIIs Smart Manufacturing Profiles oder eine an ISA-95 ausgerichtete Struktur, die jeden Fertigungsauftrag als drei getrennte Datensätze führt: die Produktdefinition (das Rezept), die Operationsanforderung (den Plan) und die Operationsausführung (das tatsächliche Ergebnis). Rezept, Plan und Ausführung, nie vermischt.
3. Stellen Sie kontextualisierte Daten über einen i3X-konformen Server bereit. Das ist Konfiguration, kein Code. Ein Konnektor scannt, was ein System ohnehin bereitstellt, bildet es mit KI-Hilfe ausschließlich zur Entwurfszeit auf ein Standardprofil ab und erzeugt eine geprüfte Konfiguration, die Ihre bestehende Middleware ausführt. Sie fasst den Live-Datenstrom nie an. Die erste Maschine eines Typs ist echte Arbeit. Die hundertste dauert Minuten.
4. Verbinden Sie Ihre IT-, Analytik- und KI-Clients über den Standard, einschließlich MCP-basierter Agenten, mit einer einzigen stabilen Schnittstelle.

„Konfiguration, kein Code. Sie fasst den Live-Datenstrom nie an. Die erste Maschine eines Typs ist echte Arbeit. Die hundertste dauert Minuten.”

Unter allen vier Schritten liegt der strategische Punkt: Das Schema ist das Asset. Konfiguration ist Daten. Sie versionieren sie, prüfen sie, rollen sie zurück und besitzen sie. Das ist es, was Souveränität wirklich heißt. Souveränität hängt nicht daran, wo die Server stehen. Sie hängt daran, wem das Modell gehört, das definiert, was ein Fertigungsauftrag ist und was OEE bedeutet. Sie können dieses Modell in der Plattform eines Anbieters mieten und am Tag des Vertragsendes mit den Zeilen hinausgehen und die Bedeutung zurücklassen. Oder Sie behalten es als eigenes, standardbasiertes Schema. Als Schneider Electric am 30. Juni 2026 eine Vereinbarung zur Übernahme von Cognite für 3,1 Milliarden US-Dollar ankündigte und damit die Schicht über den Fertigungsdaten kaufte, hörte diese Wahl auf, abstrakt zu sein. Besitzen Sie das Gehirn, mieten Sie es nicht. i3X macht dieses Besitzen praktikabel. Dieselbe Logik gilt für Ihren Audit-Trail. Wenn die Historie, die belegt, was passiert ist, still geändert werden kann oder in einem Speicher liegt, den der Anbieter kontrolliert, gehört sie Ihnen nicht wirklich.

Wann i3X die richtige Wahl ist und wann nicht

i3X passt gut zu Multi-Anbieter-Umgebungen, zur Entwicklung portabler Anwendungen, zur Integration im Brownfield sowie zu standortübergreifender Analytik und OEE-Dashboards, wo Konsistenz zwischen den Werken das Ziel ist. Sie ist nicht das richtige Werkzeug für harte Echtzeit-Regelkreise, für Event-Streaming mit sehr hohem Durchsatz oder für einen Betrieb auf einer einzigen Plattform, in dem es noch nichts gibt, womit man interoperieren müsste. Zu wissen, wo sie nicht hingehört, gehört dazu, sie gut zu nutzen.

Wenn Sie Ihr eigenes Werk morgen kartieren würden, welche einzelne Verbindung würde die meisten Antworten freischalten, die Sie heute nicht bekommen?

Über den Autor

Tobias Lante ist AI Agent Architect for Manufacturing bei Transition Technologies PSC, wo er daran arbeitet, Fertigungsdaten für KI nutzbar und belastbar zu machen. Auf LinkedIn schreibt er eine fortlaufende Serie zu Industrial DataOps und i3X, darunter From Signal to Structure, What Each Connection Is Worth und The Graph Comes Out of the Schemas. Sein Kommentar zum Start der i3X-Beta wurde auch in der Hannover-Messe-2026-Folge des Frenus-Podcasts „Best of LinkedIn: Smart Build & Manufacturing” aufgegriffen. Folgen Sie seiner Arbeit auf LinkedIn.