Der Manufacturing Service Bus (MSB) taucht seit Jahren in Industrie-4.0-Konzepten, Forschungsprojekten und Referenzarchitekturen auf. Parallel dazu hat sich der Unified Namespace (UNS) als Architekturansatz für Echtzeitdaten in der Fertigung etabliert. Beide Konzepte verfolgen ein ähnliches Ziel: Sie verbinden Maschinen, IT-Systeme und Anwendungen über eine gemeinsame Integrationsschicht. Trotzdem unterscheiden sie sich deutlich in ihrem Ansatz. Daraus ergibt sich eine zentrale Frage: Ersetzt ein Unified Namespace den Manufacturing Service Bus, ergänzen sich beide Konzepte oder lösen sie unterschiedliche Probleme? Dieser Artikel erklärt den Manufacturing Service Bus, vergleicht ihn mit dem Unified Namespace und zeigt, welche MSB-Funktionen sich mit einem NATS-basierten UNS abbilden lassen. Außerdem betrachten wir eine mögliche Referenzarchitektur und den Weg von Plug-and-Play zu Plug-and-Produce im UNS.
Was ist ein Manufacturing Service Bus?
Das Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA) beschreibt den Manufacturing Service Bus als homogene, serviceorientierte Integrationsschicht für die Fabrik. Der MSB verbindet cyber-physische Produktionssysteme (CPPS) mit IT-Infrastruktur, Cloud-Plattformen und digitalen Services. Das Konzept folgt den Prinzipien der Service-Oriented Architecture (SOA) und stützt sich in der Fraunhofer-Referenz auf die Cloud-Plattform Virtual Fort Knox. Weitere Details liefert das Produktblatt des Fraunhofer IPA. Das Vorbild aus der klassischen IT ist der Enterprise Service Bus (ESB). Wie sich solche Middleware-Konzepte auf industrielle IT/OT-Architekturen übertragen lassen, erklärt unser Artikel zu Middleware im IIoT.
Nach dem Produktblatt umfasst der Manufacturing Service Bus drei zentrale Integrationsdienste:
- Routing Services: Sie überwachen Ereignisse und Statusänderungen. Tritt beispielsweise eine Störung auf, leiten sie die Information anhand definierter Regeln an den zuständigen Empfänger weiter.
- Data Transformation Services: Sie übersetzen Daten in ein gemeinsames Metadatenmodell. Dadurch können unterschiedliche digitale Werkzeuge dieselben Informationen verstehen und weiterverarbeiten.
- Orchestration Services: Sie koordinieren Prozessschritte über ein Workflow-Management-System. Grundlage dafür bilden zuvor definierte Prozessbeschreibungen.
Ein einfaches Beispiel zeigt das Zusammenspiel. Eine Maschine fällt aus. Der Routing Service erkennt die Statusänderung und informiert die zuständige Anwendung. Anschließend startet der Orchestration Service den hinterlegten Prozess zur Umplanung. Gleichzeitig bereitet ein Transformation Service die Daten so auf, dass das Planungssystem sie verarbeiten kann.
Vorteile eines MSB und Praxisstatus
Das Fraunhofer IPA nennt vor allem Flexibilität und eine einheitliche Integration als Vorteile des Manufacturing Service Bus. Produktionssysteme und digitale Werkzeuge müssen nicht mehr über zahlreiche individuelle Schnittstellen miteinander kommunizieren. Stattdessen verbindet eine gemeinsame Schicht unterschiedliche Technologien und Protokolle. Dadurch lassen sich ältere und neuere Systeme in einer Architektur kombinieren. Außerdem können Unternehmen Geschäftsprozesse leichter an neue Anforderungen anpassen. Der MSB abstrahiert die zugrunde liegenden Systeme und schafft eine gemeinsame Integrationslogik.
Allerdings sollte man den Praxisstatus berücksichtigen. Öffentlich dokumentiert sind vor allem Forschungsprojekte, Demonstratoren und Pilotanwendungen. Eine breite Seriennutzung des Manufacturing Service Bus in Fertigungsunternehmen ist bislang nicht vergleichbar mit etablierten Messaging- oder UNS-Architekturen dokumentiert.
Manufacturing Service Bus vs. Unified Namespace im Vergleich
Der Unified Namespace (UNS) verfolgt ebenfalls das Ziel, klassische Punkt-zu-Punkt-Schnittstellen zu reduzieren. Allerdings setzt er an einer anderen Stelle an. Ein UNS ergänzt bestehende IT/OT-Landschaften um eine gemeinsame, hierarchisch organisierte Datenebene.
Anwendungen und Systeme veröffentlichen ihre Daten in diesem gemeinsamen Namensraum oder abonnieren die Informationen, die sie benötigen. Dadurch müssen Daten nicht mehr über individuelle Schnittstellen zwischen einzelnen Anwendungen transportiert werden. Der UNS löst Daten aus ihren ursprünglichen Silos und stellt sie in einem gemeinsamen Kontext bereit. Die Grundlagen dazu erklärt unser Artikel Was ist der Unified Namespace (UNS)?.
Gemeinsamkeiten von MSB und UNS
Manufacturing Service Bus und Unified Namespace verfolgen ein ähnliches übergeordnetes Ziel: Beide reduzieren individuelle Verbindungen zwischen einzelnen Produktions- und IT-Systemen. Vier Gemeinsamkeiten fallen besonders auf:
| Gemeinsamkeit | Manufacturing Service Bus | Unified Namespace |
|---|---|---|
| Adressiertes Grundproblem | Unterschiedliche Schnittstellen, Datenformate und Protokolle erschweren die Integration von Produktion und IT | Daten liegen in isolierten Systemen und sind häufig nur über individuelle Schnittstellen erreichbar |
| Gemeinsame Vermittlungsschicht | Der Bus verbindet Systeme über eine homogene Integrationsschicht | Message Broker bilden eine gemeinsame Daten- und Kommunikationsschicht |
| Einheitliches Modell | Daten und Services werden über ein gemeinsames Metadatenmodell beschrieben | Daten werden in einer standardisierten Semantik in einem gemeinsamen, hierarchischen Namensraum eingeordnet |
| Offene Standards | Standards wie OPC UA und AutomationML können eingebunden werden | Standards wie OPC UA lassen sich ebenfalls integrieren |
Unterschiede zwischen MSB und UNS
Der zentrale Unterschied lässt sich einfach zusammenfassen: Der MSB ist serviceorientiert, der UNS ist datenorientiert. Beim Manufacturing Service Bus stehen Funktionen und Services im Mittelpunkt. Systeme rufen diese Services auf. Der Bus übernimmt dabei Integrationsaufgaben wie Routing, Transformation und Orchestrierung. Ein Unified Namespace stellt dagegen einen gemeinsamen Datenraum bereit. Systeme veröffentlichen dort Zustände und Ereignisse. Andere Anwendungen abonnieren diese Informationen und führen ihre Fachlogik selbst aus.
| Kriterium | MSB | UNS |
|---|---|---|
| Grundparadigma | serviceorientiert: Funktionen werden als Services aufgerufen | datenorientiert: Systeme veröffentlichen Zustände und Ereignisse |
| Ort der Logik | Routing, Transformation und Orchestrierung liegen im Bus | Die Fachlogik liegt überwiegend in den angebundenen Systemen |
| Kommunikationsmuster | vor allem Service-Aufrufe und Orchestrierung | Pub/Sub, mit NATS zusätzlich Request/Reply |
| Kopplung | Der Konsument kennt den Service und seine Schnittstelle | Publisher und Consumer bleiben über Subjects beziehungsweise den Namensraum lose gekoppelt |
| Datenmodell | Metadatenmodell und Service-Beschreibung | hierarchischer Namensraum, häufig entlang von ISA-95-Strukturen, ergänzt durch Schemas |
| Verteilung an viele Empfänger | typischerweise gezielter Service-Aufruf | Ein Publisher kann beliebig viele Consumer bedienen |
| Betriebsmodell | in der Fraunhofer-Referenz cloud-zentral über Virtual Fort Knox | verteilte und Edge-first-Architekturen sind möglich |
| Praxisstatus | vor allem Forschungs- und Pilotprojekte dokumentiert | in industriellen Datenarchitekturen zunehmend verbreitet |
Vier Unterschiede in der Praxis
Vier Unterschiede sind für die Praxis besonders relevant:
- Kopplung: Bei einem Service-Aufruf erwartet der Sender in der Regel eine Antwort vom angesprochenen Service. Klassisches Publish/Subscribe funktioniert anders. Der Publisher veröffentlicht Daten, ohne die Empfänger kennen zu müssen. Dadurch lassen sich Sender und Empfänger stärker voneinander entkoppeln. Wann synchrone oder asynchrone Kommunikation sinnvoll ist, erläutert unser Artikel Synchrone vs. asynchrone Kommunikation im UNS.
- Datenmodell: Der Manufacturing Service Bus beschreibt Services sowie die zugehörigen Metadaten. Ein Unified Namespace bildet dagegen die Struktur der Fabrik im Namensraum ab. Standort, Werk, Bereich, Linie, Maschine und Signal können direkt Teil des Datenpfads sein. Dadurch liefert bereits der Pfad einen Teil des fachlichen Kontexts.
- Ort der Logik: Im MSB übernimmt die zentrale Integrationsschicht Aufgaben wie Routing, Transformation und Orchestrierung. Beim UNS bleibt die Fachlogik dagegen überwiegend in den Endpunkten. Ein MES, APS oder anderes Planungssystem entscheidet beispielsweise, was mit einem Ereignis geschehen soll.
- Betriebsmodell: Die referenzierte MSB-Architektur setzt auf eine zentrale Cloud-Plattform. Ein UNS kann dagegen Edge-first aufgebaut werden. Jedes Werk verfügt dann über lokale Broker und Edge-Komponenten. Dadurch laufen wichtige Prozesse auch dann weiter, wenn die Verbindung zur zentralen Infrastruktur ausfällt. Gleichzeitig bleiben lokale Datenflüsse unabhängig von WAN-Latenzen.
Beide Konzepte schließen sich daher nicht aus. Ein NATS-basierter UNS kann die gemeinsame Daten- und Kommunikationsbasis bereitstellen. Serviceorientierte Funktionen und Orchestrierung lassen sich anschließend darauf aufbauen.
Kann ein NATS-basierter UNS als Manufacturing Service Bus dienen?
Ein Unified Namespace auf Basis von NATS unterstützt nicht nur Publish/Subscribe. NATS bietet zusätzlich Request/Reply und damit ein Kommunikationsmuster, das klassischen Service-Aufrufen ähnelt.
Welche MSB-Funktionen bietet NATS?
Damit stehen mehrere Grundbausteine zur Verfügung:
- Request/Reply: Antworten laufen über ein
_INBOX-Subject. NATS unterstützt dabei unter anderem Timeouts und ein No-Responders-Signal. Weitere Details liefert die NATS-Dokumentation. - Queue Groups: Mehrere Instanzen eines Service können dieselbe Anfragegruppe bedienen. NATS verteilt eingehende Anfragen auf diese Instanzen.
- Service API: Services lassen sich über
$SRV.PING,$SRV.INFOund$SRV.STATSentdecken und beobachten. Eine automatische Schema-Validierung erfolgt über i-flow. - JetStream: JetStream ergänzt NATS um Persistenz und Replay. Während Core NATS Nachrichten höchstens einmal zustellt, ermöglicht JetStream unter anderem At-least-once-Verarbeitung.
Hinweis: Auch MQTT 5 unterstützt ein Request/Response-Muster über Response Topic und Correlation Data. Allerdings benötigt die Anwendung dafür mehr eigene Logik. Die Unterschiede erläutert unser Vergleich NATS vs. MQTT.
So bildet i-flow die MSB-Dienste im UNS ab
Die drei zentralen Dienste eines Manufacturing Service Bus lassen sich in einer NATS-basierten i-flow-Architektur folgendermaßen abbilden:
| MSB-Dienst | Umsetzung im NATS-UNS mit i-flow |
|---|---|
| Routing Services (ereignis- und regelbasiert) | Lokale i-flow Broker übernehmen das Routing innerhalb eines Standorts. Standortübergreifend verbindet ein NATS Supercluster die Broker. Regelbasierte Ereignislogik kann als Workflow auf der i-flow Edge laufen. |
| Data Transformation Services (Metadatenmodell) | Die i-flow Edge harmonisiert Daten. Der i-flow Hub verwaltet Datenmodelle und Semantik zentral und verteilt sie an die Edge-Komponenten. Companion Specifications wie PackML (OPC 30050) oder CNC (OPC 40502-1) können als Grundlage dienen. |
| Orchestration Services (zentrales Workflow-Management-System) | Die Orchestrierung ist dezentraler aufgebaut als beim klassischen MSB. Der Hub verwaltet Design, Deployment, Versionierung und Rollback der Workflows. Die Edge führt diese Workflows lokal aus. |
Die Arbeitsteilung lässt sich einfach zusammenfassen: Der Hub verwaltet und verteilt. Die Edge verarbeitet und führt aus. Der lokale Broker routet innerhalb des Standorts. Das NATS Supercluster verbindet die Standorte. Damit übernimmt nicht eine zentrale Komponente alle Aufgaben des Manufacturing Service Bus. Stattdessen verteilt die Architektur diese Aufgaben auf mehrere spezialisierte und lokal betriebene Komponenten.
Referenzarchitektur mit lokalen Edges und globalem Supercluster
Eine solche Architektur trennt Control Plane und Data Plane. Die Control Plane bildet der i-flow Hub. Er verwaltet beispielsweise Datenmodelle, Workflows und Berechtigungen. Außerdem verteilt er Konfigurationen an Edge-Komponenten und Broker. Die Data Plane besteht aus den i-flow Edges und lokalen i-flow Brokern an den einzelnen Standorten. Sie verarbeitet die Produktionsdaten direkt vor Ort und bleibt auch dann funktionsfähig, wenn der Hub vorübergehend nicht erreichbar ist.
Jeder Standort bindet seine Anlagen über eine i-flow Edge an. Die Edge verbindet industrielle Protokolle, modelliert Daten und führt lokale Workflows aus. Anschließend verteilt der lokale i-flow Broker die Informationen an Consumer vor Ort, beispielsweise ein MES.
Ein NATS Supercluster verbindet die einzelnen Standorte und schafft dadurch einen global adressierbaren Namensraum. Wie sich eine solche Architektur vom ersten Pilotprojekt bis zu mehreren Werken entwickeln kann, zeigt unser Artikel zur Evolution des Unified Namespace. Globale Anwendungen wie ERP, Analytics-Plattformen oder KI-Agenten können relevante Daten über den Supercluster abonnieren.
Für Service-Aufrufe bietet sich dagegen eine andere Regel an: Befehle bleiben möglichst lokal, Ereignisse dürfen global fließen. Dadurch hängt die lokale Produktion nicht von WAN-Latenzen oder der Verbindung zwischen mehreren Standorten ab.
Von Plug-and-Play zu Plug-and-Produce
Damit ermöglicht die Referenzarchitektur den Weg von Plug-and-Play zu Plug-and-Produce. Ein Beispiel aus der Fertigung verdeutlicht den Unterschied:
- Eine neue CNC-Fräsmaschine wird an das Produktionsnetzwerk angeschlossen.
- OneClick UNS erkennt ihren OPC-UA-Server und schlägt auf Basis von OPC 40502-1 ein passendes Datenmodell vor.
- Nach einer Freigabe stehen die Maschinendaten im Unified Namespace bereit. Ein möglicher Datenpunkt lautet beispielsweise
berlin.werk01.machining.cnc05.spindle.speed. - Damit ist die Maschine auf der Datenebene eingebunden. Anwendungen können ihre Werte über einen einheitlichen Namensraum finden und nutzen. Das entspricht Plug-and-Play für industrielle Daten.
Plug-and-Produce geht einen Schritt weiter. Das Fortiss-Paper zum Manufacturing Service Bus beschreibt einen Ansatz, bei dem Anlagen ihre Fähigkeiten einheitlich bereitstellen. Aus diesen Fähigkeiten lassen sich ausführbare Fertigungsschritte ableiten. Diese stehen wiederum als Services zur Verfügung und können zur Laufzeit orchestriert werden. Eine neue Maschine liefert dann nicht nur Daten. Sie beschreibt zusätzlich, welche Fertigungsschritte sie ausführen kann. Ein Planungssystem könnte diese Fähigkeiten erkennen und geeignete Aufträge passenden Maschinen zuordnen.
Fähigkeitskatalog im UNS: Fähigkeiten beschreiben statt Logik zentralisieren
Ein Unified Namespace kann diese Idee mit einer anderen Aufgabenverteilung aufgreifen. Daten, Fähigkeiten und Befehle nutzen denselben Namensraum, liegen jedoch auf getrennten Subjects:
# Maschinendaten (Pub/Sub)
berlin.werk01.machining.cnc05.spindle.speed
# Fähigkeitskatalog (Subscribe oder Request)
berlin.werk01.machining.cnc05.capabilities
# Befehle (Request/Reply)
berlin.werk01.machining.cnc05.cmd.skill-nameDas Prinzip besteht aus drei Schritten:
- Fähigkeiten beschreiben: Die Edge liest verfügbare OPC-UA-Methoden und Schnittstellen der Maschine aus. Ein Modell im Hub ordnet diese Informationen definierten Maschinenfähigkeiten zu. Der daraus entstehende Katalog kann anschließend im UNS liegen, beispielsweise in einem JetStream-KV-Store oder als letzter bekannter Wert eines Subjects.
- Fähigkeiten zuordnen: Ein Planungssystem liest oder abonniert den Fähigkeitskatalog. Anschließend entscheidet es, welche Maschine einen bestimmten Fertigungsschritt übernehmen kann. Diese Rolle kann ein MES, ein APS (Advanced Planning and Scheduling) oder ein KI-Agent übernehmen. Kritische Entscheidungen können weiterhin eine menschliche Freigabe erfordern.
- Fähigkeiten ausführen: Das Planungssystem ruft die ausgewählte Fähigkeit per Request/Reply über ein Command-Subject auf. Die Edge übersetzt den Befehl in die passende OPC-UA-Methode. Status, Fortschritt und Ergebnis fließen anschließend als Events zurück in den UNS.
Der Unterschied zum Manufacturing Service Bus liegt vor allem in der Verteilung der Verantwortung. Beim klassischen MSB bündelt die gemeinsame Integrationsschicht einen großen Teil der Service- und Orchestrierungslogik. In einer UNS-Architektur entscheidet dagegen beispielsweise das Planungssystem, welche Maschine eine bestimmte Aufgabe übernimmt. Die gemeinsame Infrastruktur stellt Daten, Zustände und Kommunikationsmechanismen bereit.
Das ist kein fehlendes Feature des UNS, sondern eine Architekturentscheidung.
Fazit: MSB und UNS verfolgen unterschiedliche Architekturprinzipien
Der Manufacturing Service Bus und der Unified Namespace lösen ein ähnliches Integrationsproblem mit unterschiedlichen Paradigmen. Der MSB verbindet Systeme vor allem über Services. Routing, Transformation und Orchestrierung gehören dabei zur Integrationsschicht. Der UNS schafft dagegen einen gemeinsamen Datenraum. Systeme veröffentlichen Zustände und Ereignisse, während die Fachlogik überwiegend in den angebundenen Anwendungen bleibt. Mit NATS lässt sich dieses Modell erweitern. Neben Publish/Subscribe unterstützt NATS auch Request/Reply und damit direkte Service-Aufrufe. Drei zentrale Erkenntnisse:
- MSB und UNS folgen unterschiedlichen Paradigmen: Der Manufacturing Service Bus ist serviceorientiert. Der Unified Namespace ist datenorientiert. Beide reduzieren Punkt-zu-Punkt-Integrationen, setzen dafür jedoch unterschiedliche Architekturprinzipien ein.
- Ein NATS-basierter UNS kann MSB-Funktionen abbilden: Routing und Datentransformation lassen sich direkt in einer verteilten Architektur umsetzen. Die Orchestrierung verteilt sich auf zentrale Verwaltung und lokale Ausführung.
- Die Fachlogik bleibt näher an den Anwendungen: Systeme wie MES, APS oder andere Planungslösungen entscheiden selbst, wie sie Daten und Fähigkeiten nutzen. Gleichzeitig ermöglicht ein Edge-first-Ansatz einen robusten Betrieb an jedem Standort.
