Unified Namespace for OT/IT Integration with MQTT and WinCC Open Architecture
As industrial systems become more connected, the challenge isn't just collecting data; it’s streaming it reliably and in context across OT and IT. In Episode 4 of CONNACK, Andreas Vogler, Principal Key Expert at Siemens, shared how WinCC Open Architecture (OA) integrates seamlessly with MQTT and fits naturally into a Unified Namespace (UNS) architecture. In this post, we break down the key takeaways from his talk, including how it compares with technologies like Kafka, and show how WinCC OA and MQTT enable a modern, future-proof approach to industrial data integration.
Watch the full talk below, and read on as we unpack the key takeaways from the presentation.
What is WinCC Open Architecture?
Many know it as a SCADA system, but it’s much more. As Andreas puts it, WinCC OA is a rapid-application development platform for industrial IoT (IIoT). Built on a microservices architecture from the start, it enables distributed components to communicate over TCP/IP, similar to how modern event-driven systems operate.
At the heart of WinCC OA is the Event Manager, which functions much like an MQTT broker. It distributes events between components and stores the current state of every tag, ideal for maintaining a plant-wide data layer.
Why WinCC OA and MQTT Work Well in a Unified Namespace
The Unified Namespace is all about creating a centralized, real-time, hierarchical structure of data. WinCC OA and MQTT align naturally with this model:
Structured modeling: WinCC OA lets you model machines, lines, and entire plants. These models can be exported as topic trees in MQTT format.
Real-time with stateful awareness: MQTT delivers real-time data efficiently, while WinCC OA stores the last known value of each tag
Scalable and secure integration: MQTT scales to millions of devices (especially with HiveMQ clusters). WinCC OA is well-suited for SCADA-scale deployments with up to 4,000 concurrent clients.
Push-button publishing to UNS: Define a Plant Model once in OA, then publish entire views (value, time, status) as JSON over MQTT with a single click.
Comparing MQTT, WinCC OA, and Kafka: What You Should Know
This isn’t about choosing winners. Each technology serves a different purpose in the industrial data stack. The talk emphasized that MQTT, WinCC OA, and Kafka can each play a role depending on the architecture you’re building. Here’s how they compare based on specific capabilities relevant to a Unified Namespace and modern IIoT integration:
Feature | MQTT | WinCC OA | Kafka |
---|---|---|---|
Stateful data | Optional retained messages (vendor-specific behavior) | Retains last known values for all tags | No direct way to query current state |
Retained messages | Persistence of retained messages depends on broker configuration. HiveMQ ensures reliability through enterprise-grade features. | Not applicable | Not relevant (streams are persisted) |
Scalability | Millions of devices, up to 200 million concurrent messages, especially with HiveMQ clusters | ~4,000 concurrent clients | High throughput; fewer topics preferred |
Topic granularity | Highly granular topics possible | Hierarchical views | Each topic is a file on disk—too many is inefficient |
Historization | No built-in storage (brokers, like HiveMQ, offer extensions or integrations to support this) | Logs to InfluxDB, PostgreSQL/Timescale, Oracle, or any backend | Built-in stream retention; integrates with Iceberg for querying |
Query support | Not queryable unless combined with storage | Query current values directly | Replayable history, but no real-time state querying |
In summary,
MQTT is purpose-built for lightweight, real-time, and scalable communication, making it a perfect foundation for a Unified Namespace, especially when deployed with a reliable broker like HiveMQ.
WinCC OA adds structure, processing, and state retention, ideal for contextualizing plant-level data before publishing it to MQTT.
Kafka excels at high-throughput, long-term storage of event streams, but isn’t designed for querying current machine state or fine-grained hierarchical topic models.
Together, these technologies can complement each other in a layered architecture. But when it comes to streaming industrial data across distributed systems in real time, MQTT remains the essential backbone.
A Real-world Demo of MQTT and WinCC in Action
During the presentation, Andreas Vogler demonstrated the below:
A UNS-powered smart home system that streamed sensor data to an MQTT broker, where it was subscribed and visualized in a SCADA dashboard.
A robot arm sent joint values via Sparkplug B to a Unity-powered digital twin, enabling a live 3D visualization of movement.
Tag values were exposed to a large language model (LLM), allowing operators to ask natural-language questions like “Which room has the highest temperature?”
Voice commands were issued to the robot as a playful LLM-powered control experiment, showing the potential for combining MQTT with AI in industrial use cases.
The demo showcased how WinCC Open Architecture, beyond being a SCADA system, can serve as an IIoT platform that fits perfectly into a Unified Namespace with MQTT.
How MQTT Powers Real-Time Industrial Integration with Tools Like WinCC OA
MQTT acts as the real-time data backbone across systems. WinCC OA is a tool that can plug into a Unified Namespace using MQTT, whether to consume, transform, or publish industrial data. The examples below demonstrate how MQTT enables stateful data sharing, seamless scalability, and modular integration across OT and IT environments.
1. MQTT enables distributed, modular industrial systems: Modern IIoT systems demand flexibility, and MQTT is built for that. In the demo showcased, the SCADA platform used a microservices architecture where components communicate over TCP/IP, an ideal match for MQTT’s lightweight, publish-subscribe model. MQTT acts as the backbone for distributing events and sharing real-time state across the system. Whether you’re monitoring 100 devices or 100,000, MQTT’s decoupled communication approach supports modularity, scalability, and resilience.
2. Structured industrial data fits naturally into an MQTT-based Unified Namespace: MQTT isn’t just about messaging; it’s about enabling context-rich data sharing. In this example, a plant model with machines, assets, and tag hierarchies was defined within the SCADA system and published directly into a Unified Namespace using MQTT. With a single action, values, timestamps, and quality metadata were transmitted in JSON format. This structured publishing is exactly what MQTT and HiveMQ clusters are built to scale: providing a consistent, queryable stream of real-time operations data.
3. MQTT acts as a bridge between field-level data and enterprise systems: MQTT excels at bridging OT and IT domains. The system showed integrated southbound protocols—polling or subscribing to PLCs, and pushed that data northbound via MQTT, REST, Node-RED, and even direct UNS publishing.
This shows how MQTT can serve as the transport layer for edge-to-cloud integration, supporting analytics, visualization, and AI-powered decision-making.
4. MQTT complements full-stack data transformation and enrichment: While MQTT transports raw and structured data efficiently, it becomes even more powerful when paired with systems that enrich the data at the edge. In this scenario, MQTT was used to transmit values that had already been processed, converted units (like °F to °C), multilingual labels, and contextual metadata. Combined with MQTT, this creates streams that are not just real-time, but also meaningful and ready for action across systems.
5. MQTT supports deployments from edge devices to enterprise clusters: The architecture showcased ranged from lightweight gateways like the Siemens IOT2050 and Raspberry Pi, all the way to high-availability clusters. MQTT runs across this full spectrum, supporting real-time communication at the edge and reliable, redundant messaging in the data center.
With HiveMQ, this MQTT infrastructure can scale horizontally and remain resilient across environments.
6. MQTT enables visualization, orchestration, and flow-based logic: The integration demonstrated included real-time dashboards and Node-RED logic flows, all running on top of live MQTT data. MQTT allows different consumers, such as UIs, services, and APIs, to subscribe to the same data stream without tightly coupling them. This makes it easier to build modern industrial applications that are both reactive and loosely integrated.
Conclusion
WinCC OA brings structured context and rich data modeling to industrial environments, making it easier to organize and contextualize operations data. But real-time, cross-system data movement becomes possible only with MQTT, especially if you use a scalable, reliable MQTT broker like HiveMQ. Together, they enable a robust Unified Namespace architecture that bridges OT and IT, scales from edge to cloud, and powers advanced use cases like digital twins, analytics, and AI-driven automation.
Whether you're retrofitting legacy systems or designing a greenfield deployment, MQTT with WinCC OA gives you the flexibility, transparency, and performance that modern industrial systems require.
Ready to implement a Unified Namespace with MQTT? Talk to HiveMQ about deploying an enterprise-grade MQTT broker built for IIoT success.
HiveMQ Team
The HiveMQ team loves writing about MQTT, Sparkplug, Unified Namespace (UNS), Industrial IoT protocols, IoT Data Streaming, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.