Systém Control Web dokáže provozovat aplikace dvojího druhu — aplikace datově řízené, které umožňují velmi snadno a rychle sestavit vizualizující aplikaci, a aplikace reálného času, které nabízejí komplexní podporu programování řídicích a monitorujících celků pro nejrůznější druhy použití.
Tvorba datově řízené aplikace nevyžaduje téměř žádné předběžné informace o systému, a je možné říci, že "sednete a vizualizujete". Datově řízená aplikace co nejvíce usnadňuje programátorovi tvorbu datových spojení (aplikace se o veškerá data stará ve vlastní režii optimálním způsobem) i tvorbu výkonných objektů aplikace (přístrojů, které jsou v datově řízené aplikaci automaticky aktivovány). Všechna usnadnění míří k jedinému cíli — zjednodušit běžné technologické úlohy. Vzhledem k tomu, že datově řízená aplikace pracuje téměř "sama", odpadají všechny potíže s promýšlením následností, vazeb a algoritmů. Samozřejmě, každé usnadnění musí být nutně vykoupeno zmenšením manévrovacího prostoru, který může autor aplikace využít. Programovatelnost, řízení komunikací a časování, přehled o stavu aplikace, vazba na reálný čas a plná kontrola nad během aplikace jsou v systému Control Web k dispozici pouze v aplikacích reálného času.
K čemu a kdy tedy datově řízenou aplikaci použít?
Datově řízená aplikace (dále jen aplikace) pracuje tempem, které odpovídá množství komunikovaných dat. Celý běh, tedy komunikaci a aktivaci přístrojů, řídí jádro aplikace, které na straně jedné optimalizuje komunikaci a na straně druhé podle nově získaných dat spouští patřičné přístroje. Jádro pracuje cyklicky, přičemž v každém svém průběhu — kroku — změří potřebná data, vyhodnotí výsledky, aktivuje přístroje a zapíše výsledky do technologie.
Pohon aplikace zajišťují změny dat. Systém Control Web rozlišuje tři základní druhy dat: konstanty, které mají po celou dobu aplikace neměnnou hodnotu; proměnné, které je možné libovolně upravovat, slouží tedy k úschově mezivýsledků a vnitřních stavů; a kanály, které v aplikaci představují prodloužení snímačů a řídicích prvků. Každý kanál (obraz) má v reálné technologii svou skutečnou předlohu (akční člen nebo senzor). Souhnně se všechny druhy dat nazývají datové elementy. Podrobně o nich pojednává kapitola Datové elementy a výrazy.
Princip pohonu aplikace je následující — každý z přístrojů používá nějaká vstupní data a výsledky své činnosti zase někam ukládá (zapisuje). Je tedy logické, aby přístroj dostal příležitost provést své akce vždy, když dojde ke změně jeho vstupních dat. Samozřejmě, zápis výsledku činnosti také způsobí změnu dat (změní se hodnota příslušného datového elementu), a systém proto v dalším kroku automaticky aktivuje přístroje, které používají tento změněný výstup jako svůj vstup.
Povšimněte si, že předchozí odstavec nijak nevylučuje, aby přístroj zapisoval výsledky do datového elementu, který je zároveň jeho vstupem. Vzniká jakási zpětná vazba, a kdybychom se nepohybovali v diskrétním (nespojitém) světě počítačů, musel by přístroj s takovouto zpětnou vazbou běžet nekonečně rychle (jeho výstup by se okamžitě promítal na vstup). To bohužel není možné (také bych si přál nekonečně rychlý počítač), a musí proto existovat nějaké omezení. Bylo by možné nechat přístroj s popsanou vazbou běžet maximální rychlostí, ale zátěž operačního systému a počítače by byla tak velká, že by se jiné aplikace nemusely vůbec dostat ke slovu. Nehledě na fakt, že přístroj nebývá v aplikaci jen jeden — běh všech přístrojů maximální rychlostí by zatížení ještě zvýšil.
Aplikace proto vnitřně definuje umělé zdržení mezi jednotlivými kroky jádra tak, aby byl zaručen jednak hladký chod aplikace a jednak bezproblémový běh celého zbytku systému. V současné době je zdržení mezi kroky 5 milisekund. Hodnota prodlevy byla pečlivě vybrána se znalostí mechanizmu, jakým operační systém řídí a přepíná prováděcí toky, a není vyloučeno, že se bude v budoucnu upravovat (tak, jak se budou počítače zrychlovat). Pět milisekund mezery mezi kroky odpovídá dvěma stům krokům realizovaným za jednu sekundu. To je více než dostatečná rezerva — z kolika průmyslových automatů přenesete potřebná data dvěstěkrát za sekundu (každá komunikace v čase pod pět milisekund)?
Samotná délka kroku jádra bývá různá podle momentálního výkonu komunikace. Obecně platí, že každý krok vždy dokončí všechny své komunikace, a teprve potom jádro přistoupí k aktivaci přístrojů a následně (po mezeře) ke spuštění nového kroku. Důležitý rys chování jádra spočívá v tom, že jádro neprovádí své kroky, pokud to není třeba. Tedy, neupraví-li přístroje žádné datové elementy, a nedojde-li ke změně hodnoty žádného kanálu, vyčká jádro do okamžiku, než některá z těchto událostí nastane. Faktická prodleva mezi kroky proto bývá mnohem větší, než je limitních pět milisekund.
Jádro aplikace a komunikace jsou zkonstruovány tak, aby nikdy nečekaly. Jejich činnost probíhá jen v nutných okamžicích, a i za situace, kdy jádro ještě nemůže spustit přístroje (protože není doměřeno), můžete kompletně celou aplikaci (i případně vývojové prostředí) bez omezení ovládat. Vnitřní mechanizmy a prodlevy ovlivňují pouze výkonné akce přístrojů, nikoli akce uživatelské. I aplikace čekající na doměření se proto chová normálně a umožňuje jakýkoli ovládací zásah.
V souhrnu je možné říci, že datově řízená aplikace pracuje cyklicky, přičemž délka a četnost jednotlivých cyklů jsou jádrem v širokých mezích optimalizovány.
Proměnné v aplikaci slouží k uchovávání vnitřních stavů. Jejich hodnota je okamžitě dostupná, a systém proto může na její změnu okamžitě reagovat. Zápis do proměnné proto způsobí bezprostřední (v dalším kroku jádra) aktivaci všech přístrojů, které tuto proměnnou používají jako vstup. Máte-li proto v aplikaci přístroj, ve kterém je zavedena zpětná vazba přes nějakou proměnnou, bude tento přístroj aktivován maximální rychlostí — nejvýše dvěstěkrát za sekundu (o mezeře mezi kroky pojednával předchozí oddíl).
Podívejme se na ukázku:
meter Display; ... range_from = 0; range_to = 100; a = a + 1; ... end_meter;
Tečky symbolizují ostatní parametry přístroje, pro pochopení ukázky je třeba zdůraznit, že přístroj nemá definovánu žádnou periodu obnovení. Aplikace s tímto přístrojem poběží následovně (pro jednoduchost předpokládáme, že přístroj je v aplikaci jediný):
Shrneme-li předcházející body dostaneme výsledek: přístroj začne ručičku po startu aplikace překlápět a po dosažení své horní meze běh ukončí.
Každý přístroj (nebo procedura, o procedurách se můžete dočíst v kapitole Programování a procedury — OCL může v systému Control Web vlastnit lokální proměnné, které je možné použít pouze v jednom přístroji (proceduře). Lokální proměnné jsou věcí přístroje, a netýkají se jich pravidla pro pohánění datově řízené aplikace. Použijete-li místo globální proměnné v předchozí ukázce proměnnou lokální:
meter Display; (* !!!! nepracující ukázka !!!! *) var a = real, 0; end_var; ... range_from = 0; range_to = 1000; a = a + 1; ... end_meter;
přístroj nepoběží, neboť změny lokálních dat nevedou k aktivaci přístrojů. Nabízí se proto jasné určení lokálních proměnných — tyto proměnné jsou velmi výhodné (a bezpečné) pro skladování mezivýsledků výpočtů.
Dalším základním druhem datových elementů aplikace jsou kanály. Již víte, že kanály v aplikaci představují zobrazení reálného snímače nebo řídicího členu. Důsledkem tohoto faktu je, že kanály nikdy nejsou okamžitě k dosažení a musí se z technologie do aplikace přenášet — komunikovat. Komunikace kanálů probíhá automaticky, přičemž systém sám zajišťuje vhodnou periodicitu obnování dat, jejich bezpečné doměření a nakonec, v případě změny hodnoty kanálu, i aktivaci přístrojů, které kanály používají.
Vstupní kanály tedy shodně s globálními proměnnými dokáží pohánět aplikaci (aktivovat přístroje). Existuje zde však jeden postatný rozdíl spočívající v příčině změny hodnoty proměnné nebo kanálu. Proměnou dokáže upravit pouze přístroj, vstupní kanál pouze techologie. Změnu proměnné proto aplikace rozezná bezprostředně v okamžiku, kdy do ní nějaký přístroj zapíše, změnu kanálů až po dokončení komunikace (v rámci jednoho kroku). Je proto účelné snažit se data kanálů získávat co nejčastěji, aby se co nejčastěji daly rozpoznat změny a přístroje na tyto změny mohly reagovat.
Jádro se proto snaží kanály měřit co nejčastěji. Víte již, že v každém časovém kroku musí doběhnout všechny potřebné komunikace, a také víte, že jádro aktivuje přístroje až po té, co měření dokončí. "Co nejčastěji" proto znamená tak rychle, jak komunikace a běh přístrojů dovolí (odtud také plyne úvodní věta této sekce — datově řízená aplikace pracuje tempem, které odpovídá množství komunikovaných dat). Pokud komunikace potřebných vstupních kanálů spotřebuje deset sekund, poběží jádro v cyklech dlouhých deset sekund, pokud komunikace spotřebuje desetinu sekundy, poběží jádro každou desetinu sekundy.
Popsaný mechanizmus obsahuje jistou nehospodárnost. Systém měří v každém kroku všechny vstupní kanály bez znalosti jejich významu, bez ohledu na děje, které kanál zobrazuje. Například teplotu okolního vzduchu (nebo teplotu vody v přehradě) není vůbec nutné měřit desetkrát za sekundu, i jednou za minutu to bude příliš často. V datově řízené aplikaci proto mají kanály volitelný parametr, který definuje doporučenou periodu měření kanálu. Doporučenou periodu můžete zadat jednak textově přímo do definice kanálu ("5" je perioda):
chrSinus = real, 1, Driver, input, 5;
a jednak "graficky" do sloupce "Perioda" tabulky "Kanály" v "Datových inspektorech" (více o vývojovém prostředí se dozvíte v kapitole Integrované vývojové prostředí). Definicí doporučené periody aplikaci naznačíte, jak často je třeba kanál měřit.
Možnost definovat periodu obnovení u kanálu je velmi užitečná. Jako tvůrce aplikace totiž dobře víte, co který kanál znamená, a oznámíte-li tuto skutečnost systému, může dojít ke značnému zvýšení efektivity běhu aplikace. Je rozdíl, komunikuje-li aplikace tisíc kanálů každou sekundu, nebo každou minutu. Prostřednictvím nápovědy doporučené periody měření kanálu můžete aplikaci značně usnadnit práci. Výsledkem bude menší spotřeba zdrojů operačního systému a lepší odezva běžící aplikace.
Kromě vstupních kanálů aplikace samozřejmě používá i kanály výstupní, které přenášejí data do technologie. Výstupní kanály není třeba nijak zvlášť obhospodařovat, od okamžiku zápisu jejich hodnoty do ovladače se o ně starají samy ovladače. Aplikace na jejich zápis nečeká. Zatímco vstupní kanály potřebují nepřetržitou obsluhu (musejí se měřit, jádro musí na dokončení komunikace počkat, je vhodné definovat periodu obnovení), výstupní kanály pracují zcela transparentně a automaticky. Stačí do kanálu zapsat hodnotu a o více se nemusíte starat.
Povaha výstupního kanálu umožňuje jejich použití na vstupech přístrojů — hodnota výstupního kanálu je vždy v aplikaci známa a není důvod zakazovat její čtení. Aplikace proto také i u výstupních kanálů sleduje změny hodnot a případně podle těchto změn aktivuje přístroje. Chování výstupních kanálů je velmi podobné chování proměnných (rozdíl je právě a pouze jen v komunikaci kanálů do technologie).
Každá aplikace se musí jednou rozběhnout a jednou také zastavit. Během spouštění je vždy nutné provést řadu akcí, které se za normálního běhu dělat nemusejí. Celá aplikace se musí připravit a inicializovat tak, aby byly zajištěny vždy stejné počáteční podmínky. Aplikace při rozběhu musí:
Některé z popsaných akcí je možné řídit parametry, které dokáží mírně upravit jejich průběh. Všechny parametry jsou součástí sekce settings aplikace (nastavení parametrů sekce je dostupné také v tabulce "Systém" v "Datových inspektorech" vývojového prostředí). Možné parametry jsou:
Součástí rozběhu aplikace může být také přístroj startup, který jádro spustí vždy jako první přede všemi ostatními přístroji. V datově řízených aplikací není použití přístroje startup tak důležité jako v aplikacích reálného času, neboť existuje jen jediná činnost, kterou není možné bez přístroje startup zajistit — v případě nastavení parametru skip_init_outputs na hodnotu true je přístroj startup jediné místo, kde můžete ovlivňovat hodnoty výstupních kanálů ještě před jejich první komunikací. Použití přístroje startup není povinné.
Poslední, dosud nepopsaná fáze rozběhu datově řízené aplikace, je spuštění přístrojů. Princip běhu datové aplikace spočívá v reakcích na změny hodnot datových elementů. Přístroje, které jsou aktivovány změnami hodnot kanálů, by se dříve či později rozběhly, protože komunikaci vstupních kanálů zajišťuje automaticky jádro aplikace. Avšak přístroje, které pracují s proměnnými, nemohou na činnost jádra spoléhat (neboť hodnotu proměnné dokáže upravit pouze přístroj). Dokud se totiž přístroje nerozběhnou, není žádný způsob, jak hodnoty proměnných změnit. Při startu aplikace proto jádro automaticky všechny přístroje poprvé aktivuje, a zajistí tak jejich případnou další — již datově řízenou činnost. (V mechanizmu rozběhu přístrojů existuje výjimka, která se týká periodicky pracujících přístrojů, ale ta bude popsána až v další sekci Periodické časování.) Zastavení aplikace je mnohem jednodušší než rozběh, protože vychází z běžícího, definovaného stavu. Aplikace systému Control Web může obsahovat přístroj terminate, který je v okamžiku zastavení aktivován. Pokud přístroj terminate nepoužijete, nevadí, neboť není (podobně jako startup) povinnou součástí aplikace. V přístroji terminate můžete realizovat všechny akce, které jsou nutné pro bezpečné zastavení nebo pro budoucí nový start aplikace — typickou úlohou pro přístroj terminate je rušení dočasných souborů nebo zálohování dat do nejrůznějších datových souborů.
Terminate může pracovat tak dlouho, jak potřebuje. Za běhu přístroje terminate aplikace normálně komunikuje, stejně jako jsou změnami dat normálně aktivovány přístroje. Jakmile terminate doběhne, aplikace se ukončí.
Velmi podrobně je rozběh aplikace a její zastavení popsán v následující kapitole Časování aplikací reálného času. Rozběhem se zabývají sekce Inicializace dat a Rozběh přístrojů, startup, zastavením sekce Ukončení aplikace, terminate.
Mnoho dějů, které vizualizující aplikace provádějí, vyžaduje periodicitu. Například všechny grafy, archivace nebo regulátory. Takovým přístrojům je proto nutné definovat periodu, se kterou je bude systém aktivovat. Systém Control Web podporuje tři základní způsoby, jak přístroj periodicky časovat:
Nejčastěji používaným časovačem je selector. Jeho síla spočívá v jeho schopnosti vypnout časování přístrojů. Velmi výhodné je jeho využití ve spolupráci s jednotlivými panely aplikace, kdy pomocí přístroje selector vypínáte přístroje v panelech, které momentálně nejsou zobrazeny. Vypnuté (nečasované) přístroje nepracují a tudíž nespotřebovávají systémový čas ani prostředky.
Časování přístrojů periodami a časovači je zevrubně popsáno v sekci Časování přístrojů kapitoly Časování aplikací reálného času. (Odkazy vedou doprostřed kapitoly, která se zabývá aplikacemi pracujícími podle jiných principů. Pro rozšíření poznatků o časování přístrojů datově řízených aplikací je proto vhodné z textu vybrat jen ty pasáže, které vysvětlují, jak jednotlivé druhy časování pracují. Samozřejmě, máte-li chuť a čas, přečtěte si kapitolu celou, je dlouhá, a možná i zajímavá.)
Uvažme nyní, co se stane, bude-li například graf (přístroj meter v některém z grafových režimů) časován a zároveň bude podle pravidel datově řízené aplikace ovlivňován jeho vstup jiným přístrojem. Změna dat (způsobená jiným přístrojem) by automaticky graf aktivovala — graf by se spustil mimo okamžik daný svou periodou. To by vyústilo v chybné zobrazování grafu — kromě "správných" hodnot odpovídajících okamžikům aktivace časováním by se v něm nacházela spousta hodnot "špatných" v okamžicích aktivace změnou dat.
Proto se periodicky aktivované přístroje chovají výjimečně, a jsou jádrem aktivovány jen v okamžicích stanovených jejich periodou. Změna dat, která jsou na vstupech těchto přístrojů, přístroj neaktivuje. Na tuto vlastnost se dá nahlédnout i jinak — časovaný přístroj běží díky svému časování, a nepotřebuje proto reagovat na změnu dat. Bez tohoto výjimečného chování časovaných přístrojů by například vůbec nebylo možné archivovat hodnoty kanálů každých dvacet sekund, s vysokou pravděpodobností by se archiver kvůli změně hodnoty kanálu aktivoval mnohem dříve.
V datově řízené aplikace mohou být periodicky časovány pouze některé druhy přístrojů (příkladem mohou být již uvedené grafy, programy, archivery a regulátory). Ostatní přístroje (například tlačítka) jádrem nebudou časovány i přesto, že jim periodu definujete. Perioda není při překladu odmítnuta zcela (to je nutné kvůli případným změnám režimů práce aplikace — z datově řízené aplikace na aplikaci reálného času a naopak), překladač však o neplatném zápise periody informuje v "Ploše informací o překladu".
Na závěr povídání o běhu datově řízených aplikací se pokusím objasněné principy shrnout do několika (ne zcela vyčerpávajících!) praktických rad, které vám mohou pomoci vaši aplikaci vytvořit:
Tato kapitola začala vysvětlením, že Control Web dokáže provozovat aplikace dvojího druhu — datově řízené a reálného času. Datově řízené aplikace jsou jednodušší, rychleji a snáze se vytvářejí. Za jednoduchost a snadnost se (bohužel) platí ztrátou některých zajímavých vlastností, které nemusí být potřebné (proto datově řízené aplikace existují), ale mohou někdy chybět (proto existují aplikace reálného času):
Pokud bychom hledali nějaké jednoduché rozlišení obou stylů návrhu aplikace, našli bychom asi dvojí:
Pokud cítíte, že vám některá z uvedených vlastností a schopností v datově řízených aplikacích schází, není nic jednoduššího, než přejít k aplikaci reálného času, která vše zvládne. Jestliže již však máte zkušenosti s datově řízenými aplikacemi, doporučuji před přechodem k aplikacím reálného času alespoň letmo projít kapitoly Časování aplikací reálného času a Programování a procedury — OCL, neboť aplikace reálného času pracují podle diametrálně odlišných principů a první pokusy s nimy se proto mohou zdát podivné.