The Manufacturing Service Bus (MSB) has appeared in Industry 4.0 concepts, research projects and reference architectures for years. In parallel, the Unified Namespace (UNS) has become an established architecture approach for real-time data in manufacturing. Both concepts pursue a similar goal: they connect machines, IT systems and applications through a shared integration layer. Yet their approaches differ significantly. This raises a key question: does a Unified Namespace replace the Manufacturing Service Bus, do the two complement each other, or do they solve different problems? This article explains the Manufacturing Service Bus, compares it with the Unified Namespace and shows which MSB functions a NATS-based UNS can cover. It also looks at a possible reference architecture and at the path from plug-and-play to plug-and-produce in the UNS.
What Is a Manufacturing Service Bus?
The Fraunhofer Institute for Manufacturing Engineering and Automation (IPA) describes the Manufacturing Service Bus as a homogeneous, service-based integration layer for the factory. The MSB connects cyber-physical production systems (CPPS) with IT infrastructure, cloud platforms and digital services. The concept follows the principles of service-oriented architecture (SOA). In the Fraunhofer reference, it builds on the Virtual Fort Knox cloud platform. The Fraunhofer IPA product sheet provides further details. The model from classic IT is the Enterprise Service Bus (ESB). Our article on middleware in the IIoT explains how such middleware concepts translate to industrial IT/OT architectures.
According to the product sheet, the MSB comprises three core integration services:
- Routing Services: They monitor events and status changes. If a fault occurs, for example, they forward the information to the responsible recipient based on defined rules.
- Data Transformation Services: They translate data into a shared metadata model. As a result, different digital tools can understand and process the same information.
- Orchestration Services: They coordinate process steps through a workflow management system. Previously defined process descriptions form the basis.
A simple example shows how the services work together. A machine fails. The routing service detects the status change and informs the responsible application. The orchestration service then starts the stored rescheduling process. At the same time, a transformation service prepares the data so that the planning system can process it.
Benefits of an MSB and Its Status in Practice
Fraunhofer IPA names flexibility and uniform integration as the main benefits of the Manufacturing Service Bus. Production systems and digital tools no longer have to communicate through numerous individual interfaces. Instead, a shared layer connects different technologies and protocols. This allows older and newer systems to coexist in one architecture. Companies can also adapt business processes to new requirements more easily. The MSB abstracts the underlying systems and creates a common integration logic.
However, the status in practice matters. Publicly documented use is mostly limited to research projects, demonstrators and pilot applications. Broad series use of the MSB in manufacturing companies is so far not documented at a level comparable to established messaging or UNS architectures.
Manufacturing Service Bus vs. Unified Namespace: A Comparison
The Unified Namespace (UNS) also aims to reduce classic point-to-point interfaces. However, it starts at a different point. A UNS extends existing IT/OT landscapes with a shared, hierarchically organized data layer.Applications and systems publish their data to this shared namespace or subscribe to the information they need. As a result, data no longer has to travel through individual interfaces between single applications. The UNS frees data from its original silos and provides it in a shared context. Our article What Is the Unified Namespace (UNS)? explains the basics.
Similarities Between MSB and UNS
MSB and UNS share a similar overarching goal: both reduce individual connections between production and IT systems. Four similarities stand out:
| Similarity | MSB | UNS |
|---|---|---|
| Underlying problem addressed | Different interfaces, data formats and protocols make it hard to integrate production and IT | Data sits in isolated systems and is often reachable only through individual interfaces |
| Shared mediation layer | The bus connects systems through a homogeneous integration layer | Message brokers form a shared data and communication layer |
| Unified model | Data and services are described through a shared metadata model | Data is placed in a shared, hierarchical namespace using standardized semantics |
| Open standards | Standards such as OPC UA and AutomationML can be integrated | Standards such as OPC UA can be integrated as well |
Differences Between MSB and UNS
The core difference is easy to summarize: the MSB is service-oriented, the UNS is data-oriented. In an MSB, functions and services take center stage. Systems call these services. The bus handles integration tasks such as routing, transformation and orchestration. A Unified Namespace, in contrast, provides a shared data space. Systems publish states and events there. Other applications subscribe to this information and run their own business logic.
| Criterion | MSB | UNS |
|---|---|---|
| Core paradigm | Service-oriented: functions are called as services | Data-oriented: systems publish states and events |
| Location of logic | Routing, transformation and orchestration sit in the bus | Business logic sits mostly in the connected systems |
| Communication pattern | Mainly service calls and orchestration | Pub/Sub, plus request/reply with NATS |
| Coupling | The consumer knows the service and its interface | Publishers and consumers stay loosely coupled through subjects and the namespace |
| Data model | Metadata model and service description | Hierarchical namespace, often along ISA-95 structures, complemented by schemas |
| Distribution to many recipients | Typically a targeted service call | One publisher can serve any number of consumers |
| Operating model | Cloud-centric via Virtual Fort Knox in the Fraunhofer reference | Distributed and edge-first architectures are possible |
| Status in practice | Mainly research and pilot projects documented | Increasingly common in industrial data architectures |
Four Differences that Matter in Practice
Four differences matter most in practice:
- Coupling: In a service call, the sender usually expects a reply from the service it addressed. Classic publish/subscribe works differently. The publisher publishes data without needing to know the recipients. This decouples senders and receivers more strongly. Our article Synchronous vs. Asynchronous Communication in the UNS explains when each style makes sense.
- Data model: The MSB describes services and their metadata. A Unified Namespace, in contrast, maps the structure of the factory into the namespace. Site, plant, area, line, machine and signal can be part of the data path. The path itself therefore carries part of the business context.
- Location of logic: In the MSB, the central integration layer handles tasks such as routing, transformation and orchestration. In the UNS, business logic stays mostly in the endpoints. An MES, an APS or another planning system decides, for example, what happens with an event.
- Operating model: The referenced MSB architecture relies on a central cloud platform. A UNS, in contrast, can be built edge-first. Each plant then has local brokers and edge components. Important processes keep running even if the connection to central infrastructure fails. Local data flows also stay independent of WAN latency.
The two concepts therefore do not exclude each other. A NATS-based UNS can provide the shared data and communication foundation. Service-oriented functions and orchestration can then build on top of it.
Can a NATS-Based UNS Serve as a Manufacturing Service Bus?
A Unified Namespace built on NATS supports more than publish/subscribe. NATS also offers request/reply, a communication pattern that resembles classic service calls.
Which MSB Functions Does NATS Offer?
This gives you several building blocks:
- Request/Reply: Replies travel through an
_INBOXsubject. NATS supports timeouts and a no-responders signal, among other features. The NATS documentation provides further details. - Queue Groups: Several instances of a service can serve the same request group. NATS distributes incoming requests across these instances.
- Service API: You can discover and monitor services through
$SRV.PING,$SRV.INFOand$SRV.STATS. i-flow handles automatic schema validation. - JetStream: JetStream adds persistence and replay to NATS. Core NATS delivers messages at most once, while JetStream enables at-least-once delivery, among other options.
Note: MQTT 5 also supports a request/response pattern through response topic and correlation data. However, the application needs more custom logic for it. Our comparison NATS vs. MQTT explains the differences.
How i-flow maps the MSB Services in the UNS
In a NATS-based i-flow architecture, the three core services of a Manufacturing Service Bus map as follows:
| MSB service | Implementation in the NATS-based UNS with i-flow |
|---|---|
| Routing Services (event- and rule-based) | Local i-flow Brokers handle routing within a site. A NATS Supercluster connects the brokers across sites. Rule-based event logic can run as a workflow on the i-flow Edge. |
| Data Transformation Services (metadata model) | The i-flow Edge harmonizes data. The i-flow Hub manages data models and semantics centrally and distributes them to the edge components. Companion specifications such as PackML (OPC 30050) or CNC (OPC 40502-1) can serve as a foundation. |
| Orchestration Services (central workflow management system) | Orchestration is more decentralized than in the classic MSB. The Hub manages design, deployment, versioning and rollback of the workflows. The Edge runs these workflows locally. |
The division of labor is easy to summarize: the Hub manages and distributes. The Edge processes and executes. The local broker routes within the site. The NATS Supercluster connects the sites. So no single central component takes over all tasks of the Manufacturing Service Bus. Instead, the architecture distributes these tasks across several specialized, locally operated components.
Reference Architecture with Local Edges and a Global Supercluster
Such an architecture separates the control plane from the data plane. The i-flow Hub forms the control plane. It manages data models, workflows and permissions, for example. It also distributes configurations to edge components and brokers. The data plane consists of the i-flow Edges and local i-flow Brokers at the individual sites. It processes production data on site and stays functional even if the Hub is temporarily unreachable.
Each site connects its equipment through an i-flow Edge. The Edge connects industrial protocols, models data and runs local workflows. The local i-flow Broker then distributes the information to on-site consumers, such as an MES.
A NATS Supercluster connects the individual sites and creates a globally addressable namespace. Our article on the evolution of the Unified Namespace shows how such an architecture can grow from a first pilot to many plants. Global applications such as ERP, analytics platforms or AI agents can subscribe to relevant data through the Supercluster.
For service calls, a different rule applies: keep commands local where possible and let events flow globally. This way, local production does not depend on WAN latency or on the connection between several sites.
From Plug-and-Play to Plug-and-Produce
This reference architecture enables the path from plug-and-play to plug-and-produce. An example from the shop floor shows the difference:
- A new CNC milling machine joins the production network.
- OneClick UNS detects its OPC UA server and proposes a suitable data model based on OPC 40502-1.
- Once approved, the machine data becomes available in the Unified Namespace. One possible data point is
berlin.werk01.machining.cnc05.spindle.speed. - The machine is now integrated at the data level. Applications can find and use its values through a uniform namespace. This corresponds to plug-and-play for industrial data.
Plug-and-produce goes one step further. The Fortiss paper on the Manufacturing Service Bus describes an approach in which equipment provides its capabilities in a uniform way. Executable manufacturing steps can be derived from these capabilities. These steps become available as services and can be orchestrated at runtime. A new machine then delivers more than data. It also describes which manufacturing steps it can perform. A planning system could recognize these capabilities and assign suitable orders to matching machines.
Capability Catalog in the UNS: Describing Capabilities Instead of Centralizing Logic
A Unified Namespace can pick up this idea with a different division of tasks. Data, capabilities and commands share the same namespace but sit on separate subjects:
# Machine data (Pub/Sub)
berlin.werk01.machining.cnc05.spindle.speed
# Capability catalog (subscribe or request)
berlin.werk01.machining.cnc05.capabilities
# Commands (Request/Reply)
berlin.werk01.machining.cnc05.cmd.skill-nameThe principle has three steps:
- Describe capabilities: The Edge reads the available OPC UA methods and interfaces of the machine. A model in the Hub maps this information to defined machine capabilities. The resulting catalog can then live in the UNS, for example in a JetStream KV store or as the last known value of a subject.
- Assign capabilities: A planning system reads or subscribes to the capability catalog. It then decides which machine can take over a given manufacturing step. An MES, an APS (Advanced Planning and Scheduling) or an AI agent can fill this role. Critical decisions can still require human approval.
- Execute capabilities: The planning system calls the selected capability through request/reply on a command subject. The Edge translates the command into the matching OPC UA method. Status, progress and results then flow back into the UNS as events.
The difference from the MSB lies mainly in how responsibility is distributed. In the classic MSB, the shared integration layer bundles a large part of the service and orchestration logic. In a UNS architecture, the planning system, for example, decides which machine takes on a task. The shared infrastructure provides data, states and communication mechanisms.
This is not a missing UNS feature but an architectural decision.
Conclusion: MSB and UNS Follow Different Architecture Principles
The Manufacturing Service Bus and the Unified Namespace solve a similar integration problem with different paradigms. The MSB connects systems mainly through services. Routing, transformation and orchestration belong to the integration layer. The UNS, in contrast, creates a shared data space. Systems publish states and events, while business logic stays mostly in the connected applications. NATS extends this model. Besides publish/subscribe, NATS also supports request/reply and therefore direct service calls. Three key takeaways:
- MSB and UNS follow different paradigms: The MSB is service-oriented. The Unified Namespace is data-oriented. Both reduce point-to-point integrations, but they apply different architecture principles.
- A NATS-based UNS can cover MSB functions: Routing and data transformation can be implemented directly in a distributed architecture. Orchestration splits into central management and local execution.
- Business logic stays closer to the applications: Systems such as an MES, an APS or other planning solutions decide for themselves how to use data and capabilities. An edge-first approach also keeps operations robust at every site.
