FSoE Parameter PDU : structure Master et Slave

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 :

DirectionCondition
Le Master quitte ParameterIl 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 ParameterIl 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 SafeDataDescription
0octet bas (bits 0–7) de la longueur des paramètres de communication en octets (= 2)
1octet haut (bits 8–15) de la longueur des paramètres de communication en octets (= 0)
2octet bas (bits 0–7) du watchdog FSoE (en ms)
3octet haut (bits 8–15) du watchdog FSoE (en ms)
4octet bas (bits 0–7) de la longueur des paramètres d’application en octets
5octet haut (bits 8–15) de la longueur des paramètres d’application en octets
61er octet du paramètre d’application relatif à la sécurité
…
n+5n-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.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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.

CommandSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_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 :

  1. Master → Slave : Safety Master PDU avec Command = Parameter, transportant le prochain fragment de la charge utile des paramètres dans les champs SafeData.
  2. 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

Structures PDU par état

CRC

Codes d’erreur & format des données


Consultez les articles similaires par catégorie : FSoE EtherCAT Sûreté