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. 23 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. Maschinenbelegung planen, Ventil schalten) die passende Ebene nennen und meine Wahl begründen.

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

• … zwei Merkmale von Echtzeitdaten erläutern und begründen, in welchem Bereich eines Betriebs eine Echtzeiterfassung nötig ist und wo sie wirtschaftlich nicht sinnvoll ist.

• … 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 vergleichen, je zwei Vorteile nennen und die passende Variante für ein vorhandenes TCP/IP-Netz begründen.

• … die nötigen Anpassungen an Firewall, DHCP und Netzzugangskontrolle beschreiben, wenn ein Modbus-TCP-Gerät ins Firmennetz kommt.

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

• … Entwicklungsziele, Vorteile und Anwendungsbeispiele von EtherCAT nennen bzw. beschreiben und erläutern, unter welcher Voraussetzung EtherCAT-Geräte aus einem normalen IP-Netz erreichbar sind.

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

• … zwei Vorteile von OPC UA PubSub gegenüber dem Client-Server-Modell erläutern.

• … MQTT, OPC UA, Modbus und SNMP anhand von Kriterien (Architektur, Datenmodell, Sicherheit, Ressourcenbedarf, Wartung) kennzeichnen, auch auf Grundlage eines englischen Fachtextes.

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.
• Energieintensive Anlagen sollen nur in bestimmten Zeitfenstern laufen, oder Aufträge sollen nach Lieferterminen und Wartungsfenstern auf Maschinen verteilt werden → Betriebsleitebene (das MES plant den Einsatz von Maschinen und Personal; in kleinen Betrieben übernimmt das manchmal die Prozessleitebene, weil MES und SCADA dort nicht getrennt sind).
• Ein Kundenauftrag wird angenommen und Material bestellt → Unternehmensebene.

Eine Steuerungslogik auf Feld- oder Steuerungsebene wäre für Planungsaufgaben zu spät angesiedelt: Dort ist die Maschine schon in Betrieb. Das ERP hat umgekehrt keinen Einfluss auf den konkreten Maschineneinsatz.

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 es garantiert, dass alle erforderlichen Daten innerhalb einer vorgegebenen Zeitspanne zur Verfügung stehen bzw. verarbeitet sind.

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

Echtzeitdaten unterscheiden sich von anderen Daten vor allem darin,

• dass sie ohne Zeitverzug zur Auswertung zur Verfügung stehen müssen – ein Wert, der zu spät ankommt, ist wertlos, auch wenn er korrekt ist;
• dass sie vor dem nächsten Datensatz ausgewertet sein müssen – sonst stauen sich die Werte, und die Steuerung arbeitet mit veralteten Zuständen;
• dass sie zufällig (Ereignis, z. B. Not-Halt) oder zu festgelegten Zeitpunkten (Zyklus, z. B. alle 1 ms) entstehen und dann sofort verarbeitet werden müssen.

Echtzeiterfassung kostet: schnellere Netze, spezielle Hardware, mehr Daten. Sie lohnt sich dort, wo Verzögerungen Menschen, Maschinen oder Ware gefährden – etwa beim Maschinenschutz, bei der Überwachung einer Kühlkette oder bei der Überhitzung eines Serverraums. Für Trendauswertungen (Energieverbrauch der Woche), die allgemeine Gebäudetechnik (Rollläden, Lüftung) oder vorbeugende Instandhaltung reicht eine zeitversetzte Übertragung.

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

Soll ein Gerät ausschließlich über das vorhandene TCP/IP-Netz angesprochen werden, kommt nur Modbus TCP infrage: RTU kann nicht direkt über TCP/IP übertragen werden, sondern bräuchte ein Gateway (Umsetzer RS-485 ↔︎ Ethernet). Umgekehrt ist ein Gateway der übliche Weg, alte RTU-Geräte in ein Ethernet-Netz zu holen.

Ein Modbus-TCP-Gerät ins Firmennetz bringen

Modbus selbst kennt weder Anmeldung noch Verschlüsselung: Wer Port 502 erreicht, kann Register lesen und schreiben. Wenn Du ein Gerät (z. B. einen Smart Meter) per Ethernet ins Netz bringst, passt Du deshalb mehrere Komponenten an:

• DHCP-Server: eine feste IP-Adresse (Reservierung über die MAC-Adresse) vergeben, damit das Energiemanagementsystem das Gerät immer unter derselben Adresse findet;
• Firewall: TCP-Port 502 (bzw. 802) nur vom Energiemanagementsystem zum Gerät freigeben, alles andere sperren;
• Netzzugangskontrolle (IEEE 802.1X/RADIUS): das Gerät mit einem Gerätezertifikat bzw. Zugangsdaten am RADIUS-Server bekannt machen, damit der Switch-Port es zulässt;
• VLAN: das Gerät in ein eigenes OT-Segment legen.

EtherCAT

EtherCAT (Ethernet for Control Automation Technology, IEC 61158) wurde 2003 von der Firma Beckhoff vorgestellt und wird heute von der EtherCAT Technology Group gepflegt. Die Entwicklungsziele waren, Ethernet für Automatisierungsanwendungen nutzbar zu machen, die

• sehr kurze Zykluszeiten (≤ 100 µs) brauchen,
• einen sehr geringen Jitter (≤ 1 µs) für präzise Synchronisation verlangen und
• dabei geringe Hardwarekosten haben sollen.

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.

Typische Anwendungen sind Maschinensteuerungen mit vielen Achsen: Robotik, Werkzeugmaschinen, Halbleiterfertigung, Metallumformung (Pressen, Biegemaschinen), Verpackungs- und Druckmaschinen, Spritzguss, Montagesysteme – und Energieanlagen wie Windparks oder Batteriespeicher.

EtherCAT und IP-Netze

EtherCAT verwendet einen eigenen Ethertype (0x88A4) direkt auf der Sicherungsschicht – ohne IP. Ein EtherCAT-Segment ist deshalb von einem normalen IP-Netz aus nicht erreichbar. Ist Routing nötig, kann das EtherCAT-Protokoll in UDP/IP-Datagramme gekapselt werden (UDP-Port 34980). Erst dann können Geräte aus einem anderen Netz über Router angesprochen werden – mit dem Nachteil, dass die harte Echtzeit über Router verloren geht.

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). Gegenüber dem Client-Server-Modell hat das Vorteile:

• Entkopplung und Flexibilität: Publisher und Subscriber kennen sich nicht und brauchen keine direkte Verbindung; neue Empfänger kommen hinzu, ohne dass die Steuerung umkonfiguriert wird.
• Skalierbarkeit und geringe Last: Die Steuerung sendet jeden Wert nur einmal (an den Broker bzw. als Multicast), statt für jeden Client eine eigene Sitzung zu bedienen – das schont ihre Ressourcen.
• Verteilte Systeme und Cloud: Daten lassen sich über einen Broker leicht an Edge-Rechner und Cloud-Dienste verteilen.
• One-to-many in Echtzeit: Ohne Broker über UDP und TSN lassen sich viele Steuerungen synchron mit Daten versorgen.

Die Aufgaben des Brokers sind die gleichen wie bei MQTT: Er nimmt Nachrichten der Publisher entgegen und leitet sie an alle Abonnenten des Topics weiter (Nachrichtenübermittlung) und verwaltet die angemeldeten Teilnehmer und ihre Abonnements samt Optionen (Abonnementverwaltung).

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.

In englischen Fachtexten wirst Du die Kriterien so finden: native security features (eingebaute Sicherheit), resource consumption bzw. lightweight (Ressourcenbedarf), standard data model bzw. semantics (Datenmodell), configure, test and troubleshoot (Wartungsaufwand), legacy or proprietary systems (Altsysteme, die ein Gateway brauchen).

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. Auf welcher Ebene planst Du, dass energieintensive Maschinen nur zu bestimmten Zeiten laufen? Antwort

Auf der Betriebsleitebene: Das MES plant den Einsatz von Maschinen und Personal. ERP hat keinen Einfluss auf den konkreten Maschineneinsatz; Steuerungs- und Feldebene sind erst aktiv, wenn die Maschine schon läuft. Sind MES und SCADA nicht getrennt, ist auch die Prozessleitebene möglich. siehe Abschnitt „Welche Ebene ist zuständig?“

3. Was bedeutet Echtzeitfähigkeit bei Netzwerkprotokollen, und welche Merkmale haben Echtzeitdaten? Antwort

Echtzeitfähig ist ein Protokoll, wenn es garantiert, dass alle erforderlichen Daten innerhalb einer vorgegebenen Zeitspanne zur Verfügung stehen (Determinismus, nicht Durchschnittsgeschwindigkeit). Echtzeitdaten müssen ohne Zeitverzug verfügbar und vor dem nächsten Datensatz ausgewertet sein; sie entstehen zufällig oder zu festen Zeitpunkten und müssen dann sofort verarbeitet werden. siehe Abschnitt „Echtzeit in Netzwerken“

4. Wann verwendest Du Modbus RTU, wann Modbus TCP? Antwort

Modbus RTU über RS-485 für lange Strecken, wenig Verdrahtung und Umgebungen ohne Ethernet; Modbus TCP (Port 502), wenn das vorhandene TCP/IP-Netz genutzt werden soll – RTU lässt sich nicht direkt über TCP/IP übertragen, sondern nur über ein Gateway. Für Modbus TCP brauchst Du eine feste IP-Adresse, eine Firewall-Freigabe für Port 502 und ggf. ein Gerätezertifikat für 802.1X. siehe Abschnitt „Modbus“

5. Wie wird EtherCAT echtzeitfähig, und wann ist ein EtherCAT-Gerät aus einem IP-Netz erreichbar? Antwort

Durch „processing on the fly“: Ein Frame durchläuft alle Slaves, jeder liest und schreibt seine Daten im Durchlauf, ohne den Frame erst vollständig zu empfangen; die Verzögerung je Knoten ist minimal. Erreichbar aus einem IP-Netz sind die Geräte nur, wenn das EtherCAT-Protokoll in UDP/IP-Datagramme gekapselt wird (Routingfähigkeit). siehe Abschnitt „EtherCAT“

6. Was unterscheidet OPC UA von MQTT? Antwort

OPC UA hat ein standardisiertes Informationsmodell mit Datentypen, Einheiten und Struktur (semantische Beschreibung) und eingebaute Sicherheit (Zertifikate, Signatur, Verschlüsselung); es arbeitet als Client-Server und zusätzlich mit PubSub. MQTT ist ressourcensparender und einfacher zu konfigurieren und zu warten, hat aber kein Datenmodell und keine eingebaute Sicherheit. siehe Abschnitt „Protokolle vergleichen“

7. Welche Vorteile hat OPC UA PubSub gegenüber dem Client-Server-Modell? Antwort

Publisher und Subscriber sind entkoppelt (keine direkte Verbindung, neue Empfänger ohne Umkonfiguration), die Steuerung wird entlastet, weil sie jeden Wert nur einmal sendet, das System skaliert und lässt sich leicht auf Edge und Cloud verteilen; ohne Broker sind über UDP und TSN auch Echtzeitanwendungen möglich. 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]