El estado Session sigue al estado Reset en el establecimiento de la conexión FSoE. Su único propósito es intercambiar un par de números aleatorios de 16 bits — el Master Session ID y el Slave Session ID — entre los dos nodos. Estos IDs no tienen relevancia para la seguridad; existen únicamente para diferenciar múltiples secuencias de Safety PDUs en caso de varios reinicios de la conexión FSoE, de modo que un PDU obsoleto de una instancia de conexión anterior pueda distinguirse de uno nuevo.
Este artículo recorre los dos PDUs del estado Session definidos en ETG.5100 S (D) V1.2.0, §8.2.2.3, 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 únicos bytes de datos relevantes son los dos octetos del Session ID. En cada PDU del estado Session,
SafeData[0]ySafeData[1](octetos 1 y 2) transportan juntos el Session ID de 16 bits:
- Master → Slave: el Master Session ID (un número aleatorio generado por el Master).
- Slave → Master: el Slave Session ID (un número aleatorio generado por el Slave, devuelto como acuse de recibo).
Todos los demás octetos de SafeData están sin usar y deben establecerse a 0. El campo Conn_Id también está sin usar (establecido a 0) — el Session ID no tiene relevancia para la seguridad, por lo que el Connection ID no se verifica en este estado. Los campos CRC siguen transmitiéndose y deben verificarse, pero se calculan a partir del estado inicial de reset porque el número de secuencia y el CRC heredado se borraron al entrar en el 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 Session?
El estado Session se entra cuando el Master sale del estado Reset enviando un Safety Master PDU con el comando Session. Las transiciones de estado son:
| Dirección | Condición |
|---|---|
| El Master sale de Session | Ha transferido el Master Session ID completo y recibido los acuses de recibo asociados del Slave, luego envía un Safety PDU con el comando Connection. |
| El Slave sale de Session | Recibe un Safety PDU con el comando Connection del Master. |
Ambos nodos también salen del estado Session inmediatamente si detectan un error de comunicación FSoE — en ese caso retroceden al estado Reset.
PDU Session del Master (FSoE Master → Slave)
El Master envía este PDU para transferir su Master Session ID de 16 bits al Slave. El ejemplo siguiente es la Tabla 13 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octeto 0 | Master Session Id, octeto 0 Octeto 1 | Master Session Id, octeto 1 Octeto 2 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | 0 Octeto 5 — sin usar | 0 Octeto 6 — sin usar | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | 0 Octeto 9 — sin usar | 0 Octeto 10 — sin usar |
Puntos clave:
- Command (octeto 0) es
Session. - SafeData[0] y SafeData[1] (octetos 1 y 2) transportan los dos octetos del Master Session ID de 16 bits. El Master lo genera como un número aleatorio una vez por intento de conexión.
- Todos los demás octetos de SafeData están sin usar y establecidos a 0.
- Conn_Id está sin usar y establecido a 0 — el Session ID no tiene relevancia para la seguridad, por lo que el Connection ID no se verifica en este estado.
- 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 Session del Slave (FSoE Slave → Master, acuse de recibo)
El Slave acusa recibo del comando Session devolviendo su propio Slave Session ID de 16 bits. Esto es la Tabla 14 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octeto 0 | Slave Session Id, octeto 0 Octeto 1 | Slave Session Id, octeto 1 Octeto 2 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | 0 Octeto 5 — sin usar | 0 Octeto 6 — sin usar | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | 0 Octeto 9 — sin usar | 0 Octeto 10 — sin usar |
El Slave no repite el Session ID del Master — responde con su propio Slave Session ID aleatorio generado de forma independiente. Ambos IDs se usan entonces juntos para identificar esta instancia de conexión en particular.
¿Cuántos ciclos FSoE toma la transferencia del Session ID?
El Session ID tiene 16 bits de ancho y se transporta en los dos primeros octetos de SafeData del PDU. El número de ciclos FSoE necesarios para transferirlo depende por tanto de la longitud de datos de seguridad:
| Longitud de datos de seguridad | Ciclos para transferir el Session ID | Motivo |
|---|---|---|
| ≥ 2 octetos | 1 ciclo | Ambos octetos del Session ID caben en SafeData[0] y SafeData[1]. |
| 1 octeto | 2 ciclos | Solo SafeData[0] está disponible por ciclo, por lo que los dos octetos se transfieren en dos PDUs sucesivos. |
Por eso los ejemplos de la especificación usan 4 octetos de datos de seguridad: con 4 octetos (o cualquier longitud ≥ 2), el Session ID completo de 16 bits se transfiere en un único ciclo FSoE.
Todo junto: el intercambio del estado Session
El estado Session es un simple handshake de dos pasos:
- Master → Slave: Safety Master PDU con
Command = Session, transportando el Master Session ID enSafeData[0..1]. - Slave → Master: Safety Slave PDU con
Command = Session, transportando el Slave Session ID enSafeData[0..1].
Una vez que el Master ha transferido el Master Session ID completo y recibido el/los acuse(s) de recibo del Slave, sale del estado Session enviando un Safety PDU con el comando Connection — esta es también la señal para que el Slave salga del estado Session. Si cualquiera de los dos nodos detecta un error de comunicación FSoE durante el intercambio, ambos retroceden al estado Reset.
¿Por qué el Connection ID se establece a 0 en el estado Session?
El Session ID no tiene relevancia para la seguridad. Su único propósito es diferenciar múltiples secuencias de Safety PDUs en caso de varios reinicios de la conexión FSoE — por ejemplo, para que un PDU retardado de una instancia de conexión anterior no se confunda con un PDU de la conexión nueva. Como un Session ID corrupto o conmutado no puede por sí solo causar un riesgo de seguridad, la especificación indica explícitamente que una conmutación en el nodo receptor no necesita examinarse desde una perspectiva de seguridad. En consecuencia, el Connection ID se establece a 0 para el comando Session — la conexión aún no se ha establecido, por lo que no hay ningún Connection ID que verificar.
Resumen
En el estado Session, el Safety PDU de FSoE es una envoltura de número aleatorio de dos bytes: el campo Command es Session, SafeData[0..1] transportan el Master o Slave Session ID de 16 bits, todos los demás octetos de SafeData y el campo Conn_Id son 0, y los CRC se calculan a partir del estado inicial de reset heredado del estado Reset precedente. La conexión sale de Session cuando el Master emite el comando Connection — el Slave nunca envía Connection primero, solo acusa recibo de Session con su propio Slave Session ID. El Session ID en sí no tiene relevancia para la seguridad; existe puramente para desambiguar secuencias de PDU entre reinicios repetidos de la conexión.
Referencias
- ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Tablas 13–14.
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 Connection PDU: Master and Slave Structure — estructura del PDU del estado Connection
- 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