Solace Unified Namespace: From a Single-Site UNS to a Multi-Site Event Mesh

A Solace unified namespace is a UNS carried on the Solace Event Broker or on a Solace event mesh. Solace lists Unified Namespace as a manufacturing use case, and its position is specific: keep the UNS for shared, real-time state, but do not stretch it to cover enterprise workflows. In an April 2026 blog, Solace’s Dan Prudhoe puts it as “Don’t abandon UNS, evolve it”. This page explains what that means in practice, how a single-site UNS differs from a multi-site one on a mesh, and how to design a namespace that survives crossing sites.

It sits under Solace in manufacturing in the Solace cluster.

The UNS in two sentences

A unified namespace is one structured, hierarchical, real-time data space, usually on an MQTT broker, where PLCs, SCADA, MES, ERP and historians publish and read current state instead of building point-to-point interfaces. Our UNS guide covers the pattern, the ISA-95 hierarchy and broker federation in full, and the MQTT guide covers the protocol under it.

How Solace frames the unified namespace

The definition. Solace’s UNS white paper defines it as “a real-time industrial data architecture that organizes operational events into a shared publish-subscribe structure”. That is close to the community definition.

The critique. The April 2026 blog says a UNS is good at “shared visibility and operational alignment” but that “visibility answers what is true now; behavior coordination answers what should happen next”. Its point is that an MQTT-based UNS has no model for “enterprise workflows that span multiple systems, retries, compensations, and downstream dependencies”, and that “delivery ≠ processing ≠ completion”.

What that means on a plant floor (illustrative). A line publishes state/running and every dashboard updates. Good. The same line finishes a batch and publishes a confirmation that SAP, the quality system and the warehouse must each process exactly once. If the ERP connector was restarting when the message arrived, a retained “last value” does not tell anyone that a confirmation was missed. That second flow wants a queue per consumer, acknowledgements and replay, which is what the guaranteed messaging model provides.

Single-site UNS versus a multi-site Solace unified namespace

Dimension	Single-site UNS	Multi-site UNS on a Solace mesh
Brokers	One (or one HA pair) in the plant	One per site, linked by dynamic message routing
What it shares	Current state for everyone in the plant	Selected state and events between sites and the enterprise
Delivery model	Mostly QoS 0 and QoS 1, last value retained	Queues and acknowledgements for flows that must complete
WAN dependency	None	Each link must buffer; sites must run alone
Governance	A naming convention and a spreadsheet	A catalogue of topics and schemas, for example Event Portal
Typical owner	The OT or controls team	Shared between OT (site end) and IT integration (mesh)

Designing a namespace that crosses sites

Solace topics are hierarchical, /-separated and case-sensitive, with up to 128 levels and 250 bytes per topic, according to the topic documentation. Native wildcards are * for one level and > for all trailing levels; MQTT clients use + and # as usual. The topics and wildcards page covers the mechanics. Four rules matter once the namespace spans sites:

1. Put the site near the top of the tree. acme/v1/plant-a/packaging/line-3/filler/state lets a subscription such as acme/v1/plant-a/> scope by site. The mesh propagates subscriptions, so a precise subscription keeps traffic off WAN links that do not need it.
2. Separate state from events in the topic itself. A state branch for current values and an event branch for things that happened (a batch completed, a hold placed) lets each be handled differently: last value for the first, queues for the second.
3. Version the namespace. A v1 level costs nothing and makes a later change survivable without breaking every subscriber.
4. Keep identifiers stable and meaningful. A topic that encodes a PLC tag address (plc7/N7_40) breaks when the controller is replaced. Model the asset, not the register.

Topic	Verdict	Why
acme/v1/plant-a/packaging/line-3/filler/state/speed	Good	Site, area, line and asset, then the kind of data
acme/v1/plant-a/packaging/line-3/event/batch-complete	Good	An event, ready to attract to a queue
line3/plc7/N7_40	Poor	Device address, no site, meaningless to IT
spBv1.0/Packaging/DDATA/edge-07/filler	Fine at the edge	Sparkplug identifies edge nodes, not ISA-95 levels; model it before it crosses sites

Sparkplug and the enterprise namespace are two different trees. Sparkplug fixes the topic as spBv1.0/group/message type/edge node/device, so it says which gateway published, not which line. Many plants keep Sparkplug for device state at the edge and publish a modelled, ISA-95-shaped tree for everyone else. The Solace Sparkplug page covers the Sparkplug side, and our guide to ISA-95 in practice covers the hierarchy itself.

State versus events on Solace

Current state. Most UNS designs rely on MQTT retained messages so a new subscriber gets the latest value at once. On Solace, retained messages are a Controlled Availability feature implemented through retain caches. The alternative native construct is a last value queue, which holds only the most recent message; the partitioned and last value queues page explains it. Decide which one you depend on before the design is fixed.

Events. Confirmations, quality holds and order changes should land on durable queues, one per consuming application, so a slow or offline consumer neither loses messages nor slows the others.

A worked example: adding the second plant (illustrative)

A food manufacturer runs a working UNS at its first plant on a plant broker, with SCADA, a historian and an OEE dashboard subscribed. It now acquires a second plant and wants one production report and one quality hold process across both. The sequence we would follow:

1. Leave plant one alone. Its UNS works; the plant keeps its broker and its local consumers.
2. Agree the enterprise tree first. Site, area, line and asset names, the state and event branches, and the version level, before anyone configures a broker at plant two.
3. Map, do not rename. Plant one’s existing topics are mapped into the enterprise tree at the boundary, so local screens keep working.
4. Choose what crosses. Line state at one-minute resolution, counts, alarms above a priority, batch and hold events. Not raw tags.
5. Give each enterprise consumer its own queue on the mesh, so the reporting database and the quality system fail independently.
6. Test the outage. Pull the WAN cable at plant two for an hour and confirm the hold events arrive afterwards, in order, once.

The result is two local namespaces and one enterprise namespace, which is what “evolve the UNS” looks like when it reaches a second site.

Where it gets hard

• Retained state is the feature the UNS leans on most, and it is Controlled Availability on Solace. Confirm support status for your version and edition in writing.
• Namespace governance does not scale by convention. Five sites with five naming habits produce five namespaces. Someone must own the tree, approve new branches and retire old ones.
• Two trees drift. If Sparkplug and the modelled namespace are published separately, they can disagree. Decide which one is authoritative for each consumer.
• Over-sharing. Forwarding every tag to the enterprise is the most common cost and performance mistake. List the topics that cross each boundary.
• Ownership at the seam. The site broker belongs to OT and the mesh to IT. Write down who is paged when a site link stops forwarding.

For the vendor-neutral broker choice behind all of this, see choosing a UNS broker. For the routing and buffering between plants, continue to multi-site edge to cloud. If you are designing the namespace now, our IT/OT integration work starts with the topic tree and who owns it.