O Parameter state sucede o Connection state na configuração da conexão FSoE. Seu propósito é transferir os parâmetros de comunicação relacionados à segurança (o valor do watchdog FSoE) e os parâmetros de aplicação relacionados à segurança específicos do dispositivo do master para o slave. O slave confirma cada Parameter PDU ecoando os safety data de volta. Como os parâmetros de aplicação podem ter qualquer tamanho, a transferência pode abranger múltiplos ciclos FSoE. A herança de CRC garante a segurança e a consistência da transferência de parâmetros em todos os ciclos (consulte FSoE: How does CRC inheritance work?).
Este artigo percorre os PDUs do Parameter state definidos na ETG.5100 S (D) V1.2.0, §8.2.2.5, usando o exemplo canônico da especificação de 4 octetos de safety data e 2 octetos de safety-related application parameter, o que requer dois ciclos FSoE.
Nota — o número de bytes de safety data é fixo por direção. Cada conexão FSoE tem um safety data length fixo (master→slave e slave→master), configurado de forma idêntica em ambos os nós. Os tamanhos permitidos são 1, 2, 4, 6 ou 8 octetos. O tamanho real para uma dada conexão depende do dispositivo FSoE slave e deve ser obtido na documentação do slave ou no arquivo de descrição do dispositivo (ESI/EEPROM). Os exemplos abaixo usam 4 octetos como na especificação; o layout de bytes para outros tamanhos segue o mesmo padrão (octetos de SafeData são preenchidos em ordem, com octetos não utilizados no último ciclo definidos como 0).
Quando o Parameter state é entrada e saído?
O Parameter state é entrado quando o master sai do Connection state enviando um Safety Master PDU com o comando Parameter. As transições de estado são:
| Direção | Condição |
|---|---|
| Master sai de Parameter | Transferiu o conjunto completo de parâmetros de comunicação e de aplicação e recebeu as confirmações associadas do slave, então envia um Safety PDU com o comando Data (entrando na troca cíclica de dados). |
| Slave sai de Parameter | Recebe um Safety PDU com o comando Data do master. |
Ambos os nós também saem do Parameter state imediatamente se detectarem um erro de comunicação FSoE — nesse caso, eles retornam ao Reset state.
Safety data transferidos no Parameter state
Os safety data no Parameter state são estruturados de forma diferente dos estados anteriores. Em vez de um conjunto fixo de campos, eles carregam um payload de tamanho variável encabeçado por três campos de cabeçalho de 16 bits. A Tabela 18 da ETG.5100 S (D) V1.2.0 define o layout:
| Octeto SafeData | Descrição |
|---|---|
| 0 | octeto baixo (bits 0–7) do tamanho dos parâmetros de comunicação em octetos (= 2) |
| 1 | octeto alto (bits 8–15) do tamanho dos parâmetros de comunicação em octetos (= 0) |
| 2 | octeto baixo (bits 0–7) do watchdog FSoE (em ms) |
| 3 | octeto alto (bits 8–15) do watchdog FSoE (em ms) |
| 4 | octeto baixo (bits 0–7) do tamanho dos parâmetros de aplicação em octetos |
| 5 | octeto alto (bits 8–15) do tamanho dos parâmetros de aplicação em octetos |
| 6 | 1º octeto do safety-related application parameter |
| … | |
| n+5 | n-ésimo octeto do safety-related application parameter |
Os dois primeiros campos de 16 bits são o communication parameter length (sempre 2, ou seja, apenas o valor do watchdog) e o valor do FSoE watchdog em milissegundos. O próximo campo de 16 bits é o application parameter length, seguido pelos bytes do parâmetro de aplicação em si. O watchdog FSoE e os safety-related application parameters são configurados via o safety configurator do FSoE Master.
Quantos ciclos FSoE são necessários?
Como os parâmetros de aplicação podem ter qualquer tamanho, o número total de ciclos FSoE depende tanto do application parameter length quanto do safety data length fixo do Safety PDU:
$$ \text{ciclos} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$onde o 6 corresponde aos três campos de cabeçalho de 16 bits (comm. param. length, watchdog, app. param. length). Se nem todos os octetos de safety data forem necessários no último ciclo FSoE, os octetos não utilizados devem ser transferidos como 0.
Para o exemplo da especificação (4 octetos de safety data, 2 octetos de application parameter), o payload total é 6 + 2 = 8 octetos, o que cabe em ⌈8/4⌉ = 2 ciclos FSoE. O primeiro ciclo carrega o communication parameter length, o watchdog e os primeiros dois octetos seriam o application parameter length — mas neste exemplo o application parameter length (2) é enviado no segundo ciclo junto com os dois bytes do parâmetro de aplicação, como mostrado abaixo.
Primeiro ciclo — Parâmetros de comunicação
Primeiro Safety Master PDU (FSoE Master → Slave)
O master envia este PDU para transferir o communication parameter length e o valor do watchdog FSoE. Esta é a Tabela 19 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Pontos-chave:
- Command (octeto 0) é
Parameter. - SafeData[0..1] (octetos 1 e 2) carregam o communication parameter length de 16 bits em octetos. Este é sempre 2 (little-endian:
0x02, 0x00), porque o único parâmetro de comunicação é o valor do watchdog de 16 bits. - SafeData[2..3] (octetos 5 e 6) carregam o valor do FSoE watchdog de 16 bits em milissegundos (little-endian).
- Conn_Id (octetos 9 e 10) carrega o Connection ID — como no Connection state, agora é preenchido em cada Safety PDU.
- CRC_0 e CRC_1 são transmitidos como valores little-endian de 16 bits. A herança de CRC está ativa em todos os ciclos do Parameter state.
Primeiro Safety Slave PDU (FSoE Slave → Master, confirmação)
O slave confirma o primeiro Parameter PDU ecoando de volta os mesmos safety data. Esta é a Tabela 20 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | comm. param. len, lo Octet 1 — = 2 | comm. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | watchdog, lo Octet 5 — in ms | watchdog, hi Octet 6 — in ms | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Segundo ciclo — Parâmetros de aplicação
O FSoE Master envia o segundo Safety Master PDU assim que recebe corretamente o primeiro Safety Slave PDU.
Segundo Safety Master PDU (FSoE Master → Slave)
O master envia este PDU para transferir o application parameter length e os bytes do parâmetro de aplicação em si. Esta é a Tabela 21 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Pontos-chave:
- SafeData[0..1] (octetos 1 e 2) carregam o application parameter length de 16 bits em octetos (little-endian). Neste exemplo, é 2.
- SafeData[2..3] (octetos 5 e 6) carregam os bytes do parâmetro de aplicação. Neste exemplo, há exatamente 2 bytes, preenchendo ambos os slots disponíveis.
- Se o parâmetro de aplicação fosse mais longo que os octetos de SafeData disponíveis em um ciclo, a transferência continuaria em ciclos adicionais, com os bytes restantes colocados nas mesmas posições de SafeData (começando em SafeData[0] do próximo ciclo, após qualquer cabeçalho restante). Octetos não utilizados no último ciclo são definidos como 0.
Segundo Safety Slave PDU (FSoE Slave → Master, confirmação)
O slave confirma o segundo Parameter PDU ecoando de volta os mesmos safety data. Esta é a Tabela 22 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Parameter Octet 0 | app. param. len, lo Octet 1 — = 2 | app. param. len, hi Octet 2 — = 0 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | app. param. byte 1 Octet 5 | app. param. byte 2 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Juntando tudo: a troca do Parameter state
O Parameter state é um handshake de eco em múltiplos ciclos. Cada ciclo segue o mesmo padrão:
- Master → Slave: Safety Master PDU com
Command = Parameter, carregando o próximo bloco do payload de parâmetros nos campos SafeData. - Slave → Master: Safety Slave PDU com
Command = Parameter, ecoando de volta os mesmos safety data.
O master envia o próximo ciclo apenas após receber corretamente a confirmação do slave do ciclo anterior. A transferência continua até que todos os parâmetros de comunicação e de aplicação tenham sido enviados. Após o master transferir o conjunto completo de parâmetros e receber a confirmação final, ele sai do Parameter state enviando um Safety PDU com o comando Data — isso transiciona a conexão para a troca cíclica de dados. Se qualquer nó detectar um erro de comunicação FSoE durante a troca, ambos retornam ao Reset state.
Por que a herança de CRC é importante no Parameter state?
Como a transferência de parâmetros abrange múltiplos ciclos FSoE, a herança de CRC é o que vincula os PDUs individuais em uma única transferência relevante para a segurança. O CRC de cada ciclo é calculado não apenas sobre os bytes do PDU atual, mas também sobre o CRC do PDU anterior — formando uma cadeia que o receptor pode verificar de ponta a ponta. Se qualquer PDU na sequência for corrompido, perdido ou reordenado, a cadeia de CRC é quebrada e o receptor detecta o erro. É por isso que a especificação observa que “a herança de CRC garante segurança e transferência de parâmetros consistente.” Consulte FSoE: How does CRC inheritance work? para os detalhes do algoritmo.
Resumo
No Parameter state, o FSoE Safety PDU carrega um payload de parâmetros de tamanho variável encabeçado por três campos de 16 bits: o communication parameter length (sempre 2), o valor do FSoE watchdog em milissegundos e o application parameter length. Os bytes do parâmetro de aplicação seguem. Como o payload pode exceder o safety data length fixo do PDU, a transferência pode abranger múltiplos ciclos FSoE, com octetos não utilizados no último ciclo definidos como 0. O slave confirma cada ciclo ecoando de volta os safety data. A herança de CRC em todos os ciclos garante a segurança e a consistência da transferência completa de parâmetros. A conexão sai do Parameter state quando o master envia o comando Data, entrando na troca cíclica de dados.
Referências
- ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tabelas 18–22.
Artigos relacionados
Visão geral e noções básicas
- What does the FSoE abbreviation actually mean? — o que significa a sigla FSoE
- FSoE frame structure explained by examples — layout geral do Safety PDU
- All the states of the FSoE state machine — os cinco estados FSoE e suas transições
- FSoE: Safety PDU command table — a lista completa de comandos FSoE
Estruturas PDU por estado
- FSoE Reset State PDU: Master and Slave Structure — layout do PDU e códigos de erro para o estado Reset
- FSoE Session PDU: Master and Slave Structure — layout do PDU para o estado Session
- FSoE Connection PDU: Master and Slave Structure — layout do PDU para o estado Connection
- FSoE Data PDU: Master and Slave Structure — layout do PDU para o estado Data
- FSoE Reset PDU: Master and Slave Structure — layouts de bytes para todos os tamanhos de safety data
CRC
- FSoE CRC: Which polynomial does it use? — o polinômio de 17 bits por trás do CRC FSoE
- How are the FSoE CRC tables constructed? — como as lookup tables do CRC são geradas
- FSoE: How does CRC inheritance work? — como a cadeia de CRC vincula PDUs consecutivos
- How to compute the CRC checksum for FSoE PDUs? — algoritmo de cálculo de CRC byte a byte
Códigos de erro e formato de dados
- FSoE: List of all communication error codes — todos os códigos de erro de comunicação FSoE
- FSoE: Is data transmitted little-endian or big-endian? — ordem de bytes de campos multi-byte