Als CESMII i3X im Februar an der ProveIt! gezeigt hat, habe ich aus der Distanz mitverfolgt. Vorträge angeschaut, das RFC gelesen, ins GitHub geschaut.
Ich war skeptisch. Wir kennen das Skript: Starker Auftakt. Dann Jahre voller Hersteller-Erweiterungen. Und am Ende wieder Custom-Adapter.
Aber i3X ist anders. Er ist klein.
Die ganze Spec ist eine einzige API: wie Anwendungen kontextualisierte Fertigungsdaten lesen, egal was darunter liegt. Sie definiert nicht dein Datenmodell. Sie ersetzt nicht OPC UA. Sie versucht nicht, jedes Interop-Problem zu lösen.
Genau diese Zurückhaltung lässt mich glauben, dass sie eine Chance hat.
Warum Standards auf dem Shopfloor immer wieder scheitern
Der Standard-Pitch klingt immer gleich. Universelles Datenmodell. Plug-and-Play-Interoperabilität. Eine Spec, die alle ablöst.
Ein paar Jahre später hat das Modell tausende Typen. Jeder Hersteller hängt Erweiterungen dran, damit es zu seinen bestehenden Produkten passt. Der „Compliant"-Stempel wird ein Marketing-Label. Jedes Integrationsprojekt beginnt trotzdem mit Custom-Mapping-Arbeit.
OPC UA ist der disziplinierteste Versuch, den die Fertigung je unternommen hat. Es funktioniert. Aber die Companion Specifications sind zu einem eigenen Ökosystem aus langsamen Komitees herangewachsen. In den meisten Werken, in die wir hineinkommen, laufen immer noch handgepflegte SPS-Tags, individuelle Historian-Schemas und massgeschneiderte ETL.
Es liegt nicht daran, dass Standards schlecht wären. Sondern daran, dass grosse Standards langsam sind — und langsam überlebt den Kontakt mit dem Shopfloor nicht.
Was i3X tatsächlich definiert
i3X grenzt sich rigoros ein. Aus dem RFC:
- Eine REST-API-Oberfläche zum Erkunden, Abfragen, Subskribieren und Aktualisieren
- Eine kleine Menge Resource-Typen — Namespaces, Objects, Signals, Events
- Value-Quality-Timestamp- (VQT-)Envelopes — Quality ist einer von
Good,GoodNoData,BadoderUncertain - Ein Subscription-Mechanismus für Change-Streams
Mehr nicht.
Sie sagt dir bewusst nicht, wie du deine Fabrik modellieren sollst. Deine Assets bleiben dort, wo sie sind — im Historian, im MES, in OPC UA, in MQTT. i3X ist ein Vertrag dafür, wie eine Anwendung danach fragt, nicht was sie sind.
Die Arbeitsgruppe spiegelt diesen Pragmatismus: Highbyte, Inductive Automation, Rockwell, ThinkIQ, Siemens, AWS, Microsoft. Dazu zwei Hersteller, die mit den Silos gelebt haben: GE Appliances und Georgia-Pacific. Anbieter, die normalerweise jeder ihr eigenes Modell durchdrücken würden, haben sich auf das Kleinste geeinigt, mit dem alle leben können.
Was es brauchte, i3X in PREKIT einzubauen
PREKIT exponiert seine Daten bereits über eine offene REST-API und einen MQTT-basierten Unified Namespace. Das Hinzufügen von i3X war daher weniger eine Integration als eine Übersetzung.
Eine neue Django-App unter edge-api/src/i3x/, eingehängt unter /api/i3x/v1/, mit den Standard-Endpoint-Gruppen:
GET /api/i3x/v1/namespaces
GET /api/i3x/v1/objecttypes
GET /api/i3x/v1/objects
GET /api/i3x/v1/objects/value
GET /api/i3x/v1/objects/history
POST /api/i3x/v1/subscriptions
GET /api/i3x/v1/subscriptions/stream
Rund 1900 Zeilen Python. Eine neue Datenbank-Tabelle — für Subscription-State — und sonst nichts in der Persistenz-Schicht.
Die i3X-Konzepte mappen sauber auf das bestehende PREKIT-Modell:
| i3X-Konzept | PREKIT-Modell |
|---|---|
| Namespace | EdgeNode / HubNode |
| Object Type | SystemElement, DataTag, Resource, Service |
| Signal | Signal |
| Event | Annotation |
| Property | Metadata |
| History | historian_metric-Tabelle |
Beziehungen werden zur Laufzeit aus den bestehenden Foreign Keys und der System-Element-Hierarchie abgeleitet. Authentifizierung nutzt unsere bestehenden Reader-/Writer-Berechtigungen, und die Namespace-skopierte Autorisierung von PREKIT greift unverändert — i3X-Clients sehen nur die Teile des Namespace, die ihr Token freigibt. Schreibvorgänge laufen durch die Smart-Write-Logik des PREKIT-Hubs, die das Edge-vs-Hub-Ownership bereits korrekt behandelt.
Wenn deine Plattform bereits eine offene API und ein sauberes internes Modell hat, ist i3X grösstenteils ein Wrapper. Genau das ist der Sinn der Spec.
Einen generischen Client an einen PREKIT-Hub anschliessen
Wir haben den Referenz-i3X-Explorer von CESMII auf einen unserer Hubs gerichtet, um den Vertrag zu verifizieren. Er hat sich beim ersten Versuch verbunden.
Auf der linken Seite zählt der Explorer den Namespace und die Object Types auf, die unser Hub exponiert — SystemElement, Signal, HubNode, EdgeNode, Resource, DataTag, Service, Computation, Annotation, Metadata. Keiner davon ist ein i3X-Konzept. Es sind PREKITs bestehende Entitäten, durchgereicht über den Object-Type-Vertrag von i3X.
Rechts liest der Explorer die Namespace-Metadaten direkt aus: einen stabilen URI (urn:prekit:i3x:hub:...), einen Display-Namen, rohes JSON. Darunter taucht derselbe Explorer in die Hierarchie ein — prekit-hub → Abfüllerei und so weiter, bis hinunter zu den eigentlichen Produktionsanlagen, ihrer Historie und Live-Subscriptions.
Das Spannende: wir haben keinen Code für den Explorer geschrieben. Er ist ein generischer Client. Er musste nur i3X sprechen können. Genau das ist der Sinn der Spec.
Was i3X nicht ist
Wenn du einen Standard willst, der deine Asset-Hierarchie definiert, nimm ISA-95 oder eine OPC-UA-Companion-Spec. i3X macht das nicht.
Wenn du garantierte semantische Kompatibilität zwischen zwei Werken willst, musst du dich immer noch auf Benennungen einigen. i3X sagt dir, dass beide Werke Signal-Objekte mit value, quality und timestamp exponieren. Es sagt dir nicht, dass das eine einen Wert Cycle Time nennt und das andere Taktzeit.
Und i3X ist jung. Tooling, Conformance-Tests und Ökosystem-Unterstützung sind noch dünn. Die erste Adoptionswelle werden Hersteller sein, die es schreiben, weil es billig zu schreiben ist — nicht Kunden, die es einfordern, weil es überall ist.
Das ist in Ordnung. So verbreiten sich kleine Standards.
Werden europäische Hersteller sich dafür interessieren?
Ein Historian in Stuttgart hat dieselbe Lock-in-Geschichte wie einer in Houston: Hersteller-Varianten, Custom-Adapter, zehn verschiedene Formen von „gib mir die letzte Stunde Daten für Asset X". Die meiste i3X-Energie kommt aktuell aus den USA, aber nicht alle — Prosys, der finnische OPC-UA-Tool-Anbieter, hat seine Forge-Plattform mit i3X demonstriert und kombiniert dabei Smart Manufacturing Profiles mit einem i3X-kompatiblen Interface für Unified-Namespace-Anwendungsfälle. Das ist ein nützliches Signal. Das Risiko ist dasselbe, das auch die OPC-UA-Companion-Specs hatten — jedes regionale Ökosystem erfindet seinen eigenen Dialekt, bevor der kleine Standard wandern kann. Ein Signal in Deutschland sollte aussehen wie ein Signal in Texas. Wenn wir zu lange warten, wird es das nicht.
Deshalb haben wir es jetzt eingebaut. Nicht weil Kunden danach fragen — tun sie noch nicht. Sondern weil die Kosten, es zu unterstützen, solange die Spec klein ist, niedrig sind, und die Kosten, später fünfzehn Hersteller-Varianten zu unterstützen, hoch.
Loslegen
Wenn du PREKIT betreibst, sind die i3X-Endpoints in der aktuellen Hub-Release als Beta verfügbar, eingehängt unter /api/i3x/v1/. Deine bestehenden Reader- und Writer-Tokens authentifizieren sich bereits dagegen. An deinem Datenmodell muss sich nichts ändern.
Wenn du PREKIT nicht betreibst, ist die Spec selbst einen Nachmittag deiner Team-Zeit wert. Lies das RFC. Setz den Referenz-Explorer auf. Richte ihn auf irgendeine IIoT-Plattform, die du hast. Die Form der Lücke verrät dir viel über diese Plattform.
Anerkennung an CESMII und alle, die zur i3X-Arbeitsgruppe beigetragen haben. Klein, fokussiert, lieferbar — sie haben den Brief getroffen.
Einen Blick wert, bevor Hersteller-Varianten auftauchen.
Für mehr Hintergrund siehe unseren früheren Beitrag Was ist eigentlich ein Unified Namespace? und (auf Englisch) Schematic and Semantic Data Contracts in a Unified Namespace — die Lücke bei den Benennungen, die i3X bewusst nicht zu schliessen versucht.