IT/OT-Konvergenz bezeichnet den Prozess, Informationstechnik (Geschäftssysteme, Cloud, Analytics) und Betriebstechnik (SPSen, SCADA, Maschinen) auf ein gemeinsames Fundament zu stellen, sodass beide mit denselben Daten arbeiten. In diesem Beitrag erfahren Sie, warum sich die beiden Welten so unterschiedlich entwickelt haben, was sich technisch und kulturell tatsächlich ändern muss und wie ein Unified Namespace (UNS) auf einem MQTT-Broker IT- und OT-Teams eine einheitliche Live-Sicht auf das Werk gibt, ohne die Prioritäten einer Seite zu gefährden.
Zwei Welten, die sich auseinanderentwickelt haben
Die Betriebstechnik (OT) ist in der Fertigungshalle groß geworden. Ihre Aufgabe ist es, einen physischen Prozess sicher am Laufen zu halten, jede Sekunde, über Jahrzehnte. Eine SPS, die einen Ofen steuert, kann fünfzehn Jahre lang dasselbe Programm ausführen, und das gilt als Erfolg. Veränderung ist ein Risiko, und ein Ausfall kann Anlagen beschädigen oder Menschen verletzen.
Die Informationstechnik (IT) ist im Büro groß geworden. Ihre Aufgabe ist es, Geschäftsinformationen sicher und effizient zu verarbeiten. Systeme werden monatlich gepatcht, alle paar Jahre ersetzt, und ein Ausfall ist teuer, aber selten gefährlich. Veränderung ist normal, und auf dem aktuellen Stand zu bleiben gehört zur Sicherheit dazu.
Keine der beiden Sichtweisen ist falsch. Sie sind auf unterschiedliche Folgen eines Fehlers optimiert. Die meisten Reibungen in Konvergenzprojekten entstehen, wenn Menschen die Regeln der einen Welt auf die andere anwenden.
| Dimension | IT-Prioritäten | OT-Prioritäten |
|---|---|---|
| Wichtigstes Anliegen | Vertraulichkeit der Daten | Verfügbarkeit und Sicherheit des Prozesses |
| Typischer Lebenszyklus | 3 bis 5 Jahre | 15 bis 30 Jahre |
| Patching | Regelmäßig, oft automatisiert | Selten, geplant rund um Stillstände |
| Protokolle | HTTP, SQL, REST, Cloud-APIs | Modbus, Profinet, OPC UA, Herstellerprotokolle |
| Form der Daten | Transaktionen, Dokumente, Datensätze | Kontinuierliche Signale, Zustände, Ereignisse |
| Toleranz für Ausfallzeiten | Geplante Wartungsfenster | Gemessen in Produktionsverlust pro Minute |
| Wer Änderungen vornimmt | IT-Administratoren, DevOps | Automatisierungstechniker, Integratoren |
Was IT/OT-Konvergenz wirklich bedeutet
Konvergenz wird oft missverstanden als „die SPSen ins Firmennetz hängen". Genau diese Variante macht OT-Ingenieure nervös, und das zu Recht. Richtig umgesetzt bedeutet IT/OT-Konvergenz drei engere Dinge:
- Gemeinsame Daten. Produktionsdaten fließen zuverlässig in Geschäftssysteme, und geschäftlicher Kontext wie Aufträge und Rezepturen steht dem Betrieb zur Verfügung.
- Gemeinsame Praktiken. Sicherheit, Identitäten, Monitoring und Change Management werden einheitlich angewendet und an die Rahmenbedingungen jeder Seite angepasst.
- Gemeinsame Menschen. Die Teams verstehen die Prioritäten der jeweils anderen Seite und verantworten die Integrationsschicht gemeinsam.
Was Konvergenz nicht erfordert, ist ein flaches Netzwerk. Das Purdue-Modell und die Zonen nach IEC 62443 gelten weiterhin. Die Integration findet an einer definierten Grenze statt, meist in einer industriellen DMZ, und das Werksnetz bleibt segmentiert. Unser Vergleich von Purdue-Modell und ISA-95 erklärt, wie diese Ebenen zusammenhängen.
Die technischen Bausteine
Ereignisgesteuerte Daten statt Punkt-zu-Punkt-Integrationen
Der klassische Weg, der IT Zugriff auf OT-Daten zu geben, ist eine Punkt-zu-Punkt-Integration: Das MES pollt SCADA, das ERP fragt den Historian ab, ein Reporting-Tool liest eine Datenbank, in die der Historian schreibt. Jede Verbindung ist individuell gebaut, fragil und gehört demjenigen, der sie gebaut hat. Ein neuer Konsument bedeutet eine weitere Integration.
Publish/Subscribe-Messaging ändert das. Jede OT-Quelle veröffentlicht ihre Daten einmal an einen Broker. Jeder IT-Konsument abonniert, was er braucht. Die OT-Seite muss nie wissen, wer zuhört, und die IT-Seite braucht nie eine Verbindung ins Werk. Wenn die Rolle des Brokers neu für Sie ist, lesen Sie, was ein MQTT-Broker macht.
Ein Unified Namespace als gemeinsame Sprache
Ein Broker allein macht Daten noch nicht verständlich. Der UNS fügt Struktur hinzu: Jeder Wert liegt unter einem vorhersehbaren Topic auf Basis der ISA-95-Hierarchie, etwa connectmq/acme/plant1/assembly/line2/press04/state. Die ISA-95-Ebenen Enterprise → Site → Area → Line → Cell werden dabei direkt zu Topic-Ebenen; in einem deutschen Werk könnte ein Pfad acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur lauten. Ein OT-Ingenieur erkennt den physischen Standort. Ein IT-Entwickler sieht eine stabile, dokumentierte API. Beide lesen dasselbe Topic, und MES, ERP und Analytics hängen sich an dieselbe Quelle. Unser Leitfaden zum Aufbau eines Unified Namespace führt durch das Design, und Sparkplug B und Unified Namespace zeigt, wie Sparkplug-Geräte hineinpassen.
Ausschließlich ausgehende Verbindungen
OT-Gateways verbinden sich ausgehend per TLS mit dem Broker, und IT-Konsumenten ebenfalls. Es werden keine eingehenden Ports ins Werk geöffnet. Das ist die wichtigste Eigenschaft, um die Unterstützung des OT-Sicherheitsteams zu gewinnen. Das Muster wird ausführlich in unserem Artikel zu MQTT in einer industriellen DMZ behandelt.
Klare Verantwortung für die Datenschicht
Jemand muss die Regeln für Topic-Namen, Payload-Konventionen, Zugangsdaten und Datenqualität verantworten. In reifen Organisationen entsteht daraus eine Industrial-DataOps-Funktion, die zwischen IT und OT angesiedelt ist. Mehr dazu in unserem Überblick zu Industrial DataOps.
Beispiel: Beide Teams lesen dieselben Live-Daten
So sieht Konvergenz in der Praxis aus. Ein OT-Gateway veröffentlicht den Maschinenzustand als Retained Messages in den UNS. Ein IT-Entwickler schreibt ein paar Zeilen Python, um diesen Zustand in eine Geschäftsanwendung einzuspeisen, ohne jemals die SPS oder das Gateway anzufassen.
Probieren Sie es zunächst auf dem öffentlichen MQTT-Broker aus, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten. Veröffentlichen Sie als „OT-Seite" einen Retained-Zustand:
mosquitto_pub -h broker.connectmq.com -p 1883 -i ot-sim-$RANDOM -r \
-t connectmq/demo/itot42/plant1/assembly/line2/press04/state \
-m '{"state":"RUNNING","order":"WO-1182","ts":"2026-10-16T09:12:00Z"}'
Starten Sie dann den Subscriber der „IT-Seite":
import json
import uuid
import paho.mqtt.client as mqtt
TOPIC = "connectmq/demo/itot42/plant1/+/+/+/state"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe(TOPIC, qos=1)
def on_message(client, userdata, msg):
parts = msg.topic.split("/")
area, line, machine = parts[4], parts[5], parts[6]
data = json.loads(msg.payload)
# Übergabe an ein Geschäftssystem, hier geben wir nur eine Zeile aus
print(f"{area:10} {line:6} {machine:8} {data['state']:8} order={data.get('order')}")
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"it-app-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()
Der Subscriber erhält den Retained-Zustand sofort beim Verbinden und danach jede Änderung in Echtzeit. Der OT-Ingenieur kann einen Desktop-MQTT-Explorer auf demselben Topic öffnen und sieht exakt dieselbe Nachricht. Diese gemeinsame Sicht ist Konvergenz im Arbeitsalltag. In der Produktion verwenden beide Seiten eigene Zugangsdaten für den Broker auf Port 8883, und echte Werksdaten gehen nie auf einen öffentlichen MQTT-Broker, den jeder lesen kann.
Kulturelle Schritte, damit Konvergenz Bestand hat
Die Technik ist die leichtere Hälfte. Diese Praktiken helfen auf der menschlichen Seite:
- Mit einem OT-Problem beginnen. Wählen Sie einen Anwendungsfall, der dem Werk wichtig ist, etwa ungeplante Stopps an einer Engpassmaschine. IT-getriebene Projekte, die nur dem Reporting dienen, bekommen selten Unterstützung aus der OT.
- Der OT die Edge überlassen. Automatisierungstechniker entscheiden, was aus welcher SPS gelesen wird, in welcher Rate und in welchem Modus. Die IT verantwortet die Konsumenten.
- Sich auf die Grenze einigen. Halten Sie schriftlich fest, wo die OT-Verantwortung endet, meist an der ausgehenden Verbindung des Gateways, und wo die der IT beginnt.
- Ein gemeinsames Vokabular verwenden. Die ISA-95-Hierarchie in Topic-Namen gibt beiden Teams gemeinsame Begriffe für Standorte, Bereiche, Linien und Maschinen.
- Tandems bilden. Setzen Sie einen IT-Entwickler und einen Automatisierungstechniker in dasselbe Pilotprojekt. Zwei Wochen gemeinsamer Arbeit bewirken mehr als jeder Workshop.
- Änderungsfenster respektieren. Gateway-Updates folgen den Wartungsplänen der OT, nicht dem Patch-Dienstag der IT.
Wo ein verwalteter MQTT-Broker hilft
Die gemeinsame Datenschicht muss sicher, ständig verfügbar und gewartet sein, also klassische IT-Arbeit. Läuft sie auf Werkshardware, landet diese Arbeit bei der OT, die sie meist nicht haben will. Ein verwalteter MQTT-Broker ist ein neutraler Ort, an dem sich beide Teams treffen. ConnectMQ erkennt ISA-95- und UNS-Topics automatisch, zeigt Geräte nach ISA-95-Ebene gruppiert an, dekodiert Sparkplug B für Teams, die es nutzen, und bietet einen Live-Topic-Explorer, den sowohl Automatisierungstechniker als auch Entwickler verwenden können. Organisationen mit strengen Vorgaben zur Datenresidenz können ConnectMQ BYOC in ihrem eigenen Cloud-Konto betreiben. Für einen breiteren Vergleich der Hosting-Modelle lesen Sie unseren Leitfaden zu Cloud-MQTT-Brokern, und für das vollständige industrielle Bild den Leitfaden zu Industrial IoT mit MQTT.
Ein Namespace für IT und OT mit ConnectMQ
Erstellen Sie einen kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte. Veröffentlichen Sie den Zustand einer Maschine in einen ISA-95-Topic-Baum, geben Sie beiden Teams Zugangsdaten und lassen Sie das Gespräch bei gemeinsamen Daten beginnen statt bei konkurrierenden Tabellen.
Häufig gestellte Fragen
Was ist IT/OT-Konvergenz, einfach erklärt?
Es geht darum, dass Geschäftssysteme und Werkssysteme mit denselben Daten arbeiten, mit gemeinsamen Praktiken für Sicherheit und Änderungen. Es bedeutet nicht, die Netzwerke zusammenzulegen oder der IT die Kontrolle über SPSen zu geben.
Erhöht IT/OT-Konvergenz das Cyberrisiko?
Das kann passieren, wenn Netzwerke dafür abgeflacht werden. Mit Segmentierung, ausschließlich ausgehenden Verbindungen über eine DMZ und Zugangsdaten pro Client verbessert sie Transparenz und Sicherheit in der Regel gegenüber improvisierten Integrationen.
Warum ist MQTT für IT/OT-Konvergenz so beliebt?
Clients verbinden sich ausgehend mit einem Broker, daher sind keine eingehenden Ports ins Werk nötig. Publish/Subscribe ermöglicht zudem, dass viele IT-Konsumenten dieselben OT-Daten ohne zusätzliche Integrationen nutzen.
Wer sollte den Unified Namespace verantworten?
Idealerweise ein gemeinsames Team oder eine Industrial-DataOps-Funktion. Die OT verantwortet, was an der Edge veröffentlicht wird, die IT die Konsumenten, und das gemeinsame Team die Namensregeln und Payload-Standards.
