Die Digitalisierung verlangt Architekturen, die Produktionsdaten in Echtzeit, sicher und kontextualisiert in IT- und Cloud-Systeme integrieren. Klassische, pollingbasierte REST-APIs sind dabei im IT/OT Kontext oft nicht die beste Wahl: Sie erzeugen hohen Netzwerk- und Ressourcenaufwand, verursachen Latenzen und sind nur eingeschränkt skalierbar. Im Gegensatz dazu haben sich mit MQTT und dem Unified Namespace (UNS) eventbasierte Architekturen etabliert, die Datenflüsse zwischen IT und OT effizient bündeln. Dennoch bleiben HTTP-Schnittstellen unverzichtbar, da viele Enterprise-Systeme, Cloud-Plattformen und Drittanwendungen weiterhin auf etablierte HTTP-Standards setzen. Hier setzen industrielle APIs an: Sie verbinden die Effizienz eventbasierter Kommunikation mit der breiten Kompatibilität von HTTP und stellen Produktionsdaten standardisiert, sicher und eventbasiert für Systeme wie ERP, MES oder Analytics bereit.
Limitierungen klassischer REST APIs im IT/OT-Kontext
Im IT/OT Kontext entscheidet die Fähigkeit, Echtzeitdaten zuverlässig bereitzustellen, über Produktivität, Flexibilität und Innovationsgeschwindigkeit. Ob beim Condition Monitoring, im Digital Twin oder in der KI-gestützten Produktionsplanung – Systeme müssen Datenströme zwischen Maschinen, IT- und Analytics Systemen in Millisekunden austauschen und verarbeiten.
Klassische REST-APIs sind in der IT-Welt weit verbreitet, da sie für transaktionsorientierte Workloads wie Benutzer-Authentifizierung, Stammdatensynchronisation oder Reporting entwickelt wurden. Diese Anwendungsfälle sind in der Regel zustandslos, request/response-basiert und tolerieren Abfrageintervalle im Sekunden- oder Minutenbereich, ohne dass Latenz signifikante Auswirkungen hat. In der IT/OT-Integration gelten jedoch andere Anforderungen: Produktionssysteme müssen kontinuierliche Datenströme nahezu in Echtzeit bereitstellen, oft mit Reaktionszeiten im Millisekundenbereich. Genau hier offenbaren REST-APIs strukturelle Schwächen:
- Polling-Overhead
- REST-APIs sind in der Regel request/response-basiert. Clients müssen regelmäßig aktiv Anfragen stellen, um den aktuellen Zustand zu prüfen („Polling“).
- Das führt zu höherem Netzwerk-Traffic, auch wenn keine neuen Daten vorliegen.
- Höhere Latenz
- Zwischen einer Zustandsänderung in der Maschine und der nächsten Polling-Anfrage vergeht Zeit.
- Kritische Ereignisse (z. B. Maschinenstörung, Qualitätsabweichung) werden dadurch verzögert erkannt.
- Ineffiziente Ressourcennutzung
- CPU und Speicher werden sowohl auf Server- als auch auf Client-Seite belastet, da ständig Requests verarbeitet werden müssen.
- Besonders in Edge- und SPS-Umgebungen mit begrenzter Rechenleistung ist das suboptimal.
Unified Namespace (UNS) als Basis für industrielle APIs
Die beschriebenen Limitierungen lassen sich durch eine eventbasierte Architektur auf Basis eines Unified Namespace (UNS) überwinden. Der UNS bündelt Produktions- und Geschäftsdaten in einem semantisch strukturierten Namensraum und verteilt Änderungen über Publish/Subscribe-Mechanismen. Broker-Technologien wie MQTT ermöglichen dabei eine skalierbare, entkoppelte Kommunikation zwischen OT- und IT-Systemen. So entsteht ein Single Source of Truth (SSOT), in dem Maschinen, Sensoren, ERP- und Historian-Systeme Daten bereitstellen. Diese können dann von MES, Analytics-Tools oder KI-Agenten in Echtzeit abonniert werden – ohne die Quellsysteme zu belasten. Damit wird der UNS zur Grundlage einer durchgängigen IT/OT-Integration und bildet die optimale Basis für industrielle APIs.
Industrielle APIs: Funktion und Vorteile
Auf Basis des UNS lassen sich industrielle APIs neu definieren: nicht mehr als klassische REST-Endpunkte mit festen Polling-Intervallen, sondern als eventbasierte Schnittstellen, die UNS Datenpipelines in Echtzeit anstoßen. Diese Datenpipelines können beliebige Aktionen ausführen, z.B.:
- Messwerte aus dem UNS lesen
- Berechnungen durchführen
- Daten anreichern oder an Systeme senden
- und optional ein Ergebnis per API zurückgeben.
Der Auslöser (Trigger) erfolgt dabei eventbasiert über Webhooks: Ein angebundenes System – etwa ein MES, ERP oder KI-Agent – sendet eine HTTP Anfrage, woraufhin die Pipeline automatisch die relevanten Echtzeit- und Kontextdaten aus dem UNS aggregiert, verarbeitet und zurückliefert. So lassen sich Systeme on-demand mit konsolidierten Produktionsdaten versorgen – ohne ineffizientes Polling oder proprietäre Schnittstellen.
Warum Webhooks?
Der zentrale Unterschied zwischen REST APIs und Webhooks liegt im Kommunikationsmuster:
- REST ist request/response-basiert und setzt auf Polling, d. h. ein Client muss regelmäßig Anfragen stellen, um Datenänderungen zu erkennen. Das erzeugt unnötigen Overhead, erhöht die Latenz und skaliert schlecht bei hochfrequenten Datenströmen im Shopfloor.
- Webhooks hingegen sind eventgesteuert: Das System sendet bei einem definierten Ereignis automatisch eine HTTP-Nachricht an registrierte Empfänger. Damit wird die Datenübertragung push-basiert, sofort ausgelöst und ohne wiederholte Abfragen realisiert.
Für den industriellen Kontext bedeutet das: REST eignet sich vor allem für punktuelle, transaktionsorientierte Abfragen (z. B. Stammdaten, Konfiguration), während Webhooks eine effiziente Möglichkeit bieten, MQTT-Events oder UNS-Daten in bestehende IT-Systeme mit HTTP-Schnittstellen zu integrieren – in Echtzeit und mit minimalem Overhead.
Varianten industrieller APIs
Auf Basis eines UNS entstehen zwei grundlegende API-Varianten, die sich deutlich von klassischen CRUD-Endpunkten unterscheiden. Hinter jedem Aufruf steckt keine einfache Datenabfrage, sondern eine Pipeline, die den gesamten UNS-Kontext einbezieht – inklusive Echtzeitwerten, Metadaten und optionaler Anreicherung mit historischen Informationen.
- Request/Response APIs: Hierbei ruft ein externer Client (etwa eine Anwendung oder ein Service) den Webhook auf und wartet auf die Antwort. Die entsprechende Pipeline läuft an und liefert ein strukturiertes Ergebnis zurück, typischerweise in Form von JSON. Dieses Muster eignet sich, um aktuelle Prozesswerte oder Kennzahlen abzurufen – z.B. ein KI Agent, das per API den aktuellen Status einer Maschine anfragt.
- Fire-and-Forget APIs: Der Client ruft den Webhook auf, die Pipeline wird gestartet und läuft asynchron im Hintergrund. Dieses Muster eignet sich vor allem für nicht-kritische, asynchrone Prozesse, bei denen der Client nicht auf ein Ergebnis angewiesen ist – etwa das Auslösen einer Benachrichtigung oder das Protokollieren eines Ereignisses für die spätere Analyse.
Vorteile industrieller APIs
Neben Ressourceneffizienz und Skalierbarkeit liegt ein wesentlicher Vorteil von Webhook-basierten APIs in ihrer Dynamik und Kontextsensitivität. Im Gegensatz zu starren Endpunkten können sie Eingabedaten wie Parameter, Query-Strings oder JSON-Bodies verarbeiten und damit das Verhalten der Pipelines im UNS dynamisch steuern. Ein einziger API-Endpunkt kann so je nach Kontext unterschiedliche Aktionen ausführen oder Ergebnisse liefern, z. B.:
- Zielauswahl: Parameter definieren, auf welche Maschine sich die Pipeline beziehen soll (z. B. Maschinen-ID). So kann derselbe API-Endpunkt flexibel auf verschiedene Maschinen im UNS angewendet werden.
- Datenfilterung: Query-Parameter spezifizieren den Zeitraum der Abfrage (z. B. „letzte 60 Sekunden“). Die Pipeline passt daraufhin ihre Datenbereitstellung dynamisch an.
- Bedingte Logik: Eingabewerte wie mode=simuliert steuern Ausführungspfade. So werden anstelle realer Aktor-Befehle nur Testdaten generiert und durchlaufen.
Durch diese Input-Awareness werden industrielle APIs kontextadaptiv. Anstatt zahlreiche spezialisierte Endpunkte zu pflegen, genügt ein intelligenter Endpunkt, der sich über Parameterisierung flexibel erweitern lässt. Skalierung erfolgt durch Parametrisierung, nicht durch Schnittstellen-Vervielfachung.
Architekturbeispiel i-flow Unified Namespace (UNS)
Industrielle Anwendungsfälle haben unterschiedliche Anforderungen an Latenz, Verfügbarkeit und Sicherheit. Daher ist es essenziell, APIs nicht nur zentralisiert, sondern auch dezentral auf Edge-Ebene bereitzustellen – je nach Use-Case.
Zentrale API Bereitstellung über den Hub
Die in den Werken verteilten i-flow Edges registrieren die verfügbaren Webhook-APIs im i-flow Hub. Dieser fungiert als zentrale API-Oberfläche für den gesamten Unified Namespace (UNS). Externe Aufrufe laufen über den Hub, der die Ausführung der Pipelines auf den Edges orchestriert. Dies ermöglicht eine zentralisierte Steuerung bei gleichzeitig vollständigem Zugriff auf verteilte Pipelines und Systeme.
Vorteile:
- Zentraler Endpunkt: Externe Systeme greifen über eine einheitliche API-Schnittstelle zu, ohne mehrere unterschiedliche Edge-Adressen zu verwalten.
- Zentrale Kontrolle über dezentrale Pipelines: Der Endpunkt ist zentral erreichbar, die Ausführung erfolgt verteilt auf den i-flow Edges.
Lokale API Bereitstellung auf der Edge
Edge-Instanzen können ihre APIs auch direkt im lokalen Werksnetz bereitstellen. Diese APIs sind unabhängig vom Hub aufrufbar und garantieren maximale Nähe zum Shopfloor.
Vorteile:
- Offline-Fähigkeit: Bei Ausfall von Verbindungen bleibt die lokale API nutzbar, sodass essenzielle Prozesse auch im Inselbetrieb weiterlaufen.
- Integration lokaler Systeme: MES, SCADA oder HMIs können direkt angebunden werden, mit geringer Latenz und ohne komplexe Firewall-Regeln.
Hybrider Ansatz
Der hybride Ansatz kombiniert zentrale Orchestrierung mit lokaler Verfügbarkeit. Dabei sind dieselben API-Endpunkte sowohl über den Hub als auch direkt an der Edge aufrufbar. Für API-Consumer bedeutet das: Unabhängig davon, ob eine Anwendung aus der Cloud, aus einem zentralen Rechenzentrum oder direkt aus dem Werksnetzwerk zugreift – die Funktionalität bleibt konsistent verfügbar.
Zentrales API Management mit dem i-flow Hub
APIs in industriellen Szenarien erfordern mehr als nur die technische Bereitstellung von Endpunkten. Da APIs potenziell Einfluss auf physische Prozesse haben, sind Governance, Monitoring und Lifecycle Management essentiell. Der i-flow Hub übernimmt diese Rolle und stellt zentrale Funktionen bereit:
- API-Governance: Einheitliche Definitionen für Authentifizierung, Namenskonventionen und Versionierung stellen sicher, dass alle APIs nach konsistenten Standards betrieben werden.
- Monitoring: Jeder API-Aufruf wird geloggt – inklusive Erfolgs-, Fehlerstatus, Latenzen und Ausführungsort. Logs und Metriken ermöglichen es, Probleme zu erkennen und die Stabilität der APIs sicherzustellen. Zusätzlich werden übergebene Eingaben (Parameter, Payloads) gespeichert. Damit entsteht ein vollständiger Audit-Trail, der nicht nur regulatorische Anforderungen erfüllt, sondern auch Debugging und Replay von API-Aufrufen ermöglicht.
- Deployment & Lifecycle-Management: Neue oder aktualisierte API Pipelines können über den Hub auf Edges ausgerollt werden. Versionierung und Rollback-Mechanismen sichern dabei einen kontrollierten und reproduzierbaren Betrieb.
Anwendungsbeispiel industrieller APIs
Ein Produktionsplanungs-Tool berücksichtigt bei jeder Neuplanung aktuelle Informationen aus der Fertigung. Über eine Webhook-basierte Request/Response-API ruft das Tool bei Bedarf die entsprechende Pipeline im Unified Namespace (UNS) auf.
- Pipeline-Design: Die Pipeline aggregiert Maschinendaten aus dem UNS – z. B. aktuelle Anlagenzustände, Auslastungen und Materialverfügbarkeiten.
- Datenanreicherung: Parallel werden Kontextinformationen aus der Schichtplanung (Arbeitszeiten, Personalverfügbarkeit, Qualifikationen) eingebunden.
- Planungs-API: Das Ergebnis wird als strukturiertes JSON zurückgegeben, das alle relevanten Live-Daten mit Schichtkontext kombiniert.
Praxisnutzen:
- Das Planungstool erhält auf Knopfdruck ein vollständiges, konsolidiertes Bild der aktuellen Produktionssituation.
- Das Tool erstellt realistische Pläne – unter Berücksichtigung von verfügbaren Maschinen, Material und Personal.
- Über Parameter (z. B. Linie=Presswerk1 oder Zeitraum=Schicht2) lässt sich derselbe Endpunkt flexibel über Produktionsbereiche hinweg verwenden, ohne neue Schnittstellen zu entwickeln.
Praxisbeispiel
Entdecken Sie, wie Sto SE & Co. KGaA, ein weltweit führender Hersteller von Bauwerksbeschichtungen, i-flow Industrial APIs nutzt, um Systeme und Produktionen weltweit zu vernetzen. Durch die Implementierung des Unified Namespace (UNS) von i-flow als zentralen Data Hub ermöglicht Sto Interoperabilität in seiner komplexen IT/OT-Landschaft über das gesamte globale Partnernetzwerk hinweg. Lesen Sie die vollständige Success Story hier.
Fazit
Industrielle APIs im Unified Namespace (UNS) schließen die Lücke zwischen effizienter, eventbasierter Kommunikation in der OT und der Standardwelt von HTTP in der IT. Während klassische REST-APIs für transaktionsorientierte IT-Workloads geeignet sind, scheitern sie im Shopfloor an den Anforderungen von Latenz, Skalierbarkeit und Echtzeitfähigkeit. Webhook-basierte UNS-APIs bieten hier den entscheidenden Vorteil: Sie liefern Produktionsdaten kontextualisiert, sicher und on-demand – ohne Polling-Overhead und mit hoher Flexibilität durch Parametrisierung.
Für Architekten bedeutet das: Statt einer Vielzahl proprietärer Schnittstellen entsteht eine konsolidierte Zugriffsschicht auf Live-Daten, die sowohl zentrale IT-Systeme als auch lokale Shopfloor-Anwendungen bedient. Wer den UNS als Fundament nutzt und darauf eventbasierte APIs etabliert, schafft die Basis für durchgängige IT/OT-Integration und zukunftssichere Fabrikarchitekturen.
