Kepware Is Not a Unified Namespace

Mario

Mario

— 5 min read
Share
Kepware Is Not a Unified Namespace

Why protocol translation stops at the edge — and why DataOps fills the role

The short answer

Kepware gets data out of devices; a Unified Namespace (UNS) says what that data means to the business. Kepware is an excellent input to a UNS, but it is not the UNS. A DataOps hub such as HighByte Intelligence Hub does the modeling, contextualization and publishing that turn raw tags into a namespace, and with an MQTT broker beside it (or its built-in one) it covers the role almost entirely.

The confusion is understandable. Kepware's IoT Gateway can publish tags to an MQTT broker, so a team enables an MQTT agent, sees values arriving in MQTT Explorer, and declares the UNS done. What they actually built is a device-shaped tag dump on a broker: topics that mirror channel and PLC addresses, payloads with no units or asset identity, and every consumer re-mapping the same tags on its own. The broker is shared; the meaning is not.

This article walks through what a UNS actually requires, where a protocol-translation layer stops, and what a DataOps layer adds to close the gap.

What a UNS actually requires

A UNS is an architecture, not a product: one event-driven, semantically organized view of the current state of the business, where every system publishes what it knows and subscribes to what it needs. Five properties define it:

  1. Semantic hierarchy. Topics follow the business, typically ISA-95 (enterprise / site / area / line / cell), not the wiring.
  2. Contextualized payloads. A message describes an asset as a structured object: values with units, identity, quality, timestamps, and related context such as product or work order.
  3. Reusable models. The same kind of asset looks the same everywhere, regardless of PLC brand or site.
  4. Event-driven, decoupled pub/sub. Producers report by exception; consumers subscribe without point-to-point integrations.
  5. OT and IT in one tree. MES, ERP, LIMS and quality systems publish into the same namespace as the machines.
UNS reference pattern · ISA-95 topic tree on an MQTT broker

UNS reference pattern · ISA-95 topic tree on an MQTT broker

The broker is only the meeting point; the value lies in the shape of the tree and the meaning of each payload.

Where Kepware stops

Kepware answers "what is register N7:12 on that PLC?"; a UNS answers "what is filler 3 doing, and on which order?". Kepware's job is protocol translation, and it does it very well: a large driver library puts Rockwell, Siemens, Modbus, Fanuc and dozens of other protocols behind OPC UA, and its IoT Gateway pushes tags to MQTT or REST. That is the hardest connectivity problem on the plant floor. But everything it publishes is shaped by the connection, not by the business:

  • The namespace is the wiring. Kepware's address space is channel, device, tag group, tag. Topics built from it encode PLC names and register addresses, so a controller swap or a re-addressed tag breaks every subscriber.
  • The payload is a tag, not an asset. The IoT Gateway sends tag ID, value, quality and timestamp as JSON (PTC docs). There are no reusable types: a filler on a Siemens line and one on a Rockwell line are two unrelated tag lists.
  • No outside context. Kepware cannot join a machine state with the work order from MES, the SKU from ERP or the spec limits from LIMS. Units, asset IDs and product live elsewhere.
  • OT only. Its sources are devices. IT systems do not publish through it, so it can only ever fill the machine branch of the tree.
  • JSON, not Sparkplug. The IoT Gateway publishes plain JSON over MQTT 3.1/3.1.1; Sparkplug B output needs another component (TTPSC).

The difference is visible on the broker. Kepware alone publishes something like this:

topic:   kepware/Line3_Channel/Filler_PLC/Global/N7_12
payload: {"timestamp":1760542560000,
          "values":[{"id":"Line3_Channel.Filler_PLC.Global.N7_12",
                     "v":3,"q":true,"t":1760542560000}]}

A UNS consumer needs this:

topic:   acme/floripa/packaging/line3/filler/state
payload: {"assetId":"FIL-0312","state":"Running",
          "speed":{"value":412,"unit":"bpm"},
          "workOrder":"WO-58821","sku":"AGUA-500",
          "oee":0.81,"ts":"2026-10-15T12:36:00-03:00"}

The value 3 means "Running" only to someone who has read the PLC program. Aliases and Advanced Tags can rename and derive values inside Kepware, but the result is still a flat tag list without asset identity, units or business context.

What a DataOps layer adds

HighByte Intelligence Hub does exactly the work Kepware leaves undone: it turns tags and records into modeled, contextualized assets and publishes them as the namespace. It typically consumes Kepware over OPC UA, alongside SQL, REST, MQTT, historians and files, and adds five things:

  • Models and instances. Define a type once (Filler: state, speed, counts, OEE) and instantiate it per asset, mapping each instance to whatever tags or columns feed it. Siemens or Rockwell underneath, the payload is identical.
  • Contextualization. One instance merges machine data with the MES work order, the ERP material and the LIMS result.
  • Pipelines. Transform, filter, buffer and report by exception, and reshape the same model for each destination.
  • Namespace and publishing. It publishes to MQTT or Sparkplug B in an ISA-95 hierarchy, and since version 3.0 ships an embedded MQTT v3.1.1/v5 broker (Control Engineering, Novotek).
  • Both directions. It subscribes to the UNS and delivers to systems that do not speak MQTT, such as SQL databases, REST APIs and cloud services (HiveMQ webinar).
Reference architecture · connect, model, share

Reference architecture · connect, model, share

Kepware stays where it is strongest, at the device edge; HighByte publishes modeled assets to the broker and reads back from it for systems that cannot subscribe.

Side by side

No single column is full. Kepware owns the device edge, HighByte covers nearly everything that makes the namespace meaningful, and the broker handles fan-out and retained state.

Author's assessment · 8 UNS requirements × 3 layers

Author's assessment · 8 UNS requirements × 3 layers

HighByte's partial marks are deliberate: it connects to some devices directly but does not replace a deep driver library, its embedded broker suits a site rather than an enterprise backbone, and model governance is as much an organizational discipline as a software feature.

Where the line really is

HighByte fills the UNS role almost completely; what remains is a broker sized for the scope and the discipline to govern the models. For a single site, Intelligence Hub with its embedded broker is a working UNS. Across sites, the usual pattern adds a clustered broker such as HiveMQ or EMQX, with a hub per site publishing into one enterprise tree.

A pragmatic build order:

  1. Keep Kepware at the edge. Use it for what it does best, driver coverage, and expose tags over OPC UA. Do not shape topics there.
  2. Model in the DataOps layer. Define asset types once, instantiate per machine, and join MES, ERP and LIMS context into the instances.
  3. Publish the tree from one place. Let HighByte own the ISA-95 topic structure and payload schema, so naming rules live in one tool instead of in every MQTT agent.
  4. Pick the broker by scope. Embedded for a site or a pilot; clustered for the enterprise backbone.
  5. Govern the models. Version them, assign owners, and treat a schema change like an API change, because every subscriber depends on it.

The test is simple: if a new consumer has to open a PLC program or a tag spreadsheet to understand a message, you have a broker full of tags, not a Unified Namespace.

Sources

Read more