Platnost tohoto pořekadla zjevně není omezena jen na průmysl oděvní konfekce, ale vztahuje se prakticky 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 své 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 nízkou hmotnost a dlouhý provoz na baterie, u osobního organizéru je nízká hmotnost a spotřeba téměř vším. 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á nasazení 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í, zaměřených stále více 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 soustřeďme na kritéria důležitá pro schopnost systémů a aplikací pracovat ve strojích, rozvaděčích a jiných zabudovaných aplikacích, tedy na velikost potřebných zdrojů počítače (především velikosti paměti, ale i výkonu procesoru) 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, dnešní 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 zpracování co největšího počtu 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 na pozadí. Tohoto lze dosáhnout za cenu zavedení řady výjimek ve standardním chování přepínače úloh, které zajišťují preferenci úloh na popředí.

• Pád cen pamětí a nárůst výkonu procesorů nenutí k přílišnému zaobírání se paměťovými nároky. Ukazuje se že zdvojnásobení paměti je vždy jednodušší, levnější a bezpečnější než pracná, zdlouhavá a nejistá snaha optimalizovat aplikaci na nižší spotřebu paměti. Ušetřený čas je možno namísto toho věnovat přidávání nových vlastností, které opět zvyšují nároky na zdroje počítače.

• Náročnost programů na zdroje počítače s sebou přináší nutnost přítomnosti diskové paměti, dnes prakticky jediného dostupného vysoko-kapacitního paměťového média.

• Nedůležitost časově-deterministického zpracování v prostředí kancelářských i inženýrských aplikací vede i vyjmutí pravidel definujících časové chování z definic standardních programových rozhraní. Takže kupříkladu způsob nadržování aplikaci pracující v popředí se tak liší mezi různými implementacemi Win32 API (Windows 9X vs. 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 mezi-procesové synchronizace jsou v prostředí Win32 navrženy z hlediska kancelářských, inženýrských i serverových aplikací velice 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 prováděna tzv. prováděcími toky. Každý proces (aplikace) má alespoň jeden takový tok, ale může jich 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, 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 řadu programových rozhraní umožňující 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čí nějakou činnost. Jinými slovy jeden prováděcí tok čeká na jiný tok. Co se ale stane, pokud 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. Toto 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 provádí přednostně před toky s nízkou prioritou. Problém vyvstane ve chvíli, kdy se stejná situace opakuje rekurzívně - 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 sice systém 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 existuje několik snah proniknout na trh zabudovaných aplikací, například projekt Windows At Work, který zcela neuspěl především díky požití nespolehlivého 16 bitového kódu systémů MS-DOS a Windows v3.1 a 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 (a 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í je 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 kupříkladu nepodporují zabezpečení, jak je známe z Windows NT/2000), ale na druhé straně programátoři API systémů Windows znají a tyto 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 až OEM partneři nasazující jej ve svých řešeních mohli zvolit které komponenty chtějí a které ne a tím výrazně redukovat jeho paměťové nároky.

• 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é 32-bitové 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 řádově stovky KB paměti. Pokud je v systému začleněno grafické uživatelské rozhraní, spotřeba paměti vzroste na několik MB. Vzhledem k dnešnímu stavu vývoje pamětí a jejich ceně není racionální snažit se množství potřebné paměti dále snižovat.

• 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 32-bitové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 provádí 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 časy 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á DLL knihoven, které jsou mapovány na stejné paměťové lokace všech procesů. Adresový prostor pro DLL knihovny každého procesu je tak omezen již zavedenými DLL knihovnami 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 velice košaté. Návrháři se snažili vybrat vždy z několika způsobů, jimiž je možné danou funkčnost ve Windows NT/2000 naprogramovat, zachovat vždy alespoň jediný způsob, ale velmi často se nepodařilo ani to. Řada funkcí ve Windows CE prostě není a je nutné tento nedostatek složitě obcházet, pokud to je vůbec možné.

• Dalším problémem je celkový výkon systému. Windows CE využívají k implementaci řady 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 velice čistá, v praxi přináší značné problémy díky velké režii a samotné Windows NT od této architektury z výkonnostních důvodů ustoupily již ve verzi 4. Díky tomu běží Windows CE na stejném počítači výrazně pomaleji než třeba Windows 98.

• Relativní mladost systému zapříčiňuje poměrně značné množství chyb. Vývojáři se musí připravit na problémy mající původ v systému samotném i ve vývojových nástrojích, které je nutno v aplikacích obcházet. V tomto ohledu ale není situace nijak výjimečná a lze předpokládat, že s vyspíváním Windows CE bude chyb ubývat.

Přes všechny nedostatky představují Windows CE univerzální platformu, 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 se stává volbou výrobců systémů pro průmyslovou automatizaci. Windows CE před jinými systémy pomáhá mimo popularity platformy Windows a síly 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áni času a podporu periferií a aplikace bývá zaintegrová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, pokud je 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 nasazení Windows CE tvorba programového vybavení. Řada výrobců začíná nabízet systém Windows CE pro zabudované aplikace na platformě PC. Oproti jiným verzím Windows to přináší řadu výhod, například schopnost práce bez pevného disku, možnost bezproblémového vypnutí bez nebezpečí poškození souborů na disku a ohrožení dalšího startu systému, rychlý start aplikace po zapnutí apod. Probléme 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í nasazení aplikace ve velkých objemech schopných uhradit vysoké vývojové náklady. 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. Řada techniků, aplikačních inženýrů i studentů jej zná a dokáže efektivně využívat jeho bohatých možností. Ačkoliv aplikace systému Control Web pracují ve velmi velkých systémech skládajících se z řady počítačů propojených lokálními i vzdálenými sítěmi a k dispozici je i verse spolupracující se systémy Windows 2000 Advanced Server zapojenými do clusteru, na druhé straně 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). Verse Control Web Runtime pro Windows CE umožňuje nasadit 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 FLASH pamětí 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 velkou variantností konfigurace Windows CE, neboť OEM výrobce rozhoduje, které komponenty do systému zabuduje a které ne.

Další problém je s instalací produktu. Jen několik implementací Windows CE (například Pocket PC a H/PC) podporuje standardní způsob instalace přes stolní počítač a rozhraní ActiveSync, řada 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, v případě Windows CE je to složitější. Distribuce Control Web Runtime pro Windows CE se snaží 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. Vývoj aplikace pro Windows CE probíhá vždy na 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ů (kupříkladu 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, samozřejmě pokud je na tomto počítači k dispozici stejný hardware, jako bude připojen k počítači s Windows CE, s patřičnými ovladači. I pokud ne, 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 přenechat jen ladění vlastní komunikace.

• Vlastní přenos aplikace na počítač s Windows CE probíhá s pomocí „Průvodce pro export aplikace do Windows CE”. Tento průvodce nabídne uživateli volbu Windows CE platformy, typu procesoru na němž Windows CE pracují, volbu spojení s Windows CE zařízením (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 bývá často k dispozici jen paměť FLASH, na níž je emulován IDE disk. Ovšem takový disk je omezen množstvím zápisových cyklů, které bývá 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. Z tohoto důvodu jsou v Control Web Runtime pro Windows CE omezeny zápisy na disk, např. nejsou tvořeny .log soubory apod. Rovněž nedostupné ve Windows CE jsou virtuální přístroje, které závisí na programových komponentách Windows, které ve Windows CE nemají ekvivalent. Například knihovny pro DDE a NetDDE, ODBC ovladače nebo plnohodnotné OLE.

Další omezení zůstávají na zvážení aplikačního inženýra, protože je není možno obecně ošetřit na úrovni systému Control Web. I když je typické nasazovat Windows CE na počítačích s malými zobrazovači s rozlišením 320x240 nebo 640x480 bodů, existují i zabudované PC s obrazovkou s rozlišením 800x600 bodů s plnobarevnou grafikou. Několik obrázků s takovým rozlišením dokáže snadno zaplnit mnoho MB 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 funkčnosti 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ý HTTP server apod. Zachována je i plná programovatelnost celého prostředí. Rovněž verze pro Windows CE 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žno použít celou řadu ovladačů pro průmyslové automaty, měřicí a akční jednotky apod.

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