O Data state é o estado final da configuração da conexão FSoE e aquele em que a conexão passa o resto de seu tempo de vida. Ele sucede o Parameter state. Diferente dos estados anteriores, onde o número de ciclos FSoE era fixado pelo protocolo, o Data state executa continuamente — ciclos FSoE são transferidos até que ocorra um erro de comunicação ou um nó FSoE seja parado localmente. Em cada ciclo, o FSoE Master envia SafeOutputs para o FSoE Slave, e o FSoE Slave confirma enviando SafeInputs de volta ao master.
O Data state usa dois comandos:
- ProcessData — usado quando os safety data são válidos.
- FailSafeData — usado quando um nó detecta localmente que seus safety data não são válidos ou devem ser comutados para o safe state.
Este artigo percorre os quatro PDUs do Data state definidos na ETG.5100 S (D) V1.2.0, §8.2.2.6, usando o exemplo canônico da especificação de 4 octetos de safety data.
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 é mostrado em FSoE Reset PDU: Master and Slave Structure.
Quando o Data state é entrada e saído?
O Data state é entrado quando o master sai do Parameter state enviando um Safety Master PDU com o comando ProcessData (ou FailSafeData). Uma vez no Data state, a conexão permanece ali indefinidamente:
| Direção | Condição |
|---|---|
| Master permanece em Data | Envia PDUs de ProcessData ou FailSafeData ciclicamente até ocorrer um erro de comunicação ou ser parado localmente. |
| Slave permanece em Data | Confirma cada PDU do master e envia ProcessData ou FailSafeData de volta até ocorrer um erro de comunicação ou ser parado localmente. |
Ambos os nós saem do Data state imediatamente se detectarem um erro de comunicação FSoE — nesse caso, eles retornam ao Reset state.
Comando ProcessData (dados válidos)
Safety Master PDU (FSoE Master → Slave)
O master envia este PDU para transferir SafeOutputs ao slave. Esta é a Tabela 23 da ETG.5100 S (D) V1.2.0 para 4 octetos de safety data.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| ProcessData Octet 0 | SafeOutputs, byte 1 Octet 1 | SafeOutputs, byte 2 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | SafeOutputs, byte 3 Octet 5 | SafeOutputs, byte 4 Octet 6 | 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) é
ProcessData. - SafeData[0..3] carregam os SafeOutputs — os dados de saída relacionados à segurança do master para o slave. Os bytes são posicionados em ordem: SafeData[0] é o 1º octeto, SafeData[1] é o 2º, e assim por diante.
- Conn_Id (octetos 9 e 10) carrega o Connection ID, como nos estados Connection e Parameter.
- 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 Data state, encadeando cada PDU ao anterior.
Safety Slave PDU (FSoE Slave → Master)
O slave confirma o PDU de ProcessData do master e envia SafeInputs de volta ao master. Esta é a Tabela 24 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| ProcessData Octet 0 | SafeInputs, byte 1 Octet 1 | SafeInputs, byte 2 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | SafeInputs, byte 3 Octet 5 | SafeInputs, byte 4 Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
Note a assimetria com os estados anteriores: no Data state, o slave não ecoa de volta os safety data do master. Em vez disso, ele envia seus próprios SafeInputs — os dados de entrada relacionados à segurança do slave para o master. O master envia SafeOutputs, o slave responde com SafeInputs; cada direção carrega seu próprio payload independente.
Comando FailSafeData (safe state)
Se o FSoE Master detectar localmente que os SafeOutputs não são válidos ou devem ser comutados para o safe state, ele envia o comando FailSafeData em vez de ProcessData. O mesmo se aplica ao FSoE Slave: se ele detectar localmente que os SafeInputs não são válidos ou devem ser comutados para o safe state, ele envia FailSafeData em vez de ProcessData.
Safety Master PDU com FailSafeData (FSoE Master → Slave)
Esta é a Tabela 25 da ETG.5100 S (D) V1.2.0 para 4 octetos de safety data.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| FailSafeData Octet 0 | 0 Octet 1 — fail-safe data | 0 Octet 2 — fail-safe data | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — fail-safe data | 0 Octet 6 — fail-safe data | 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) é
FailSafeData. - Todos os octetos de SafeData são definidos como 0 — os fail-safe data não carregam nenhum payload útil; eles sinalizam que o remetente comutou suas saídas para o safe state.
- Os campos Conn_Id e CRC comportam-se exatamente como no PDU de ProcessData. O CRC ainda é calculado e ainda deve verificar — o fail-safe state é um estado operacional definido, não um erro de comunicação.
Safety Slave PDU com FailSafeData (FSoE Slave → Master)
Esta é a Tabela 26 da ETG.5100 S (D) V1.2.0 para 4 octetos de safety data.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| FailSafeData Octet 0 | 0 Octet 1 — fail-safe data | 0 Octet 2 — fail-safe data | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — fail-safe data | 0 Octet 6 — fail-safe data | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, lo Octet 9 | Connection Id, hi Octet 10 |
ProcessData e FailSafeData são escolhidos independentemente
Uma propriedade-chave do Data state é que a escolha entre ProcessData e FailSafeData é independente em cada direção — ela depende apenas de circunstâncias locais, não do comando recebido do peer:
- O master envia ProcessData se seus SafeOutputs são válidos, ou FailSafeData se não são.
- O slave envia ProcessData se seus SafeInputs são válidos, ou FailSafeData se não são.
Isso significa que é perfeitamente normal que uma direção carregue ProcessData enquanto a outra carrega FailSafeData no mesmo ciclo. Por exemplo, se os SafeOutputs do master são válidos, mas os SafeInputs do slave não são, o master envia ProcessData e o slave responde com FailSafeData. Nenhum nó precisa aguardar o outro trocar de comando; a decisão é puramente local.
Juntando tudo: a troca do Data state
O Data state é uma troca cíclica contínua:
- Master → Slave: Safety Master PDU com
Command = ProcessData(carregando SafeOutputs) ouCommand = FailSafeData(todos os SafeData = 0). - Slave → Master: Safety Slave PDU com
Command = ProcessData(carregando SafeInputs) ouCommand = FailSafeData(todos os SafeData = 0).
Este ciclo se repete indefinidamente. O comando em cada direção é escolhido independentemente com base na validade local dos safety data. Se qualquer nó detectar um erro de comunicação FSoE (consulte FSoE: List of all communication error codes), ambos os nós retornam ao Reset state e a configuração da conexão recomeça.
Resumo
No Data state, o FSoE Safety PDU finalmente carrega dados de segurança do usuário: o master envia SafeOutputs e o slave responde com SafeInputs, cada um usando o comando ProcessData. Se os safety data de qualquer nó não forem válidos ou devam ser comutados para o safe state, ele envia o comando FailSafeData em vez disso, com todos os octetos de SafeData definidos como 0. A escolha entre os dois comandos é independente em cada direção e depende apenas de circunstâncias locais. O Data state executa continuamente até ocorrer um erro de comunicação (acionando um retorno a Reset) ou um nó ser parado localmente. A herança de CRC encadeia cada PDU ao anterior durante todo o Data state, de modo que qualquer corrupção, perda ou reordenação é detectada imediatamente.
Referências
- ETG.5100 S (D) V1.2.0, §8.2.2.6 Data state, Tabelas 23–26.
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 Parameter PDU: Master and Slave Structure — layout do PDU para o estado Parameter
- 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