PROFINET, EtherNet/IP, EtherCAT, OPC UA und MQTT im Vergleich

Kurzfassung:

Verwenden Sie

PROFINET, EtherNet/IP oder EtherCAT

, wenn eine SPS oder Bewegungssteuerung zyklisch und mit vorhersehbarem Zeitverhalten Prozessdaten mit einem Roboter, Antrieb oder E/A-Gerät austauschen muss.

OPC UA

eignet sich, wenn übergeordnete Software strukturierte Maschineninformationen benötigt;

MQTT

verteilt Ereignisse und Telemetriedaten über einen Publish/Subscribe-Broker an verschiedene Anwendungen. Diese Technologien ersetzen einander nicht unmittelbar. In einer gut geplanten Fabrik können mehrere parallel sinnvoll sein. Entscheidend sind vorhandene Steuerungen, tatsächlich installierte Schnittstellen und Lizenzen, Datenflüsse und das Verhalten bei Kommunikationsverlust – nicht eine isolierte Geschwindigkeitsangabe.

Technischer Leitfaden, aktualisiert am 13. Oktober 2026. Der Vergleich basiert auf Normen und Dokumentation. Er ist weder ein Laborbenchmark noch ein Kompatibilitätsnachweis für bestimmte Roboter- und SPS-Modelle.

Schneller Überblick: Welches industrielle Kommunikationsprotokoll passt?

Faustregel:

Wählen Sie das Protokoll

für jede Schnittstelle einzeln

, nicht eines für das ganze Werk. Die SPS kann den Roboter über PROFINET steuern, während ein Edge-Gateway OPC-UA-Daten liest und ausgewählte Produktionsereignisse über MQTT verteilt.

Warum Ethernet nicht gleich Ethernet ist

Industrielles Ethernet ist eine Gruppe unterschiedlicher Technologien, kein universell austauschbares Kommunikationssystem. RJ45-ähnliche Stecker, Ethernet-Leitungen oder teilweise gemeinsame Infrastruktur bedeuten nicht, dass Geräte miteinander kommunizieren können. Rollen, Protokollstapel, Zeitmechanismen, Adressierung und Anwendungsdaten unterscheiden sich.

Die wichtigste Grenze verläuft zwischen

zyklischen Steuerungsdaten

und

übergeordneten Informationen

. Steuerungsdaten werden wiederholt aktualisiert, damit die SPS mit aktuellen Ein- und Ausgangszuständen den Maschinenablauf steuert. Übergeordnete Software benötigt dagegen Bedeutung, Verlauf und Kontext, beispielsweise MES, SCADA, Instandhaltung und Analysesysteme.

Ein Roboter kann bei jedem konfigurierten E/A-Intervall ein aktualisiertes SPS-Befehlswort benötigen. Für ein Produktionsdashboard genügt vielleicht die Information, dass ein Zyklus begonnen, ein Werkstück fertiggestellt oder ein Fehler gemeldet wurde. Solche Ereignisse unnötig in ein zyklisches E/A-Abbild zu pressen, erzeugt Aufwand. Eine normale MQTT-Nachricht als einzigen zeitkritischen Maschinen-Interlock zu verwenden, ist dagegen ein Architekturfehler.

Determinismus ist nicht nur Geschwindigkeit.

Für Steuerungen sind Vorhersagbarkeit und begrenzte Laufzeiten mindestens so wichtig wie der mittlere Datendurchsatz. Die tatsächliche Reaktionszeit umfasst Netzwerkaktualisierung, SPS-Taskplanung, Verarbeitung in der Robotersteuerung und Programmlogik. Ein schnelles Netzwerk heilt keine schlechte Ablaufsteuerung.

1. PROFINET: zyklische Kommunikation in SPS-basierten Anlagen

PROFINET

wird von PROFIBUS & PROFINET International (PI) betreut und dient der industriellen Automatisierung mit zyklischen Prozessdaten, Diagnosefunktionen und Engineering-Integration. In einer üblichen Architektur arbeitet die SPS als

IO-Controller

, die Robotersteuerung oder dezentrale E/A-Station als

IO-Device

. Zwischen beiden werden die konfigurierten Ein- und Ausgangsdaten ausgetauscht.

So funktioniert PROFINET

PROFINET unterstützt Echtzeitkommunikation für zyklische E/A. Bekannte Varianten sind

RT (Real Time)

für zahlreiche Standardanwendungen und

IRT (Isochronous Real Time)

für strengere Synchronisierungsanforderungen, sofern verfügbar. PI entwickelt außerdem PROFINET-Funktionen mit Bezug zu Time-Sensitive Networking (TSN). Diese Merkmale sind keine beliebig austauschbaren Optionen: Steuerung, Gerät, Firmware und Netzaufbau müssen die tatsächlich benötigte Funktion unterstützen.

Zur Inbetriebnahme gehören zudem Geräteidentifikation, Alarme, Diagnose und Parametrierung. Typischerweise wird eine

GSDML

-Datei verwendet: eine XML-Gerätebeschreibung für PROFINET, die Module, Datenlängen und Fähigkeiten für die Engineering-Software bereitstellt.

Beispiel: SPS und Roboter über PROFINET

Die SPS könnte Betriebsfreigabe, Programmnummer und Startanforderung übertragen. Der Roboter meldet bereit, beschäftigt, abgeschlossen und Störung zurück. Der Signalvertrag legt fest, was jedes Bit bedeutet, wer es setzt und wie eine unterbrochene Sequenz behandelt wird. PROFINET transportiert die Bytes,

definiert aber nicht die herstellerspezifische Handshake-Logik des Roboters

.

PROFINET ist sinnvoll, wenn

die Anlage bereits darauf ausgelegt ist, die Robotersteuerung die benötigte IO-Device-Rolle bereitstellt und das SPS-Engineering die exakte GSDML- und E/A-Konfiguration unterstützt. Aus PROFINET-Unterstützung folgen nicht automatisch PROFIsafe, IRT oder Motion-Funktionen.

2. EtherNet/IP: CIP-basierte Steuerung über Ethernet/IP

EtherNet/IP

wird von ODVA betreut und überträgt das

Common Industrial Protocol (CIP)

über Standard-Ethernet- und Internetprotokolle. Es wird für Geräte-E/A und Diagnosen eingesetzt. Trotz der ähnlichen Bezeichnung ist es weder einfach irgendeine Ethernet-Verbindung noch automatisch mit PROFINET kompatibel.

Zyklische E/A und explizite Nachrichten

CIP unterscheidet zwischen dem E/A-Austausch, häufig

Implicit Messaging

genannt, und dem anfragebasierten Zugriff auf Geräteobjekte,

Explicit Messaging

. Zyklische E/A nutzen üblicherweise UDP, explizite Nachrichten oft TCP. Die Verbindungen übertragen Byte-Assemblies, deren Bedeutung vom veröffentlichten Gerätemodell und der Konfiguration abhängt.

In einer typischen SPS-Roboter-Verbindung übernimmt die SPS die Rolle

I/O Scanner

, das Roboterinterface die Rolle

Adapter

. Die genaue Begrifflichkeit und die unterstützten Betriebsarten können hersteller- und generationsabhängig sein. Die

EDS (Electronic Data Sheet)

ist eine hilfreiche Gerätebeschreibung; zusätzlich sind Assembly-Instanzen, Eingangs- und Ausgangslängen, Verbindungspfad und Requested Packet Interval (

RPI

) zu prüfen. Eine EDS-Datei garantiert noch keine vollständige automatische Integration.

ODVA definiert auch CIP Safety, CIP Motion, CIP Sync und CIP Security. Dass diese zur CIP-Familie gehören,

belegt keine Unterstützung in einer bestimmten Robotersteuerung

.

EtherNet/IP ist sinnvoll, wenn

SPS und Netzwerk auf CIP beruhen, Roboter oder Endeffektor die richtige Adapter-Rolle besitzen und Mapping, Verbindungsgrößen und Aktualisierung geprüft sind. Ein erfolgreicher Ping bestätigt nur IP-Erreichbarkeit, nicht einen funktionierenden zyklischen Datenaustausch.

3. EtherCAT: Verarbeitung im Durchlauf und synchrone Geräte

EtherCAT

, unterstützt von der EtherCAT Technology Group (ETG), verwendet ein anderes Prinzip. Ein

MainDevice

schickt einen EtherCAT-Frame durch ein Segment. Jedes

SubDevice

liest seine Ausgabedaten und ergänzt seine Eingabedaten beim Durchlauf. Diese

On-the-fly

-Verarbeitung vermindert wiederholte Einzelabfragen und eignet sich für anspruchsvolle verteilte Steuerungsaufgaben.

Warum EtherCAT kein gewöhnliches TCP/IP ist

Standardmäßige EtherCAT-Prozessdatenframes verwenden Ethernet-Rahmen, üblicherweise mit EtherType

0x88A4

. Es handelt sich

nicht um normale TCP- oder UDP-Pakete

. Ein gewöhnlicher Büro-Switch, IP-Router oder MQTT-Broker lässt sich nicht automatisch in ein EtherCAT-Segment einfügen. Topologie und Segmenthardware müssen den Vorgaben der eingesetzten Geräte entsprechen.

Der Mechanismus

Distributed Clocks (DC)

kann kompatible Geräte synchronisieren, beispielsweise mehrere Servoantriebe für abgestimmte Bewegung. Damit ist nicht automatisch jede beliebige Roboterbewegung zwischen Systemen koordiniert.

Für die Konfiguration wird oft eine XML-Datei

ESI (EtherCAT SubDevice Information)

genutzt. Integratoren müssen Prozessdatenobjekte, Betriebszustände, Synchronisierungsmodi, physische Schnittstellen und Firmwareversionen prüfen. Je nach Hersteller können spezifische Implementierungen nötig sein.

EtherCAT ist sinnvoll, wenn

die Maschine darauf aufgebaut ist, Synchronisierung oder verteilte Motion benötigt wird und alle Komponenten – einschließlich eines eventuellen Roboterinterfaces – die passenden Rollen und Funktionen unterstützen. Eine besonders niedrige theoretische Zykluszahl reicht als Begründung nicht aus.

4. OPC UA: Maschineninformationen mit Struktur und Bedeutung

OPC Unified Architecture (OPC UA)

der OPC Foundation ist eine plattformunabhängige industrielle Kommunikationsarchitektur. Sie stellt Maschinen, Eigenschaften, Beziehungen und Methoden in einem Informationsmodell dar, das Anwendungen erkunden und verstehen können. Häufig wird Client/Server genutzt; geeignete Implementierungen unterstützen auch Publish/Subscribe. Authentifizierung, Verschlüsselung und Autorisierung sind Bestandteil der Architektur.

Warum Informationsmodelle wichtig sind

Stellen wir uns ein MES vor, das Betriebsart, ausgewähltes Programm, aktuellen Alarm und Teilezähler eines Roboters benötigt. Ein reines SPS-E/A-Array zeigt davon möglicherweise nur Byte-Offsets und Bitnummern. Ein OPC-UA-Server kann dagegen benannte Objekte, Datentypen und Beziehungen präsentieren. Auch hier muss das konkrete Modell bekannt sein; dennoch ist man nicht auf eine unkommentierte Byte-Tabelle angewiesen.

Für die Robotik definiert

OPC 40010-1, OPC UA for Robotics – Part 1: Vertical Integration

ein Informationsmodell für übergeordnete Systeme. Die offizielle Referenz nennt

Version 1.02 vom 8. September 2025

. Ein Roboterhersteller kann OPC UA anbieten, ohne dieses Companion-Modell oder alle optionalen Funktionen zu implementieren.

Ist OPC UA ausschließlich zur Überwachung gedacht?

Nein. OPC UA ermöglicht Lesen, Schreiben, Methoden und Publish/Subscribe. Die Arbeiten zu

Field Level Communications / OPC UA FX

erweitern die Technik in Richtung Feldebene, auch hinsichtlich Echtzeitanforderungen. Das ist eine wichtige Einordnung: In klassischen Roboterzellen wird OPC UA häufig oberhalb des Steuerungsnetzes eingesetzt, grundsätzlich auf Überwachung beschränkt ist die Technologie aber nicht. Für Steuerungsaufgaben müssen konkrete Profile, Geräte und validiertes Zeitverhalten nachgewiesen werden.

OPC UA ist sinnvoll, wenn

unterschiedliche Plattformen eine auffindbare, strukturierte und geschützte Sicht auf Maschinendaten benötigen. Konfigurieren Sie Zertifikate, Authentifizierung, Berechtigungen, sichere Endpunkte und erlaubte Lese-/Schreiboperationen. Ein vorhandener OPC-UA-Server gibt dem MES noch kein Recht, Roboterbewegungen auszulösen.

5. MQTT: Produktionsereignisse veröffentlichen und abonnieren

MQTT

ist ein von OASIS standardisiertes Publish/Subscribe-Nachrichtenprotokoll. Ein Gerät oder eine Edge-Anwendung veröffentlicht Daten unter einem

Topic

; ein Broker verteilt sie an interessierte Abonnenten. Der Sender muss nicht direkt mit jedem Dashboard, jeder Datenbank oder Analyseanwendung verbunden sein.

Praxisbeispiel für MQTT-Topic und Payload

Ein Gateway könnte unter

factory/bilbao/cell-03/robot-01/status

folgende beispielhafte JSON-Nachricht veröffentlichen:

{
  "schema_version": 1,
  "asset_id": "robot-01",
  "timestamp_utc": "2026-10-13T12:00:00Z",
  "state": "running",
  "program_id": "job-024",
  "parts_completed": 1842,
  "source_quality": "good"
}

Nur Beispieldaten, keine Messwerte einer realen Anlage.

MQTT legt nicht fest, was

state

,

program_id

und

parts_completed

bedeuten. Der Integrationsvertrag muss Einheiten, Datentypen, Zeitstempel, Ereigniskennungen, Verantwortlichkeiten, Schemaversionen und Erkennung veralteter Werte regeln.

Was die MQTT-QoS-Stufen tatsächlich garantieren

• 
  QoS 0:
  
  höchstens einmalige Zustellung auf MQTT-Ebene; Nachrichten können verloren gehen.
• 
  QoS 1:
  
  mindestens einmalige Zustellung auf MQTT-Ebene; Duplikate sind möglich.
• 
  QoS 2:
  
  genau einmalige Zustellung innerhalb des betreffenden MQTT-Nachrichtenaustauschs, mit zusätzlichem Protokollaufwand. Daraus folgt nicht, dass eine nachgelagerte Datenbanktransaktion oder physische Roboteraktion genau einmal ausgeführt wird.

Retained Messages zeigen den zuletzt veröffentlichten Zustand, der allerdings veraltet sein kann. Persistente Sitzungen, Wiederholungen und Ablaufzeiten müssen bewusst festgelegt werden. Nutzen Sie Zeitstempel, Aktualitätsregeln und gegebenenfalls Ereignis-IDs oder Idempotenzschlüssel. Zur Absicherung gehören authentifizierte Clients, gegebenenfalls TLS, Topic-bezogene Zugriffslisten und eingeschränkte Brokerverbindungen.

MQTT ist sinnvoll, wenn

Betriebsereignisse, Wartungsmeldungen oder historische Telemetrie an mehrere Verbraucher verteilt werden sollen. Dass ein Cloud-Dienst ein Topic veröffentlichen kann, ersetzt weder eine validierte zyklische SPS-Roboter-Verbindung noch eine Sicherheitsfunktion.

So arbeiten die Protokolle in einer Roboterzelle zusammen

Betrachten wir eine Verpackungszelle mit Industrieroboter, SPS, Greifer, Sensorik und übergeordnetem Dashboard. Eine mögliche Architektur trennt die Aufgaben:

1. 
   Maschinensteuerung:
   
   Die SPS überträgt Roboterbefehle und -zustände über ein unterstütztes zyklisches Feldbusinterface. Die Robotersteuerung führt ihr validiertes Programm aus. Weitere Antriebe oder E/A können denselben oder einen anderen Feldbus nutzen.
2. 
   Funktionale Sicherheit:
   
   Ein separat ausgelegtes Sicherheitssystem überwacht Schutzeinrichtungen und sichere Stoppfunktionen. Je nach Risikobeurteilung nutzt es sicherheitsgerichtete verdrahtete E/A oder ein unterstütztes Sicherheitsprotokoll.
3. 
   Strukturierte Betriebsdaten:
   
   Roboter, SPS oder Industrial Gateway stellen ausgewählte Zustände und Diagnosen über OPC UA bereit; Schreibrechte sind begrenzt.
4. 
   Ereignisverteilung:
   
   Ein autorisiertes Gateway wandelt bestimmte Änderungen in MQTT-Ereignisse um. Der Broker wird dabei kein erforderlicher Bestandteil des Maschinensteuerkreises.
5. 
   Geschäftsanwendungen:
   
   MES, Instandhaltung und Analyse nutzen Informationen für Rückverfolgbarkeit, OEE und Fehlersuche.

Das ist ein Architekturbeispiel, kein allgemeingültiger Bauplan. Manche Werke verbinden die SPS direkt mit dem MES, andere verwenden Historian-Systeme oder OPC UA ohne MQTT. Ein Gateway sollte einen realen Integrationsbedarf decken und nicht nur eine zusätzliche Ausfallquelle schaffen.

Praxisbeispiel: robuster SPS-Roboter-Handshake

Ein Protokoll transportiert Signale; der

Schnittstellenvertrag

legt das beabsichtigte Maschinenverhalten fest. Die folgende Tabelle zeigt einen beispielhaften Pick-and-Place-Zyklus. Signalnamen und Richtungen sind konzeptionell, kein Standard und keine herstellerspezifische Belegung.

Möglicher Ablauf:

Die SPS prüft die normalen Maschinenvoraussetzungen, wählt den Auftrag, überträgt eine neue Befehlskennung und fordert einen Zyklus an. Der Roboter bestätigt die angenommene Kennung, meldet beschäftigt und später den Abschluss für denselben Befehl. Die SPS gibt keinen weiteren Zyklus frei, bevor sie den vorherigen samt Ergebnis abgeglichen hat. Einschalten, Timeout oder Verbindungsverlust dürfen eine alte Anforderung nie stillschweigend in einen neuen Bewegungsbefehl verwandeln.

Für Spannungsrückkehr, Not-Halt, Schutzstopp, Steuerungsneustarts, Auftragswechsel, gleichzeitige Fehler und Handbetrieb braucht es klare Regeln. Anwendungsbits wie

Ready

oder

Heartbeat

sind

keine sicherheitsgerichteten Signale

, sofern sie nicht ausdrücklich in einer geeigneten Sicherheitsarchitektur umgesetzt und validiert wurden. Ein normales Feldbusstatusbit beweist keine sichere Zelle.

E/A-Kommunikation, Roboterbewegung und funktionale Sicherheit unterscheiden

Häufig werden drei verschiedene Fragestellungen vermischt:

• 
  Normaler E/A-Handshake:
  
  Startanforderungen, Zustände, Programmnummern und Diagnosen austauschen. Oft reicht ein kleiner zyklischer Datenblock.
• 
  Bewegungskoordination:
  
  Mehrere Achsen, Förderbandverfolgung oder koordinierte Roboterbewegungen synchronisieren. Dafür können herstellerspezifische Motion-Optionen, synchronisierte Uhren, Profile oder proprietäre Schnittstellen nötig sein – nicht bloß ein kürzerer E/A-Zyklus.
• 
  Funktionale Sicherheit:
  
  Gefährdungen erkennen und validierte Sicherheitsfunktionen ausführen. Mögliche Protokolle sind
  
  PROFIsafe
  
  ,
  
  CIP Safety
  
  und
  
  Safety over EtherCAT (FSoE)
  
  , jedoch nur mit geeigneten sicherheitsgerichteten Teilnehmern und entsprechender Auslegung und Validierung.

Sicherheitslogik, Sicherheitskommunikation, Safe Torque Off, Schutzstopp und Not-Halt sind keine austauschbaren Begriffe. Umsetzung, geforderte Zuverlässigkeit und Wiederanlaufverhalten ergeben sich aus Risikobeurteilung und geltenden Normen, nicht aus einem Protokollvergleich.

In sechs Schritten zum passenden Protokoll

1. 
   Konkrete Geräte erfassen.
   
   SPS-CPU, Robotersteuerung, E/A-Module, Antriebe, Firmwarestände, Netzwerkkarten und installierte Softwarelizenzen dokumentieren. Die Marke allein garantiert keine einheitlichen Schnittstellen.
2. 
   Funktionen zuordnen.
   
   Jeden Wert als zyklischen Befehl/Zustand, Bewegungsdaten, sicherheitsbezogene Kommunikation, Diagnose oder Geschäftstelemetrie einordnen.
3. 
   Netzwerkrollen prüfen.
   
   PROFINET IO-Controller/IO-Device, EtherNet/IP Scanner/Adapter und EtherCAT MainDevice/SubDevice unterscheiden. Geräte mit gleichem Protokollnamen, aber unpassenden Rollen kommunizieren möglicherweise nicht direkt.
4. 
   Integrationsnachweise anfordern.
   
   GSDML für PROFINET, EDS und Verbindungsparameter für EtherNet/IP oder ESI für EtherCAT beschaffen. Bei OPC UA unterstützte Endpunkte, Namensräume und Sicherheitsprofile; bei MQTT Broker- und Payloadvertrag klären.
5. 
   Zeit- und Fehlerverhalten spezifizieren.
   
   Aktualisierungsintervalle, veraltete Daten, Timeouts und Zustände nach Verbindungsabbruch oder Neustart festlegen. SPS-Zyklus, Roboterverarbeitung und Sicherheit separat betrachten.
6. 
   Minimale Schnittstelle am Prüfstand nachweisen.
   
   Verbindung herstellen, typische E/A-Werte übertragen, Datentypen und Byte-Reihenfolge prüfen, danach Kommunikationsausfall und Neustart simulieren – noch bevor die Architektur festgelegt wird.

Drei typische Beschaffungssituationen

Szenario A: vorhandene PROFINET-Anlage.

Unterstützt die gewählte Robotersteuerung PROFINET als IO-Device, kann der bestehende Feldbus Engineering, Ersatzteile und Wartung vereinfachen. Maßgeblich ist die installierte Option, nicht die Broschüre.

Szenario B: CIP-basierte SPS-Landschaft.

Ein EtherNet/IP-Adapter am Roboter kann die einfachste Integration ermöglichen. Prüfen Sie Assemblies, Datenlängen, RPI und Störungsverhalten vor der SPS-Programmierung.

Szenario C: EtherCAT-Maschine mit mehreren Servoachsen.

EtherCAT passt häufig zu Antrieben und E/A; ein eigenständiger Industrieroboter nutzt für den Programm-Handshake möglicherweise trotzdem einen anderen Feldbus, wenn nur dieser unterstützt wird. Eine Maschine darf mehrere Feldnetzwerke besitzen.

Wichtiger als beworbene Zykluszeiten

Hersteller nennen mitunter eindrucksvolle theoretische Aktualisierungswerte. Für bestimmte Konfigurationen können sie stimmen, beschreiben aber nicht die Reaktionszeit Ihrer gesamten Roboterzelle. Trennen Sie:

• 
  Feldbus-Aktualisierungsintervall:
  
  Häufigkeit des Austauschs der Prozessdaten.
• 
  Jitter:
  
  zeitliche Schwankungen bei Datenankunft und Task-Ausführung.
• 
  SPS-Taskperiode:
  
  Zeitpunkte des Einlesens, Verarbeitens und Ausgebens.
• 
  Reaktion der Robotersteuerung:
  
  Zeitpunkt der Eingangserkennung und Zustandsänderung im Programm.
• 
  Physikalische Reaktion:
  
  zusätzliche Reaktionszeit der Hardware innerhalb der validierten Sequenz.

Beim üblichen Start/Beschäftigt/Fertig-Handshake zählen Vorhersagbarkeit, Diagnose und Kompatibilität oft mehr als minimale Netzzyklen. Für eng gekoppelte Antriebe kann das anders sein. Messen Sie kritische Zeiten am vorgesehenen Aufbau; ein Protokollname ist kein Leistungsnachweis.

Netzwerksegmentierung, Fernzugriff und Cybersicherheit

OPC UA und MQTT verbessern Transparenz, schaffen aber zusätzliche Zugangspfade. Defense in Depth trennt Maschinensteuerung von Leitsystemen und Unternehmensdiensten, erlaubt nur benötigte Datenflüsse und verhindert, dass ein Ausfall von Analysesystemen zum Steuerungsproblem wird.

• 
  Segmentierung:
  
  Zell-, Überwachungs- und Unternehmenszonen definieren; nach Bedarf geroutete und gefilterte Übergänge einrichten.
• 
  Identitäten:
  
  eigene Dienstkonten mit minimalen Rechten verwenden; keine geteilten Standardpasswörter oder unbeschränkt anonymen Clients.
• 
  Zertifikate und Verschlüsselung:
  
  unterstützte OPC-UA-Sicherheitsmodi, vertrauenswürdige Zertifikate und abgesicherte MQTT-Transporte konfigurieren; Gültigkeiten überwachen.
• 
  Minimale Rechte:
  
  Betriebsdaten standardmäßig nur lesend bereitstellen. Fernschreibzugriffe benötigen geprüfte, protokollierte Befehlsabläufe.
• 
  Unabhängige Fehlerreaktion:
  
  Ausfälle von Cloud, Broker, Historian oder SCADA dürfen kein unsicheres Maschinenverhalten verursachen.
• 
  Wartbarkeit:
  
  Konfigurationssicherungen, Netzwerkpläne, Supportdaten und kontrollierte Updates sowie Credential-Verwaltung vorhalten.

Ein allgemeiner Artikel ersetzt keine Sicherheitsbewertung der Netzwerke einer Fabrik. Notwendige Maßnahmen ergeben sich aus Bedrohungsanalyse, Produktionsbedingungen, geltenden Vorgaben und verbauter Technik.

Inbetriebnahme-Checkliste: Diese Tests dokumentieren

• 
  Geräteidentität:
  
  erwartete Steuerung, Firmware, Module und Lizenzen vorhanden.
• 
  Konfiguration:
  
  Beschreibungsdateien, Modulreihenfolge, Assemblies und Byte-/Bit-Reihenfolge stimmen mit dem freigegebenen Interface überein.
• 
  Rollen und Adressierung:
  
  jede Schnittstelle arbeitet mit der vorgesehenen Controller/Device- oder Client/Server-Rolle.
• 
  Normaler Handshake:
  
  Programmwahl, Ready, Anfrage, Annahme, Busy und Abschluss stimmen auf beiden Seiten.
• 
  Ungültige Eingaben:
  
  unbekannte Programme, fehlerhafte Werte und widersprüchliche Befehle werden zurückgewiesen oder sicher behandelt.
• 
  Kommunikationsverlust:
  
  Kabeltrennung oder Prozessstopp löst vorgesehene Reaktion und Alarm aus; die Wiederkehr startet keinen Zyklus unerwartet.
• 
  Spannungsrückkehr:
  
  SPS, Roboter und Gateway gleichen Zustände ab und löschen veraltete Anforderungen.
• 
  Datenaktualität:
  
  OPC-UA-/MQTT-Empfänger unterscheiden aktuelle, unterbrochene und veraltete Daten.
• 
  Zugriffskontrolle:
  
  unerlaubte Schreibzugriffe, Broker-Publikationen und Zonenübergänge werden blockiert.
• 
  Sicherheitsvalidierung:
  
  qualifiziertes Personal prüft Sicherheitsfunktionen samt Fehlern und Wiederanlauf eigenständig.

Eine freigegebene Schnittstellenmatrix und Testergebnisse gehören zu Schaltplänen, SPS-Programm und Roboterbackups. Der nächste Techniker sollte die Bedeutung eines Bits nicht erst aus laufender Software rekonstruieren müssen.

Häufige Fragen

Was ist besser: PROFINET oder EtherNet/IP?

Keines ist grundsätzlich besser. Beide eignen sich für viele zyklische SPS-Roboter-Verbindungen. Meist entscheiden vorhandene SPS-Plattform, Schnittstellenoptionen, Engineering-Werkzeuge, Rollen und Serviceanforderungen. Prüfen Sie die konkrete Kombination statt nur nomineller Übertragungswerte.

Ist EtherCAT schneller als PROFINET?

EtherCAT ist auf effizienten deterministischen Datenaustausch und synchronisierte Geräte ausgelegt. Auch PROFINET bietet verschiedene Echtzeitmechanismen einschließlich IRT. Ohne definierte Geräte, Topologie, Zyklen und vollständige Steuerungsaufgabe ist ein pauschales Geschwindigkeitsranking technisch wenig aussagekräftig.

Können SPS und Roboter direkt über OPC UA kommunizieren?

Ja, wenn beide kompatible OPC-UA-Funktionen anbieten und die Anwendung darauf ausgelegt wurde. Ein OPC-UA-Server stellt aber nicht automatisch eine geeignete zyklische Roboter-E/A-Schnittstelle oder validierte Sicherheitskommunikation bereit. Anforderungen und Implementierung müssen konkret geprüft werden.

Kann MQTT einen Industrieroboter starten oder stoppen?

Eine Anwendung kann technisch MQTT-Befehle empfangen. MQTT allein gewährleistet aber weder sichere deterministische Bewegungssteuerung noch einen sicherheitsgerichteten Stopp. Fernbefehle müssen durch Autorisierung, Zustandsprüfungen in SPS/Roboter und validierte Maschinensteuerungen laufen. Sicherheitsfunktionen dürfen nicht von normaler MQTT-Zustellung abhängen.

Können PROFINET, EtherNet/IP und EtherCAT denselben Switch verwenden?

Nicht einfach voraussetzen. Manche PROFINET- und EtherNet/IP-Netze können geeignete gemanagte Industrie-Ethernet-Switches nutzen, unter Beachtung von Protokoll, Timing und Topologie. Der übliche zyklische EtherCAT-Verkehr funktioniert anders und benötigt passende Segmenthardware. Gleiche Kabel bedeuten keine Interoperabilität.

Wozu dienen GSDML-, EDS- und ESI-Dateien?

Diese Beschreibungen stellen Gerätefunktionen für Engineering-Tools bereit:

GSDML

für PROFINET,

EDS

für viele EtherNet/IP-Integrationen und

ESI

für EtherCAT. Sie unterstützen die Konfiguration von Prozessdaten, Parametern und Identität, ersetzen aber keine Prüfung von Firmware, Rollen und Signalbedeutungen.

Fazit: Zuerst die Steuerungsgrenzen festlegen

Für eine Industrieroboterzelle kann eine sinnvolle Ausgangsarchitektur

einen zyklischen Feldbus für Maschinenabläufe, separat validierte Sicherheitsfunktionen, strukturierte OPC-UA-Daten für übergeordnete Systeme und MQTT nur dort umfassen, wo brokerbasierte Ereignisverteilung tatsächlich hilft

. Das ist eine bewährte Denkweise, keine zwingende Universallösung. Entscheidend sind konkrete Schnittstellen, ein eindeutiger Signalvertrag und getestetes Verhalten bei Störungen.

Bevor eine Kommunikationskarte oder Lizenz bestellt wird, ist häufig eine einzige Seite besonders wertvoll:

Wem gehört jedes Signal? Über welches Netzwerk läuft es? Wie lange ist es gültig? Was passiert, wenn es ausbleibt?

Quellen und weitere Prüfung

Für diese Aktualisierung berücksichtigte Primärquellen der Standardisierungsorganisationen:

• 
  PROFIBUS & PROFINET International – PROFINET-Technologie
  
  : Echtzeitvarianten, Diagnose und PROFIsafe.
• 
  PI – GSDML-Spezifikation für PROFINET
  
  : XML-Gerätebeschreibungen und PROFIBUS-GSD.
• 
  ODVA – EtherNet/IP
  
  : CIP-Architektur und zyklische UDP-Kommunikation.
• 
  EtherCAT Technology Group – EtherCAT-Technologie
  
  : On-the-fly-Verarbeitung, Distributed Clocks und Safety.
• 
  ETG – EtherCAT Compendium
  
  : Betriebszustände, Engineering und Umsetzung.
• 
  OPC Foundation – OPC Unified Architecture
  
  : Informationsmodelle und Sicherheitsarchitektur.
• 
  OPC Foundation – OPC UA for Robotics, Part 1
  
  : Version 1.02 vom 8. September 2025.
• 
  OPC Foundation – Field Level Communications / OPC UA FX
  
  .
• 
  OASIS – MQTT Version 5.0
  
  : OASIS-Standard vom 7. März 2019.

Hinweis zur Verifizierung:

Die Quellen belegen Protokollprinzipien und veröffentlichte Spezifikationen, nicht installierte Optionen oder die Kompatibilität beliebiger SPS-Roboter-Paare. Es liegen hier keine Messungen einer konkreten Fabrikanlage vor. Quellenstand: 13. Oktober 2026.

Planen Sie eine Roboter-SPS-Integration?

Beginnen Sie mit exakter Robotersteuerung, SPS-Modell, Firmware, Feldbusoptionen und einer Liste der benötigten Signale. Weitere Leitfäden bietet

AYXWORKS Robotics & Automation

, darunter

kamerageführtes Greifen mit Kalibrierung und Fehlerbehandlung

. Machbarkeit und Zuständigkeiten können mit Eurobots/ReBots besprochen werden; mehr zum Autor steht im

AYXWORKS-Portfolio

.

Diskussion:

Was hat bei Ihrer Inbetriebnahme am meisten Aufwand verursacht: PROFINET-Mapping, EtherNet/IP-Assemblies, EtherCAT-Konfiguration, OPC-UA-Sicherheit oder uneinheitliche MQTT-Payloads?

Abbildung im Artikel: originale AYXWORKS-Erklärungsgrafik. Sie ersetzt keinen projektspezifischen Netzwerkplan. Bildnachweise für separat eingestellte Beitragsbilder entsprechend der tatsächlichen Lizenz beibehalten.