Projektování distribuovaných řídicích systémů podle časové odezvy

Projektování distribuovaných řídicích systémů podle časové odezvy

Radim Novotný

Jakýkoliv systém pro řízení technologického procesu, a tedy i současný distribuovaný, musí být co do doby svých odezev nezbytně navržen tak, aby bylo zajištěno řízení daného technologického procesu v reálném čase. Článek informuje o originální metodě stanovování doby odezvy průmyslových komunikačních sítí založených na přístupové metodě token ring. Použitelnost metody je autorem s úspěchem ověřena technickými prostředky firmy Siemens na sítích Profibus v laboratoři i v reálných podmínkách řízení technologických procesů.

1. Úvod

Rozvoj výpočetní techniky vnesl do oblasti řízení technologických procesů nový pohled na koncepci řídicích systémů. Původní složité a těžkopádné řídicí počítače, které centrálně plnily všechny funkce při řízení technologického procesu, byly nahrazeny jednoduššími systémy vykonávajícími jednotlivé funkce, popř. jejich skupiny. Tento přechod od koncepce centralizovaného řízení k řízení tzv. distribuovanému znamenal zásadní obrat v řešení automatizačních úloh. Mimo jiné v tom, že mezi jednotlivými komponentami distribuovaného řídicího systému je třeba zajistit výměnu informací. K tomu je nutná komunikační síť. Ale distribuovaný přístup současně přinesl i nové, dříve neznámé problémy.

Jednak vyvstala potřeba standardizovat komunikační sítě: tento proces, víceméně trvalý, zde není předmětem zájmu. Důležité pouze je, že dále diskutované protokoly a sítě Profibus bezesporu patří a i v dohledné budoucnosti budou patřit k nejrozšířenějším.

Druhý problém, neméně významný, představuje doba potřebná k přenosu dat mezi jednotlivými částmi distribuovaného řídicího systému: programovatelnými automaty (Programmable Logic Controller – PLC), vizualizačními, monitorovacími a ovládacími stanicemi (Supervisory Control And Data Acquisition/Human Machine Interface – SCADA/HMI), speciálními výpočetními prostředky, systémy decentralizovaných vstupů a výstupů (v/v), bránami mezi jednotlivými komunikačními sítěmi atd. navzájem propojenými komunikační sítí (komunikačními sítěmi), po níž (nichž) si mezi sebou předávají data. Pro správné fungování řídicího systému jako celku je nutné, aby doby odezvy v jednotlivých komunikačních kanálech byly krátké (aby nemohly být příčinou nesprávného fungování řídicího systému).

Typickým příkladem je doba odezvy při komunikaci mezi PLC a systémem decentralizovaných v/v, která musí dostatečně krátká, aby bylo možné technologii správným způsobem řídit. Jiným příkladem je častý požadavek garantovat dobu odezvy řídicího (vizualizačního) systému na povel (např. spuštění pohonu) zadaný v zobrazení technologie na obrazovce monitoru počítače.

Naposled uvedený příklad je typickou úlohou přicházející z praxe. Operátor vloží do vizualizačního systému povel a čeká na zpětné potvrzení o provedení příkazu řídicím systémem. V běžné praxi je možné čekat maximálně tři až čtyři sekundy. Poté začíná mít operátor podezření na možnou poruchu vzniklou v technologii anebo v řídicím systému, popř. chybu v jeho programovém vybavení. Většinou se v takové situaci pokusí operaci opakovat, což může mít i fatální následky.

U rozsáhlých řízených technologií může přitom mezi systémem SCADA/HMI a vstupy a výstupy do technologie existovat několik komunikačních sítí podle různých standardů, kterými jsou propojeny např. PLC různých typů, systémy SCADA/HMI vytvořené na různých platformách a systémy decentralizovaných v/v. Každá ze zúčastněných částí přispívá svým dílem k výslednému zpoždění (době) odezvy.

Shrnuto, je tedy typickou úlohou současné inženýrské praxe v oboru řízení technologických procesů návrh komplexního řídicího systému spočívající ve volbě vhodných standardních komponent v podobě komunikačních standardů a prostředků, PLC, systémů SCADA/HMI a systémů decentralizovaných v/v a jejich uspořádání do takové architektury, která splní veškeré požadavky na funkce i doby odezvy řídicího systému při minimálních nákladech na jeho realizaci, provoz a údržbu [1].

Pokud je známo, neexistuje v praxi žádný nástroj, který by umožnil uvedenou projektovou úlohu rutinně řešit. Ví se však, že pokud ve fázi návrhu dojde k zásadním koncepčním chybám či opomenutím, tyto nedostatky se většinou projeví až v konečné fázi oživování řídicího systému. Tedy v době, kdy je již – z finančních i časových důvodů – velmi nesnadné architekturu řídicího systému jakkoliv podstatněji měnit.

Jako nástroj umožňující včas, tj. v dostatečně raném stadiu projektu, ocenit architekturu distribuovaného řídicího systému z hlediska doby odezvy byla ve [4] pro dále definovanou třídu řídicích systémů navržena a ověřena metoda jejího stanovení, která je stručně popsána v tomto článku.

2. Současný stav v oblasti návrhu komunikačních sítí

Při pohledu do historie je patrné, že v oblasti distribuovaných řídicích systémů se vztah ke komunikačním standardům vyvíjel poněkud jinak než v oblasti klasické výpočetní techniky. Základním rozdílem je skutečnost, že v automatizační technice nebyly, především vzhledem k menším požadavkům na výpočetní výkon a naopak tvrdším požadavkům na rozměry, spolehlivost atd., používány tak výkonné výpočetní systémy jako ve světě počítačů. Typicky bylo na průmyslové komunikační sběrnici požadováno, aby měla deterministický přístup k přenosovému médiu a aby uživateli umožnila jednoduše zajistit komunikaci mezi řídicími stanicemi (většinou PLC), popř. připojit vizualizační systém nebo jednoduchý aplikační program v PC způsobem tzv. na míru. Objevovala se spíše řešení propojující komponenty řídicích systémů prostřednictvím tzv. uzavřených (proprietárních) standardů (DH+ firmy Allen-Bradley, Sinec L1 firmy Siemens atd.). Takové distribuované řídicí systémy z 80. a počátku 90. let minulého století byly většinou sestaveny z jednoho vizualizačního systému a jednoho až čtyř PLC. Požadavky na přenos dat bývaly již ze strany objednatele minimalizovány právě s ohledem na relativně malý výkon komunikačních sítí.

S vývojem v oblasti PC a softwaru pro vizualizaci a správu dat však přišly požadavky na archivaci výrobních dat, jejich bilancování a přenosy dat do nadřazených úrovní řízení, které po jedné komunikační síti předávají data do sítě operátorských a dispečerských terminálů a na druhé straně komunikují v jiné síti a v jiném komunikačním standardu s nadřazeným prostředím podniku. Objemy přenášených dat zásadně vzrostly.

Požadavky na přenosy podstatně větších objemů dat přinesly problémy s prodlužující se dobou odezvy, zatím ve většině případů řešené až při realizaci daného řídicího systému. Někdy se však původně požadovaných dob odezvy vůbec nepodařilo dosáhnout. Důvody byly technického charakteru, velmi často ale v kombinaci s finančními anebo časovými tlaky.

2.2 Současné metody návrhu
Jaké jsou v současné době teoretické prostředky umožňující rychle a do určité míry správně navrhnout architekturu řídicího systému při použití standardních komponent průmyslové automatizace, tj. průmyslových komunikačních sítí, programovatelných logických automatů a vizualizačních systémů?

Odpověď na tuto otázku není jednoduchá. Výrobci automatizační techniky většinou charakterizují svoje komunikační sítě jejich určením – jako síť pro „střední“, „vyšší“ či „nižší“ úroveň řízení. Taková charakteristika však většinou nic neříká o výsledné době odezvy. Katalogy a uživatelské příručky o době odezvy nehovoří vůbec: předpokládá se, že se systém bude chovat „správně“.

Navrhnout průmyslovou komunikační síť a předem ověřit jejich chování je např. možné při použití modelu komunikační sítě sestaveného v univerzálním simulačním prostředí, popř. vlastními silami. Autor tento postup v praxi vyzkoušel se školní verzí produktu Witness. Výsledky byly použitelné, avšak tento přístup nesplňuje základní požadavek praxe, kterým je co nejsnadnější a pohotové použití.

Samozřejmě je známo poměrně mnoho metod a matematických modelů popisujících časové chování komunikační sítě [4]. Bohužel jde o modely vyvinuté téměř výhradně pro počítačové sítě a pozornost věnovaná v tomto ohledu průmyslovým komunikačním sítím je minimální, až nulová.

Existují také, alespoň pro některé sítě (např. Ethernet), různé typy hotových simulačních prostředků od freewarových verzí až po profesionální návrhová prostředí. Tyto softwarové produkty jsou opět většinou určeny pro návrh rozsáhlých komunikačních sítí v prostředí „ryzí“ výpočetní techniky prostřednictvím metody Petriho sítí. Jedná se o metodu sice principiálně jednoduchou, avšak v etapě následné analýzy vyžadující určité specifické znalosti problematiky. Z pohledu běžného automatizačního inženýra se tato metoda tedy také jeví jako příliš složitá.

Z naznačených důvodů se v běžné automatizační praxi tudíž většinou vychází pouze z empirických závěrů, ze zkušeností projektantů a z podobnosti s již realizovanými řešeními. Není známo, že by v daném ohledu existovala ucelená metodika návrhu průmyslové komunikační sítě. Nejvhodnější pro běžnou technickou praxi přitom je mít k dispozici vzorec, popř. vzorce, pro přímý výpočet hodnoty jednoho specifického parametru, kterým je zpoždění zprávy v síti. Protože většinou se pracuje s hrubým odhadem veličin, je v tomto případě naprosto dostačující přesnost výpočtu okolo 30 %.

2.3 Vymezení úlohy
Cílem automatizačního projektu je realizovat řídicí systém pro danou úlohu (technologii). Výsek současného typického řídicího systému je ukázán na obr. 1. Jde o řízení v nadřazené úrovni řešící problém plánování výroby s vazbou na podnikovou úroveň řízení prostřednictvím MES (Manufacturing Execution System). Je patrné, že jednotlivé aplikace průmyslových komunikačních sítí jsou značně rozsáhlé a že již ve fázi návrhu řídicího systému je nutné zaručit některé parametry, především požadovanou dobu odezvy. Jestliže je předpoklad, že problémy kompatibility jednotlivých komponent i popř. funkčních schopností celého zařízení jsou vyřešeny, přičemž tento předpoklad lze v současnosti pokládat za oprávněný, stává se klíčovou právě otázka časových odezev. Jejich přílišná délka může diskvalifikovat celý systém řízení [1].

Pozornost je dále věnována komunikačnímu standardu Profibus (-DP, -FMS), na českém trhu snad vůbec nejrozšířenějšímu.

Jako reprezentativní je pro účely analýzy časové odezvy zvolen řídicí systém, který je tvořený:

• komunikační sítí,
• určitým počtem spolu komunikujících PLC,
• vizualizačním systémem.

Cílem je najít pro zvolený komunikační standard vztah pro výpočet doby odezvy komunikačního kanálu ve dvou základních případech:

• při komunikaci mezi PLC,
• pro operaci zápisu a přečtení dat z PLC (jako typickou úlohu vizualizačního systému)

a dále ze známých dílčích dob odezvy jeho jednotlivých prvků stanovit výslednou dobu odezvy řídicího systému.

4. Způsob řešení

Jak již bylo uvedeno, lze časové chování komunikačního kanálu vyšetřovat na modelu sestaveném s použitím simulačních jazyků. Ačkoliv relativně jednoduchá, pro použití v praxi se tato metoda příliš nehodí. Je nutné vlastnit simulační prostředek a ovládat simulační prostředí.

Zvolená jiná cesta vede přes matematický model komunikačního kanálu založený na Markovových řetězcích k nalezení vzorce, který umožní dostatečně přesně stanovit časovou odezvu budoucího reálného komunikačního kanálu [4]. Jako zdroje dat pro model komunikační sítě jsou modelovány PLC a vizualizační systémy

Použitý přístup umožňuje najít pro síť typu token ring matematický model a následně analyticky vyjádřit hlavní ukazatele její výkonnosti. Vypočítané hodnoty ukazatelů je potom možné porovnat s výsledky měření na reálném modelovém řídicím systému, výpočetní vztahy podle výsledků porovnání upravit a upravené použít v reálných aplikacích při řízení technologií.

Použitý postup dovoluje v důsledku sestavit obecně použitelnou metodiku návrhu komunikační sítě řídicího systému s ohledem na dobu odezvy.

5. Matematický model komunikačního kanálu sítě typu token ring

Model je pohledem na komunikační kanál ze strany libovolné aktivní stanice. Je pojat jako jednorozměrný markovský systém (symbol M/M/1) s blokováním obsluhy – vysílání (s cyklickou obsluhou).

Situace je znázorněna na obr. 2. Data se přenášejí v dávkách. Každá stanice má jednu frontu zpráv určených k vysílání. Každá z N aktivních stanic vysílá po dobu T_s. Po dobu T_r je vysílání blokováno. Symbol SP značí spínač, který ukazuje, že v daném okamžiku může přijímat data současně několik stanic. To však z hlediska tvorby modelu vysílacích stanic není podstatné.

Pro nalezení matematického modelu je třeba znát:

• počet stanic M a počet aktivních stanic N,
• dobu oběhu pověření k vysílání (token) T_RT, z níž je odvozena doba setrvání tokenu,
• délku vysílané zprávy W a přenosovou rychlost B v baudech (baude rate),
• intenzitu I_V vzniku zpráv a intenzitu I_O jejich odesílání z vysílající stanice.

Síť s  uvedenými parametry je možné interpretovat jako stochastický markovský model diskrétní ve stavech a spojitý v čase. Modelu vysílacích stanic z obr. 2 odpovídá stavový diagram na obr. 3. Uzly grafu znamenají markovské stavy. Stavy dvojice <j, i>, kde j = 0, 1, označují pověření k vysílání: je-li j = 0, vysílání není blokováno, při j = 1 blokováno je. Počet stavů je nekonečný. Parametr r je převrácená hodnota doby T_R, kdy stanice nemá pověření k vysílání (token) a vysílání je blokováno, s je převrácená hodnota doby, kdy stanice token má, tj.vysílání je povoleno. Model podle obr. 3 je modelem růstu a zániku, neboť má kladné přechodové stavy pouze do sousedních stavů. Lze ho tedy chápat jako zobrazení množiny vstupních parametrů {s, r, N, T_TR, B, I_V, I_O} do množiny základních výstupních ukazatelů výkonnosti

{T_Q, I_Vmax}, přičemž I_Vmax je maximální intenzita generování zpráv (největší možný počet zpráv generovaných a poslaných za sekundu) a T_Q je střední zpoždění zprávy ve stanici (doba čekání zprávy ve stanici, než je odeslána).

Exponenciální rozložení vzniku zprávy ve stanici je jediné rozložení, které je možné obecně řešit. Pokud je v praxi toto rozložení jiné než exponenciální, dostanou se vždy lepší výsledky. Exponenciální rozložení tedy poskytuje nejhorší možný odhad.

Z uvedeného modelu lze postupem popsaným ve [4] odvodit pro střední zpoždění zprávy v síti typu token ring vztah

a maximální intenzita generování zpráv jako mez stability systému je potom

6. Experimentální ověření modelu sítě

6.1 Podmínky modelového experimentu
Ověření a následná korekce modelu popsaného v kap. 5 byly provedeny prostřednictvím měření na reálných komunikační sítích Profibus (Sinec L2). Použity byly PLC firmy Siemens řad Simatic S5 115 U s komunikačními procesory CP 5431, Simatic S7 300 s komunikačním procesorem CP 343-5 a Simatic S7 400 s komunikačním procesorem CP 443-5. Jako vizualizační systémy pro testování byly použity vizualizační systémy WinCC, InTouch a Genesis na vizualizační stanici s procesorem Pentium III, 850 MHz, s RAM 256 MB a operačním systémem Windows NT 4.0 (rok 2000). Jednotlivé hardwarové komponenty byly připojeny na komunikační síť.

Byly provedeny dva druhy měření:

• na síti s PLC bez vizualizační stanice,
• měření na síti PLC s vizualizační stanicí.

6.2 Modelové měření na síti PLC bez vizualizační stanice
Měření na modelové síti samotných PLC, označených na obr. 4 jako PLC1 až PLCN, probíhalo za těchto podmínek:

• Stanice si předávají zprávu do kruhu, takže první stanice vyšle zprávu; byl měřen čas, kdy se tato zpráva objeví opět v této stanici (celková doba přenosu zprávy).

• Perioda vysílání zprávy byla nastavena na konstantní hodnotu stálou po definovanou dobu.

• Měřilo se při pevné délce zprávy 50, popř. 200 bytů.

• Vedle hlavního toku dat, tj. toku referenčního pro dané výsledky měření, jsou mezi jednotlivými stanicemi ještě další komunikační kanály, jejichž počet je parametrem měření. Je to proto, aby bylo možné stanovit vztah mezi počtem stanic a počtem logických kanálů, je-li jejich počet menší než N(N – 1)/2, kde N je počet stanic, a provést příslušnou korekci.

• Pro měření bylo nutné sestavit jednoduchý program, který vyšle zprávu a měří dobu do jejího příchodu. Není možné použít funkci tzv. sledování proměnných, protože by mohlo dojít ke zkreslení výsledků vlivem proměnné doby komunikace.

• Komunikace byla řešena na základě služeb umožňujících vyslání zprávy s následným krátkým potvrzením.

Při měření byly použity tyto hodnoty:

• přenosová rychlost: 93,75 kb/s, 187,5 kb/s a 500 kb/s,

• počet stanic (PLC): 3, 5 a 10,

• počet logických kanálů: 3, 5, 7, 10, 15, 20, 30 a 45,

• doba cyklu PLC: T_PLC = 50 ms,

• doba přenosu zprávy po sběrnici PLC: zanedbatelná,

• doba přenosu zprávy po komunikační sběrnici T_SB: vypočtena z přenosové rychlosti a délky zprávy.

První skupinou měření byla ověřena platnost modelu na síti s plným počtem logických komunikačních kanálů, kdy byla porovnávána reálná doba čekání zprávy ve stanici s dobou čekání zprávy ve stanici vypočtenou podle modelu při použití výrazu celková doba přenosu zprávy (od vyslání zprávy do jejího příjmu v téže stanici) = počet stanic × (doba přenosu zprávy po komunikační sběrnici + zpoždění zprávy ve stanici (doba čekání T_q) + doba cyklu PLC)

Naměřené výsledky byly porovnány s teoretickými.

Další etapou experimentu byla měření s daným počtem stanic N při různém počtu logických komunikačních kanálů. Měřeno bylo při N = 5 a N = 10, přičemž proměnnou veličinou byl počet logických komunikačních kanálů, postupně 3, 7, 10, 15, 20, 30 a 45 logických kanálů. Měřilo se při každém z uvedených počtů a při všech již zmíněných rychlostech přenosu.

Podle počtu realizovaných spojení byl odvozen tzv. korigovaný počet stanic počet spojení = korigovaný počet stanic × (korigovaný počet stanic – 1)/2

Parametr korigovaný počet stanic je potom použit pro výpočet zpoždění zprávy ve stanici T_q.

Relativní odchylka mezi vypočítaným a naměřeným zpožděním zprávy se u obou typů sítě pohybovala v pásmu ±20 %. Takováto chyba je pro praxi akceptovatelná.

6.3 Modelové měření na síti s PLC s vizualizační stanicí
Při měření na síti PLC s vizualizační stanicí (obr. 5) byla použita shodná metodika jako u sítě samotných PLC, jen s tím rozdílem, že vizualizační stanice zapsala data do první stanice a z poslední stanice je četla.

Důležitou součástí celé úlohy bylo zjistit zpoždění mezi vstupem zadaným na obrazovce a vlastním výstupem telegramu generovaného při zadaném nastavení komunikačního procesoru. Tento parametr je relativně velmi obtížné zjistit, neboť závisí nejen na vlastnostech vizualizačního softwaru, ale i na konfiguraci PC, na kterém je vizualizační software provozován (především na velikosti jeho operační paměti). Toto zpoždění se pohybovalo okolo 200 ms.

Při závěrečném vyhodnocení byly použity poznatky z měření bez vizualizačních stanic, tj. neovlivněné vlastnostmi komponent vizualizačního systému. Pro výpočet ze vzorce byl tudíž určen korigovaný (virtuální) počet stanic a s použitím této hodnoty byly následně vypočítány výsledky.

Uvedená metoda měření vykazovala chybu asi do 30 %. Zásadní problém bohužel představuje měření na vizualizační stanici, kde odhad zpoždění může vykazovat chybu až 50 % (v případech, kdy jsou na stanici v některých časových úsecích spuštěny ještě jiné aplikace).

7. Metodika návrhu distribuovaného řídicího systému podle doby odezvy

7.1 Síť s přístupovou metodou token ring (Profibus)
Doporučený postup návrhu distribuovaného řídicího systému na bázi sítě s přístupovou metodou token ring beroucí v úvahu časovou odezvu budoucího realizovaného díla je takovýto:

• Sestavíme komunikační matici ze všech PLC a vizualizačních stanic, čímž se definují jednotlivé komunikační vazby.

• Stanovíme předpokládanou dobu oběhu tokenu: použijeme doporučenou hodnotu pro předpokládanou rychlost přenosu odvozenou z omezení délky komunikační sběrnice.

• Zvolíme předpokládanou délku telegramu (pro síť Profibus se v praxi vcelku osvědčil aritmetický průměr všech telegramů, většinou se však používá – protože je relativně malá – délka maximálně možná, tj. 240 bytů užitečných dat).

• Vypočteme intenzity příchodu a odchodu tokenu a vysílání zprávy.

• Pokud mezi sebou nekomunikuje každá stanice s každou, tj. počet komunikačních kanálů se nerovná hodnotě výrazu N(N – 1)/2, kde N je počet stanic, volíme tzv. redukovaný počet stanic: najdeme nejbližší větší počet stanic danému počtu komunikačních kanálů.

• Vypočteme hodnoty T_q, představující přibližné střední zpoždění zprávy, tj. dobu, kterou zpráva čeká ve stanici na odeslání.

• Z přenosové rychlosti a délky zprávy vypočítáme zpoždění na sběrnici.

• Experimentálně nebo odhadem podle parametrů PLC z programovacího prostředí zjistíme doby cyklu PLC.

• Je-li připojena vizualizační stanice, experimentálně nebo z literatury zjistíme dobu zpoždění telegramu při průchodu jejím softwarem, firmwarem a hardwarem.

• Celkové zpoždění zjistíme jako součet položek zpoždění na sběrnici, zpoždění telegramu ve stanici, doba cyklu PLC a popř. také vliv vizualizační stanice.

Výslednou hodnotu porovnáme se zadanými požadavky na dobu odezvy systému.

7.2 Komunikační síť typu master/slave
Řídicí stanice (master) se cyklicky dotazuje všech řízených stanic (slave). Pro svou jednoduchost nevyžaduje výpočet doby zpoždění v tomto případě žádný zvláštní teoretický rozbor. Postup je takovýto:

• Výrobce udává např. pro Profibus-DP dobu potřebnou na přenos jednoho bytu při definované přenosové rychlosti.

• Vynásobením počtu stanic, délky přenášených dat a konstanty známé z předchozího odstavce dostaneme dobu zpoždění zprávy ze stanic typu slave.

• Je-li doba zpoždění zprávy kratší než doba cyklu PLC, je situace bez problémů. Při zpoždění delším než perioda PLC je třeba na tuto skutečnost pamatovat při tvorbě uživatelského programu.

8. Použití metody na reálném řídicím systému

Metodika popsaná v předcházejících kapitolách byla ověřena také na reálných řídicích systémech. Se sítí Profibus byla využita na jedné z jejích nejrozsáhlejších aplikací u nás – na řídicím systému čistírny odpadních vod (jeho čistírenské a kalové části).

Pro řídicí systém čistírny odpadních vod byla teoreticky vypočtena doba odezvy 6,2 s. Reálná doba se nyní pohybuje okolo 5 až 7 s.

9. Závěr

Na základě teoretického rozboru jsou podle Markovových řetězců sestaveny matematické modely a související postupy umožňující při návrhu komunikačních sítí typu token ring (reprezentovaných sítí Profibus) odhadnout předem, výpočtem, dobu odezvy budoucího reálného decentralizovaného řídicího systému tvořeného PLC, komunikačními kanály a popř. vizualizačním systémem typu SCADA/HMI. Použitý matematický model z mnoha důvodů představuje jen dosti hrubé přiblížení se k reálného systému. Nicméně je dostatečně mocným nástrojem k tomu, aby bylo možné již v úvodní fázi návrhu řídicího systému, tj. během nabídkového řízení, s minimálními časovými a tím i finančními náklady rozhodnout o konfiguraci komunikační sběrnice s ohledem na požadovanou dobu odezvy (přípustné zpoždění) v distribuovaném řídicím systému typu, který v současné průmyslové automatizaci převládá.

Navržená originální metodika byla s úspěchem ověřena na modelových distribuovaných řídicích systémech i na rozlehlých reálných dílech.

Testování na reálných aplikacích se uskutečilo na systémech PLC firmy Siemens Simatic S5/7 a na systémech HMI/SCADA firem Siemens, Wonderware a Iconics, s laskavým přispěním firmy SIDAT s. r. o., Praha.

Zjištěné rozdíly mezi vypočítanými hodnotami a hodnotami naměřenými na skutečných řídicích systémech jsou 20 až 40 %. Tato chyba je, vzhledem ke značnému rozptylu parametrů, v praxi akceptovatelná, neboť cílem je především rychle a levně získat alespoň přibližný odhad časového chování plánovaného řídicího systému.

V článku jsou velmi stručně popsány pouze principy metody. Veškeré detaily, včetně podrobných výsledků ověřovacích zkoušek apod., lze získat v [4] a tam citované literatuře, popř. a nejlépe u autora.

Ing. Radim Novotný, Ph.D.,
Sidat, spol. s r. o.,
(novotnyr@sidat.cz)