ISO/OSI-Modell – Netzwerkgrundlagen für Siemens SPS

Warum ein Schichtenmodell?

Damit Geräte verschiedener Hersteller miteinander kommunizieren können, wurde die Kommunikation in sieben aufeinander aufbauende Schichten zerlegt – das ISO/OSI-Referenzmodell (ISO 7498, «Open Systems Interconnection»). Jede Schicht erfüllt genau eine klar abgegrenzte Aufgabe und nutzt dabei die Dienste der Schicht darunter.

Analogie Briefpost: Der Briefinhalt (Nutzdaten) interessiert die Post nicht. Der Umschlag mit Adresse (Schicht 3), der Sortiercode im Verteilzentrum (Schicht 2) und der Lastwagen auf der Autobahn (Schicht 1) arbeiten unabhängig voneinander – und lassen sich einzeln austauschen, ohne dass der Briefinhalt geändert werden muss.

Genau das ist der praktische Nutzen in der Automatisierung: Ein PROFINET-Telegramm bleibt identisch, egal ob es über Kupfer, Lichtwellenleiter oder WLAN übertragen wird – nur Schicht 1 wechselt.

Virtuelle und reale Kommunikation

Jede Schicht «spricht» logisch mit der gleichen Schicht der Gegenstelle (gestrichelte Pfeile). Real laufen die Daten aber im Sender nach unten, über das Übertragungsmedium und im Empfänger wieder nach oben.

Merkhilfe (Schicht 7 → 1): Alle deutschen Studenten trinken verschiedene Sorten Bier.
Anwendung – Darstellung – Sitzung – Transport – Vermittlung – Sicherung – Bitübertragung

Zwei Welten in einer Schichtung

Schicht 5–7: Anwendungsorientiert

Legt fest, was übertragen wird und wie die Daten zu interpretieren sind. Hier liegen PROFINET IO, die S7-Kommunikation, OPC UA und der CPU-Webserver.

Schicht 1–4: Transportorientiert

Regelt, wie die Daten zum Ziel gelangen: Kabel, MAC-Adressen, IP-Adressen, Ports. Diese Schichten sind bei Ethernet für alle Protokolle gleich.

Wichtig für die Praxis: Nicht jedes Industrieprotokoll benutzt alle sieben Schichten. Der zyklische PROFINET-RT-Verkehr ist ein Schicht-2-Verfahren: Die Schichten 3 bis 7 werden dafür nicht verwendet – deshalb ist RT schnell, aber nicht routingfähig. Details dazu im Tab «Siemens & PROFINET».

Übersicht der sieben Schichten

Nr.	Schicht (DE)	Schicht (EN)	Dateneinheit	Typisch bei Siemens
7	Anwendungsschicht	Application	Daten	PROFINET-IO-Dienste, S7-Protokoll, OPC-UA-Dienste, SNMP
6	Darstellungsschicht	Presentation	Daten	Big Endian, String / WString, OPC-UA-Codierung
5	Sitzungsschicht	Session	Daten	logische Sitzungen, z.B. OPC-UA-Session
4	Transportschicht	Transport	Segment	TCP, UDP, Port 102 mit TSAP bei ISO-on-TCP, OPC UA 4840
3	Vermittlungsschicht	Network	Paket	IP-Adresse, Subnetzmaske, Router, ping
2	Sicherungsschicht	Data Link	Rahmen (Frame)	MAC, PROFINET RT/IRT, DCP, LLDP, MRP
1	Bitübertragungsschicht	Physical	Bit	100BASE-TX, RJ45 / M12, LWL, RS-485

Die 7 Schichten im Detail

Schicht anklicken – die Erklärung mit Siemens-Bezug erscheint darunter.

Anwendungsorientierte Schichten

Welche Schichten nutzt welches Protokoll?

Ein Protokoll auswählen – im Turm werden die genutzten Schichten farbig dargestellt, übersprungene Schichten ausgegraut.

Der Trick von PROFINET: zwei Kanäle über eine Leitung

Auf derselben PROFINET-Leitung laufen gleichzeitig Echtzeit- und Standard-Ethernet-Telegramme. Der Unterschied liegt darin, wie tief sie den Protokollstapel durchlaufen.

Echtzeitkanal (RT / IRT)

Zyklische Prozessdaten gehen direkt auf Schicht 2. Kennung im Ethernet-Rahmen: EtherType 0x8892, dahinter die Frame-ID. Kein IP-, kein TCP-Header – dadurch kurze, gleichmässige Laufzeiten und ein deutlich kleineres Telegramm. Ebenfalls direkt auf Ethernet: DCP, LLDP, MRP und PTCP.

Standardkanal (TCP/UDP-IP)

Für die TCP/IP-basierten Dienste – Webserver, OPC UA, Zugriff des Programmiergerätes sowie die azyklischen PROFINET-Dienste über RPC auf UDP – wird der IP-Stapel genutzt. Diese Daten sind routingfähig, aber zeitlich nicht deterministisch.

Konsequenz für die Projektierung: Weil RT-Telegramme keinen IP-Header besitzen, können sie von einem Router nicht in ein anderes Subnetz weitergeleitet werden. IO-Controller und IO-Device müssen im selben Ethernet-Subnetz liegen. Nur die TCP/IP-basierten Dienste (z.B. Zugriff des Programmiergerätes, Webserver) sind routbar.

Und wie koppelt man dann zwei Anlagenteile? Das I-Device. Weil sich RT-Verkehr nicht über Schicht 3 weiterleiten lässt, erfolgt die Kopplung nicht über Routing, sondern auf Anwendungsebene. Eine CPU kann als I-Device projektiert werden: Gegenüber dem übergeordneten IO-Controller verhält sie sich wie ein ganz normales IO-Device – zyklischer RT-Austausch auf Schicht 2, Identifikation über Gerätename und DCP, ebenfalls Schicht 2. Gleichzeitig kann dieselbe CPU nach unten IO-Controller für ihre eigenen unterlagerten Geräte sein.

Aus Sicht des Schichtenmodells kommt dabei nichts Neues hinzu – neu ist allein die Rolle. Wichtig für die Praxis: Ein I-Device ist kein Gateway. Der übergeordnete Controller sieht die unterlagerten Geräte nicht und kann nicht auf sie zugreifen. Der Datenaustausch läuft ausschliesslich über die projektierten Transferbereiche, deren Inhalte im Anwenderprogramm zwischen dem Prozessabbild und dem Transferbereich kopiert werden müssen.

Protokolle und Ports im Siemens-Umfeld

Protokoll / Dienst	Schicht	Port / Kennung	Verwendung
PROFINET RT	2	EtherType 0x8892	Zyklischer Austausch der IO-Daten (Prozessabbild)
PROFINET IRT	2	EtherType 0x8892, reservierte Sendephase	Taktsynchroner Betrieb, Motion Control
DCP	2	EtherType 0x8892	Gerätename und IP vergeben, «Erreichbare Teilnehmer», LED blinken
LLDP	2	EtherType 0x88CC	Nachbarschaftserkennung, Topologie, Gerätetausch ohne Wechselmedium
MRP	2	EtherType 0x88E3	Medienredundanz im Ring (Umschaltzeit typ. 200 ms)
PTCP	2	EtherType 0x8892	Synchronisation der Sendetakte für IRT
ARP	2/3	EtherType 0x0806	MAC-Adresse zu einer IP-Adresse ermitteln
ICMP (ping)	3	–	Erreichbarkeit prüfen
Offene Kommunikation (TCP / UDP)	4	frei wählbar, Vorschlag im TIA Portal: 2000	TSEND_C/TRCV_C und TUSEND/TURCV zu SPS, PC oder Fremdgerät
ISO-on-TCP (RFC 1006)	4	TCP 102, Adressierung über TSAP	Transportdienst für die S7-Kommunikation und TSEND_C/TRCV_C
S7-Protokoll	7	über ISO-on-TCP	PUT/GET, BSEND/BRCV, HMI-Kopplung
OPC UA	4–7	TCP 4840	Herstellerunabhängiger Datenaustausch, Server in der S7-1500
Modbus TCP	4 und 7	TCP 502	Anbindung von Fremdgeräten
HTTP / HTTPS	4 und 7	TCP 80 / 443	Webserver der CPU
SNMP	4 und 7	UDP 161 / 162	Netzwerkdiagnose, Auslesen durch Netzmanagement-Tools
PROFINET azyklisch (RPC)	3–7	UDP 34962–34964	Verbindungsaufbau, Datensätze lesen/schreiben, Parametrierung, Alarme

Bezug zum TIA Portal

Beim Projektieren einer offenen Kommunikation entscheidet der gewählte Verbindungstyp direkt darüber, welche Schichten benutzt werden: TCP nutzt Schicht 4 mit frei wählbarem Port, ISO-on-TCP adressiert die Verbindungsendpunkte zusätzlich über TSAPs – ebenfalls auf Schicht 4 –, UDP arbeitet verbindungslos.

Portnummer bei der offenen Kommunikation: Beim Verbindungstyp TCP oder UDP schlägt das TIA Portal in den Verbindungsparametern standardmässig Port 2000 vor. Das ist kein reservierter oder standardisierter Port, sondern lediglich ein Vorschlag – die Nummer ist frei wählbar, muss aber auf beiden Seiten übereinstimmen. Zu vermeiden sind die von der CPU bereits belegten Ports, unter anderem 80 und 443 (Webserver), 102 (ISO-on-TCP), 161/162 (SNMP), 4840 (OPC UA) und 34962 bis 34964 (PROFINET).

// Offene Kommunikation über ISO-on-TCP (RFC 1006, TCP-Port 102)
// Der TSAP wird in der Verbindungsprojektierung hinterlegt (Schicht 4).
"TSEND_C_DB"(REQ := sendeAnstoss,
    CONT := TRUE,
    CONNECT := "Verbindung_ISO_on_TCP",
    DATA := "DatenDB".Sendepuffer,
    DONE => sendeFertig,
    ERROR => sendeFehler,
    STATUS => sendeStatus);

Merksatz: IP-Adresse = Schicht 3 (welches Gerät im Netz) · TCP-Port und TSAP = Schicht 4 (welcher Dienst im Gerät) · PROFINET-Gerätename = Identifikation über DCP auf Schicht 2 (welches IO-Device der Controller anspricht).

Datenkapselung – wie das Telegramm entsteht

Auf dem Weg nach unten ergänzt jede Schicht ihre eigenen Steuerinformationen (Header). Der Empfänger entfernt sie in umgekehrter Reihenfolge wieder. Diesen Vorgang nennt man Kapselung.

Vergleich des Protokoll-Overheads

Bestandteil	S7 über ISO-on-TCP	PROFINET RT
Ethernet-Header + FCS (Schicht 2)	ja (14 + 4 Byte)	ja (14 + 4 Byte, meist mit VLAN-Tag 4 Byte)
IP-Header (Schicht 3)	ja (20 Byte)	entfällt
TCP-Header (Schicht 4)	ja (20 Byte)	entfällt
TPKT / COTP (Schicht 4, RFC 1006)	ja (7 Byte)	entfällt
Kennung im Telegramm	S7-Header (Schicht 7)	Frame-ID (2 Byte) + APDU-Status (4 Byte), Schicht 2
Zeitverhalten	nicht deterministisch	deterministisch, Aktualisierungszeit projektierbar
Über Router übertragbar	ja	nein

Rechenbeispiel: Ein IO-Device mit 8 Byte Eingangsdaten überträgt im RT-Telegramm rund 60 Byte auf dem Kabel. Über den vollen TCP/IP-Stapel wären allein für die Header rund 50 Byte zusätzlich nötig – bei einer projektierten Aktualisierungszeit von 1 ms und vielen Teilnehmern ein erheblicher Unterschied in der Netzlast. Die Werte gelten für dieses Beispiel; die tatsächliche Aktualisierungszeit hängt von Projektierung, Gerät und Netzauslastung ab.

Fehlersuche entlang der Schichten

Die wirksamste Diagnosestrategie im Anlagenbetrieb: immer von unten nach oben prüfen. Ohne Schicht 1 nützt die korrekte IP-Adresse nichts.

Schicht	Typisches Fehlerbild	Prüfen mit
1 – Bitübertragung	Keine Link-LED, sporadische Ausfälle, hohe Fehlerzähler an einem Port	Link-LED am Gerät und Switch, Kabel und Stecker, Port-Statistik im CPU-Webserver, Leitungslänge max. 100 m bei Kupfer
2 – Sicherung	IO-Device bleibt im Fehler, obwohl es im Netz sichtbar ist; Topologiefehler; Ring öffnet nicht	PROFINET-Gerätenamen mit der Projektierung vergleichen (DCP), «Erreichbare Teilnehmer» in TIA, MAC-Adresse am Gerät, Topologiesicht (LLDP), MRP-Rolle Manager/Client, Duplexeinstellung
3 – Vermittlung	Programmiergerät findet die CPU nicht, obwohl Link vorhanden ist; ping antwortet sprunghaft	IP-Adresse und Subnetzmaske vergleichen, Router-Eintrag prüfen, `ping` absetzen, auf doppelt vergebene IP-Adressen prüfen
4 – Transport	ping funktioniert, Verbindung schlägt trotzdem fehl	Portnummer auf beiden Seiten vergleichen (Vorschlag TIA Portal: 2000), Firewall bzw. Portfreigabe (TCP 102, 2000, 4840, 502), Verbindungstyp prüfen, bei ISO-on-TCP die TSAPs beider Partner vergleichen
5 – Sitzung	Verbindung wird abgewiesen oder bricht nach kurzer Zeit ab	Anzahl projektierter Verbindungen gegen die Verbindungsressourcen der CPU prüfen, bei OPC UA die Session-Einstellungen und Zertifikate
6 – Darstellung	Verbindung steht, Werte sind aber unplausibel oder «verdreht»	Byte-Reihenfolge (S7 arbeitet mit Big Endian), Datentypen und Strukturlängen beider Partner vergleichen
7 – Anwendung	Verbindungsaufbau des IO-Device schlägt fehl, Baugruppe wird als «nicht projektiert» gemeldet, Datensatzaufträge werden mit Fehler quittiert	Bestellnummer und Firmwarestand, Steckplatzbelegung und projektierte Datenlängen gegen die Hardwarekonfiguration vergleichen

Was ein erfolgreicher ping beweist – und was nicht

Der ping ist das meistgenutzte Diagnosemittel und gleichzeitig das am häufigsten überschätzte. Er nutzt ICMP auf Schicht 3 und weist damit nach: Die Leitung trägt (Schicht 1), der Rahmen kommt an (Schicht 2) und ein Gerät antwortet unter dieser IP-Adresse (Schicht 3).

Der ping beweist

Die Schichten 1 bis 3 funktionieren bis zu dem Gerät, das geantwortet hat.

Der ping beweist nicht

Dass es das richtige Gerät ist – und dass die Schichten 4 bis 7 funktionieren.

Fall	ping	Kommunikation	Ursache
Doppelte IP-Adresse im Netz	erfolgreich	gestört oder sprunghaft	Es antwortet ein anderes Gerät als das erwartete – typisch nach einem Gerätetausch mit vorbelegter Adresse (Schicht 3)
Unterschiedliche Subnetzmaske bei den Partnern	im selben Segment erfolgreich	über den Router hinaus gestört	Das Gerät hält den entfernten Partner für lokal und antwortet nicht über den Router (Schicht 3)
Portnummer stimmt nicht überein	erfolgreich	Verbindungsaufbau schlägt fehl	Bei der offenen Kommunikation muss der Port auf beiden Seiten gleich sein (Schicht 4)
Port durch Firewall gesperrt	erfolgreich	kein Verbindungsaufbau	ICMP ist erlaubt, TCP 102 oder 2000 nicht (Schicht 4)
Verbindungsressourcen der CPU erschöpft	erfolgreich	Verbindung wird abgewiesen	Zu viele gleichzeitige Verbindungen projektiert (Schicht 5)
CPU in STOP oder Baustein wird nicht aufgerufen	erfolgreich	keine Daten	Die Schnittstelle antwortet, die Anwendung sendet aber nicht (Schicht 7)
PROFINET-Gerätename falsch	erfolgreich	IO-Device bleibt im Fehler	Der Controller identifiziert das Device über DCP, nicht über die IP-Adresse (Schicht 2)

Merksatz: Ein erfolgreicher ping heisst nur, dass irgendein Gerät unter dieser IP-Adresse erreichbar ist. Ein fehlgeschlagener ping ist dagegen sehr aussagekräftig: Dann liegt der Fehler mit hoher Wahrscheinlichkeit in den Schichten 1 bis 3, und alles darüber muss gar nicht erst geprüft werden.

Verdacht auf doppelte IP-Adresse prüfen: Das betreffende Gerät vom Netz trennen und erneut pingen. Antwortet die Adresse weiterhin, ist ein zweites Gerät mit derselben IP-Adresse im Netz. Ergänzend zeigt «Erreichbare Teilnehmer» im TIA Portal alle Geräte mit MAC-Adresse, Gerätename und IP-Adresse – unabhängig davon, ob die IP-Adresse zum eigenen Subnetz passt.

Der häufigste Praxisfall

«Die IP-Adresse stimmt, das Gerät läuft trotzdem nicht an.»
Der PROFINET-Gerätename ist eine PROFINET-spezifische Identifikation auf Basis von DCP und damit auf Schicht 2 angesiedelt. Der IO-Controller identifiziert sein IO-Device über diesen Namen und weist die IP-Adresse anschliessend über DCP zu. Stimmt der Gerätename nicht mit der Projektierung überein, bleibt das Device im Fehler – unabhängig davon, welche IP-Adresse eingestellt ist.

Faustregel für den Serviceeinsatz: Link-LED → «Erreichbare Teilnehmer» → ping → Gerätename. Wer diese Reihenfolge einhält, findet den überwiegenden Teil der PROFINET-Störungen in wenigen Minuten.

Quiz – ISO/OSI in der Automatisierung

Antwort anklicken. Die Auswertung erfolgt sofort.