L’état Parameter suit l’état Connection dans la procédure d’établissement de la connexion FSoE. Son rôle est de transférer les paramètres de communication relatifs à la sécurité (la valeur du watchdog FSoE) et les paramètres d’application relatifs à la sécurité spécifiques au dispositif du Master vers le Slave. Le Slave accuse réception de chaque PDU Parameter en renvoyant les données de sécurité. Comme les paramètres d’application peuvent avoir n’importe quelle longueur, le transfert peut s’étaler sur plusieurs cycles FSoE. L’héritage CRC garantit la sécurité et la cohérence du transfert de paramètres sur tous les cycles (voir FSoE : comment fonctionne l’héritage CRC ?).
Cet article passe en revue les PDU de l’état Parameter définis dans ETG.5100 S (D) V1.2.0, §8.2.2.5, en utilisant l’exemple canonique de la spécification avec 4 octets de données de sécurité et 2 octets de paramètre d’application relatif à la sécurité, ce qui nécessite deux cycles FSoE.
Note — le nombre d’octets de données de sécurité est fixe par direction. Chaque connexion FSoE a une longueur de données de sécurité fixe (Master→Slave et Slave→Master), configurée de manière identique sur les deux nœuds. Les longueurs autorisées sont 1, 2, 4, 6 ou 8 octets. La longueur réelle pour une connexion donnée dépend du dispositif FSoE Slave et doit être extraite de la documentation du Slave ou du fichier de description du dispositif (ESI/EEPROM). Les exemples ci-dessous utilisent 4 octets comme dans la spécification ; la disposition des octets pour les autres longueurs suit le même schéma (les octets SafeData sont remplis dans l’ordre, les octets inutilisés du dernier cycle étant mis à 0).
Quand entre-t-on et sort-on de l’état Parameter ?
L’état Parameter est entré lorsque le Master quitte l’état Connection en envoyant un Safety Master PDU avec la commande Parameter. Les transitions d’état sont :
| Direction | Condition |
|---|---|
| Le Master quitte Parameter | Il a transféré l’ensemble complet des paramètres de communication et d’application, et reçu les accusés de réception associés du Slave, puis envoie un Safety PDU avec la commande Date (entrant dans l’échange cyclique de données). |
| Le Slave quitte Parameter | Il reçoit un Safety PDU avec la commande Date du Master. |
Les deux nœuds quittent également l’état Parameter immédiatement s’ils détectent une erreur de communication FSoE — dans ce cas, ils reviennent à l’état Reset.
Données de sécurité transférées dans l’état Parameter
Les données de sécurité dans l’état Parameter sont structurées différemment des états précédents. Au lieu d’un ensemble fixe de champs, elles transportent une charge utile de longueur variable précédée de trois champs d’en-tête 16 bits. La Table 18 d’ETG.5100 S (D) V1.2.0 définit la disposition :
| Octet SafeData | Description |
|---|---|
| 0 | octet bas (bits 0–7) de la longueur des paramètres de communication en octets (= 2) |
| 1 | octet haut (bits 8–15) de la longueur des paramètres de communication en octets (= 0) |
| 2 | octet bas (bits 0–7) du watchdog FSoE (en ms) |
| 3 | octet haut (bits 8–15) du watchdog FSoE (en ms) |
| 4 | octet bas (bits 0–7) de la longueur des paramètres d’application en octets |
| 5 | octet haut (bits 8–15) de la longueur des paramètres d’application en octets |
| 6 | 1er octet du paramètre d’application relatif à la sécurité |
| … | |
| n+5 | n-ième octet du paramètre d’application relatif à la sécurité |
Les deux premiers champs 16 bits sont la longueur des paramètres de communication (toujours 2, c’est-à-dire uniquement la valeur du watchdog) et la valeur du watchdog FSoE en millisecondes. Le champ 16 bits suivant est la longueur des paramètres d’application, suivie des octets du paramètre d’application eux-mêmes. Le watchdog FSoE et les paramètres d’application relatifs à la sécurité sont configurés via le safety configurator du FSoE Master.
Combien de cycles FSoE sont nécessaires ?
Comme les paramètres d’application peuvent avoir n’importe quelle longueur, le nombre total de cycles FSoE dépend à la fois de la longueur du paramètre d’application et de la longueur fixe des données de sécurité du Safety PDU :
$$ \text{cycles} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$où le 6 correspond aux trois champs d’en-tête 16 bits (longueur des paramètres de communication, watchdog, longueur des paramètres d’application). Si tous les octets de données de sécurité ne sont pas requis dans le dernier cycle FSoE, les octets inutilisés doivent être transférés comme 0.
Pour l’exemple de la spécification (4 octets de données de sécurité, 2 octets de paramètre d’application), la charge utile totale est de 6 + 2 = 8 octets, ce qui tient dans ⌈8/4⌉ = 2 cycles FSoE. Le premier cycle transporte la longueur des paramètres de communication, le watchdog, et les deux premiers octets seraient la longueur du paramètre d’application — mais dans cet exemple, la longueur du paramètre d’application (2) est envoyée dans le second cycle avec les deux octets du paramètre d’application, comme illustré ci-dessous.
Premier cycle — Paramètres de communication
Premier Safety Master PDU (FSoE Master → Slave)
Le Master envoie ce PDU pour transférer la longueur des paramètres de communication et la valeur du watchdog FSoE. Il s’agit de la Table 19 d’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 | long. param. comm., bas Octet 1 — = 2 | long. param. comm., haut Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, bas Octet 5 — en ms | watchdog, haut Octet 6 — en ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, bas Octet 9 | Connection Id, haut Octet 10 |
Points clés :
- Command (octet 0) est
Parameter. - SafeData[0..1] (octets 1 et 2) transportent la longueur des paramètres de communication 16 bits en octets. C’est toujours 2 (little-endian :
0x02, 0x00), car le seul paramètre de communication est la valeur du watchdog 16 bits. - SafeData[2..3] (octets 5 et 6) transportent la valeur du watchdog FSoE 16 bits en millisecondes (little-endian).
- Conn_Id (octets 9 et 10) transporte le Connection ID — comme dans l’état Connection, il est désormais renseigné dans chaque Safety PDU.
- CRC_0 et CRC_1 sont transmis comme valeurs 16 bits little-endian. L’héritage CRC est actif sur tous les cycles de l’état Parameter.
Premier Safety Slave PDU (FSoE Slave → Master, accusé de réception)
Le Slave accuse réception du premier PDU Parameter en renvoyant les mêmes données de sécurité. Il s’agit de la Table 20 d’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 | long. param. comm., bas Octet 1 — = 2 | long. param. comm., haut Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, bas Octet 5 — en ms | watchdog, haut Octet 6 — en ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, bas Octet 9 | Connection Id, haut Octet 10 |
Second cycle — Paramètres d’application
Le FSoE Master envoie le second Safety Master PDU une fois qu’il a correctement reçu le premier Safety Slave PDU.
Second Safety Master PDU (FSoE Master → Slave)
Le Master envoie ce PDU pour transférer la longueur des paramètres d’application et les octets du paramètre d’application eux-mêmes. Il s’agit de la Table 21 d’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 | long. param. app., bas Octet 1 — = 2 | long. param. app., haut Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | param. app., octet 1 Octet 5 | param. app., octet 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, bas Octet 9 | Connection Id, haut Octet 10 |
Points clés :
- SafeData[0..1] (octets 1 et 2) transportent la longueur des paramètres d’application 16 bits en octets (little-endian). Dans cet exemple, elle vaut 2.
- SafeData[2..3] (octets 5 et 6) transportent les octets du paramètre d’application. Dans cet exemple, il y a exactement 2 octets, remplissant les deux emplacements disponibles.
- Si le paramètre d’application était plus long que les octets SafeData disponibles dans un cycle, le transfert continuerait dans des cycles supplémentaires, les octets restants étant placés dans les mêmes positions SafeData (à partir de SafeData[0] du cycle suivant, après tout en-tête restant). Les octets inutilisés du dernier cycle sont mis à 0.
Second Safety Slave PDU (FSoE Slave → Master, accusé de réception)
Le Slave accuse réception du second PDU Parameter en renvoyant les mêmes données de sécurité. Il s’agit de la Table 22 d’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 | long. param. app., bas Octet 1 — = 2 | long. param. app., haut Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | param. app., octet 1 Octet 5 | param. app., octet 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, bas Octet 9 | Connection Id, haut Octet 10 |
Synthèse : l’échange de l’état Parameter
L’état Parameter est un handshake par écho sur plusieurs cycles. Chaque cycle suit le même schéma :
- Master → Slave : Safety Master PDU avec
Command = Parameter, transportant le prochain fragment de la charge utile des paramètres dans les champs SafeData. - Slave → Master : Safety Slave PDU avec
Command = Parameter, renvoyant les mêmes données de sécurité.
Le Master n’envoie le cycle suivant qu’après avoir correctement reçu l’accusé de réception du Slave du cycle précédent. Le transfert continue jusqu’à ce que tous les paramètres de communication et d’application aient été envoyés. Une fois que le Master a transféré l’ensemble complet des paramètres et reçu l’accusé de réception final, il quitte l’état Parameter en envoyant un Safety PDU avec la commande Date — cela fait passer la connexion dans l’échange cyclique de données. Si l’un des nœuds détecte une erreur de communication FSoE pendant l’échange, les deux reviennent à l’état Reset.
Pourquoi l’héritage CRC est-il important dans l’état Parameter ?
Comme le transfert de paramètres s’étale sur plusieurs cycles FSoE, l’héritage CRC est ce qui relie les PDU individuels en un seul transfert pertinent pour la sécurité. Le CRC de chaque cycle est calculé non seulement sur les octets du PDU courant, mais aussi sur le CRC du PDU précédent — formant une chaîne que le récepteur peut vérifier de bout en bout. Si un PDU de la séquence est corrompu, perdu ou réordonnancé, la chaîne CRC se rompt et le récepteur détecte l’erreur. C’est pourquoi la spécification note que « l’héritage CRC garantit la sécurité et la cohérence du transfert de paramètres ». Consultez FSoE : comment fonctionne l’héritage CRC ? pour les détails de l’algorithme.
Résumé
Dans l’état Parameter, le Safety PDU FSoE transporte une charge utile de paramètres de longueur variable précédée de trois champs 16 bits : la longueur des paramètres de communication (toujours 2), la valeur du watchdog FSoE en millisecondes, et la longueur des paramètres d’application. Les octets du paramètre d’application suivent. Comme la charge utile peut dépasser la longueur fixe des données de sécurité du PDU, le transfert peut s’étaler sur plusieurs cycles FSoE, les octets inutilisés du dernier cycle étant mis à 0. Le Slave accuse réception de chaque cycle en renvoyant les données de sécurité. L’héritage CRC sur tous les cycles garantit la sécurité et la cohérence du transfert complet des paramètres. La connexion quitte l’état Parameter lorsque le Master envoie la commande Date, entrant dans l’échange cyclique de données.
Références
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tables 18–22.
Articles liés
Vue d’ensemble & notions de base
- FSoE : Que signifie réellement cette abréviation ? — ce que signifie l’acronyme FSoE
- FSoE : structure de trame expliquée par exemples — disposition générale du Safety PDU
- FSoE : tous les états de la machine à états — les cinq états FSoE et leurs transitions
- FSoE : table des commandes Safety PDU — la liste complète des commandes FSoE
Structures PDU par état
- FSoE Reset State PDU : structure Master et Slave — disposition du PDU et codes d’erreur pour l’état Reset
- FSoE Session PDU : structure Master et Slave — disposition du PDU pour l’état Session
- FSoE Connection PDU : structure Master et Slave — disposition du PDU pour l’état Connection
- FSoE Date PDU : structure Master et Slave — disposition du PDU pour l’état Date
- FSoE Reset PDU : structure Master et Slave — dispositions d’octets pour toutes les longueurs de données de sécurité
CRC
- FSoE CRC : quel polynôme utilise-t-il ? — le polynôme 17 bits derrière le CRC FSoE
- FSoE : Comment sont construites les tables CRC ? — comment les tables de lookup CRC sont générées
- FSoE: How does CRC inheritance work? — comment la chaîne CRC relie les PDU consécutifs
- Comment calculer la somme de contrôle CRC pour les PDU FSoE ? — algorithme de calcul CRC octet par octet
Codes d’erreur & format des données
- FSoE : liste de tous les codes d’erreur de communication — tous les codes d’erreur de communication FSoE
- FSoE : les données sont-elles transmises en little-endian ou big-endian ? — ordre des octets des champs multi-octets