Použití sítě Ethernet pro řízení v reálném čase – NDDS

Použití sítě Ethernet pro řízení v reálném čase – NDDS

Článek je věnován základním vlastnostem sítě Ethernet z hlediska jejího použití k řízení v reálném čase v průmyslu. Seznamuje s komunikačním modelem publish-subscribe a upozorňuje na zkušenost s produktem NDDS, který jej využívá jako základní stavební prvek umožňující prostřednictvím sítě Ethernet řídit v reálném čase.

1. Úvod

Síť Ethernet je dosud ve značné míře vnímána jako nespolehlivé přenosové prostředí nevhodné pro průmyslové aplikace vyžadující řízení v reálném čase. V současné době se však tento názor začíná postupně měnit. Vznikají různé metody umožňující obejít základní vlastnost sítě Ethernet, kterou je nedeterminističnost – žádnému z uzlů v síti Ethernet nelze zaručit, že se v konečném čase dostane k vysílání (pokud o něj projeví zájem). Uvedenou problematikou se zabývá mnoho firem investujících do vývoje souvisejících technických a programových prostředků značné finanční částky. Cílem těchto projektů je zejména nahradit dražší specializované protokoly a potřebné karty (např. Profibus, CAN apod.) levnými síťovými kartami, které jsou běžně dostupné, a ty pak používat pro distribuované řízení.

V článku jsou zmíněny základní vlastnosti sítě Ethernet z hlediska reálného času obecně. Dále je určena spolehlivost komunikace a uvedeny číselné příklady. Vhodný pro oblast řízení v reálném čase se jeví komunikační model publish-subscribe Jako komerční aplikace založená na uvedeném modelu je v závěru článku stručně zmíněn produkt NDDS firmy RTI.

2. Základní vlastnosti sítě Ethernet

Síť Ethernet používá pro přístup k vlastnímu přenosovému médiu metodu CSMA/CD. Tato metoda je založena na odposlouchávání signálů ze sítě. Daný uzel při každém pokusu o vysílání nejprve testuje, zda již nevysílá některý jiný z uzlů v síti (popř. segmentu sítě). V případě, že některý jiný vysílá, čeká se na uvolnění sběrnice. Tento stav je naznačen na obr. 1. Složitější stav nastane, snaží-li se současně vysílat dva uzly (obr. 2). Oba budou čekat na uvolnění sběrnice a pak následně začnou současně vysílat. Jelikož oba uzly při vysílání zároveň odposlouchávají signály ze sběrnice, zjistí kolizi. Kolize se částečně vyřeší tím, že každý uzel vygeneruje „náhodnou“ dobu, po jejímž uplynutí teprve bude opět usilovat o získání přístupu ke sběrnici. Po každém neúspěšném pokusu se maximální hodnota intervalu, ze kterého se náhodně vybírá, zdvojnásobuje (měří se v jednotkách zvaných slot delay). Na počátku je maximální hodnota rovna 0 (okamžité odeslání), při první kolizi 2, následně 4 atd. U sítě Ethernet s přenosovou rychlostí 10 Mb/s odpovídá jednotce slot delay zpoždění 51,2 µs. Algoritmus zdvojnásobení však není nekonečný. Standardně se zastavuje po desátém neúspěchu, čemuž odpovídá 1 024násobek slot delay. Při velkém zatížení sítě však dochází ke značnému počtu kolizí a tím ke zpožďování odesílání zpráv – tzv. latenci. Latence, která je závislá na zatížení sběrnice, je v systémech reálného času jedním z jejich nejdůležitějších parametrů.

3. Pravděpodobnost chyby při přenosu

Jak už bylo řečeno, nelze v síti Ethernet jednoznačně zaručit (tj. s pravděpodobností rovnající se jedné), že zpráva bude doručena! Tato skutečnost vyplývá ze samotného principu činnosti této sítě. Přijmeme-li však určitá omezení, lze stanovit pravděpodobnost, s jakou bude zpráva doručena. Za tím účelem vezmeme v úvahu tato omezení:

• pracujeme v uzavřené části sítě (subnet),
• posíláme mnoho malých paketů stejné délky (což je typické pro řízení v reálném čase),
• zatížení sítě je relativně malé nebo střední (ne velké zatížení).

Je-li uvažována síť s pouze jedním uzlem, nemůže dojít ke kolizi (uzel sám se sebou nemůže kolidovat).

Při dvou uzlech rovněž nemůže nastat kolize (neuvažujeme případ, že oba začnou vysílat v jeden okamžik). Zajímavá je již síť se třemi uzly. Jestliže dva z nich čekají na vysílání, je pravděpodobnost vzniku kolize rovna jedné. V kroku následujícím po kolizi se vygeneruje náhodné číslo z množiny {0, 1, 2} (viz kap. 2). Pravděpodobnost vzniku kolize je zde 1/3. Při druhé kolizi se vybírá náhodné číslo z množiny {0, 1, 2, 3, 4}, pravděpodobnost vzniku kolize je 1/5 atd. Z principu této přístupové metody je možné odvodit vztah pro pravděpodobnost vzniku chyby typu nedoručení zprávy do N pokusů [1]

Jak klesá pravděpodobnost nedoručení zprávy s počtem opakování, ukazuje tab. 1.

Tab. 1. Pravděpodobnost nedoručení zprávy podle počtu opakování

Je-li zajímavá pravděpodobnost, s jakou nenastane chyba, lze ji vypočítat jako (1 – P_err). Pravděpodobnost, že se nevyskytne chyba po M přenesených paketech, je rovna

Vyřešením rovnice (1) pro M vznikne vztah

4. Spolehlivost přenosového kanálu

Je-li známa přenosová rychlost a velikost zpráv a je uvedeno maximální zpoždění při přenosu (latence), je podle předcházejících vztahů možné vypočítat, po jakou dobu nenastane chyba v přenosu. Bude-li např. v síti Ethernet s přenosovou rychlostí 100 Mb/s posíláno každou sekundu 1 000 zpráv o konstantní délce 128 bitů, nebudou mít zprávy s pravděpodobností 0,99 zpoždění větší než 1 ms po dobu 1 140 roků. Při tvrdších požadavcích na zpoždění nebo naopak při méně výkonné síti Ethernet se bude spolehlivost přenosového kanálu zmenšovat (tj. bude se zkracovat doba, po kterou je s danou pravděpodobností jisté, že zpráva bude doručena s předepsaným zpožděním). Pro přehlednost je v tab.2 uvedeno několik dalších příkladů (samozřejmě, že uvedené hodnoty spolehlivosti platí jen při splnění předpokladů uvedených v kap. 3).

Tab. 2. Latenční jistota: po jakou dobu nebude s pravděpodobností 0,99 a danými parametry zpráva zpožděna o více než Tmax

5. Komunikační model pro řízení v reálném čase

Jak efektivně využít komunikační kanál? To je otázka, kterou se teď budeme zabývat. Právě volba špatného komunikačního modelu může způsobit, že značná část kapacity komunikačního kanálu bude neefektivně využívána k zasílání redundantních dat. Tři dále uvažované základní komunikační modely jsou znázorněny na obr. 3.

Spojení mezi dvěma body (bod-bod, point-to-point) představuje nejjednodušší a tradiční druh komunikace. Klasickým zástupcem tohoto druhu spojení je telefonování. Spojení lze navázat, pouze je-li známo číslo volané stanice. Tento model je využíván také TCP. Má-li síť velký počet uzlů, je komunikace typu bod-bod těžkopádná, neboť data jsou vyměňována v jeden okamžik pouze mezi dvěmi stanicemi (one-to-one communication).

Komunikace typu klient-server, zavedená v 80. letech, je založena na jednom centrálním serveru, přes který je uskutečňována komunikace s jednotlivými klienty. Data jsou produkována mnoha uzly a zároveň mnoha uzly přijímána. Model klient-server je relativně málo výkonný, neboť vyžaduje nadbytečné kroky, jako např. nevyhnutelný průchod dat přes centrální server, který do komunikace přidává nadbytečné zpoždění. Velmi citlivým místem je samotný server, při jehož selhání se celá komunikace zastaví. Pro zvýšení spolehlivosti lze v systému použít několik centrálních serverů, což však vede k potížím se synchronizací a údržbou dat.

Model publish-subscribe je navržen pro distribuci dat způsobem založeným na tom, že jeden producent (publisher) posílá data současně většímu počtu konzumentů (subscribers

Pro komunikaci po síti Ethernet v reálném čase je komunikační model publish-subscribe ideální, neboť významně přispívá ke zmenšení zatížení sítě.

Pro úspěch a kvalitní komunikaci však nestačí jen dobrý komunikační model. Je třeba si uvědomit, že propustnost sítě závisí také na způsobu zacházení s daty při jejich vkládání na sběrnici. Data přitom mohou být typu signál, příkaz, stav, událost, žádost.

Například teploměr odesílá údaje o teplotě. V případě, že se mu nepodaří odeslat data napoprvé a do komunikačního zásobníku mezitím přijde nový údaj o teplotě, již není nutné „starou“ hodnotu teploty odesílat. Naopak jestliže by se toto stalo s příkazem, došlo by k porušení struktury toku dat do daného zařízení s výsledkem neprovedení nebo vykonání jiného než žádoucího (popř. i kriticky důležitého) příkazu.

Podobně data typu událost jsou zprávy, které jsou generovány asynchronními událostmi (v systému nebo jeho okolí). Mají většinou velkou prioritu a je nutné je včas doručit. Příjem některých druhů zpráv přitom nemusí být potvrzován a stačí pouze potvrdit jejich odeslání do sítě. Efektivní komunikace pro použití v systémech reálného času musí proto podporovat všechny typy zpráv a musí s nimi umět správně zacházet.

6. Model real-time publish-subscribe

Model real-time publish-subscribe (RTPS) rozšiřuje model publish-subscribe o časové parametry a tak umožňuje návrháři řídit tok dat v síti podle jejich typů (viz kap. 5). Producent a konzument se v tomto ohledu svými parametry liší.

Každý producent je charakterizován prostřednictvím čtyř parametrů, kterými jsou:

• záměr (topic) – identifikační známka dat,
• typ (type) – datový formát,
• vliv (strengh) – relativní váha dat oproti datům se stejným záměrem,
• doba platnosti (persistence) – jak často jsou posílána data.

Když dva producenti posílají data se stejným záměrem, jsou akceptována data pouze od producenta s větším vlivem. Tento mechanismus umožňuje snadno vytvářet záložní systémy, neboť selže-li primární systém, je automaticky nahrazen systémem sekundárním (s menší vahou dat, než je váha dat primárního systému), ale oba systémy přitom mohou na síti neustále koexistovat.

Podobně jako producenti je čtyřmi parametry charakterizován i každý konzument. Jsou to:

• záměr (topic) – identifikační známka dat,
• typ (typ) – datový typ,
• minimální separace (minimum separation) – doba, po kterou nebudou akceptována žádná nová data,
• uzávěrka (deadline) – maximální doba čekání na nová data.

Minimální separace chrání pomalejší konzumenty před producenty, kteří vysílají data příliš rychle, a ta by mohla zaplnit komunikační zásobník. Parametr deadline umožňuje nastavit signalizaci stavu, při kterém k danému konzumentovi nepřicházejí včas nová data (upozorňuje např. na chybu producenta).

7. NDDS

7.1 Popis produktu
Pod označením NDDS se skrývá o softwarový produkt firmy RTI, který je určen pro snadnou tvorbu řídicích aplikací reálného času, jež budou komunikovat po síti Ethernet. Zajišťuje rychlou deterministickou výměnu dat přes komunikační zásobník IP. Na rozdíl od běžných internetových aplikací nevyužívá pro komunikaci TCP, ale pouze základní komunikační protokol UDP, jak je patrné z obr. 4. Hlavními přednostmi tohoto produktu jsou:

• komunikace typu publish-subscribe nebo klient-server,
• anonymní komunikace (záměr spojení),
• výběr stupně spolehlivosti zasílání zpráv,
• podpora platforem Windows, Linux, VxWorks a dalších,
• generátor automatického kódu,
• uživatelská definice datových typů.

Vlastní komunikace s produktem je z pohledu programátora velmi jednoduchá. Na straně producenta se prohlásí záměr, tj. jaké údaje se budou publikovat (např. teplota) a určí se jejich formát a stupeň spolehlivosti doručení. Konzument, který chce data odebírat, musí registrovat příslušné téma (teplota) a NDDS se postará o správné doručení zprávy od producenta k protějším stranám konzumentů. Počet konzumentů i producentů daného tématu může být větší než jedna (viz kap. 6). Každého asi napadne otázka, jak se pozná, komu se má doručit zpráva, jestliže je komunikace anonymní? Vedle NDDS běží tzv. démon, který si udržuje databázi všech aktivních spojení s názvy jednotlivých témat. V této databázi je uchována informace, na jaké IP adrese je právě dané téma, kterému se mají doručit data.

7. 2 Zkušenosti
Během asi tříměsíčního testování verze NDDS 2.3h se ukázalo jako překvapivě jednoduché vytvořit první aplikaci. Přispěla k tomu i velmi kvalitní dokumentace a technická podpora produktu na internetu.

V počátcích existoval záměr použít NDDS i na malém zařízení s mikroprocesorem z rodiny ‘51 a řadičem sítě Ethernet. Po zjištění nedostatečnosti výpočetní a paměťové kapacity ‘51, neboť pro plnohodnotnou práci NDDS je vyžadován operační systém reálného času, který podporuje správu procesu a komunikaci mezi procesy, se původní záměr ukázal jako nerealizovatelný.

Testováním bylo také zjištěno, že NDDS 2.3h korektně neodhlašuje jednotlivé konzumenty z komunikačního spojení. Tento nedostatek by měl být v brzké době opraven ve verzi 3.0.

8. Závěr

V článku jsou uvedeny základní informace týkající se problematiky řízení v reálném čase při komunikaci prostřednictvím sítě Ethernet a je předložen určitý podrobnější pohled na tuto problematiku. Právě postupně vzrůstající zájem trhu o využití sítě Ethernet pro řízení předurčuje tento směr jako velmi perspektivní a posouvá ho do popředí. Tento trend lze vidět např. na sběrnici Profibus, jejíž některé části jsou nahrazovány právě spojením po síti Ethernet.

Jelikož jde o dosti rozsáhlé téma, lze zájemcům doporučit [2], kde je poměrně dobře zpracována celá problematika RTPS.