Connecting to a Unified Namespace: Publishing and Consuming Shop-Floor Data

From PLCs and legacy equipment on the operational technology (OT) side and from databases and SAP on the IT side, in other words from systems that do not necessarily speak MQTT themselves. So the first step is an inventory: which source can be reached by which route?

Which tool builds these routes depends on what the namespace runs on. If it stands on its own, on a broker you run yourself for example, that tool is the OPC Router as standalone middleware on site; the table lists its routes. If the Unified Namespace runs on the pronubes platform, pronubes Edge takes on the job. There it is the connection layer between the local systems and the platform, with instances at the sites. Which of the two fits depends on the role. The table and the sections that follow describe the OPC Router as documented in its manual.

The consumers read from the broker: an MES, a SCADA system, dashboards, and from the same product family manubes for transparency and production management from the cloud and pronubes for analyzing the data and automating processes. Both subscribe to topics on the broker.

Middleware cannot help with machines that have no interface at all. Those need retrofit sensors.

In practice: According to the international use cases on opc-router.com (page dated August 2026), a manufacturer of forged parts collects information from an OPC server and publishes it via MQTT. The benefit the entry names is that the process data is “now easily accessible to other systems”. A manufacturer of sticky notes uses the same route to forward production data to its MES and SCADA system, where it is also analyzed with AI. Neither entry mentions a Unified Namespace. Both show the pattern a namespace rests on: publish once, read many times.

Through a flow in the OPC Router: a trigger starts it, and the MQTT transfer object publishes the value to the broker. For PLC values, the trigger is usually the OPC Client's data change trigger. It fires when a value changes, so what gets sent is what has changed. "Output Metadata" adds the timestamp and quality.

The MQTT transfer object is part of the OPC Router's MQTT plug-in. That is where the topic is set, which is the value's name in the namespace, together with the quality of service and whether the broker should retain the message. Three settings carry most of the UNS logic:

• Retain tells the broker to store the message as the last known one for that topic. A new subscriber receives it straight away. This is the mechanism behind the claim that a namespace "holds the current state". It does not replace a long-term history, which typically lives in a historian, a time-series database or a data lake.
• Dynamic topic builds the name at runtime from an input value, so a single flow can serve many machines.
• Quality of service costs throughput. In a series of measurements by the vendor, QoS 1 was about 11 % slower than QoS 0, and QoS 2 about 37 % slower. The conditions matter: an earlier version of the OPC Router, 100 parallel transfer flows without a connection pool, a local broker, Windows Sandbox with 4 GB and a payload of 100 bytes. The manual states explicitly that the figures show the ratio between the variants, not a performance limit. Its recommendation: QoS 0 for cyclic telemetry, QoS 1 as the default, and QoS 2 only where a duplicate must be ruled out for business reasons. QoS 2 provides exactly-once delivery between broker and router; it does not protect against duplicates caused by overlapping subscriptions.

MQTT 5 allows user properties to travel with a message, such as a schema version. The manual adds that business data belongs in the payload or in the topic structure, not in these extra fields. For the payload itself, the JSON Schema plug-in validates incoming data and generates outgoing data from a schema, optionally pinned to a fixed schema version.

What a published value can look like is shown here by an example of one possible configuration. The flow puts the value and the details from "Output Metadata" into a JSON document and publishes it on the topic for that measurement, here plant-north/hall-2/line-3/filler/temperature:

Field names and structure are set in the configuration. The MQTT transfer object sends the content as a string or a byte array and does not prescribe a format.

What about Sparkplug B? Sparkplug B gives MQTT messages a fixed structure for state, metrics and heartbeats. In return, it prescribes the path: spBv1.0////. A free path that mirrors the equipment hierarchy from ISA-95, such as Enterprise / Site / Area / Line / Cell, and Sparkplug B are therefore mutually exclusive. Combining the two requires a mapping rule that says which level becomes the Group ID, which becomes the node and which goes into the metric name. The OPC Router's Sparkplug plug-in publishes in the "Node" profile, where it sets Group ID and Node ID as defaults that each transfer object can override. Its second profile, "Application", belongs to the return path.

Through a flow that starts at the broker. The OPC Router's MQTT trigger, "MQTT Subscribe", subscribes to a topic or, depending on the broker, to a pattern with wildcards. Every incoming message starts the flow, and its content is available there for further processing as a string or a byte array. If the content is a JSON document, the JSON Read transfer object evaluates its fields with JMESPath. The same JSON Schema plug-in that generates outgoing documents when publishing validates incoming ones, explicitly including data that arrives over MQTT. At the end of the flow, a transfer object writes to the target. The broker connection can be the same one used for publishing. Systems without MQTT are thus consumers of the namespace without being on the broker themselves.

This route is the last stretch of a larger loop. How production data turns into decisions that flow back into production is what pronubes describes as a closed loop: data-driven production. The focus here is the technology underneath: how a value from the namespace reaches its target, and how the sender finds out whether it arrived.

Which targets such a flow serves depends on its transfer objects. The MQTT plug-in page gives MQTT to OPC UA, to SAP, to SQL and to REST as examples:

The same use cases describe routes to targets like these, but without a broker. A pump manufacturer in Finland uses the OPC Router to bring production planning data from the ERP system into its PLCs, and the OPC Router reports the activity back to the ERP system. An Austrian company in the chemical industry runs the OPC Router as a data hub in production at several sites: data comes from production over OPC UA, and, depending on the site, REST, InfluxDB, SAP or printers are connected. The use cases contain no case in which the OPC Router subscribes to data from a broker and writes it on.

Into the PLC: orders and setpoints with acknowledgment

A PLC can be a target too. The OPC Router then writes through an OPC server such as Kepware or through the PLC's own OPC UA server, the same route it reads from when publishing. These transfer objects are available for that:

• OPC Data Access writes current values to data points, over OPC Classic and OPC UA. If the data points are only known at runtime, OPC Dynamic Write writes to the paths passed in.
• OPC Structures writes an OPC UA structure, such as an order that the PLC defines as a structure.
• OPC Methods calls a method in the PLC and receives its return values. This requires OPC UA and a PLC that offers the method.
• OPC Message bundles the data to be written into one request with a MessageID that the OPC Router can increment with every transfer. With "Wait for response" enabled, it waits until the PLC confirms processing through a response data point. If no confirmation arrives within the response timeout, the transfer counts as failed and is aborted.

For orders and setpoints, OPC Message is the route with acknowledgment. It is the handshake that the PLC article describes for the opposite direction, with the roles swapped: the OPC Router writes the record and signals it through the send data point, and the PLC processes it in its program and confirms through the response data point. Processing thus stays in the PLC. Control commands to running processes do not belong on this route. The manubes article Unified Namespace – Grundprinzipien und Umsetzung (in German) likewise advises examining processes with very high demands on response time, reliability and availability carefully before integrating them into a UNS, for example in production control or safety-related applications; in such cases, dedicated, directly connected systems are often still preferred.

Which systems may write is decided by the plant operator. The tools for this sit at the broker, for which the MQTT specification recommends access controls per topic, and in the PLC or the OPC server, where OPC UA provides write permissions per user. The Sparkplug specification names three places for commands: access control lists on the broker, permissions in the sending application, and the edge node itself, which decides whether to carry out a command.

Sparkplug as a consumer

Sparkplug B also works in both directions. A Sparkplug connection in the OPC Router registers with the broker in one of two profiles. In the "Node" profile, the OPC Router runs an edge node: it publishes values and, through the Sparkplug Command Trigger, receives commands that an application sends to it, in Sparkplug B the message types NCMD for the node and DCMD for a device. In the "Application" profile, it sits on the other side: the trigger for node and device data fires when a connected device changes its data, and the Application Command transfer object sends commands to Sparkplug nodes, addressed by Group ID, Node ID and optionally Device ID.

Sparkplug B does not define an acknowledgment of its own for commands. According to the specification, an edge node writes a received command to the PLC using the native protocol, and confirmation comes indirectly: when the output changes, the node publishes the new value as a DATA message. What happens when a write fails is not covered by the specification.

How does the sender know whether a command arrived?

Not from the MQTT acknowledgment. The MQTT trigger acknowledges a message to the broker as soon as it has queued the transfer or, with "Wait for Transfer" enabled, only after the transfer has finished. In both cases, the manual states, the acknowledgment only reports that the router has completed the message. It does not contain the result of the transfer, and a failed transfer is not reported to the broker as an error either. The Sparkplug Command Trigger never acknowledges a command.

A business-level response is therefore a message of its own, configured in the flow:

• With MQTT 5, the sender puts a response topic and correlation data into its request. The MQTT trigger can output both to the flow, and the MQTT transfer object has an option to send the message to a response topic instead of the configured topic. This requires the broker connection to be set to MQTT 5 and the broker to support that version.
• With MQTT 3.1.1, these properties do not exist. The identifier and the response topic then go into the payload, as AWS describes for commands on its IoT platform.
• With Sparkplug, an additional "Sparkplug Node Publish" transfer object in the same flow publishes a response. According to the manual, this happens in the middle of the flow, independently of the transfer result and with no reference to the command that triggered it.

If the response is also meant to report a failure, the write step goes into a Try/Catch transfer object, and the CATCH branch publishes the error message. Without that wrapper, the transfer ends at the failed step, and the transfer object that was supposed to send the acknowledgment never runs. Each call of the TRY branch has a fixed time limit of 30 seconds. The OPC Message response timeout therefore has to stay below it. If the PLC takes longer to confirm, the attempt counts as failed, and the CATCH branch reports an error while the PLC may still be processing the order.

An example configuration for this direction: an order for the filler on line 3 arrives as a JSON document on a dedicated command topic, with an identifier that comes back in the acknowledgment:

The flow writes the order and target quantity to the PLC with OPC Message and, once the PLC has confirmed, publishes on the response topic:

In the CATCH branch, the same place holds "result": "error" along with the error message. Here too, fields and topics are set in the configuration.

The organization designs it. Which levels central IT defines and which the plant owns is set out in the table on pronubes.com, along with the naming rules.

No software makes that decision for you.

Middleware takes on the second half: it does not define the name, it keeps it consistent. In the OPC Router, the convention sits in the topic as a template variable. The concrete values for each machine are rows in a CSV or Excel file from which the instances are generated. If the fixed part of the convention changes, one change to the template is enough; the instances then have to be put back into production. If the name of a single machine changes, that affects its row in the file, not the template. What a rename costs on the consumer side is covered in the FAQ on pronubes.com.

Where commands live is part of the convention too. Sparkplug B carries data and commands as separate message types in the path: NDATA and DDATA for values, NCMD and DCMD for commands. The specification cites this decoupling as what makes it possible to restrict, through access control on the broker, which applications may send commands. AWS recommends for its IoT platform that data and command topics be distinguished at the very first level. Both can be carried over to a namespace that mirrors the equipment hierarchy, as an analogy; where commands sit within it is for the convention to decide. Separate topics are the prerequisite for granting write permissions per topic.

That a live value only becomes readable together with master data is described on pronubes.com as a step of its own. The question here is where that data comes from: not from the PLC, but from the MES, the ERP system or a database.

In the OPC Router this can be combined in one flow: the live value triggers, a database query or an SAP call fetches the order reference, and both are published as a single JSON document. Each building block is documented; combining them is a configuration task. MQTT Data Storage also keeps the last message received for each topic on disk, where another flow can read it and combine it with a trigger of its own.

Duplicate rows in the database, a dashboard showing a frozen pressure value, a machine sending under the wrong name, an order that reaches the PLC a second time, and one that never arrives: these failure patterns follow from the way MQTT and the namespace are built and for the most part occur regardless of the product in use.

A flow fires twice, or not at all

The symptom: A flow writes the same record to the database twice. Or a flow that ran yesterday no longer fires at all.

The cause: Wildcards are an obvious choice in a namespace. One flow subscribes to plant-north/hall-2/#, a second to a single topic below it. For the broker, these are two separate subscriptions. Whether it then delivers a matching message once, or once per subscription, is left open by the MQTT specification, in both 3.1.1 and 5.

How it shows: duplicate rows with identical content and almost the same arrival time, or triggers in the configuration error state that name the affected topic. The second case comes from a quirk of the OPC Router, see below.

On your side. Before commissioning, check how the broker in use delivers on overlapping patterns. Build flows on QoS 1 triggers so they tolerate being run more than once, since at QoS 1 the broker may redeliver anyway.

In the OPC Router. If the broker connection runs MQTT 5 and the broker includes the subscription identifier, the manual states that the router assigns each delivery to its subscription and fires a flow only once, even when patterns overlap, unless MQTT Data Storage is active: then the identifier is not evaluated. This is set in the “MQTT Version” field of the broker connection. MQTT Data Storage subscribes to the pattern # by default and so overlaps with every trigger; its patterns should be limited to the topics actually needed, in the “Storage” section. As a last resort, “Enable Message Duplicate Detection” under “Advanced” discards identical messages within a time window of 3 seconds by default. It is off by default because it also discards genuine repeats with the same content. It also applies only per broker connection.

An OPC Router quirk. If several flows monitor the same topic over the same broker connection, one of them has “Wait for Transfer” enabled and the message arrives with a QoS above 0, the manual states that none of them fires. All the triggers involved go into the configuration error state, and a single waiting trigger is enough to cause it. The fix is to remove one of the three conditions: either switch off “Wait for Transfer” on every trigger for that topic, monitor the topic in one flow only, or make sure the message arrives with QoS 0.

A silent outage looks like a steady value

The symptom: The dashboard has shown the same pressure for hours. The line appears to be running smoothly. In fact the source dropped out hours ago.

The cause: Retain is intended. Every new subscriber is meant to get the last value immediately. When the source fails, that very value stays on the broker, and an unchanged value cannot be told apart from a stale one. This is a different problem from a gap in the historian record, which What is SCADA? describes. The symptom itself, a metric that stays the same although the line is running, is covered in What is ISA-95? together with the settings on the trigger, and pronubes.com lists it among the common pitfalls. This section is about what the namespace adds to it: the value the broker holds.

How it shows: not in the value itself. Only comparing its timestamp with the current time shows how old it is.

On your side. Add a status topic for each source to the naming convention, and build consumers so that they evaluate the age of a value rather than only the value. That is a decision about the namespace, not a setting.

In the OPC Router. The plug-in configuration has a First Will and a Last Will, each with a retain option. The obvious choice is to put both on the same status topic: online on connect, offline on disconnect. The Last Will only reports a broken connection between router and broker, however, not a PLC failing behind the OPC server. That shows in the quality: “Output Metadata” on the data change trigger sends timestamp and quality along with the value, and “Trigger on Quality Change” also fires when only the quality changes. The Data-Change-Missing trigger fires when a data point does not change within a check period. The settings for this are described in What is ISA-95? Two settings need care, because they can make a stale value look fresh: “At least every” transmits the current value periodically, so with a frozen source it transmits the frozen value. It only helps together with “Output Metadata” and a consumer that evaluates the timestamp sent with the value. “Publish known device metrics on reconnect” in the Sparkplug plug-in republishes known metrics after a reconnect, with the same risk. In the same plug-in, “Add Session Number to Device Birth and Death” adds the current session number to Device Birth and Death messages.

The broker accepts every typo

The symptom: A machine is missing from the analysis even though it is sending. It is just sending under a different name.

The cause: The OPC Router’s own page What is MQTT? puts it plainly: the broker accepts any valid topic without prior initialization, and topics are case-sensitive. So plant1/hall1 and Plant1/Hall1 would be two different topics. Connecting a fleet of machines by hand can create parallel branches this way without a single error message. A consumer with a wildcard on the correct branch never receives data from the machine that went astray.

How it shows: When browsing the broker, a branch appears twice, once in upper case and once in lower case.

On your side. Put the convention in writing and keep the list of machines and their names in one maintained file, not in someone’s head. A template makes the spelling consistent, but it does not check it: a typo in the list creates a branch of its own again.

In the OPC Router. The topic can be set up as a template variable of type String, the only type that allows a variable to be combined with fixed text. Instances are created from a CSV or Excel file via the template download and “Import”, as a series, or, with the Enterprise+ add-on, dynamically from a database table. In the MQTT transfer object, “Start Browsing” offers a topic selection based on the current broker connection.

A command arrives a second time

The symptom: An order that was completed long ago shows up in the PLC again. Nobody sent it again.

The cause: The order was published with retain. The broker then holds it as the last known message for the topic and, under the MQTT specification, delivers it to every new subscription. Under MQTT 3.1.1, it also resends retained messages when a client subscribes again to a topic it is already subscribed to, and under MQTT 5 it does the same with Retain Handling 0. The specification explains retain as a means for state messages: a new subscriber is meant to get the most recent state. A command with retain, by contrast, reaches every new subscription again, including that of a consumer that has already carried it out. Sparkplug B explicitly requires NCMD and DCMD commands to be published without retain and with QoS 0.

How it shows: An MQTT client that newly subscribes to the command topic immediately receives a message although nobody is sending. It carries the retain flag, because the broker delivers retained messages at subscription time with the flag set.

On your side. Publish commands without retain. Some brokers can enforce this through access rules: HiveMQ through its Enterprise Security Extension, EMQX from version 5.1.1 in its ACL file. The Mosquitto ACL file only distinguishes read and write permissions. A message that is already retained disappears when an empty message with retain is sent to the same topic; current subscribers receive that empty message as well and have to recognize it as a non-command. With MQTT 5, a subscriber can use Retain Handling 2 to opt out of retained messages at subscription time, and a sender can attach a lifetime with Message Expiry: if it has run out before delivery to a subscriber has started, the broker discards that copy. And since the broker may redeliver at QoS 1 anyway, give every command an identifier or sequence number that lets the receiver recognize a repeat.

In the OPC Router. If the OPC Router publishes commands itself, such as an order from SAP, “Retain” stays off in the MQTT transfer object for those topics. For the receiving side, the manual only states that the MQTT trigger checks the retain flag of an incoming message; it does not describe a setting that discards retained messages. The check for repeats therefore belongs in the flow: it compares a command’s identifier with the last one processed, in a database table for example, before writing to the PLC. In the broker connection, “CleanSession” starts a new session without saved messages. With it switched off, the session persists, and the broker delivers QoS 1 and 2 messages that arrived during an interruption once the connection is back. Whether a command should still be carried out after a disruption is therefore decided before commissioning.

A write fails without notice

The symptom: An order is in the namespace, the sending system lists it as transmitted, and it never reached the PLC. The sender received no error message.

The cause: If the write step in a flow fails, because the PLC cannot be reached for example, the OPC Router aborts the transfer. The remaining steps no longer run, and the aborted transfer is not repeated. The failure is not reported to the broker, not even with “Wait for Transfer”; the message counts as delivered. The sender only gets what has been explicitly configured as a response.

How it shows: in the transfer status in the OPC Router, not at the broker. An error stays completely inconspicuous in a Try/Catch transfer object without a CATCH branch: it swallows a final failure, the transfer stays green, and only the Succeeded status output is false.

On your side. Every command gets a response that carries its result, and the sender treats a response that has not arrived within a set time as an error. Only repeat what may be carried out more than once.

In the OPC Router. With OPC Message and “Wait for response”, a confirmation from the PLC that does not arrive within the response timeout turns into a failed transfer. The Try/Catch transfer object can retry the write step, with at most 5 attempts, each with a fixed time limit of 30 seconds. A retry, however, re-executes the entire TRY branch, including steps that already succeeded, so it only suits flows that may be run more than once. The CATCH branch handles the final failure and publishes the error acknowledgment. The Store & Forward add-on does not help here. According to its product page, it is meant for non-time-critical channels that do not expect a response to be processed; a write with “Wait for response”, however, evaluates the confirmation from the PLC. A delayed order would also arrive only once the set time has passed and the sender already treats it as failed: too late, or twice if the order has been sent again in the meantime. The manual also advises against it for targets where only the current value matters, such as an OPC tag, because outdated values would otherwise be written with a delay.