Industrielle Kommunikation: Automatisierungspyramide, Echtzeit, Modbus, EtherCAT und OPC UA

Industrielle Kommunikation: Automatisierungspyramide, Echtzeit, Modbus, EtherCAT und OPC UA

https://bildung.social/@oerinformatik/

https://oer-informatik.de/industrielle-kommunikation

Industrie 4.0, Automatisierungspyramide, OT, Echtzeit, Feldbus, Industrial Ethernet, Modbus, EtherCAT, OPC UA, PubSub, MQTT, IEC 62443

tl/dr; (ca. 25 min Lesezeit): In einer Fabrik reden Sensoren, Steuerungen, Leitstände und ERP-System miteinander – aber nicht alle in derselben Sprache und nicht alle gleich schnell. Du lernst die Automatisierungspyramide mit ihren fünf Ebenen kennen und erfährst, was Echtzeit für ein Netzwerkprotokoll bedeutet. Danach geht es um drei Protokolle, die Dir in der Industrie ständig begegnen: das alte, einfache Modbus (RTU und TCP), das schnelle EtherCAT mit seinem Prinzip „processing on the fly“ und OPC UA mit seinem Informationsmodell, das auch Publish/Subscribe beherrscht. Zum Schluss vergleichst Du die Protokolle mit MQTT und SNMP und erfährst, wie Du die Produktionsnetze absicherst [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Teil einer Artikelreihe zu vernetzten Systemen: MQTT: Publish/Subscribe, Topics, Wildcards und QoS / Industrielle Kommunikation / Übungsaufgaben zur industriellen Kommunikation

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste des Artikels MQTT: Publish/Subscribe, Topics, Wildcards und QoS auf.

Als Grundlagen der industriellen Kommunikation kann ich nach Durchlesen des Artikels…

• … die fünf Ebenen der Automatisierungspyramide nennen, ihnen typische Systeme (Sensor, SPS, SCADA, MES, ERP) zuordnen und den Unterschied zwischen IT und OT erläutern.

• … für eine Funktion (z. B. Eilauftrag einplanen, Ventil schalten, Alarm quittieren) entscheiden, welche Ebene sie übernimmt, und dabei Zeitanforderung und benötigten Überblick abwägen.

• … erläutern, was Echtzeitfähigkeit bei Netzwerkprotokollen bedeutet, und harte von weicher Echtzeit unterscheiden.

• … Datenströme eines Betriebs danach einordnen, ob sie harte, weiche oder gar keine Echtzeit brauchen, und dabei Nutzen und Kosten der Echtzeiterfassung abwägen.

• … die Protokolle Modbus, EtherCAT und OPC UA ihrem typischen Einsatz zuordnen.

Darüber hinaus kann ich als Profilwissen für vernetzte Systeme…

• … Modbus RTU und Modbus TCP nach Bitübertragung, Adressierung und Geschwindigkeit vergleichen und ein RTU-Gerät über ein Gateway erreichbar machen.

• … den Weg eines Modbus-TCP-Geräts vom Anstecken bis zur ersten Abfrage planen und dabei Adressvergabe, Netzzugang und Filterregeln absichern.

• … das Kernprinzip „processing on the fly“ erläutern, mit dem EtherCAT echtzeitfähig wird.

• … an einer Beispielrechnung zeigen, warum ein EtherCAT-Zyklus mit vielen Teilnehmern kurz bleibt, und erklären, warum EtherCAT ohne IP auskommt und was das für den Zugriff aus anderen Netzen bedeutet.

• … das Informationsmodell von OPC UA beschreiben und erläutern, warum OPC UA (wie MQTT) als zustandshaltend gilt.

• … die Zahl der Verbindungen bei Client-Server und bei PubSub mit Broker vergleichen und daraus Vor- und Nachteile von OPC UA PubSub ableiten.

• … für eine Kommunikationsbeziehung im Betrieb zwischen MQTT, OPC UA, Modbus und SNMP auswählen und die Wahl mit Kommunikationsmuster, Datenbeschreibung, Absicherung und Aufwand begründen.

In einer Rahmenfertigung biegt eine Maschine Aluminiumrohre, ein Roboter schweißt sie zusammen, ein Ofen brennt die Pulverbeschichtung ein. Jede Anlage hat eine eigene Steuerung, und jede Steuerung hat Dutzende Sensoren und Antriebe. Gleichzeitig will die Produktionsleitung wissen, welcher Auftrag gerade wo steckt, und der Einkauf will wissen, wie viele Rohre noch auf Lager sind. All diese Systeme müssen Daten austauschen – aber mit sehr unterschiedlichen Anforderungen: Der Roboter braucht seine Positionswerte in Mikrosekunden, das Lagersystem kommt mit einer Meldung pro Stunde aus. Deshalb gibt es in der Industrie nicht das eine Protokoll, sondern eine Schichtung von Systemen und Protokollen.

Die Automatisierungspyramide

Die Automatisierungspyramide ordnet die Systeme eines produzierenden Betriebs in Ebenen. Unten liegen sehr viele einfache Geräte, die sehr schnell reagieren müssen; nach oben werden es weniger Systeme, die mehr Daten zusammenfassen und in längeren Zeiträumen planen. Ein verwandtes Ebenenmodell beschreibt die Norm IEC 62264 (Integration von Unternehmens- und Leitsystemen, bekannt als ISA-95); die Pyramide selbst wird je nach Quelle mit fünf oder sechs Ebenen dargestellt. Verbreitet ist die folgende Einteilung:

Die fünf Ebenen der Automatisierungspyramide

Nr.	Ebene	Typische Systeme	Aufgabe	Zeithorizont
1	Unternehmensebene	ERP (Enterprise Resource Planning)	Aufträge annehmen, Material und Personal grob planen, Kosten und Bestände führen	Tage bis Wochen
2	Betriebsleitebene	MES (Manufacturing Execution System)	Aufträge in Arbeitsschritte zerlegen, Maschinen feinplanen und belegen, Auftragsfortschritt und Qualitätsdaten erfassen	Stunden bis Minuten
3	Prozessleitebene	SCADA (Supervisory Control and Data Acquisition), Leitstand, HMI	Anlagen bedienen und beobachten, Alarme anzeigen, Messwerte archivieren	Sekunden
4	Steuerungsebene	SPS (speicherprogrammierbare Steuerung), Roboter-, CNC-Steuerung	Ein- und Ausgänge zyklisch verarbeiten, Abläufe steuern und regeln	Millisekunden
5	Feldebene	Sensoren, Aktoren, Antriebe, Ein-/Ausgabemodule	Messen (z. B. Lichtschranke, Temperaturfühler) und Stellen (z. B. Ventil, Motor)	Mikro- bis Millisekunden

Merke Dir die Richtung der Informationen: nach oben werden Daten erfasst und verdichtet (aus tausend Messwerten wird „Auftrag 1041 ist fertig geschweißt“), nach unten fließen Planungen und Vorgaben (aus „Auftrag 1041 bis Freitag“ wird „Schweißzelle 2 startet um 7:15 Uhr Programm 17“).

Welche Ebene ist zuständig?

Um eine Funktion einer Ebene zuzuordnen, fragst Du: Wie schnell muss reagiert werden, und wie viel Überblick braucht die Entscheidung?

• Eine Lichtschranke erkennt ein Werkstück, und das Förderband soll sofort stoppen → Steuerungsebene (die SPS reagiert im Zyklus; die Lichtschranke selbst gehört zur Feldebene).
• Ein Bediener soll im Leitstand sehen, dass der Ofen zu heiß wird, und ihn quittieren → Prozessleitebene.
• Ein Eilauftrag soll in die Reihenfolge der Frühschicht eingeschoben werden, ohne dass andere Rahmen ihren Termin verpassen → Betriebsleitebene (das MES kennt alle offenen Arbeitsschritte und den Belegungsplan jeder Anlage; wo es kein eigenes MES gibt, wandert diese Aufgabe in die Leitstand-Software).
• Ein Kundenauftrag wird angenommen und Material bestellt → Unternehmensebene.

Für Planung sind die beiden unteren Ebenen ungeeignet: Eine SPS kennt nur ihre eigene Anlage und den aktuellen Zyklus, nicht die Warteschlange der nächsten Stunden. Das ERP sieht zwar Liefertermine, plant aber in Tagen und Wochen und kennt weder Rüstzeiten noch den aktuellen Zustand einer Schweißzelle. Die passende Ebene ist die, deren Zeithorizont zur Entscheidung passt und die alle betroffenen Anlagen überblickt.

IT und OT

Die oberen Ebenen (ERP, oft auch MES) gehören klassisch zur IT (Informationstechnik), die unteren (Feld, Steuerung, häufig auch SCADA) zur OT (Operational Technology, Betriebstechnik). OT-Systeme laufen oft 15 bis 20 Jahre, dürfen nicht einfach für ein Update neu starten und sind für Verfügbarkeit und Echtzeit gebaut – nicht für Vertraulichkeit. Mit Industrie 4.0 verschwimmt die Pyramide: Sensoren melden Daten direkt an eine Cloud, und eine SPS spricht mit dem MES über OPC UA. Man spricht deshalb auch von einer vernetzten Automatisierung oder von „Automatisierungssäulen“. Das Ebenenmodell bleibt trotzdem hilfreich, um Aufgaben und Zeitanforderungen zuzuordnen.

Echtzeit in Netzwerken

Im Alltag heißt „Echtzeit“ oft einfach „schnell“. In der Automatisierung ist es genauer:

Ein System ist echtzeitfähig, wenn für jede Übertragung bzw. Verarbeitung eine Frist festgelegt ist und das System nachweisbar zusagt, sie in jedem Fall einzuhalten – auch bei Volllast. (Die Norm DIN 44300 beschrieb den Echtzeitbetrieb ähnlich: Ergebnisse müssen innerhalb einer vorgegebenen Zeitspanne verfügbar sein.)

Es kommt also nicht auf die durchschnittliche Geschwindigkeit an, sondern auf die Vorhersagbarkeit (Determinismus). Ein Netz, das meistens nach 1 ms, aber gelegentlich erst nach 200 ms liefert, ist nicht echtzeitfähig – auch wenn es im Mittel schnell ist. Wichtige Begriffe:

• Zykluszeit: Zeit, in der alle Teilnehmer einmal ihre Daten ausgetauscht haben (z. B. 1 ms).
• Latenz: Verzögerung zwischen Senden und Empfangen.
• Jitter: Schwankung der Latenz bzw. der Zykluszeit. Für synchronisierte Antriebe muss der Jitter sehr klein sein (unter 1 µs).
• Harte Echtzeit: Eine überschrittene Frist ist ein Fehler mit Folgen (Roboterarm kollidiert, Schutztür öffnet zu spät). Weiche Echtzeit: Eine überschrittene Frist mindert nur die Qualität (Videobild ruckelt, Messwert im Dashboard kommt später).

Die Grafik zeigt den Unterschied an erfundenen Beispielwerten: Das Standardnetz liefert meist schneller als die Frist, verpasst sie aber zweimal deutlich; das echtzeitfähige Netz hält sie in jedem Zyklus ein, mit kaum messbarem Jitter.

Merkmale von Echtzeitdaten

Woran erkennst Du, dass Daten echtzeitkritisch sind? Drei Fragen helfen:

• Verfällt der Wert? Eine Achsposition von vor 5 ms ist für die Regelung nutzlos, auch wenn sie stimmt. Ein Monatszählerstand ist morgen noch genauso brauchbar.
• Kommt der nächste Wert schon bald? Bei zyklischen Daten muss die Verarbeitung mit dem Takt Schritt halten; wer langsamer auswertet als gemessen wird, schiebt eine wachsende Warteschlange vor sich her.
• Was passiert bei Verspätung? Hängt daran Sicherheit (Person in der Roboterzelle) oder nur Komfort (Diagramm im Dashboard aktualisiert sich später)?

Ob ein Wert regelmäßig im Takt oder unvorhersehbar als Ereignis (Lichtgitter unterbrochen) entsteht, ändert nichts an der Frist: Auch das Ereignis muss rechtzeitig beim Empfänger sein.

Echtzeit hat ihren Preis: abgestimmte Netzkomponenten, eigene Hardware, viele kleine Datenpakete. In der Rahmenfertigung lohnt sie sich etwa für die Positionsregelung der Biegeachsen oder das Lichtgitter am Schweißroboter. Für den Pulvervorrat in der Beschichtung, die Luftfeuchte im Rohrlager oder den Stromverbrauch pro Schicht reicht es völlig, wenn die Werte gesammelt und alle paar Minuten übertragen werden.

Warum Standard-Ethernet nicht reicht

Klassisches Ethernet mit TCP/IP ist nicht deterministisch: Switches puffern Frames in Warteschlangen, bei hoher Last kommen Pakete verzögert an, TCP wiederholt verlorene Segmente und liefert sie erst in der richtigen Reihenfolge aus. Für Echtzeitdaten wird deshalb oft UDP statt TCP genutzt (ein verlorener alter Messwert wird nicht wiederholt, der nächste ist ohnehin aktueller), oder man setzt ganz auf spezielle Industrial-Ethernet-Protokolle bzw. auf TSN (Time-Sensitive Networking, IEEE 802.1), das Ethernet um Zeitplanung und reservierte Zeitschlitze erweitert.

Feldbusse und Industrial Ethernet im Überblick

Früher wurden Feldgeräte über Feldbusse mit eigener Verkabelung (meist RS-485) angeschlossen, z. B. Modbus RTU oder PROFIBUS. Heute setzt sich Industrial Ethernet durch: Ethernet-Hardware (Kabel, Stecker, Bitübertragung nach IEEE 802.3), aber mit Protokollen, die Echtzeit garantieren. Die wichtigsten Vertreter sind in der Normenreihe IEC 61158 zusammengefasst.

Ausgewählte Protokolle der industriellen Kommunikation

Protokoll	Medium	Echtzeit	Typischer Einsatz
Modbus RTU	seriell (RS-485)	eingeschränkt, langsam	Zähler, Frequenzumrichter, einfache Sensoren
Modbus TCP	Ethernet, TCP/IP	nein (TCP)	Energiezähler, Gateways, Anbindung an Leitsysteme
EtherCAT	Ethernet (eigenes Protokoll)	hart, sehr kurze Zyklen	Antriebe, Robotik, Werkzeugmaschinen
PROFINET, EtherNet/IP	Ethernet	weich bis hart (je nach Klasse)	Fertigungsanlagen, SPS-Vernetzung
OPC UA	TCP/IP, UDP, MQTT	nein (mit TSN: ja)	Maschine zu MES/ERP, herstellerübergreifend

Modbus

Modbus wurde 1979 für Steuerungen entwickelt und ist bis heute weit verbreitet, weil es einfach, offen und lizenzfrei ist. Ein Client (früher: Master) fragt, ein Server (früher: Slave) antwortet. Die Daten liegen in vier Tabellen mit festen Adressen: Coils (Bits, les- und schreibbar), Discrete Inputs (Bits, nur lesbar), Input Register (16-Bit-Werte, nur lesbar) und Holding Register (16-Bit-Werte, les- und schreibbar). Ein Energiezähler stellt z. B. die Wirkleistung in den Holding Registern 3000 und 3001 bereit; welches Register was bedeutet, steht nur im Handbuch des Geräts – ein Datenmodell mit Bedeutung gibt es nicht.

Modbus RTU und Modbus TCP im Vergleich

	Modbus RTU	Modbus TCP
Übertragung	seriell, meist RS-485 (Zweidrahtleitung als Bus)	Ethernet, Modbus-Nachricht in TCP/IP verpackt
Port	–	TCP-Port 502 (mit TLS: Modbus/TCP Security, Port 802)
Adressierung	Geräteadresse 1–247 am Bus	IP-Adresse (plus Unit-ID für Geräte hinter Gateways)
Vorteile	große Leitungslängen (bis ca. 1.200 m), wenig Verdrahtung (ein Bus für viele Geräte), funktioniert ohne Ethernet, robust und günstig	nutzt vorhandenes Ethernet und Netzwerktechnik, höhere Datenrate, mehrere Clients gleichzeitig, über Router erreichbar, leicht in Leit- und Energiemanagementsysteme einzubinden
Nachteile	langsam (typisch 9.600–115.200 bit/s), nur ein Client am Bus	100-m-Grenze je Kupfersegment, keine harte Echtzeit

Die beiden Varianten unterscheiden sich schon auf der Bitübertragungsschicht: RTU-Frames laufen als serielle Zeichen über eine RS-485-Zweidrahtleitung, Modbus-TCP-Nachrichten stecken in Ethernet-Frames. Ein RTU-Gerät lässt sich deshalb nicht einfach an einen Switch stecken. Altgeräte holst Du über ein Gateway ins Ethernet: Es spricht auf der einen Seite RS-485, auf der anderen Modbus TCP und reicht Anfragen anhand der Unit-ID an das passende Gerät am Bus weiter.

Ein Modbus-TCP-Gerät ins Firmennetz bringen

Modbus selbst kennt weder Anmeldung noch Verschlüsselung: Wer Port 502 erreicht, kann Register lesen und auch schreiben. Verfolge deshalb den Weg eines neuen Geräts (z. B. eines Frequenzumrichters an einer Absauganlage) vom Anstecken bis zur ersten Abfrage:

1. Anstecken: Der Switch-Port lässt das Gerät erst ins Netz, wenn es sich per IEEE 802.1X ausgewiesen hat – bei Industriegeräten meist mit einem Gerätezertifikat, ersatzweise über die MAC-Adresse (MAB). Der Authentisierungsserver weist es dabei gleich dem OT-VLAN zu.
2. Adresse erhalten: Das Gerät braucht eine Adresse, die sich nie ändert, denn der Client fragt es über die IP-Adresse ab. Dafür trägst Du es statisch ein oder legst im DHCP eine Reservierung an.
3. Erste Abfrage: Zwischen Leitsystem und OT-Segment filtert eine Firewall. Freigegeben wird nur die eine Richtung vom abfragenden System zum Gerät auf TCP 502 (bzw. 802 mit TLS); Schreibzugriffe lassen sich mit Modbus-fähigen Firewalls zusätzlich auf erlaubte Funktionscodes beschränken.

EtherCAT

EtherCAT (Ethernet for Control Automation Technology, IEC 61158) wurde 2003 von der Firma Beckhoff vorgestellt und wird heute von der EtherCAT Technology Group (ETG) gepflegt. Laut ETG sollte es Ethernet für Maschinensteuerungen tauglich machen: Zyklen im Bereich von 100 µs und darunter, Synchronisation der Teilnehmer auf deutlich unter eine Mikrosekunde genau und dabei Kosten auf dem Niveau klassischer Feldbusse.

Processing on the fly

Bei normalem Ethernet empfängt jedes Gerät einen Frame vollständig, prüft ihn, verarbeitet ihn und schickt eine Antwort. Bei vielen Teilnehmern summieren sich diese Verzögerungen. EtherCAT macht es anders:

• Der Master (die Steuerung) schickt einen einzigen Frame, der Datenbereiche für alle Teilnehmer enthält.
• Jeder Slave liest die für ihn bestimmten Daten und fügt seine eigenen ein, während der Frame durch ihn hindurchläuft („processing on the fly“). Der Frame wird nicht erst vollständig empfangen und dann weitergeleitet, sondern nur um wenige Nanosekunden verzögert. Das übernimmt ein eigener Chip (EtherCAT Slave Controller), nicht die CPU des Geräts.
• Der letzte Slave schickt den Frame zurück zum Master (logischer Ring über die Vollduplex-Leitungen, physisch eine Linie, ein Baum oder ein Stern).

Dadurch ist die Verarbeitungszeit je Teilnehmer winzig und gut vorhersagbar, und die Bandbreite wird fast vollständig für Nutzdaten verwendet. Über Distributed Clocks (vergleichbar mit dem Precision Time Protocol IEEE 1588) laufen die Uhren aller Teilnehmer synchron.

Vorteile und Einsatz

• Sehr kurze Zykluszeiten (≤ 100 µs) und sehr geringer Jitter (≤ 1 µs) – auch für viele synchronisierte Antriebe;
• geringe Hardwarekosten: Standard-Ethernet-Kabel (100BASE-TX, bis 100 m je Segment; 100BASE-FX über Glasfaser für längere Strecken) und keine Switches zwischen den Slaves nötig;
• flexible Topologie (Linie, Baum, Stern, Ring mit Redundanz) mit bis zu 65.535 Teilnehmern;
• hohe Nutzdatenrate, weil ein Frame viele Teilnehmer bedient;
• Diagnose: Fehlerstellen lassen sich genau lokalisieren.

EtherCAT spielt seine Stärken überall dort aus, wo viele Achsen im Gleichtakt laufen müssen – in der Rahmenfertigung etwa bei den Biegemaschinen. Weitere Beispiele sind Holzbearbeitungszentren, Prüfstände, Medizintechnik (z. B. Patientenliegen in Großgeräten), Bühnentechnik oder Lagerlifte.

EtherCAT und IP-Netze

EtherCAT-Frames tragen einen eigenen Ethertype (0x88A4) und haben keinen IP-Kopf. Ein Router entscheidet aber anhand der Ziel-IP-Adresse, wohin ein Paket geht – mit einem reinen EtherCAT-Frame kann er nichts anfangen. Für Zugriffe über Netzgrenzen sieht der Standard daher eine Variante vor, bei der die EtherCAT-Daten als Nutzlast in UDP (Port 34980) über IP transportiert werden. Häufiger ist in der Praxis ein anderer Weg: Die Steuerung (der Master) hat zusätzlich eine normale Netzwerkschnittstelle und gibt Diagnosedaten z. B. per OPC UA weiter. In beiden Fällen gilt: Über Router und Büronetz ist keine harte Echtzeit mehr garantiert.

OPC UA

OPC UA (Open Platform Communications Unified Architecture, IEC 62541) ist der herstellerunabhängige Standard für den Datenaustausch zwischen Maschinen und zwischen Maschine und IT (MES, ERP, Cloud). Eine Server-Adresse sieht so aus: opc.tcp://mes01.example:4840 – das Anwendungsprotokoll heißt OPC UA Binary über TCP (opc.tcp), der Standardport ist 4840.

Das Informationsmodell

Der große Unterschied zu Modbus oder MQTT: OPC UA überträgt nicht nur Werte, sondern beschreibt sie. Jeder Server stellt einen Adressraum aus Knoten (Nodes) bereit, z. B.

• Objekt Einbrennofen1 mit den Variablen Objekttemperatur und Sollwert,
• je Variable: Datentyp (Double), Einheit (°C), Zeitstempel und Statuscode (gut/unsicher/schlecht), dazu Lese- und Schreibrechte,
• Methoden wie StarteProgramm(nr) und Ereignisse wie Alarme.

Als Ausschnitt aus dem Adressraum sieht das so aus:

Ein Client kann diesen Adressraum durchsuchen (Browse) und versteht die Daten, ohne das Handbuch des Herstellers zu kennen. Branchenverbände legen sogenannte Companion Specifications fest, z. B. für Roboter oder Spritzgießmaschinen, sodass Maschinen verschiedener Hersteller gleich aussehen. Man spricht von semantischer Beschreibung der Nutzdaten.

Client-Server, Sitzungen und Sicherheit

Im klassischen Modell baut ein Client (z. B. das MES) eine Verbindung zum Server (z. B. der SPS) auf. Darüber laufen ein sicherer Kanal (Secure Channel) und eine Sitzung (Session). In der Sitzung legt der Client Subscriptions an: Er teilt dem Server mit, welche Werte er beobachten will, und der Server meldet nur Änderungen.

Deshalb ist OPC UA – wie MQTT – zustandshaltend: Die Verbindung bleibt bestehen, und der Server merkt sich über die einzelne Anfrage hinaus den Zustand der Sitzung (wer angemeldet ist, welche Werte abonniert sind, welche Meldungen schon zugestellt wurden). HTTP dagegen ist zustandslos: Jede Anfrage steht für sich, der Server vergisst den Client nach der Antwort.

Sicherheit ist eingebaut: Anwendungen weisen sich mit X.509-Zertifikaten aus, Nachrichten werden signiert und/oder verschlüsselt, Benutzer melden sich an und erhalten Rechte je Knoten.

OPC UA PubSub

Seit Version 1.04 (2018) kennt OPC UA zusätzlich das Modell PubSub (Publish/Subscribe). Ein Publisher veröffentlicht Datensätze, Subscriber empfangen sie – entweder über einen Broker (z. B. MQTT oder AMQP) oder ohne Broker per UDP-Multicast (dann auch zusammen mit TSN für Echtzeit). Den Unterschied siehst Du am besten durch Zählen: Wollen 4 Anwendungen die Daten von 6 Steuerungen haben, braucht Client-Server 4 · 6 = 24 Sitzungen, und jede Steuerung bedient 4 davon. Mit Broker hält jede Steuerung genau eine Verbindung, jede Anwendung ebenfalls eine – zusammen 10. Daraus ergibt sich:

• Eine neue Anwendung kostet die Steuerungen keine zusätzliche Last und keine Änderung an ihrer Konfiguration; sie abonniert einfach beim Broker.
• Sender und Empfänger müssen sich nicht kennen, nicht einmal gleichzeitig online sein. Das erleichtert die Weitergabe an Edge-Rechner und Cloud-Dienste.
• Ohne Broker, per UDP-Multicast und TSN, erreicht ein Datensatz viele Empfänger gleichzeitig – auch für Echtzeitaufgaben zwischen Steuerungen.
• Der Preis: Der Broker ist ein zusätzliches System, das ausfallen kann, abgesichert und betrieben werden muss.

Wie bei MQTT ist der Broker die Verteilstelle: Er weiß, wer welche Daten abonniert hat, stellt jede eingehende Nachricht genau diesen Empfängern zu, prüft beim Anmelden Identität und Rechte und hält Nachrichten auf Wunsch für später verbundene Empfänger bereit.

Protokolle vergleichen

In der Praxis kombinierst Du die Protokolle: EtherCAT unter der SPS, Modbus für Zähler und Altgeräte, OPC UA von der SPS zum MES, MQTT für Dashboards und Cloud, SNMP für die Überwachung der Netzwerkgeräte.

Wenn Du englische Herstellerunterlagen oder die OPC-UA-Spezifikation liest, begegnen Dir dieselben Kriterien etwa als information model und address space (Datenbeschreibung), security mode Sign/SignAndEncrypt (Absicherung), footprint (Ressourcenbedarf) oder gateway für die Anbindung älterer Geräte.

Produktionsnetze absichern

Viele OT-Protokolle (Modbus, ältere Feldbusse) wurden für abgeschottete Netze entworfen und haben keine eigene Sicherheit. Ein Angriff auf Switches oder Steuerungen kann Befehle verfälschen, Echtzeitdaten verzögern oder die Kommunikation lahmlegen – mit Folgen für Menschen und Maschinen. Die Normenreihe IEC 62443 beschreibt, wie Industrieanlagen abgesichert werden. Wichtige Maßnahmen:

• Segmentierung in Zonen (VLAN IT, VLAN OT) mit Firewalls dazwischen (Conduits); oft eine Industrie-DMZ zwischen Büro- und Produktionsnetz;
• nur benötigte Ports freigeben (z. B. 502 nur vom Leitsystem);
• Netzzugangskontrolle (802.1X), verwaltete (managed) Industrie-Switches statt unmanaged;
• verschlüsselte Protokolle bevorzugen (OPC UA mit Sign & Encrypt, MQTT über TLS, Modbus/TCP Security), Fernwartung nur per VPN;
• Monitoring des OT-Verkehrs, um ungewöhnliche Schreibbefehle zu erkennen.

Leitfragen

1. Welche fünf Ebenen hat die Automatisierungspyramide, und welche Systeme gehören dazu? Antwort

Von oben: Unternehmensebene (ERP), Betriebsleitebene (MES), Prozessleitebene (SCADA, Leitstand), Steuerungsebene (SPS, Robotersteuerung), Feldebene (Sensoren, Aktoren). Nach oben werden Daten erfasst und verdichtet, nach unten fließen Planungen und Vorgaben. siehe Abschnitt „Die Automatisierungspyramide“

2. Ein Eilauftrag soll in die laufende Schicht eingeschoben werden. Welche Ebene entscheidet über die neue Reihenfolge, und warum nicht die SPS? Antwort

Die Betriebsleitebene (MES): Sie plant im Stunden- und Minutenbereich und überblickt die Belegung aller Anlagen. Die SPS sieht nur ihre eigene Anlage und den aktuellen Zyklus; das ERP plant zu grob und kennt den Anlagenzustand nicht. Ohne eigenes MES übernimmt die Leitstand-Software diese Aufgabe. siehe Abschnitt „Welche Ebene ist zuständig?“

3. Ein Netz liefert im Mittel nach 0,8 ms, in seltenen Fällen nach 150 ms. Ist es echtzeitfähig? Antwort

Nein, wenn die Frist z. B. 2 ms beträgt: Echtzeit verlangt, dass die Frist in jedem Fall eingehalten wird, auch bei Volllast. Entscheidend ist die garantierte Höchstzeit (Determinismus), nicht der Mittelwert. Ob ein Datenstrom Echtzeit braucht, hängt davon ab, wie schnell der Wert verfällt, wie dicht der nächste Wert folgt und was eine Verspätung anrichtet. siehe Abschnitt „Echtzeit in Netzwerken“

4. Wie erreicht ein Leitsystem im Ethernet einen alten Zähler, der nur Modbus RTU beherrscht, und was ist beim Einbinden eines Modbus-TCP-Geräts zu beachten? Antwort

Über ein Gateway, das RS-485 und Ethernet verbindet und Anfragen über die Unit-ID an das richtige Gerät am Bus weitergibt. Ein Modbus-TCP-Gerät braucht eine unveränderliche Adresse, wird über 802.1X ins OT-VLAN gelassen und ist nur über eine enge Firewall-Regel (TCP 502 vom abfragenden System) erreichbar, weil Modbus selbst weder Anmeldung noch Verschlüsselung kennt. siehe Abschnitt „Modbus“

5. Warum bleibt ein EtherCAT-Zyklus auch mit vielen Teilnehmern kurz, und warum kann ein Router EtherCAT-Frames nicht weiterleiten? Antwort

Ein einziger Frame bedient alle Slaves; jeder liest und schreibt seine Daten, während der Frame ihn durchläuft („processing on the fly“), und hält ihn nur Nanosekunden auf, statt ihn erst vollständig zu empfangen. EtherCAT-Frames haben keinen IP-Kopf, ein Router findet darin also keine Zieladresse. Über Netzgrenzen hilft der UDP-Transport der EtherCAT-Daten oder eine Diagnoseschnittstelle des Masters. siehe Abschnitt „EtherCAT“

6. Was unterscheidet OPC UA von MQTT? Antwort

OPC UA beschreibt jeden Wert im Informationsmodell mit Typ, Einheit, Zeitstempel und Status, sodass ein Client ihn ohne Handbuch versteht; Zertifikate, Signatur und Verschlüsselung gehören zum Protokoll. Es arbeitet mit Sitzungen (Client-Server) und zusätzlich mit PubSub. MQTT überträgt dagegen beliebige Bytes unter einem Topic: Das macht es schlank genug für Mikrocontroller, die Bedeutung der Daten und die Absicherung über TLS musst Du aber selbst festlegen. siehe Abschnitt „Protokolle vergleichen“

7. Wie viele Verbindungen braucht es, wenn 3 Anwendungen die Daten von 5 Steuerungen lesen – einmal mit Client-Server, einmal mit Broker? Antwort

Client-Server: 3 · 5 = 15 Sitzungen, jede Steuerung bedient 3. Mit Broker: 5 + 3 = 8 Verbindungen, jede Steuerung genau eine. Neue Anwendungen belasten die Steuerungen deshalb nicht; dafür kommt mit dem Broker ein zusätzliches System hinzu, das betrieben und abgesichert werden muss. siehe Abschnitt „OPC UA PubSub“

8. Warum gilt OPC UA als zustandshaltend? Antwort

Client und Server halten eine dauerhafte Verbindung mit Sitzung; der Server merkt sich über die einzelne Anfrage hinaus, wer angemeldet ist, welche Werte abonniert sind und was schon zugestellt wurde. HTTP vergisst den Client dagegen nach jeder Antwort. siehe Abschnitt „Client-Server, Sitzungen und Sicherheit“

Links und weitere Informationen

• Übungen: Übungsaufgaben zur industriellen Kommunikation

• Voraussetzung: MQTT: Publish/Subscribe, Topics, Wildcards und QoS, OSI- und TCP/IP-Modell, Protokolle und Ports

• weiterführend: VLAN und Netzsegmentierung, Verschlüsselung und TLS

• als Nachschlagewerk: OPC Foundation – OPC UA, EtherCAT Technology Group – Technik, Modbus Organization – Spezifikationen

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Industrielle Kommunikation: Automatisierungspyramide, Echtzeit, Modbus, EtherCAT und OPC UA” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/industrielle-kommunikation veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/mcu/iot-grundlagen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]