In jeder industriellen Linie laufen gleichzeitig 3–7 verschiedene Protokolle. Ein Kunde, der fragt „können wir alles in OPC UA haben?", fragt nach etwas, das technologisch nicht lösbar ist — Feldbus, Motion-Bus und IT/OT-Integration sind drei verschiedene Welten mit unterschiedlichen Anforderungen an Latenz, Determinismus, Bandbreite und Lebenszyklus. Dieser Artikel beschreibt, wann welches Protokoll zu verwenden ist und wann die Wahl durch die frühere Technologieauswahl (SPS, Motion-Controller, Sensor) festgelegt ist und nicht durch eine ingenieurmäßige Entscheidung.
Drei Schichten, drei Welten
Field/Sensor Layer (niedrigste 5–50 μs Latenz)
- **EtherCAT** — Beckhoff, KEB, einige ABB-Motoren. Sub-100 μs Jitter, voll deterministisch. Am besten für Motion Control mit mehr als 4 koordinierten Achsen.
- **Profinet IRT / Isochronous** — Siemens Core, Phoenix Contact, Wago, Bosch Rexroth. 100–250 μs, hoher Determinismus. Für die meisten Maschinen in Europa = De-facto-Standard.
- **Sercos III** — Bosch Rexroth, KEB, Nische. Hervorragender Motion-Bus, aber rapide auf dem Rückzug gegenüber EtherCAT.
Cell/Machine Layer (1–100 ms)
- **Profinet RT** — übliche Siemens-Maschine. 1–10 ms RTT, deckt 95 % der Produktionsmaschinen ab.
- **EtherNet/IP** — Allen-Bradley / Rockwell-Ökosystem. In der SK weniger verbreitet, dominiert aber in den USA / Automotive Tier 1.
- **Modbus TCP** — das einfachste. Kein Determinismus, aber 200+ bestehende Geräte von dutzenden Herstellern sprechen Modbus.
Plant/IT Layer (Latenz egal, wichtig ist der Inhalt)
- **OPC UA** (Server/Client + PubSub) — Interoperabilität SCADA, MES, ERP, Cloud. Hier lebt OPC UA.
- **MQTT (meistens Sparkplug B)** — IIoT, Telemetrie in die Cloud, Edge-Gateway → Cloud.
- **HTTP/REST + WebSocket** — moderne Dashboards, Grafana, Custom UI.
Ein Kunde, der „alles in OPC UA" will, will Plant-Level-Interoperabilität zwischen 5 SPS-Herstellern erreichen — was OPC UA perfekt löst. OPC UA zwischen Servomotor und Controller zu verwenden, ist ein technologischer Unsinn: Latenz von 5–20 ms ist 100× langsamer, als es Motion Control erfordert.
Modbus — wann ergibt es 2026 noch Sinn
Modbus RTU (RS-485) und Modbus TCP sind die einfachsten Protokolle, die die Industrie kennt. Tabelle von Registern, Function Code 03/04 (read), 06/16 (write), CRC. Implementierung in SPS oder Python in 2 Stunden.
**Plus:** - Universell — jeder Hersteller von Sensoren, Frequenzumrichtern, Energiezählern unterstützt es - Trivial zu debuggen (Wireshark mit Modbus-Dissector, Modpoll Command-Line) - Keine Lizenzen, keine Integration Kits, keine EDS/GSDML-Dateien - Günstig — Modbus-Gateway für 80 EUR, OPC UA Gateway für 800–2.000 EUR
**Minus:** - Master-Slave (Request-Response), keine event-getriebenen Daten - Ohne Determinismus — Modbus RTU bei 19.200 Baud dauert das Lesen von 100 Registern ~150 ms - Ohne Sicherheit (RTU gar nicht, TCP nur über TLS-Tunnel) - Ohne Semantik — Register 40001 ist „was du dort hineintust". Ohne Dokumentation ist das Auslesen eines Wertes sinnlos.
**Wann verwenden:** günstige Sensoren, Energiezähler, einfache Steuerungen (Carel, Eliwell, Belimo, IFM), Legacy-Geräte (Frequenzumrichter 2015–), DIY und Maker-Setups. Jeder Fall, in dem 1-Hz-Auslesen reicht und Sie Budget sparen.
**Wann NICHT verwenden:** jedes Setup mit mehr als 50 Geräten in einem Netzwerk (Modbus-Master-Skalierung ist ein Problem), jede Anwendung mit Echtzeit (Motion, Fast Safety), jede IT/OT-Integration (fehlende Semantik).
Profinet — das Arbeitspferd europäischer Linien
Profinet (Process Field Network) liegt in den Händen von Siemens und dem PROFIBUS & PROFINET International (PI) Konsortium. Drei Versionen:
- **Profinet TCP** (azyklisch) — 100+ ms, für Konfiguration und Diagnose
- **Profinet RT** (Real Time) — 1–10 ms, für normale SPS ↔ I/O-Kommunikation
- **Profinet IRT** (Isochronous Real Time) — sub-1 ms, für Motion Control
**Plus:** - De-facto-Standard in der EU (Siemens-Dominanz) - Reiches Ökosystem — Beckhoff, Phoenix Contact, Wago, Festo, SICK, Pepperl+Fuchs, B&R sprechen Profinet - Webbasierte Diagnose in jedem IO-Modul - TSN-Ready (ab Profinet 2.4) - Sicherheit über PROFIsafe Profile (für Safety-Relais)
**Minus:** - Komplexer als Modbus — erfordert GSDML-Dateien, IP-Adressierung, Device Naming - Lizenzkontext (Siemens TIA Portal, OpenPN Stack für 3rd Party) - Switches müssen „Profinet Conformance Class A/B/C" sein — ein gewöhnlicher Cisco-Switch reicht oft bei IRT nicht aus - Topologische Einschränkungen — IRT erfordert Line oder Star (keinen Zyklus)
**Wann verwenden:** jede moderne Maschine in der EU mit mehr als 5–10 IO-Modulen, Motion Control über 4 Achsen, Integration mit Siemens SCADA (WinCC, PCS 7), Fälle, in denen der Kunde bereits 5+ Siemens-Maschinen hat und ein homogenes Ökosystem will.
**Wann NICHT verwenden:** stark heterogene Umgebungen (wo die Hälfte der Geräte Allen-Bradley ist → EtherNet/IP ist die bessere Wahl), kleine Maschinen mit 3–5 IO-Punkten (Modbus RTU reicht, günstiger), US-Kunden (wo Rockwell dominiert).
OPC UA — Interoperabilität für IT/OT-Integration
OPC UA (Unified Architecture) ist kein Feldbus. Es ist eine **Applikationsschicht** auf TCP/IP, die löst: Wie verschiedene Maschinen, SCADA, MES und Cloud-Services **semantisch reichhaltige** Daten austauschen.
**Plus:** - Plattform-agnostisch (SPS, Embedded Linux, Windows-Server, Docker-Container) - Vendor-agnostisch (Siemens, Rockwell, B&R, Beckhoff, Honeywell — alle haben einen OPC UA Server) - Reiche Semantik — Typen, Hierarchie, Metadaten, Zeitstempel - Sicherheit als First-Class Citizen — X.509-Zertifikate, Role-Based Access, Audit Trail - Companion Specs für konkrete Domänen (OPC UA for Robotics, for Machinery, for Pumps) - PubSub-Modell (MQTT-basiert oder UDP-Multicast) für Cloud- und Brokerlose Szenarien
**Minus:** - Latenz 5–50 ms pro Zyklus — unbrauchbar für Motion Control - CPU-intensiv (auf üblichem Embedded-Gerät 20–40 % Auslastung nur durch den OPC-UA-Server) - Komplex — Security-Stack, Certificate Management, Address Space Modeling — das ist nicht „lies Register 40001" - Für dieselbe Aufgabe 5× mehr Code als Modbus
**Wann verwenden:** SCADA-, MES-, ERP-Integration. Bridging zwischen verschiedenen Vendoren. Cloud-Telemetrie. Jeder Fall, an dem später Analytics, ML-Modell oder BI-Dashboard angeschlossen wird. Maschinen, die in ein MOM/MES-System integriert werden (Apriso, Critical Manufacturing, GE Plant Apps).
**Wann NICHT verwenden:** zwischen SPS und Sensor (Profinet/EtherCAT). Für einfache Telemetrie in die Cloud (MQTT Sparkplug B ist 10× günstiger in der Implementierung). Zwischen zwei SPS, die nativ über Feldbus sprechen können (Profinet PLC-to-PLC ist schneller und deterministischer).
Häufigstes Architekturmuster 2026
Eine Maschine in Europa läuft 2026 typischerweise:
``` Sensor/I/O ←Profinet RT→ SPS ←Profinet RT→ Drive (Motion) ↓ OPC UA Server ↓ SCADA (Ignition, WinCC) ↓ OPC UA / MQTT Sparkplug B ↓ MES (Apriso, Critical Manufacturing) ↓ ERP / Cloud (SAP, AWS IoT, Azure IoT Hub) ```
Modbus erscheint am Rand — bei günstigen Sensoren, Energiezählern, Frequenzumrichtern. Wir sprechen mit ihm über Modbus → Profinet Gateway (Hilscher netTAP, Anybus X-Gateway, Phoenix Contact AXL F BK) oder über einen OPC UA Server mit Modbus-Driver (Kepware, Matrikon, ignition.com).
Drei Entscheidungen ohne technologisch korrekte Antwort
1. Soll ich OPC UA Companion Spec für Robotics verwenden?
Für KUKA-, ABB-, FANUC-Integration mit MES ist es theoretisch die richtige Wahl. In der Praxis: Die Companion-Spec-Implementierung hinkt der Roboter-Firmware 12–18 Monate hinterher, also muss der Kunde manchmal eine proprietäre REST-API oder OPC UA mit eigener Semantik nutzen. Die Wahl hängt von der **konkreten Firmware-Version des Roboters** ab — klären Sie das mit dem Vendor vor dem Commitment im Projekt.
2. Soll ich von Profibus DP auf Profinet umsteigen?
Profibus DP ist die enorme Grundlage älterer Linien (2005–2018). Migration zu Profinet kostet 30–50 % CAPEX der Installation und zahlt sich oft nur, wenn Sie auch die SPS migrieren. Realistisch: Wenn Ihre Linie stabil ist und der Profibus-Master noch verfügbar ist (Siemens verkauft Spare Parts bis 2030+), migrieren Sie nicht unnötig. Migration ergibt Sinn in Kombination mit einer neuen SPS oder Expansion.
3. Soll ich auf TSN (Time-Sensitive Networking) umsteigen?
TSN ist ein IEEE-Standard, der deterministisches Ethernet in jedes industrielle Protokoll bringt. Profinet, EtherCAT, EtherNet/IP — alle werden schrittweise TSN-aware. Realistisch 2026: Wenn Sie keine neue Flagship-Linie bauen, warten Sie 2–3 Jahre. TSN-Switches sind noch 3–5× teurer als gewöhnliche Managed Switches, das Ökosystem ist unreif.
Praktische Checkliste fürs Projekt
Vor der Protokollauswahl: 1. Welche SPS sind bereits in der Werkstatt? (Siemens → Profinet default, AB → EtherNet/IP, Beckhoff → EtherCAT) 2. Welches SCADA? (WinCC → Profinet + OPC UA, Ignition → OPC UA + MQTT, FactoryTalk → EtherNet/IP + OPC UA) 3. Welches MES? (Apriso → OPC UA, Critical Manufacturing → OPC UA, eigene App → REST + MQTT) 4. Gibt es eine Cloud-Strategie? (Ja → MQTT Sparkplug B oder OPC UA PubSub, Nein → OPC UA Server reicht) 5. Wie ist die Schätzung der Gerätezahl? (< 20 → Modbus reicht, 20–100 → Profinet, 100+ → Profinet + OPC UA Hierarchie) 6. Welche Zykluszeit ist gefordert? (> 100 ms → OPC UA, 10–100 ms → Profinet RT, < 10 ms → Profinet IRT / EtherCAT, < 1 ms → EtherCAT oder Sercos III)
Diese sechs Fragen decken 90 % der Entscheidung ab. Die restlichen 10 % sind Vendor Relationship, bestehende Verträge und persönliche Präferenzen des Teams, das die Linie 10 Jahre wartet.
---
*Wir machen SPS-Programmierung und IT/OT-Integration quer durch Protokolle (Siemens, Beckhoff, Allen-Bradley, B&R, OPC UA, MQTT). Wenn Sie über eine neue Linie oder Modernisierung einer bestehenden nachdenken, geht die erste Beratung (60 Minuten) die Protokollarchitektur durch, bevor das Elektroprojekt beginnt.*