Echtzeit-PLC-Daten-Streaming OPC-UA Modbus und moderne Integrationsmuster

Einführung

Live-Daten von einer Speicherprogrammierbaren Steuerung (SPS, englisch: Programmable Logic Controller, PLC) abzurufen klingt einfach – bis man es tun muss, ohne die Steuerung zu verlangsamen oder ein Loch ins Netzwerk zu reißen. Zwei Protokolle dominieren diese Entscheidung: OPC-UA und Modbus. Dieser Beitrag beschreibt die Integrationsmuster für das Streaming von PLC-Echtzeitdaten über beide Protokolle, die Rolle von MQTT und Sparkplug als Brückenschicht, die Argumente für Edge-Integration sowie die Sicherheitseigenschaften, die jede Wahl mit sich bringt. Er richtet sich an IT-Sicherheitsexperten, Compliance-Beauftragte und Verteidigungsauftragnehmer, die diese Entscheidungen treffen und anschließend in einem Audit vertreten müssen.

Wesentliche Erkenntnisse

• Die eigentliche Einschränkung ist die Steuerung. Das Ziel ist, PLC-Daten in der benötigten Frequenz und mit der erforderlichen Sicherheit zu streamen, ohne dem deterministischen Steuerungsablauf Rechenzyklen zu entziehen.
• OPC-UA ist der sichere, moderne Standard. Authentifizierung, Autorisierung und Verschlüsselung sind in der Spezifikation verankert, und Subscriptions übertragen Änderungen aktiv. Für Neuinstallationen ist OPC-UA die erste Wahl.
• Modbus ist allgegenwärtig, aber unsicher. In seiner Grundform bietet es weder Authentifizierung, noch Autorisierung oder Verschlüsselung, und kein natives Publish-Modell – „Streaming" bedeutet hier Polling. Absichern durch Netzwerkkontrollen ist Pflicht.
• MQTT und Sparkplug schließen die Lücke. Ein Broker verteilt Daten von einem Gateway an viele Empfänger; Sparkplug fügt die Struktur hinzu, die rohes MQTT in eine kohärente OT-Datenschicht verwandelt.

PLCs in der industriellen Automatisierung verstehen

Bevor man sich mit Integrationsmustern befasst, ist es hilfreich, genau zu verstehen, was eine PLC tatsächlich bereitstellt. Eine PLC hält den Prozesszustand in einem Register- oder Adressraum: Coils, diskrete Eingänge, Halteregister und Eingangsregister im Modbus-Modell, oder einen typenreichen Adressraum aus Knoten im OPC-UA-Modell. PLC-Daten in Echtzeit zu streamen bedeutet, die Werte in diesem Adressraum von der Steuerung in ein System zu übertragen, das sie speichern, analysieren oder darauf reagieren kann – ohne den deterministischen Steuerungsablauf zu stören, für den die PLC eigentlich da ist.

Genau dieser letzte Punkt ist das eigentliche Problem. PLCs sind die Arbeitspferde der Automatisierung in Fertigung, Energie, Wasser und Verteidigungszulieferketten – und sie wurden für deterministische Steuerung entwickelt, nicht dafür, einen hochvolumigen Telemetrie-Feed zu bedienen. Wird eine Steuerung zu stark belastet, werden dem Steuerungstask Rechenzyklen entzogen. Die Frage lautet daher nie einfach „Wie bekomme ich die Daten heraus?", sondern: „Wie bekomme ich die Daten in der benötigten Frequenz und mit der erforderlichen Sicherheit heraus, ohne die Steuerung zu beeinträchtigen?"

Die Bedeutung von Echtzeitdaten

Echtzeit-Datenstreaming von PLCs ermöglicht es Organisationen, Prozesse live zu überwachen, Entscheidungen zu verbessern und vorausschauende Wartung auf Basis aktueller Signale statt nachträglicher Berichte durchzuführen. Genaue, zeitnahe Daten wirken sich messbar auf Produktionseffizienz, Qualitätskontrolle und Anlagenlebensdauer aus. „Echtzeit" ist jedoch kein einheitlicher Begriff. Ein Vibrationssignal für die Lageranalyse kann eine Abtastrate im Bereich von Zehntelmillisekunden erfordern, während ein täglicher Energieverbrauch einmal pro Minute abgefragt werden kann, ohne dass es jemandem auffällt. Das Streaming-Muster an die tatsächliche Latenzanforderung anzupassen ist das, was eine tragfähige Architektur von einer unterscheidet, die die Steuerung still und leise überlastet.

OPC-UA: Eine sichere und skalierbare Lösung

OPC-UA (Open Platform Communications Unified Architecture) ist eine plattformunabhängige, serviceorientierte Architektur für den zuverlässigen und sicheren Datenaustausch in heterogenen industriellen Systemen. Es ist als mehrteilige IEC-62541-Reihe standardisiert und wird von der OPC Foundation gepflegt, deren veröffentlichte Spezifikationen sowohl das Informationsmodell als auch die Kommunikationsmechanik definieren. Robustheit und Flexibilität machen OPC-UA zum modernen Standard für Echtzeit-PLC-Datenstreaming.

Zwei Wege, wie OPC-UA Daten überträgt

OPC-UA bietet zwei grundlegend verschiedene Transportmuster – sie zu verwechseln ist ein häufiger Architekturirrtum.

• Client/Server mit Subscriptions. Ein Client baut eine Session mit dem Server auf, erstellt eine Subscription und registriert überwachte Elemente. Der Server überträgt dann Datenänderungsbenachrichtigungen nur dann, wenn ein überwachter Wert eine konfigurierte Totzone überschreitet – in einem von Ihnen festgelegten Abtastintervall. Das ist Request/Response beim Aufbau, aber ereignisgesteuert zur Laufzeit, was deutlich effizienter als naives Polling ist, da ruhige Tags keinen Traffic erzeugen.
• OPC-UA Pub/Sub. Definiert in OPC UA Part 14: PubSub, entkoppelt dieses Muster Publisher und Subscriber vollständig. Ein Publisher sendet Dataset-Nachrichten auf einen Transport – entweder einen broker-basierten Transport wie MQTT oder AMQP, oder einen brokerlosen UDP-Multicast-Transport für latenzarme Many-to-Many-Verteilung im lokalen Netzwerk. Keine Session, kein verbindungsspezifischer Zustand pro Subscriber auf der Steuerung. Pub/Sub macht OPC-UA im Flottenmaßstab praktikabel und ist die natürliche Wahl, wenn dieselben Daten gleichzeitig an Historians, Analysesysteme und einen MQTT-Broker verteilt werden sollen.

Die praktische Regel: Client/Server-Subscriptions eignen sich für eine kleine Anzahl von Empfängern, die eine verwaltete Session und bestätigte Zustellung benötigen. Pub/Sub ist die Wahl, wenn Fan-out skaliert werden muss, ein Broker überquert wird oder harte Latenzanforderungen auf der Leitung gelten.

Wesentliche Merkmale von OPC-UA

• Plattformunabhängigkeit. OPC-UA läuft auf verschiedenen Hardware-Plattformen und Betriebssystemen und verhindert so eine Bindung an einen einzelnen Hersteller-Stack.
• Sicherheit als erstklassiges Merkmal. Das Sicherheitsmodell ist in OPC UA Part 2: Security Model beschrieben und umfasst Authentifizierung, Autorisierung, Signierung und Verschlüsselung auf Nachrichten- und Kanalebene. Ein gesicherter Kanal (Sign oder SignAndEncrypt) mit zertifikatsbasierter gegenseitiger Authentifizierung ist genau die Haltung, die NIST SP 800-171 für den Schutz von Controlled Unclassified Information (CUI) erwartet.
• Reichhaltiges, typisiertes Informationsmodell. Über reine Werte hinaus überträgt OPC-UA Datentypen, Beziehungen und Metadaten, sodass ein Empfänger die Bedeutung eines Tags selbst ermitteln kann, anstatt auf eine externe Tabelle angewiesen zu sein.

OPC-UA für PLCs implementieren

1. Kompatibilität prüfen. Stellen Sie sicher, dass Ihre PLCs einen OPC-UA-Server bereitstellen, oder schalten Sie einen vor. Viele moderne PLCs liefern einen integrierten OPC-UA-Server mit, ältere Baureihen benötigen jedoch oft ein Gateway.
2. Kanal standardmäßig absichern. Anonymen Zugriff deaktivieren, zertifikatsbasierte Authentifizierung vorschreiben und SignAndEncrypt aktivieren. Ein OPC-UA-Server, der im Netzwerk erreichbar ist und Sicherheit deaktiviert hat, gehört zu den häufigsten und schwerwiegendsten Befunden in OT-Assessments.
3. Empfängermuster im Voraus festlegen. Entscheiden Sie sich vorab für Subscriptions oder Pub/Sub, denn eine nachträgliche Umstellung berührt die gesamte nachgelagerte Pipeline.
4. Adressraum planen. Eine saubere, gut benannte Knotenhierarchie zahlt sich jedes Mal aus, wenn jemand Neues den Feed konsumieren muss.

Modbus: Einfachheit trifft Allgegenwart

Modbus ist eines der ältesten und am weitesten verbreiteten Kommunikationsprotokolle in der industriellen Automatisierung. Als offene Spezifikation von der Modbus Organization veröffentlicht und gepflegt, hat seine Einfachheit es zu einer nahezu universellen Gemeinsprache für die Geräteanbindung – einschließlich PLCs – gemacht.

Wie Modbus-Streaming tatsächlich funktioniert

Modbus hat keinen nativen Publish-Mechanismus. Es gibt kein „Register abonnieren und Callback erhalten." Modbus-Daten zu streamen bedeutet Polling: Ein Client sendet wiederholt Leseanfragen (Read Holding Registers, Read Input Registers) an einen Server, in einem selbst festgelegten Intervall. Alles am Echtzeit-Verhalten von Modbus ergibt sich aus dieser Tatsache.

• Die Polling-Frequenz ist Ihr Stellrad. Schnelleres Polling liefert frischere Daten, aber jeder Poll kostet eine Transaktion auf der Leitung und eine Antwort der Steuerung. Bei Modbus RTU über serielle Verbindungen setzen Roundtrip-Zeit und Bus-Kollisionen eine harte Obergrenze für die erreichbare Geschwindigkeit.
• Lesevorgänge bündeln. Das Lesen eines zusammenhängenden Registerblocks in einer einzigen Anfrage ist deutlich effizienter als viele Einzelregister-Lesevorgänge. Zusammengehörige Werte in benachbarten Registern anzuordnen ist ein echter Leistungshebel.
• Veraltete und zerrissene Lesevorgänge beachten. Mehrregister-Werte, die sich zwischen zwei Polls ändern, können mitten in einer Änderung gelesen werden. Wo das relevant ist, sollten die Mechanismen der Steuerung genutzt werden, um konsistente Snapshots bereitzustellen.

Vorteile von Modbus

• Einfachheit. Minimale Konfiguration, einfach zu implementieren, jedem Integrator vertraut.
• Interoperabilität. Funktioniert mit einer enormen Bandbreite an Geräten und Herstellern.
• Kosten. Offen und lizenzgebührenfrei, was die Implementierungskosten niedrig hält.

Modbus für Echtzeitdaten integrieren

1. Protokollauswahl. Wählen Sie Modbus RTU für serielle Verbindungen und Modbus TCP für Ethernet-Netzwerke entsprechend Ihrer Infrastruktur.
2. Netzwerkdesign. Latenz minimieren und Zuverlässigkeit maximieren – beides begrenzt direkt, wie „echtzeit" Ihr Stream sein kann.
3. Sicherheitsmaßnahmen. Modbus bietet in seiner Grundform weder Authentifizierung, noch Autorisierung oder Verschlüsselung. Die eigene Sicherheitsspezifikation der Modbus Organization ergänzt eine TLS-geschützte Variante, aber die meisten installierten Geräte stammen aus der Zeit davor. Behandeln Sie einfaches Modbus auf der Leitung als grundsätzlich nicht vertrauenswürdig und kompensieren Sie dies durch Netzwerkkontrollen – zu demselben Schluss kommt NIST für Legacy-Feldprotokolle.

MQTT und Sparkplug: Die Brückenschicht

Weder OPC-UA-Subscriptions noch Modbus-Polling lösen das Problem, Daten von vielen Steuerungen an viele Empfänger über eine Anlage oder ein WAN zu übertragen, ohne eine Explosion von Punkt-zu-Punkt-Verbindungen zu erzeugen. Hier verdient ein leichtgewichtiger Publish/Subscribe-Broker seinen Platz.

MQTT ist ein Publish/Subscribe-Nachrichtenprotokoll, das für eingeschränkte Netzwerke und unzuverlässige Verbindungen entwickelt wurde. Ein Gateway liest von der PLC (über OPC-UA oder durch Modbus-Polling) und publiziert die Werte an einen MQTT-Broker. Beliebig viele Empfänger abonnieren die Topics, die sie benötigen. Dieses Report-by-Exception-Muster mit Broker-Vermittlung passt gut zu OT-Netzwerken: Die Steuerung kommuniziert mit einem lokalen Gateway, das Gateway hält eine ausgehende Verbindung zum Broker, und der Broker übernimmt den Fan-out. Dieser Broker ist auch der Angriffspunkt: Ein Standard-MQTT-Broker wird ohne Authentifizierung, Verschlüsselung oder Topic-Zugriffssteuerung ausgeliefert – seine Absicherung ist daher genauso wichtig wie seine Inbetriebnahme. Siehe Configure MQTT flows für die Absicherung mit Identität und TLS.

Sparkplug ist eine offene Spezifikation unter der Verwaltung der Eclipse Foundation, die dem rohen MQTT Struktur verleiht. Einfaches MQTT macht keine Vorgaben zu Payload-Format oder Gerätelebenszyklus, sodass jede Integration beides neu erfinden muss. Sparkplug standardisiert den Topic-Namensraum, definiert einen typisierten Payload und fügt Birth- und Death-Zertifikate hinzu, damit Empfänger jederzeit wissen, ob ein Gerät online ist und welchen aktuellen Zustand es hat. Für industrielle Telemetrie verwandelt Sparkplug MQTT von einem generischen Nachrichtenbus in eine kohärente OT-Datenschicht. Die Kombination von OPC-UA am Controller-Edge mit einer MQTT/Sparkplug-Brücke für den Transport ist heute eines der bewährtesten Muster in der Praxis.

Edge-Integration

Integrations­logik an den Edge zu verlagern – auf ein Gateway oder einen Industrie-PC direkt neben den Steuerungen – verändert die Wirtschaftlichkeit des Streamings grundlegend.

• Lokal zuerst. Der Edge-Knoten pollt Modbus oder abonniert über OPC-UA im lokalen Segment, wo die Latenz gering und die Verbindung vertrauenswürdig ist, und leitet dann einen aufbereiteten Stream nach oben weiter.
• Filtern und aggregieren vor dem Transport. Totband-Filterung, Downsampling und Aggregation am Edge reduzieren WAN-Bandbreite und Cloud-Ingest-Kosten und verringern den Schadensradius eines falsch konfigurierten Empfängers, der eine Steuerung überlastet.
• Verbindungsausfälle überstehen. Ein gutes Edge-Gateway puffert lokal und leitet bei Wiederverbindung weiter, sodass ein WAN-Ausfall keine Lücke im historischen Datensatz hinterlässt.
• Die Grenze durchsetzen. Der Edge ist der natürliche Ort, um anlagenseitige Protokolle zu terminieren und einen gesicherten, authentifizierten Stream weiterzusenden – so bleiben unsichere Feldprotokolle vollständig aus dem weiteren Netzwerk heraus.

Moderne Integrationsmuster

Hybride Protokollstrategie

Die Kombination von OPC-UA und Modbus ermöglicht es, jedes Protokoll dort einzusetzen, wo es passt: OPC-UA für sichere, typisierte, komplexe Austausche und Modbus-Polling für einfache, hochfrequente Werte von Geräten, die nichts anderes sprechen. Ein Gateway, das beide Protokolle in einen einzigen MQTT/Sparkplug-Feed normalisiert, gibt nachgelagerten Systemen eine einheitliche Schnittstelle – unabhängig davon, was das Feldgerät tatsächlich spricht.

Cloud-Integration

PLC-Daten in Cloud-Plattformen zu streamen erschließt erweiterte Analysen und skalierbare Speicherung. Der Grenzübergang ist der sensible Teil. Anlagenprotokolle am Edge terminieren, Daten nur über authentifizierte, verschlüsselte Kanäle übertragen und sicherstellen, dass Cloud-Integrationen mit CMMC- und NIS2-Verpflichtungen im Einklang bleiben, wenn CUI im Scope ist.

Sicherheitsimplikationen

Das gewählte Streaming-Muster ist eine Sicherheitsentscheidung, nicht nur eine Architekturentscheidung.

• Protokollinhärentes Risiko. OPC-UA kann authentifizieren und verschlüsseln; Modbus in seiner Grundform kann beides nicht. Alles, was über einfaches Modbus gestreamt wird, ist für jeden im Segment lesbar und fälschbar.
• Defense in Depth statt Protokoll-Nachrüstung. NIST SP 800-82, Guide to Operational Technology Security, stellt ausdrücklich fest, dass OT-Umgebungen auf geschichtete Kontrollen, Netzwerksegmentierung und strikte Zugriffsgrenzen setzen sollten, anstatt davon auszugehen, dass das Feldprotokoll sich selbst schützt. Diese Vorgabe gilt direkt für das Streaming: OT-Netzwerk segmentieren, jeden abgehenden Datenfluss absichern und an der Grenze überwachen.
• Datenflussprinzip der minimalen Rechte. Ein Streaming-Empfänger benötigt selten Schreibzugriff. Nur-Lese-Pfade, die am Gateway erzwungen werden, eliminieren eine ganze Angriffskategorie, bei der ein kompromittierter Analyse-Empfänger Steuerbefehle zurück an eine PLC sendet.
• Sichtbarkeit. Protokollbewusstes Monitoring am Gateway verwandelt die Streaming-Grenze in einen Sensor, der unerwartete Lesevorgänge, fehlerhafte Frames oder Verbindungsversuche aufdeckt, die niemals stattfinden sollten.

Herausforderungen und Überlegungen

Legacy-Systeme

Viele Umgebungen betreiben noch Steuerungen, die ausschließlich Legacy-Protokolle sprechen. Protokoll-Gateways binden diese in moderne Architekturen ein und dienen, richtig umgesetzt, gleichzeitig als Sicherheitsgrenze, die das alte Protokoll aus dem weiteren Netzwerk heraushält.

Compliance und Sicherheit

Die Ausrichtung an NIST 800-171, NIST SP 800-82, CMMC und NIS2 ist in regulierten Umgebungen nicht optional. Regelmäßige Audits und Sicherheitsassessments halten die Compliance aufrecht und decken Schwachstellen auf, bevor ein Prüfer es tut.

Interoperabilität

Nahtlose Interoperabilität über Geräte und Hersteller hinweg erfordert nach wie vor echte Tests. Den vollständigen Pfad – Steuerung, Gateway, Broker, Empfänger – während der Integration validieren, statt die Lücken erst im Produktivbetrieb zu entdecken.

Fazit

Beim Echtzeit-Streaming von PLC-Daten bestimmt die Protokollwahl die Sicherheitslage. OPC-UA bietet Verschlüsselung, Authentifizierung und die Wahl zwischen verwalteten Subscriptions und skalierbarem Pub/Sub; Modbus bietet weder Sicherheit noch ein natives Streaming-Modell, nur Polling. Das robusteste Muster in der Praxis liest von der Steuerung über ein gesichertes Protokoll, normalisiert über ein Edge-Gateway und transportiert über MQTT mit Sparkplug für Struktur – bei segmentierter und abgesicherter OT-Grenze gemäß NIST SP 800-82. Für neue Integrationen: OPC-UA mit aktivierter Sicherheit als Standard wählen. Für bestehende Modbus-Installationen: Sicherheit auf Netzwerkebene ergänzen, anstatt ein Protokoll nachzurüsten, das nie dafür ausgelegt war, sich selbst zu schützen.