SCADA-Systeme (Supervisory Control and Data Acquisition) sind seit Jahrzehnten zentraler Bestandteil der industriellen Automatisierung. Sie erfassen Daten von SPS/PLC-Steuerungen, visualisieren Prozesse und ermöglichen deren Bedienung vor Ort. Mit dem Aufkommen von Industrie 4.0 steigen jedoch die Anforderungen: Daten müssen standortübergreifend in Echtzeit verfügbar sein – horizontal und vertikal bis in die Cloud integriert. Klassische SCADA-Architekturen stoßen hier schnell an ihre Grenzen. Häufig entstehen Datensilos, in denen Informationen isoliert bleiben und nur über aufwändige Schnittstellen oder manuelle Exporte in höhere MES-/ERP-Ebenen gelangen. Das ist teuer, unflexibel und hemmt das volle Potenzial moderner Industrieanwendungen.
Die Lösung: SCADA im Unified Namespace (UNS) sinnvoll integrieren. Der folgende Artikel zeigt, wie das gelingen kann – und welche fokussierte Rolle SCADA-Systeme in modernen UNS Architekturen einnehmen.
Was ist ein SCADA System?
SCADA-Systeme (Supervisory Control and Data Acquisition) übernehmen zentrale Aufgaben in der industriellen Automatisierung: Sie erfassen, visualisieren und überwachen Prozessdaten, ermöglichen das Setzen von Sollwerten, managen Alarme und speichern Daten langfristig (Historisierung). Als Schnittstelle zwischen Mensch und Maschine erlaubt SCADA dem Bedienpersonal, Prozesse gezielt zu steuern und zu überwachen. Traditionell ist SCADA zudem über individuelle Schnittstellen mit übergeordneten Systemen wie MES oder ERP verbunden – oft in der Rolle einer OT-Daten-Integrationsschicht.
Durch diese zentrale Vermittlerrolle entsteht eine starke Abhängigkeit und strikte Kopplung zwischen den Systemen (Punkt-zu-Punkt Integration). Dies führt in der Praxis häufig zu Datensilos und erschwert die Skalierung moderner Industrie 4.0 Anwendungen.
Was ist der Unified Namespace (UNS)?
Der Unified Namespace (UNS) ist ein unternehmensweites Echtzeit-Datenmodell, das typischerweise auf dem MQTT-Protokoll basiert. Er fungiert als zentrale „Single Source of Truth“ für Betriebs- und Produktionsdaten und bildet die Struktur des Unternehmens in einem gemeinsamen digitalen Namensraum ab. Alle Geräte, Steuerungen und Applikationen veröffentlichen ihre Daten in diesen Namespace – und jedes berechtigte System kann die gewünschten Informationen abonnieren. Grundlage dafür ist das Publish/Subscribe-Prinzip von MQTT: Datenproduzenten (Publisher), etwa Sensoren, Gateways oder Steuerungen, senden ihre Informationen thematisch geordnet (über sogenannte Topics) an einen zentralen MQTT-Broker. Datenkonsumenten (Subscriber), wie SCADA-, MES- oder Cloud-Systeme, abonnieren relevante Topics und erhalten automatisch Updates.
Dieses Modell entkoppelt Datenquellen von Datenverbrauchern. Dabei übernimmt der Broker die Rolle einer zentralen, systemübergreifenden Datendrehscheibe. Die resultierende Entkopplung eliminiert Datensilos und schafft die Grundlage für eine skalierbare, durchgängige horizontale und vertikale Integration. Weitere Details hierzu finden Sie hier.
SCADA im Unified Namespace (UNS): Architekturbeispiel
In einer Unified Namespace Architektur übernimmt das SCADA-System nicht länger die zentrale Rolle als Datenvermittler zwischen OT und höheren IT-Systemen. Für diese Aufgabe sind SCADA Lösungen traditionell weder konzipiert noch optimiert. Stattdessen wird SCADA zu einem gleichberechtigten Teilnehmer in einer MQTT-basierten Infrastruktur.
Integration Steuerung zu SCADA
Ein typischer Datenfluss in einer modernen IIoT-Architektur mit UNS gliedert sich wie folgt:
- Sensor/PLC: Erfassen Prozessdaten (z. B. Temperaturen, Drücke, Füllstände) und führen die Steuerungslogik aus. Sie stellen die Rohdaten bereit, kommunizieren jedoch häufig über OT-spezifische Protokolle.
- Edge-Gateway (z.B. i-flow Edge): Aggregiert Daten von einer oder mehreren SPS über Schnittstellen wie Modbus und publiziert sie via MQTT an den zentralen Broker im UNS. Dabei übernimmt das Gateway die Protokolltransformation – es konvertiert herstellerspezifische OT-Protokolle in ein standardisiertes, MQTT-basiertes Datenmodell.
- MQTT-Broker (UNS): Der Broker empfängt die eingehenden Daten und organisiert sie thematisch in Topics. Als zentrale Datendrehscheibe ermöglicht er eine „One-to-Many“-Verteilung: Jedes angebundene System (z. B. SCADA, MES, Analytics) kann gezielt die für es relevanten Topics abonnieren – ohne dass die Datenquelle mehrfach senden muss.
- SCADA-System: Das SCADA abonniert die relevanten Topics vom Broker und erhält so Echtzeitdaten aus allen gewünschten Anlagenteilen. Statt jede SPS einzeln abzufragen, erfolgt der Datenzugriff nun ereignisgesteuert über MQTT. Bei Bedarf kann SCADA auch Befehle (Steuerkommandos) als MQTT-Nachrichten publizieren, die von Gateways oder SPS-Systemen abonniert und verarbeitet werden.
Diese Architektur entkoppelt die Systeme und schafft gleichzeitig eine zentrale, einheitliche Schnittstelle zwischen IT und OT. Die SPS sendet ihre Daten nur noch einmal an den Broker – unabhängig davon, welche Systeme sie konsumieren. SCADA wird so zu einem von vielen gleichberechtigten Subscribern und konzentriert sich wieder auf die Kernaufgaben: das Überwachen und Steuern von Prozessen. Die Datenverteilung übernimmt ein darauf optimierter MQTT-Broker – skalierbar und flexibel.
Integration in übergeordnete Systeme
Der wahre Mehrwert des Unified Namespace (UNS) zeigt sich darin, dass nicht nur SCADA-Systeme, sondern sämtliche IT- und OT-Komponenten parallel und in Echtzeit auf dieselbe Datenbasis zugreifen können. Über den MQTT-Broker lassen sich Produktionsdaten nahtlos in ERP-, MES-, Analyseplattformen oder Cloud-Dienste integrieren – ebenfalls über das MQTT-Subscription-Modell. Jedes System abonniert gezielt die Informationen, die es aus dem gemeinsamen Namensraum benötigt:
- Ein MES-System kann Maschinendaten wie Stückzahlen oder Betriebszustände abonnieren, um Fertigungsaufträge live zu verfolgen.
- Gleichzeitig kann eine Cloud-basierte Analytics-Anwendung dieselben Daten sowie zusätzliche Parameter (z. B. Vibrationen, Temperaturen) analysieren, um Muster oder Korrelationen zwischen Prozesswerten und Maschinenzuständen zu erkennen.
Ereignisse werden unmittelbar bei Auftreten an alle abonnierten Systeme weitergegeben – in Echtzeit, ohne Zeitverzug oder manuelle Erfassung. Damit ersetzt der UNS klassische punktuelle Schnittstellen durch ein zentrales, skalierbares Datenmodell.
Die Rolle von Sparkplug B
Um SCADA-Systeme effizient in den Unified Namespace (UNS) zu integrieren, hat sich der offene MQTT-Erweiterungsstandard Sparkplug B etabliert. Dabei handelt es sich um eine Spezifikation der Eclipse Foundation. Diese spezifiziert, wie MQTT-Nachrichten in industriellen Automatisierungsumgebungen im SCADA Kontext strukturiert sein müssen. Denn: MQTT an sich legt weder Datenformate noch Topic-Strukturen fest. Diese hohe Flexibilität führt zu Integrationsaufwänden im SCADA, wenn verschiedene Hersteller eigene Formate oder Namenskonventionen verwenden. Sparkplug B schließt diese Lücke. Detaillierte Informationen hierzu finden Sie hier.
Wie funktioniert Sparkplug B?
Sparkplug B schafft eine standardisierte Kommunikation zwischen Steuerungen, Gateways und SCADA-Systemen. Zu den zentralen Elementen gehören:
- Selbsterkennung durch Birth-/Death-Messages: Geräte melden sich beim Start automatisch mit einer Birth Message beim MQTT-Broker an, die ihre komplette Datenstruktur enthält. SCADA-Systeme (als Sparkplug-Subscriber) erkennen neue Geräte und deren Datenpunkte sofort. Bei Ausfall sendet das Gerät eine Death Message, sodass der Systemzustand stets transparent bleibt.
- Einheitliche Payloads: Sparkplug B definiert standardisierte Datenpakete inklusive Datentypen, Zeitstempeln, Quality Flags und Metadaten. Dadurch ist Plug-and-Play-Integration ohne manuelle Mapping-Aufwände möglich.
Limitierungen von Sparkplug B
Trotz der Vorteile bringt Sparkplug B auch einige technische Limitierungen mit sich – insbesondere bei der Integration in höhere IT-Ebenen innerhalb einer verteilten UNS-Architektur:
- Abhängigkeit von einer Primary Host Application: Sparkplug B sieht eine zentrale „Primary Application“ (SCADA-System) vor, die koordinierende Aufgaben übernimmt. Fällt diese Instanz aus, stoppen die angebundenen Geräte ihre Datenübertragung. Dieses zentrale Steuerungskonzept widerspricht dem dezentralen Ansatz des Unified Namespace.
- Begrenzte Topic-Struktur: Die Spezifikation limitiert die Tiefe und Flexibilität der Topic-Hierarchie. Dadurch lassen sich komplexe Strukturen – etwa nach ISA-95 – nur schwer abbilden. Auch die Nutzung von MQTT-Wildcards wird dadurch stark eingeschränkt.
- Kein Quality of Service über Level 0: Sparkplug B schreibt MQTT QoS 0 („at most once“) vor. Nachrichten werden also ungesichert übertragen, was für viele industrielle Anwendungsfälle mit hohen Anforderungen an Datenintegrität nicht ausreichend ist.
- Verbot des Retain-Flags: Die Verwendung des MQTT-Retain-Flags ist in Sparkplug B untersagt. Das bedeutet: der Broker speichert den letzten bekannten Wert eines Topics nicht – ein neu verbundener Client erhält somit keine aktuellen Daten, bis ein neuer Wert gesendet wird.
- Geringe IT-Kompatibilität: Gängige IT-Systeme wie ERP, MES oder Cloud-Plattformen unterstützen Sparkplug B nicht nativ. Die binäre Protobuf-Codierung muss erst dekodiert werden, bevor die Daten verarbeitet werden können. Dies erhöht den Integrationsaufwand deutlich.
Empfehlung: Koexistenz von Sparkplug B und JSON im Unified Namespace
Sparkplug B ist ein empfehlenswerter Standard für OT-nahe Szenarien mit zentralen SCADA-Systemen und klassischer n:1-Kommunikation. Durch standardisierte Payloads, automatische Gerätemeldungen (Birth/Death Messages) und Plug-and-Play-Funktionalität bietet Sparkplug eine robuste Grundlage für die strukturierte Integration von Maschinen- und Prozessdaten in der operativen Ebene. In umfassenden, unternehmensweiten Unified Namespace-Architekturen stößt Sparkplug B jedoch an systemische Grenzen – insbesondere aufgrund seiner begrenzten Flexibilität bei Topic-Strukturen, der fehlenden IT-Kompatibilität sowie des zentralistischen Kommunikationsmodells.
Daher: Sparkplug B ausschließlich im SCADA Kontext und für die Integration von Steuerungen, Gateways und SCADA nutzen. JSON over MQTT für IT-Systeme (z. B. MES, ERP, Cloud).
Sparkplug B und JSON over MQTT können im UNS problemlos parallel existieren – durch eine klare Trennung der Topic-Strukturen:
- OT-SCADA-Kommunikation: Gateways und SCADA-Systeme publizieren und konsumieren Daten im Sparkplug-konformen Topic-Bereich (z. B. spBv1.0/group_id/edge_node_id/device_id). Diese Topics sind strikt strukturiert und folgen den Sparkplug-Konventionen.
- OT-IT-Kommunikation: Höhere Systeme wie MES, ERP oder Analytics-Plattformen abonnieren MQTT-Topics mit JSON-formatierten Payloads – oft aus einem separaten, semantisch strukturierten Namensraum (z. B. factory/area1/site2/line3/machine4/alarms).
Ein Gateway (z.B. i-flow Edge) kann hierbei als Brücke fungieren: Er wandelt Sparkplug-Daten in JSON um und stellt sie in einem eigenen, lesbaren Topic-Baum für die IT bereit. Umgekehrt ist auch die Konvertierung von JSON-Daten in Sparkplug-Formate möglich, wenn etwa ein OT System Informationen direkt aus IT-Systemen benötigt.
Fazit
Im Kontext von Industrie 4.0 verändert sich die Rolle von SCADA grundlegend. Statt zentrale Integrationsinstanz in starr gekoppelten Architekturen zu sein, wird SCADA im Unified Namespace (UNS) zu einem gleichberechtigten Teilnehmer in einer flexiblen, ereignisgesteuerten Infrastruktur. Über MQTT kommuniziert es direkt mit Sensorik, Steuerungen und IT-Systemen – ohne proprietäre Punkt-zu-Punkt-Verbindungen oder manuelle Exporte.
