Die Konvergenz von Information Technology (IT) und Operational Technology (OT) stellt Unternehmen vor eine fundamentale Herausforderung: Heterogene Systeme – von SPSen über SCADA bis zu ERP-Systemen – müssen nahtlos kommunizieren. Traditionell sprechen diese Systeme unterschiedliche „Sprachen“: Modbus, OPC UA, S7, REST, SQL. Middleware im IIoT bildet die Vermittlungsschicht, die diese Protokolle übersetzt, Datenflüsse routet und Transformationen orchestriert. Von Message Brokern über Edge-Gateways bis zu API-Gateways: Dieser Artikel erklärt, welche Middleware-Komponenten in modernen Industrial IoT-Architekturen zum Einsatz kommen, wie sie im Unified Namespace (UNS) positioniert werden und welche Architekturmuster sich in der Praxis bewährt haben.
Was ist Middleware im IIoT?
Der Begriff Middleware stammt aus der klassischen IT-Welt und bezeichnet Software, die zwischen Betriebssystem und Anwendungen vermittelt. Application Server, Enterprise Service Buses (ESB) und Message Queues sind typische Beispiele. Middleware im IIoT erweitert dieses Konzept um industriespezifische Anforderungen: Edge-Komponenten für protokollheterogene OT-Umgebungen, Echtzeit-Fähigkeit und Determinismus.
Definition und Abgrenzung
Middleware im IIoT ist Kommunikations-Infrastruktur, die Daten zwischen heterogenen Systemen transportiert, transformiert und routet. Sie ist keine Business-Logik, keine Datenbank und keine Applikation selbst – sondern die Schicht dazwischen.
Was Middleware ist:
- Kommunikations-Infrastruktur: Message Broker (NATS, MQTT), API-Gateways, ESBs
- Daten-Transformation: Protokoll-Konverter (OPC UA → JSON), Einheitenkonvertierung, Schema-Mapping
- Routing und Orchestrierung: Topic-basierte Nachrichtenvermittlung, Workflow-Engines
Was Middleware nicht ist:
- Business-Logik (z.B. Produktionsplanung, Qualitätsalgorithmen)
- Persistenz-Schicht (Time-Series-Datenbanken, Historiker)
- End-User-Applikationen (Dashboards, MES, ERP)
Warum Middleware im IIoT unverzichtbar ist
Vier industriespezifische Herausforderungen machen Middleware im IIoT zum Fundament moderner Architekturen:
- Heterogenität: Über 200 industrielle Protokolle existieren parallel – OPC UA, Modbus TCP, Modbus RTU, Profinet, EtherCAT, BACnet, S7, CIP. Jede SPS-Generation bringt neue Varianten. Middleware abstrahiert diese Vielfalt.
- Skalierung: Ein modernes Werk generiert Daten von tausenden Sensoren, hunderten Maschinen und dutzenden IT-Systemen. Ohne zentrale Middleware-Schicht entstehen n*(n-1) Punkt-zu-Punkt-Verbindungen. Beispiel: Bei 50 Systemen entstehen ohne Middleware n × (n − 1) = 50 × 49 = 2.450 direkte Punkt-zu-Punkt-Verbindungen – eine Architektur-Katastrophe.
- Real-Time vs. Batch: OT-Systeme erfordern deterministische Latenz (< 100 ms), IT-Systeme verarbeiten Batch-Daten (minütlich, stündlich). Middleware entkoppelt diese unterschiedlichen Zeitdomänen.
- IT/OT-Kluft: OT-Ingenieure sprechen Ladder Logic und Feldbus, IT-Entwickler sprechen REST und SQL. Middleware übersetzt nicht nur Protokolle, sondern auch Denkweisen.
Middleware-Typen im IIoT
Middleware im IIoT ist kein monolithischer Block, sondern ein Spektrum spezialisierter Komponenten. Jede erfüllt spezifische Funktionen im Datenfluss von der SPS bis zum ERP-System.
1. Message Broker (NATS/MQTT)
Message Broker sind die zentrale Drehscheibe für asynchrone, Publish/Subscribe-basierte Nachrichtenvermittlung.
Funktion: Produzenten publizieren Nachrichten auf Topics, Konsumenten abonnieren Topics. Der Broker entkoppelt Sender und Empfänger – sie müssen sich nicht kennen, nicht gleichzeitig online sein.
Beispiele:
NATS– Cloud-Native Message Broker mit JetStream-Persistenz, optimiert für hohen DurchsatzMQTT (Eclipse Mosquitto)– Lightweight-Protokoll für Edge-Deployments, QoS-Levels, Retained MessagesApache Kafka– High-Throughput-Streaming-Plattform für Big-Data-Pipelines
Use Case: NATS und MQTT bilden das Herzstück des Unified Namespace (UNS) – alle Daten fließen über den Broker. Kafka eignet sich für Streaming-Analytics mit extremen Durchsatzanforderungen.
Eigenschaften: Asynchron, lose gekoppelt, skalierbar (Cluster), Topic-basierte Zugriffskontrolle (ACLs).
2. Protokoll-Konverter / Edge-Gateways
Edge-Gateways übersetzen proprietäre OT-Protokolle in standardisierte Formate für die IT-Welt.
Funktion: Lesen von SPSen (OPC UA, Modbus, S7), Transformieren in JSON/Protobuf, Publizieren via NATS oder MQTT ins UNS.
Beispiele:
i-flow Edge– Edge-Gateway mit Multi-Protokoll-Support, Data Harmonization, Container-basiertKepware– Industrieller Connectivity-ServerIgnition Edge– SCADA-Gateway mit Edge-Historian
Use Case: Anbindung von Legacy-SPSen (Siemens S7-300, Allen-Bradley ControlLogix) an den UNS. Edge-Gateways laufen typischerweise auf Industrie-PCs direkt am Shopfloor.
Eigenschaften: Edge-deployed, niedrige Latenz (< 50 ms), Protokoll-Expertise erforderlich, häufig mit lokaler Pufferung bei Netzwerkausfall.
3. Data Harmonization Layer
Data Harmonization normalisiert, kontextualisiert und reichert Rohdaten an, bevor sie ins UNS fließen.
Funktion: Einheitenkonvertierung (°F → °C), ISA-95-Kontextualisierung (Machine ID → Enterprise/Site/Area/Line/Cell), Zeitstempel-Normalisierung (UTC), Schema-Validierung.
Beispiele:
i-flow Edge– Integrierte Data-Harmonization-Engine, global skalierbar über i-flow HubNode-RED Flows– Lokale Flow-basierte Transformation Pipelines
Use Case: Eine Siemens-SPS liefert Temperatur in 0.1°C-Schritten als INT16, eine Rockwell-SPS in °F als REAL. Data Harmonization normalisiert beide auf {"temperature": {"value": 87.3, "unit": "celsius"}}.
Eigenschaften: Zustandslos (Stateless Transformation), idempotent, fehlertolerante Pipelines.
Middleware Architektur im Unified Namespace (UNS)
Der Unified Namespace (UNS) ist keine einzelne Komponente, sondern eine Architektur – und diese Architektur ist selbst Middleware. Das UNS-Konzept zentralisiert alle Produktionsdaten in einer NATS- oder MQTT-basierten Publish/Subscribe-Struktur. Alle OT- und IT-Systeme agieren als Produzenten oder Konsumenten. Das Ergebnis: keine Punkt-zu-Punkt-Verbindungen mehr, sondern eine sternförmige Architektur mit dem Message Broker als Zentrum. Dabei ist der UNS kein flacher Daten-Bus, sondern ein Schichtenmodell. Jede Schicht erfüllt spezifische Middleware-Funktionen:
Schicht-für-Schicht-Erklärung:
- OT Layer: SPSen, Sensoren, Antriebe – die Datenquelle. Sprechen proprietäre Protokolle.
- Protocol Converters (Edge Gateways): Erste Middleware-Schicht. Übersetzt OPC UA, Modbus, S7 → NATS/JSON oder MQTT/JSON.
- Data Harmonization Layer: Zweite Middleware-Schicht. Normalisiert Einheiten, fügt ISA-95-Kontext hinzu, validiert Schemas.
- Message Broker (NATS/MQTT): Dritte Middleware-Schicht, das Herzstück. Single Source of Truth (SSOT) für alle Echtzeitdaten.
- IT Layer: MES, ERP, Analytics – die Konsumenten. Nutzen Daten für Business-Logik, Reporting, KI-Modelle.
Evolutionsstufen im Unified Namespace (UNS)
Der Unified Namespace entwickelt sich typischerweise in vier Evolutionsstufen – von einem einfachen Single-Broker-Setup bis zu einem global föderierten Supercluster. Die Wahl der richtigen Stufe hängt von Skalierung, Verfügbarkeitsanforderungen, Anzahl der Standorte und WAN-Verfügbarkeit ab.
Stufe 1: Single-Broker (Local UNS)
Struktur: Alle Edge-Gateways verbinden sich mit einem einzelnen Message Broker (NATS oder MQTT) im Werk. Der Broker läuft typischerweise auf einer VM, einem Edge-Server oder einem Industrie-PC.
Charakteristik:
- Einfaches Setup: Ein Broker, keine Cluster-Konfiguration
- Keine Redundanz: Single Point of Failure
- Ein Standort: Alle Daten bleiben lokal im Werk
- Kein Clustering: Broker läuft als Single-Instance
- Standort-Autonomie: Werk ist unabhängig von WAN-Verbindung
- Architekturkomplexität: einfach
Use Case: Einstieg in UNS-Architektur, Pilotprojekt mit <50 Maschinen, dedizierte Shopfloor-Netzwerk-Infrastruktur, keine HA-Anforderungen.
Evolutionstreiber: Sobald High Availability (HA) erforderlich wird oder der Broker an Performance-Grenzen stößt (>200.000 Messages/sec), ist ein Cluster-Setup notwendig.
Stufe 2: Local Broker Cluster (High-Availability UNS)
Struktur: Alle Edge-Gateways verbinden sich mit einem lokalen NATS-Cluster (3+ Nodes für High Availability) im Werk. Der Cluster ist als Full Mesh konfiguriert – jeder NATS-Server verbindet sich mit jedem anderen im Cluster.
Charakteristik:
- High Availability: Cluster statt Single Node – kein Single Point of Failure
- Horizontale Skalierung: Performance-Steigerung durch Hinzufügen weiterer Nodes
- Standort-Autonomie: Werk ist weiterhin unabhängig von WAN
- Architekturkomplexität: mittel
Use Case: Produktives UNS-Deployment mit Rollout auf >50 Maschinen, HA-Anforderungen, Produktionsstopp bei Broker-Ausfall inakzeptabel.
Evolutionstreiber: Rollout in weitere Werke oder geografische Standorte erfordert Multi-Site-Architektur.
Stufe 3: Distributed Multi-Cluster (Multi-Site UNS)
Struktur: Jeder Standort (z.B. Werk Berlin, Werk Shanghai, Werk Chicago) betreibt ein eigenständiges lokales NATS-Cluster (3+ Nodes). Die Cluster sind nicht miteinander verbunden – jeder Standort operiert vollständig autark mit eigenem Namespace.
Charakteristik:
- Standort-Autonomie: Jedes Werk funktioniert vollständig autark bei WAN-Ausfall
- Reduzierte Latenz: Lokale Pub/Sub-Kommunikation ohne Round-Trip zu externem Standort (<5 ms)
- Isolierte Namespaces: Jeder Standort hat eigene ISA-95-Hierarchie (z.B.
werk01.line01.robot01), zentrale Namespace Governance über i-flow Hub - Keine Standort-übergreifende Kommunikation: Cluster sehen sich gegenseitig nicht
- Architekturkomplexität: mittel
Use Case: Erste Rollouts in Multi-Site-Produktionsnetzwerke mit <5 Standorten, jedes Werk operiert unabhängig, keine globale Datensicht erforderlich.
Evolutionstreiber: Sobald IT-Analytics globale Datensicht benötigt (z.B. Produktionsvergleich zwischen Werken, globale OEE-Dashboards, Multi-Site-ML-Modelle), ist eine Föderation der Cluster über ein NATS Supercluster notwendig.
Stufe 4: NATS Supercluster (Global UNS)
Struktur: Ein NATS Supercluster föderiert mehrere regionale NATS-Cluster zu einem global adressierbaren Namespace. Jeder Standort (z.B. Werk Berlin, Werk Shanghai, Werk Chicago) betreibt weiterhin sein lokales 3-Node-NATS-Cluster, aber diese Cluster sind via gateway-Verbindungen vernetzt.
Funktionsweise:
- Lokale Pub/Sub: Nachrichten innerhalb eines Clusters bleiben lokal (z.B.
berlin.werk01.line01.robot01.temperaturebleibt in Berlin-Cluster) - Subject Interest Propagation: Wenn ein Subscriber in Shanghai
berlin.werk01.>abonniert, propagiert NATS dieses Interest über Gateway-Verbindung nach Berlin - On-Demand-Routing: Nur Nachrichten mit aktiven Remote-Subscribern werden über Gateways geroutet (spart WAN-Bandbreite)
- Global adressierbarer Namespace: Alle Cluster teilen sich einen gemeinsamen Topic-Namespace – IT-Systeme können Daten aller Standorte abonnieren
Charakteristik:
- Standort-Autonomie: Jedes Werk funktioniert autark bei WAN-Ausfall (lokale Pub/Sub unbeeinträchtigt)
- Latenz-optimiert für Edge: Shopfloor-Kommunikation bleibt lokal (<5 ms)
- Globale Skalierbarkeit: Neue Standorte fügen eigenen Cluster hinzu, keine zentrale Last
- Bandbreiten-Effizienz: Subject-Interest-basiertes Routing – nur benötigte Daten über WAN
- Global föderierter Namespace: ISA-95-Hierarchie ist global eindeutig (
berlin.werk01,shanghai.werk02) - Architekturkomplexität: hoch
Use Case: Globales Multi-Site-Produktionsnetzwerk (>5 Standorte), IT-Analytics benötigt globale Datensicht (Multi-Site-OEE-Dashboards, Produktionsvergleich zwischen Werken), WAN-Ausfälle möglich aber selten, Hybrid-Cloud-Strategie (Shopfloor-Echtzeit lokal, IT-Analytics global).
Zusammenfassung
| Stufe | Architektur | Struktur | Autonomie & Latenz | Skalierung & HA | Typischer Use Case | Komplexität |
|---|---|---|---|---|---|---|
| 1 | Single-Broker (Local UNS) | Ein einzelner Broker im Werk (VM/Edge-PC), kein Clustering | Vollständig lokal, WAN-unabhängig | Keine HA, Single Point of Failure, begrenzte Performance | Pilotprojekt, <50 Maschinen, keine HA-Anforderung | Einfach |
| 2 | Local Broker Cluster (HA UNS) | Lokales Cluster (3+ Nodes), Full-Mesh im Werk | Lokal, WAN-unabhängig | High Availability, horizontale Skalierung im Werk | Produktiver Rollout >50 Maschinen, Ausfall nicht tolerierbar | Mittel |
| 3 | Distributed Multi-Cluster (Multi-Site UNS) | Mehrere Werke, jeweils eigenes lokales Cluster, nicht miteinander verbunden | Autark pro Standort, <5 ms lokal | HA je Werk, keine globale Datensicht | Multi-Site (<5 Standorte), Werke operieren unabhängig | Mittel |
| 4 | NATS Supercluster (Global UNS) | Mehrere lokale Cluster via Gateways föderiert, global adressierbarer Namespace | Autark bei WAN-Ausfall, lokale Echtzeit bleibt lokal, globale Subscriptions möglich | Globale Skalierbarkeit, kein zentrales Bottleneck, WAN-effizientes Routing (Interest-basiert) | Globales Produktionsnetzwerk (>5 Standorte), globale Analytics & OEE | Hoch |
Fazit
Middleware im IIoT ist mehr als ein Message Broker – es ist ein Schichtenmodell, das heterogene OT- und IT-Systeme nahtlos verbindet. Jede Schicht erfüllt dabei spezifische Funktionen. Der Unified Namespace (UNS) selbst ist eine Middleware-Architektur, in der NATS und / oder MQTT als zentrale Drehscheibe fungieren. Drei zentrale Erkenntnisse:
- UNS ist Middleware-Architektur: Das Unified Namespace ist keine Applikation, sondern ein Schichtenmodell von Middleware-Komponenten.
- Spezialisierte Middleware für spezialisierte Anforderungen: Message Broker für Pub/Sub und Gateways für Protokoll-Konvertierung
- Lose Kopplung und Skalierbarkeit sind Schlüsselprinzipien: Middleware entkoppelt Produzenten und Konsumenten. Pub/Sub-Pattern ermöglichen horizontale Skalierung ohne Architektur-Redesign.
