FSoE: Struktura Session PDU pro Master a Slave

Stav Session následuje po stavu Reset při navazování FSoE spojení. Jeho jediným účelem je vyměnit pár 16bitových náhodných čísel — Master Session ID a Slave Session ID — mezi oběma uzly. Tyto ID nemají žádný bezpečnostní význam; existují pouze k rozlišení více sekvencí Safety PDU v případě několika restartů FSoE spojení, aby bylo možné odlišit zastaralou PDU z předchozí instance spojení od čerstvé.

Tento článek projde dvěma PDU stavu Session definovanými v ETG.5100 S (D) V1.2.0, §8.2.2.3, a to na kanonickém příkladu specifikace se 4 oktety bezpečnostních dat.

Poznámka — počet bajtů bezpečnostních dat je pevně dán pro každý směr. Každé FSoE spojení má pevnou délku bezpečnostních dat (master→slave a slave→master), konfigurovanou shodně na obou uzlech. Povolené délky jsou 1, 2, 4, 6 nebo 8 oktetů. Skutečná délka pro dané spojení závisí na FSoE Slave zařízení a musí být převzata z dokumentace Slave nebo souboru popisu zařízení (ESI/EEPROM). Níže uvedené příklady používají 4 oktety jako specifikace; rozložení bajtů pro ostatní délky je uvedeno v FSoE Reset PDU: Master and Slave Structure.

Poznámka — jedinými relevantními datovými bajty jsou dva oktety Session ID. V každé PDU stavu Session nesou SafeData[0] a SafeData[1] (oktety 1 a 2) společně 16bitový Session ID:

  • Master → Slave: Master Session ID (náhodné číslo generované Masterem).
  • Slave → Master: Slave Session ID (náhodné číslo generované Slave, odeslané zpět jako potvrzení).

Všechny ostatní oktety SafeData jsou nevyužity a musí být nastaveny na 0. Pole Conn_Id je rovněž nevyužito (nastaveno na 0) — Session ID nemá bezpečnostní význam, takže Connection ID se v tomto stavu neověřuje. Pole CRC jsou stále přenášena a musí se ověřit, ale počítají se z počátečního stavu reset, protože číslo sekvence i zděděné CRC byly vymazány při vstupu do předchozího stavu Reset (viz FSoE: How does CRC inheritance work? a How to compute the CRC checksum for FSoE PDUs?).

Kdy se vstupuje do stavu Session a kdy se z něj vystupuje?

Do stavu Session se vstupuje, když Master opustí stav Reset odesláním Safety Master PDU s komandou Session. Přechody stavů jsou:

SměrPodmínka
Master opouští SessionPřenést kompletní Master Session ID a přijmout příslušná potvrzení od Slave, poté odeslat Safety PDU s komandou Connection.
Slave opouští SessionPřijmout Safety PDU s komandou Connection od Master.

Oba uzly také okamžitě opustí stav Session, pokud detekují chybu komunikace FSoE — v takovém případě se vrátí do stavu Reset.

Master Session PDU (FSoE Master → Slave)

Master odesílá tuto PDU k přenosu svého 16bitového Master Session ID do Slave. Následující příklad je Tabulka 13 ETG.5100 S (D) V1.2.0 pro 4 oktety bezpečnostních dat.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Session
Oktet 0
Master Session Id, oktet 0
Oktet 1
Master Session Id, oktet 1
Oktet 2
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
0
Oktet 5 — nevyužito
0
Oktet 6 — nevyužito
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
0
Oktet 9 — nevyužito
0
Oktet 10 — nevyužito

Klíčové body:

  • Komanda (oktet 0) je Session.
  • SafeData[0] a SafeData[1] (oktety 1 a 2) nese dva oktety 16bitového Master Session ID. Master jej generuje jako náhodné číslo jednou za pokus o spojení.
  • Všechny ostatní oktety SafeData jsou nevyužity a nastaveny na 0.
  • Conn_Id je nevyužito a nastaveno na 0 — Session ID nemá bezpečnostní význam, takže Connection ID se v tomto stavu neověřuje.
  • CRC_0 a CRC_1 se přenášejí jako 16bitové little-endian hodnoty, počítané z počátečního stavu reset zděděného z předchozího stavu Reset.

Slave Session PDU (FSoE Slave → Master, potvrzení)

Slave potvrzuje komandu Session odesláním zpět vlastního 16bitového Slave Session ID. Jedná se o Tabulku 14 ETG.5100 S (D) V1.2.0.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Session
Oktet 0
Slave Session Id, oktet 0
Oktet 1
Slave Session Id, oktet 1
Oktet 2
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
0
Oktet 5 — nevyužito
0
Oktet 6 — nevyužito
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
0
Oktet 9 — nevyužito
0
Oktet 10 — nevyužito

Slave neodesílá zpět Session ID Master — odpovídá vlastním nezávisle generovaným náhodným Slave Session ID. Obě ID se pak společně používají k identifikaci této konkrétní instance spojení.

Kolik FSoE cyklů trvá přenos Session ID?

Session ID je 16 bitů široký a je přenášen v prvních dvou oktetech SafeData PDU. Počet FSoE cyklů potřebných k přenosu proto závisí na délce bezpečnostních dat:

Délka bezpečnostních datCykly k přenosu Session IDDůvod
≥ 2 oktety1 cyklusOba oktety Session ID se vejdou do SafeData[0] a SafeData[1].
1 oktet2 cyklyPouze SafeData[0] je k dispozici na cyklus, takže dva oktety se přenášejí ve dvě po sobě jdoucích PDU.

Proto příklady specifikace používají 4 oktety bezpečnostních dat: s 4 oktety (nebo libovolnou délkou ≥ 2) se celý 16bitový Session ID přenáší v jediném FSoE cyklu.

Shrnutí: výměna ve stavu Session

Stav Session je jednoduché dvoukrokové handshake:

  1. Master → Slave: Safety Master PDU s Command = Session, nese Master Session ID v SafeData[0..1].
  2. Slave → Master: Safety Slave PDU s Command = Session, nese Slave Session ID v SafeData[0..1].

Jakmile Master přenese kompletní Master Session ID a přijme potvrzení od Slave, opouští stav Session odesláním Safety PDU s komandou Connection — to je také signál pro Slave k opuštění stavu Session. Pokud kterýkoliv uzel během výměny detekuje chybu komunikace FSoE, oba se vrátí do stavu Reset.

Proč je Connection ID ve stavu Session nastaveno na 0?

Session ID nemá bezpečnostní význam. Jeho jediným účelem je rozlišit více sekvencí Safety PDU v případě několika restartů FSoE spojení — například aby zpožděná PDU z předchozí instance spojení nebyla zaměněna za PDU nového spojení. Protože poškozené nebo přepnuté Session ID samo o sobě nemůže způsobit bezpečnostní riziko, specifikace explicitně uvádí, že přepnutí v přijímacím uzlu nemusí být z bezpečnostního hlediska zkoumáno. V důsledku toho je Connection ID nastaveno na 0 pro komandu Session — spojení ještě nebylo navázáno, takže neexistuje žádné Connection ID, které by se ověřovalo.

Shrnutí

Ve stavu Session je FSoE Safety PDU dvou bajtovou obálkou náhodného čísla: pole Command je Session, SafeData[0..1] nese 16bitový Master nebo Slave Session ID, každý další oktet SafeData a pole Conn_Id jsou 0 a CRC se počítají z počátečního stavu reset zděděného z předchozího stavu Reset. Spojení opouští Session, když Master vydá komandu Connection — Slave nikdy neodesílá Connection jako první, pouze potvrzuje Session vlastním Slave Session ID. Samotné Session ID nemá bezpečnostní význam; existuje čistě pro rozlišení sekvencí PDU napříč opakovanými restarty spojení.

Reference

  • ETG.5100 S (D) V1.2.0, §8.2.2.3 Session state, Tabulky 13–14.

Související příspěvky

Přehled a základy

Struktury PDU podle stavů

CRC

Chybové kódy a formát dat


Podívejte se na podobné články podle kategorie: FSoE EtherCAT Safety