Jedna velikost nepadne všem

Jedna velikost nepadne všem

Platnost tohoto rčení zjevně není omezena jen na průmysl oděvní konfekce, ale vztahuje se v podstatě na všechna průmyslová odvětví. Různé tržní segmenty a různé oblasti použití mění kritéria užitečnosti a kvality každého výrobku a tím nutí výrobce modifikovat produkty pro různé zákazníky. V oblasti informačních technologií existují také různá kritéria vhodnosti a užitečnosti – u stolního počítače preferujeme maximální výkon téměř bez ohledu na spotřebu energie a hmotnost, u přenosného počítače se raději spokojíme s menším výkonem, ale vyžadujeme malou hmotnost a dlouhý provoz s napájením z baterií, u osobního organizéru je malá hmotnost a spotřeba téměř rozhodujícím kritériem. Podobná diverzifikace panuje i v softwarovém průmyslu, i když v této oblasti jsou rozdíly v očích veřejnosti méně patrné. Přesto pro odborníky představují různá použití operačních systémů a aplikací naprostou změnu kritérií, podle nichž jsou softwarové projekty konstruovány i hodnoceny.

Pomiňme rozdílnost konceptů klientských aplikací, stále více zaměřených na snadnost a bezproblémovost obsluhy a současně na estetickou stránku produktu, a serverových aplikací, které často poskytují pouze „spartánské“ uživatelské rozhraní, neboť předpokládají, že je budou obsluhovat lidé znalí, a soustředí se na vlastní funkčnost, efektivitu využití zdrojů počítače apod. Namísto toho se věnujme kritériím důležitým pro schopnost systémů a aplikací pracovat ve strojích, rozváděčích a jiných zabudovaných aplikacích, tedy na velikost zdrojů počítače (především velikosti paměti, ale i výkonu procesoru) potřebných pro práci systému, na schopnost systému pracovat v reálném čase, zotavit se z náhlých vypnutí apod.

Pracovní stanice a servery
Nikdo se již nediví nepřetržitému nárůstu výkonu procesorů a kapacit pamětí ve stolních i přenosných počítačích a serverech. A tak zatímco první PC/XT mělo problémy s dostatečně rychlým obnovením textové obrazovky a první PC/AT jen obtížně překreslovalo okna s jednoduchým grafickým uživatelským rozhraním, současná uživatelská rozhraní oplývají efekty animací, průhlednosti apod. Dlouhodobým vývojem se vytříbila kritéria pro návrh počítačů, operačních systémů i aplikací pro osobní počítače i servery:

• Spíše než přesná časová odezva systému je důležitá jeho celková propustnost. Jinými slovy: není příliš podstatné, kdy přesně k dané operaci dojde, důležitější je schopnost zpracovat co největší počet operací za určitý čas.
• U interaktivních aplikací se přidává ještě další kritérium – subjektivní dojem uživatele pracujícího s počítačem. Úkoly, na něž se uživatel zrovna soustředí, musí mít přednost před úkoly pracujícími v pozadí. Toho lze dosáhnout za cenu zavedení mnoha výjimek ve standardním chování přepínače úloh, které zajišťují preferenci úloh v popředí.
• Pokles cen pamětí a nárůst výkonu procesorů nenutí k přílišnému zaobírání se potřebnou velikostí paměti. Ukazuje se, že zdvojnásobit její kapacitu je vždy jednodušší, levnější a bezpečnější než snaha pracně, zdlouhavě a s nejistým výsledkem optimalizovat aplikaci z hlediska co nejmenších požadavků na paměť. Ušetřený čas je možné namísto toho věnovat přidávání nových vlastností, které opět zvyšují nároky na počítač.
• Velké nároky programů na již zmíněné zdroje počítače vyžadují použití diskové paměti, nyní v podstatě jediného dostupného velkokapacitního paměťového média.
• Malý význam časově deterministického zpracování v prostředí kancelářských a inženýrských aplikací vede i k vyjmutí pravidel definujících časové chování z definic standardních programových rozhraní. Takže např. způsob „nadržování“ aplikaci pracující v popředí se tak liší mezi různými implementacemi Win32 API (Windows 9X versus Windows NT) i mezi různými verzemi jediné implementace.

Všechny zde uvedené body platí i pro nejrozšířenější operační systémy řady Windows NT/2000 firmy Microsoft. Ačkoliv systémy přepínání procesů a meziprocesové synchronizace jsou v prostředí Win32 navrženy z hlediska kancelářských, inženýrských i serverových aplikací velmi dobře, jejich reakční doby nejsou deterministicky určitelné, a tedy není možné zaručit reakci aplikace na události do určité doby.

Typickým architektonickým rysem operačních systémů Windows NT/2000 znemožňujícím deterministické určení doby přepnutí výpočetního kontextu z jednoho procesu na druhý je tzv. inverze priorit. Veškerá činnost aplikací v systémech Win32 je vykonávána tzv. prováděcími toky. Každý proces (aplikace) má alespoň jeden takový tok, může jich však být i více. Na počítači vybaveném jediným procesorem sice může v každém okamžiku běžet právě jediný prováděcí tok (thread, programové vlákno), ale systém jejich vykonávání po krátkých časových intervalech řádu desítek až stovek milisekund střídá, takže pro uživatele vytváří dojem jejich současné činnosti. O změnu kontextu vykonávání z jednoho prováděcího toku na druhý se stará část operačního systému zvaná plánovač. Aby bylo možné práci více toků účinně řídit, operační systém nabízí aplikacím množství programových rozhraní umožňujících synchronizaci jejich provádění. Tak může jeden prováděcí tok zastavit svou činnost (plánovač mu nebude přidělovat čas procesoru) do doby, než jiný prováděcí tok ukončí určitou činnost. Jinými slovy jeden prováděcí tok čeká na jiný tok. Co se ale stane, jestliže prováděcí tok s vysokou prioritou čeká na tok s nízkou prioritou? Může vzniknou paradoxní situace, že prováděcí tok s vysokou prioritou stojí, neboť čeká na jiný prováděcí tok s nízkou prioritou, který se nemůže dostat „ke slovu“, neboť plánovač přiděluje procesor dalšímu toku se střední prioritou. Tuto situaci řeší operační systém tak, že dočasně zvětší prioritu prováděcímu toku, na který čeká jiný tok s vysokou prioritou, aby byla splněna podmínka, že toky s vysokou prioritou se vykonávají přednostně před toky s nízkou prioritou. Problém vyvstane ve chvíli, kdy se stejná situace opakuje rekurzivně – i prováděcí tok s právě zvýšenou prioritou může čekat na další tok s nízkou prioritou. Systémy Windows NT/2000 na takovou situaci pamatují a prohledávají tyto řetězce závislostí s předem neurčenou délkou. V důsledku toho systém sice ctí prioritu prováděcích toků, ale doba přepnutí kontextu z jednoho prováděcího toku na druhý je v principu nedeterministická.

Windows CE – předefinování požadavků na operační systém
V historii firmy Microsoft se objevilo několik snah proniknout na trh zabudovaných aplikací, např. projekt Windows At Work, který naprosto neuspěl především vlivem použití nespolehlivého šestnáctibitového kódu systémů MS-DOS a Windows 3.1 a v důsledku naprosté závislosti na architektuře Intel x86. Po dalších neúspěšných pokusech vyvinout zcela nový objektový operační systém (projekt Pulsar) dostal podporu systém Windows CE (podle neoficiální interpretace písmena CE značí Consumer Electronics, česky spotřební elektronika), určený právě pro práci v zabudovaných aplikacích bez pevného disku a s omezenými zdroji.

Hlavní předností systému Windows CE (ale také částečně jeho nedostatkem) je snaha o zachování kompatibility aplikačního programového rozhraní s ostatními systémy Windows. Ačkoliv je systém napsán zcela znovu (není v něm obsažen kód převzatý z jiných implementací Windows), syntaxe a chování funkcí jeho programového rozhraní jsou až na pár výjimek shodné s jinými systémy. Tak je sice řada parametrů různých funkcí nevyužita a parametry jsou předávány zbytečně (Windows CE např. nepodporují zabezpečení, jak je známe z Windows NT/2000), ale naproti tomu programátoři znají API systémů Windows a své znalosti mohou zužitkovat při vývoji aplikací pro Windows CE, což se ukazuje jako velmi silná zbraň v boji za získání popularity. Celou architekturu ovlivnila sada základních požadavků:

• Windows CE musí být schopny práce v zabudovaných aplikacích bez diskové paměti.
• Systém musí být navržen modulárně, aby OEM-partneři, používající jej ve svých řešeních, mohli zvolit, které komponenty chtějí a které ne, a tím mohli výrazně redukovat požadavky systému na paměť.
• Systém by měl být schopen deterministické práce v aplikacích reálného času.
• Systém musí podporovat robustní zpracování více procesů s oddělenými paměťovými prostory a současné zpracování více prováděcích toků.
• Cílovou platformou nebudou jen procesory x86, ale i jiné 32bitové architektury.
• API systému by mělo zůstat kompatibilní s jinými implementacemi Windows.

Některé cíle se podařilo splnit lépe, jiné hůře. Windows CE skutečně pracují na systémech disponujících pamětí o velikosti řádově stovek kilobytů. Je-li v systému začleněno grafické uživatelské rozhraní, požadavky na kapacitu paměti vzrostou na několik megabytů. Vzhledem k současnému stavu vývoje pamětí a jejich ceně není racionální snažit se množství potřebné paměti dále zmenšovat.

Také podpora procesorů je velmi široká. Mimo klasické řady Intel x86 podporují Windows CE i procesory ARM, MIPS, PowerPC, Hitachi SH, Toshiba apod. Obecně mohou Windows CE pracovat na jakémkoliv 32bitovém procesoru s implementovanou správou paměti.

Podpora deterministického přepínání kontextu prováděcích toků je zavedena až od verze 3. Od této verze jádro operačního systému zabezpečuje inverzi priorit prováděcích toků jen v jediné úrovni a tím umožňuje stanovit maximální dobu potřebnou na přepnutí kontextu. Od verze 3 je také k dispozici podstatně jemnější členění priorit prováděcích toků: k dispozici je 256 úrovní priorit, na rozdíl od 8 úrovní v předchozích verzích systému („velké“ implementace Windows disponují 32 úrovněmi priorit).

I další vlastnosti podporující zpracování úloh v reálném čase byly ve verzi 3 vylepšeny. Kupříkladu systémové časovače pracují s rozlišením 1 ms oproti 25 ms u předchozích verzí. Byla přidána podpora pro vložené zpracování přerušení (objeví-li se přerušení s vysokou prioritou v době zpracovávání přerušení s nižší prioritou, obsluha přerušení s vysokou prioritou se předběhne a nemusí čekat, až obsluha přerušení s nižší prioritou skončí). Počet současně spuštěných procesů je omezen na 32. Počet prováděcích toků těchto procesů je ale omezen jen množstvím zdrojů počítače. Omezení na 32 procesů plyne ze snahy o maximální zefektivnění správy paměti jednotlivých procesů. Rovněž virtuální adresový prostor každého procesu je omezen na 32 MB. Další omezení se týká knihoven DLL, které jsou mapovány na stejné paměťové lokace všech procesů. Adresový prostor pro knihovny DLL každého procesu je tak omezen již zavedenými knihovnami DLL všech ostatních běžících procesů.

Zásadním problémem se ukázal požadavek na kompatibilitu se systémy Windows NT/2000, které pracují na počítačích s neskonale větší pamětí a rychlejšími procesory a jejichž API je velmi „košaté“. Návrháři se snažili vždy z několika způsobů, jimiž je možné danou funkci ve Windows NT/2000 naprogramovat, zachovat vždy alespoň jediný, ale velmi často se nepodařilo ani to. Mnoho funkcí ve Windows CE prostě není a je nutné tento nedostatek složitě obcházet, je-li to vůbec možné.

Dalším sporným bodem je celkový výkon systému. Windows CE využívají k implementaci mnoha funkcí jádra systému (grafika, správa oken a událostí, souborové služby) servisních procesů. Ačkoliv z teoretického hlediska je taková architektura velmi čistá, v praxi přináší značné problémy pro velkou režii, a samotné Windows NT od této architektury z důvodu výkonnosti ustoupily již ve verzi 4. Vlivem toho běží Windows CE na stejném počítači výrazně pomaleji než třeba Windows 98.

Relativně krátká doba existence systému zapříčiňuje dosti velké množství chyb. Vývojoví pracovníci se musí připravit na problémy mající původ v samotném systému i ve vývojových nástrojích, které je nutné v aplikacích obcházet. V tomto ohledu ale není situace nijak výjimečná a lze předpokládat, že se zdokonalováním Windows CE bude chyb ubývat.

Přes všechny nedostatky jsou Windows CE univerzální platformou, která díky své dostupnosti, podobnosti s jinými systémy Windows, relativní bezproblémovosti implementace (ve srovnání s úsilím nutným k implementaci jiných platforem) a široké podpoře vývojových nástrojů získává na popularitě a stále častěji je volena výrobci systémů pro průmyslovou automatizaci. Vést před jinými systémy napomáhá systému Windows CE mimo popularitu platformy Windows a sílu firmy Microsoft také jejich robustní návrh a otevřenost k aplikacím třetích stran. Jiné systémy reálného času jsou často navrhovány spíše jako sada knihoven pro plánování času a podporu periferií, aplikace bývá integrována do celého obrazu systému ve fázi jeho překladu a chyby aplikace ohrožují celý systém. Kupříkladu podpora pro oddělené paměťové prostory jednotlivých procesů bývá často dodávána jako volitelná komponenta, je-li vůbec k dispozici.

Control Web Runtime pro Windows CE
Přes dostupnost vývojových prostředků Microsoft Embedded Visual C++ a Visual Basic bývá největším problémem aplikace Windows CE tvorba programového vybavení. Mnoho výrobců začíná nabízet systém Windows CE pro zabudované aplikace na platformě PC. Oproti jiným verzím Windows tento postup přináší mnoho výhod, např. schopnost pracovat bez pevného disku, možnost zařízení vypnout bez nebezpečí poškození souborů na disku a ohrožení dalšího startu systému, rychlý start aplikace po zapnutí apod. Problémem ale je, jak vytvořit aplikaci samotnou. Začít psát aplikaci přímo v jazyce C nebo C++, přitom studovat programové rozhraní systému a jeho zvláštnosti, ladit ji a testovat, to si mohou dovolit jen velké společnosti, které mají potřebné programátorské zázemí a které předpokládají zavedení aplikace ve velkých objemech, schopných uhradit vysoké náklady na vývoj. Pro jednotlivé navzájem se dosti lišící nasazení je použití základních vývojových nástrojů krajně nevhodné a neekonomické.

Řešením problému, jak Windows CE v průmyslovém PC oživit, je systém rychlého vývoje průmyslových vizualizačních a řídicích aplikací Control Web 2000. Control Web je široce rozšířen v prostředí systémů Windows NT/2000 v průmyslu i ve středních a vysokých školách. Mnoho techniků, aplikačních inženýrů i studentů jej zná a dokáže efektivně využívat jeho bohaté možnosti. Ačkoliv aplikace systému Control Web pracují ve velmi velkých systémech, skládajících se z mnoha počítačů propojených lokálními i vzdálenými sítěmi, a k dispozici je i verze spolupracující se systémy Windows 2000 Advanced Server zapojenými do clusteru, minimální požadavky na počítač schopný provozovat aplikaci odpovídají požadavkům pro běh alespoň systémů Windows 95/98 (pro spolehlivý dlouhodobý chod aplikací je vždy lépe použít Windows 2000). Verze Control Web Runtime pro Windows CE umožňuje použít aplikaci na všech počítačích, na nichž pracuje systém Windows CE verze 3.0 – tedy nejen na počítačích s architekturou PC a pamětí flash namísto pevného disku, ale i na počítačích s procesory ARM či MIPS.

Zvláštnosti systému Windows CE se do jisté míry promítají i do návrhu Control Web Runtime pro Windows CE. Především Windows CE není možné koupit jako maloobchodní produkt, systém je vždy dodáván prostřednictvím OEM-partnerů jako součást počítačů. Tím vzniká problém s velkým počtem variant konfigurace Windows CE, neboť OEM-výrobce rozhoduje, které komponenty do systému zabuduje a které ne.

Další nedostatek lze vidět v omezené možnosti instalovat produkt. Jen několik implementací Windows CE (např. Pocket PC a H/PC) podporuje standardní způsob instalace přes stolní počítač a rozhraní ActiveSync, mnoho dalších implementací toto rozhraní nemá k dispozici. Na rozdíl od stolního počítače, kdy zákazník vloží CD-ROM do mechaniky a o další se postará systém, u Windows CE je to složitější. Distribuce Control Web Runtime pro Windows CE se snaží tuto situaci maximálně ulehčit i zákazníkům bez hlubších znalostí operačních systémů Windows.

Především Control Web Runtime pro Windows CE se neinstaluje jako samostatný produkt, ale jako komponenta standardního vývojového prostředí Control Web 2000. Aplikace pro Windows CE se vyvíjí vždy ve stolním počítači. Návrhář pouze zvolí v dialogovém okně nastavení, že vyvíjí aplikaci pro Windows CE. Vývojové prostředí se přizpůsobí skrytím virtuálních přístrojů nepodporovaných ve Windows CE z palety přístrojů a doplněním několika dalších kontrol do ostatních virtuálních přístrojů (např. daný virtuální přístroj nemusí ve Windows CE podporovat práci ve všech módech). Aplikaci lze ladit a testovat na stolním počítači, je-li na tomto počítači k dispozici stejný hardware, jaký bude připojen k počítači s Windows CE, s patřičnými ovládači. A pokud tomu tak není, lze aplikaci do značné míry otestovat a upravovat s použitím virtuálních zdrojů dat a na samotný běh pod Windows CE nechat jen ladění vlastní komunikace.

Vlastní aplikace je na počítač s Windows CE přenášena s pomocí Průvodce pro export aplikace do Windows CE. Tento průvodce nabídne uživateli volbu platformy Windows CE, typu procesoru, na němž Windows CE pracují, volbu spojení se zařízením s Windows CE (automatické přes ActiveSync nebo manuální) a na základě zadaných parametrů vygeneruje instalační balík pro Control Web Runtime pro Windows CE spolu s přeloženou aplikací. Uživatel se tedy nemusí zaobírat detaily instalace systému Control Web a přenosem všech aplikačních souborů (přeložená aplikace, ikony, obrázky apod.) na platformu Windows CE. Vygenerovaný balík obsahuje vše potřebné.

Jak už bylo řečeno, Control Web Runtime pro Windows CE nepodporuje úplně všechny vlastnosti dostupné ve verzi pracující ve Windows NT/2000. V naprosté většině je to dáno přímo omezeními Windows CE. K typickým omezením patří absence permanentního přepisovatelného paměťového média. V zabudovaných aplikacích často bývá k dispozici jen paměť flash, na níž je emulován disk s IDE. Ovšem takový disk je omezen množstvím zápisových cyklů, které bývají v řádech tisíců až desítek tisíců. Velmi rychlý zápis může takový disk zničit během relativně krátké doby. Proto jsou v Control Web Runtime pro Windows CE omezeny zápisy na disk, např. nejsou tvořeny soubory obsahující údaje o monitorování systému (log files) apod. Rovněž nedostupné ve Windows CE jsou virtuální přístroje, které závisejí na programových komponentách Windows, jež ve Windows CE nemají ekvivalent. Například knihovny pro DDE a NetDDE, ovládače ODBC nebo plnohodnotné OLE.

Další omezení zůstávají na zvážení aplikačního inženýra, protože je nelze obecně ošetřit na úrovni systému Control Web. I když je typické používat Windows CE na počítačích s malými zobrazovači s rozlišením 320 × 240 nebo 640 × 480 bodů, existují i zabudovaná PC s obrazovkou s rozlišením 800 × 600 bodů s plnobarevnou grafikou. Několik obrázků s takovým rozlišením dokáže snadno zaplnit mnoho megabytů paměti, a protože Windows CE nemá kde vytvořit odkládací soubor, který by dokázal překlenout momentální nedostatek fyzické paměti, aplikace je ukončena.

Přesto naprostá většina funkcí systému Control Web zůstává zachována i ve verzi pro Windows CE. K dispozici je kompletní sada přístrojů pro vizualizaci, grafickou animaci, zabudovaný dynamický server HTTP apod. Zachována je i plná programovatelnost celého prostředí. Verze pro Windows CE rovněž podporuje síťovou konektivitu s jinými systémy Control Web s výměnou dat, vzdálené aktivace přístrojů apod. V prostředí Windows CE je také možné použít množství ovládačů pro průmyslové automaty, měřicí a akční jednotky apod.

Control Web Runtime pro Windows CE v podstatě odstraňuje nesnáze s tvorbou programového vybavení pro zabudované průmyslové počítače a tím umožňuje jejich široké používání. Jediná architektura aplikací a vzájemná konektivita využívají investice firem do vývojových prostředí i znalosti pracovníků a dovolují jim nasazovat aplikace od clusterů s více počítači až po malá zabudovaná zařízení.