Von den frühen Anfängen fest verdrahteter Relais und isolierter SPS bis hin zu offenen, interoperablen Architekturen für die intelligente Fertigung hat die Entwicklung industrieller Kommunikationsprotokolle einen tiefgreifenden Wandel durchlaufen. In den ersten Jahrzehnten der Anlagenautomatisierung arbeiteten Regelkreise als digitale Inseln. Steuerungen führten deterministische Logik lokal aus, doch der Austausch von Telemetriedaten über Prozessgrenzen hinweg erforderte eine umfangreiche Punkt-zu-Punkt-Verdrahtung oder kundenspezifische Schnittstellenkarten.

Mit zunehmender Komplexität moderner Prozessindustrien überstieg der betriebliche Bedarf an Echtzeitdiagnosen, systemübergreifender Koordination und unternehmensweiter Transparenz die Möglichkeiten isolierter Feldsteuerungen. Der Wandel hin zu vernetzten Umgebungen bestand nicht lediglich darin, Bits über eine Leitung zu übertragen; er bedeutete eine grundlegende Neugestaltung der Strukturierung, kontextbezogenen Zuordnung und Übertragung industrieller Daten über Feldgeräte, Edge-Controller und Netzwerke für Unternehmensanalysen hinweg.

Die Grundlagen der Anlagennetzwerke: Modbus, frühe SPS und Protokollfragmentierung

Als speicherprogrammierbare Steuerungen Ende der 1960er-Jahre in Produktionsanlagen Einzug hielten, ersetzten sie komplexe Relaisschränke durch softwarebasierte Kontaktplanlogik. Als Anlagen jedoch größer wurden und Dutzende eigenständiger SPS entlang der Verarbeitungslinien eingesetzt wurden, benötigten Ingenieure ein standardisiertes physisches und logisches Medium, über das die Steuerungen interne Register ohne zwischengeschaltete Relaissignalisierung austauschen konnten.

1979 führte Modicon (heute Schneider Electric) den Modbus-Standard ein und veränderte damit die industrielle Kommunikation grundlegend. Modbus wurde auf Grundlage einer Master/Slave- (heute Client/Server-)Architektur entwickelt, die über serielle Schnittstellen wie RS-485 betrieben wird. Das Protokoll war offen und lizenzgebührenfrei und vereinfachte den Datenabruf auf Registerebene. Seine Einfachheit und leichte Implementierbarkeit machten es zu einem allgegenwärtigen Standard – ein Status, den es bis heute an Millionen aktiver Endpunkte behauptet.

Trotz seines historischen Erfolgs weist Modbus strukturelle Engpässe auf, wenn es in datenintensiven Automatisierungsumgebungen eingesetzt wird. Modbus bietet keine native Datentypisierung, keine Kontextmetadaten, keine Zeitstempel und keine Pub/Sub-Funktionen. Um einen Analogwert abzurufen, muss ein Master-Controller bestimmte Holding-Register kontinuierlich abfragen. Als sich Steuerungsnetzwerke auf Tausende von I/O-Punkten ausweiteten, führte das regelmäßige Abfragen zu gravierenden Bandbreitenengpässen und Latenzproblemen.

Um diese Einschränkungen zu überwinden und eine schnelle deterministische Steuerung zu ermöglichen, entwickelten führende Automatisierungsanbieter proprietäre Feldbusarchitekturen und leistungsorientierte Protokollerweiterungen:

• Siemens setzte PROFIBUS (und später PROFINET) ein, um den schnellen zyklischen Austausch von I/O-Daten und komplexen Diagnoseflags über verteilte Feldstationen wie Siemens SIMATIC-Steuerungen zu unterstützen.
• Allen-Bradley / Rockwell Automation führte Data Highway Plus (DH+) und ControlNet ein, die sich schließlich über das Common Industrial Protocol (CIP) zu EtherNet/IP weiterentwickelten.
• Mitsubishi Electric implementierte CC-Link, um eine schnelle deterministische Steuerung über dedizierte, störsichere physikalische Schichten zu ermöglichen.

Obwohl diese Feldbustechnologien eine deterministische Ausführung von Regelkreisen erfolgreich ermöglichten, führten sie zu einer „Herstellerabhängigkeit“. Die Anbindung einer Allen-Bradley-SPS an einen Siemens-Antrieb oder einen Stromzähler eines Drittanbieters erforderte komplexe Protokollkonverter, kundenspezifische Speicherzuordnungen und störanfällige Gateway-Hardware, wodurch die Wartungskosten über den gesamten Lebenszyklus stiegen.

Aufbrechen der Herstellerabhängigkeit: Von OPC Classic zu plattformunabhängigem OPC UA

Die durch die Fragmentierung der Protokolle verursachten betrieblichen Reibungsverluste führten die Automatisierungsbranche zu einheitlichen Abstraktionsebenen. Statt für jede Verbindung zwischen SPS und HMI individuelle Softwaretreiber zu schreiben, benötigten Ingenieure eine standardisierte Übersetzungsschnittstelle.

1996 arbeitete eine Gruppe von Automatisierungsanbietern mit Microsoft zusammen, um den Standard Open Platform Communications (OPC) zu entwickeln, der später als OPC Classic bezeichnet wurde. OPC Classic basierte auf den Microsoft-Technologien OLE, COM und DCOM und etablierte standardisierte Client-Server-Schnittstellen für den Datenzugriff (OPC DA), Alarme und Ereignisse (OPC AE) sowie den Zugriff auf historische Daten (OPC HDA). Ein Automatisierungsanbieter musste lediglich einen OPC-Server für seine Hardware bereitstellen; jede OPC-kompatible HMI- oder SCADA-Software konnte anschließend Daten nahtlos lesen und schreiben.

Die Abhängigkeit von Microsoft DCOM führte jedoch zu spezifischen betrieblichen Herausforderungen, als sich industrielle Netzwerke modernisierten:

• Betriebssystemabhängigkeit: OPC-Classic-Server konnten nur unter Windows-Betriebssystemen ausgeführt werden, wodurch eingebettete Linux-Controller, RTOS-Geräte und Unix-Unternehmensserver ausgeschlossen waren.
• Sicherheitsbeschränkungen: Die DCOM-Konfiguration über Firewalls und Subnetzgrenzen hinweg war bekanntermaßen schwierig und erforderte offene Portbereiche, die gravierende Cybersicherheitslücken verursachten.
• Fehlender semantischer Kontext: Daten wurden hauptsächlich als Rohwerte übertragen, ohne integrierten Kontext, technische Einheiten oder direkt im Übertragungsrahmen eingebettete semantische Metadaten.

Um diese architektonischen Schwachstellen zu beheben, veröffentlichte die OPC Foundation 2008 die OPC Unified Architecture (OPC UA). OPC UA verzichtete auf DCOM zugunsten einer offenen, serviceorientierten Architektur (SOA), die TCP/IP sowie HTTP/HTTPS-Transportschichten verwendet. Entscheidend ist, dass OPC UA plattformunabhängig ist und eine native Integration direkt in Linux-Edge-Gateways, eingebetteten Steuerungen und Cloud-Umgebungen ermöglicht.

Darüber hinaus führte OPC UA ein objektorientiertes Informationsmodell ein. Statt eine isolierte Gleitkommazahl zu übertragen, kapselt OPC UA Daten als komplexe Objekte, die mit technischen Einheiten, oberen und unteren Alarmgrenzwerten, Zeitstempelgenauigkeit und Zugriffsrechten versehen sind. Zusammen mit der integrierten PKI-Verschlüsselung und der Authentifizierung über x509-Zertifikate bildet OPC UA einen Eckpfeiler der sicheren IT/OT-Konvergenz.

DCS-Architekturen, O-PAS und moderne hybride Steuerung

Während SPS-Systeme bei der schnellen diskreten Steuerung hervorragende Leistungen erbringen, stützten sich Prozessindustrien – etwa die petrochemische Raffination, die Energieerzeugung und die Spezialchemie – historisch auf verteilte Leitsysteme (DCS). Ein DCS integriert Steuerungen, I/O-Subsysteme, Historian-Datenbanken und Bedienerarbeitsplätze in eine einheitliche Engineering-Umgebung.

Herkömmliche DCS-Implementierungen gewährleisteten eine hohe Systemzuverlässigkeit und redundante Regelkreise. Diese enge Integration ging jedoch zulasten der Modularität. Proprietäre Controllernetzwerke, geschlossene I/O-Busse und spezialisierte Konfigurationssoftware banden Anlagenbetreiber jahrzehntelang an Ökosysteme einzelner Anbieter. Die Erweiterung eines herkömmlichen DCS oder die Integration spezialisierter Subsysteme von Drittanbietern – etwa zur Online-Überwachung von Maschinenschwingungen – erforderte häufig kostspielige technische Anpassungen.

Abbildung 1. Funktionsebenen eines verteilten Leitsystems (DCS), die traditionelle hierarchische Steuerungsebenen veranschaulichen. Bild mit freundlicher Genehmigung von Wikimedia Commons.

Um dieses Paradigma zu durchbrechen, initiierten große Industriebetreiber unter der Führung von ExxonMobil den Open Process Automation Standard (O-PAS) im Rahmen des OPA-Forums von The Open Group. O-PAS zielt darauf ab, eine offene, hardwareunabhängige Architektur für die Prozessautomatisierung zu schaffen, die durch drei zentrale Säulen definiert ist:

1. Interoperabilität: Standardisierte Kommunikationsbusse (unter Nutzung von OPC UA), die den nativen Datenaustausch zwischen Komponenten verschiedener Hardwarehersteller ohne Entwicklung kundenspezifischer Treiber ermöglichen.
2. Modularität: Entkopplung von Softwareanwendungen und zugrunde liegender Hardware durch containerisierte Microservices und verteilte Steuerknoten (DCNs).
3. Sicherheit: Integrierte Cybersicherheit gemäß den IEC-62443-Normen, die an jeder Gerätegrenze durchgesetzt wird.

Heute setzen moderne Anlagen häufig hybride Architekturen ein. Kritische Prozessanlagen werden von robusten DCS-Plattformen wie DCS-Steuerungssystemen verwaltet, während Zusatzgeräte, Umweltüberwachungssysteme und spezielle Turbomaschinen-Schutzsysteme Anlagenzustandsparameter über offene, standardisierte Protokolle direkt an Edge-Plattformen übertragen.

Ereignisgesteuerte Telemetrie: MQTT und Edge-Netzwerke mit geringer Bandbreite

Als sich die Feldinstrumentierung von einfachen diskreten Sensoren zu komplexen intelligenten Messumformern weiterentwickelte, die Hunderte von Diagnoseparametern melden konnten, wurden die betrieblichen Grenzen herkömmlicher Client-Server-Netzwerke mit Anfrage-/Antwort-Kommunikation deutlich.

1999 entwickelten Andy Stanford-Clark (IBM) und Arlen Nipper (Arcom, heute Cirrus Link) das Message Queuing Telemetry Transport (MQTT), um Bandbreiten- und Latenzbeschränkungen in entfernten SCADA-Anwendungen zu lösen, etwa bei der Überwachung von Öl- und Gaspipelines über Satellitenverbindungen. In diesen Umgebungen erwies sich kontinuierliches Polling über Verbindungen mit hoher Latenz als kostspielig und unzuverlässig.

MQTT löste diese Herausforderungen durch eine ereignisgesteuerte Publish-/Subscribe-(Pub-/Sub-)Architektur mit einem zentralen Message Broker:

• Entkoppelte Kommunikation: Edge-Knoten (Publisher) und Unternehmenssoftware (Subscriber) bauen keine direkten Punkt-zu-Punkt-Verbindungen auf. Sie kommunizieren asynchron über den MQTT-Broker.
• Minimaler Overhead: Mit einem kompakten 2-Byte-Header reduziert MQTT den Bandbreitenbedarf im Vergleich zu HTTP-/REST-APIs oder umfangreichen RPC-Protokollen erheblich.
• Report-by-Exception (RBE): Feldgeräte veröffentlichen Daten nur, wenn sich ein Wert über eine definierte Totzone oder Zustandsschwelle hinaus ändert. Dadurch entfällt unnötiger Polling-Datenverkehr im Netzwerk.
• Zustandsüberwachung: Funktionen wie „Keep-Alive“-Timer und das „Last Will and Testament“ (LWT) ermöglichen es dem Broker, Abonnenten sofort zu benachrichtigen, wenn die Verbindung eines Edge-Geräts plötzlich abbricht.

Abbildung 2. Publish-/Subscribe-Modell in einer MQTT-Netzwerkarchitektur, die Edge-Knoten mit zentralen Anwendungs-Brokern verbindet. Bild mit freundlicher Genehmigung von Wikipedia Commons.

Während reines MQTT einen flexiblen Mechanismus zur Übertragung von Nutzdaten bietet, standardisiert es weder den Aufbau von Topics noch die Formatierung von Nutzdaten. Um dieses Problem zu lösen, entwickelte die industrielle Gemeinschaft die Spezifikation Sparkplug B. Sparkplug B definiert einen standardisierten Topic-Namensraum, eine kompakte Google-Protocol-Buffer-(Protobuf)-Nutzdatenstruktur und Mechanismen zur Zustandsverwaltung und macht aus dem reinen MQTT eine industrietaugliche Transportschicht für Unternehmen.

Das moderne industrielle Paradigma: Unified Namespace (UNS)-Architektur

Die Ansammlung von Legacy-Polling-Protokollen, isolierten OPC-Servern und Punkt-zu-Punkt-API-Verbindungen führt häufig zu einer komplexen „Spaghetti-Architektur“. In dieser Umgebung erfordert das Hinzufügen eines einzigen neuen Analysetools den Aufbau individueller Verbindungen zu jedem SCADA-Knoten, Historian und jeder MES-Datenbank in der gesamten Anlage.

Um diese Integrationsengpässe zu beseitigen, implementieren moderne Automatisierungsingenieure die Architektur des Unified Namespace (UNS). Ein Unified Namespace fungiert als zentrale Echtzeit-Softwareabstraktionsschicht und dient als „Single Source of Truth“ für alle Betriebs- und Geschäftsdaten innerhalb eines Unternehmens.

Abbildung 3. Unified-Namespace-Struktur zur Orchestrierung des Echtzeitdatenflusses über alle ISA-95-Unternehmensebenen. Bild mit freundlicher Genehmigung von Wikipedia Commons.

Auf einem Publish/Subscribe-Modell basierend – typischerweise implementiert mit MQTT Sparkplug B oder Event-Streaming-Plattformen – strukturiert ein UNS Daten semantisch gemäß standardisierten physischen Hierarchien (wie ISA-95):

Enterprise / Standort / Bereich / Linie / Zelle / Anlage

In einem vollständig umgesetzten UNS-Framework:

• Eine Feld-SPS veröffentlicht den Motorstatus direkt an Enterprise/Plant_A/Line_2/Mixer/Motor_Speed bei einer Zustandsänderung.
• Das SCADA-System abonniert die Topic-Struktur, um Echtzeitgrafiken für Bediener darzustellen.
• Das Enterprise-Asset-Management-System (EAM) empfängt denselben Topic-Datenstrom, um Betriebsstunden zu erfassen und vorbeugende Wartungen automatisch zu planen.
• Cloudbasierte Machine-Learning-Modelle übernehmen den vereinheitlichten Datenstrom, um prädiktive Anomalieerkennung durchzuführen, ohne zusätzliche Polling-Anfragen an die Feldsteuerung zu stellen.

Durch die Entkopplung von Datenproduzenten und Datenkonsumenten mittels eines UNS können Industrieunternehmen Softwaretools und Edge-Sensoren hinzufügen, ändern oder skalieren, ohne bestehende Regelkreise neu entwickeln zu müssen.

Protokollmatrix und technischer Vergleich auf Feldebene

Die Auswahl der optimalen Protokollstrategie erfordert ein Verständnis der technischen Leistungsmerkmale, des Payload-Overheads und der Zielanwendungen jeder Netzwerkschicht im gesamten betrieblichen Ökosystem:

Entwicklung einer praxisnahen Architektur: Modernisierung älterer Anlagenabläufe

Die Migration einer laufenden Brownfield-Fertigungsanlage von älteren Polling-Netzwerken zu einer offenen, ereignisgesteuerten Architektur erfordert einen phasenweisen technischen Ansatz statt einer vollständigen Systemüberholung.

Betrachten wir eine typische Anlage für kontinuierliche Prozesse, in der ältere PLC-5- oder frühe ControlLogix-Systeme parallel zu eigenständiger Schutzhardware für rotierende Maschinen betrieben werden. Der Versuch, sämtliche Legacy-Hardware gleichzeitig zu ersetzen, führt zu unvertretbaren Risiken durch Ausfallzeiten und hohen Investitionskosten. Eine strukturierte Modernisierungs-Roadmap in drei Phasen bietet einen praktikablen Weg nach vorn:

1. Phase 1: Edge-Protokollübersetzungsschicht
   Installieren Sie industrielle Edge-Gateways neben den Racks der Legacy-SPSen. Das Edge-Gateway fragt lokale Halteregister über serielle oder ältere Feldbusprotokolle ab und wandelt Rohwerte in strukturierte OPC-UA-Knoten oder MQTT-Sparkplug-B-Topics um.
2. Phase 2: Bereitstellung des Brokers und Strukturierung der UNS
   Implementieren Sie einen hochverfügbaren, redundanten MQTT-Broker vor Ort. Definieren Sie einen einheitlichen ISA-95-Topic-Namensraum für die gesamte Produktionsebene. Leiten Sie Telemetriedaten der Edge-Gateways an den Broker weiter und ermöglichen Sie so sofort die Echtzeit-Überwachung von Anlagen, ohne die zugrunde liegenden SPS-Zykluszeiten oder die Steuerungslogik zu verändern.
3. Phase 3: Integration fortschrittlicher Analysen und hybrider Steuerung
   Verbinden Sie Enterprise-Historian-Systeme, Cloud-Analyse-Engines und moderne HMI-Systeme direkt als Abonnenten mit der UNS. Wenn Legacy-Controller das Ende ihrer Lebensdauer erreichen, ersetzen Sie sie durch moderne PACs mit offener Architektur, die nativ für OPC-UA- und MQTT-Umgebungen ausgelegt sind.

Mit dieser modularen Strategie schützen Industrieanlagen bestehende Kapitalinvestitionen in Feldhardware und gewinnen zugleich die Datenflexibilität, Cybersicherheitskonformität und Skalierbarkeit, die für moderne Industrie-4.0-Betriebe erforderlich sind.