SCADA systems (Supervisory Control and Data Acquisition) have been a central component of industrial automation for decades. They collect data from PLC/PLC controllers, visualize processes and enable their operation on site. With the advent of Industry 4.0, however, the requirements are increasing: Data must be available across locations in real time – horizontally and vertically integrated right up to the cloud. Traditional SCADA architectures quickly reach their limits here. Data silos are often created in which information remains isolated and only reaches higher MES/ERP levels via complex interfaces or manual exports. This is expensive, inflexible and inhibits the full potential of modern industrial applications.
The solution: integrating SCADA into the Unified Namespace (UNS) in a meaningful way. The following article shows how this can be achieved – and what focused role SCADA systems play in modern UNS architectures.
What is a SCADA system?
SCADA systems (Supervisory Control and Data Acquisition) perform key tasks in industrial automation: they record, visualize and monitor process data, enable setpoints to be set, manage alarms and store data for the long term (historization). As an interface between humans and machine, SCADA allows operating personnel to control and monitor processes in a targeted manner. Traditionally, SCADA is also connected to higher-level systems such as MES or ERP via individual interfaces – often in the role of an OT data integration layer.
This central mediator role creates a strong dependency and strict coupling between the systems (point-to-point integration). In practice, this often leads to data silos and makes it difficult to scale modern Industry 4.0 applications.
What is the Unified Namespace (UNS)?
The Unified Namespace (UNS) is a company-wide real-time data model that is typically based on the MQTT protocol. It acts as a central “single source of truth” for operating and production data and maps the structure of the company in a common digital namespace. All devices, controllers and applications publish their data in this namespace – and every authorized system can subscribe to the desired information. The basis for this is the publish/subscribe principle of MQTT: data producers (publishers), such as sensors, gateways or controllers, send their information to a central MQTT broker in a thematically organized manner (via so-called topics). Data consumers (subscribers), such as SCADA, MES or cloud systems, subscribe to relevant topics and receive updates automatically.
This model decouples data sources from data consumers. The broker takes over the role of a central, cross-system data hub. The resulting decoupling eliminates data silos and creates the basis for scalable, end-to-end horizontal and vertical integration. Further details can be found here.
SCADA in the Unified Namespace (UNS): Architectural Example
In a Unified Namespace architecture, the SCADA system no longer takes over the central role of data hub between OT and higher IT systems. SCADA solutions are traditionally neither designed nor optimized for this task. Instead, SCADA becomes an equal participant in an MQTT-based infrastructure.
PLC to SCADA Integration
A typical data flow in a modern IIoT architecture with UNS is structured as follows:
- Sensor/PLC: Record process data (e.g. temperatures, pressures, fill levels) and execute the control logic. They provide the raw data, but often communicate via OT-specific protocols.
- Edge gateway (e.g. i-flow Edge): Aggregates data from one or more PLCs via interfaces such as Modbus and publishes it to the central broker in the UNS via MQTT. The gateway takes over the protocol transformation – it converts manufacturer-specific OT protocols into a standardized, MQTT-based data model.
- MQTT broker (UNS): The broker receives the incoming data and organizes it thematically into topics. As a central data hub, it enables “one-to-many” distribution: each connected system (e.g. SCADA, MES, analytics) can subscribe specifically to the topics relevant to it – without the data source having to send multiple times.
- SCADA system: The SCADA subscribes to the relevant topics from the broker and thus receives real-time data from all desired system parts. Instead of querying each PLC individually, data access is now event-driven via MQTT. If required, SCADA can also publish commands (control commands) as MQTT messages, which are subscribed to and processed by gateways or PLC systems.
This architecture decouples the systems and simultaneously creates a central, standardized interface between IT and OT. The PLC only sends its data to the broker once – regardless of which systems consume it. SCADA thus becomes one of many equal subscribers and concentrates once again on its core tasks: monitoring and controlling processes. Data distribution is handled by an optimized MQTT broker – scalable and flexible.
Integration into Higher-Level Systems
The true added value of the Unified Namespace (UNS) is that not only SCADA systems, but all IT and OT components can access the same database in parallel and in real time. Production data can be seamlessly integrated into ERP, MES, analysis platforms or cloud services via the MQTT broker – also using the MQTT subscription model. Each system specifically subscribes to the information it needs from the shared namespace:
- An MES system can subscribe to machine data such as quantities or operating statuses in order to track production orders live.
- At the same time, a cloud-based analytics application can analyze the same data as well as additional parameters (e.g. vibrations, temperatures) to identify patterns or correlations between process values and machine states.
Events are forwarded to all subscribed systems as soon as they occur – in real time, without delay or manual recording. The UNS thus replaces traditional point interfaces with a central, scalable data model.
The Role of Sparkplug B
The open MQTT extension standard Sparkplug B has been established to efficiently integrate SCADA systems into the Unified Namespace (UNS). This is a specification from the Eclipse Foundation. It specifies how MQTT messages must be structured in industrial automation environments in a SCADA context. This is because MQTT itself does not specify data formats or topic structures. This high level of flexibility leads to integration efforts in SCADA if different manufacturers use their own formats or naming conventions. Sparkplug B closes this gap. Detailed information can be found here.
How does Sparkplug B work?
Sparkplug B creates standardized communication between controllers, gateways and SCADA systems. The central elements include:
- Self-recognition through birth/death messages: Devices automatically register with the MQTT broker at startup with a birth message that contains their complete data structure. SCADA systems (as sparkplug subscribers) immediately recognize new devices and their data points. In the event of a failure, the device sends a death message so that the system status always remains transparent.
- Uniform payloads: Sparkplug B defines standardized data packages including data types, timestamps, quality flags and metadata. This enables plug-and-play integration without manual mapping efforts.
Limitations of Sparkplug B
Despite the advantages, Sparkplug B also has some technical limitations – especially when it comes to integration into higher IT levels within a distributed UNS architecture:
- Dependence on a primary host application: Sparkplug B provides for a central “primary application” (SCADA system) that takes on coordinating tasks. If this instance fails, the connected devices stop their data transmission. This central control concept contradicts the decentralized approach of the Unified Namespace.
- Limited topic structure: The specification limits the depth and flexibility of the topic hierarchy. This makes it difficult to map complex structures – for example according to ISA-95. This also severely restricts the use of MQTT wildcards.
- No quality of service above level 0: Sparkplug B specifies MQTT QoS 0 (“at most once”). Messages are therefore transmitted unsecured, which is not sufficient for many industrial use cases with high data integrity requirements.
- Prohibition of the retain flag: The use of the MQTT retain flag is prohibited in Sparkplug B. This means: the broker does not save the last known value of a topic – a newly connected client therefore does not receive any current data until a new value is sent.
- Low IT compatibility: Common IT systems such as ERP, MES or cloud platforms do not support Sparkplug B natively. The binary protobuf coding must first be decoded before the data can be processed. This significantly increases the integration effort.
Recommendation: Coexistence of Sparkplug B and JSON in the UNS
Sparkplug B is a recommended standard for OT-related scenarios with central SCADA systems and classic n:1 communication. Thanks to standardized payloads, automatic device messages (birth/death messages) and plug-and-play functionality, Sparkplug offers a robust basis for the structured integration of machine and process data at the operational level. In comprehensive, company-wide Unified Namespace architectures, however, Sparkplug B comes up against systemic limits – particularly due to its limited flexibility in topic structures, the lack of IT compatibility and the centralized communication model.
Therefore: Use Sparkplug B exclusively in the SCADA context and for the integration of controllers, gateways and SCADA. JSON over MQTT for IT systems (e.g. MES, ERP, cloud).
Sparkplug B and JSON over MQTT can exist in parallel in the UNS without any problems – thanks to a clear separation of the topic structures:
- OT-SCADA communication: Gateways and SCADA systems publish and consume data in the Sparkplug-compliant topic area (e.g. spBv1.0/group_id/edge_node_id/device_id). These topics are strictly structured and follow the Sparkplug conventions.
- OT-IT communication: Higher-level systems such as MES, ERP or analytics platforms subscribe to MQTT topics with JSON-formatted payloads – often from a separate, semantically structured namespace (e.g. factory/area1/site2/line3/machine4/alarms).
A gateway (e.g. i-flow Edge) can act as a bridge here: It converts Sparkplug data into JSON and makes it available to IT in a separate, readable topic tree. Conversely, it is also possible to convert JSON data into Sparkplug formats, for example if an OT system requires information directly from IT systems.
Conclusion
In the context of Industry 4.0, the role of SCADA is changing fundamentally. Instead of being a central integration instance in rigidly coupled architectures, SCADA in the Unified Namespace (UNS) is becoming an equal participant in a flexible, event-driven infrastructure. It communicates directly with sensors, controllers and IT systems via MQTT – without proprietary point-to-point connections or manual exports.
