FSoE: Struktura Parameter PDU pro Master a Slave

Stav Parameter následuje po stavu Connection při navazování FSoE spojení. Jeho účelem je přenést bezpečnostní komunikační parametry (hodnota FSoE watchdog) a zařízení specifické bezpečnostní aplikační parametry z Masteru do Slave. Slave potvrzuje každou PDU Parameter tím, že bezpečnostní data odešle zpět. Protože aplikační parametry mohou mít libovolnou délku, může přenos zahrnovat více FSoE cyklů. Dědičnost CRC zajišťuje bezpečnost a konzistenci přenosu parametrů napříč všemi cykly (viz FSoE: How does CRC inheritance work?).

Tento článek projde PDU stavu Parameter definovanými v ETG.5100 S (D) V1.2.0, §8.2.2.5, a to na kanonickém příkladu specifikace se 4 oktety bezpečnostních dat a 2 oktety bezpečnostního aplikačního parametru, což vyžaduje dva FSoE cykly.

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 následuje stejný vzor (oktety SafeData se vyplňují v pořadí, přičemž nevyužité oktety v posledním cyklu jsou nastaveny na 0).

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

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

SměrPodmínka
Master opouští ParameterPřenést kompletní sadu komunikačních a aplikačních parametrů a přijmout příslušná potvrzení od Slave, poté odeslat Safety PDU s komandou Data (vstup do cyklické výměny dat).
Slave opouští ParameterPřijmout Safety PDU s komandou Data od Master.

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

Bezpečnostní data přenášená ve stavu Parameter

Bezpečnostní data ve stavu Parameter jsou strukturována odlišně od předchozích stavů. Místo pevné sady polí nese payload proměnné délky uvozený třemi 16bitovými poli hlavičky. Tabulka 18 ETG.5100 S (D) V1.2.0 definuje rozložení:

Oktet SafetyDataPopis
0nízký oktet (bity 0–7) délky komunikačních parametrů v oktetech (= 2)
1vysoký oktet (bity 8–15) délky komunikačních parametrů v oktetech (= 0)
2nízký oktet (bity 0–7) FSoE watchdog (v ms)
3vysoký oktet (bity 8–15) FSoE watchdog (v ms)
4nízký oktet (bity 0–7) délky aplikačních parametrů v oktetech
5vysoký oktet (bity 8–15) délky aplikačních parametrů v oktetech
61. oktet bezpečnostního aplikačního parametru
n+5n-tý oktet bezpečnostního aplikačního parametru

První dvě 16bitová pole jsou délka komunikačních parametrů (vždy 2, tj. pouze hodnota watchdog) a hodnota FSoE watchdog v milisekundách. Další 16bitové pole je délka aplikačních parametrů, následované samotnými bajty aplikačních parametrů. FSoE watchdog a bezpečnostní aplikační parametry se konfigurují prostřednictvím bezpečnostního konfigurátoru FSoE Master.

Kolik FSoE cyklů je potřeba?

Protože aplikační parametry mohou mít libovolnou délku, celkový počet FSoE cyklů závisí jak na délce aplikačních parametrů, tak na pevné délce bezpečnostních dat Safety PDU:

$$ \text{cykly} = \left\lceil \frac{6 + \text{appParamLen}}{\text{safetyDataLen}} \right\rceil $$

kde číslo 6 představuje tři 16bitová pole hlavičky (délka kom. param., watchdog, délka apl. param.). Pokud nejsou v posledním FSoE cyklu vyžadovány všechny oktety bezpečnostních dat, nevyužité oktety se přenášejí jako 0.

Pro příklad specifikace (4 oktety bezpečnostních dat, 2 oktety aplikačního parametru) je celkový payload 6 + 2 = 8 oktetů, což se vejde do ⌈8/4⌉ = 2 FSoE cyklů. První cyklus nese délku komunikačních parametrů, watchdog a první dva oktety by byly délka aplikačních parametrů — ale v tomto příkladu je délka aplikačních parametrů (2) odeslána ve druhém cyklu společně se dvěma bajty aplikačního parametru, jak je uvedeno níže.

První cyklus — Komunikační parametry

První Safety Master PDU (FSoE Master → Slave)

Master odesílá tuto PDU k přenosu délky komunikačních parametrů a hodnoty FSoE watchdog. Jedná se o Tabulku 19 ETG.5100 S (D) V1.2.0.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Parameter
Oktet 0
délka kom. param., lo
Oktet 1 — = 2
délka kom. param., hi
Oktet 2 — = 0
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
watchdog, lo
Oktet 5 — v ms
watchdog, hi
Oktet 6 — v ms
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
Connection Id, lo
Oktet 9
Connection Id, hi
Oktet 10

Klíčové body:

  • Komanda (oktet 0) je Parameter.
  • SafeData[0..1] (oktety 1 a 2) nese 16bitovou délku komunikačních parametrů v oktetech. Ta je vždy 2 (little-endian: 0x02, 0x00), protože jediným komunikačním parametrem je 16bitová hodnota watchdog.
  • SafeData[2..3] (oktety 5 a 6) nese 16bitovou hodnotu FSoE watchdog v milisekundách (little-endian).
  • Conn_Id (oktety 9 a 10) nese Connection ID — jako ve stavu Connection je nyní vyplněno v každé Safety PDU.
  • CRC_0 a CRC_1 se přenášejí jako 16bitové little-endian hodnoty. Dědičnost CRC je aktivní napříč všemi cykly stavu Parameter.

První Safety Slave PDU (FSoE Slave → Master, potvrzení)

Slave potvrzuje první PDU Parameter tím, že odesílá zpět stejná bezpečnostní data. Jedná se o Tabulku 20 ETG.5100 S (D) V1.2.0.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Parameter
Oktet 0
délka kom. param., lo
Oktet 1 — = 2
délka kom. param., hi
Oktet 2 — = 0
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
watchdog, lo
Oktet 5 — v ms
watchdog, hi
Oktet 6 — v ms
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
Connection Id, lo
Oktet 9
Connection Id, hi
Oktet 10

Druhý cyklus — Aplikační parametry

FSoE Master odesílá druhou Safety Master PDU, jakmile správně přijme první Safety Slave PDU.

Druhá Safety Master PDU (FSoE Master → Slave)

Master odesílá tuto PDU k přenosu délky aplikačních parametrů a samotných bajtů aplikačních parametrů. Jedná se o Tabulku 21 ETG.5100 S (D) V1.2.0.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Parameter
Oktet 0
délka apl. param., lo
Oktet 1 — = 2
délka apl. param., hi
Oktet 2 — = 0
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
apl. param., bajt 1
Oktet 5
apl. param., bajt 2
Oktet 6
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
Connection Id, lo
Oktet 9
Connection Id, hi
Oktet 10

Klíčové body:

  • SafeData[0..1] (oktety 1 a 2) nese 16bitovou délku aplikačních parametrů v oktetech (little-endian). V tomto příkladu je 2.
  • SafeData[2..3] (oktety 5 a 6) nese bajty aplikačních parametrů. V tomto příkladu jsou přesně 2 bajty, které vyplňují obě dostupné pozice.
  • Pokud by aplikační parametr byl delší než dostupné oktety SafeData v jednom cyklu, přenos by pokračoval v dalších cyklech, přičemž zbývající bajty by byly umístěny na stejné pozice SafeData (počínaje SafeData[0] dalšího cyklu, po případné zbývající hlavičce). Nevyužité oktety v posledním cyklu jsou nastaveny na 0.

Druhá Safety Slave PDU (FSoE Slave → Master, potvrzení)

Slave potvrzuje druhou PDU Parameter tím, že odesílá zpět stejná bezpečnostní data. Jedná se o Tabulku 22 ETG.5100 S (D) V1.2.0.

KomandaSafeData[0]SafeData[1]CRC_0SafeData[2]SafeData[3]CRC_1Conn_Id
Parameter
Oktet 0
délka apl. param., lo
Oktet 1 — = 2
délka apl. param., hi
Oktet 2 — = 0
CRC_0_Lo
Oktet 3
CRC_0_Hi
Oktet 4
apl. param., bajt 1
Oktet 5
apl. param., bajt 2
Oktet 6
CRC_1_Lo
Oktet 7
CRC_1_Hi
Oktet 8
Connection Id, lo
Oktet 9
Connection Id, hi
Oktet 10

Shrnutí: výměna ve stavu Parameter

Stav Parameter je vícacyklové handshake s odezvou. Každý cyklus následuje stejný vzor:

  1. Master → Slave: Safety Master PDU s Command = Parameter, nese další blok payloadu parametrů v polích SafeData.
  2. Slave → Master: Safety Slave PDU s Command = Parameter, odesílá zpět stejná bezpečnostní data.

Master odesílá další cyklus až poté, co správně přijme potvrzení Slave z předchozího cyklu. Přenos pokračuje, dokud nejsou odeslány všechny komunikační a aplikační parametry. Jakmile Master přenese kompletní sadu parametrů a přijme konečné potvrzení, opouští stav Parameter odesláním Safety PDU s komandou Data — tím se spojení přepne do cyklické výměny dat. Pokud kterýkoliv uzel během výměny detekuje chybu komunikace FSoE, oba se vrátí do stavu Reset.

Proč je dědičnost CRC důležitá ve stavu Parameter?

Protože přenos parametrů zahrnuje více FSoE cyklů, dědičnost CRC je to, co váže jednotlivé PDU do jediného bezpečnostně relevantního přenosu. CRC každého cyklu se počítá nejen přes bajty aktuální PDU, ale také přes CRC předchozí PDU — vytváří řetězec, který může přijímač ověřit end-to-end. Pokud je jakákoliv PDU v sekvenci poškozena, ztracena nebo přehozena, řetězec CRC se přeruší a přijímač detekuje chybu. Proto specifikace uvádí, že „dědičnost CRC zajišťuje bezpečnost a konzistentní přenos parametrů". Viz FSoE: How does CRC inheritance work? pro detaily algoritmu.

Shrnutí

Ve stavu Parameter nese FSoE Safety PDU payload parametrů proměnné délky uvozený třemi 16bitovými poli: délka komunikačních parametrů (vždy 2), hodnota FSoE watchdog v milisekundách a délka aplikačních parametrů. Následují bajty aplikačních parametrů. Protože payload může přesahovat pevnou délku bezpečnostních dat PDU, může přenos zahrnovat více FSoE cyklů, přičemž nevyužité oktety v posledním cyklu jsou nastaveny na 0. Slave potvrzuje každý cyklus tím, že bezpečnostní data odešle zpět. Dědičnost CRC napříč všemi cykly zajišťuje bezpečnost a konzistenci kompletního přenosu parametrů. Spojení opouští stav Parameter, když Master odesílá komandu Data, čímž vstupuje do cyklické výměny dat.

Reference

  • ETG.5100 S (D) V1.2.0, §8.2.2.5 Parameter state, Tabulky 18–22.

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