O Connection state sucede o Session state na configuração da conexão FSoE. Seu propósito é transferir o Connection ID de 16 bits — um identificador único gerado pelo safety configurator do FSoE Master — junto com o FSoE Slave Address de 16 bits do master para o slave. O slave confirma ecoando os mesmos safety data de volta. A partir desse ponto, o Connection ID é transportado no campo Conn_Id de cada Safety PDU subsequente, para que ambos os nós possam verificar se um telegrama está realmente endereçado a eles.
Este artigo percorre os dois PDUs do Connection state definidos na ETG.5100 S (D) V1.2.0, §8.2.2.4, 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.
Nota — os bytes de dados relevantes são o Connection ID e o FSoE Slave Address. Em cada PDU do Connection state, os quatro octetos de SafeData carregam dois valores de 16 bits:
SafeData[0..1](octetos 1 e 2) — o Connection ID (octeto baixo, octeto alto). Este é um valor único de 16 bits gerado pelo safety configurator;0x0000não é permitido, então até 65 535 conexões FSoE podem coexistir em um sistema de comunicação.SafeData[2..3](octetos 5 e 6) — o FSoE Slave Address (octeto baixo, octeto alto). Este é um endereço único configurado no respectivo dispositivo FSoE Slave.Diferente dos estados Reset e Session, o campo
Conn_Id(octetos 9 e 10) não é mais 0 — ele agora carrega o Connection ID real, assim como fará em cada Safety PDU subsequente após o estabelecimento da conexão. Os campos de CRC ainda são transmitidos e devem verificar, calculados a partir do reset initial state herdado do Reset state precedente (consulte FSoE: How does CRC inheritance work? e How to compute the CRC checksum for FSoE PDUs?).
Quando o Connection state é entrada e saído?
O Connection state é entrado quando o master sai do Session state enviando um Safety Master PDU com o comando Connection. As transições de estado espelham as do Session state:
| Direção | Condição |
|---|---|
| Master sai de Connection | Transferiu o Connection ID completo e o FSoE Slave Address e recebeu a confirmação associada do slave, então envia um Safety PDU com o comando Data (entrando na troca cíclica de dados). |
| Slave sai de Connection | Recebe um Safety PDU com o comando Data do master. |
Ambos os nós também saem do Connection state imediatamente se detectarem um erro de comunicação FSoE — nesse caso, eles retornam ao Reset state.
Safety data transferidos no Connection state
Antes de examinar o layout completo do PDU, vale focar apenas na porção de safety data. A Tabela 15 da ETG.5100 S (D) V1.2.0 define quais bytes são transferidos:
| Octeto SafetyData | Descrição |
|---|---|
| 0 | octeto baixo (bits 0–7) do Connection ID |
| 1 | octeto alto (bits 8–15) do Connection ID |
| 2 | octeto baixo (bits 0–7) do FSoE Slave Address |
| 3 | octeto alto (bits 8–15) do FSoE Slave Address |
O Connection ID e o FSoE Slave Address têm cada um 16 bits de largura, então juntos ocupam exatamente 4 octetos de SafeData. Isso tem uma consequência importante para o número de ciclos FSoE necessários:
| Safety data length | Ciclos para transferir Connection ID + Slave Address | Motivo |
|---|---|---|
| 4 octetos | 1 ciclo | Todos os 4 octetos cabem em um PDU. |
| 2 octetos | 2 ciclos | Apenas 2 octetos de SafeData por ciclo. |
| 1 octeto | 4 ciclos | Apenas 1 octeto de SafeData por ciclo. |
É por isso que os exemplos da especificação usam 4 octetos de safety data: com 4 octetos, o Connection ID inteiro e o FSoE Slave Address são transferidos em um único ciclo FSoE.
Master Connection PDU (FSoE Master → Slave)
O master envia este PDU para transferir o Connection ID e o FSoE Slave Address. O exemplo abaixo é a Tabela 16 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Pontos-chave:
- Command (octeto 0) é
Connection. - SafeData[0..1] (octetos 1 e 2) carregam o Connection ID de 16 bits (little-endian). Este é o mesmo valor que agora também aparece no campo
Conn_Id. - SafeData[2..3] (octetos 5 e 6) carregam o FSoE Slave Address de 16 bits (little-endian). Este é o endereço único configurado no dispositivo slave.
- Conn_Id (octetos 9 e 10) carrega o Connection ID — ele não é mais 0 como nos estados Reset e Session. A partir deste PDU, o campo
Conn_Idé preenchido em cada Safety PDU. - CRC_0 e CRC_1 são transmitidos como valores little-endian de 16 bits, calculados a partir do reset initial state herdado do Reset state precedente.
Slave Connection PDU (FSoE Slave → Master, confirmação)
O slave confirma o comando Connection enviando de volta os mesmos safety data — ou seja, ele ecoa o Connection ID e o FSoE Slave Address que o master enviou. Esta é a Tabela 17 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Octet 0 | Connection Id, low octet Octet 1 | Connection Id, high octet Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | FSoE Slave Address, low octet Octet 5 | FSoE Slave Address, high octet Octet 6 | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | Connection Id, low octet Octet 9 | Connection Id, high octet Octet 10 |
Diferente do Session state, onde o slave responde com seu próprio Slave Session ID gerado independentemente, no Connection state o slave ecoa de volta o Connection ID e o FSoE Slave Address que o master enviou. Esta é a forma do slave confirmar que recebeu e aceitou as informações de endereçamento.
Por que o Connection ID e o FSoE Slave Address são ambos transferidos?
Os dois valores têm papéis complementares no endereçamento:
- O FSoE Slave Address é único no sistema de comunicação e é configurado no respectivo dispositivo FSoE Slave. Ao transferi-lo junto com o Connection ID, o slave pode verificar se foi realmente endereçado — de modo que um endereçamento inválido seria detectado.
- O Connection ID também é único no sistema de comunicação (gerado pelo safety configurator do FSoE Master). Por ser único, é enviado no campo
Conn_Idde cada Safety PDU subsequente, para que tanto o FSoE Master quanto o FSoE Slave possam detectar se estão endereçados pelo telegrama.
A combinação dos dois significa que um slave pode verificar durante a configuração da conexão que é o alvo pretendido (via FSoE Slave Address), e então durante a operação cíclica ambos os nós podem verificar cada telegrama (via Connection ID no campo Conn_Id).
Quantas conexões FSoE são possíveis?
O Connection ID é um valor de 16 bits, o que nominalmente permitiria 65 536 valores distintos. No entanto, Connection ID = 0x0000 não é permitido, então o número máximo de conexões FSoE em um sistema de comunicação é 65 535. Se vários FSoE Masters estiverem presentes no sistema de comunicação, o usuário deve garantir que os Connection IDs usados por todos os masters sejam únicos em todo o sistema.
Juntando tudo: a troca do Connection state
O Connection state é um handshake simples de eco:
- Master → Slave: Safety Master PDU com
Command = Connection, carregando o Connection ID emSafeData[0..1], o FSoE Slave Address emSafeData[2..3]e o Connection ID no campoConn_Id. - Slave → Master: Safety Slave PDU com
Command = Connection, ecoando de volta o mesmo Connection ID e FSoE Slave Address.
Após o master transferir o Connection ID completo e o FSoE Slave Address e receber a confirmação do slave, ele sai do Connection 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.
Resumo
No Connection state, o FSoE Safety PDU carrega dois valores de 16 bits nos campos SafeData: o Connection ID (um identificador único em todo o sistema gerado pelo safety configurator) e o FSoE Slave Address (um endereço único configurado no dispositivo slave). O slave confirma ecoando esses dados de volta. Diferente dos estados Reset e Session, o campo Conn_Id agora é preenchido com o Connection ID real — e permanece preenchido em cada Safety PDU subsequente, permitindo que ambos os nós verifiquem se cada telegrama está endereçado a eles. Como o Connection ID 0x0000 não é permitido, até 65 535 conexões FSoE podem coexistir em um sistema de comunicação.
Referências
- ETG.5100 S (D) V1.2.0, §8.2.2.4 Connection state, Tabelas 15–17.
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 Parameter PDU: Master and Slave Structure — layout do PDU para o estado Parameter
- 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