Stav Connection následuje po stavu Session při navazování FSoE spojení. Jeho účelem je přenést 16bitový Connection ID — jedinečný identifikátor generovaný bezpečnostním konfigurátorem FSoE Master — společně s 16bitovou FSoE Slave Address z Masteru do Slave. Slave potvrdí tím, že stejná bezpečnostní data odešle zpět. Od tohoto okamžiku je Connection ID přenášeno v poli Conn_Id každé následující Safety PDU, takže oba uzly mohou ověřit, zda je telegram skutečně adresován jim.
Tento článek projde dvěma PDU stavu Connection definovanými v ETG.5100 S (D) V1.2.0, §8.2.2.4, 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 — relevantní datové bajty jsou Connection ID a FSoE Slave Address. V každé PDU stavu Connection nesou čtyři oktety SafeData dvě 16bitové hodnoty:
SafeData[0..1](oktety 1 a 2) — Connection ID (nízký oktet, vysoký oktet). Jedná se o jedinečnou 16bitovou hodnotu generovanou bezpečnostním konfigurátorem;0x0000není povoleno, takže v jednom komunikačním systému může současně existovat až 65 535 FSoE spojení.SafeData[2..3](oktety 5 a 6) — FSoE Slave Address (nízký oktet, vysoký oktet). Jedná se o jedinečnou adresu nastavenou na příslušném FSoE Slave zařízení.Na rozdíl od stavů Reset a Session pole
Conn_Id(oktety 9 a 10) již není 0 — nyní nese skutečný Connection ID, přesně tak, jak tomu bude v každé následující Safety PDU po navázání spojení. Pole CRC jsou stále přenášena a musí se ověřit; počítají se z počátečního stavu reset zděděného z 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 Connection a kdy se z něj vystupuje?
Do stavu Connection se vstupuje, když Master opustí stav Session odesláním Safety Master PDU s komandou Connection. Přechody stavů zrcadlí přechody stavu Session:
| Směr | Podmínka |
|---|---|
| Master opouští Connection | Přenést kompletní Connection ID a FSoE Slave Address 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í Connection | Přijmout Safety PDU s komandou Data od Master. |
Oba uzly také okamžitě opustí stav Connection, pokud detekují chybu komunikace FSoE — v takovém případě se vrátí do stavu Reset.
Bezpečnostní data přenášená ve stavu Connection
Před prozkoumáním úplného rozložení PDU se vyplatí zaměřit pouze na část bezpečnostních dat. Tabulka 15 ETG.5100 S (D) V1.2.0 definuje, které bajty se přenášejí:
| Oktet SafetyData | Popis |
|---|---|
| 0 | nízký oktet (bity 0–7) Connection ID |
| 1 | vysoký oktet (bity 8–15) Connection ID |
| 2 | nízký oktet (bity 0–7) FSoE Slave Address |
| 3 | vysoký oktet (bity 8–15) FSoE Slave Address |
Connection ID i FSoE Slave Address jsou každé 16 bitů široké, takže dohromady zabírají přesně 4 oktety SafeData. To má důležitý důsledek pro počet potřebných FSoE cyklů:
| Délka bezpečnostních dat | Cykly k přenosu Connection ID + Slave Address | Důvod |
|---|---|---|
| 4 oktety | 1 cyklus | Všechny 4 oktety se vejdou do jedné PDU. |
| 2 oktety | 2 cykly | Pouze 2 oktety SafeData na cyklus. |
| 1 oktet | 4 cykly | Pouze 1 oktet SafeData na cyklus. |
Proto příklady specifikace používají 4 oktety bezpečnostních dat: s 4 oktety se celý Connection ID a FSoE Slave Address přenášejí v jediném FSoE cyklu.
Master Connection PDU (FSoE Master → Slave)
Master odesílá tuto PDU k přenosu Connection ID a FSoE Slave Address. Následující příklad je Tabulka 16 ETG.5100 S (D) V1.2.0 pro 4 oktety bezpečnostních dat.
| Komanda | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Oktet 0 | Connection Id, nízký oktet Oktet 1 | Connection Id, vysoký oktet Oktet 2 | CRC_0_Lo Oktet 3 | CRC_0_Hi Oktet 4 | FSoE Slave Address, nízký oktet Oktet 5 | FSoE Slave Address, vysoký oktet Oktet 6 | CRC_1_Lo Oktet 7 | CRC_1_Hi Oktet 8 | Connection Id, nízký oktet Oktet 9 | Connection Id, vysoký oktet Oktet 10 |
Klíčové body:
- Komanda (oktet 0) je
Connection. - SafeData[0..1] (oktety 1 a 2) nese 16bitový Connection ID (little-endian). Jedná se o stejnou hodnotu, která se nyní objevuje také v poli
Conn_Id. - SafeData[2..3] (oktety 5 a 6) nese 16bitovou FSoE Slave Address (little-endian). Jedná se o jedinečnou adresu konfigurovanou na zařízení Slave.
- Conn_Id (oktety 9 a 10) nese Connection ID — již není 0 jako ve stavech Reset a Session. Od této PDU dále je pole
Conn_Idvyplněno v každé Safety PDU. - 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 Connection PDU (FSoE Slave → Master, potvrzení)
Slave potvrzuje komandu Connection tím, že odesílá zpět stejná bezpečnostní data — tedy odesílá zpět Connection ID a FSoE Slave Address, které odeslal Master. Jedná se o Tabulku 17 ETG.5100 S (D) V1.2.0.
| Komanda | SafeData[0] | SafeData[1] | CRC_0 | SafeData[2] | SafeData[3] | CRC_1 | Conn_Id | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Connection Oktet 0 | Connection Id, nízký oktet Oktet 1 | Connection Id, vysoký oktet Oktet 2 | CRC_0_Lo Oktet 3 | CRC_0_Hi Oktet 4 | FSoE Slave Address, nízký oktet Oktet 5 | FSoE Slave Address, vysoký oktet Oktet 6 | CRC_1_Lo Oktet 7 | CRC_1_Hi Oktet 8 | Connection Id, nízký oktet Oktet 9 | Connection Id, vysoký oktet Oktet 10 |
Na rozdíl od stavu Session, kde Slave odpovídá vlastním nezávisle generovaným Slave Session ID, ve stavu Connection Slave odesílá zpět Connection ID a FSoE Slave Address, které odeslal Master. Tímto způsobem Slave potvrzuje, že přijal a přijal adresovací informaci.
Proč se přenáší jak Connection ID, tak FSoE Slave Address?
Obě hodnoty plní doplňkové role při adresování:
- FSoE Slave Address je jedinečná v komunikačním systému a je nastavena na příslušném FSoE Slave zařízení. Přenosem společně s Connection ID může Slave ověřit, zda byl skutečně adresován — takže by bylo detekováno neplatné adresování.
- Connection ID je také jedinečný v komunikačním systému (generovaný bezpečnostním konfigurátorem FSoE Master). Protože je jedinečný, je odesílán v poli
Conn_Idkaždé následující Safety PDU, takže FSoE Master i FSoE Slave mohou detekovat, zda jsou telegramem adresováni.
Kombinace obou znamená, že Slave může ověřit během navazování spojení, že je zamýšleným cílem (prostřednictvím FSoE Slave Address), a poté během cyklického provozu mohou oba uzly ověřit každý telegram (prostřednictvím Connection ID v poli Conn_Id).
Kolik FSoE spojení je možných?
Connection ID je 16bitová hodnota, což nominálně umožňuje 65 536 odlišných hodnot. Nicméně Connection ID = 0x0000 není povoleno, takže maximální počet FSoE spojení v komunikačním systému je 65 535. Pokud je v komunikačním systému přítomno několik FSoE Master, uživatel musí zajistit, aby Connection ID používané všemi Master byly jedinečné napříč celým systémem.
Shrnutí: výměna ve stavu Connection
Stav Connection je jednoduché handshake s odezvou:
- Master → Slave: Safety Master PDU s
Command = Connection, nese Connection ID vSafeData[0..1], FSoE Slave Address vSafeData[2..3]a Connection ID v poliConn_Id. - Slave → Master: Safety Slave PDU s
Command = Connection, odesílá zpět stejný Connection ID a FSoE Slave Address.
Jakmile Master přenese kompletní Connection ID a FSoE Slave Address a přijme potvrzení od Slave, opouští stav Connection 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.
Shrnutí
Ve stavu Connection nese FSoE Safety PDU dvě 16bitové hodnoty v polích SafeData: Connection ID (jedinečný systémový identifikátor generovaný bezpečnostním konfigurátorem) a FSoE Slave Address (jedinečná adresa nastavená na zařízení Slave). Slave potvrzuje tím, že tato data odešle zpět. Na rozdíl od stavů Reset a Session je pole Conn_Id nyní vyplněno skutečným Connection ID — a zůstává vyplněno v každé následující Safety PDU, což oběma uzlům umožňuje ověřit, že je každý telegram adresován jim. Protože Connection ID 0x0000 není povoleno, může v jednom komunikačním systému současně existovat až 65 535 FSoE spojení.
Reference
- ETG.5100 S (D) V1.2.0, §8.2.2.4 Connection state, Tabulky 15–17.
Související příspěvky
Přehled a základy
- What does the FSoE abbreviation actually mean? — co znamená zkratka FSoE
- FSoE frame structure explained by examples — obecné rozložení Safety PDU
- All the states of the FSoE state machine — pět stavů FSoE a jejich přechody
- FSoE: Safety PDU command table — úplný seznam FSoE komand
Struktury PDU podle stavů
- FSoE Reset State PDU: Master and Slave Structure — rozložení PDU a chybové kódy pro stav Reset
- FSoE Session PDU: Master and Slave Structure — rozložení PDU pro stav Session
- FSoE Parameter PDU: Master and Slave Structure — rozložení PDU pro stav Parameter
- FSoE Data PDU: Master and Slave Structure — rozložení PDU pro stav Data
- FSoE Reset PDU: Master and Slave Structure — rozložení bajtů pro všechny délky bezpečnostních dat
CRC
- FSoE CRC: Which polynomial does it use? — 17bitový polynom za FSoE CRC
- How are the FSoE CRC tables constructed? — jak se generují vyhledávací tabulky CRC
- FSoE: How does CRC inheritance work? — jak řetězec CRC propojuje po sobě jdoucí PDU
- How to compute the CRC checksum for FSoE PDUs? — algoritmus výpočtu CRC bajt po bajtu
Chybové kódy a formát dat
- FSoE: List of all communication error codes — všechny chybové kódy komunikace FSoE
- FSoE: Is data transmitted little-endian or big-endian? — pořadí bajtů vícebajtových polí