Entwicklung industrieller Kommunikationsprotokolle: Von Modbus zu UNS & O-PAS

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 wie digitale Inseln. Steuerungen führten deterministische Logik lokal aus, doch der Austausch von Telemetriedaten über Prozessgrenzen hinweg erforderte 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 Übergang zu vernetzten Umgebungen bestand nicht nur darin, Bits über eine Leitung zu übertragen; er stellt eine grundlegende Neugestaltung der Strukturierung, kontextbezogenen Zuordnung und Übertragung industrieller Daten über Feldgeräte, Edge-Controller und Netzwerke für Unternehmensanalysen hinweg dar.

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

Als speicherprogrammierbare Steuerungen Ende der 1960er-Jahre in Fertigungsanlagen Einzug hielten, ersetzten sie komplexe Relaisschränke durch softwarebasierte Kontaktplanlogik. Als Anlagen jedoch wuchsen und Dutzende unabhängiger SPS über Prozesslinien hinweg eingesetzt wurden, benötigten Ingenieure ein standardisiertes physisches und logisches Medium, über das 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 einer Master/Slave- (heute Client/Server-)Architektur entwickelt, die über serielle Schnittstellen wie RS-485 betrieben wird, und bot ein offenes, lizenzfreies Protokoll, das den Datenabruf auf Registerebene vereinfachte. Seine Einfachheit und leichte Implementierung machten es zu einem allgegenwärtigen Standard – ein Status, den es bis heute an Millionen aktiver Endpunkte besitzt.

Trotz seines historischen Erfolgs weist Modbus strukturelle Engpässe auf, wenn es in datenintensiven Automatisierungsumgebungen eingesetzt wird. Modbus verfügt weder über eine native Datentypisierung noch über Kontextmetadaten, Zeitstempel oder Pub/Sub-Funktionen. Um einen analogen Wert abzurufen, muss ein Master-Controller bestimmte Holding-Register kontinuierlich abfragen. Als sich Steuerungsnetzwerke auf Tausende von I/O-Punkten ausweiteten, führte das routinemäßige Abfragen zu einer erheblichen Überlastung der Bandbreite und zu Latenzproblemen.

Um diese Einschränkungen zu überwinden und eine deterministische Hochgeschwindigkeitssteuerung zu ermöglichen, entwickelten große Automatisierungsanbieter proprietäre Feldbusarchitekturen und leistungsorientierte Protokollerweiterungen:

• Siemens setzte PROFIBUS (und später PROFINET) ein, um den schnellen zyklischen Austausch von E/A-Daten und komplexen Diagnoseflags zwischen verteilten Feldstationen wie Siemens-SIMATIC-Controllern 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 „Herstellerbindung“. Die Anbindung einer Allen-Bradley-SPS an einen Siemens-Antrieb oder einen Energiezähler eines Drittanbieters erforderte komplexe Protokollkonverter, individuelle Speicherzuordnungen und störanfällige Gateway-Hardware, wodurch die Wartungskosten über den gesamten Lebenszyklus stiegen.

Aufbrechen der Herstellerbindung: Von OPC Classic zu plattformunabhängigem OPC UA

Die durch die Fragmentierung der Protokolle verursachten betrieblichen Reibungsverluste führten die Automatisierungsbranche zu einheitlichen Abstraktionsebenen. Anstatt 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 Technologien OLE, COM und DCOM von Microsoft 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 besonderen 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 wurden.
• Sicherheitsbeschränkungen: Die Konfiguration von DCOM über Firewalls und Subnetzgrenzen hinweg war bekanntermaßen schwierig und erforderte offene Portbereiche, die erhebliche Cybersicherheitsrisiken mit sich brachten.
• 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 verabschiedete sich von DCOM zugunsten einer offenen, serviceorientierten Architektur (SOA), die TCP/IP- und HTTP/HTTPS-Transportschichten verwendet. Entscheidend ist, dass OPC UA plattformunabhängig ist und eine native Integration direkt in Linux-Edge-Gateways, eingebettete Controller 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 bei der schnellen Ablaufsteuerung brillieren, verließen sich Prozessindustrien – etwa die petrochemische Raffination, die Stromerzeugung und die Herstellung von Spezialchemikalien – traditionell auf Distributed Control Systems (DCS). Ein DCS integriert Controller, 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 Controller-Netzwerke, 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 Distributed Control Systems (DCS), die traditionelle hierarchische Steuerungsebenen veranschaulichen. Bild mit freundlicher Genehmigung von Wikimedia Commons.

Um dieses Paradigma zu durchbrechen, initiierten große Industrieunternehmen 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 wird:

1. Interoperabilität: Standardisierte Kommunikationsbusse (unter Nutzung von OPC UA), die es Komponenten verschiedener Hardwarehersteller ermöglichen, Daten ohne die Entwicklung kundenspezifischer Treiber nativ auszutauschen.
2. Modularität: Entkopplung von Softwareanwendungen und zugrunde liegender Hardware durch containerisierte Microservices und verteilte Steuerungsknoten (DCNs).
3. Sicherheit: Integrierte Cybersicherheit gemäß den IEC-62443-Standards, 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 Hilfsanlagen, Umweltüberwachungsgeräte und spezielle Schutzsysteme für Turbomaschinen Zustandsparameter direkt über offene, standardisierte Protokolle an Edge-Plattformen übertragen.

Ereignisgesteuerte Telemetrie: MQTT und Edge-Netzwerke mit geringer Bandbreite

Mit der Weiterentwicklung der Feldinstrumentierung von einfachen diskreten Sensoren zu komplexen intelligenten Messumformern, die Hunderte von Diagnoseparametern melden können, 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) speziell zur Lösung von Bandbreiten- und Latenzproblemen in entfernten SCADA-Anwendungen, 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 Bandbreitenverbrauch 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 ein festgelegtes Totband oder einen Zustandsschwellenwert hinaus ändert, wodurch unnötiger Polling-Datenverkehr im Netzwerk entfällt.
• Zustandsbewusstsein: Funktionen wie „Keep-Alive“-Timer und „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 Anwendungsbrokern verbindet. Bild mit freundlicher Genehmigung von Wikimedia Commons.

Während reines MQTT einen flexiblen Mechanismus für den Transport von Nutzdaten bietet, standardisiert es weder den Aufbau von Topics noch die Formatierung von Nutzdaten. Um dieses Problem zu lösen, entwickelte die Industrie die Spezifikation Sparkplug B. Sparkplug B definiert einen standardisierten Topic-Namespace, eine kompakte Google-Protocol-Buffer-(Protobuf)-Nutzdatenstruktur und Mechanismen zur Zustandsverwaltung und verwandelt dadurch rohes MQTT in eine industrietaugliche Transportschicht für Unternehmen.

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

Die Ansammlung veralteter Polling-Protokolle, isolierter OPC-Server und Punkt-zu-Punkt-API-Verbindungen führt häufig zu einer komplexen „Spaghetti-Architektur“. In diesem Umfeld erfordert das Hinzufügen eines einzigen neuen Analysetools individuelle 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 Softwareabstraktionsschicht in Echtzeit, die als „Single Source of Truth“ für alle Betriebs- und Geschäftsdaten innerhalb eines Unternehmens dient.

Abbildung 3. Unified-Namespace-Struktur zur Orchestrierung des Echtzeitdatenflusses über alle ISA-95-Ebenen eines Unternehmens. Bild mit freundlicher Genehmigung von Wikimedia Commons.

Auf einem Publish-/Subscribe-Modell basierend – typischerweise mit MQTT Sparkplug B oder Event-Streaming-Plattformen implementiert – strukturiert ein UNS Daten semantisch anhand standardisierter physischer Hierarchien (wie ISA-95):

Unternehmen / Standort / Bereich / Linie / Zelle / Anlage

In einem vollständig realisierten UNS-Framework:

• Eine Feld-SPS veröffentlicht den Motorstatus direkt auf 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 die vorbeugende Wartung automatisch zu planen.
• Cloudbasierte Machine-Learning-Modelle nehmen den vereinheitlichten Datenstrom auf, um eine prädiktive Anomalieerkennung auszufü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 Protokoll-Overheads und der Zielanwendungen jeder Netzwerkebene im gesamten Betriebsumfeld:

Protokoll	Architektur	Transportschicht	Datennutzlast & Kontext	Primärer Anwendungsbereich
Modbus RTU/TCP	Client/Server (Polling)	RS-485 / TCP/IP	Rohe 16-Bit-Register, keine Metadaten	Ältere Geräte, Energiezähler, einfache Sensornetzwerke
PROFINET / EtherNet/IP	Zyklisches Producer/Consumer-Verfahren	Ethernet / kundenspezifische physische Schicht	Deterministische I/O-Frames, Diagnose auf Geräteebene	Hochgeschwindigkeits-Diskretsteuerung, Bewegungssteuerung, Feld-I/O
OPC UA	Client/Server & Publish/Subscribe	TCP/IP, HTTP/HTTPS, WebSockets	Umfangreiche Objektmodelle, Metadaten, Verschlüsselungszertifikate	SPS-zu-SCADA, Kommunikation zwischen Steuerungen, IT/OT-Bridging
MQTT / Sparkplug B	Publish/Subscribe über zentralen Broker	TCP/IP, TLS (leichtgewichtig)	Übertragung bei Ausnahme, Protobuf-Nutzlast mit semantischen Topics	UNS-Architektur, IIoT-Edge-Sensoren, Cloud-Telemetrieanalysen

Engineering einer Architektur aus der Praxis: Modernisierung älterer Betriebsabläufe in Produktionsanlagen

Die Migration einer in Betrieb befindlichen Brownfield-Produktionsanlage von älteren Polling-Netzwerken zu einer offenen, ereignisgesteuerten Architektur erfordert einen phasenweisen Engineering-Ansatz statt einer vollständigen Systemüberholung.

Betrachten Sie eine typische Anlage zur kontinuierlichen Prozessverarbeitung, in der ältere PLC-5- oder frühe ControlLogix-Systeme neben eigenständiger Schutzhardware für rotierende Maschinen betrieben werden. Der Versuch, sämtliche ältere Hardware gleichzeitig zu ersetzen, birgt inakzeptable Risiken durch Ausfallzeiten und Kapitalkosten. 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 älteren SPS. Das Edge-Gateway liest lokale Halteregister über serielle oder ältere Feldbusprotokolle aus und konvertiert Rohwerte in strukturierte OPC-UA-Knoten oder MQTT-Sparkplug-B-Topics.
2. Phase 2: Bereitstellung des Brokers und Strukturierung des UNS
   Stellen Sie einen hochverfügbaren, redundanten MQTT-Broker vor Ort bereit. Definieren Sie einen einheitlichen ISA-95-Topic-Namensraum für die gesamte Produktionsfläche. Leiten Sie die Telemetriedaten der Edge-Gateways in den Broker, um sofort eine Echtzeittransparenz über Anlagen zu ermöglichen, ohne die zugrunde liegenden SPS-Zykluszeiten oder die Steuerungslogik zu verändern.
3. Phase 3: Integration fortschrittlicher Analysen und hybrider Steuerung
   Verbinden Sie unternehmensweite Historian-Systeme, Cloud-Analyse-Engines und moderne HMI-Systeme direkt als Abonnenten mit dem UNS. Wenn ältere Steuerungen 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.

Durch diese modulare 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-Abläufe erforderlich sind.