O Session state sucede o Reset state na configuração da conexão FSoE. Seu único propósito é trocar um par de números aleatórios de 16 bits — o Master Session ID e o Slave Session ID — entre os dois nós. Esses IDs não têm relevância para a segurança; eles existem apenas para diferenciar múltiplas sequências de Safety PDU no caso de vários restarts da conexão FSoE, de modo que um PDU obsoleto de uma instância anterior de conexão possa ser distinguido de um novo.
Este artigo percorre os dois PDUs do Session state definidos na ETG.5100 S (D) V1.2.0, §8.2.2.3, 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 únicos bytes de dados relevantes são os dois octetos do Session ID. Em cada PDU do Session state,
SafeData[0]eSafeData[1](octetos 1 e 2) juntos carregam o Session ID de 16 bits:
- Master → Slave: o Master Session ID (um número aleatório gerado pelo master).
- Slave → Master: o Slave Session ID (um número aleatório gerado pelo slave, enviado de volta como confirmação).
Todos os outros octetos de SafeData são não utilizados e devem ser definidos como 0. O campo Conn_Id também é não utilizado (definido como 0) — o Session ID não tem relevância para a segurança, então o Connection ID não é verificado neste estado. Os campos de CRC ainda são transmitidos e devem verificar, mas são calculados a partir do reset initial state porque o número de sequência e o CRC herdado foram limpos na entrada do Reset state precedente (consulte FSoE: How does CRC inheritance work? e How to compute the CRC checksum for FSoE PDUs?).
Quando o Session state é entrada e saído?
O Session state é entrado quando o master sai do Reset state enviando um Safety Master PDU com o comando Session. As transições de estado são:
| Direção | Condição |
|---|---|
| Master sai de Session | Transferiu o Master Session ID completo e recebeu as confirmações associadas do slave, então envia um Safety PDU com o comando Connection. |
| Slave sai de Session | Recebe um Safety PDU com o comando Connection do master. |
Ambos os nós também saem do Session state imediatamente se detectarem um erro de comunicação FSoE — nesse caso, eles retornam ao Reset state.
Master Session PDU (FSoE Master → Slave)
O master envia este PDU para transferir seu Master Session ID de 16 bits ao slave. O exemplo abaixo é a Tabela 13 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 | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octet 0 | Master Session Id, octet 0 Octet 1 | Master Session Id, octet 1 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
Pontos-chave:
- Command (octeto 0) é
Session. - SafeData[0] e SafeData[1] (octetos 1 e 2) carregam os dois octetos do Master Session ID de 16 bits. O master gera isso como um número aleatório uma vez por tentativa de conexão.
- Todos os outros octetos de SafeData são não utilizados e definidos como 0.
- Conn_Id é não utilizado e definido como 0 — o Session ID não tem relevância para a segurança, então o Connection ID não é verificado neste estado.
- 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 Session PDU (FSoE Slave → Master, confirmação)
O slave confirma o comando Session enviando de volta seu próprio Slave Session ID de 16 bits. Esta é a Tabela 14 da ETG.5100 S (D) V1.2.0.
| Command | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Session Octet 0 | Slave Session Id, octet 0 Octet 1 | Slave Session Id, octet 1 Octet 2 | CRC_0_Lo Octet 3 | CRC_0_Hi Octet 4 | 0 Octet 5 — unused | 0 Octet 6 — unused | CRC_1_Lo Octet 7 | CRC_1_Hi Octet 8 | 0 Octet 9 — unused | 0 Octet 10 — unused |
O slave não ecoa o Session ID do master — ele responde com seu próprio Slave Session ID aleatório gerado independentemente. Ambos os IDs são então usados juntos para identificar essa instância específica de conexão.
Quantos ciclos FSoE a transferência do Session ID leva?
O Session ID tem 16 bits de largura e é carregado nos dois primeiros octetos de SafeData do PDU. O número de ciclos FSoE necessários para transferi-lo depende, portanto, do safety data length:
| Safety data length | Ciclos para transferir o Session ID | Motivo |
|---|---|---|
| ≥ 2 octetos | 1 ciclo | Ambos os octetos do Session ID cabem em SafeData[0] e SafeData[1]. |
| 1 octeto | 2 ciclos | Apenas SafeData[0] está disponível por ciclo, então os dois octetos são transferidos em dois PDUs sucessivos. |
É por isso que os exemplos da especificação usam 4 octetos de safety data: com 4 octetos (ou qualquer tamanho ≥ 2), o Session ID de 16 bits inteiro é transferido em um único ciclo FSoE.
Juntando tudo: a troca do Session state
O Session state é um handshake simples de duas etapas:
- Master → Slave: Safety Master PDU com
Command = Session, carregando o Master Session ID emSafeData[0..1]. - Slave → Master: Safety Slave PDU com
Command = Session, carregando o Slave Session ID emSafeData[0..1].
Após o master transferir o Master Session ID completo e receber a(s) confirmação(ões) do slave, ele sai do Session state enviando um Safety PDU com o comando Connection — este é também o sinal para o slave sair do Session state. Se qualquer nó detectar um erro de comunicação FSoE durante a troca, ambos retornam ao Reset state.
Por que o Connection ID é definido como 0 no Session state?
O Session ID não tem relevância para a segurança. Seu único propósito é diferenciar múltiplas sequências de Safety PDU no caso de vários restarts da conexão FSoE — por exemplo, para que um PDU atrasado de uma instância anterior de conexão não seja confundido com um PDU da nova conexão. Como um Session ID corrompido ou trocado não pode por si só causar um risco de segurança, a especificação afirma explicitamente que uma troca no nó receptor não precisa ser examinada do ponto de vista de segurança. Consequentemente, o Connection ID é definido como 0 para o comando Session — a conexão ainda não foi estabelecida, então não há Connection ID para verificar.
Resumo
No Session state, o FSoE Safety PDU é um envelope de número aleatório de dois bytes: o campo Command é Session, SafeData[0..1] carregam o Master ou Slave Session ID de 16 bits, todos os outros octetos de SafeData e o campo Conn_Id são 0, e os CRCs são calculados a partir do reset initial state herdado do Reset state precedente. A conexão sai do Session quando o master emite o comando Connection — o slave nunca envia Connection primeiro, ele apenas confirma Session com seu próprio Slave Session ID. O Session ID em si não tem relevância para a segurança; ele existe puramente para desambiguar sequências de PDU entre restarts repetidos da conexão.
Referências
- ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Tabelas 13–14.
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 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 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