L’état Reset est le point d’entrée de chaque connexion FSoE (Fail Safe over EtherCAT). La connexion y entre après la mise sous tension, après un redémarrage (reset connection), ou dès qu’une erreur de communication FSoE a été détectée. Tant que la connexion est dans cet état, aucune donnée de sécurité utilisateur n’est échangée — les Safety PDU sont réaffectés pour transporter la commande Reset avec un code d’erreur d’un seul octet qui indique au pair pourquoi la connexion a été réinitialisée.
Cet article passe en revue les trois PDU de l’état Reset définis dans ETG.5100 S (D) V1.2.0, §8.2.2.2, en utilisant l’exemple canonique de la spécification avec 4 octets de données de sécurité. Pour les dispositions complètes en 2/4/6/8 octets, consultez FSoE Reset PDU : structure Master et Slave.
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 — le seul octet de données pertinent est le code d’erreur. Dans chaque PDU de l’état Reset,
SafeData[0](octet 1) est le seul octet de données de sécurité qui ait une signification :
0x00— reset intentionnel (mise sous tension, redémarrage / reset connection), ou l’accusé de réception par le Slave d’un Reset du Master.- Non nul — le code d’erreur de communication FSoE qui a déclenché le reset (voir Table 28 ci-dessous).
Tous les autres octets SafeData sont inutilisés et doivent être mis à 0. Le champ Conn_Id est également inutilisé (mis à 0) — il n’est vérifié qu’une fois la connexion établie. Les champs CRC sont toujours transmis et doivent toujours ê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é sont effacés à l’entrée dans Reset (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 Reset ?
L’état Reset réinitialise la connexion FSoE après la mise sous tension ou après une erreur de communication. Deux choses sont réinitialisées à l’entrée :
- le numéro de séquence, et
- le CRC du dernier télégramme qui était utilisé dans le calcul du CRC (c’est-à-dire que la chaîne d’héritage CRC est rompue).
Les transitions d’état sont asymétriques, reflétant les rôles Master/Slave :
| Direction | Condition |
|---|---|
| Le Master quitte Reset | Il envoie un Safety Master PDU avec la commande Session au Slave. |
| Le Slave quitte Reset | Il reçoit un Safety Master PDU valide avec la commande Session. |
En d’autres termes, le Master quitte Reset en émettant la commande Session, et le Slave quitte Reset dès qu’il accepte ce PDU Session. Tant que les deux côtés sont encore dans Reset, ils échangent des Safety PDU transportant la commande Reset, comme illustré ci-dessous.
Master Reset PDU (FSoE Master → Slave)
Le Master envoie ce PDU après un redémarrage ou après avoir détecté une erreur de communication FSoE. L’exemple ci-dessous correspond à la Table 10 d’ETG.5100 S (D) V1.2.0 pour 4 octets de données de sécurité.
| Commande | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | code d'erreur Octet 1 — 0 pour redémarrage | 0 Octet 2 — inutilisé | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — inutilisé | 0 Octet 6 — inutilisé | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — inutilisé | 0 Octet 10 — inutilisé |
Points clés :
- Command (octet 0) est
Reset. - SafeData[0] (octet 1) transporte le code d’erreur (bits 0–7). Une valeur de
0x00signifie un simple redémarrage / reset connection ; toute valeur non nulle identifie l’erreur de communication qui a déclenché le reset (voir la table ci-dessous). - Tous les autres octets SafeData sont inutilisés et mis à 0.
- CRC_0 et CRC_1 sont toujours transmis comme valeurs 16 bits little-endian, mais comme le numéro de séquence et le CRC hérité ont été réinitialisés à l’entrée, ils sont calculés à partir de l’état initial de reset — non chaînés depuis la trame précédente.
- Conn_Id est inutilisé et mis à 0 dans l’état Reset. Le Connection ID n’est vérifié qu’une fois la connexion établie.
Slave Reset PDU — accusé de réception d’un Reset du Master (FSoE Slave → Master)
Lorsque le Slave reçoit une commande Reset valide du Master, il en accuse réception en envoyant un Safety Slave PDU avec la commande Reset et tous les octets SafeData mis à 0 — y compris la position du code d’erreur. Il s’agit de la Table 11 d’ETG.5100 S (D) V1.2.0.
| Commande | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | 0 Octet 1 — accusé de réception | 0 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 | 0 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — inutilisé | 0 Octet 10 — inutilisé |
La seule différence avec le Master Reset PDU est que SafeData[0] est toujours 0 — le Slave ne renvoie pas de code d’erreur lors de l’accusé de réception. Un code d’erreur à zéro dans cette position est exactement ce que le Master utilise pour reconnaître l’accusé de réception.
Slave Reset PDU — reset initié par le Slave (FSoE Slave → Master)
Le Slave peut lui-même initier un Reset, soit lors d’un redémarrage (reset connection), soit en cas d’erreur qu’il a détectée localement. Dans ce cas, il envoie un Safety Slave PDU structurellement identique au Master Reset PDU : la commande Reset est définie, et SafeData[0] transporte le propre code d’erreur du Slave (0x00 pour un simple redémarrage). Il s’agit de la Table 12 d’ETG.5100 S (D) V1.2.0.
| Commande | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Reset Octet 0 | code d'erreur Octet 1 — 0 pour redémarrage | 0 Octet 2 — inutilisé | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — inutilisé | 0 Octet 6 — inutilisé | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — inutilisé | 0 Octet 10 — inutilisé |
Le Master accuse réception de ce Reset initié par le Slave non pas en envoyant un autre PDU Reset, mais en quittant l’état Reset : il envoie un Safety Master PDU avec la commande Session, ce qui est le signal pour les deux côtés de sortir de Reset.
Synthèse : l’échange de l’état Reset
Les trois PDU ci-dessus forment un petit handshake qui dépend de qui a initié le reset :
- Reset initié par le Master : le Master envoie Reset (avec code d’erreur) → le Slave accuse réception avec Reset (SafeData = 0) → le Master envoie Session pour quitter Reset.
- Reset initié par le Slave : le Slave envoie Reset (avec code d’erreur) → le Master envoie Session pour quitter Reset (c’est l’accusé de réception du Master).
Dans les deux cas, la connexion ne quitte l’état Reset que lorsque le Master émet la commande Session ; jusqu’alors, chaque PDU sur le support transporte la commande Reset, le champ Conn_Id est 0, et la seule charge utile significative est l’octet unique du code d’erreur dans SafeData[0].
Codes d’erreur de communication FSoE (Table 28)
Le code d’erreur transporté dans SafeData[0] d’un PDU Reset provient de la table suivante. Une valeur de 0x00 signifie « pas d’erreur » — c’est-à-dire un reset local ou l’accusé de réception d’une commande Reset. Les codes 1–11 sont définis par la norme ; 0x80–0xFF sont réservés aux erreurs SafePara spécifiques au dispositif.
| Code d’erreur | Description |
|---|---|
| 0 | Reset local ou accusé de réception d’une commande RESET |
| 1 | Commande inattendue (INVALID_CMD) |
| 2 | Commande inconnue (UNKNOWN_CMD) |
| 3 | Connection ID invalide (INVALID_CONNID) |
| 4 | Erreur CRC (INVALID_CRC) |
| 5 | Watchdog expiré (WD_EXPIRED) |
| 6 | FSoE Slave Address invalide (INVALID_ADDRESS) |
| 7 | Données de sécurité invalides (INVALID_DATA) |
| 8 | Longueur de paramètre de communication invalide (INVALID_COMMPARALEN) |
| 9 | Données de paramètre de communication invalides (INVALID_COMPARA) |
| 10 | Longueur de paramètre d’application invalide (INVALID_USERPARALEN) |
| 11 | Données de paramètre d’application invalides (INVALID_USERPARA) |
| 0x80–0xFF | SafePara invalide (spécifique au dispositif) |
Résumé
Dans l’état Reset, le Safety PDU FSoE est effectivement une enveloppe diagnostique d’un octet : le champ Command est Reset, SafeData[0] transporte le code d’erreur (ou 0 lors de l’accusé de réception), tous les autres octets SafeData et le champ Conn_Id sont 0, et les CRC sont recalculés à partir de l’état initial de reset car le numéro de séquence et le CRC hérité ont tous deux été effacés à l’entrée. La connexion ne quitte Reset que lorsque le Master envoie la commande Session — le Slave n’envoie jamais Session, il accuse seulement réception du Reset en mettant ses SafeData à zéro.
Références
- ETG.5100 S (D) V1.2.0, §8.2.2.2 Reset state, Tables 10–12 et Table 28.
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 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 Parameter PDU : structure Master et Slave — disposition du PDU pour l’état Parameter
- 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
