Der Connection-Zustand folgt auf den Session-Zustand beim Aufbau der FSoE-Verbindung. Seine Aufgabe ist es, die 16-Bit Connection ID — einen eindeutigen Bezeichner, der vom Safety-Konfigurator des FSoE-Masters erzeugt wird — zusammen mit der 16-Bit FSoE-Slave-Adresse vom Master zum Slave zu übertragen. Der Slave quittiert dies, indem er dieselben Sicherheitsdaten zurücksendet. Von diesem Punkt an wird die Connection ID im Conn_Id-Feld jeder folgenden Safety PDU übertragen, sodass beide Knoten prüfen können, ob ein Telegramm tatsächlich an sie adressiert ist.
Dieser Artikel behandelt die beiden im Connection-Zustand definierten PDUs aus ETG.5100 S (D) V1.2.0, §8.2.2.4, anhand des kanonischen Beispiels der Spezifikation mit 4 Oktetts Sicherheitsdaten.
Hinweis — die Anzahl der Sicherheitsdaten-Bytes ist pro Richtung festgelegt. Jede FSoE-Verbindung hat eine feste Sicherheitsdatenlänge (Master→Slave und Slave→Master), die auf beiden Knoten identisch konfiguriert ist. Die zulässigen Längen sind 1, 2, 4, 6 oder 8 Oktetts. Die tatsächliche Länge für eine bestimmte Verbindung hängt vom FSoE-Slave-Gerät ab und muss der Dokumentation oder der Gerätebeschreibungsdatei (ESI/EEPROM) des Slaves entnommen werden. Die folgenden Beispiele verwenden wie die Spezifikation 4 Oktetts; das Byte-Layout für andere Längen ist in FSoE Reset PDU: Master- und Slave-Struktur dargestellt.
Hinweis — die relevanten Datenbytes sind die Connection ID und die FSoE-Slave-Adresse. In jeder PDU des Connection-Zustands tragen die vier SafeData-Oktetts zwei 16-Bit-Werte:
SafeData[0..1](Oktetts 1 und 2) — die Connection ID (niedriges Oktett, hohes Oktett). Dies ist ein eindeutiger 16-Bit-Wert, der vom Safety-Konfigurator erzeugt wird;0x0000ist nicht zulässig, sodass bis zu 65 535 FSoE-Verbindungen in einem Kommunikationssystem koexistieren können.SafeData[2..3](Oktetts 5 und 6) — die FSoE-Slave-Adresse (niedriges Oktett, hohes Oktett). Dies ist eine eindeutige Adresse, die am jeweiligen FSoE-Slave-Gerät eingestellt wird.Anders als in den Zuständen Reset und Session ist das
Conn_Id-Feld (Oktetts 9 und 10) nicht mehr 0 — es enthält nun die tatsächliche Connection ID, genau wie in jeder folgenden Safety PDU, sobald die Verbindung aufgebaut ist. Die CRC-Felder werden weiterhin übertragen und müssen verifiziert werden, berechnet aus dem Reset-Anfangszustand, der vom vorangegangenen Reset-Zustand geerbt wurde (siehe FSoE: Wie funktioniert die CRC-Vererbung? und Wie berechnet man die CRC-Prüfsumme für FSoE-PDUs?).
Wann wird der Connection-Zustand betreten und verlassen?
Der Connection-Zustand wird betreten, wenn der Master den Session-Zustand verlässt, indem er eine Safety Master PDU mit dem Connection-Befehl sendet. Die Zustandsübergänge spiegeln die des Session-Zustands wider:
| Richtung | Bedingung |
|---|---|
| Master verlässt Connection | Er hat die vollständige Connection ID und FSoE-Slave-Adresse übertragen und die zugehörige Quittierung vom Slave erhalten, dann sendet er eine Safety PDU mit dem Data-Befehl (Eintritt in den zyklischen Datenaustausch). |
| Slave verlässt Connection | Er empfängt eine Safety PDU mit dem Data-Befehl vom Master. |
Beide Knoten verlassen den Connection-Zustand außerdem sofort, wenn sie einen FSoE-Kommunikationsfehler erkennen — in diesem Fall fallen sie in den Reset-Zustand zurück.
Im Connection-Zustand übertragene Sicherheitsdaten
Vor dem vollständigen PDU-Layout lohnt sich ein Blick auf den Sicherheitsdaten-Anteil. Tabelle 15 von ETG.5100 S (D) V1.2.0 definiert, welche Bytes übertragen werden:
| SafetyData-Oktett | Beschreibung |
|---|---|
| 0 | niedriges Oktett (Bits 0–7) der Connection ID |
| 1 | hohes Oktett (Bits 8–15) der Connection ID |
| 2 | niedriges Oktett (Bits 0–7) der FSoE-Slave-Adresse |
| 3 | hohes Oktett (Bits 8–15) der FSoE-Slave-Adresse |
Connection ID und FSoE-Slave-Adresse sind jeweils 16 Bit breit, belegen zusammen also genau 4 SafeData-Oktetts. Das hat eine wichtige Konsequenz für die Anzahl der erforderlichen FSoE-Zyklen:
| Sicherheitsdatenlänge | Zyklen zur Übertragung von Connection ID + Slave-Adresse | Grund |
|---|---|---|
| 4 Oktetts | 1 Zyklus | Alle 4 Oktetts passen in eine PDU. |
| 2 Oktetts | 2 Zyklen | Nur 2 SafeData-Oktetts pro Zyklus. |
| 1 Oktett | 4 Zyklen | Nur 1 SafeData-Oktett pro Zyklus. |
Deshalb verwenden die Beispiele der Spezifikation 4 Oktetts Sicherheitsdaten: Mit 4 Oktetts werden die gesamte Connection ID und die FSoE-Slave-Adresse in einem einzigen FSoE-Zyklus übertragen.
Master Connection PDU (FSoE Master → Slave)
Der Master sendet diese PDU, um die Connection ID und die FSoE-Slave-Adresse zu übertragen. Das folgende Beispiel ist Tabelle 16 von ETG.5100 S (D) V1.2.0 für 4 Oktetts Sicherheitsdaten.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Wichtige Punkte:
- Command (Oktett 0) ist
Connection. - SafeData[0..1] (Oktetts 1 und 2) tragen die 16-Bit Connection ID (Little-Endian). Dies ist derselbe Wert, der nun auch im
Conn_Id-Feld erscheint. - SafeData[2..3] (Oktetts 5 und 6) tragen die 16-Bit FSoE-Slave-Adresse (Little-Endian). Dies ist die eindeutige, am Slave-Gerät konfigurierte Adresse.
- Conn_Id (Oktetts 9 und 10) trägt die Connection ID — sie ist nicht mehr 0 wie in den Reset- und Session-Zuständen. Ab dieser PDU ist das
Conn_Id-Feld in jeder Safety PDU belegt. - CRC_0 und CRC_1 werden als 16-Bit-Little-Endian-Werte übertragen, berechnet aus dem Reset-Anfangszustand, der vom vorangegangenen Reset-Zustand geerbt wurde.
Slave Connection PDU (FSoE Slave → Master, Quittierung)
Der Slave quittiert den Connection-Befehl, indem er dieselben Sicherheitsdaten zurücksendet — er spiegelt also die Connection ID und die FSoE-Slave-Adresse, die der Master gesendet hat. Dies ist Tabelle 17 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Anders als im Session-Zustand, wo der Slave mit seiner selbst erzeugten Slave Session ID antwortet, spiegelt der Slave im Connection-Zustand die Connection ID und FSoE-Slave-Adresse zurück, die der Master gesendet hat. Damit bestätigt der Slave, dass er die Adressierungsinformationen empfangen und akzeptiert hat.
Warum werden sowohl die Connection ID als auch die FSoE-Slave-Adresse übertragen?
Die beiden Werte haben sich ergänzende Rollen bei der Adressierung:
- Die FSoE-Slave-Adresse ist im Kommunikationssystem eindeutig und wird am jeweiligen FSoE-Slave-Gerät eingestellt. Durch die Übertragung zusammen mit der Connection ID kann der Slave prüfen, ob er tatsächlich adressiert wurde — sodass eine ungültige Adressierung erkannt würde.
- Die Connection ID ist ebenfalls im Kommunikationssystem eindeutig (vom Safety-Konfigurator des FSoE-Masters erzeugt). Da sie eindeutig ist, wird sie im
Conn_Id-Feld jeder folgenden Safety PDU gesendet, sodass sowohl der FSoE-Master als auch der FSoE-Slave erkennen können, ob das Telegramm an sie adressiert ist.
Die Kombination aus beiden bedeutet, dass ein Slave während des Verbindungsaufbaus verifizieren kann, dass er das beabsichtigte Ziel ist (über die FSoE-Slave-Adresse), und während des zyklischen Betriebs beide Knoten jedes Telegramm verifizieren können (über die Connection ID im Conn_Id-Feld).
Wie viele FSoE-Verbindungen sind möglich?
Die Connection ID ist ein 16-Bit-Wert, was nominal 65 536 verschiedene Werte zuließe. Allerdings ist Connection ID = 0x0000 nicht zulässig, sodass die maximale Anzahl an FSoE-Verbindungen in einem Kommunikationssystem 65 535 beträgt. Wenn mehrere FSoE-Master im Kommunikationssystem vorhanden sind, muss der Anwender sicherstellen, dass die von allen Mastern verwendeten Connection IDs im gesamten System eindeutig sind.
Zusammenspiel: der Austausch im Connection-Zustand
Der Connection-Zustand ist ein einfaches Echo-Handshake:
- Master → Slave: Safety Master PDU mit
Command = Connection, die die Connection ID inSafeData[0..1], die FSoE-Slave-Adresse inSafeData[2..3]und die Connection ID imConn_Id-Feld trägt. - Slave → Master: Safety Slave PDU mit
Command = Connection, die dieselbe Connection ID und FSoE-Slave-Adresse zurückspiegelt.
Sobald der Master die vollständige Connection ID und FSoE-Slave-Adresse übertragen und die Quittierung des Slaves erhalten hat, verlässt er den Connection-Zustand durch Senden einer Safety PDU mit dem Data-Befehl — dies überführt die Verbindung in den zyklischen Datenaustausch. Erkennt ein Knoten während des Austauschs einen FSoE-Kommunikationsfehler, fallen beide in den Reset-Zustand zurück.
Zusammenfassung
Im Connection-Zustand trägt die FSoE Safety PDU zwei 16-Bit-Werte in den SafeData-Feldern: die Connection ID (ein eindeutiger systemweiter Bezeichner, der vom Safety-Konfigurator erzeugt wird) und die FSoE-Slave-Adresse (eine eindeutige, am Slave-Gerät eingestellte Adresse). Der Slave quittiert, indem er diese Daten zurückspiegelt. Anders als in den Reset- und Session-Zuständen ist das Conn_Id-Feld nun mit der tatsächlichen Connection ID belegt — und es bleibt in jeder folgenden Safety PDU belegt, sodass beide Knoten verifizieren können, dass jedes Telegramm an sie adressiert ist. Da Connection ID 0x0000 nicht zulässig ist, können bis zu 65 535 FSoE-Verbindungen in einem Kommunikationssystem koexistieren.
Referenzen
- ETG.5100 S (D) V1.2.0, §8.2.2.4 Connection state, Tabellen 15–17.
Verwandte Beiträge
Überblick & Grundlagen
- What does the FSoE abbreviation actually mean? — wofür das FSoE-Akronym steht
- FSoE frame structure explained by examples — allgemeiner Aufbau der Safety PDU
- All the states of the FSoE state machine — die fünf FSoE-Zustände und ihre Übergänge
- FSoE: Safety PDU command table — die vollständige Liste der FSoE-Befehle
PDU-Strukturen nach Zustand
- FSoE Reset State PDU: Master and Slave Structure — PDU-Layout und Fehlercodes für den Reset-Zustand
- FSoE Session PDU: Master and Slave Structure — PDU-Layout für den Session-Zustand
- FSoE Parameter PDU: Master and Slave Structure — PDU-Layout für den Parameter-Zustand
- FSoE Data PDU: Master and Slave Structure — PDU-Layout für den Data-Zustand
- FSoE Reset PDU: Master and Slave Structure — Byte-Layouts für alle Sicherheitsdatenlängen
CRC
- FSoE CRC: Which polynomial does it use? — das 17-Bit-Polynom hinter dem FSoE-CRC
- How are the FSoE CRC tables constructed? — wie die CRC-Lookup-Tabellen erzeugt werden
- FSoE: How does CRC inheritance work? — wie die CRC-Kette aufeinanderfolgende PDUs verknüpft
- How to compute the CRC checksum for FSoE PDUs? — Byte-für-Byte-CRC-Berechnungsalgorithmus
Fehlercodes & Datenformat
- FSoE: List of all communication error codes — alle FSoE-Kommunikationsfehlercodes
- FSoE: Is data transmitted little-endian or big-endian? — Byte-Reihenfolge mehrstelliger Felder