Der Session-Zustand folgt auf den Reset-Zustand beim Aufbau der FSoE-Verbindung. Sein einziger Zweck ist es, ein Paar 16-Bit-Zufallszahlen — die Master Session ID und die Slave Session ID — zwischen den beiden Knoten auszutauschen. Diese IDs haben keine Sicherheitsrelevanz; sie existieren nur, um mehrere Safety-PDU-Sequenzen bei mehreren Neustarts der FSoE-Verbindung zu unterscheiden, sodass eine veraltete PDU einer vorherigen Verbindungsinstanz von einer frischen unterschieden werden kann.
Dieser Artikel behandelt die beiden im Session-Zustand definierten PDUs aus ETG.5100 S (D) V1.2.0, §8.2.2.3, 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 einzigen relevanten Datenbytes sind die beiden Session-ID-Oktetts. In jeder PDU des Session-Zustands tragen
SafeData[0]undSafeData[1](Oktetts 1 und 2) zusammen die 16-Bit Session ID:
- Master → Slave: die Master Session ID (eine vom Master erzeugte Zufallszahl).
- Slave → Master: die Slave Session ID (eine vom Slave erzeugte Zufallszahl, als Quittierung zurückgesendet).
Alle anderen SafeData-Oktetts sind ungenutzt und müssen auf 0 gesetzt werden. Das Conn_Id-Feld ist ebenfalls ungenutzt (auf 0 gesetzt) — die Session ID hat keine Sicherheitsrelevanz, daher wird die Connection ID in diesem Zustand nicht geprüft. Die CRC-Felder werden weiterhin übertragen und müssen verifiziert werden, sie werden jedoch aus dem Reset-Anfangszustand berechnet, da Sequenznummer und geerbter CRC beim Eintritt in den vorangegangenen Reset-Zustand zurückgesetzt wurden (siehe FSoE: Wie funktioniert die CRC-Vererbung? und Wie berechnet man die CRC-Prüfsumme für FSoE-PDUs?).
Wann wird der Session-Zustand betreten und verlassen?
Der Session-Zustand wird betreten, wenn der Master den Reset-Zustand verlässt, indem er eine Safety Master PDU mit dem Session-Befehl sendet. Die Zustandsübergänge sind:
| Richtung | Bedingung |
|---|---|
| Master verlässt Session | Er hat die vollständige Master Session ID übertragen und die zugehörigen Quittierungen vom Slave erhalten, dann sendet er eine Safety PDU mit dem Connection-Befehl. |
| Slave verlässt Session | Er empfängt eine Safety PDU mit dem Connection-Befehl vom Master. |
Beide Knoten verlassen den Session-Zustand außerdem sofort, wenn sie einen FSoE-Kommunikationsfehler erkennen — in diesem Fall fallen sie in den Reset-Zustand zurück.
Master Session PDU (FSoE Master → Slave)
Der Master sendet diese PDU, um seine 16-Bit Master Session ID an den Slave zu übertragen. Das folgende Beispiel ist Tabelle 13 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octet 0 | Master Session Id, octet 0 Octet 1 | Master Session Id, octet 1 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
Wichtige Punkte:
- Command (Oktett 0) ist
Session. - SafeData[0] und SafeData[1] (Oktetts 1 und 2) tragen die beiden Oktetts der 16-Bit Master Session ID. Der Master erzeugt diese einmal pro Verbindungsversuch als Zufallszahl.
- Alle anderen SafeData-Oktetts sind ungenutzt und auf 0 gesetzt.
- Conn_Id ist ungenutzt und auf 0 gesetzt — die Session ID hat keine Sicherheitsrelevanz, daher wird die Connection ID in diesem Zustand nicht geprüft.
- 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 Session PDU (FSoE Slave → Master, Quittierung)
Der Slave quittiert den Session-Befehl, indem er seine eigene 16-Bit Slave Session ID zurücksendet. Dies ist Tabelle 14 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octet 0 | Slave Session Id, octet 0 Octet 1 | Slave Session Id, octet 1 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
Der Slave spiegelt die Session ID des Masters nicht zurück — er antwortet mit seiner selbst erzeugten, unabhängigen Zufalls-Slave Session ID. Beide IDs werden dann zusammen verwendet, um diese bestimmte Verbindungsinstanz zu identifizieren.
Wie viele FSoE-Zyklen dauert die Session-ID-Übertragung?
Die Session ID ist 16 Bit breit und wird in den ersten beiden SafeData-Oktetts der PDU getragen. Die Anzahl der erforderlichen FSoE-Zyklen zur Übertragung hängt daher von der Sicherheitsdatenlänge ab:
| Sicherheitsdatenlänge | Zyklen zur Übertragung der Session ID | Grund |
|---|---|---|
| ≥ 2 Oktetts | 1 Zyklus | Beide Session-ID-Oktetts passen in SafeData[0] und SafeData[1]. |
| 1 Oktett | 2 Zyklen | Nur SafeData[0] ist pro Zyklus verfügbar, sodass die beiden Oktetts in zwei aufeinanderfolgenden PDUs übertragen werden. |
Deshalb verwenden die Beispiele der Spezifikation 4 Oktetts Sicherheitsdaten: Mit 4 Oktetts (oder einer beliebigen Länge ≥ 2) wird die gesamte 16-Bit Session ID in einem einzigen FSoE-Zyklus übertragen.
Zusammenspiel: der Austausch im Session-Zustand
Der Session-Zustand ist ein einfaches zweistufiges Handshake:
- Master → Slave: Safety Master PDU mit
Command = Session, die die Master Session ID inSafeData[0..1]trägt. - Slave → Master: Safety Slave PDU mit
Command = Session, die die Slave Session ID inSafeData[0..1]trägt.
Sobald der Master die vollständige Master Session ID übertragen und die Quittierung(en) des Slaves erhalten hat, verlässt er den Session-Zustand durch Senden einer Safety PDU mit dem Connection-Befehl — dies ist auch das Signal für den Slave, den Session-Zustand zu verlassen. Erkennt ein Knoten während des Austauschs einen FSoE-Kommunikationsfehler, fallen beide in den Reset-Zustand zurück.
Warum ist die Connection ID im Session-Zustand auf 0 gesetzt?
Die Session ID hat keine Sicherheitsrelevanz. Ihr einziger Zweck ist es, mehrere Safety-PDU-Sequenzen bei mehreren Neustarts der FSoE-Verbindung zu unterscheiden — beispielsweise damit eine verzögerte PDU einer vorherigen Verbindungsinstanz nicht für eine PDU der neuen Verbindung gehalten wird. Da eine beschädigte oder vertauschte Session ID für sich allein keine Sicherheitsgefahr verursachen kann, stellt die Spezifikation ausdrücklich fest, dass ein Wechsel im empfangenden Knoten aus Sicherheitsperspektive nicht geprüft werden muss. Folglich ist die Connection ID auf 0 gesetzt für den Session-Befehl — die Verbindung ist noch nicht aufgebaut, daher gibt es keine Connection ID zu prüfen.
Zusammenfassung
Im Session-Zustand ist die FSoE Safety PDU ein zweistelliger Zufallszahlen-Umschlag: Das Command-Feld ist Session, SafeData[0..1] tragen die 16-Bit Master- oder Slave Session ID, jedes andere SafeData-Oktett und das Conn_Id-Feld sind 0, und die CRCs werden aus dem Reset-Anfangszustand berechnet, der vom vorangegangenen Reset-Zustand geerbt wurde. Die Verbindung verlässt Session, wenn der Master den Connection-Befehl aussendet — der Slave sendet niemals zuerst Connection, er quittiert Session nur mit seiner eigenen Slave Session ID. Die Session ID selbst hat keine Sicherheitsrelevanz; sie existiert rein zur Unterscheidung von PDU-Sequenzen über wiederholte Verbindungsneustarts hinweg.
Referenzen
- ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Tabellen 13–14.
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 Connection PDU: Master and Slave Structure — PDU-Layout für den Connection-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