Myšlenka, že stroj může ovlivňovat sám sebe, je velmi stará. Přesto však její uskutečnění připadá až do novověku. Parní motory byly v Anglii známy několik desetiletí, a přesto stále nebyly použitelné. Konstruktéři neuměli vyřešit problém prudkého zvýšení otáček stroje při jeho náhlém odlehčení. Stroj většinou vysoké otáčky mechanicky nevydržel. Teprve až geniální objev odstředivého regulátoru přívodu páry umožnil otáčky udržet ve správných mezích, a tehdy mohl být parní stroj masově nasazen. Sám odstředivý regulátor byl pravděpodobně vůbec první lidstvem použitý automatizační prostředek.
Odstředivý regulátor je mechanický analogový regulátor a pracuje dokonale spojitě — na změny otáček reaguje kdykoli a okamžitě. Stroje a technologie dnešní doby jsou o několik řádů složitější než parní stroj, a jejich řízení s jedním mechanickým regulátorem nevystačí. Přesné, rychlé, spolehlivé a kontrolovatelné řízení je uskutečnitelné pouze s pomocí jiného programovatelného stroje — číslicového počítače.
Číslicový počítač pracuje diskrétně — postupně po jedné vykonává sled elementárních akcí. Pracuje velmi rychle, a proto obrovské množství jednoduchých akcí může dohromady realizovat (pochopitelně o něco pomaleji) i velmi složitou činnost. Současné počítače však nemají inteligenci a dokáží uskutečňovat jen to, co jim člověk programem přikáže. Pokud mají provádět nějakou činnost delší (nebo neomezenou) dobu, musí nutně určitou část programu vykonávat opakovaně, ve smyčce.
Automatizační úlohy, ať to je samostatný sběr dat, vizualizace, regulace nebo složitější řízení, jsou právě takovou skupinou úloh, která musí pracovat bez výpadků dlouhou dobu, a počítač proto vykonává program (celý nebo jeho různé části) mnohonásobně opakovaně. Povaha úlohy přitom přikazuje, jak často se jednotlivé části programu mají opakovat. S rychlostí opakování nejspíše nebudou problémy při regulaci výšky hladiny rybníka, naopak měření vibrací hřídele turbíny si nejspíš nějaký svižnější přístup vynutí. Programy, které by tyto dvě úlohy řešily, budou vcelku podobné — oba budou muset umět měřit (jednou výšku hladiny, podruhé vibrace), oba budou muset umět získaná data analyzovat a oba budou také muset poskytnou nějaký výsledek. Zásadní rozdíl nebude v principu práce programů, ale v jejich časování, ve způsobu jak rychle programy poběží a jak rychle se budou muset opakovat.
Všimněte si, že povaha technologií a fyzikálních jevů vcelku přirozeně (i když pouze rámcově) předurčuje rychlosti, které je třeba při jejich řízení nebo vizualizaci použít. Řídicí nebo vizualizační akce, které program zajišťuje, tak mají předem přibližně dáno, jak často musí být spouštěny.
Všechny automatizační úlohy souvisejí s časem, jednak musejí pracovat periodicky a jednak musejí své výsledky vztahovat k okamžikům, kdy mají smysl a platnost. Skutečný čas plyne nezávisle a spojitě (kvantové aspekty pomineme), naopak čas automatizační úlohy plyne po skocích. Sladění těchto dvou časů a orientace mezi nimi je proto součástí každého automatizačního programu.
Některé úlohy navíc musí splňovat určitá další kritéria, například regulační smyčka běží každou sekundu, a program navíc musí zajistit, že jeden běh smyčky nebude delší než 50 milisekund. Možný největší počet opakování smyčky programu je s délkou jednoho běhu úzce svázán, není možné požadovat, aby smyčka běžela desetkrát za sekundu a přitom sama trvala 5 sekund. Zdroj času, který má program provozující automatizační úlohu k dispozici, musí být natolik přesný, aby úloha mohla nejen bezpečně zajistit své opakování (s patřičnou rychlostí), ale navíc také veškeré další časové požadavky na ni kladené. Obyčejně se za bezpečný považuje zdroj času, který má nejméně 10× až 20× větší rozlišení než je nejkratší časový interval, s nímž úloha operuje (například, má-li úloha pracovat s periodou 100 milisekund, měla by mít k dispozici zdroj času s rozlišením ne horším, než 5–10 milisekund).
Program provozující nějakou úlohu musí mít k dispozici prostředky, kterými dokáže požadavky řešení uspokojit. Pokud se to nedaří (z nejrůznějších důvodů) musí mít program jednak možnost zjistit, že a proč se něco nedaří, a jednak musí mít možnost chybný stav řízeně opravit (opět nejrůznějším způsobem — je možné úlohu zastavit, restartovat nebo pokusit se "zvýšeným úsilím" situaci napravit).
Programové systémy, které mají schopnost orientace v čase, znají svůj momentální stav, vědí, jakou mají rezervu a jsou schopny přesně zjistit (a případně odstranit) příčinu svých časových potíží jsou systémy reálného času. Důležité je, že systém reálného času má vždy informace o svém běhu, ale nemusí být vždy schopen všechny požadavky na něj kladené splnit absolutně. Důraz je tedy kladen na informace, podle kterých se aplikace sama může rozhodovat o svém vlastním běhu. Žádný systém reálného času nikdy nedokáže například:
Systémy reálného času jsou velmi flexibilní a mocné, ale jsou schopné uspokojit pouze požadavky, které jsou rozumné, neboli požadavky reálně vztažené k použitému hardware, technologii, možnostem operačního systému, možnostem přenosu dat a fyzikálním zákonům. Systém reálného času vždy dokáže "pouze":
Systém Control Web je systém reálného času. Jeho aplikace se může dobrovolně těchto vlastností vzdát — může pracovat jako řízená daty. To přináší zjednodušení návrhu a menší nutnost detailně celou úlohu promýšlet. Stojí však za úvahu, jestli zjednodušení tvorby aplikace vyváží nemožnost aktivně a přesně ovlivňovat její chod.
V předchozím oddíle se velmi často skloňovaly pojmy "program", "smyčka" případně "jeden průchod programu". Aplikace v systému Control Web žádný zjevný "program" nebo "smyčku" neobsahuje, a přesto všechny popsané principy a pravidla realizuje a splňuje — jako celek, sestavený z jednotlivých samostatných spolupracujících objektů. To je velká výhoda systému Control Web, neboť automatizační úlohu je možné rozložit na jednoduché (logické) části, které pracují "vedle sebe", nezávisle. Samozřejmě, všechny takové části spolu mohou velmi dobře komunikovat, vždyť jsou součástí jedné aplikace, nicméně míra a způsob této komunikace zůstavají plně v moci aplikačního programátora.
Pokud bychom se přeci jen snažili v aplikaci nalézt pojem "smyčka" nebo "program", nalezeneme je na dvou možných úrovních:
Je možné říci, že jedna aplikace v systému Control Web pracuje jako řada zcela nezávislých automatizačních miniúloh, přičemž elementární jednotkou pro běh miniúlohy je přístroj. Tyto principy — jednak oddělení řídicích operací a jednak plná distribuovatelnost běhu úlohy (možné rozložení problému na mnoho přístrojů) — v souhrnu umožňují velmi jednoduchý a zároveň extrémně mocný návrh aplikací. Control Web přitom zůstává stát v pozadí s jediným úkolem — vykonávat požadavky jednotlivých aplikačních objektů.
Hlavním problémem časování je zajištění dostatečné přesnosti běhu aplikace v jakémkoli stavu zaneprázdněnosti operačního systému. Control Web dosahuje požadované přesnosti jednoduchým (avšak promyšleným) způsobem. Běžící aplikace je vnitřně rozdělena na část časově kritickou, která zaručuje přesnost časování, a část výkonnou, která pohnání přstroje a komunikuje. Opět se zde objevuje charakteristický rys systémů reálného času — především je nutné mít dobré informace o časových poměrech v aplikaci (to právě zajišťuje časově kritická část aplikace).
Control Web vyhrazuje pro kritickou část aplikace samostatný prováděcí tok (o procesech a tocích se dočtete více v kapitole Co jsou to procesy a prováděcí toky), který pracuje s vyšší prioritou, než mají všechny ostatní normální toky všech aplikací systému. Operační systém zaručuje, že z toků, které jsou v daném okamžiku schopny běžet (tedy nečekají a nespí), poběží vždy tok s nejvyšší prioritou (pokud je toků se stejně vysokou prioritou více, bude je operační systém střídat). Prováděcí tok s kritickou částí aplikace (jiný jeho používaný název je časovací prováděcí tok, případně česko-anglicky časovací thread) proto díky své vyšší prioritě poběží právě tehdy, kdy se sám rozhodne.
Časovací tok:
Časovací tok pracuje velmi efektivně díky svému optimalizovanému návrhu a díky přesné definici svých činností. Realizuje skutečně jen to nejnutnější, co je třeba pro dokonalou časovou orientaci aplikace. Má to však jeden háček. I sebelepší návrh nepřemůže operační systém.
Operační systémy Windows95/98, WindowsNT4.0, Windows2000 a WindowsCE2.1 používají model prováděcích toků pracující s elementárním časový kvantem dlouhým 15 milisekund, přičemž k délce tohoto kvanta jsou vztaženy i operace čekání a "spánku". Pokud v těchto operačních systémech přikážete prováděcímu toku "spi 3 milisekundy", je tok při první vhodné příležitosti (maximálně po 18 milisekundách) po "probuzení" zařazen do fronty toků, které jsou připraveny běžet, a teprve jakmile se na něj dostane řada, je rozběhnut. Skutečný interval, po kterém bude probuzený tok rozběhnut, je závislý především na celkovém počtu toků běžících se stejnou prioritou. Bude-li tok v systému sám (velmi nepravděpodobná varianta), bude nejspíše skutečně "spát" 3 milisekundy. Čím více však v systému poběží toků, tím více se 3 milisekundy mohou natáhnout.
Většina programových balíků a aplikací operačního systému je naštěstí napsána ohleduplně (stejně jako Control Web), a jejich prováděcí toky pracují jen v okamžicích, kdy se něco stane a kdy je třeba skutečně reagovat. Typický příklad je textový editor — jeho tok zpracovávající vstup z klávesnice bude po většinu času dobrovolně spát, a nechá se vzbudit operačním systémem jen v okamžiku stisku klávesy. Výsledkem této dobrovolné ohleduplnosti je stav, kdy většina toků na něco čeká, a i když jich celkem v systému bývá běžně kolem stovky, skutečně aktivních — běžících jich je jen málo. Operačnímu systému se proto daří ve většině případů programátorem požadované prodlevy dodržet (i když by podle svých specifikací nemusel).
Časovací tok má vyšší prioritu a většinou běží samostatně. Přerušen může být jen toky s ještě vyšší prioritou (což jsou toky systémové) a uvedené možné variace prodlev proto nejsou tak velké. Nicméně i tak vzájemné interakce systémových toků a časovacího toku vyúsťují v drobné interferenční odchylky velikosti až ±5 milisekund od správné hodnoty.
Zkušenosti ukazují, že takové variace jsou celkem pravidelné. Například postupné délky opakovaného intervalu 1 000 milisekund mohou být 1 001, 1 002, 1 001 a 996 milisekund, což zase není až tak špatné. Bohužel (to uvidíte později), tyto variace mohou velmi ovlivnit okamžiky vztažené k absolutnímu času. Čtyřem uvedeným hodnotám intervalů mohou například odpovídat absolutní časové okamžiky 0,998, 1,999, 3,001, 4,002 a 4,998 sekund. Použijeme-li z těchto okamžiků jen celé sekundy (nebo jinak, budeme-li v těchto okamžicích číst sekundy absolutního času), dostaneme posloupnost sekund 0, 1, 3, 4, 4. Nic moc pravidelného i přesto, že aplikace, přesněji časovací tok, pracuje s přesností ± 0,2 % (největší odchylka byla na sekundovém intervalu ± 2 milisekundy).
Z uvedeného vyplývá, že systém Control Web je schopen velmi přesně dodržet počet časových kroků v určitém intervalu v případě, že aplikace běží volně, bez skluzu. Obecně lze říci, že čím více se zkracují periody běhu přístrojů, tím větší budou variace délek jednotlivých period (intervaly přestanou být izochronní).
Neměli bychom zapomenout, že časovací tok neběží jen tak sám pro sebe a že aplikace obsahuje také nějaké přístroje a ovladače. Především ony totiž nakonec ovlivňují skutečné délky period a určují, jestli aplikace bude pracovat hladce nebo s časovými potížemi. Nejrychlejší přístroje (program, samostatné procedury) spotřebují řádově desítky mikrosekund v každém běhu. Aplikace však také archivuje, vykresluje či komunikuje a spotřeby času těchto úloh mohou dosáhnout i sekundových hodnot. Konečný výsledek, pružnost a svižnost aplikace reálného času v důsledku proto vždy záleží jen na návrhu a implementaci vlastní aplikace.
Control Web nabízí pro globální úpravu běhu aplikace speciální možnost zvýšení (nebo snížení) priority celého procesu, tedy automaticky všech jeho prováděcích toků (detailně je rozdíl mezi prioritami procesů a prováděcích toků popsán v kapitole Co jsou to procesy a prováděcí toky). Celá aplikace (nejen časovací tok, ale i výkonná část) tak může mít přednost před všemi ostatními v operačním systému. To může být někdy užitečné, například v situacích, kdy v systému běží nějaká úloha na pozadí — například programy synchronizující čas. Jinak je zvyšování priority procesu jako celku de facto zbytečné, neboť:
Většina technologických úloh je povahou spíše vizualizační. Aplikace především slouží k zobrazení stavu, archivují hodnoty, případně předzpracovávají data pro další použití. Důležitý je sběr dat a jejich prezentace. Takové aplikace také většinou zpracovávají velký tok dat, nezřídka se současně měří mnoho tisíc kanálů a vytvářejí stovky databází.
V kontrastu proti vizualizačním úlohám stojí přímé řízení, které je takřka pravým opakem. Datový tok bývá malý (ale rychlý), aplikace především řídí a bývá zaručena určitá doba odezvy. Většinou se také nic nearchivuje a na obrazovce (pokud ji počítač vůbec má zapojenu) se zobrazují jen nejnutnější údaje.
Z pohledu aplikace a časovacího toku systému Control Web jsou oba přístupy (téměř) totožné, neboť funkčnost aplikace je vždy dána pouze funkčností použitých přístrojů. Obecný rámec reálného času poskytovaný systémem Control Web to nijak neovlivňuje. Co však může být nastaveno, a co může ovlivnit způsob práce aplikace, je míra zdržení operačním systémem.
Pokud Control Web zrovna neprovozuje nějakou aplikaci, pracuje normálně jako ostatní aplikace operačního systému. Většinu času čeká na nějakou vstupní událost, kterou nejčastěji bývají nějaká operace s myší, klávesnicí nebo pokyn k překreslení nějaké části plochy. Objeví-li se událostí najednou více, seřadí je operační systém do fronty a Control Web je zpracuje postupně. Pojmenujme všechny tyto události jako vstupní.
Rozběhnete-li aplikaci, situace se změní. Control Web jako systém reálného času dává přednost běhu aplikace před vstupními událostmi, které zpracovává až když mu zbude nějaký čas (řečeno s určitou nadsázkou). Běží-li aplikace s dostatečnou rezervou (neboli nemusí-li být neustále všechny přístroje poháněny), je v prodlevách mezi jejich akcemi na zpracování vstupní fronty času dostatek. Pokud však aplikace "nestíhá", není na vstupní události čas, a systém reálného času má dvě možnosti — buď vstupní události ignorovat, nebo respektovat. Bohužel, vstupní události jsou nevyzpytatelné, a nelze se nijak spolehnout, že jich bude jen malý počet nebo že budou všechny zpracovány v určitém čase. Pokud je systém zpracovává, může to pro něj být dosti nepříjemná věc.
Časovací tok je zpočátku nastaven tak, aby při svém běhu vstupní události respektoval, takže po dokončení každé jedné elementární smyčky zjišťuje, jestli operační systém něco zajímavého nepřipravil. Pokud ano, počká nejprve časovací tok na vyprázdnění vstupní fronty a teprve potom pokračuje ve svém běhu. Z toho vyplývá, že základní způsob práce aplikace systému Control Web je spíše vizualizační — po každém elementárním kvantu běhu jsou zpracovány všechny dostupné vstupní události.
Pro aplikace přímého řízení je tento přístup riskantní. Vstupní události mohou počkat, protože primární je zaručení správného chování řídicího systému. Časovací tok takovou změnu umožňuje, a dokáže běžet naplno bez čekání na vyprázdnění vstupní fronty — dokáže běžet v režimu pevného reálného času. Volba, která ovlivňuje popsané chování časovacího toku, je součástí aplikační sekce settings a jmenuje se hard_real_time:
settings ... hard_real_time = true; ... end_settings;
Parametr samozřejmě můžete nastavit také v záložce "Systémové nastavení" v "Datových inspektorech" volbou "Striktní dodržování reálného času".
Aplikace pracující v režimu pevného reálného času dává přednost svému běhu. Uvažme nyní znovu důležitá fakta, která s během aplikace v tomto režimu souvisejí:
Souhrný výsledek je tento: Pokud aplikace pevného reálného času nemá rezervu a pracuje maximální rychlostí, nezpracovávají se vstupní události, a aplikace proto: nekreslí, nereaguje na klávesnici a nereaguje na myš, takže nepracují tlačítka ani jiné ovládací prvky. Teprve až se systému uleví, vyšetří se nějaký čas, a fronta vstupních událostí se zpracuje. Není příliš dobré, aby aplikace soustavně vstupní frontu ignorovala, protože se tím de facto odřezává od zpráv operačního systému. Nicméně, pokud to má aplikace přikázáno, nic jiného jí nezbývá.
Běh v pevném reálném čase ovlivňuje ještě jeden parametr. Control Web standardně sleduje dobu, po kterou aplikace ignoruje vstupní frontu, a pokud je tato doba příliš dlouhá, násilím aplikaci pozdrží a frontu zpracuje. Tuto sledovací dobu, po kterou bude aplikace mít povoleno ignorovat vstupní události, nastavíte parametrem aplikace paint_time_limit v sekci settings. Možnosti nastavení jsou široké — od 0, kdy de facto zrušíte pevný reálný čas (otázka je, proč byste to tak dělali), až po infinite, kdy pevný reálný čas poběží přesně tak tvrdě bez zpracování vstupních událostí, jak to bylo popisováno.
Aplikace pevného reálného času musí být více než jiné dobře promyšlena a musí více než jiné pracovat s dostatečnou rezervou (opět další ukázka klasického konfliktu: mocnější a kvalitnější řešení vyžaduje více práce a promýšlení). Použití pevného reálného času je třeba vždy zvážit, protože jeho vlastnosti a způsob chování jej předurčují pro "neviditelný" běh. Je asi zbytečné snažit se pomocí pevného reálného času dávat přednost běhu aplikaci, která v každém svém kroku přeskládá několik databází na síťových serverech. Doporučení je jasné — prvotní nastavení aplikace (tedy bez pevného reálného času) vyhoví v 99,5 % případů a pevný reálný čas by měl zůstat vyhražen pro skutečně kritické řídicí aplikace.
Součástí aplikace systému Control Web jsou různé podrobné informace o běhu časovacího i výkonného toku, o běhu jednotlivých přístrojů a o komunikacích. Aplikace (přesněji každý modul) může pomocí parametru show_timing_info sekce settings všechny tyto údaje zobrazit v okně "Časování" (volbu "Zobrazit okno s informacemi o časování aplikace" můžete nastavit také v záložce "Systém" v "Datových inspektorech"), které je potom kdykoli za jejího běhu dostupné k nahlédnutí. Okno "Časování" obsahuje čtyři vodorovné záložky:
Záložky okna Časování
Jednotlivé záložky obsahují údaje sdružené podle logického významu, přičemž záložka "Časování" obsahuje souhrnné informace o běhu, záložka "Ovladače" souhrnná data o komunikaci, záložka "Kanály" data o komunikaci jednotlivých kanálů a záložka "Přístroje" statistická data o jednotlivých přístrojích.
Význam jednotlivých položek v záložkách bude podrobně vysvětlován postupně v dalším textu kapitoly, tak jak se postupně bude odhalovat způsob práce systému Control Web. Zde bude vysvětlen pouze význam těch údajů, o kterých se již další text nebude zmiňovat:
Záložka kanály je mírně odlišná od záložek "Ovladače" a "Přístroje". Nenabízí totiž ve svém výběrovém řádku jména dostupných kanálů. Kanálů bývá v aplikacích velký počet a kopírování jejich jmen do seznamu by spotřebovalo mnoho času i paměti. V záložce "Kanály" proto musíte jméno požadovaného kanál nejprve vepsat do výběrového řádku, a teprve až po té systém zobrazí jeho data. Jednou zapsaná jména se přitom do výběrového řádku přidávají. Je-li vybraný kanál pole, musíte do řádku spolu s jeho jménem zapsat také požadovaný index (například chaPressure[112]).
Některé údaje zobrazované v okně "Časování" jsou dostupné přímo běžící aplikaci — většina informačních a statistických údajů o komunikaci kanálů je dostupná v jejich atributech (podrobný popis atributů obsahuje kapitola Datové elementy a výrazy, údaje o skluzu aplikace a skluzu přístroje jsou zase dostupné v parametru ActivateMode systémové událostní procedury OnActivate() (popis systémových událostních procedur obsahuje kapitola Programování a procedury — OCL). Aplikace se tak může přesně dozvědět, v jakém momentálním stavu se komunikace, případně celá aplikace, nachází.
Oddíl Časování přístrojů se zabývá časováním z pohledu přístrojů — z pohledu aplikace a jejího tvůrce. Její náplní budou způsoby časování — tedy jak aplikaci pohánět. Vnitřní principy běhu systému Control Web popisuje dále oddíl Časování zevnitř.
Aplikace reálného času jsou navrhovány "událostním" a "algoritmickým" způsobem — "událostním" proto, že v řadě situací aplikace reagují (a vykonávají akce) na uživatelský zásah nebo informaci z ovladače, "algoritmickým" proto, že aplikace realizuje nějaký předem známý postup řízení, archivací nebo jiných akcí. Primární je znalost technologie a jejích součástí, aplikace je potom modelem, který technologii ovlivňuje.
Zatímco "událostní" přístup vyúsťuje v řadu akcí neperiodických, asynchronních, přístup "algoritmický" produkuje akce peridodické, akce, které v pravidelných intervalech něco monitorují, nebo ovlivňují. Periodické provádění akcí je základ běhu všech aplikací reálného času.
Elementárním prvkem aplikace je přístroj. Každý přístroj může uskutečňovat velké množství činností (v extrémním případě můžete celou aplikaci vytvořit s použitím procedur jednoho přístroje), přičemž z pohledu systému je již lhostejné, kolik jich vlastně je. Control Web časuje (v tomto oddíle se pojem časování zúží a bude synonymem ke spojení "periodická aktivace") vždy celé přístroje — procedury mohou také "běžet samostatně" a "dobíhat", ale jejich aktivaci zajišťuje (vnitřně) přístroj, nikoli systém. Dále proto budeme používat spojení "časování přístroje", přičemž tím bude vždy myšleno "časování přístroje jako celku", tedy včetně případných procedur.
Základní způsob, jak časovat, je časování periodou. Časování periodou znamená aktivaci přístroje vždy po uplynutí zvolené délky periody, bez vztahu k okolnímu absolutnímu času. Systém zajišťuje jen periodicitu a shodnost intervalů, nic více. Protože je počátek časování periodou vždy relativně vztažen k okamžiku startu aplikace, nazývá se toto časování také relativní časování (časovací periody musejí někdy začínat a start aplikace je celkem přirozeným vhodným okamžikem). Systém Control Web bude přístroj relativně časovat, pokud bude v zápisu jeho parametru timer číselná hodnota (případně číselná konstanta):
meter Graph; ... timer = 15; ... end_meter;
Přístroj Graph bude časován každých 15 sekund počínaje startem aplikace (z příkladu vyplývá, že časový údaj v přístroji je udáván v sekundách; všechny časové údaje v aplikaci jsou udávány v sekundách).
Perioda může být zadána v rozmezí od 0 do "nekonečna". Nulová perioda má speciální význam — přístroj bude časován maximální možnou rychlostí systému a jednotlivé smyčky časovacího toku budou velmi krátké a rychlé. Přístroj s nulovou periodou bude pracovat značně anizochronně (koneckonců perioda je nulová, tak jakápak izochronie) a okamžiky jeho oživování budou tudíž značně ovlivněny momentálním stavem celého operačního systému. Nicméně, rychlost systému je opravdu značná a přístroj s nulovou periodou může být obvolán mnohotisíckrát za sekundu. Perioda "nekonečno" se do textu zapisuje jako klíčové slovo infinite (celý parametr potom bude timer = infinite;) a má také speciální význam — přístroj bude spuštěn pouze jednou při startu aplikace.
Na tomto místě je vhodné poprvé použít pojmu časový krok a začít s ním operovat. Časový krok má (bohužel) v systému Control Web dva významy. První význam je vztažen k přístroji, a znamená jednu aktivaci přístroje (ať už to je aktivace časováním nebo nějakou událostí), druhý význam je vztažen k vnitřnímu časování a znamená jeden elementární běh časování systému. Tento oddíl zůstane u významu prvního, neboť druhého si dosyta užijete později.
Pro relativní časování přístrojů v souhrnu platí:
Všimněte si, z prvního bodu vyplývá, že start aplikace může být velmi náročný. Aplikace může obsahovat velké množství relativně časovaných přístrojů, a všechny takové přístroje při startu provedou svou akci. Start aplikace proto může představovat značné nahuštění činností přístrojů (takové nahuštění již nikdy později nemusí nastat) se všemi důsledky z toho plynoucími — například může vzniknout skluz.
Důsledkem druhého bodu je zase skutečnost, že relativně časovaný přístroj ignoruje absolutní čas. Jednak není možné stanovit počátek časování (vždy se začne v okamžiku startu) a jednak beze změny periody není možné zachovat aktivace ve stále stejných okamžicích absolutního času (i kdyby se to po startu podařilo, tak první změna systémového času vše zhatí). Případnou vazbu na absolutní čas je proto třeba realizovat jinak.
Relativní časování je velmi jednoduché, je možné je považovat za časování "první volby" a pravděpodobně bude použito ve většině případů.
Jednoduchým rozšířením popsaného relativního časování vznikne časování absolutní, neboli časování periodou s posunutím. Přístroje s absolutním časováním budou mít v zápisu parametru timer dvě časové hodnoty:
program Analyze; ... timer = 60, 10; ... end_program;
První číslo opět definuje periodu (podobně jako při relativním časování), druhé posunutí. Časování periodou s posunutím je vztaženo ke skutečnému absolutnímu času, systém časování přístroje udržuje v závěsu systémového času.
Počáteční okamžik všech period s posunutím je stanoven na půlnoc dne, kdy byla aplikace spuštěna (půlnoc, která již uplynula). Parametr posunutí potom určuje zpoždění začátku první periody, neboli čas, který uplyne od půlnoci do okamžiku prvního časového kroku přístroje.
Podívejme se na periodu s posunutím více prakticky. Uvažme případ nulového posunutí. Absolutní perioda časování začíná o půlnoci a dále pokračuje ve stanovených intervalech. Časování 60, 0 proto znamená "první časový krok je o půlnoci a další následují po minutě", časování 259200, 0 znamená "první krok o půlnoci a další následují každou třetí půlnoc, tedy o půlnoci na konci 3., 6., 9., ... dne běhu".
Nenulové posunutí celý mechanizmus časování posune o patřičný interval vpřed. Časování 60, 30 znamená "první časový krok je 30 sekund po půlnoci a další následují po minutě, tedy v 00.01:30, 00.02:30, ...", časování 259200, 86400 znamená "první časový krok bude jeden den po půlnoci, další potom po třech dnech, tedy o půlnoci na konci 1., 4., 10., ... dne běhu".
Vztah periody a posunutí je omezen pouze přirozenou podmínkou, že posunutí nemůže být větší než perioda. Pokud však přesto takové posunutí zadáte, použije z něj systém zbytek po dělení periodou (stejného výsledku dosáhnete jak časováním 60, 17 tak časováním 60, 77).
Aplikace bývá spuštěna v nepříliš přesně určeném okamžiku. Bez ohledu na tento fakt systém samozřejmě musí zajistit správné rozběhnutí absolutních period. Control Web vypočítá nejbližší vhodný okamžik (který odpovídá výše popsanému "půlnočnímu" mechanizmu) tak, aby přístroj svůj první časový krok provedl v souladu s definicí časování. Absolutně časovaný přístroj prostě jen začne pracovat místo v první periodě po půlnoci v některé z period dalších. To znamená, že absolutně časované přístroje vždy vykonají svůj první časový krok dříve, než uplyne (relativně od startu aplikace) jejich perioda.
Absolutní časování je zavěšeno na skutečný (absolutní) čas. Musí proto reagovat na jeho změny. Zadáte-li například časování 3600, 1800, předpokládáte, že časové kroky přístroje budou vždy v polovině mezi celými hodinami, a to samozřejmě musí být zachováno i v případě, že se čas počítače posune o deset minut (třeba kvůli tomu, že se předbíhal). Změny systémového času proto vždy způsobují změny absolutního časování přístrojů. Na rozdíl od relativního časování (kde je prioritní perioda) má při časování absolutním přednost vazba na skutečný čas. Periody nejsou tak důležité, zachovávají se pouze v intervalech mezi změnami systémového času.
Mechanizmus výpočtu period s posunutím pracuje stejně dobře i pro desetinná čísla (pro zlomky sekundy). Klidně můžete přístroji definovat časování 1.17, 0.29 a systém zajistí přístroji časové kroky ve správných okamžicích. Je to poněkud méně zřejmé než při použití celých čísel, nicméně je to stejně dobře možné; i přesto, že většina absolutně časovaných přístrojů bude používat period a posunutí celistvých.
Systém Control Web počítá periody a posunutí v okamžiku startu a dále vždy při změně systémového času. Control Web vždy vypočítá jen počáteční zdržení, které je nutné pro zarovnání posunuté periody, a další časové kroky již následují periodicky. Mechanizmus výpočtu dalších časových kroků je tak shodný pro obě časování — absolutní i relativní. Z hlediska výkonu aplikace a režie systému je proto absolutní časování shodné s relativním.
Pro absolutní časování v souhrnu platí:
Absolutně časované přístroje proto mohou být použity například:
Hlavní odlišnost absolutního a relativního časování spočívá v zachovávání či nezachovávání délek jednotlivých period. Pokud není délka periody pro přístroj kritická (chcete-li přístroj časovat "asi tak každých deset sekund" tak perioda kritická není), je vhodné zamyslet se nad časovým rozdělením zátěže — rozfázováním běhu a použít absolutní časování. Uvidíte, že aplikace poběží lépe, když bude častěji provádět menší dávky přístrojů.
V souvislosti s absolutním časováním mějte na paměti časové variace způsobené přepínáním prováděcích toků. Uvažme přístroj s časovačem 1, 0, který zobrazuje sekundy skutečného času. Takový přístroj by měl zobrazovat každou sekundu novou hodnotu. Již bylo vysvětleno, že tomu tak nebude vždy (milisekundové variace period se ořezáním projeví jako sekundová chyba). Je proto třeba s tímto mechanizmem počítat:
Poslední poznámka se týká odlišných konvencí zápisu desetinných čísel v našich a anglosaských zemích. Zatímco u nás je obvyklé oddělovat desetinnou část čísla čárkou, v anglosaských zemích se používá tečka. Control Web používá stejně jako všechny ostatní vývojové systémy a programovací jazyky desetinnou tečku. Pokud v přístroji použijete zápis expression = a * 1,9;, systém ohlásí chybu. Pokud ale stejné číslo zapíšete u klíčového slova timer, žádná chyba hlášena nebude, systém údaj akceptuje jako časování s periodou 1 a posunutím 9.
Relativně i absolutně časované přístroje provádějí své časové kroky v rytmu, který jim přikazuje časovací tok aplikace. Jsou časovány přímo samotným systémem. Control Web definuje ještě i jiný způsob časování — nepřímý, kdy přístroje provádějí své časové kroky uvnitř časového kroku jiného logicky nadřazeného přístroje. Přístroje, které mohou zastřešovat při časování jiné přístroje, se nazývají časovače a způsob časování přístrojů s využitím časovačů časování časovačem.
Princip práce časovačů je jednoduchý — časovač ve svém časovém kroku prochází jednotlivé podřízené přístroje a podle určitých pravidel jim povolí uskutečnit jejich časové kroky. Časovače vytvářejí jakési "malé jadérko", které pohání jen omezenou skupinu přístrojů. Je proto celkem logické, že podřízené přístroje pracují všechny se stejnou periodou jako jejich časovače. Samotné přístroje časovačem časované pracují úplně stejně jako při periodickém časování (dokonce to ani nijak nejsou schopny rozlišit). Přístroj časovaný časovačem obsahuje ve svém parametru timer jméno příslušného časovače, a případně navíc požadované pořadí časování:
meter Graph; ... timer = Sequencer_100ms, 4; ... end_meter;
Přístroj Graph bude časován časovačem se jménem Sequencer_100ms a časovač bude tento přístroj spouštět jako čtvrtý v pořadí. Definice pořadí časování není povinná, a pokud ji neuvedete, bude přístroj zařazen do časovače na aktuální poslední pozici (další přístroje bez určení pořadí časování budou opět umístěny na aktuální poslední pozici, tedy za). Definované pořadí časování je nejlépe viditelné ve stromu časování grafického editoru vývojového prostředí. Pořadí jednotlivých přístrojů zařazených do časovače přesně odpovídá zapsaným hodnotám. Pokud pořadí přístroje ve stromu (přetažením) upravíte, změní se i zápis pořadí časování ve zdrojovém textu. Pokud je během načítání zdrojového textu nalezeno několik přístrojů se shodně definovaným pořadím, zařadí je systém do časovače postupně tak, jak jsou nalezeny ve zdrojovém textu.
Všechny časovače mohou obsahovat najednou více přístrojů (i časovačů). Podřízené přístroje jsou v časovačích uspořádány za sebou v sekvenci, kterou časovače pevně dodržují. Znamená to, že časovač jednotlivé podřízené přístroje časuje postupně, tak jak přístroje ukončují své časové kroky. Dokud přístroj neukončí svou činnost, nepokračuje časovač dále. Tato sekvenčnost zpracování je vlastní všem časovačům a je to zároveň to hlavní, co odlišuje periodické časování od časování časovačem, neboť při periodickém časování systém nijak pořadí časování přístrojů nezaručuje — v ideálním případě nekonečně rychlého počítače (toho se nikdy nedočkáme) by pracovaly všechny periodicky časované přístroje současně.
Poznámka k procedurám — procedury mohou ukončit (nebo přerušit) svůj běh několika způsoby: doběhnutím na konec, nebo příkazy pause, wait, yield a stop. Pokud bude v přístroji procedura OnActivate(), která bude některým z popsaných ukončovacích příkazů přerušena, ukončí se tím i celý časový krok přístroje. Zařadíte-li proto do časovače přístroj s procedurou, je vhodné pečlivěji rozmyslet, jak jsou použité procedury naprogramovány. Jejich předčasné (neuvědomělé) ukončení může ovlivnit běh dalších přístrojů jinak, než by si autor přál (a plánoval).
Základní a nejjednodušší časovač je sequencer. Nedefinuje k popsaným principům navíc žádná další pravidla a pracuje jako jednoduchá posloupnost přístrojů. Sequencer použijete v případě, kdy vyžadujete zajištění následnosti nějakých akcí.
Složitější časovač je iterator, který navíc k sekvenčnímu zpracování přístrojů přidává možnost jejich opakování — zacyklení. Iterator na počátku svého časového kroku nejprve vyhodnotí podmínku výskoku (jestli má podřízené přístroje rozběhnout či ne) a případně přístroje postupně aktivuje. Jakmile iterator všechny přístroje obvolá, opět podmínku testuje a v případě jejího nesplnění pokračuje v obvolávání přístrojů znova od začátku. Celkem zřejmé je, že cyklus přístrojů v iteratoru musí nějak (i nepřímo) ovlivňovat podmínku výskoku. Jinak se snadno může stát, že se cyklus stane nekonečným. Iterator je přístroj, který nebudete příliš často používat, jednodušší je vytvářet smyčky přímo programátorským zápisem v těle nějaké procedury.
Poslední časovač je selector. Tento časovač (kromě sekvenčního zpracování přístrojů) umí pracovat s několika sekvencemi najednou a umí jednotlivé sekvence také vypínat a zapínat. Jednotlivé sekvence selectoru jsou nazývány větve (podle podobnosti s živými stromy). Součástí definice větve je podmínka, která určuje, jestli selector přístroje v odpovídající sekvenci v daném časovém kroku rozběhne nebo ne. Selector tak nabízí velmi užitečnou možnost vypínat a zapínat časování mnoha přístrojů najednou. Přístroje zařazené do různých větví selectoru pracují podmíněně podle výsledku vyhodnocení příslušných podmínek. Je-li podmínka splněna, selector přístroje v dané sekvenci aktivuje, v opačném případě nikoli.
Selector budete (měli byste) používat velmi často, protože vypínaní nebo zapínání časování přístrojů může dramaticky zefektivnit běh aplikace. Selector se typicky používá ve vazbě na panely, přesněji na jejich viditelnost na obrazovce. Mnoho panelů obsahuje mnoho přístrojů, které nemusejí být časovány, když panel není zobrazen (grafy pochopitelně musí běžet neustále). Patří sem všechny signalizace stavů nebo zobrazení hodnot bez historie. Pokud tyto přístroje necháte časovat selectorem, který bude mít v podmínce výraz "panel je vidět", budou tyto přístroje časovány jen bude-li panel zobrazen. Uvážíte-li, že panelů bývá často více jak deset, a přístrojů v nich mnohem více jak deset, bude úspora prostředků při vypnutí časování velmi výrazná. Pamatujte na to, že aplikace bude právě tak výkonná a svižná, jak ji naprogramujete.
Všechny tři časovače dohromady umožňují definovat obecný algorimus. Aby to bylo možné, musí mít programátor možnost vytvořit posloupnost (sequencer), vyrobit cyklus (iterator) a mít možnost rozhodování — větvení programu (selector). To časovače umožňují a teoreticky byste s jejich pomocí mohli zapsat jakýkoli program (i když to příliš nedoporučuji, snad jen jako oddychové zpestření).
Trochu netypické a odlišné je časování pomocí procedur nebo přímo časování procedur. Výrazové prostředky zápisu algoritmu v systému Control Web jsou totiž natolik mocné, že umožňují samy o sobě řídit a časovat přístroje. Hlavním aktérem takového časování je vždy příkaz pause, který dokáže po stanovenou dobu vykonávání algoritmu pozdržet. Stanovená doba je výsledkem výpočtu výrazu, a může se proto libovolně měnit. Procedurou proto můžete časovat dynamicky s proměnlivými periodami.
Do procedury můžete zapsat vlastní časovací smyčku, která postupně bude podle různých (vašich) pravidel vykonávat nejrůznější operace. Vezměme následující příklad (zase mírně předbíhám, procedury jsou posány až v kapitole Programování a procedury — OCL, datové elementy v kapitole Datové elementy a výrazy):
var Signal = boolean, false; Period = real, 2; end_var; instrument meter Display; timer = 0.05; ... mode = flow_graph; history = 100; procedure OnActivate(); begin if Signal then Display.SetValue( 75 ); else Display.SetValue( 25 ); end; end_procedure; end_meter; program Rectangle; timer = infinite; procedure OnActivate(); begin loop Signal = true; pause Period / 2; Signal = false; pause Period / 2; end; end_procedure; end_program; end_instrument;
Přístroj Display je časován periodicky a ukazuje v grafu dlouhém 100 vzorků (tedy 5 sekund) vývoj hodnoty proměnné Signal. Důležitější (a zajímavější) je přístroj Rectangle. Tělo jeho procedury OnActivate() obsahuje nekonečnou smyčku (loop..end), kterou přístroj neustále prochází a opakovaně tak vykonává čtyři příkazy: nastaví proměnnou Signal na true, počká 1 sekundu (Period / 2), nastaví proměnnou Signal na false a zase počká 1 sekundu. Vidíte, že se střídavě sekundu co sekundu překlopí proměnná Signal ze stavu aktivního do stavu neaktivního a naopak. Zajímavé je dále:
Ukázka je samozřejmě pouze ukázka, a nepokryje všechny možné varianty, zápis algoritmu je zcela obecná věc. Například jsme se vůbec nepokusili upravit výrazy příkazu pause — tím bychom měnili střídu generovaného signálu. Vyzkoušejte si to.
Časování procedur nejspíše nebude příliš často používáno. Jednak proto, že většinou postačí použití některého jednoduššího způsobu časování a jednak proto, že může být ve složitějších situacích dosti obtížné celý problém včetně komunikací pochopit a analyzovat tak, aby vše pracovalo správně (problém domyšlení všech souvislostí). Na druhé straně, pokud budete procedurou pouze časovat (nebudete v ní komunikovat ani pracovat s daty), můžete velmi jednoduše dosáhnout velmi složitého dynamického časování — podobně jako v naší ukázce.
Nakonec poznámka: příkaz procedury pause není totéž co wait. Příkaz wait čeká na splnění podmínky maximální rychlostí (a navíc beztak neobsahuje žádný časový údaj), a je proto pro časování procedurou nepoužitelný.
Doposud jsme hovořili o obecných principech časování, o principech časování systému Control Web a o způsobu časování přístrojů. Ve všech případech jsme hovořili (abstraktně) o "systému, který časuje" nebo o "jádru, které obvolává přístroje". Je to zatím tajemná část aplikace, která je odpovědná za správnou komunikaci, správný běh přístrojů a správnou synchronizaci dat. Dále ji budeme nazývat jádro, které spolu s časovacím tokem odpovídá za veškeré časování a aktivitu aplikace.
Na rozdíl od časovacího toku pracuje jádro ve výkonném prováděcím toku, a je proto postaveno na roveň všem ostatním normálním tokům přítomným v operačním systému. Bez zvýšení priority celého procesu tedy veškeré přístroje, jejich kreslení a reakce na události, ovladače a komunikace pracují konkurenčně se zbytkem systému. To v principu nijak nevadí, protože čas, který přístroje spotřebují, žádná priorita procesu neovlivní.
Výkonný časovací tok je v systému Control Web jeden společný pro všechny spuštěné moduly (pokud jich je více). I zde je v principu jedno, jestli přístroje různých modulů pracují v jednom nebo více tocích, neboť souhrnný jimi spotřebovaný čas se rozdělením do více toků nijak nezmenší. Naopak, jeden tok znamená menší režii operačního systému a lepší vzájemné ovlivňování chodu přístrojů z různých modulů, což v důsledku vyúsťuje v hladší běh a lepší pocit z ovládání.
V oddíle o časování přístrojů byl pojem časový krok používán ve významu jednoho elementárního spuštění přístroje. V oddíle Časování zevnitř bude používán druhý význam tohoto pojmu — časový krok bude jeden elementární běh jádra systému, během něhož se uskuteční vstupní i výstupní komunikace a provedou časové kroky (už je tu opět první význam) přístrojů, které měly být spuštěny. Pro větší bezpečnost budu používat (kde to jen půjde) rozlišení "časový krok jádra" a "časový krok přístroje".
Časový krok jádra může být v různých okamžicích aplikace různě dlouhý — rozdíly mohou dosahovat až několika řádů (!). Vše závisí pouze na aktuálních akcích (komunikacích především), které se v kroku provádějí. Ve většině aplikací se dokonce délky kroků střídají — zpravidla nejprve přijde krok dlouhý, způsobený periodickými časovači (v něm se většinou komunikuje), a po něm následuje krok krátký, ve kterém se "dodělávají" přístroje, které byly aktivovány událostmi z přístrojů v kroku dlouhém (krátký krok většinou nekomunikuje, proto je krátký).
Délka časového kroku jádra je samozřejmě důležitý informační údaj. Control Web proto změřené údaje uchovává a zobrazuje je v "Okně časování". Délka časového kroku jádra již byla jednou přesně definována (při popisu údaje "Celkový spotřebovaný čas" "Okna časování"), nebylo však řečeno, že to je délka časového kroku. Proto délku definuji znovu — délka časového kroku jádra je interval mezi probuzením časovacího toku a dalším testem na případný možný jeho spánek (čekání na další krok). Součástí této délky je samotný běh jádra, běh přístrojů, veškeré režie, komunikace a případně vyprazdňování vstupní fronty událostí. Sečtené délky jednotlivých časových kroků jádra dohromady dávají "Celkový spotřebovaný čas".
"Okno časování" zobrazuje o časovém kroku jádra celou řadu informací:
Popisované údaje jsou navzájem svázány i jinak.
Například:
Nastane-li na konci jednoho běhu časovacího toku situace, kdy je nově vypočtěný okamžik vzbuzení toku (neboli "Čas aplikace") pozadu za systémovým časem, říkáme, že je aplikace ve skluzu. Skluz vznikne tehdy, trvá-li některý z časových kroků jádra příliš dlouho. Časovací tok při skluzu možnou časovou rezervu nejen vyčerpá, ale také ji i překročí a spotřebuje část času, který již měl patřit novému časovému kroku. Aplikace ve skluzu nemůže dodržet správné intervaly period — příliš dlouhé trvání časového kroku jádra jí v tom brání.
Skluz je normální součástí běhu aplikace, a téměř v každé se občas objeví. Systém se snaží skluz vyrovnat, snaží se "dohnat" skutečný čas, pracuje "zvýšeným úsilím" a jednotlivé zpožděné časové kroky jádra uskutečňuje tak rychle, jak to jen jde. Skluz bývá okamžitou událostí, která většinou rychle pomine, a dohánění proto většinou splní svůj účel — skluz se vyrovná. Nicméně, chybně navržená aplikace nemá rezervu, časové kroky trvají soustavně déle, než je v aplikaci naprogramováno, a ani dohánění tudíž situaci nespraví. Taková aplikace má nereálné požadavky a neměla by být provozována.
Skluz by bylo možné v okamžiku jeho vzniku rozeznat v časovacím okně tak, že by součet okamžité délky kroku a okamžité rezervy překročil délku nejmenšího časového kroku. Jinými slovy, krok jádra by byl delší, než měl být. V okně časování se okamžitě skluz projeví také na dosaženém času aplikace, který se začne zpožďovat za časem od rozběhu. V hrubém přiblížení je možné pomocí podílu údaje "Rozdíl" a délky nejkratšího kroku zjistit, kolik časových kroků jádra chybí, kolik jich systém bude muset provést, aby skluz vyrovnal. Skluz také způsobí vynulování okamžité rezervy, veškerý čas bude spotřebován na běh aplikace. Při skluzu se situace může dále vyvíjet třemi způsoby:
Je-li skluz delší než nejkratší délka kroku přístroje, nemůže nastat první situace, a systém musí skluz vyrovnat pomocí několika časových kroků jádra. Dohánějící jádro tudíž běží rychleji, takže také rychleji časuje jednotlivé přístroje. Během skluzu proto systém nezachovává délky period. Je to nutné opatření, protože byla-li perioda jednou delší (v okamžiku vzniku skluzu), musí být jedna, nebo více dalších period kratší, aby další časové kroky přístroje (po vyrovnání skluzu) nastaly v původních teoretických vypočítaných okamžicích. Pokud se tento mechanizmus zdá býti podivným, je to jen další argument pro tvrzení, že aplikace musí být navržena tak, aby ke skluzu nedocházelo. Když už skluz jednou vznikne, tak je pozdě lamentovat, a nezbývá nic jiného, než se ze skluzu zotavit doháněním.
Skluz vznikne v okamžiku, kdy se některý časový krok jádra protáhne, a nestihne se kvůli tomu časový krok přístroje s nejkratší periodou časování. Prodloužení kroku jádra může být i takové, že utečou časové kroky přístrojů s delší periodou. Control Web proto rozeznává skluz aplikace a skluz přístroje. Skluz aplikace vznikne, když se alespoň jeden z přístrojů dostane do skluzu. Aplikační skluz je důležitější, protože zahrnuje všechny přístroje, a citlivější, neboť registruje i přístroj s nejkratším časovým krokem. Některé přístroje se do skluzu nemusejí vůbec dostat, je-li například přístroj časován s periodou 86 400 sekund (1 den), postihne jej skluz jen s malou pravděpodobností (skluz by musel vzniknout těsně před okamžikem aktivace tohoto přístroje).
Skluz přístroje i aplikace je možné detekovat pomocí systémové událostní procedury OnActivate( ActivateMode : cardinal ) (popis programování procedur obsahuje kapitola Programování a procedury — OCL:
procedure OnActivate( ActivateMode : cardinal ); begin if bitget( ActivateMode, 8 ) = 1 then ... (* aplikace je ve skluzu *) end; if bitget( ActivateMode, 5 ) = 1 then ... (* přístroj je ve skluzu *) end; end_procedure;
Parametr ActivateMode obsahuje v jednotlivých bitech i různé jiné informace (více je o proceduře OnActivate napsáno v kapitole Programování a procedury — OCL, nás momentálně zajímá jen bit 8, který nese informaci o skluzu aplikace a bit 5 s informací o skluzu přístroje.
Pracuje-li aplikace ve skluzu, nemůže až do okamžiku jeho zániku přesně plnit časovací kritéria. Časové kroky přístrojů se zpožďují vůči teoretickým hodnotám a periody jsou delší než by měly být. Dlouhodobý skluz je v rozporu s požadavky kladenými na aplikace reálného času — aplikace již nemá rezervu, kterou by mohla použít pro překlenutí potenciálních časovacích potíží. O takové situaci systém Control Web musí uživatele informovat, protože aplikace nepracuje podle představ jeho návrhu. Dlouhodobý skluz je považován za chybu časování, která je oznámena speciálním dialogovým oknem:
Chyba časování
a je zapsána do záložky "Chybové zprávy" "Okna zpráv". Systém chybu časování hlásí v případě, že po určitou dobu skluz aplikace neklesl. Prodleva hlášení této chyby je nastavitelná pomocí parametru time_error_limit v aplikační sekci settings v rozmezí od 0 do infinite, přičemž 0 znamená okamžité hlášení chyby, jakmile vznikne skluz, a infinite potlačení hlášení chyby časování (systém chybu časování nikdy nenahlásí).
V aplikacích pevného reálného času je chyba časování považována za natolik závažnou, že při jejím objevení (po uplynutí intervalu vymezeného parametrem time_error_limit) dojde k chybě běhu a systém Control Web modul zastaví.
Aplikace může být navržena z hlediska skluzu různými způsoby:
Pasivní aplikace se nemohou skluzu bránit, a neměly by proto nikdy běžet v režimu pevného reálného času.
Občas se přihodí, že aplikace pracuje "na hraně" mezi prvním a druhým případem. Jeden z projevů těchto aplikací je celkem matoucí. Pokud aplikace spustíte bez pevného reálného času, dostane se ihned po startu do skluzu, a již se z něj nedostane. Patří tedy do skupiny první. Pokud aplikaci spustíte v režimu pevného reálného času, aplikace se při startu do skluzu nedostane a pracuje jako aplikace ze skupiny druhé. Matení spočívá ve faktu, že se zdá, že pevný reálný čas aplikaci nějak pomohl a že aplikace lépe běží. Není to pravda, naopak, zapnutí pevného reálného času (a vymizení skluzu) maskuje potíže a vytváří menší časovanou nálož. Velký nárůst skluzu při startu aplikace je způsoben velkým množstvím požadavků na kreslení — při startu se celá aplikace musí nakreslit. Víme již, že kreslení probíhá prostřednictvím fronty zpráv, kterou operační systém plní a aplikace vyprazdňuje — dokresluje. Toto prvotní překreslení může trvat relativně dlouho a může proto způsobit vznik skluzu. Zapnutí pevného reálného času zablokuje zpracování vstupní fronty, neobjeví se zdržení a skluz nevznikne. Časovaná nálož se projeví okamžitě, kdy se aplikace bude muset celá najednou překreslit — najednou odkryjete celou její plochu nebo operační systém překreslí všechna okna (to občas dělává). Vznikne kopie situace při startu a aplikace se dostane do skluzu, ze kterého se nemusí být schopna dostat. Aplikace takto vytvořená, používající pevný reálný čas pro "zodolnění" proti potížím, je špatná.
Každý jeden časový krok jádra musí zajistit několik spolu souvisejících činností.
Popsané úkoly — aktivaci přístrojů a komunikaci — jádro plní podle jednoznačně definovaných jednoduchých protokolů — na straně ovladačů je protokol zapouzdřen do několika procedur (podrobný popis viz kapitola Komunikace, ovladače a kanály) jejich rozhraní, na straně přístrojů je protokol skrytý uvnitř systému a je realizován pomocí metod objektů přístrojů. Jádro pracuje jako realizátor příkazů časovacího toku, který zprostředkovává vzájemnou komunikaci mezi aplikací (přístroji) a ovladači (technologií):
Schéma časování
Časovací tok před začátkem časového kroku připraví seznam přístrojů, které se mají dostat ke slovu, a rozběhne jádro. Jádro začne realizovat své činnosti a cyklicky pracuje tak dlouho, dokud neuspokojí všechny požadavky připravených přístrojů. V prvém přiblížení je jasné, že jádro musí:
Příprava dat je fáze, ve které jádro spolupracuje s přístroji. Přístroje, které neobsahují procedury, jsou schopny jádru informace o všech kanálech, které potřebují, poskytnout najednou. Přístroje s procedurami (a časovače) toho schopny nejsou, a jak uvidíme později, pracují komplikovaněji.
Druhá fáze — měření kanálů — následuje bezprostředně po fázi první. Jádro nyní spolupracuje s ovladači, kterým nejdříve oznámí všechny kanály, které si přeje změřit. Následuje krok potvrzovací, kdy jádro postupně pro všechny kanály zjišťuje, jestli je ovladač úspěšně změřil. Odpoví-li ovladač kladně (kanál změřil), uschová jádro změřenou hodnotu ve své datové oblasti. Odpoví-li ovladač záporně, jádro si zapamatuje, že kanál ještě nebyl změřen. Potvrzování dokončení měření skončí ve chvíli, kdy se jádro zeptá ovladače na poslední požadovaný kanál.
Běh jádra se může po dokončení potvrzování ubírat dvěma cestami:
Čekání na dokončení měření je důležité, neboť bez něj by přístroje pracovaly se špatnými — starými hodnotami kanálů. Jádro musí počkat, až ovladač data poskytne. Zpoždění způsobuje komunikace ovladače s měřicím zařízením (snímačem). Jak uvidíte v kapitole Komunikace, ovladače a kanály, mohou být délky komunikací různých ovladačů velmi odlišné. Měřicí karta zasunutá přímo do počítače bude data poskytovat mnohem rychleji než průmyslový automat komunikující po sériové lince.
V průběhu čekání na dokončení měření se jádro chová pasivně. Veškerá aktivita leží na bedrech ovladače, který sám musí v případě doměření systém informovat. (prostředky, které ovladač musí v takovém případě použít popisuje kapitola Komunikace, ovladače a kanály). Jinými slovy, jádro během čekání nic nedělá, nespotřebovává žádné systémové prostředky, a teprve když mu ovladač oznámí, že změřil data, probudí se a zpracuje doměřené kanály.
Daří-li se komunikovat, je všechno v pořádku. Ovladač po určité době všechna změřená data poskytne jádru a to pokračuje aktivací přístrojů. Komunikace se však může nedařit. Mohou se vyskytnout potíže na komunikační lince, průmyslový automat selže, případně pouze vypnou v technologii proud. Ovladač není schopen data jádru předat (nemůže žádná změřit), jádro nemůže pokračovat a aplikace přestává vizualizovat a řídit. Systém sice reaguje na vstupní události (operace s myší a klávesnicí), ale aplikace stojí. Aby se předešlo popsanému zastavení aplikace, definuje Control Web v aplikaci nejdelší povolenou dobu čekání na měření — parametr input_timeout aplikační sekce settings. Jádro nikdy nečeká na odezvy ovladačů déle, než má tímto parametrem povoleno. Celý postup jádra při měření kanálů ukazuje obrázek:
Měření kanálů
Komunikační prodleva samozřejmě může sloužit i k jiným účelům než je ochrana před nekončícím měřením. S její pomocí můžete efektivně omezovat nejdelší dobu komunikace, například v aplikacích, kde je řízení s použitím starých hodnot menším zlem, než řízení zpožděné. Délka prodlevy je stavitelná od nuly (jádro nikdy nečeká a okamžitě po zapsání požadavků do ovladače pokračuje aktivací přístrojů bez ohledu na výsledek měření) až do "nekonečna" (infinite), kdy jádro vždy čeká až do okamžiku doměření posledního kanálu. Hodnota 0 znamená minimální zdržení běhu časového kroku jádra a vysokou pravděpodobnost práce se starými hodnotami kanálů, hodnota nekonečno znamená naopak stoprocentní jistotu aktuálnosti dat za cenu možného velmi dlouhého čekání na výsledek.
Je vhodné ještě chvíli zůstat u zdůrazněných slov předchozího odstavce — nejdelší doba komunikace. Ve většině případů jádro od ovladačů dostane změřená data dříve, než uplyne definovaná prodleva. Jádro pozná, že již byly všechny kanály korektně předány, a čekání ukončí. Definovaná prodleva tedy stanovuje horní mez, která většinou není dosažena, ale která není nikdy překročena.
Nastane-li situace, kdy se ovladači nepodaří požadované kanály změřit do vypršení prodlevy, pokračuje jádro dále. Ovladač přitom stále pracuje (na pozadí), komunikuje a stále je schopen poskytovat výsledky. Jádro v takovém případě informace od ovladačů pouze registruje a při vhodné příležitosti (buď na konci časového kroku jádra nebo při měření kanálů nově požadovaných při postupné aktivaci přístroje — viz níže) je zpracuje. Ovladač tedy může komunikovat svou rychlostí a jádro jeho výsledky použije při nejbližší volné chvilce.
Ne všechny kanály jsou stejně důležité. Některé musí být skutečně vždy změřeny, jiné klidně mohou zastarat. Vzniká problém, jak prodlevu nastavit, aby vyhověla pro všechny případy. Řešení problému je velmi rychlé — s jednou hodnotou prodlevy nevystačíte. Systém Control Web proto umožnuje u každého kanálu prodlevu definovat samostatně. Kanály, které se musejí vždy změřit, budou mít prodlevu větší, kanály, na kterých "nezáleží" menší (nebo nulovou). Definice prodlevy přímo u kanálu má přednost před definicí v sekci settings. To znamená, že kanál použije buď prodlevu svou (je-li definovaná), nebo prodlevu systémovou (kanál je definován bez prodlevy). V nejširším pojetí se nabízejí dvě základní strategie definic prodlev:
Sejdou-li se v jednom časovém kroku jádra kanály s různými komunikačními prodlevami, vybere jádro pro čekání prodlevu nejdelší. Uvážíme-li, že délka prodlevy u kanálu vyjadřuje přibližně jeho důležitost, je to výběr logický. Přístroje jsou v časovém kroku jádra aktivovány nejpozději tehdy, je-li vyčerpána největší možná komunikační prodleva.
Již víte, že prodlevu je možné nastavit globálně pro všechny kanály nebo jednotlivě pro vybrané kanály. Kromě těchto způsobů může vaše aplikace použít dynamického řízení komunikačních prodlev — pomocí atributu timeout (o atributech pojednává kapitola Datové elementy a výrazy). Zápisem hodnoty prodlevy do atributu okamžite upravíte chování měření kanálu (okamžitě od dalšího následujího měření). V běžných aplikacích pravděpodobně vystačíte se statickými definicemi prodlev, nicméně i tak máte přesné dynamické řízení stále k dispozici.
Poslední způsob čekání na výsledek komunikace, který systém poskytuje, je nejvíce expertní a bude používán velmi výjimečně — čekání s využitím stavových informací kanálu. Toto čekání je uskutečnitelné pouze tehdy, má-li kanál nastavenu nulovou prodlevu (tehdy na jeho doměření jádro nečeká). Aplikace může po vzniku požadavku sledovat, jak se mění stav komunikace (pomocí atributu status) a v okamžiku jejího dokončení pokračovat dále.
S prodlevami a měřením kanálů souvisí jedna potenciálně nepříjemná věc. Využití prodlev v aplikaci mlčky předpokládá, že použitý ovladač odpovídá specifikacím a správně obsluhuje komunikaci svých kanálů. Ovladače specifikacím samozřejmě musí odpovídat (specifikace nejsou nijak komplikované) a drtivá většina jim také odpovídá. Nicméně, ovladač může být buď z neznalosti nebo ze spekulativních důvodů napsán chybně tak, že simuluje okamžité změření hodnoty. To pochopitelně znamená, že jádro na fyzické změření nikdy nepočká. Nemůže, neboť je ovladačem obelháno. O této chybě ovladače se můžete více dočíst v kapitole Komunikace, ovladače a kanály.
Systém Control Web za běhu aplikace o komunikaci průběžně shromažďuje různá statistická data. Takto získané údaje je možné prohlédnout v "Okně časování", přičemž souhrnné údaje o komunikaci obsahuje záložka "Ovladače" a údaje o jednotlivých samostatných kanálech záložka "Kanály". O průběhu komunikace vypovídají následující údaje:
Kromě údajů rozdělených podle směru komunikace záložka obsahuje také časové informace o komunikaci:
Připomínám, že údaje v této záložce platí souhrnně pro všechny kanály vybraného ovladače. Proto například "Průměrná doba komunikace" představuje pouze orientační údaj. Přesné (neprůměrované) hodnoty jsou k dispozici v údajích záložky "Kanály".
O atributech, na které se text odkazuje, se můžete dočíst také v kapitole Datové elementy a výrazy.
Jakmile jádro úspěšně dokončí měření vstupních kanálů, případně jakmile uplyne komunikační prodleva, přijdou na řadu přístroje — přesněji jejich aktivace. Aktivace přístroje znamená, že přístroj provede svůj časový krok. Aktivace přístrojů není ovlivňována žádnými speciálními parametry (tak jak bylo například ovlivňováno měření prodlevami) a vše je řízeno jen postupnou interakcí jádra a samotného přístroje.
Přístroje jsou aktivovány jádrem sekvenčně, přičemž není možné, aby se přístroj aktivoval dříve, než předcházející přístroj dobrovolně ukončí svůj časový krok. Toto pravidlo zamezuje vzájemnému skrytému (a tudíž špatnému, protože neovlivnitelnému) paralelnímu běhu přístrojů. Již bylo naznačeno, že přístroje mohou být dvojí: "jednoduché", které vědí jaké vstupní kanály chtějí, a "komplikované" (lepší by bylo říci promyšlené), které to nevědí, a musejí měřené kanály postupně zjišťovat. Postupné zjišťování informací o požadovaných kanálech je přímým důsledkem optimalizace komunikací v přístrojích — optimalizace vám umožňuje v jedné proceduře jednou tisíc kanálů měřit a podruhé zase neměřit. "Komplikované" přístroje jsou všechny přístroje s nějakou procedurou a časovače. "Jednoduché" přístroje jsou všechny ostatní. Podle druhu přístroje jádro při aktivaci postupuje následovně:
Z druhého bodu ("komplikované" přístroje) vyplývá několik důležitých skutečností:
Souhrnně aktivaci jednoho přístroje demonstruje následující obrázek:
Aktivace přístroje
Stejně jako o časování, ovladačích a kanálech aplikace i o přístrojích shromažďuje statistická data. V "Okně časování" je přístrojům věnována samostatná záložka, z níž již část byla popsána (přímo v oddíle "Okno časování"). Zbývající zobrazené údaje jsou:
Zápisem výsledků shromážděných ve výstupních kanálech do ovladačů časový krok jádra končí (pokud není co zapisovat, skončí dříve). Víme již také, že výstupní kanály mohou být zapsány do technologie dříve, v situaci, kdy jsou přístroje aktivovány přerušovaně. Při postupném zápisu výstupních kanálů můžete odhalit jednu z odlišností v chování vstupních a výstupních kanálů.
Vstupní kanál nikdy není v jednom časovém kroku měřen vícekrát. Je to dáno tím, že vstupní kanál reprezetuje data, která primárně vznikají a existují v technologii. Pokud se daří měřit vstupní kanály určitou rychlostí, nemá smysl se pokoušet vyšším počtem požadavků získat další hodnoty. Technologie a ovladač data rychleji neposkytnou a v mezičase si je nevymyslí. Jádro pracuje s obrazem skutečné veličiny, který je po cestě několikrát časově převzorkován a sáhodlouze komunikován. Bezpečnější je jednou získanou hodnotu uschovat a v jednom časovém kroku ji již neměnit. Další hodnota nemusí být dostupná.
Výstupní kanál naopak primárně vzniká a existuje v aplikaci, zatímco technologie pracuje s obrazem. Výstupní kanál proto musí být do technologie zapisován při každé změně. To znamená, že výstupní kanál (na rozdíl od vstupního) může být během jednoho časového kroku komunikován vícekrát. Sáhodlouhá komunikace a časové převzorkování existují samozřejmě také, ale práci s nimi má příjemce dat, nikoli jádro.
Rozdíl mezi vstupním a výstupním kanálem je možné popsat také jazykem teorie systémů — měření je komunikace klient — server, kdy klient — jádro žádá ovladač — server o data z technologie; zatímco zápis dat probíhá plně v režii jádra — neexistuje žádný server ani klient, ovladač a technologie pouze vykonávají co se jim přikáže — zapisující jádro je systém řídící jiné hierachicky nižší systémy. Pozoruhodné je, že dva natolik diametrálně odlišné přístupy je možné skloubit do jednoho principiálního schématu komunikace a čekání na výsledek. Na první pohled se vůbec nezdá, jaké (poněkud zbytečně akademické) rozebrání komunikací odhalí rozdíly.
Postup jádra při zápisu výstupních hodnot je tedy identický s postupem použitým při měření. Jádro nejprve ovladači oznámí hodnoty všech kanálů, které si přeje zapsat do technologie, poté se s ovladačem dohaduje, zdali již byly kanály zapsány, a nakonec případně čeká do vypršení komunikační prodlevy na potvrzení zápisu. Globální prodleva zápisu kanálů se nastavuje v aplikační sekci settings a jmenuje se output_timeout. Stejně jako vstupní kanály mohou mít i výstupní kanály ve své definici uvedenu specifickou hodnotu prodlevy, která má před globálním nastavením přednost. Výstupní kanály také mají atributy timeout i status, pomocí kterých je možné zápisy detailně řídit.
Prodleva komunikací výstupních kanálů bude většinou nevyužita, neboť princip výstupních kanálů (vznikají v aplikaci) nenutí vždy ověřovat, jestli se zápis zdařil.
Zatím nebyly v této kapitole ani jednou zmíněny obousměrné kanály. Nyní, když již víte, co se děje během časového kroku jádra, je možné vysvětlit potenciální nebezpečí použití těchto kanálů — komunikační překryvy.
Obousměrný kanál je kanál, který je při použití pro vstup dat měřen a při použití pro výstup zapisován. Jádro registruje obousměrný kanál jako jeden prvek, má pro něj tudíž vyhrazen prostor jednoho datového elementu (to je nutné, neboť použití dvou míst v paměti by vedlo na dvojici kanálů — jeden vstupní a druhý výstupní). Všechny zápisy a měření hodnot procházejí tímto jedním paměťovým místem. Uvažme následující situaci:
Na konci postupu bude ve vnitřních datových strukturách (a tím i v aplikaci!) hodnota změřená, ale zastaralá (neboť do technologie proklouzla hodnota zapsaná). Navíc přístroj, který do kanálu zapsal, bude žít v přesvědčení, že jeho vlastní vnitřní hodnota (původně zapsaná do kanálu) je stejná, jako obsah kanálu.
Uvedený postup není jediný, který vede k překryvu. Zkuste si také v popsaném mechanizmu rozvinout slovo "přístroje" do jednotlivých skutečných přístrojů a sledovat, jakou skutečnou hodnotu kanálu kdy který přístroj použije. Uvážíte-li, že podobné potíže může mít s obsluhou obousměrného kanálu i ovladač (ten zase v různých okamžicích dostává hodnoty a požadavky z jádra i z technologie), vznikne celkem znamenitý zmatek.
Nelze jednoznačně říci, že použití obousměrných kanálů vede vždy k popsaným potížím. Jejich použití není chybou. Kladou však dosti značné nároky na návrh, promyšlení a v neposlední řadě také testování aplikace. V mnoha případech překryvy vůbec nemohou vzniknout, neboť aplikace data komunikuje řízeně (sama si ovládá, kdy se co zapíše a změří). Záleží tedy na způsobu použití obousměrných kanálů. Je možné vyslovit pouze jediné doporučení — pokud vystačíte jen se vstupními a výstupními kanály, nepoužívejte kanály obousměrné. Nasazení obousměrných kanálů by mělo zůstat v záloze až do okamžiku, kdy bude jejich použití nevyhnutelné.
Mezi výrazové prostředky zápisu algoritmu v procedurách patří několik příkazů, které v běžných programovacích jazycích nenajdete. S jejich pomocí je možné řídit běh aplikace nebo časovat přístroje. Jiný speciální prostředek — atributy kanálů — umožňují získávat informace o komunikaci. Kombinací obou prvků — procedur a atributů — vznikne velmi mocná možnost detailního řízení komunikace. Upozorňuji, že tak jak je řízení komunikace mocný nástroj, je to také nástroj pokročilý. Pokud momentálně nepotřebujete v aplikaci uchopit komunikaci zcela přesně do svých rukou a doposud popsané mechanizmy vám nadmíru stačí, klidně tuto sekci přeskočte, a vraťte se k ní kdykoli uznáte za potřebné, či vhodné.
Pro řízenou komunikaci je velmi důležitý způsob použití procedury. Všechno, co bude v této sekci vysvětlováno, platí pouze pro procedury aktivované jádrem. To je procedura OnActivate a případně procedury, které "se vyvázaly" použitím přerušovacího příkazu z volání jiného přístroje nebo z volání reagujícího na nějakou událost.
Procedury, které jsou volány jiným přístrojem nebo systémem při vzniku události (například OnMouseDown), je pro popisované použití nejdříve nutné rozběhnout samostatně. Standardně je takové "vyvázání se" ve všech procedurách kromě OnActivate zakázáno (parametr independent_procedure_execution sekce settings je false, a jeho povolování ani není bez pečlivého promyšlení doporučeno. Nicméně, přejete-li si skutečně komunikaci řídit i z jiné procedury, než je OnActivate, je třeba tento parametr nastavit na hodnotu true.
Pro přesné řízení komunikace se v procedurách používají:
Připomeňme si, že příkazy yield, pause a wait přerušují proceduru a ukončují časový krok přístroje. To je velmi důležitý fakt, který je nutnou podmínkou možnosti řízení komunikace v procedurách. Přístroj bude po vykonání těchto příkazů aktivován opětovně až v následujícím časovém kroku jádra, tedy v situaci, kdy již vstupní kanály mohou obsahovat nové hodnoty. Na přerušovací příkazy je proto možné pohlížet jako na příkazy vyvolávající komunikaci. Není to příliš přesné, neboť dochází k převrácení příčiny a následku, ale je to názorné — přerušení umožňuje jádru pokračovat, takže je možné zahájit další časový krok jádra a v něm provést novou komunikaci, jejíž výsledky přerušený přístroj použije. (Z uvedených tvrzení také vyplývá, že pro řízení komunikace není možné použít mechanizmu přerušované aktivace, který jednak není možné ovlivňovat a jednak nedokáže nikdy změřit novou hodnotu vstupního kanálu.)
Mechanizmus postupné aktivace zaručuje, že momentálně probíhající kód procedury bude pracovat s aktuálními hodnotami vstupních kanálů. Přípravu a měření těchto kanálů vždy uskutečňuje jádro automaticky bez ohledu na nějaké ruční řízení. Řízení komunikací se proto týká hlavně zápisů, tedy výstupních kanálů. Řízení komunikace však automaticky ovlivňuje i kanály vstupní. Přerušovaná aktivace zajistí, že před pokračováním běhu procedury přerušené některým z přerušovacích příkazů budou změřeny všechny vstupní kanály, které procedura obsahuje až do místa výskytu dalšího přerušovacího příkazu nebo místa nejistoty — podmíněného příkazu (i podmínky skryté v příkazech cyklu).
Běh procedury a místa měření vstupních kanálů je nejjednodušší demonstrovat na příkladu (příklad obsahuje rozličné varianty, a ač je krátký, je nabitý informacemi):
procedure OnActivate(); begin (* před první aktivací jádro změřilo kanály 1, 2 a 3. Více změřit nemohlo, protože nemůže předvídat výsledek příkazu if channel3 = 100. *) a = channel1 + channel2; (* Procedura při první aktivaci běží až k místu podmínky, kterou vyhodnotí. Načež aktivaci přeruší a požádá jádro o změření kanálů 1, 3 a 4 (měl-li kanál 3 hodnotu 100) nebo kanálu 5 (neměl-li kanál 3 hodnotu 100). Kanály 6 a 7 nejsou měřeny, protože jsou za přerušovacími příkazy. *) if channel3 = 100 then (* Jádro změřilo kanál 4, kanály 1 a 3 již mají pro tento krok jádra platnou hodnotu a nebyly proto znova měřeny. Procedura běží až k příkazu yield, který její běh přeruší. *) a = channel1 + channel3 + channel4; (* Yield způsobí přerušení běhu procedury a jádro automaticky (ve spolupráci s přístrojem) změří kanály 1, 2, 3 a 6. Všechny tyto kanály mohou být změřeny najednou, neboť mezi nimi není žádný nejistý nebo přerušovací příkaz. *) yield; (* Kanál 6 byl změřen v této proceduře poprvé, kanály 1, 2 a 3 již podruhé. *) a = channel1 + channel6; else a = channel5; (* Yield způsobí přerušení běhu procedury a jádro automaticky (ve spolupráci s přístrojem) změří kanály 1, 2, 3 a 7. Všechny tyto kanály mohou být změřeny najednou, neboť mezi nimi není žádný nejistý nebo přerušovací příkaz. *) yield; (* Kanál 6 byl změřen v této proceduře poprvé, kanály 1, 2 a 3 již podruhé. Kanál 3 bude změřen jednou, a použit dvakrát (podruhé při prvním testu příkazu wait. *) a = channel1 + channel3 + channel7; end; a = channel2; (* Wait pracuje cyklicky tak dlouho, dokud kanál 3 nemá hodnotu 100. Wait sám vnitřně přerušuje běh procedury a vynucuje si tak měření kanálu 3. Poslední běh příkazu wait (kanál nabude hodnoty 100) způsobí pouze přerušení aktivace (ne přerušení běhu procedury), v rámci něhož je potřetí v této proceduře změřen kanál 1. *) wait channel3 = 100; a = channel1; end_procedure;
Příkazy yield, pause a wait provádějí podobné činnosti a v principu je možné jejich veškerou činnost zapsat pouze s použitím příkazu pause. Uvedená ukázka je teoretická (i když by pracovala) a slouží pouze k lepšímu pochopení činnosti jednotlivých příkazů:
(* yield *) ... pause 0; ... (* wait condition *) ... while not condition do yield; end; ... (* nebo *) ... while not condition do pause 0; end; ...
Řízenou komunikaci je možné rozdělit do několika kroků:
Příprava kanálů je velmi jednoduchá. Do výstupních kanálů jednoduše zapíšete požadovanou hodnotu, vstupní kanály připravíte jejich použitím v nějakém výraze (stačí jednoduché přiřazení). Výstupní kanály je třeba nastavit před přerušením procedury, vstupní kanály se během přerušení změří a jejich příprava tedy spočívá v jejich zapsání někam za příkaz přerušení:
channel1 = 10; yield; a = channel2;
V ukázce je procedura přerušena příkazem yield, zapsán je připravený výstupní kanál channel1 a změřen je připravený vstupní kanál 2. Zároveň vidíte, že druhý krok řízení komunikace — přerušení aktivace — je také velice jednoduchý.
Poslední fáze komunikace je čekání na její výsledek. V principu je možné buď čekání úplně vypustit (například pokud komunikujete s kartou v počítači), nebo použít čekání systémové (bude za vás čekat jádro), nebo čekat na výsledek programově přímo v proceduře, nebo použít kombinace čekání systémového a programového:
channel1:timeout = 2; yield; a = channel1; channel1:timeout = 0;
Kanál channel1 bude změřen, přičemž čekání na výsledek komunikace se protáhne nejdéle na dvě sekundy. Pokud se během těchto dvou sekund kanál nepodaří změřit, zůstane jeho hodnota nezměněna.
(* společná část vyvolávající komunikaci *) channel1:timeout = 0; yield; a = channel1; (* 1. čekání s využitím bitu stGetWaitACK[3] atributu status *) wait bitget( channel1:status, 3 ) = 0; (* nebo *) (* 2. čekání s využitím bitu stGetACKed[8] atributu status *) wait bitget( channel1:status, 8 ) = 1; (* nebo *) (* 3. čekání s využitím bitů stGetACKed[8] a stGetError[9] atributu status *) wait ( bitget( channel1:status, 8 ) = 1 ) or ( bitget( channel1:status, 9 ) = 1 );
Čekání 1. a 3. jsou totožná, protože jádro zaručuje, že při nastavení bitu stGetACKed nebo stGetError vynuluje bit stGetWaitACK. Čekání druhé nepodchycuje stav, kdy při komunikaci vznikne chyba, a skončí tedy jen v okamžiku, kdy je kanál skutečně správně přečten. Status kanálu obsahuje také bit stGetTimeout, který bude v našem případě vždy nastaven, neboť jádro v důsledku nastavení prodlevy na 0 nikdy nepočká — prodleva (nulová) okamžitě vyprší.
Ukázka čekání s využitím atributu value_set:
channel1:timeout = 0; channel1:value_set = false; yield; a = channel1; wait channel1:value_set;
Atribut value_set systém pouze nastavuje, takže je nutné jej před začátkem komunikace nastavit na hodnotu false. Čekání skončí v případě, že se úspěšně podaří hodnotu změřit, jedná se tedy o ekvivalent druhého čekání z předchozí ukázky.
Popsané programové způsoby čekání nijak nepodchycují délku komunikace. To může být nedostatek, občas je vhodné čekání ukončit, trvá-li již příliš dlouho. Možností, jak zabudovat do čekání prodlevu je několik. Ukázka nabízí jeden z nich:
start = run_time_msec; channel1:timeout = 0; yield; a = channel1; wait ( bitget( channel1:status, 3 ) = 0 ) or ( run_time_msec - start > 2000 );
Systémová proměnná run_time_msec obsahuje počet milisekund od startu aplikace, naše ukázka proto čeká na dokončení komunikace nejdéle dvě sekundy.
Jak nakonec procedura bude čekat, jestli pomocí jádra (s minimální spotřebou času, ale bez aktivací přístrojů), nebo příkazem wait (s velkou spotřebou času, ale s normálním během ostatních přístrojů) záleží pouze na vás — tvůrcích aplikace.
Ukažme si, jak může kombinované čekání vypadat:
channel1:timeout = 0.2; channel1:value_set = false; attempts = 5; loop yield; a = channel1; if channel1:value_set then exit; end; attempts = attempts - 1; if attempts = 0 then exit; end; end;
Ukázka čeká pasivně vždy 200 milisekund. Podaří-li se kanál změřit, opouští se měřicí cyklus. V opačném případě (například při chybě komunikace) se pokračuje v měření a to až čtyřikrát.
Ukázky byly sestaveny s použitím vstupních kanálů. Výstupní kanály se obsluhují v principu shodně s jednou výjimkou — u výstupního kanálu nemá smysl používat atribut value_set, neboť během zápisu ke změně hodnoty kanálu nedochází. Druhá metoda používající atribut status je však použitelná bez výhrad, pouze se nesmí zapomenout, že bity signalizující stav zápisu mají jiná jména i čísla — stSetWaitACK (1), stSetACKed (5), stSetTimeout (4) a stSetError (6).
Další důležitá zmínka se váže k příkazu wait. Jeho použití je v našich ukázkách jediné možné, varianta čekání bez přerušování běhu procedury (například v cyklu while channel1:value_set do ... end;) neumožní komunikaci jádra s ovladačem, hodnotu nebude možné doměřit a cyklus while bude nekonečný.
Ukázky řízení komunikace se soustředily na objasnění principu a pro jednoduchost mlčky zanedbaly jakékoli okolí — hlavně jiné přístroje. Každý z těchto jiných přístrojů může do těchto mechanizmů zasahovat a může tak s řízeně komunikovanými kanály pracovat. Ohroženy jsou výstupní a obousměrné kanály použité jako výstupy, neboť, jak již víme, výstupy mohou nabývat během jednoho časového kroku jádra více hodnot. Řízené zapsání výstupu v proceduře může proběhnou excelentně, ale kvůli akci jiného přístroje můžete zapsat a ověřit úplně jinou hodnotu, než jste si původně připravili.
Řízení komunikace je velmi pokročilý způsob, jak komunikovat, a je možné předpokládat, že bude použit pouze v případě obzvláště důležitých kanálů. Rutinní používání tohoto postupu by bylo asi nepraktické, protože samotné jádro dokáže vyhovět aplikaci svými postupy v 99,99 % až 100 % případů. Řízená komunikace v procedurách je třešnička na dortu komunikačních možností systému Control Web.
Přístroje mohou být aktivovány buď periodicky, nebo výjimkami od jiných přístrojů nebo ovladačů. Periodickou aktivaci zajišťuje časovací tok spolu s jádrem podle informací přítomných přímo v přístroji, zatímco aktivaci výjimkami musí vždy způsobit přístroj nebo ovladač (objekty mimo jádro).
Výjimky se nazývají také "zprávy", takže je možné použít například větu "přístroj pošle zprávu...". Jen je třeba rozlišovat mezi zprávami operačního systému (ty se zase častěji nazývají události), které se řadí do fronty vstupních zpráv, a zprávami aplikace systému Control Web, které si navzájem posílají přístroje a ovladače.
Základní rozdíl mezi periodickým časováním a výjimkami spočívá v jejich předpověditelnosti. Zatímco o periodickém časování je vše známo předem, tedy jak perioda, tak jednotlivé okamžiky aktivací přístroje, o výjimkách není předem známo nic, a systém s nimi nemůže dopředu nijak počítat. Tento zásadní rozdíl také vymezuje použití jednotlivých způsobů časování — periodické časování bude použito všude tam, kde je znám související děj, časování výjimkami všude tam, kde předem není dán žádný děj ani časový rámec. Výjimkami se časuje typicky asynchronně (tedy kdykoli), většinou v reakci na vstupní události. Výjimky umožňují programovat aplikaci "událostně" jako sadu akcí, které mohou být v určitý předem neznámý okamžik podle potřeby provedeny.
Výjimku přístroje je v aplikaci možné vyrobit dvěma způsoby:
Výjimky ovladače se do zdrojového textu zapisují trochu jinak (naopak). V přístroji se pomocí parametru driver_exception nedefinuje příjemce zprávy, ale její zdroj — ovladač. Ovladač nemusí umět výjimky generovat, tato vlastnost není součástí specifikace nutných vlastností ovladače. Z toho také plyne určitá volnost v návrhu ovladačů, kdy podle potřeby může každý ovladač výjimku použít k signalizaci naprosto jiné skutečnosti. Například standardní ovladač ASCII-Driver dokáže výjimku generovat v případě, že přijme po sériové lince nějaká data.
Obě výjimky, přístrojová i ovladačová, jsou zpracovány v takovém pořadí, jak přicházejí. Zachycení všech výjimek a jejich shromáždění v pořadí jejich vzniku má na starosti časovací tok. Výjimky jsou asynchronní a časovací tok je proto zpracovává co nejrychleji, obyčejně okamžitě, jakmile jádro dokončí probíhající časový krok. Pokud zrovna časovací tok čeká na probuzení, jsou výjimky zpracovány okamžitě při jejich přijetí.
Časovací tok má dvě možnosti:
Velmi snadno může vzniknou situace, kdy jednomu přístroji v jednom časovém kroku jádra pošle zprávu více přístrojů. Popsaný mechanizmus zaručuje, že přístroj dostane zprávu pouze jednu, neboť na výjimky vzniklé v jednom kroku jádra se pohlíží jako na výjimku jednu. Zajímavější situace nastane, pošle-li přístroji zprávu současně přístroj i ovladač, případně čeká-li přístroj na aktivaci výjimkou a ještě jej současně periodicky aktivuje časovací tok (to může nastat v případě, kdy časovací tok slučuje výjimky a periodicky časované přístroje).
I za této situace bude přístroj obeslaný všemi způsoby aktivován pouze jednou — dojde k souběhu výjimek. Způsob aktivace může přístroj velmi zajímat. Několik přístrojů například pracuje tvrdošíjně pouze jsou-li periodicky aktivovány (například PID regulátor), přičemž ostatní způsoby aktivace přehlížejí. Souběh bez informací o výjimkách by způsobil ztrátu informace. Každý přístroj proto dostává při své aktivaci od jádra seznam všech příčin aktivace. Tato informace je dostupná i v proceduře OnActivate s parametry — buď se čtyřmi, které přímo po řadě určují příčinu aktivace, nebo s jedním, který kromě příčin aktivace ještě obsahuje další informace (o proceduře OnActivate se dočtete v kapitole Programování a procedury — OCL). Každý přístroj v aplikaci se tudíž může dozvědět, proč vlastně zrovna pracuje.
Souběh výjimek má ještě jeden aspekt. Víte, že časovací tok zachovává pořadí aktivací přístrojů podle pořadí přijatých zpráv. Přidá-li se k již existující příčině aktivace nějaká další, vznikne souběh. Přístroj zůstane na svém dosaženém pořadí.
V případě souběhu tedy bude přístroj aktivován v okamžiku, který odpovídá vzniku první příčiny aktivace. Například, vznikne-li souběh výjimky a časování periodou, je přístroj připraven pro aktivaci před časovanými přístroji. Přidání časování periodou pořadí přístroje neovlivní, a přístroj proto bude aktivován z důvodu výjimky i uplynutí periody před přístroji aktivovanými pouze z důvodu uplynutí periody.
Mechanizmus výjimek je obecný a je systémem používán také vnitřně. Jistě si pamatujete, že příkazy yield, pause a wait přerušují proceduru a ukončují časový krok přístroje. Bez výjimek by procedura nemohla pokračovat dříve, než v okamžiku další periodické aktivace (nebyl by důvod proceduru aktivovat). Příkaz yield, nebo pause 0 by se tak protáhl třeba na deset sekund. Procedury proto komunikují s časovacím tokem pomocí vnitřních (skrytých) výjimek, pro které však platí všechna popsaná pravidla. Takže není-li potřeba periodicky časovat, vynutí si výjimka vložení časového kroku a procedura může pokračovat po příkazu yield s minimálním časovým zpožděním.
Asynchronnímu časování je věnována samostatná kapitola Neperiodické časování, která na celou problematiku nahlíží z jiného úhlu, než striktně časovacího.
Veškerý text této kapitoly (kromě malého kousku u periodického časování) zatím předpokládal, že aplikace běží. Po drtivou většinu času provozu aplikace je takový předpoklad správný a bez výhrad platný. Aplikace se však při startu rozbíhá a při zastavení ukončuje, přičemž jak rozběh tak ukončení musejí provádět jiné akce, než jaké jsou typické pro běh. Před vlastním během je třeba legálně nastartovat přístroje, korektně inicializovat vnitřní data a kanály a zajistit plynulý rozběh časování. Zastavení naopak musí bezpečně ukončit časování a komunikace.
Při rozběhu aplikace se musí inicializovat (nastavit na počáteční hodnotu) globální proměnné a výstupní kanály (konstanty také, ale tam se to předpokládá jaksi automaticky). Obojí jsou totiž přístrojům k dispozici okamžitě (bez měření) a jakékoli čtení jejich obsahu musí vždy (již od počátku) poskytnout legální hodnotu. Globální proměnné i výstupní jsou inicializovány ihned při čtení jejich definic.
Výstupní kanály jsou však (na rozdíl od proměnných) spjaty s konkrétními existujícími řídicími prvky a inicializace kanálů by tedy měla ovlivnit i je. Na druhé straně je docela dobře možné chtít výstupní kanál inicializovat "jen tak", než se aplikace rozběhne, a teprve až poté výstupní kanál nastavit na správnou hodnotu vyčtenou z technologie. Nelze rozhodnout, který z obou způsobů je správný — nejspíše bude část aplikací potřebovat inicializovat jak kanál tak technologický prvek, a část nikoli. Aplikace proto definuje parametr skip_init_outputs sekce settings, který se chování inicializací řídí:
Prvotní inicializace proměnných a kanálů probíhá při jejich čtení. Od toho okamžiku jsou oba druhy datových elementů k dispozici přístrojům, které je jednak mohou číst, a jednak do nich mohou zapisovat. Aplikace ještě neběží a nejedná se tedy o běžné výkonné čtení a zápisy — přístroje pouze v rámci své inicializace upravují datové elementy, které jsou jejich výstupem, na svou inicializační hodnotu. Například, přístroj control zapíše při své inicializaci do svého výstupu hodnotu, která je určena jeho parametrem init_value. Po inicializaci kanálů a proměnných jejich počátečními hodnota jsou tedy přístroje druhé v pořadí, kdo ovlivňuje hodnotu datových elementů.
Přístroje při inicializaci svých výstupů zapisují do proměnných i kanálů vždy bez možnosti tuto vlastnost jakkoli vypnout. Pokud je výstupem přístroje výstupní kanál, je jeho hodnota přístrojem změněna, a podle nastavení parametru skip_init_outputs případně také připravena k zápisu. Jinými slovy, hodnota výstupního kanálu uvnitř systému je přístrojem při inicializaci ovlivněna vždy, nicméně vlastní přenos kanálu do techologie může a nemusí být realizován — to již záleží na nastavení parametru skip_init_outputs.
Hodnota datového elementu po inicializaci přístrojů však stále ještě nemusí být konečná.
Třetí v pořadí, kdo může ovlivnit hodnoty výstupních kanálů a proměnných, jsou přístroje backup, které slouží k obnovení zálohovaných veličin. Data zálohovaná přístrojem backup jsou skrytě dosazena do všech přístrojů, které patřičný datový element používají jako svůj výstup — například již zmíněný přístroj control po obnovení dat přístrojem backup automaticky upraví svou hodnotu (svůj vzhled) podle svého výstupu.
Obnovení dat ze zálohy pomocí přístrojů backup je operace, která musí být vždy do aplikace naprogramována a systém ji nikdy neprovádí sám od sebe. Naprogramováním v tomto případě se rozumí pouhá přítomnost přístroje backup v aplikaci. Jelikož je zařazení přístroje backup nutně vždy krokem tvůrce aplikace, není důvod předpokládat, že by si autor data z přístroje backup nepřál obnovit. Proto přístroj backup při obnovení výstupního kanálu automaticky kanál připravuje k zápisu, a hodnota kanálu proto bude vždy komunikována až do technologie. Přístroje backup se tedy neřídí parametrem skip_init_outputs.
Posledním místem, kde můžete počáteční hodnotu datových elementů upravit, je přístroj startup (jeho popis následuje níže). Přístroj startup je normální součástí zdrojového textu aplikace a může obsahovat jakýkoli algoritmus, takže podle potřeby můžete v tomto přístroji jakémukoli datovému elementu nastavit jakoukoli hodnotu. Jelikož je startup poslední v řadě inicializací datových elementů, budou hodnoty v něm nastavené skutečně poslední a čerstvě rozběhnutá aplikace použije právě je.
Inicializace datových elementů v přístroji startup může proběhnout dvojím způsobem:
Počáteční inicializace datových elementů je navržena tak, aby pokryla pokud možno všechny myslitelné varianty. Mechanizmus je možné ovlivnit volbou skip_init_outputs tak, že ve výsledku systém pracuje jedním z následujících způsobů:
Inicializace dat
Současně s inicializací dat se při spouštění průběžně inicializují a k rozběhu připravují jednotlivé přístroje. Každý přístroj během inicializace může ovlivňovat datové elementy (to jste již poznali), může spouštět událostní procedury a může posílat zprávy jiným přístrojům. Aplikace však ještě neběží, a proto všechny akce systém provádí "do zásoby". Některé z nich navíc nemohou být zcela realizovány (například procedura nebude po příkazu yield ihned pokračovat), a odloží se až na dobu běhu.
Přístroje při své inicializaci mohou provádět následující akce, které budou plně uskutečněny až po rozběhu aplikace:
Všechny zprávy se během inicializace řadí do fronty podle okamžiku vzniku a jsou najednou zpracovány po dokončení běhu přístroje startup před rozběhem ostatních přístrojů. Počáteční zprávy jsou tedy vloženy mezi aktivaci startupu a ostatní počáteční aktivace, neboli jinak řečeno, zprávy přeskočí přístroj startup.
Již jste se (několikrát) dozvěděli, že existuje přístroj startup, který je možné použít (mimo jiné) při inicializaci datových elementů. Jeho postavení v systému je výjimečné, neboť pro něj platí následující speciální pravidla:
O rozběhu aplikace zatím víte, že postupuje následujícími kroky:
K úspěšnému rozběhu aplikace již zbývá málo — začít periodicky časovat přístroje. Protože se již o periodickém časování hovořilo v oddíle Časování přístrojů, shrnu na tomto místě pouze skutečnosti, které se vážou k rozběhu aplikace:
První časový krok jádra (tedy krok s přístrojem startup) je zároveň krokem, od kterého je možné považovat aplikaci za rozběhnutou, takže veškeré komunikace, výjimky a časování začnou probíhat podle výše obšírně popsaných mechanizmů.
Přístroj není povinnou součástí aplikace a vůbec jej nemusíte používat. Aplikace bez přístroje startup poběží stejně dobře. Celý text se doposud přístrojem startup zabýval, neboť startup patří k rozběhu, a bez jeho zahrnutí (nebo neustálého opakování, že startup může a nemusí existovat) by se popis rozběhových pochodů zbytečně rozmělňoval. Popsané startovací děje probíhají bez přístroje startup shodně, odlišnost spočívá právě v prostém vypuštění přístroje startup i se všemi akcemi, které se ho týkají. Bez přístroje startup nemůžete ovlivňovat výstupní kanály po jejich obnovení přístroji backup, nemůžete zprávami aktivovat přístroje a nemůžete připravit specifické podmínky pro běh aplikace (například přizpůsobit velikost hlavního panelu aktuálním velikostem obrazovky). Podobně vypadá rozběh jádra — bez přístroje startup se žádný zvláštní časový krok nevkládá a časování začne okamžitě krokem jádra, ve kterém se jednak vyřídí inicializační zprávy a jednak poprvé aktivují relativně časované přístroje.
Pokud byste zkusili přístroj startup vyhledat v existujících aplikacích, bude přítomen asi v 80 % případů. Jeho použití je tedy docela časté, ale jde to i bez něj. Doporučení týkající se přístroje startup může být pouze velmi obecné — lepší než trvale komplikovat vztahy mezi přístroji různými podmínkami rozběhu aplikace, je dát na jedno místo v aplikaci vhodný impuls, který se již nikdy později za běhu nezopakuje. Výsledkem bude funkčně shodná aplikace, zmenší se však riziko chyb a zpřehlední se její zápis.
Opakem přístroje startup je přístroj terminate. Spouští se na konci aplikace v okamžiku, kdy již je jasné, že aplikace má být zastavena. Součástí terminate proto mohou být různé operace — odstranění dočasných souborů, dokončení komunikací, zálohování posledních známých dat nebo vypnutí a rozpojení komunikačních kanálů.
Jedná se opět o přístroj speciální, a platí pro něj tedy zvláštní pravidla:
Podobně jako přístroj startup není ani přístroj terminate povinnou součástí aplikace. Pokud jej nepoužijete, systém dokončí právě probíhající časový krok, zastaví peridické časování, vyřeší zaslané zprávy (ty se mohou dále šířit a řešení zpráv proto může spotřebovat několik časových kroků jádra) a dokončí rozběhnuté vstupní i výstupní komunikace. Po té aplikace skončí.
Končící aplikace (ať již obsahuje přístroj terminate nebo ne) signalizuje svůj stav každému aktivovanému přístroji prostřednictvím bitu 9 v parametru procedury OnActivate( ActivateMode : cardinal ). Všechny přístroje se tak mohou dovědět, jestli jsou aktivovány při ukončování, a mohou podle toho přizpůsobovat své chování. Samotný přístroj terminate (aktivovaný jako terminate, neboli jako poslední přístroj) obsahuje v parametru své procedury OnActivate( ActivateMode : cardinal ) bit 7. Je-li přístroj terminate aktivován za chodu aplikace (periodicky nebo výjimkou), ActivateMode uvedený bit 7 neobsahuje.
V obou případech (při použití terminate i bez něj) nemusí být aplikace konečná. První způsob, jak aplikaci nikdy neukončit, je vyrobit nekonečný přístroj terminate — například naprogramujete nekonečný cyklus s jediným příkazem yield v těle cyklu. Druhá možnost je porucha v komunikaci — nemusí se dařit vyřídit všechny existující vstupní nebo výstupní požadavky. Za těchto okolností by aplikace nikdy neskončila.
Systém Control Web proto obsahuje pojistku, která "nekonečné ukončení" odstraní. Použijete-li přístroj terminate, otevře se v okamžiku zastavování aplikace následující okno:
Ukončení aplikace
Terminate tedy může pracovat třeba nekonečně dlouho, nicméně stisk kombinace kláves <Ctrl>+<End> aplikaci jistě ukončí. Terminate sice nedoběhne a komunikace se nedokončí, ale s tím se už nedá nic dělat.
Pokud aplikace terminate neobsahuje, otevírá se uvedené okno automaticky po pěti sekundách od pokynu k zastavení aplikace. Postup je potom shodný — stisk kombinace kláves <Ctrl>+<End> aplikaci ukončí.
Přístroj terminate se používá mnohem méně než přístroj startup. Je to asi dáno tím, že při zastavení má aplikace k dispozici platná data, a nemusí se tudíž příliš starat o jejich obsluhu. Z obecného hlediska je vhodné v přístroji terminate provádět jen nejnutnější akce, které příliš nebudou brzdit zastavení aplikace. Pokud si nepřejete aplikaci zastavit, použijte mechanizmu uživatelských přístupových práv (popsáno v kapitole Systém kontroly uživatelských práv). Po rozběhu přístroje terminate je již pozdě na nějaké rozsáhlé akce. Přeje-li si uživatel aplikaci zastavit, má být aplikace zastavena a ne zdržována přístrojem terminate.
Programování aplikací reálného času může být dvojsečnou zbraní. Na jedné straně jsou aplikace reálného času velmi elegantní a velmi mocné, dokážete s nimi splnit jakákoli přání zákazníků (počínaje archivacemi do gigantických databází přes vizualizace velmi rychlých dějů až k přímému řízení strojů). Systém Control Web vás přitom všemožně podporuje a poskytuje vám neobvykle širokou paletu nástrojů (nakonec, všechno řízení, komunikaci i časování můžete takřka zcela převzít do svých rukou).
Na straně druhé však toto velmi benevolentní otevření se a nabídnutá volnost návrhu nutí vás — tvůrce aplikace převzít plně odpovědnost za svou práci. Aplikace reálného času musí být dobře promyšlena, musí se více programovat a musí se pamatovat na to, že program pracuje vždy přesně tak, jak ho programátor vyrobil (a že tudíž nedělá to, co si programátor přeje). Aplikace a systém (jádro a časovací tok) vám dovolí témeř cokoli, ale musíte si být vědomi, že vy jste ta hlavní osoba, která celou aplikační mozaiku ze služeb systému poskládá. Vytvoříte-li chybný obrazec, nebo přesáhnete-li možnosti stroje, programu či fyziky, nedokáže vám v tom aplikace nijak zabránit. To by vás musela omezit a to přece není cílem.
Výhody aplikací reálného času jsou: otevřenost, univerzálnost, škálovatelnost, plná podpora programování na všech úrovních a plná kontrola nad během aplikace.
Rizika aplikací reálného času jsou: otevřenost, univerzálnost, škálovatelnost, plná podpora programování na všech úrovních a plná kontrola nad během aplikace.
Jen vaše práce rozhodne, do které skupiny se vaše aplikace zařadí.