FSoE Session PDU : structure Master et Slave

L’état Session suit l’état Reset dans la procédure d’établissement de la connexion FSoE. Son seul rôle est d’échanger une paire de nombres aléatoires 16 bits — le Master Session ID et le Slave Session ID — entre les deux nœuds. Ces ID n’ont aucune pertinence pour la sécurité ; ils existent uniquement pour différencier plusieurs séquences de Safety PDU en cas de redémarrages multiples de la connexion FSoE, afin qu’un PDU périmé d’une instance de connexion précédente puisse être distingué d’un nouveau.

Cet article passe en revue les deux PDU de l’état Session définis dans ETG.5100 S (D) V1.2.0, §8.2.2.3, en utilisant l’exemple canonique de la spécification avec 4 octets de données de sécurité.

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 est présentée dans FSoE Reset PDU : structure Master et Slave.

Note — les seuls octets de données pertinents sont les deux octets du Session ID. Dans chaque PDU de l’état Session, SafeData[0] et SafeData[1] (octets 1 et 2) transportent ensemble le Session ID 16 bits :

• Master → Slave : le Master Session ID (un nombre aléatoire généré par le Master).
• Slave → Master : le Slave Session ID (un nombre aléatoire généré par le Slave, renvoyé comme accusé de réception).

Tous les autres octets SafeData sont inutilisés et doivent être mis à 0. Le champ Conn_Id est également inutilisé (mis à 0) — le Session ID n’a aucune pertinence pour la sécurité, donc le Connection ID n’est pas vérifié dans cet état. Les champs CRC sont toujours transmis et doivent être vérifiés, mais ils sont calculés à partir de l’état initial de reset car le numéro de séquence et le CRC hérité ont été effacés à l’entrée dans l’état Reset précédent (voir FSoE : comment fonctionne l’héritage CRC ? et Comment calculer la somme de contrôle CRC pour les PDU FSoE ?).

Quand entre-t-on et sort-on de l’état Session ?

L’état Session est entré lorsque le Master quitte l’état Reset en envoyant un Safety Master PDU avec la commande Session. Les transitions d’état sont :

Les deux nœuds quittent également l’état Session immédiatement s’ils détectent une erreur de communication FSoE — dans ce cas, ils reviennent à l’état Reset.

Master Session PDU (FSoE Master → Slave)

Le Master envoie ce PDU pour transférer son Master Session ID 16 bits au Slave. L’exemple ci-dessous correspond à la Table 13 d’ETG.5100 S (D) V1.2.0 pour 4 octets de données de sécurité.

Points clés :

• Command (octet 0) est Session.
• SafeData[0] et SafeData[1] (octets 1 et 2) transportent les deux octets du Master Session ID 16 bits. Le Master le génère comme un nombre aléatoire une fois par tentative de connexion.
• Tous les autres octets SafeData sont inutilisés et mis à 0.
• Conn_Id est inutilisé et mis à 0 — le Session ID n’a aucune pertinence pour la sécurité, donc le Connection ID n’est pas vérifié dans cet état.
• CRC_0 et CRC_1 sont transmis comme valeurs 16 bits little-endian, calculées à partir de l’état initial de reset hérité de l’état Reset précédent.

Slave Session PDU (FSoE Slave → Master, accusé de réception)

Le Slave accuse réception de la commande Session en renvoyant son propre Slave Session ID 16 bits. Il s’agit de la Table 14 d’ETG.5100 S (D) V1.2.0.

Le Slave ne renvoie pas le Session ID du Master — il répond avec son propre Slave Session ID aléatoire généré indépendamment. Les deux ID sont ensuite utilisés ensemble pour identifier cette instance de connexion particulière.

Combien de cycles FSoE le transfert du Session ID prend-il ?

Le Session ID fait 16 bits de large et est transporté dans les deux premiers octets SafeData du PDU. Le nombre de cycles FSoE requis pour le transférer dépend donc de la longueur des données de sécurité :

C’est pourquoi les exemples de la spécification utilisent 4 octets de données de sécurité : avec 4 octets (ou toute longueur ≥ 2), le Session ID 16 bits entier est transféré en un seul cycle FSoE.

Synthèse : l’échange de l’état Session

L’état Session est un simple handshake en deux étapes :

1. Master → Slave : Safety Master PDU avec Command = Session, transportant le Master Session ID dans SafeData[0..1].
2. Slave → Master : Safety Slave PDU avec Command = Session, transportant le Slave Session ID dans SafeData[0..1].

Une fois que le Master a transféré le Master Session ID complet et reçu le(s) accusé(s) de réception du Slave, il quitte l’état Session en envoyant un Safety PDU avec la commande Connection — c’est également le signal pour le Slave de quitter l’état Session. Si l’un des nœuds détecte une erreur de communication FSoE pendant l’échange, les deux reviennent à l’état Reset.

Pourquoi le Connection ID est-il mis à 0 dans l’état Session ?

Le Session ID n’a aucune pertinence pour la sécurité. Son seul but est de différencier plusieurs séquences de Safety PDU en cas de redémarrages multiples de la connexion FSoE — par exemple, pour qu’un PDU retardé d’une instance de connexion précédente ne soit pas confondu avec un PDU de la nouvelle connexion. Comme un Session ID corrompu ou permuté ne peut pas par lui-même causer un risque de sécurité, la spécification indique explicitement qu’une permutation dans le nœud récepteur n’a pas besoin d’être examinée du point de vue de la sécurité. Par conséquent, le Connection ID est mis à 0 pour la commande Session — la connexion n’est pas encore établie, il n’y a donc aucun Connection ID à vérifier.

Résumé

Dans l’état Session, le Safety PDU FSoE est une enveloppe de nombre aléatoire à deux octets : le champ Command est Session, SafeData[0..1] transportent le Master ou Slave Session ID 16 bits, tous les autres octets SafeData et le champ Conn_Id sont 0, et les CRC sont calculés à partir de l’état initial de reset hérité de l’état Reset précédent. La connexion quitte Session lorsque le Master émet la commande Connection — le Slave n’envoie jamais Connection en premier, il accuse seulement réception de Session avec son propre Slave Session ID. Le Session ID lui-même n’a aucune pertinence pour la sécurité ; il existe purement pour distinguer les séquences de PDU à travers les redémarrages répétés de la connexion.

Références

• ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Tables 13–14.

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 — structure générale de la PDU Safety
• 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 — structure PDU et codes d’erreur pour l’état Reset
• FSoE Connection PDU : structure Master et Slave — structure PDU pour l’état Connection
• FSoE Parameter PDU : structure Master et Slave — structure PDU pour l’état Parameter
• FSoE Data PDU : structure Master et Slave — structure PDU pour l’état Data
• FSoE Reset PDU : structure Master et Slave — structures d’octets pour toutes les longueurs de Safety Data

CRC

• FSoE CRC : quel polynôme utilise-t-il ? — le polynôme 17 bits du CRC FSoE
• FSoE : Comment sont construites les tables CRC ? — comment les tables de lookup CRC sont générées

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 multioctets