# Běh datově řízené aplikace

## O datově řízených aplikacích

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?

- V případech, kdy data z technologie archivujete a vizualizujete bez potřeby precizně řídit časování těchto dějů.
- Vizualizujete-li pomalu se vyvíjející děje.
- Všude tam, kde tempo sběru dat příliš nesouvisí s během aplikace, a kde předem víte, že data z technologie rychleji stejně nezískáte.
- Pro aplikace, ve kterých je načasování měření dat méně důležité než jejich přehledná grafická prezentace.
- Potřebujete-li rychle vytvořit aplikaci, nad kterou "nebudete muset přemýšlet" (to se musí vždycky, ale datově řízená aplikace realizuje mnoho věcí automaticky a návrh aplikace tak značně usnadňuje).

## Jak datově řízená aplikace běží

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é

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ý):

- Po startu je přístroj automaticky spuštěn. V jeho prvním běhu se vyhodnotí vstupní výraz a + 1 a jeho výsledek se zapíše opět do proměnné a.
- Zápis nové hodnoty do proměnné a způsobí automatickou aktivaci přístroje v následujícím kroku jádra (tedy za pět milisekund).
- Přístroj je tedy znova spuštěn a opětovně vyhodnocuje svůj výraz, což opět způsobí jeho další aktivaci. Tyto činnosti se dále opakují.
- Přístroj meter ořezává svůj výstup mezemi definovanými v parametrech range_from a range_to. Jakmile proměnná a dosáhne hodnoty 100 (range_to), přičte se k ní jednička, ale výsledek — 101 — bude ihned ořezán na 100. Hodnota 100 se proto zapíše zpět do proměnné. Všimněte si, že před aktivací přístroje měla proměnná hodnotu 100 a aktivace její hodnotu nezměnila. Nebyl tedy splněn základní předpoklad pohánění datově řízené aplikace, a tímto okamžikem se proto spouštění přístroje zastaví.

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ů.

### Kanály a komunikace

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).

### Rozběh a zastavení aplikace

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í:

- Inicializovat výstupní kanály. Tím se zajistí shodnost hodnot kanálů, se kterými pracuje aplikace (výstupní kanály se neměří) a techologie.
- Inicializovat přístroje. Přístroje během inicializace nastavují své počáteční hodnoty (každý přístroj s výstupem umožňuje definovat svou počáteční hodnotu) do výstupních datových elementů a případně posílají zprávy a volají událostní procedury o změně svého výstupu.
- Obnovit data za záloh vytvořených přístroji backup. Změny datových elementů obnovených tímto způsobem se automaticky promítají do všech přístrojů, které tyto datové elementy používají jako svůj výstup.
- Provést případnou první komunikaci, která přenese (doposud jen připravované) hodnoty výstupních kanálů do technologie.
- Rozběhnout přístroje. Tím skončí start a aplikace začíná normálně běžet.

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:

- Parametr disable_init_messages zakazuje přístrojům během inicializace posílání zpráv o změně výstupu.
- Parametr skip_init_procedures přikazuje přístrojům během inicializace přeskakovat volání všech událostních procedur.
- Parametr skip_init_outputs. Na rozdíl od předchozích parametrů se tento chová poněkud složitěji. Jednak řídí jaké inicializační hodnoty kanálů se použijí a jednak řídí, kdy se provede první komunikace (komunikace výstupních kanálů).

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.

## Periodické časování

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:

- Relativně (jednoduchou periodou) — jádro aktivuje přístroj vždy nejdříve po uplynutí definované periody. Okamžiky aktivací přístroje jsou vztaženy k okamžiku startu aplikace, a přístroj proto nemá žádný přesně definovaný vztah k absolutnímu (skutečnému) času.
- Absolutně (periodou s posunutím) — perioda aktivace je doplněna posunutím, které vztahuje okamžiky aktivací k absolutnímu (skutečnému) času. Přístroj je jádrem aktivován v čase součtu posunutí a celistvého násobku periody počítaného od půlnoci. Přístroje časované absolutně jsou aktivovány podle skutečného času a jeho změny (například denní korekce) tudíž způsobují i změny časování přístrojů. Délky jednotlivých period aktivací se proto mohou u absolutně časovaných přístrojů v okamžicích změn času lišit.
- Časovačem — Control Web obsahuje tři speciální přístroje, které dokáží svou vlastní aktivaci šířit na další přístroje, a tak je časovat. Jednotlivé časovače se od sebe mírně liší činností, kterou vykonávají, takže existuje sequencer, který zajišťuje aktivaci přístrojů seřazených v definované posloupnosti, selector, který dokáže aktivovat různé skupiny přístrojů v závislosti na výsledku vyhodnocení obecné podmínky (dokáže časovat podmíněně), a iterator, který aktivace přístrojů provádí cyklicky.

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".

## Jak rychle a bezpečně navrhnout datově řízenou aplikaci

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:

- Zjistěte, jaká vstupní data (vstupní kanály) bude aplikace používat. Zároveň zjistěte, jaká je vhodná perioda obnovování jednotlivých kanálů. Podle takto připravených údajů definujte v aplikaci vstupní kanály.
- Zjistěte, jaká výstupní data bude aplikace poskytovat. Vytvořte výstupní kanály odpovídající zjištěným údajům.
- Definujte všem přístrojům, které mají pracovat periodicky, vhodnou periodu časování.
- Používejte pro veškeré mezivýsledky lokální proměnné. Nepoužívejte pro tento případ proměnné globální — zbytečně by se mohly aktivovat přístroje, které výsledek velmi pravděpodobně neupotřebí.
- Šetřte globálními proměnnými všeobecně. Globální proměnné jsou velmi mocný a rychlý prostředek, jak aplikaci řídit (pouhým přiřazením jedné proměnné můžete například zcela přeuspořádat viditelnost panelů — obrazovek), ale čím více bude v aplikaci těchto vazeb, tím obtížnější bude aplikaci udržet pod kontrolou.

## Omezení datově řízených aplikací

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):

- V datově řízené aplikaci nikdy nemůžete komunikovat jen ta data, která zrovna aktivované přístroje vyžadují. Aplikace reálného času proto může efektivněji komunikovat.
- V datově řízené aplikaci nikdy nemůžete ovlivnit délku komunikace, nemůžete dát přednost určitým důležitým kanálům. Aplikace reálného času proto dokáže reagovat s větší časovou stabilitou a se zřetelem na potřebnost dat.
- V datově řízené aplikaci nikdy nemůžete aktivně ovlivnit chod aplikace, neboť neexistují kritéria, podle který by se dalo rozhodovat. Datově řízená aplikace nikdy neběží ve skluzu, protože pracuje rychlostí komunikace. V aplikaci reálného času jsou kritéria, kterými se dá posoudit kvalita běhu, dobře definována, a vývoj běhu aplikace je proto možné libovolně upravovat.
- V datově řízené aplikaci nikdy nemůžete vytvořit řídicí aplikaci, která by dosáhla zaručených časových odezev. V aplikaci reálného času to je jedna ze základních úloh.
- V datově řízené aplikaci nikdy nemůžete dát přednost běhu aplikace. Vždy si budou vizualizace a běh aplikace vzájemně konkurovat. Aplikace reálného času dokáží pracovat v režimu, který (v případě potřeby) ignoruje okolí a věnuje se plně běhu aplikace.

Pokud bychom hledali nějaké jednoduché rozlišení obou stylů návrhu aplikace, našli bychom asi dvojí:

- míra volnosti návrhu a možnosti řešení problémů jsou v datově řízených aplikacích malé a v aplikacích reálného času velké.
- míra znalostí nutných k tvorbě aplikace je v datově řízených aplikacích menší a v aplikacích reálného času větší.

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é.

## Shrnutí

- Datově řízená aplikace aktivuje přístroje (a tím uskutečňuje svou činnost) v okamžiku změny hodnoty dvou druhů dat — proměnných a kanálů.
- Proměnné jsou vnitřní věcí aplikace, a mohou prot být změněny jen přístroji. Proměnné jsou proto jakýmsi signálním mechanizmem datově řízené aplikace. Schopnost aktivovat přístroje mají pouze proměnné globální.
- Kanály jsou naopak zobrazením technologie, a jejich změny musí systém vyhodnocovat sám — pomocí jejich opakovaného měření. Jsou-li data ze dvou po sobě jdoucích měření různá, aktivuje systém přístroje, které kanál používají jako vstup.
- Datově řízená aplikace se snaží změny zjišťovat co nejrychleji, takže komunikuje kanály tak často, jak to komunikační kanál dovolí. U většiny kanálů je předem známo, jak rychle je má smysl měřit. Tuto periodu obnovení je možné kanálu přiřadit a systém jej pak čte méně často.
- Mnoho činností musí probíhat periodicky, bez ohledu na změnu dat (ty jsou v těchto případech nezajímavé). Některé přístroje proto mohou být periodicky časovány.
- Datově řízená aplikace poskytuje rychlý a jednoduchý návrh za cenu zmenšení říditelnosti a omezení výrazových prostředků, které jsou jinak dostupné v aplikacích reálného času.