FCC průmyslové systémy
+420 472 774 173
info@fccps.cz
Praha
Ústí nad Labem
Bratislava
PO - PÁ
8:00 - 16:00
E-shop
Banner rubrika 1
TSN / Time Sensitive Networking: pod pokličkou
Vzdálený přístup s Ewon Cosy – postup konfigurace
LIN – představení protokolu
Propojení Siemens Profinet PLC s Modbus RTU (serial) pomocí převodníku Anybus Communicator
Modbus TCP
Profibus
EtherCAT
M.2 NVMe v průmyslovém nasazení
PROFINET
Ethernet/IP
Porovnání rádiových přijímačů Meinberg
Cloud a kybernetická bezpečnost v kritických aplikacích
Pokročilé technologie lcd displejů – optical bonding
HMS představuje komunikační řešení pro bateriové systémy skladování energie
Siemens PLC - Jak na vzdálenou správu
„Časová synchronizace – přestupná sekunda“
ATOP - průmyslové ethernetové switche, routery
Jakou technologii SSD zvolit
Využití a výhody out-of-band připojení pro zařízení IoT
CAN FD - stručný úvod
Definice rozšířené teploty pro průmyslové paměti.
Synchronizace času - profesionální audio/video broadcasting
Elektrická (smart) dálnice
Zajímavý výzkum na katedře měření ČVUT FEL
Stroj pro kontrolu kulových čepů
Příklady 3G a 4G modemů
Kontrolní zařízení pro kovové třmeny
Stabilní výkon SSD v nestabilních situacích napájení
Kontrola správného postupu ruční montáže chladiče klimatizační jednotky
Měřicí stanice pro záznam dat z průtokoměrů a měřičů hladin na modelu vodního díla
Teaming - redundantní Ethernet pod Windows
Kontrola sestavy čerpadla pro automobilový motor
Ochrana proti přepětí v kontextu průmyslové elektroniky - svodiče a galvanická izolace
Mobilní data v proudu času
Strojové vidění hlídá kvalitu v lakovně plechu
Řídicí terminály pro biologické laboratoře
Kontrola plastového výlisku
PCI Express - mýty a fakta
Identifikace a kontrola přítomnosti krytu automobilového reflektoru ve stříkací lince
CAN - stručný úvod
Stanice pro kontrolu sestavy konektoru
Kontrola 50 000 dílů za směnu
Antény pro WiFi - 1. část
Antény pro WiFi - 2. část
Základní přehled o technologii WiFi
Dodávané a podporované operační systémy pro PC
Kontrola barevného odstínu světlovodičů automobilového reflektoru
Strojové učení strojového vidění
Londýnské metro je na špici ve získávání energie pro využití ve stanicích
Pásma LTE/UMTS/EDGE/GSM používaná v České republice
Vizualizace výrobních dat, On-line reporting stavu výroby
Antimikrobiální ošetření Active Key inovace
PC Nexcom zlepšuje svážení odpadků
Vizualizace výrobních dat, On-line zásobování Machinery a Assembly
Průvodce výběrem vhodné gateway
Přehled procesorů versus verze Windows

TSN / Time Sensitive Networking: pod pokličkou


(František Ryšánek, podzim 2023)

Úvodem

Asi díky mému vztahu k sortimentu Meinberg (synchronizace času) a konkrétně IEEE1588 PTP příležitostně zpozoruji buzzword TSN, když se mihne kolem. U Meinbergů v souvislosti s PTP profilem 802.1AS, který je součástí TSN. Mimo sortiment Meinberg se jednalo dosud až na výjimky o setkání papírová, hardware s údajnou podporou TSN jsem držel v ruce asi jednou.

PTP profil 802.1AS je podivín: předně si upravuje IEEE1588 PTP na "svoje" gPTP, tj. 802.1AS není podmnožinou IEEE1588-2008. Dále má svůj vlastní režim provozu switchů (hybrid BC/TC), má svůj vlastní BMCA.

Tu a tam se v ceníku některého z menšinových výrobců ethernetových switchů objeví model s údajnou podporou TSN, ale dostupnost je neznámá a manuál buď není nebo je "tajuplný".

Nedávno jsem postřehl nuanci v množině 802.xyz přípodotků, která naznačuje generační předěl v plemenném názvosloví TSN. (Těžko mluvit o generačním předělu ohledně dosud prakticky prázdné množiny fyzického hardwaru.)

A právě tato nuance mě ponoukla k tomuto spisku.
Následující dvě kapitoly shrnují TSN "před a poté".
 

Původní neinvazivní TSN

TSN je často vysvětlováno směrem od průmyslové komunikace, řekněme komunikace mezi PLC někde ve výrobním provozu. V tomto prostředí se tradičně používají "průmyslové sběrnice" mnoha druhů (fieldbus v širším slova smyslu) - někdy proprietární od fyzické vrstvy výš, často založené na komoditní fyzické vrstvě: RS485, CAN a potomstvo, v modernější době často Ethernet.

Jedním z typických koncepčních schémat komunikace je "distribuované zrcadlení process image", kde si jednotlivé uzly na sběrnici v rychlém sledu předávají "žezlo" (token passing) a každý odvysílá svůj vlastní segment sdílené "tabulky proměnných". Může se tak dít bez jednoznačného mastera, nebo jeden uzel komunikaci nějakým způsobem moderuje, případně z pozice mastera cyklicky oslovuje jednotlivé slavy (což je způsob relativně nejméně efektivní). Cyklus může běžet nebržděně a z hlediska lidského reálného času asynchronně, nebo mohou cykly startovat v pevném taktu.

Právě cyklická komunikace v deterministickém taktu bývá dávána za příklad praktického uspořádání low-latency komunikace v real-time nasazení. Laskavý čtenář přimhouří oko nad okolností, že přenosové zpoždění jako takové s přidělováním vysílacího času vlastně nesouvisí.
Pro potřeby tohoto vysvětlení budiž dílčí pointou, že "cyklická data" jsou v tutorialech ohledně TSN zmiňována ve smyslu "spěchající provoz", s požadavky na nízkou latenci. V protikladu k "acyklickým datům", která protečou samotížně, až na ně dojde řada.

První vlna TSN řeší upřednostnění časově kritických dat pomocí vcelku standardních schopností běžných čipsetů ethernetových switchů: na bázi řazení egressu do několika fyzických front s odstupňovanou prioritou.
Pravda je, že už algoritmy řazení do front v této první vlně budí určité podezření, že možná budou vyžadovat v hardwaru určité úsilí navíc, nad rámec běžných schopností, které stačí na 802.1p, IP DSCP apod.

Konkrétně už první vlna TSN zavádí tato 802 čísílka a k nim vysvětlivky:

  • 802.1Qci Ingress Policing
  • 802.1Qav Credit-based shaper
  • 802.1Qbv Time Aware Shaper
  • 802.1AS (PTP - ten už známe, samostatná pohádka)

 

802.1AS = svého druhu PTP, vyžaduje přinejmenším HW značkování + související podporu ve firmwaru (lepší je komplet HW implementace). Řekněme, že PTP už není úplný exot.

Popravdě, už ty divotvorné frontovací strategie jsou na pováženou.
Ale pořád tu nikdo nenaznačuje, že by se snad mělo kvůli latencím prioritního provozu přerušovat odesílání paketu, který už je vysílán, už ho kus odlétl do fyzického média. To by totiž znamenalo udělat pauzu a paket prakticky zahodit, poté co by fyzická vrstva příjemce konstatovala vadné CRC.

...nebo snad ne ?
 

Novinka: frame preemption / interspersing

No a přesně tuto novinku přinášejí poslední dva přírůstky do TSN 802.xyz zoo:

  • 802.1Qbu Frame Preemption
  • 802.3br Interspersed Express Traffic

 

Tedy: dlouhý neprioritní paket, loudající se z prvního místa ve frontě směrem ven, lze podle nových norem v rámci druhé vrstvy přerušit = rozdělit na fragmenty. Následně odvysílat spěchající provoz, a pak navázat dalším fragmentem přerušeného neprioritního paketu. Toto proložení proběhne bez ztráty pomalého paketu. Zdá se, že "peklo zamrzlo".

Pomalý paket lze přerušit = rozfragmentovat i navícekrát. Minimální velikost payloadu uvnitř fragmentu je 60 Bajtů. Místo přerušení podléhá nějakému pravidlu pro zarovnání (snad po 8 oktetech, alespoň v prvních draftech z roku 2014 se o tom hovořilo ve smyslu TBD) a sama podpora Frame Preemption přidává ke každému rámci pár bajtů navíc. Tzn. efektivita ve smyslu pásma má své meze a minimální latence pro prioritní provoz taky neklesne na úplnou nulu. Ale lepší 60B než 1500B nebo nedejbože jumbo.

Formát letmo produkovaných fragmentů pomalého provozu je vymyšlen tak, aby jednotlivý fragment měl platné CRC. Proto nedochází k zahazování přerušených pomalých paketů, a proto také není potřeba úprava fyzické vrstvy: lze použít standardní PHY transceivery a standardní SERDES nebo MII transport mezi MAC/PHY. Úpravu křemíku ale samozřejmě vyžaduje MAC vrstva. (Kdo ví něco o Ethercatu, zažívá patrně v tuto chvíli lehké deja vu.)

Norma také pamatuje na kompatibilitu se staršími ethernetovými porty / uzly, které Frame Preemption nepodporují. K zapnutí této vlastnosti v MAC vrstvě se přikročí teprve poté, co se oba partneři na fyzickém spoji dohodnou, že oba tuto vlastnost podporují.
K této dohodě NEdochází v rámci IEEE 802.3 clauses 28 & 40 - TSN definuje k tomuto účelu speciální rámce zvané VERIFY a RESPOND. V podstatě dotaz-odpověď, transakce je provedena pro každý směr nezávisle (každý z obou partnerů se svým jménem zeptá a očekává odpověď).
 

Závěr

Pokud stavíte síť a aplikaci s využitím TSN, dávejte si pozor, co kupujete za komponenty. Je třeba samozřejmě vycházet z reálných potřeb aplikace. Pokud míříte na frame preemption / interspersing, buďte si vědomi, že se jedná v letech 2022-2023 stále o novinku, která se teprve začíná objevovat v čipsetech switchů. Tzn. v tom případě nepovažujte za bernou minci přítomnost buzzwordu "TSN" v katalogovém listu, ale hledejte 802.3br a 802.1Qbu.

Například "klientský" čip Intel i225, který údajně podporuje vše potřebné, prošel během několika let asi třemi revizemi křemíku, než mu konečně výrobce vychytal dětské nemoci.

Obecně asi nebude problém, pokud systém využívající TSN kupujete jako ucelenou proprietární stavebnici od konkrétního výrobce. Pozor ale na hardware "z volného trhu" = pokud se snažíte integrovat systém z komponent od různých výrobců. Zde platí "důvěřuj, ale prověřuj". Papír katalogového listu unese hodně (a co teprve PDFko) - reálně je třeba, uvažované konfigurace si otestovat na vzorcích hardwaru.

Což mi připomíná... ono to asi nepůjde snadno pasivně odposlechnout (např. skrz optický splitter).
Síťovkou bez podpory samozřejmě nikoli.
Pokud se použije síťovka s podporou (např. i225, viz níže) tak nejprve není jisté, že do pasivního odposlechu zafunguje dvoustranný handshake VERIFY+RESPOND.
A pokud odposlechová síťovka pochopí a fragmenty přijme, tak zas pokud všechno klapne, dostane odposlouchávající user space již rekombinované kompletní rámce = nemá šanci, vidět jednotlivé fragmenty. Pokud bude fragmentace někde skřípat (sem tam nějaký fragment bude chybět nebo bude mít vadné CRC) tak se to projeví ztrátou celých paketů v odposlechnutém PCAPu. Určitou informaci by mohlo poskytnout porovnání přenosových latencí se zapnutou preempcí vs. bez preempce - na to stačí odposlech se synchronní časovou základnou a HW značkováním v odposlechu.
Úplný detailní odposlech fragmentů leda specializovaným analyzátorem (nebo dobrým osciloskopem).

Inu nemůže být každý den posvícení.
 

Odkazy

TSN technology: basics of Ethernet Frame Preemption, part 1 and part 2

Ludwig Winkel, Siemens AG:
souborIEEE 802.3br
Interspersing express traffic (IET)
Task Force (TF)
Baseline 2014-05-14

souborI225/I226 Time-Sensitive Networking Features Brief

 

Eshop
Youtube
Magazín
Kalalog
FCC průmyslové systémy


Již více než 25 let na českém trhu

FCC průmyslové systémy je technicko – obchodní společností, zastupující významné výrobce v oblasti průmyslové automatizace a telekomunikační techniky. V oblasti průmyslové automatizace zahrnuje naše nabídka spektrum sahající od senzorových systémů přes průmyslové sběrnice a průmyslové komunikace po průmyslové výpočetní, řídicí a dispečerské systémy na bázi specializovaných PC. Naší významnou specializací jsou systémy pro strojové vidění využívané v oblasti výrobní automatizace a kontroly kvality. Spolupracujeme s nejvýznamnějšími světovými dodavateli průmyslové výpočetní techniky a komunikací z Evropy a Asie a disponujeme i vlastním vývojovým a konstrukčním zázemím včetně vývoje softwaru.

up