Der Parameter-Zustand folgt auf den Connection-Zustand beim Aufbau der FSoE-Verbindung. Seine Aufgabe ist es, die sicherheitsbezogenen Kommunikationsparameter (den FSoE-Watchdog-Wert) und die gerätespezifischen sicherheitsbezogenen Applikationsparameter vom Master zum Slave zu übertragen. Der Slave quittiert jede Parameter-PDU, indem er die Sicherheitsdaten zurückspiegelt. Da die Applikationsparameter eine beliebige Länge haben können, kann die Übertragung mehrere FSoE-Zyklen umfassen. Die CRC-Vererbung stellt die Sicherheit und Konsistenz der Parameterübertragung über alle Zyklen hinweg sicher (siehe FSoE: Wie funktioniert die CRC-Vererbung?).
Dieser Artikel behandelt die im Parameter-Zustand definierten PDUs aus ETG.5100 S (D) V1.2.0, §8.2.2.5, anhand des kanonischen Beispiels der Spezifikation mit 4 Oktetts Sicherheitsdaten und 2 Oktetts sicherheitsbezogenem Applikationsparameter, was zwei FSoE-Zyklen erfordert.
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 folgt demselben Muster (SafeData-Oktetts werden der Reihe nach gefüllt, wobei ungenutzte Oktetts im letzten Zyklus auf 0 gesetzt werden).
Wann wird der Parameter-Zustand betreten und verlassen?
Der Parameter-Zustand wird betreten, wenn der Master den Connection-Zustand verlässt, indem er eine Safety Master PDU mit dem Parameter-Befehl sendet. Die Zustandsübergänge sind:
| Richtung | Bedingung |
|---|---|
| Master verlässt Parameter | Er hat den vollständigen Satz an Kommunikations- und Applikationsparametern übertragen und die zugehörigen Quittierungen vom Slave erhalten, dann sendet er eine Safety PDU mit dem Data-Befehl (Eintritt in den zyklischen Datenaustausch). |
| Slave verlässt Parameter | Er empfängt eine Safety PDU mit dem Data-Befehl vom Master. |
Beide Knoten verlassen den Parameter-Zustand außerdem sofort, wenn sie einen FSoE-Kommunikationsfehler erkennen — in diesem Fall fallen sie in den Reset-Zustand zurück.
Im Parameter-Zustand übertragene Sicherheitsdaten
Die Sicherheitsdaten im Parameter-Zustand sind anders strukturiert als in den vorherigen Zuständen. Statt eines festen Satzes an Feldern tragen sie eine Nutzlast variabler Länge, der drei 16-Bit-Header-Felder vorangehen. Tabelle 18 von ETG.5100 S (D) V1.2.0 definiert das Layout:
| SafetyData-Oktett | Beschreibung |
|---|---|
| 0 | niedriges Oktett (Bits 0–7) der Länge der Kommunikationsparameter in Oktetts (= 2) |
| 1 | hohes Oktett (Bits 8–15) der Länge der Kommunikationsparameter in Oktetts (= 0) |
| 2 | niedriges Oktett (Bits 0–7) des FSoE-Watchdogs (in ms) |
| 3 | hohes Oktett (Bits 8–15) des FSoE-Watchdogs (in ms) |
| 4 | niedriges Oktett (Bits 0–7) der Länge der Applikationsparameter in Oktetts |
| 5 | hohes Oktett (Bits 8–15) der Länge der Applikationsparameter in Oktetts |
| 6 | 1. Oktett des sicherheitsbezogenen Applikationsparameters |
| … | |
| n+5 | n-tes Oktett des sicherheitsbezogenen Applikationsparameters |
Die ersten beiden 16-Bit-Felder sind die Kommunikationsparameterlänge (immer 2, d. h. nur der Watchdog-Wert) und der FSoE-Watchdog-Wert in Millisekunden. Das nächste 16-Bit-Feld ist die Applikationsparameterlänge, gefolgt von den Applikationsparameter-Bytes selbst. Der FSoE-Watchdog und die sicherheitsbezogenen Applikationsparameter werden über den Safety-Konfigurator des FSoE-Masters konfiguriert.
Wie viele FSoE-Zyklen sind erforderlich?
Da die Applikationsparameter eine beliebige Länge haben können, hängt die Gesamtzahl der FSoE-Zyklen sowohl von der Applikationsparameterlänge als auch von der festen Sicherheitsdatenlänge der Safety PDU ab:
$$ \text{Zyklen} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$wobei die 6 die drei 16-Bit-Header-Felder (Kommunikationsparameterlänge, Watchdog, Applikationsparameterlänge) berücksichtigt. Wenn nicht alle Sicherheitsdaten-Oktetts im letzten FSoE-Zyklus benötigt werden, sind die ungenutzten Oktetts als 0 zu übertragen.
Für das Beispiel der Spezifikation (4 Oktetts Sicherheitsdaten, 2 Oktetts Applikationsparameter) beträgt die Gesamtnutzlast 6 + 2 = 8 Oktetts, was in ⌈8/4⌉ = 2 FSoE-Zyklen passt. Der erste Zyklus trägt die Kommunikationsparameterlänge, den Watchdog und die ersten beiden Oktetts wären die Applikationsparameterlänge — in diesem Beispiel wird die Applikationsparameterlänge (2) jedoch im zweiten Zyklus zusammen mit den beiden Applikationsparameter-Bytes gesendet, wie unten gezeigt.
Erster Zyklus — Kommunikationsparameter
Erste Safety Master PDU (FSoE Master → Slave)
Der Master sendet diese PDU, um die Kommunikationsparameterlänge und den FSoE-Watchdog-Wert zu übertragen. Dies ist Tabelle 19 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Wichtige Punkte:
- Command (Oktett 0) ist
Parameter. - SafeData[0..1] (Oktetts 1 und 2) tragen die 16-Bit Kommunikationsparameterlänge in Oktetts. Diese ist immer 2 (Little-Endian:
0x02, 0x00), da der einzige Kommunikationsparameter der 16-Bit-Watchdog-Wert ist. - SafeData[2..3] (Oktetts 5 und 6) tragen den 16-Bit FSoE-Watchdog-Wert in Millisekunden (Little-Endian).
- Conn_Id (Oktetts 9 und 10) trägt die Connection ID — wie im Connection-Zustand ist sie nun in jeder Safety PDU belegt.
- CRC_0 und CRC_1 werden als 16-Bit-Little-Endian-Werte übertragen. Die CRC-Vererbung ist über alle Parameter-Zustands-Zyklen aktiv.
Erste Safety Slave PDU (FSoE Slave → Master, Quittierung)
Der Slave quittiert die erste Parameter-PDU, indem er dieselben Sicherheitsdaten zurückspiegelt. Dies ist Tabelle 20 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Zweiter Zyklus — Applikationsparameter
Der FSoE-Master sendet die zweite Safety Master PDU, sobald er die erste Safety Slave PDU korrekt empfangen hat.
Zweite Safety Master PDU (FSoE Master → Slave)
Der Master sendet diese PDU, um die Applikationsparameterlänge und die Applikationsparameter-Bytes selbst zu übertragen. Dies ist Tabelle 21 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Wichtige Punkte:
- SafeData[0..1] (Oktetts 1 und 2) tragen die 16-Bit Applikationsparameterlänge in Oktetts (Little-Endian). In diesem Beispiel ist sie 2.
- SafeData[2..3] (Oktetts 5 und 6) tragen die Applikationsparameter-Bytes. In diesem Beispiel gibt es genau 2 Bytes, die beide verfügbaren Slots füllen.
- Wenn der Applikationsparameter länger wäre als die verfügbaren SafeData-Oktetts in einem Zyklus, würde die Übertragung in zusätzlichen Zyklen fortgesetzt, wobei die verbleibenden Bytes in denselben SafeData-Positionen platziert werden (beginnend bei SafeData[0] des nächsten Zyklus, nach einem eventuell verbleibenden Header). Ungenutzte Oktetts im letzten Zyklus werden auf 0 gesetzt.
Zweite Safety Slave PDU (FSoE Slave → Master, Quittierung)
Der Slave quittiert die zweite Parameter-PDU, indem er dieselben Sicherheitsdaten zurückspiegelt. Dies ist Tabelle 22 von ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Zusammenspiel: der Austausch im Parameter-Zustand
Der Parameter-Zustand ist ein mehrzykliges Echo-Handshake. Jeder Zyklus folgt demselben Muster:
- Master → Slave: Safety Master PDU mit
Command = Parameter, die den nächsten Abschnitt der Parameternutzlast in den SafeData-Feldern trägt. - Slave → Master: Safety Slave PDU mit
Command = Parameter, die dieselben Sicherheitsdaten zurückspiegelt.
Der Master sendet den nächsten Zyklus erst, nachdem er die Quittierung des Slaves für den vorherigen Zyklus korrekt empfangen hat. Die Übertragung wird fortgesetzt, bis alle Kommunikations- und Applikationsparameter gesendet wurden. Sobald der Master den vollständigen Parametersatz übertragen und die finale Quittierung erhalten hat, verlässt er den Parameter-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.
Warum ist die CRC-Vererbung im Parameter-Zustand wichtig?
Da die Parameterübertragung mehrere FSoE-Zyklen umfasst, bindet die CRC-Vererbung die einzelnen PDUs zu einer einzigen sicherheitsrelevanten Übertragung zusammen. Der CRC jedes Zyklus wird nicht nur über die Bytes der aktuellen PDU berechnet, sondern auch über den CRC der vorherigen PDU — dies bildet eine Kette, die der Empfänger Ende-zu-Ende verifizieren kann. Wenn eine PDU in der Sequenz beschädigt, verloren oder neu geordnet wird, bricht die CRC-Kette ab und der Empfänger erkennt den Fehler. Deshalb stellt die Spezifikation fest, dass „die CRC-Vererbung Sicherheit und konsistente Parameterübertragung gewährleistet". Siehe FSoE: Wie funktioniert die CRC-Vererbung? für die Details des Algorithmus.
Zusammenfassung
Im Parameter-Zustand trägt die FSoE Safety PDU eine Parameternutzlast variabler Länge, der drei 16-Bit-Felder vorangehen: die Kommunikationsparameterlänge (immer 2), den FSoE-Watchdog-Wert in Millisekunden und die Applikationsparameterlänge. Die Applikationsparameter-Bytes folgen. Da die Nutzlast die feste Sicherheitsdatenlänge der PDU überschreiten kann, kann die Übertragung mehrere FSoE-Zyklen umfassen, wobei ungenutzte Oktetts im letzten Zyklus auf 0 gesetzt werden. Der Slave quittiert jeden Zyklus, indem er die Sicherheitsdaten zurückspiegelt. Die CRC-Vererbung über alle Zyklen stellt die Sicherheit und Konsistenz der vollständigen Parameterübertragung sicher. Die Verbindung verlässt den Parameter-Zustand, wenn der Master den Data-Befehl sendet, was den Eintritt in den zyklischen Datenaustausch markiert.
Referenzen
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tabellen 18–22.
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 Connection PDU: Master and Slave Structure — PDU-Layout für den Connection-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