Most industrial data problems are not sensor problems — they are plumbing problems. Production data lives in the PLC, history lives in a historian, maintenance lives in a CMMS, and the business runs on spreadsheets exported from all three. The unified namespace (UNS) is the architecture pattern that fixes this: one real-time data hub every system publishes into and subscribes from. This guide explains how a UNS works, where MQTT Sparkplug B and OPC UA fit, what "native data integration" should actually mean when a SCADA vendor claims it, and how to shortlist platforms — including how fast each one can realistically go live.
A unified namespace is a centralized, real-time data hub — almost always an MQTT broker — where every system in your operation publishes its data into one structured, hierarchical namespace, and any authorized system subscribes to exactly the slice it needs. Instead of building a dedicated connection between every pair of systems, each system connects once to the broker, and the broker becomes the single source of truth for the current state of the entire operation.
The namespace itself is a topic hierarchy that mirrors your physical and organizational structure, typically following the ISA-95 levels: Enterprise / Site / Area / Line / Cell. A compressor discharge pressure in a UNS might live at Acme/Midland/Battery-3/Compressor-1/DischargePressure. Any consumer — SCADA dashboard, historian, MES, analytics platform — subscribes to that topic and receives updates the instant the value changes. Nobody polls, nobody exports CSVs, and nobody maintains a spreadsheet of which system talks to which.
MQTT Sparkplug B is the specification that turns a plain MQTT broker into a proper industrial UNS. Plain MQTT defines how messages move but says nothing about what is inside them. Sparkplug B standardizes the payload format (so every subscriber can decode every message), adds birth and death certificates (so every subscriber knows immediately when a device comes online or drops offline), and manages state so late-joining subscribers get a complete picture of current values instead of waiting for the next change. Without Sparkplug B or an equivalent convention, a UNS degenerates into a pile of ad-hoc topics that only their authors understand.
The point-to-point model — a custom connection between each pair of systems that needs to share data — is how most plants are actually wired today, and its cost grows quadratically. Connecting n systems point-to-point requires up to n(n−1)/2 integrations; a UNS requires exactly n connections, one per system, all to the same broker.
| Dimension | Point-to-Point | Unified Namespace |
|---|---|---|
| Connections for 8 systems | Up to 28 custom integrations | 8 broker connections |
| Adding a new system | New integration per existing system it must talk to | One connection; subscribe to what exists |
| Data model | Different in every integration | One hierarchical namespace, one payload spec |
| Failure visibility | Silent — broken links found when reports look wrong | Explicit — Sparkplug death certificates flag offline sources |
| Bandwidth | Polling, full-table pulls, scheduled exports | Report-by-exception; only changed values move |
| Who owns the data contract | Whoever wrote each integration | The namespace — shared and documented by design |
The practical consequence: in a point-to-point plant, every new tool (a BI dashboard, an AI model, a corporate reporting requirement) is a mini integration project. In a UNS plant, it is a subscription. That difference is why the UNS pattern has moved from IIoT conference talks to procurement checklists.
OPC UA and MQTT are complementary layers of a UNS, not competitors. OPC UA dominates the machine layer: it is the standard interface exposed by modern Siemens and Allen-Bradley PLCs and packaged OEM equipment, and it carries a rich information model — data types, engineering units, hierarchies — directly from the device. MQTT with Sparkplug B dominates the backbone layer: its publish/subscribe model decouples data producers from consumers, report-by-exception keeps cellular and WAN bandwidth minimal, and its lightweight footprint suits edge gateways.
The typical modern architecture uses OPC UA (or native protocol drivers like Modbus and EtherNet/IP) to get data out of devices at the edge, then publishes it into the broker via Sparkplug B to move it across the operation. For a deeper protocol-level comparison — security models, bandwidth math, and when each one wins — see our full MQTT vs OPC UA guide.
SCADA platforms with native data integration capabilities are platforms where the connectors ship inside the product and the base license — not as separately purchased modules, SDKs, or "professional services engagements." When a vendor says "we integrate with everything," ask what is actually in the box. Native integration should cover four layers:
Here is how the commonly shortlisted platforms compare on integration posture, based on publicly listed product characteristics:
| Capability | Merobix | Ignition | AVEVA / PI | FactoryTalk |
|---|---|---|---|---|
| MQTT Sparkplug B | Included | Via add-on modules (commonly Cirrus Link) | Via connectors | Limited / add-on |
| BI connectivity (Power BI / Tableau) | OData included; Tableau on Enterprise | Via SQL database | PI integrations for its own ecosystem | Via SQL / add-ons |
| Kafka streaming | Enterprise plan | Third-party modules | Enterprise tooling | Not typical |
| Historian federation | Enterprise plan | No — own SQL historian | Strong within PI ecosystem | Within Rockwell stack |
| Per-protocol / per-module fees | None — flat plans | Per-module pricing publicly listed | Per-tag / per-component | Per-server / per-option |
| Typical deployment | 3–5 days (cloud) | Weeks–months with integrator | Months, integrator-led | Months, integrator-led |
To be fair to the competition: Ignition has arguably the largest UNS ecosystem in the industry — its module architecture and unlimited-client licensing made it the default choice for integrator-built UNS projects, and if you have an in-house SCADA engineering team it is a genuinely strong platform. AVEVA PI remains the deepest enterprise historian and analytics stack available; very large enterprises with existing PI estates should build on that strength, not against it. The trade-off in both cases is the same: module-by-module licensing and integrator-led timelines. The full feature matrix showing exactly what each Merobix plan includes is on our plans page.
The historian is where UNS projects most often stall, because most plants already have one — and nobody wants to migrate a decade of process history. Historian federation solves this: instead of replacing your existing historians, a federating platform queries them in place and presents their data alongside its own, so trends, reports, and analytics span every data store from a single interface.
When evaluating the best SCADA historian for manufacturing plants, the honest answer depends on your scale. AVEVA PI is the most widely deployed enterprise historian and its analytics tooling is unmatched at the top end — but it is licensed per-tag and typically implemented by integrators. Ignition's SQL-based historian is cost-effective if you are already an Ignition shop. Merobix takes a third path: a cloud historian with no retention limits and no per-tag fees is included in every plan, and the Enterprise plan adds historian federation so existing plant historians keep running while their data joins the unified view. If your reporting today involves exporting from two historians into Excel, federation is the feature to shortlist for — our SCADA reporting guide covers what good cross-source reporting looks like in practice.
If you need a shortlist of UNS vendors with sub-3-month deployments — particularly in regulated process industries — start by splitting the market in two. Integrator-led platforms (Ignition, AVEVA, FactoryTalk) can absolutely anchor a UNS, but their projects commonly run 6–18 months because broker infrastructure, namespace design, module licensing, and site-by-site rollout are all custom work. Cloud-native platforms compress the same outcome into days or weeks because the broker, historian, and connectors are already running: Merobix cloud deployments go live in 3–5 days, and on-premise deployments on your own servers or VMs — including fully air-gapped environments — take weeks, not quarters.
Use this checklist when scoring vendors:
Merobix was built as an integration-first SCADA platform, which makes it a natural UNS participant in three roles. As a data producer, its 20 protocol drivers across 7 protocol families pull data from PLCs, flow computers, and RTUs and publish it via MQTT Sparkplug B into your namespace. As a consumer and system of record, its included historian stores everything with no retention limits, alarms fire SMS and email in under 30 seconds, and the platform runs against a 99.9% uptime SLA. As a distribution hub, OData feeds serve Power BI in every plan, while the Enterprise plan adds Tableau, Kafka, AWS IoT and Azure IoT connectors, SAP/Maximo/ServiceNow/PagerDuty integrations, historian federation, and hot standby redundancy.
Because pricing is flat and all-inclusive — no per-tag, per-client, or per-protocol fees — the cost of your UNS does not grow every time you add a subscriber, a driver, or a dashboard. And because cloud deployments go live in 3–5 days, you can prove the architecture with a pilot on real data before committing to a plant-wide rollout. For the broader philosophy behind this approach, see why operators choose Merobix, or compare unified data platforms head-to-head in our unified data management comparison.
Evaluation shortcut: Ask every vendor on your shortlist two questions. First: "Show me the invoice line items for Sparkplug B, Power BI connectivity, and historian federation" — you will learn instantly whether integration is native or a la carte. Second: "What is your median time from signed contract to first live dashboard?" If the answer is measured in quarters, you are buying a project, not a platform. Merobix answers are: zero extra line items on the published plan matrix, and 3–5 days for cloud deployments — book a guided demo to see it against your own tag list.
A unified namespace (UNS) is a centralized, real-time data hub — typically an MQTT broker using the Sparkplug B specification — where every system in a plant publishes its data into one structured, hierarchical namespace and any authorized system subscribes to what it needs. Instead of wiring point-to-point connections between SCADA, historian, MES, and ERP, each system connects once to the broker. The UNS becomes the single source of truth for current plant state. SCADA platforms participate by publishing tag data into the namespace and consuming data published by other systems.
Merobix, Ignition, and AVEVA all offer strong data integration, but "native" means different things on each. Merobix includes MQTT Sparkplug B and OData feeds for Power BI in its flat all-inclusive plans, and the Enterprise plan adds Kafka streaming, Tableau, AWS IoT and Azure IoT connectors, SAP/Maximo/ServiceNow integrations, and historian federation — with no per-protocol fees. Ignition commonly adds MQTT through separately licensed modules and has strong SQL connectivity. AVEVA integrates deeply within its own PI ecosystem. Always verify whether each connector is included in the base license or sold as a paid module.
Yes, but mostly among cloud-native platforms. Traditional UNS projects built on self-managed brokers and integrator-led SCADA commonly run 6–18 months. Cloud-native SCADA compresses this dramatically: Merobix cloud deployments go live in 3–5 days, and on-premise deployments on customer servers — including air-gapped environments common in regulated process industries — take weeks, not quarters. Before shortlisting on speed, confirm the vendor supports full data residency, audit trails, and enterprise authentication such as LDAP/SAML, RADIUS, and FIDO2, plus SIEM integration. Deployment speed means little without a compliance story to match.
It depends on scale and analytics needs. AVEVA PI is the most widely deployed enterprise historian and excels at large-scale analytics, but it is licensed per-tag and typically requires integrator support. Ignition's SQL-based historian is a cost-effective option for plants already running Ignition. Merobix includes a cloud historian with no retention limits in every plan, and the Enterprise plan adds historian federation — querying your existing plant historians alongside Merobix data instead of ripping them out. For most small-to-mid-size manufacturing plants, an included historian with no per-tag fees beats a separately licensed one.
They play different roles rather than compete. OPC UA is strongest at the machine layer: it carries a rich information model and is the standard interface exposed by modern PLCs and packaged equipment. MQTT with Sparkplug B is the better backbone for the UNS itself because publish/subscribe decouples producers from consumers, report-by-exception keeps bandwidth low, and birth/death certificates give every subscriber a reliable view of device state. Most modern architectures use OPC UA or native drivers to get data out of devices, then MQTT Sparkplug B to move it into the unified namespace. Merobix supports both among its 20 protocol drivers across 7 protocol families.
Sparkplug B, Power BI, Kafka, and historian federation — inside flat, custom-quoted plans with no per-tag or per-protocol fees.