OPC UA vs Modbus: Welches Protokoll passt 2026 in Ihre Anlagenmodernisierung?

Der fundamentale Unterschied zwischen beiden Protokollen liegt nicht in der Bandbreite oder der Latenz, sondern in der Semantik. OPC UA bringt einen vollständigen Adressraum (Address Space) mit: jeder Datenpunkt ist ein typisierter Node mit eindeutiger NodeId (Namespace-Index plus Identifier), Referenzen zu Parent- und Child-Nodes, Datentyp, Engineering Units, Genauigkeit, Historisierungsflag und beliebigen weiteren Attributen. Ein OPC-UA-Client, der zum ersten Mal eine Anlage besucht, kann den Baum durchnavigieren (Browse) und versteht ohne Vorwissen, dass "ns=4;s=Pump_07.FlowRate" eine Durchflussmessung in m³/h mit Statuscode und Zeitstempel ist.

Modbus kennt nichts davon. Hinter Adresse 40001 steht eine 16-Bit-Zahl — ob das ein Druckwert, ein Statusbit oder ein Fehlerregister ist, weiß nur die Bedienungsanleitung des Herstellers. Bei jedem Gerätetausch und jeder Firmware-Aktualisierung droht ein Mapping-Fehler. Genau hier setzen die Companion Specifications an: PA-DIM (Process Automation Device Information Model) standardisiert Prozessmessgeräte, AutoID kapselt RFID- und Barcode-Reader, OPC UA for Machinery vereinheitlicht Maschinen-Identifikation und Zustand. Wer in 2026 ein MES-Projekt nach RAMI 4.0 entwirft, baut die Verwaltungsschale (Asset Administration Shell, AAS) auf einem OPC-UA-Informationsmodell auf — Modbus ist auf dieser Ebene schlicht nicht satisfaktionsfähig.

OPC UA löst die OT-Cybersicherheitsanforderung im Protokoll selbst. Beim Verbindungsaufbau handeln Client und Server einen SecureChannel aus: MessageSecurityMode kann *None*, *Sign* oder *SignAndEncrypt* sein, die SecurityPolicy reicht von *Basic256Sha256* über *Aes128_Sha256_RsaOaep* bis zu den aktuellen *Aes256_Sha256_RsaPss*-Profilen. Jede Anwendung weist sich mit einem X.509-Anwendungszertifikat aus, jeder Benutzer optional zusätzlich per Username/Password oder eigenem X.509-Token. Audit-Events im Adressraum loggen jede Verbindungs- und Konfigurationsänderung — exakt das, was ein IEC-62443-3-3-Audit unter "System Integrity" und "Use Control" verlangt.

Modbus liefert davon nichts. Das Protokoll hat weder ein Authentifizierungs- noch ein Integritäts- noch ein Verschlüsselungsfeld. Der CRC beim Modbus RTU schützt gegen Übertragungsfehler, nicht gegen Manipulation. Die offizielle Erweiterung Modbus/TCP Security (TLS 1.2 mit X.509-Mutual-Authentication) existiert seit 2018, wird aber außerhalb von Schneider Modicon M580 und einigen wenigen Geräten kaum implementiert. In der Praxis kompensiert man durch Netzsegmentierung (Zonen und Conduits nach ISA-95), VLANs, Firewalls und in besonders kritischen Pfaden Datendioden.

Für jedes Projekt unter NIS2-Richtlinie, Cyber Resilience Act (CRA) oder mit auditiertem IEC-62443-Zonenplan ist OPC UA die sicherere Spezifikation — Modbus überlebt nur in streng segmentierten OT-Inseln.

Bis 2018 war OPC UA reines Client/Server: ein Client öffnet eine Subscription, abonniert MonitoredItems mit definiertem publishingInterval und samplingInterval und der Server sendet Datenänderungen aktiv. Das skaliert in einer einzelnen Maschine hervorragend (typisch 100-1000 Items pro Subscription, 100 ms publishingInterval), stößt aber bei Hunderten von Clients und Tausenden von Geräten an Grenzen.

Mit OPC UA Part 14 (Pub/Sub) kam 2018 die zweite Säule: Server publizieren ihre Datasets als NetworkMessages entweder direkt per UDP-Multicast auf demselben Netzsegment oder über einen Broker (MQTT, AMQP). Ein typisches IIoT-Setup 2026 sieht so aus: SPS publiziert per OPC UA Pub/Sub über MQTT an einen HiveMQ- oder EMQX-Cluster, MES und Cloud-Historian (MindSphere, AWS SiteWise) abonnieren dieselben Topics, Sparkplug B als ergänzende Payload-Spezifikation strukturiert die Topics einheitlich.

Modbus bleibt streng pollbasiert. Der Client fragt zyklisch ab — meist mit FC03 (Read Holding Registers) oder FC04 (Read Input Registers). Auf RS-485 mit 32 Slaves und 100 Registern pro Slave kommt man bei 115,2 kBd auf realistische Zykluszeiten von 200-500 ms. Modbus TCP entkoppelt die serielle Engstelle, behält aber das Polling-Modell. Das bedeutet: jeder zusätzliche Client multipliziert die Last auf dem Slave-Gerät, und Ereignisse sind erst sichtbar, wenn der nächste Poll sie einsammelt. Für Echtzeit-Datenakquise und Edge-Anbindung ist das ein architektonischer Sackgassen-Pfad.

Die Modernisierung von Modbus auf OPC UA ist selten ein "Big Bang", sondern ein gestufter Pfad mit klar bezifferbaren Kostenblöcken.

Hardware und Lizenzen. Eine Siemens S7-1500 bringt OPC UA Server und Client ab TIA Portal v18 ohne Zusatzlizenz mit, der Companion-Spec-Support (PA-DIM, Machinery) ist als Bibliothek verfügbar. Beckhoff liefert den TwinCAT OPC UA Server als kostenpflichtige TF6100-Lizenz pro Steuerung. Phoenix Contact und Wago integrieren OPC UA inzwischen in den AXC- und PFC200-Linien. Für Bestandsanlagen ohne OPC-UA-fähige SPS sind Edge-Gateways das Standardrezept: Kepware KEPServerEX, Ignition Edge, Hilscher netIOT Edge, HMS Anybus, Softing dataFEED — Preise pro Knoten 800-3000 EUR plus Wartung.

Engineering-Aufwand. Das Informationsmodell muss entworfen und gepflegt werden. Wer eine PA-DIM-konforme Pumpe modelliert, investiert pro Geräteklasse einen bis fünf Personentage. Die Zertifikatsverwaltung (PKI, Global Discovery Server, Erneuerung) braucht einen klaren Betriebsprozess — sonst läuft die Anlage nach 24 Monaten in den Zertifikatsablauf. Modbus dagegen kostet im Engineering fast nichts: Registerliste aus dem Handbuch ins SCADA übertragen, fertig.

Praxis-Empfehlung. OPC UA dort einsetzen, wo das semantische Modell, die Sicherheit oder die MES-Anbindung den Aufwand rechtfertigen — also auf der Zellebene und darüber. Modbus bleibt auf der Feldebene: Antriebe, Zähler, einzelne Sensoren. Ein Gateway (Kepware, Ignition, Node-RED) übersetzt zwischen beiden Welten. Diese Koexistenz ist 2026 die mit Abstand häufigste Architektur in Brownfield-Projekten von Siemens, Beckhoff, Wago, Phoenix Contact und SAP MII bis hinunter zur einzelnen Fertigungslinie.