El estado Connection sigue al estado Session en el establecimiento de la conexión FSoE. Su propósito es transferir el Connection ID de 16 bits — un identificador único generado por el safety configurator del FSoE Master — junto con la FSoE Slave Address de 16 bits del Master al Slave. El Slave acusa recibo devolviendo los mismos datos de seguridad. A partir de este punto, el Connection ID se transporta en el campo Conn_Id de cada Safety PDU posterior, de modo que ambos nodos pueden comprobar si un telegrama va realmente dirigido a ellos.
Este artículo recorre los dos PDUs del estado Connection definidos en ETG.5100 S (D) V1.2.0, §8.2.2.4, usando el ejemplo canónico de la especificación de 4 octetos de datos de seguridad.
Nota — el número de bytes de datos de seguridad es fijo por dirección. Cada conexión FSoE tiene una longitud fija de datos de seguridad (master→slave y slave→master), configurada de forma idéntica en ambos nodos. Las longitudes permitidas son 1, 2, 4, 6 u 8 octetos. La longitud real para una conexión dada depende del dispositivo FSoE Slave y debe tomarse de la documentación del Slave o de su archivo de descripción de dispositivo (ESI/EEPROM). Los ejemplos siguientes usan 4 octetos como en la especificación; el diseño de bytes para otras longitudes se muestra en FSoE Reset PDU: Master and Slave Structure.
Nota — los bytes de datos relevantes son el Connection ID y la FSoE Slave Address. En cada PDU del estado Connection, los cuatro octetos de SafeData transportan dos valores de 16 bits:
SafeData[0..1](octetos 1 y 2) — el Connection ID (octeto bajo, octeto alto). Es un valor único de 16 bits generado por el safety configurator;0x0000no está permitido, por lo que pueden coexistir hasta 65 535 conexiones FSoE en un sistema de comunicación.SafeData[2..3](octetos 5 y 6) — la FSoE Slave Address (octeto bajo, octeto alto). Es una dirección única configurada en el dispositivo FSoE Slave correspondiente.A diferencia de los estados Reset y Session, el campo
Conn_Id(octetos 9 y 10) ya no es 0 — ahora transporta el Connection ID real, igual que hará en cada Safety PDU posterior una vez establecida la conexión. Los campos CRC siguen transmitiéndose y deben verificarse, calculados a partir del estado inicial de reset heredado del estado Reset precedente (consulta FSoE: How does CRC inheritance work? y How to compute the CRC checksum for FSoE PDUs?).
¿Cuándo se entra y se sale del estado Connection?
El estado Connection se entra cuando el Master sale del estado Session enviando un Safety Master PDU con el comando Connection. Las transiciones de estado reflejan las del estado Session:
| Dirección | Condición |
|---|---|
| El Master sale de Connection | Ha transferido el Connection ID completo y la FSoE Slave Address y recibido el acuse de recibo asociado del Slave, luego envía un Safety PDU con el comando Data (entrando en el intercambio cíclico de datos). |
| El Slave sale de Connection | Recibe un Safety PDU con el comando Data del Master. |
Ambos nodos también salen del estado Connection inmediatamente si detectan un error de comunicación FSoE — en ese caso retroceden al estado Reset.
Datos de seguridad transferidos en el estado Connection
Antes de examinar el diseño completo del PDU, conviene centrarse solo en la parte de datos de seguridad. La Tabla 15 de ETG.5100 S (D) V1.2.0 define qué bytes se transfieren:
| Octeto de SafetyData | Descripción |
|---|---|
| 0 | octeto bajo (bits 0–7) del Connection ID |
| 1 | octeto alto (bits 8–15) del Connection ID |
| 2 | octeto bajo (bits 0–7) de la FSoE Slave Address |
| 3 | octeto alto (bits 8–15) de la FSoE Slave Address |
El Connection ID y la FSoE Slave Address tienen cada uno 16 bits de ancho, por lo que juntos ocupan exactamente 4 octetos de SafeData. Esto tiene una consecuencia importante para el número de ciclos FSoE necesarios:
| Longitud de datos de seguridad | Ciclos para transferir Connection ID + Slave Address | Motivo |
|---|---|---|
| 4 octetos | 1 ciclo | Los 4 octetos caben en un PDU. |
| 2 octetos | 2 ciclos | Solo 2 octetos de SafeData por ciclo. |
| 1 octeto | 4 ciclos | Solo 1 octeto de SafeData por ciclo. |
Por eso los ejemplos de la especificación usan 4 octetos de datos de seguridad: con 4 octetos, el Connection ID completo y la FSoE Slave Address se transfieren en un único ciclo FSoE.
PDU Connection del Master (FSoE Master → Slave)
El Master envía este PDU para transferir el Connection ID y la FSoE Slave Address. El ejemplo siguiente es la Tabla 16 de ETG.5100 S (D) V1.2.0 para 4 octetos de datos de seguridad.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octeto 0 | Connection Id, octeto bajo Octeto 1 | Connection Id, octeto alto Octeto 2 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | FSoE Slave Address, octeto bajo Octeto 5 | FSoE Slave Address, octeto alto Octeto 6 | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, octeto bajo Octeto 9 | Connection Id, octeto alto Octeto 10 |
Puntos clave:
- Command (octeto 0) es
Connection. - SafeData[0..1] (octetos 1 y 2) transportan el Connection ID de 16 bits (little-endian). Es el mismo valor que ahora también aparece en el campo
Conn_Id. - SafeData[2..3] (octetos 5 y 6) transportan la FSoE Slave Address de 16 bits (little-endian). Es la dirección única configurada en el dispositivo Slave.
- Conn_Id (octetos 9 y 10) transporta el Connection ID — ya no es 0 como en los estados Reset y Session. A partir de este PDU, el campo
Conn_Idse rellena en cada Safety PDU. - CRC_0 y CRC_1 se transmiten como valores little-endian de 16 bits, calculados a partir del estado inicial de reset heredado del estado Reset precedente.
PDU Connection del Slave (FSoE Slave → Master, acuse de recibo)
El Slave acusa recibo del comando Connection devolviendo los mismos datos de seguridad — es decir, repite el Connection ID y la FSoE Slave Address que envió el Master. Esto es la Tabla 17 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octeto 0 | Connection Id, octeto bajo Octeto 1 | Connection Id, octeto alto Octeto 2 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | FSoE Slave Address, octeto bajo Octeto 5 | FSoE Slave Address, octeto alto Octeto 6 | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, octeto bajo Octeto 9 | Connection Id, octeto alto Octeto 10 |
A diferencia del estado Session, donde el Slave responde con su propio Slave Session ID generado de forma independiente, en el estado Connection el Slave repite el Connection ID y la FSoE Slave Address que envió el Master. Esta es la forma que tiene el Slave de confirmar que ha recibido y aceptado la información de direccionamiento.
¿Por qué se transfieren tanto el Connection ID como la FSoE Slave Address?
Los dos valores cumplen roles complementarios en el direccionamiento:
- La FSoE Slave Address es única en el sistema de comunicación y se configura en el dispositivo FSoE Slave correspondiente. Al transferirla junto con el Connection ID, el Slave puede comprobar si realmente estaba dirigido a él — de modo que se detectaría un direccionamiento inválido.
- El Connection ID también es único en el sistema de comunicación (generado por el safety configurator del FSoE Master). Al ser único, se envía en el campo
Conn_Idde cada Safety PDU posterior, de modo que tanto el FSoE Master como el FSoE Slave pueden detectar si el telegrama va dirigido a ellos.
La combinación de ambos permite que un Slave verifique durante el establecimiento de la conexión que es el destino previsto (vía la FSoE Slave Address), y luego durante la operación cíclica ambos nodos pueden verificar cada telegrama (vía el Connection ID en el campo Conn_Id).
¿Cuántas conexiones FSoE son posibles?
El Connection ID es un valor de 16 bits, lo que nominalmente permitiría 65 536 valores distintos. Sin embargo, Connection ID = 0x0000 no está permitido, por lo que el número máximo de conexiones FSoE en un sistema de comunicación es 65 535. Si hay varios FSoE Masters en el sistema de comunicación, el usuario debe asegurarse de que los Connection IDs usados por todos los Masters sean únicos en todo el sistema.
Todo junto: el intercambio del estado Connection
El estado Connection es un simple handshake de eco:
- Master → Slave: Safety Master PDU con
Command = Connection, transportando el Connection ID enSafeData[0..1], la FSoE Slave Address enSafeData[2..3], y el Connection ID en el campoConn_Id. - Slave → Master: Safety Slave PDU con
Command = Connection, repitiendo el mismo Connection ID y la misma FSoE Slave Address.
Una vez que el Master ha transferido el Connection ID completo y la FSoE Slave Address y recibido el acuse de recibo del Slave, sale del estado Connection enviando un Safety PDU con el comando Data — esto transiciona la conexión al intercambio cíclico de datos. Si cualquiera de los dos nodos detecta un error de comunicación FSoE durante el intercambio, ambos retroceden al estado Reset.
Resumen
En el estado Connection, el Safety PDU de FSoE transporta dos valores de 16 bits en los campos SafeData: el Connection ID (un identificador único en todo el sistema generado por el safety configurator) y la FSoE Slave Address (una dirección única configurada en el dispositivo Slave). El Slave acusa recibo repitiendo estos datos. A diferencia de los estados Reset y Session, el campo Conn_Id ahora se rellena con el Connection ID real — y permanece relleno en cada Safety PDU posterior, permitiendo a ambos nodos verificar que cada telegrama va dirigido a ellos. Como el Connection ID 0x0000 no está permitido, pueden coexistir hasta 65 535 conexiones FSoE en un sistema de comunicación.
Referencias
- ETG.5100 S (D) V1.2.0, §8.2.2.4 Connection state, Tablas 15–17.
Artículos relacionados
Visión general y conceptos básicos
- What does the FSoE abbreviation actually mean? — qué significa el acrónimo FSoE
- FSoE frame structure explained by examples — estructura general del Safety PDU
- All the states of the FSoE state machine — los cinco estados FSoE y sus transiciones
- FSoE: Safety PDU command table — la lista completa de comandos FSoE
Estructuras PDU por estado
- FSoE Reset State PDU: Master and Slave Structure — estructura del PDU y códigos de error del estado Reset
- FSoE Session PDU: Master and Slave Structure — estructura del PDU del estado Session
- FSoE Parameter PDU: Master and Slave Structure — estructura del PDU del estado Parameter
- FSoE Data PDU: Master and Slave Structure — estructura del PDU del estado Data
- FSoE Reset PDU: Master and Slave Structure — diseños de bytes para todas las longitudes de datos de seguridad
CRC
- FSoE CRC: Which polynomial does it use? — el polinomio de 17 bits detrás del CRC de FSoE
- How are the FSoE CRC tables constructed? — cómo se generan las tablas de lookup del CRC
- FSoE: How does CRC inheritance work? — cómo la cadena de CRC enlaza PDUs consecutivos
- How to compute the CRC checksum for FSoE PDUs? — algoritmo de cálculo del CRC byte a byte
Códigos de error y formato de datos
- FSoE: List of all communication error codes — todos los códigos de error de comunicación FSoE
- FSoE: Is data transmitted little-endian or big-endian? — orden de bytes de los campos multibyte