El estado Parameter sigue al estado Connection en el establecimiento de la conexión FSoE. Su propósito es transferir los parámetros de comunicación relacionados con la seguridad (el valor del watchdog de FSoE) y los parámetros de aplicación específicos del dispositivo relacionados con la seguridad del Master al Slave. El Slave acusa recibo de cada PDU Parameter repitiendo los datos de seguridad. Como los parámetros de aplicación pueden tener cualquier longitud, la transferencia puede abarcar varios ciclos FSoE. La herencia de CRC garantiza la seguridad y la consistencia de la transferencia de parámetros en todos los ciclos (consulta FSoE: How does CRC inheritance work?).
Este artículo recorre los PDUs del estado Parameter definidos en ETG.5100 S (D) V1.2.0, §8.2.2.5, usando el ejemplo canónico de la especificación de 4 octetos de datos de seguridad y 2 octetos de parámetro de aplicación relacionado con la seguridad, lo que requiere dos ciclos FSoE.
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 sigue el mismo patrón (los octetos de SafeData se rellenan en orden, con los octetos no usados del último ciclo establecidos a 0).
¿Cuándo se entra y se sale del estado Parameter?
El estado Parameter se entra cuando el Master sale del estado Connection enviando un Safety Master PDU con el comando Parameter. Las transiciones de estado son:
| Dirección | Condición |
|---|---|
| El Master sale de Parameter | Ha transferido el conjunto completo de parámetros de comunicación y de aplicación y recibido los acuses de recibo asociados del Slave, luego envía un Safety PDU con el comando Data (entrando en el intercambio cíclico de datos). |
| El Slave sale de Parameter | Recibe un Safety PDU con el comando Data del Master. |
Ambos nodos también salen del estado Parameter inmediatamente si detectan un error de comunicación FSoE — en ese caso retroceden al estado Reset.
Datos de seguridad transferidos en el estado Parameter
Los datos de seguridad en el estado Parameter se estructuran de forma distinta a los estados anteriores. En lugar de un conjunto fijo de campos, transportan un payload de longitud variable encabezado por tres campos de cabecera de 16 bits. La Tabla 18 de ETG.5100 S (D) V1.2.0 define el diseño:
| Octeto de SafetyData | Descripción |
|---|---|
| 0 | octeto bajo (bits 0–7) de la longitud de los parámetros de comunicación en octetos (= 2) |
| 1 | octeto alto (bits 8–15) de la longitud de los parámetros de comunicación en octetos (= 0) |
| 2 | octeto bajo (bits 0–7) del watchdog de FSoE (en ms) |
| 3 | octeto alto (bits 8–15) del watchdog de FSoE (en ms) |
| 4 | octeto bajo (bits 0–7) de la longitud de los parámetros de aplicación en octetos |
| 5 | octeto alto (bits 8–15) de la longitud de los parámetros de aplicación en octetos |
| 6 | 1er octeto del parámetro de aplicación relacionado con la seguridad |
| … | |
| n+5 | n-ésimo octeto del parámetro de aplicación relacionado con la seguridad |
Los dos primeros campos de 16 bits son la longitud de los parámetros de comunicación (siempre 2, es decir, solo el valor del watchdog) y el valor del watchdog de FSoE en milisegundos. El siguiente campo de 16 bits es la longitud de los parámetros de aplicación, seguido por los bytes del parámetro de aplicación en sí. El watchdog de FSoE y los parámetros de aplicación relacionados con la seguridad se configuran vía el safety configurator del FSoE Master.
¿Cuántos ciclos FSoE se requieren?
Como los parámetros de aplicación pueden tener cualquier longitud, el número total de ciclos FSoE depende tanto de la longitud del parámetro de aplicación como de la longitud fija de datos de seguridad del Safety PDU:
$$ \text{ciclos} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$donde el 6 corresponde a los tres campos de cabecera de 16 bits (longitud de parámetros de comunicación, watchdog, longitud de parámetros de aplicación). Si no se requieren todos los octetos de datos de seguridad en el último ciclo FSoE, los octetos no usados se transferirán como 0.
Para el ejemplo de la especificación (4 octetos de datos de seguridad, 2 octetos de parámetro de aplicación), el payload total es 6 + 2 = 8 octetos, que caben en ⌈8/4⌉ = 2 ciclos FSoE. El primer ciclo transporta la longitud de los parámetros de comunicación, el watchdog, y los primeros dos octetos serían la longitud de los parámetros de aplicación — pero en este ejemplo la longitud de los parámetros de aplicación (2) se envía en el segundo ciclo junto con los dos bytes del parámetro de aplicación, como se muestra abajo.
Primer ciclo — Parámetros de comunicación
Primer Safety Master PDU (FSoE Master → Slave)
El Master envía este PDU para transferir la longitud de los parámetros de comunicación y el valor del watchdog de FSoE. Esto es la Tabla 19 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octeto 0 | long. parám. comm., lo Octeto 1 — = 2 | long. parám. comm., hi Octeto 2 — = 0 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | watchdog, lo Octeto 5 — en ms | watchdog, hi Octeto 6 — en ms | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, lo Octeto 9 | Connection Id, hi Octeto 10 |
Puntos clave:
- Command (octeto 0) es
Parameter. - SafeData[0..1] (octetos 1 y 2) transportan la longitud de los parámetros de comunicación de 16 bits en octetos. Siempre es 2 (little-endian:
0x02, 0x00), porque el único parámetro de comunicación es el valor del watchdog de 16 bits. - SafeData[2..3] (octetos 5 y 6) transportan el valor del watchdog de FSoE de 16 bits en milisegundos (little-endian).
- Conn_Id (octetos 9 y 10) transporta el Connection ID — igual que en el estado Connection, ahora se rellena en cada Safety PDU.
- CRC_0 y CRC_1 se transmiten como valores little-endian de 16 bits. La herencia de CRC está activa en todos los ciclos del estado Parameter.
Primer Safety Slave PDU (FSoE Slave → Master, acuse de recibo)
El Slave acusa recibo del primer PDU Parameter repitiendo los mismos datos de seguridad. Esto es la Tabla 20 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octeto 0 | long. parám. comm., lo Octeto 1 — = 2 | long. parám. comm., hi Octeto 2 — = 0 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | watchdog, lo Octeto 5 — en ms | watchdog, hi Octeto 6 — en ms | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, lo Octeto 9 | Connection Id, hi Octeto 10 |
Segundo ciclo — Parámetros de aplicación
El FSoE Master envía el segundo Safety Master PDU una vez que ha recibido correctamente el primer Safety Slave PDU.
Segundo Safety Master PDU (FSoE Master → Slave)
El Master envía este PDU para transferir la longitud de los parámetros de aplicación y los bytes del parámetro de aplicación en sí. Esto es la Tabla 21 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octeto 0 | long. parám. app, lo Octeto 1 — = 2 | long. parám. app, hi Octeto 2 — = 0 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | byte parám. app 1 Octeto 5 | byte parám. app 2 Octeto 6 | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, lo Octeto 9 | Connection Id, hi Octeto 10 |
Puntos clave:
- SafeData[0..1] (octetos 1 y 2) transportan la longitud de los parámetros de aplicación de 16 bits en octetos (little-endian). En este ejemplo es 2.
- SafeData[2..3] (octetos 5 y 6) transportan los bytes del parámetro de aplicación. En este ejemplo hay exactamente 2 bytes, rellenando ambas posiciones disponibles.
- Si el parámetro de aplicación fuera más largo que los octetos de SafeData disponibles en un ciclo, la transferencia continuaría en ciclos adicionales, con los bytes restantes colocados en las mismas posiciones de SafeData (empezando en SafeData[0] del siguiente ciclo, tras cualquier cabecera restante). Los octetos no usados del último ciclo se establecen a 0.
Segundo Safety Slave PDU (FSoE Slave → Master, acuse de recibo)
El Slave acusa recibo del segundo PDU Parameter repitiendo los mismos datos de seguridad. Esto es la Tabla 22 de ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octeto 0 | long. parám. app, lo Octeto 1 — = 2 | long. parám. app, hi Octeto 2 — = 0 | CRC_0_Lo Octeto 3 | CRC_0_Hi Octeto 4 | byte parám. app 1 Octeto 5 | byte parám. app 2 Octeto 6 | CRC_1_Lo Octeto 7 | CRC_1_Hi Octeto 8 | Connection Id, lo Octeto 9 | Connection Id, hi Octeto 10 |
Todo junto: el intercambio del estado Parameter
El estado Parameter es un handshake de eco multiciclo. Cada ciclo sigue el mismo patrón:
- Master → Slave: Safety Master PDU con
Command = Parameter, transportando el siguiente fragmento del payload de parámetros en los campos SafeData. - Slave → Master: Safety Slave PDU con
Command = Parameter, repitiendo los mismos datos de seguridad.
El Master envía el siguiente ciclo solo después de haber recibido correctamente el acuse de recibo del Slave del ciclo anterior. La transferencia continúa hasta que se han enviado todos los parámetros de comunicación y de aplicación. Una vez que el Master ha transferido el conjunto completo de parámetros y recibido el acuse de recibo final, sale del estado Parameter 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.
¿Por qué es importante la herencia de CRC en el estado Parameter?
Como la transferencia de parámetros abarca varios ciclos FSoE, la herencia de CRC es lo que vincula los PDUs individuales en una única transferencia relevante para la seguridad. El CRC de cada ciclo se calcula no solo sobre los bytes del PDU actual, sino también sobre el CRC del PDU anterior — formando una cadena que el receptor puede verificar de extremo a extremo. Si cualquier PDU de la secuencia se corrompe, se pierde o se reordena, la cadena de CRC se rompe y el receptor detecta el error. Por eso la especificación indica que “la herencia de CRC garantiza una transferencia de parámetros segura y consistente”. Consulta FSoE: How does CRC inheritance work? para los detalles del algoritmo.
Resumen
En el estado Parameter, el Safety PDU de FSoE transporta un payload de parámetros de longitud variable encabezado por tres campos de 16 bits: la longitud de los parámetros de comunicación (siempre 2), el valor del watchdog de FSoE en milisegundos, y la longitud de los parámetros de aplicación. A continuación van los bytes del parámetro de aplicación. Como el payload puede exceder la longitud fija de datos de seguridad del PDU, la transferencia puede abarcar varios ciclos FSoE, con los octetos no usados del último ciclo establecidos a 0. El Slave acusa recibo de cada ciclo repitiendo los datos de seguridad. La herencia de CRC en todos los ciclos garantiza la seguridad y la consistencia de la transferencia completa de parámetros. La conexión sale del estado Parameter cuando el Master envía el comando Data, entrando en el intercambio cíclico de datos.
Referencias
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tablas 18–22.
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 Connection PDU: Master and Slave Structure — estructura del PDU del estado Connection
- 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