Ein Analytics-System soll Produktionsdaten aus OSIsoft PI, Ignition Historian und Siemens MindSphere gleichzeitig abfragen – doch jede Plattform spricht eine andere API-Sprache. Der Unified Namespace (UNS) löst die horizontale Integration exzellent: Echtzeit-Events fließen via MQTT oder NATS zwischen OT- und IT-Systemen. Allerdings fehlt dem UNS ein standardisiertes Interface für den strukturierten, query-basierten Datenzugriff von IT-Seite (Pull Zugriff). i3X von CESMII will genau diese Lücke schließen – als offene API-Spezifikation, die heterogene Manufacturing-Plattformen mit einer einheitlichen Query-Schnittstelle zugänglich macht.
Warum i3X? Das n×m Integrationsproblem
Die API-Landschaft in modernen Manufacturing-Umgebungen ist fragmentiert. OSIsoft PI nutzt die PI Web API, Ignition Historian arbeitet mit einer eigenen RESTful API, Siemens MindSphere setzt auf proprietäre Endpoints. Daher wächst der Integrationsaufwand mit jeder neuen Plattform oder IT-Anwendung quadratisch: Fünf Plattformen × fünf IT-Systeme bedeuten 25 Custom-Integrationen, die entwickelt und gewartet werden müssen.
Der UNS mit MQTT und NATS löst die horizontale IT/OT Integration hervorragend: Events fließen in Echtzeit über den UNS nach dem Pub/Sub-Prinzip. Was jedoch fehlt, ist ein standardisiertes Query-Interface für IT-Systeme, die historische Produktionsdaten strukturiert abfragen wollen. Für diesen Pull-Zugriff muss jedes IT-System heute gegen die native API der jeweiligen Plattform, sei es die UNS oder die IT Plattform, entwickelt werden.
Was ist i3X von CESMII?
i3X von CESMII – ausgeschrieben „Common Contextual Manufacturing Information API“ – ist eine offene API-Spezifikation für standardisierten Datenzugriff auf heterogene Manufacturing-Plattformen. Plattform-Anbieter sollen künftig i3X implementieren können, sodass IT-Systeme anschließend mit einer einheitlichen Schnittstelle auf alle kompatiblen Systeme zugreifen. i3X wird von CESMII (Clean Energy Smart Manufacturing Innovation Institute) entwickelt – einem US-amerikanischen Institut für Smart Manufacturing.
| Was i3X ist | Was i3X NICHT ist |
|---|---|
| API-Spezifikation (RFC): i3X definiert, welche Endpoints, Query-Patterns und Datenstrukturen Manufacturing-Plattformen bereitstellen sollten – keine Custom-Adapter pro Datenquelle. |
Kein Protokoll: MQTT, OPC UA und NATS transportieren Daten zwischen Systemen. i3X definiert, wie Apps diese Daten abfragen – es ersetzt keine Transport-Protokolle. |
| Kontextualisierte Daten: i3X operiert auf bereits verarbeiteten Daten mit ISA-95-Kontext (z.B. aus dem Unified Namespace), nicht auf Rohdaten vom Shopfloor. |
Kein Message Broker: NATS- oder MQTT-Broker vermitteln Pub/Sub-Nachrichten im Unified Namespace (UNS). i3X operiert eine Ebene höher – auf dem Data Access Layer über diesen Brokern. |
| Application-Layer-Fokus: Zielgruppe sind IT-Systeme (Analytics, BI-Tools, ML-Pipelines), die historische Daten abfragen, nicht OT-Echtzeit-Steuerungen. |
Kein Ersatz für den Unified Namespace: Der Unified Namespace ist eine Publish/Subscribe-Architektur mit Message Brokern als Kern. i3X kann innerhalb eines UNS als API-Gateway-Layer genutzt werden, definiert aber nicht den ISA-95-Kontext selbst. |
Entwicklungsstatus (Stand 2026)
Die Spezifikation befindet sich aktuell in Pre-Alpha-Phase. Es handelt sich dabei um einen RFC (Request for Comments), keine fertige Implementierung. Eine Demo-Instanz steht auf Github zur Verfügung.
Auf welcher Ebene standardisiert i3X? – Einordnung im Data Access Model
Um zu verstehen, wo i3X ansetzt, hilft das Data Access Model nach Matthew Parris: Es unterteilt IT/OT-Interoperabilität in sechs aufeinander aufbauende Ebenen – von L0 (Transport: z.B. TCP/IP) bis L5 (Objects: semantische Datenmodelle). Echte Plug-and-Play-Interoperabilität erfordert Konsistenz auf allen Ebenen. Einen vollständigen Überblick liefert der Detailartikel: IT/OT-Interoperabilität im UNS – Grundlagen.
i3X von CESMII nutzt bestehende Transportstandards und will konsequent die oberen Schichten standardisieren – genau dort, wo heterogene IT Plattformen heute auseinanderlaufen. Dadurch greifen IT-Systeme mit identischen Queries auf OSIsoft PI, Ignition oder jede andere i3X-kompatible Plattform zu – ohne plattformspezifische Adapter-Entwicklung.
Zielgruppen von i3X
Zwei Zielgruppen profitieren direkt:
- App-Entwickler (primär): Analytics-Entwickler, ML-Engineers und Dashboard-Spezialisten, die eine portable Integration ohne plattformspezifische Custom-Adapter benötigen
- Plattform-Anbieter (sekundär): Historian-Vendors und industrielle IoT-Plattformen, die durch i3X-Implementierung ihre Interoperabilität und Marktakzeptanz verbessern
i3X vs. Message Broker vs. OPC UA – auf einen Blick
Die folgende Tabelle verdeutlicht, dass i3X von CESMII nicht mit bestehenden Protokollen konkurriert, sondern eine komplementäre Ebene adressiert.
Beispiel zur Veranschaulichung: NATS transportiert Temperatur-Events in Echtzeit für Monitoring- oder Streaming-Analytics-Anwendungen. Zudem ermöglicht i3X standardisierte Abfragen auf den UNS-Namespace sowie auf einzelne Datenpunkte wie „Temperatur“ für Pull-basierte Anwendungen. Beispielsweise kann ein Instandhaltungssystem so den aktuellen Inhalt einer Qualitäts-Queue (z. B. offene Prüflose) auslesen. Beide Patterns koexistieren im selben UNS-Stack und adressieren unterschiedliche Anwendungen.
| Aspekt | i3X | OPC UA | Message Broker (z.B. NATS) |
|---|---|---|---|
| Typ | API-Spezifikation (RFC) | Industrie-Kommunikationsstandard | Pub/Sub-Protokoll |
| Standardisiert | L2–L5 | L0–L5 | L0–L1 |
| Anwendung | IT | OT | IT-OT |
| Kommunikation | Pull (Request/Response) | Client/Server + Pub/Sub | Push (Pub/Sub) |
| Latenz | Sekunden (Query-basiert) | < 1 ms – 50 ms (profilabhängig) | < 10 ms |
| Echtzeit-Ziel | Keine Echtzeit (Analytics, Reporting, Data Access) | Soft- bis Hard-Real-Time (profilabhängig) | Near-Real-Time (Event Streaming) |
| Wo im UNS | IT-Layer (API) | Edge / OT-Layer | UNS Core |
| Status (2026) | Pre-Alpha | weit verbreitet | weit verbreitet |
i3X im Unified Namespace (UNS) Stack
i3X ist kein Ersatz für den Unified Namespace (UNS), sondern der fehlende API-Layer darüber. Das folgende Stack-Modell zeigt die Positionierung.
Die Schichten mit klar getrennten Aufgaben (Details können Sie im Artikel Middleware Architektur im Unified Namespace (UNS) nachlesen):
- IT Layer: MES, ERP, Analytics – die Konsumenten. Nutzen Daten für Business-Logik, Reporting, KI-Modelle.
- i3X API Layer: Standardisierter, query-basierter Pull-Zugriff für IT-Systeme auf historische und kontextualisierte Produktionsdaten.
- Message Broker (NATS/MQTT): Single Source of Truth (SSOT) für alle Echtzeitdaten.
- Data Harmonization Layer: Normalisiert Einheiten, fügt ISA-95-Kontext hinzu, validiert Schemas.
- Protocol Converters (Edge Gateways): Übersetzt OPC UA, Modbus, S7 → NATS/JSON oder MQTT/JSON.
- OT Layer: SPSen, Sensoren, Antriebe – die Datenquelle. Sprechen proprietäre Protokolle.
Die klare Abgrenzung: i3X ist weder ein Message Broker noch ein Kommunikationsprotokoll. Es ersetzt den UNS nicht – sondern ergänzt ihn als standardisierte Query-Schnittstelle für IT-Systeme, die auf gespeicherte, kontextualisierte Produktionsdaten zugreifen.
Wann ist i3X die richtige Wahl?
i3X ist die richtige Wahl wenn…
- Multi-Vendor-Umgebung: OSIsoft PI, Ignition Historian und MindSphere laufen parallel – eine zentrale Analytics-App soll auf alle drei zugreifen, ohne drei separate Integrationen zu entwickeln
- Portierbare App-Entwicklung: Dieselbe Predictive-Maintenance-App soll bei mehreren Kunden mit unterschiedlichen Plattformen funktionieren – eine i3X-Integration statt fünf proprietärer Adapter
- Brownfield-Integration: Legacy-Systeme mit proprietären APIs sollen für moderne IT-Anwendungen abstrahiert werden, ohne die OT-Schicht anzufassen
- Multi-Site-Analytics: Globale OEE-Dashboards aggregieren Produktionsdaten verschiedener Standorte über eine einheitliche API – unabhängig von lokalen Plattformentscheidungen
Nicht geeignet, wenn…
- Event-Driven-Architekturen: Hoher Durchsatz (>1.000 Messages/sec) für Event-Streaming bleiben UNS Aufgabe mittels Pub/Sub Mechanismen.
- Echtzeit-Steuerung (< 50 ms): Für Closed-Loop-Control bleiben UNS oder direkte SPS-Kommunikation gesetzt – i3X ist Query-basiert und daher für latenz-kritische Steuerungen ungeeignet
- Einzelplattform-Umgebung: Bei nur einer Plattform ist die native API direkter und einfacher – der Zusatzaufwand einer Abstraction-Layer lohnt sich erst bei mehreren Quellen
- Produktionseinsatz geplant: Der Pre-Alpha-Status (Stand 2026) bedeutet, dass signifikante Änderungen bis zur stabilen Version zu erwarten sind
Best Practices für die i3X-Implementierung
| Do | Avoid |
|---|---|
| Layered Architecture: i3X als zusätzlichen Layer über dem UNS-Core positionieren – NATS für Echtzeit-Events, i3X für strukturierte Queries. |
i3X für Echtzeit-Control: Das Query-basierte Pull-Modell ist für latenz-kritische Steuerungen ungeeignet – hier bleiben MQTT und direkte SPS-Kommunikation gesetzt. |
| API-Versionierung: Semantic Versioning einsetzen (z. B. i3x/v1, i3x/v2) – Breaking Changes nur mit Major-Version-Bump. |
Produktionseinsatz vor stabiler Version: Pre-Alpha-Status beachten; RFC-Änderungen bis Q1 2026 erwartet – Entwicklung unter github.com/cesmii/i3X verfolgen. |
| Sichere Authentication: OAuth 2.0 / JWT für alle i3X-API-Zugriffe einsetzen, Role-Based Access Control (RBAC) pro App und User-Rolle konfigurieren. |
i3X als UNS-Ersatz: Der UNS bleibt das Fundament der Architektur – i3X ergänzt ihn als API-Layer, ersetzt ihn jedoch nicht. |
Fazit
i3X von CESMII schließt die Lücke, die MQTT und NATS bewusst offen lassen: den standardisierten, query-basierten Datenzugriff für IT-Systeme auf heterogene Manufacturing-Plattformen. Dadurch löst es das n×m-Integrationsproblem auf den Ebenen L2–L5 des Data Access Models – genau dort, wo heterogene APIs heute Komplexität erzeugen. Drei zentrale Erkenntnisse:
- Komplementär, nicht konkurrierend: i3X ergänzt
MQTT/NATSim UNS – Push für Events, Pull für strukturierte Queries - L2–L5-Standardisierung: i3X von CESMII will Mapping, Encoding, Values und Objects standardisieren – die Schichten, die heute Fragmentierung erzeugen
- Pre-Alpha beachten: Das Potenzial ist klar; die Spezifikation entwickelt sich jedoch noch aktiv.
