TVORBA SYSTÉMOVÝCH MODULŮ PRO PODPORU ŘÍZENÍ V OPERAČNÍM SYSTÉMU MS WINDOWS NT

Transkript

1 VŠB TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ Katedra automatizační techniky a řízení TVORBA SYSTÉMOVÝCH MODULŮ PRO PODPORU ŘÍZENÍ V OPERAČNÍM SYSTÉMU MS WINDOWS NT Souhrn disertační práce Studijní program: 23 0 V Strojní inženýrství Studijní obor: Automatizace technologických procesů, Doktorand: Ing. David FOJTÍK Školitel: Prof. Ing. Jiří Tůma, CSc. Školitel specialista: Dr. Ing. Dalibor Kačmář Ostrava 2004

2 2 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Doktorská disertační práce byla vypracována v rámci doktorského studia na Katedře automatizační techniky a řízení Fakulty strojní VŠB Technické univerzity Ostrava. Oponenti: Prof. Ing. Vladimír Vašek, CSc. FT UTB ve Zlíně Doc. Dr. Ing. Milan Heger, CSc. FMMI VŠB TU Ostrava Doc. Ing. Cyril Klimeš, CSc. PřF Ostravská univerzita v Ostravě Obhajoba disertační práce se koná dne v zasedací místnosti v hodin, v budově VŠB TU Ostrava, tř. 7. listopadu 5, Ostrava Poruba. S disertační prací je možné se seznámit na Studijním oddělení Fakulty strojní VŠB - Technické univerzity Ostrava, tř. 7. listopadu 7, , Ostrava Poruba, místnost A 32.

3 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 3 Úvod Řízení technologických procesů je dnes neodmyslitelně spjato s výpočetní technikou. Již řadu let jsou takto využívány různé počítačové platformy založené na různorodých architekturách. Mezi nimi samozřejmě také počítače řady PC, které se díky značné oblibě a rozšíření čím dál častěji prosazují. S volbou platformy PC je neodmyslitelně spjat výběr vhodného operačního systému. Zde se ihned nabízí nepřeberné množství různých operačních systémů mnoha výrobců, které se více či méně specializují na určitou oblast použití. Z pochopitelných důvodů však mezi významná kritéria výběru operačního systému patří jeho uživatelská známost, vývojářská podpora, dostupnost dalších aplikací, schopnost integrace do podnikové sítě apod. Díky tomu se výběr mnohdy omezí pouze na operační systémy rodiny MS Windows NT a to i přesto, že jejich architektura nebyla k řízení technologických procesů navržena. Vzniká tudíž snaha využít tyto operační systémy ve vizualizačních a dispečerských systémech, v systémech přímého řízení z PC a také v oblasti systémů reálného času. V posledních dvou jmenovaných oblastech je však jejich praktické využití stále poměrně neobvyklé. Důvodem je především náročné programování hardwaru, jenž je zapříčiněno jinak velmi důmyslnou architekturou a také faktem, že operační systémy architektury MS Windows NT zcela nesplňují podmínky potřebné v systémech reálného času. Disertační práce popisuje návrh a praktickou realizaci softwarového doplňku s jehož pomocí je možné přímé řízení z počítače v reálném čase snadno provádět i pod operačními systémy rodiny MS Windows NT. 2 Cíle disertační práce Disertační doktorská práce se především zabývá využitím operačních systémů architektury MS Windows NT k řízení na úrovni těsně spjaté s technologickým procesem a k řízení systémů v reálném čase. Cíle disertační práce lze shrnout do těchto bodů: Rozbor vlastností operačních systémů rodiny Microsoft Windows z hlediska využití v systémech řízení technologických procesů a v systémech reálného času. Analýza možností úprav operačních systémů technologie MS Windows NT pro podporu systémů řízení pracujících v reálném čase. Návrh vlastního řešení doplňku pro podporu řízení v reálném čase pod operačními systémy architektury MS Windows NT. Realizace návrhu s ohledem na jeho snadné používaní s možností rozšíření podle potřeb uživatelů. Ověření funkčnosti navrženého systému na počítačových a fyzikálních modelech s ohledem na chování systému v reálném čase, v závislosti na výkonnosti odlišných hardwarových platforem a jejich zatížení. Souhrn disertační práce

4 4 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 3 Operační systémy rodiny Microsoft Windows a jejich využití v systémech řízení technologických procesů V současné době nejčastěji používané operační systémy rodiny Microsoft Windows lze rozdělit na: Operační systémy úzce spjaté s platformou PC a vycházející ze starších 6-bitových verzí. Zde patří MS Windows 95 a jeho novější verze MS Windows 98/ME. Přenositelné operační systémy založené na nové plně 32-bitové architektuře označované jako NT (New Technology) a používané převážně na platformě PC. Do této skupiny patří MS Windows NT (3.5, 4.0), jeho nástupci MS Windows 2000/XP a také specializované systémy MS Windows NT/ XP Embedded. Operační systémy zcela nové plně 32-bitové architektury určené pro malá zařízení mimo platformu PC. Zde patří MS Windows CE (2.x, 3.0,.NET) a jeho odrůda Pocket PC. 3. Operační systém MS Windows 95 Z hlediska využití operačního systému Windows 95 (98, ME) v oblastech řízení technologických procesů můžeme považovat za pozitivní především relativně snadné programování hardwaru, silné grafické rozhraní, podporu moderních technologií a počítačových sítí. Na druhou stranu je tento operační systém méně stabilní, neoddělitelně svázaný s platformou PC, neschopný využít víceprocesorové systémy apod. Především však je již jeho vývoj ukončen, neboť důvody pro které byl vytvářen (podpora 6-bitových a MS DOS aplikací, nižší nároky na hardware) v dnešní době ztrácí na významu. Z pohledu systémů reálného času je nasazení tohoto operačního systému velmi komplikované. Důvodem je především způsob implementace rozhraní Win32 API, které běží na samostatném virtuálním počítači. Takto vlákna rozhraní Win32 podléhají dvěma plánovačům jednak plánovači virtuálních počítačů a následně pak plánovači rozhraní Win32 API [HOUŠKA]. Odtud vzniká problém odhadu doby odezvy systému na HW přerušení a doby jejich zpracování. V technické praxi je operační systém Windows 95 (98, ME) využíván především v operátorských systémech SCADA/HMI (Supervisory Control And Data Acquisition / Human Machine Interface), tedy v oblasti vizualizace, sběru dat, supervizního řízení apod. Existuje mnoho komerčních aplikací, které nasazení v těchto oblastech značně usnadňují. Jedná se např. o systémy InTouch, CITECT, TIRS, Control Panel a další. Přímé řízení systémů je v tomto operačním systému spíše neobvyklé, převážně realizované pouze v laboratorních systémech. I pro tuto oblast využití existují podpůrné komerční aplikace [KUCHAŘ] například: Logic Scanner LS25, Control Web, Control Panel, Real-Time Toolbox apod. Některé z nich navíc svým způsobem řeší problémy s realtimovostí tohoto systému. 3.2 Operační systémy rodiny MS Windows NT Z hlediska využití toho operačního systému v oblastech řízení technologických procesů mu lze vytknout komplikované programování hardwaru, jenž vždy vede na tvorbu ovladačů. Daleko horší je to však z pohledu požadavků na přímé využití k řízení systémů reálného času (viz kapitola 4.2). V technické praxi je operační systém MS Windows NT/XP/2000 obdobně jako MS Windows 95 převážně využíván v operátorských systémech SCADA/HMI. Taktéž řada vývojových nástrojů a aplikací usnadňujících jeho nasazení v této oblasti je obdobná. K řízení systému přímo z počítače jsou spíše předurčeny klony těchto operačních systémů a to MS Windows NT Embedded a MS Windows XP Embedded [MICROSOFT 2003]. Oproti klasickým verzím se odlišují schopností se zavádět z nepřepisovatelného zdroje (ROM, CD), nižšími požadavky na paměť (2 MB RAM, 8 MB pevné paměti např. ROM), absencí potřeby klasického vstupního a výstupního zařízení (monitoru, klávesnice, myši) a především svou modularitou, díky které je možné jej sestavit podle požadavků, cílového zaměření apod. Vnitřní architektura je však u obou operačních systémů s klasickými verzemi naprosto shodná. Nabídka komerčních řešení podporujících nasazení operačních systémů architektury Windows NT k přímému řízení je oproti Windows 95 o poznání bohatší. Například již od verze

5 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 5 MS Windows NT 4.0 jsou k dispozici systémy [KUCHAŘ]: OpenControl, Pyradim-3, WinAC Basic, WinAC Pro, InControl 7.0, Think & Do, Soft Logic 5 apod. Mnohé z nich také rozšiřují schopnosti a odstraňují nedostatky tohoto operačního systému tak, aby jej bylo možné použít i k řízení systémů reálného času. Speciálně pro potřebu systémů reálného času je navíc k dispozici rozšiřující doplněk RTX (Real Time extension) firmy VenturCom [O KEEFE], jenž samozřejmě podporuje i vývojově nejnovější verze MS Windows XP a MS Windows XP Embedded. 3.3 Operační systém MS Windows CE Microsoft Windows CE je 32-bitový univerzální operační systém určený pro malá zařízení mimo platformu PC, která jsou typicky bezdisková s omezenou kapacitou paměti. Díky vytvořené tenké vrstvě kódu, nacházející se mezi jádrem a hardwarem je Windows CE adaptivní na specifické hardwarové platformy. Operační systém MS Windows CE [BELLO] se od ostatních Windows operačních systémů odlišuje především svou modularitou. To znamená, že je možné jej uživatelsky sestavit pro požadovaný produkt z dostupných softwarových modulů tak, aby vyhověl přísným omezením ohledně paměti a velikosti u většiny elektronických přístrojů. Výběrem nejmenšího množství požadovaných modulů (komponent), vyhovujících systémovým požadavkům může OEM (Original Equipment Manufacturer) minimalizovat potřebnou paměť, splňující potřebu operačního systému. Ve svém důsledku takto můžou existovat (a také existují) zařízení, která nemají žádné grafické rozhraní, neboť jej nepotřebují. Operační systém Windows CE je specificky zaměřen na OEM výrobce a na nezávislé dodavatele hardwaru IHV (Independent Hardware Vendor). Oproti ostatním Windows operačním systémům, které jsou dodávány ve formě softwarových balíků, jsou Windows CE navrženy pro zabudování do paměti ROM. Z pohledu přímého řízení a řízení v reálném čase má operační systém Windows CE nejlepší vlastnosti z celé rodiny operačních systémů MS Windows [MICROSOFT 998B, MICROSOFT 2003]. V oblasti řízení je nejčastěji využíván v operátorských multifunkčních panelech (například: SIMATIC MP270 [KABEŠ]) a v průmyslových počítačích velmi těsně spjatých s technologickým procesem (například: H2-WPLC, Runtime PC [PROKEŠ]). 4 Operační systémy technologie MS Windows NT a systémy reálného času Existují systémy, které vyžadují okamžitě v tzv. kritickém čase zpracování svých požadavků. Jejich společným znakem je vysoká náročnost na rychlost a čas, ve kterém se musí vzniklé podněty zpracovat, jinak je správná činnost narušena, někdy i s katastrofálními následky. Obecně je označujeme jako systémy reálného času. Nejčastěji užívaná definice těchto systému zní [COMP.REALTIME]: "Systém reálného času je systém, ve kterém je správné počínání závislé nejen na bezchybném logickém výpočtu, ale také na čase, ve kterém je vyřešen." Pro úplnost je třeba doplnit, že onen čas, uvedený v definici, je uvažován za velmi krátký, natolik krátký, že ho nelze zaručit libovolnou volbou komponent systému. Je důležité rozlišovat mezi systémem reálného času a operačním systémem reálného času označovaném jako RTOS (Real-Time Operating System). Reálný čas systému je závislý na všech prvcích systému (hardwaru, operačním systému a aplikaci), které jsou potřebné k jeho existenci. RTOS je právě jeden prvek z celkového systému reálného času, který musí poskytovat potřebné funkce umožňující vznik tohoto systému a musí vyhovovat jeho požadavkům. 4. Definice a požadavky na operační systém reálného času Nejčastěji se setkáváme s definicí, jejíž citace zní [COMP.REALTIME]: "RTOS je systém, který zpracovává libovolnou možnou událost nebo kombinaci událostí předem determinovatelným způsobem." Souhrn disertační práce

6 6 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Pojem determinovatelný způsob zpracování znamená, že je jednoznačně dán sled zpracování jednotlivých událostí (pomocí priorit) a tudíž je možné pro libovolnou událost určit maximální čas potřebný k jejímu zpracování. Důležitější než definice jsou však požadavky, které by měl RTOS splňovat [COMP.REALTIME]:. RTOS musí podporovat preemptivní multitasking. 2. RTOS musí podporovat mechanizmus zpracovávání vláken podle priorit. 3. RTOS musí poskytovat mechanizmus řešení problému "inverze priorit". 4. RTOS musí podporovat predikovatelné možnosti synchronizace běžících vláken. Navíc musí být chování operačního systému předvídatelné. To znamená, že projektanti systémů reálného času musí být dobře informováni o úrovni systému přerušení, systémovém volání a časování. Tyto požadavky lze charakterizovat takto: Musí být známá maximální doba, během které jsou maskována přerušení operačním systémem a ovladači zařízení. Prodleva přerušení (doba od přerušení k následnému běhu vlákna) musí být předvídatelná a kompatibilní s požadavky aplikace. Doba každého systémového volání by měla být předvídatelná a nezávislá na počtu objektů v systému. Často se také můžeme setkat s rozdělením RTOS podle přísnosti požadavku kladeného na dodání výsledku v požadované lhůtě a to na hard a soft systémy. Nasazení soft RTOS je možné v systémech, které sice vyžadují dodání výsledku do určité lhůty, ale její nedodržení se v závislosti na velikosti zpoždění projeví pouze snížením kvality daného procesu. Jinak řečeno, nedodání výsledku v požadované době nezpůsobí krach systému. U těchto RTOS je obvykle uváděná pravděpodobnost (okolo 95 %) dodržení požadovaného limitu. Oproti tomu hard RTOS je vyžadován v systémech, kde nedodržení požadovaného limitu na dodání výsledku způsobí úplné selhání systému. Jinak řečeno, dodání výsledku po tomto limitu je srovnatelné s nedodáním výsledku vůbec. 4.2 Srovnání vlastností operačních systémů platformy MS Windows NT s požadavky na RTOS Operační systémy platformy MS Windows NT nebyly koncipovány jako RTOS a tudíž nevyhovují všem výše kladeným požadavkům. V následujícím textu se zaměříme na ty aspekty a vlastnosti, jenž vedou k tomuto tvrzení Preemptivní zpracování vláken a problém inverze priorit MS Windows NT/2000/XP je víceúlohový preemptivní operační systém. Každý proces vlastní minimálně jedno prováděcí vlákno, které je zodpovědné za vykonávání kódu procesu. Systém přiděluje jednotlivým vláknům tzv. časová kvanta, po kterých jsou zpracována procesorem počítače. Přidělování tohoto kvanta je řízeno na základě 32 úrovní priorit, které mohou vlákna nabývat (0 - speciální použití, - nejnižší možná, 3 - nejvyšší). Vlákna stejných priorit jsou považována za rovnocenná, tudíž jim systém přiděluje cyklicky stejná časová kvanta. Z pohledu RTOS jsou zajímavé pouze priority vláken třídy real-time (rozmezí 6 až 3). Z tohoto intervalu jsou však určité priority nedostupné, tudíž je nemohou aplikace využít [JEFFREY]. Ve skutečnosti je tak k dispozici pouze sedm úrovní priorit (6, 22 26, 3), což často bývá označováno jako jeden z nedostatků tohoto systému pro oblast aplikací reálného času. Daleko závažnější však je, že systém v oblasti real-timových priorit neposkytuje mechanizmus řešení problému inverze priorit. Problém je doprovodným jevem víceúlohových operačních systémů, kde je potřeba poskytnout nástroje pro uzamykání zdrojů k výhradnímu přístupu jedné úlohy.

7 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 7 Průběh Priorita Úloha C Úloha B Úloha A - Vlákno běží - Vlákno čeká - Uzamčený zdroj Zdroj Čas [ms] Obr. 4. Princip vzniku inverze priorit Tento jev vzniká (viz obr. 4.), když vlákno (C) s vysokou prioritou čeká na uvolnění zdroje, který je uzamčen vláknem s nízkou prioritou (A). Tento zdroj však vlákno nízké priority nemůže uvolnit, protože je přerušeno vláknem (B) střední priority. Tak dochází k tomu, že vlákno (C) vysoké priority je pozastaveno činností vlákna (B) střední priority. Inverze priorit je velmi nebezpečná v případě, že úloha se střední prioritou provádí dlouhodobý nepodstatný úkol a přeruší tak úlohy nutné k provozu Vstupně výstupní systém a správa přerušení Pro bezchybný chod RTOS je nezbytné, aby vykonávání libovolného vlákna (a to i s nejvyšší prioritou 3) neblokovalo hardwarové přerušení. Dále je nutné zajistit mechanizmus obsluhy hardwarového přerušení podle priorit. V systémech Windows NT je problém vyřešen mechanizmem 32 úrovní IRQL. Respektive, každá činnost je prováděná s jistou úrovní IRQL. Je-li prováděna činnost s vyšší úrovní IRQL, jsou všechny požadavky stejné a nižší úrovně maskovány. Přerušit tuto činnost může pouze požadavek s vyšší úrovní IRQL. Jsou-li všechny požadavky vyšší úrovně dokončeny, systém samočinně úroveň sníží a umožní tak zpracování požadavků nižší úrovně. Nejvyšší priorita Úrovně IRQL 3 Kritická chyba HW Nejnižší priorita 30 Výpadek napájení Priority Win32 API vláken Hardwarová přerušení Softwarová přerušení 29 Meziprocesorová synch. 28 Přerušení časovače 27 ISR - Zařízení 26 ISR - Zařízení 2 4 ISR - Zařízení n 3 Ladění programů/aplikací 2 DPC APC 0 Vlákna Win32 API Režim jádra Uživatelský režim 3 Časově kritická 24 Normální 6 Klidová 5 Kritická: všechny třídy 3 Normální: třída vysoká 8 Normální: třída normální 4 Normální: třída klidová Klidová: všechny třídy 0 Podproces nulové stránky Priority reálného času Proměnné úrovně priorit Třída: Vysoká, Normální, Klidová Obr. 4.2 Kompletní rozlišení úrovní priorit všech činností v operačních systémech NT architektury Jak vyplývá z obrázku 4.2, má každé hardwarové zařízení generující přerušení IRQ přiřazenou určitou úroveň IRQL. Na této úrovni je vykonávána rutina obsluhy přerušení ISR (Interrupt Service Routine) daného zařízení. Tato rutina provádí pouze nezbytné činnosti, které Souhrn disertační práce

8 8 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT nesnesou odklad. Vše ostatní se přenechává rutině DPC (Deferred Procedure Call), která je vykonávána na úrovni IRQL 2. Pro vlákna procesů jsou vyčleněny úrovně IRQL 0 nebo IRQL. Ve většině případů jsou tato vlákna vykonávána s úrovní IRQL 0, pouze obsluha APC (Asynchronous Procedure Call) je vykonávaná s úrovní IRQL [JEFFREY]. Na těchto úrovních jsou již vlákna zpracována podle již zmíněného mechanizmu priorit (0 3). Uvedený dvoufázový mechanizmus (ISR-DPC) obsluhy přerušení, používající velmi krátkých těl ISR funkcí, umožňuje zbytečně neblokovat ostatní přerušení IRQ. Tato vlastnost je z pohledu RTOS považována jako vysoce pozitivní. Bohužel však použitý mechanizmus fronty DPC není z tohoto pohledu vhodně navržen. Problémem totiž je, že fronta DPC používá mechanizmus FIFO (First In First Out) a tedy vkládané úlohy jsou zpracovány podle pořadí, v jakém byly vloženy a ne podle priority přerušení nebo priority aplikace Dostupné časovače systému Operační systémy architektury NT nabízejí hned několik nástrojů umožňující periodicitu operací. Teoreticky lze všechny tyto nástroje nastavit s přesností až na jednu milisekundu. Prakticky však této přesnosti za určitých okolností dosahuje pouze nejpřesnější [MICROSOFT 2003] Multimediální časovač původně navržen pro multimediální aplikace. S Multimediálním časovačem lze v relativně nezatíženém systému zajistit vykonávání periodické činnosti s frekvencí až khz. Tuto minimální periodu však může ovlivnit zvýšené zatížení systému, především procesy svázané s obsluhou periferních zařízení (spouštění aplikací, síťová komunikace, otevírání dokumentů apod.). Díky tomu se může vykonání činnosti opozdit i o stovky milisekund. Kromě zmiňovaných vlastností má operační systém i jiné nedostatky, které způsobují jeho nevhodnost pro systémy reálného času. Jedná se především o obtížný odhad doby běhu systémových funkcí, neboť je závislá na počtu objektů a vytížení systému. Všechny uvedené nedostatky pak lze shrnout do několika bodů: Nízký počet real-time priorit. Obtížný odhad doby průchodu informace od vzniku přerušení k předání aplikaci v případě použití architektury DPC. Neřešená problematika vzniku inverze priorit v oblasti třídy real-timových priorit. Absence přesného a spolehlivého mechanizmu zajišťujícího vzbuzení vlákna v přesně stanovenou dobu. Respektive, nepřesný časovač generující události. Obtížný odhad doby běhu systémových funkcí jádra operačního systému. 5 Návrh podpory řízení v reálném čase Řízení v reálném čase tvoří jen část možných aplikací nasazovaných v systémech reálného času. Tyto aplikace mají svá specifika, díky kterým jsou určité požadavky na RTOS méně důležité a naopak jiné získávají na váze. Specifické požadavky aplikací řízení v reálném čase jsou: Zajištění opakovaného provádění algoritmu regulace s přesnou periodou obvykle velmi krátkou. Podpora pro okamžitý přístup ke speciálnímu typu hardwaru počítače. Celková doba potřebná ke zjištění regulované veličiny, provedení výpočtu a nastavení akční veličiny musí být determinovatelná. Cílem návrhu je nalezení řešení, které tyto požadavky dokáže naplnit i v prostředí operačních systémů architektury Windows NT. Jedním z možných řešení je přenesení řídicí části do nižších vrstev systému, respektive do nízkoúrovňového ovladače, nejlépe do rutiny ISR. Vlastní nízkoúrovňový ovladač pak může přímo vykonávat řídicí algoritmus a poskytovat

9 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 9 vyšším vrstvám (uživatelské aplikaci) pouze možnost nastavit parametry regulace, monitorovat její průběh apod. Tím se nabízí možnost generování přesné periody s využitím nezávislých hardwarových časovačů ve formě obsluhy opakovaně generovaného přerušení. Níže popisovaný mechanizmus řízení v reálném čase v systémech architektury MS Windows NT je založený právě na tomto řešení. 5. Funkční principy a požadavky na strukturu ovladače Princip navrhovaného řešení využívá možnosti vytvořit speciální nízkoúrovňový ovladač doplňkového hardwarového zařízení (multifunkční karty) s vlastními časovači, které by umožnily periodicky volat přerušení IRQ. V obsluze přerušení (rutina ISR) se pak již provede časově kritická operace (algoritmus regulace) na vysoké úrovni IRQL. Implementací algoritmu regulace do rutiny ISR se však ztrácí určitá flexibilita, kterou má programátor k dispozici v případě běžného umístění algoritmu v aplikačních vrstvách. Je proto nutné pečlivě volit daný regulátor s ohledem na maximální možné využití v převážné většině řízených systémů, nebo lépe nabízet sadu různorodých regulátorů s možností jejich výběru. PC s MS Windows NT/2000/XP Řízená soustava Uživatelský software Nízkoúrovňový ovladač karty IRQ Multifunkční karta Technologický proces Výběr typu regulátoru včetně nastavení všech jeho parametrů w Výpočet odchylky e Algoritmus regulace (Rutina ISR) u y Časovače D/A A/D Akční veličina Regulovaná veličina Obr. 5. Zjednodušené schéma regulačního obvodu Na základě uvedených požadavků a na uvedeném principu řešení byly sestaveny základní požadavky na strukturu a funkčnost ovladače, které lze shrnout do těchto bodů:. Ovladač v první řadě musí mapovat obsluhu přerušení (rutinu ISR) na patřičný kanál IR podle příslušných požadavků. 2. Současně by měl ovladač podporovat správu většího počtu rutin ISR tak, aby bylo možné pro každý typ periodické činnosti vytvořit zcela nezávislou rutinu dynamicky zaváděnou až podle konkrétních představ uživatele. 3. Ovladač by měl poskytovat sadu realizovaných regulátorů, ze kterých si uživatel snadným postupem podle potřeb vybere. Počet nabízených regulátorů by neměl být konečný, respektive struktura ovladače by měla umožnit další regulátory přidat. 4. Všechny nabízené regulátory by měly být v maximální míře uživatelsky stavitelné včetně možnosti výběru konkrétního analogového vstupu (výstupu) pro regulovanou (akční) veličinu. Žádaná veličina by měla být stavitelná i za chodu regulace. 5. Součástí každého regulátoru by měl být spolehlivý mechanizmus předávaní informací o jeho průběhu uživatelským aplikacím. Daný mechanizmus nesmí ovlivnit schopnost řídit v reálném čase. 6. Ke snížení výpočetních nároků by měl daný ovladač poskytovat možnost předávat tyto informace ve skupinách. Mechanizmus předávání dat by měl být navržen tak, aby nedocházelo k jejich ztrátám. 7. Ovladač by měl poskytovat možnost nastavování a čtení všech výstupů a vstupů karty tak, aby mohl být využit i pro oblast měření či regulace v systémech nevyžadujících reálný čas. 8. Kromě regulace by měl ovladač poskytovat mechanizmus zajišťující nepřetržitě opakované měření uživatelsky zvolených vstupů s přesnou a obvykle vysokou vzorkovací frekvencí. U této činnosti je zcela nezbytné zabezpečit bezztrátové zasílání naměřených dat uživatelským aplikacím. Souhrn disertační práce

10 0 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 9. Při návrhu všech činností ovladače by měl být brán zřetel na maximální nezávislost realizovaného řešení na konkrétním doplňkovém hardwaru. Konstrukce ovladače by měla být realizovaná tak, aby bylo možné s minimálními úpravami ovladač přenést a aplikovat na libovolný typ doplňkového hardwaru splňující základní požadavky. 0. Existuje řada regulátorů mnohdy vícerozměrných nebo integrujících hned několik vstupních veličin, které jsou navrženy přímo pro konkrétní technologický proces a tudíž je nelze dopředu v ovladači implementovat. Ovladač by tudíž měl poskytnout možnost snadno i takovýto regulátor dodatečně realizovat.. Tvorba jakéhokoliv algoritmu je téměř vždy spojena s laděním, které v případě rutin ovladače není snadné [FOJTÍK 2000A]. Ladění ovladačů vyžaduje již hlubší znalosti principů jejich tvorby a speciální softwarové i hardwarové vybavení, které ne vždy bude mít uživatel k dispozici. Na tuto skutečnost by měl návrh ovladače pamatovat a umožnit tak konkrétní algoritmus předem realizovat a odzkoušet v uživatelském režimu s plnou podporou kompilátorů aplikací Win32 API. 2. Užití ovladače by mělo být poměrně snadnou záležitostí jak z pohledu programátora uživatelských aplikací tak také z pohledu koncového uživatele. Součástí ovladače by tak měla být snadno ovladatelná uživatelská aplikace umožňující využít veškeré uvedené vlastnosti ovladače. 5.2 Požadavky na vlastnosti doplňkového hardwaru V převážné většině případů je pro řízení z PC použita analogová multifunkční karta vybavená jak analogovými vstupy tak výstupy. Pro náš případ je však nutné mít k dispozici také hardwarové čítače umožňující periodicky generovat přerušení IRQ. Mnohé typy zmíněných multifunkčních karet těmito čítači disponují obvykle pro účely periodicky opakovaného měření zvolených vstupů. Shrneme-li uvedené poznatky, můžeme požadavky na nezbytné multifunkční analogové zařízení charakterizovat takto:. Zařízení musí obsahovat patřičné analogové vstupy a výstupy k získávání a nastavení regulované a akční veličiny. 2. Zařízení musí nabízet možnost generovat v počítači přerušení IRQ nejlépe s možností volby jeho kanálu. 3. Zařízení musí nabízet přesné čítače schopné přerušení IRQ periodicky zahajovat a to buď přímo, nebo lépe jako důsledek ukončení A/D převodu. 5.3 Doprovodné problémy Přenesení těla algoritmu do rutiny ISR ještě nezajišťuje vždy zaručenou odezvu a tím přesnou vzorkovací periodu. Rutinu ovlivňují jiné obsluhy přerušení, jejíž úroveň IRQL je shodná nebo vyšší a některé systémové činnosti, jenž mohou na určitou dobu maskovat veškerá přerušení. Navíc systémem automaticky přiřazená úroveň IRQL se ne vždy dá předem odhadnout, dokonce může být na tomtéž počítači pokaždé jiná. Vše se totiž odvíjí od příslušného řadiče přerušení a typu operačního systému. Chceme-li vylepšit determinovatelnost obsluhy a tím zkvalitnit přesnost vzorkování musíme detailně pochopit jak hardwarové tak softwarové řešení mechanizmu správy požadavků a obsluh přerušení. Nutné je tudíž provést důkladnou analýzu těchto mechanizmů v závislosti na typu operačního systému a hardwarového řadiče přerušení. Na základě této hluboké analýzy je pak možné kvalifikovaně navrhnout a realizovat případná vylepšení, jenž z pohledu požadavků reálného času vlastní regulaci zkvalitní. S implementací složitých matematických algoritmů do těla rutiny ISR však vzniká zcela nečekaný problém. Kompilátor ovladačů pro operační systémy architektury MS Windows NT totiž nepodporuje operace s reálnými čísly a algoritmy regulátorů se jen těžko bez aritmetiky reálných čísel realizují. Odtud je důležité nalézt efektivní řešení daného problému a umožnit tak zcela svobodně algoritmy realizovat.

11 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 6 Implementace aritmetiky reálných čísel Absence podpory aritmetiky reálných čísel značně komplikuje implementaci složitějších matematických operací (jako jsou například regulační algoritmy) přímo do funkcionality ovladače. K řešení lze najít hned několik cest:. upravit potřebné algoritmy tak, aby vystačily s celočíselnou aritmetikou, 2. vytvořit vlastní funkcionalitu reálných čísel, 3. softwarově realizovat funkcionalitu reálných čísel dle standardu IEEE 754, 4. použít standard reálných čísel IEEE 754 s využitím matematického koprocesoru. Posuzováním všech možností se svými přednostmi a nevýhodami se jeví jako nejvýhodnější použití formátu čísel dle standardu IEEE 754 s vlastními algoritmy numerických operací [KAHAN, SHAABAN]. Pro náš účel je zcela dostatečný formát reálného čísla se základní přesností (Single Precision), jemuž odpovídá Win32 API typ FLOAT. V tomto formátu je reálná hodnota uložena ve 32 bitech (viz obr. 6.) S E M Sign Exponent Mantissa FloatValue = (-) S 2 E-27,M Obr. 6. Formát reálného čísla základní přesnosti dle standardu IEEE 754 [SHAABAN] Formát čísla je navržen tak, že mantisa v normalizovaném tvaru vždy začíná binární jedničkou. Ta se z důvodu úspory neukládá, tudíž základ čísla se uchovává s rozlišením 24 bitů ve formě,m. Předpokládáme-li použití maximálně 6-ti bitových převodníků vidíme, že přesnost čísla je pro náš účel plně dostačující. Princip uložení reálného čísla nejlépe vyjadřuje obrázek ,625 0, = ,5 0,25 + 0, , , = 0 0,5 + 0,25 = 0,625 S E = 30 M = 0,32825 (-) S 2 E-27,M = 2 3,32825 = 0,625 Obr. 6.2 Příklad binární podoby 32 bitového reálného čísla 0,625 dle standardu IEEE 754 K realizaci algoritmů regulátorů potřebujeme kromě vlastní prezentace reálné proměnné také operátory základních matematických operací (+, -, *, /) a převodní funkce z/do celočíselných proměnných. K tomuto účelu byla vytvořena knihovna funkcí realizující všechny potřebné operace. Seznam některých funkcí je uveden v tabulce 6.. Tab. 6. Seznam vybraných funkcí a maker pro práci s reálnými čísly v rutinách ovladačů Název funkce/makra R32TOUSHORT R32FROMUSHORT Popis Makro převádějící reálné číslo na celočíselný USHORT. Makro převádějící celočíselný USHORT na reálné číslo. Souhrn disertační práce

12 2 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Název funkce/makra r32sum r32add r32diff r32mul r32div Popis Funkce součtu dvou reálných 32 bitových čísel. Funkce přičtení druhého 32 bitového reálného čísla k prvnímu. Funkce rozdílu dvou reálných 32 bitových čísel. Funkce součinu dvou reálných 32 bitových čísel. Funkce podílu dvou reálných 32 bitových čísel. 7 Hardwarová realizace obsluhy zařízení v PC Procesory x86 kompatibilní mají dva na sobě nezávislé signály přerušení. Prvním je nemaskovatelný signál NMI, jenž je vyhrazen především k signalizaci katastrofických stavů (výpadek napájení, chyba parity apod.). Druhým je již maskovatelný vstup INTR společně sloužící všem periferním zařízením ke vznášení požadavků na obsluhu. Signál má nižší prioritu nežli NMI a je možné jej během zpracování kritických operací zablokovat (maskovat). Existence pouze jednoho společného vstupu INTR vznáší problém jak rozpoznat, které zařízení o obsluhu žádá, jak ošetřit možné kolize v případě žádosti několika zařízení najednou, či jak určitá zařízení přednostně obsloužit apod. Tento problém se na platformě x86 řeší buď pomocí přídavného obvodu 8259A (často označovaný zkratkou PIC Programable Interrupt Controler), nebo nověji obvody APIC (Advanced Programable Interrupt Controler). 7. Hardwarová správa přerušení s využitím obvodů 8259A Zaměříme-li se na procesory x86 kompatibilní, lze činnost obvodu popsat následovně: Předpokládejme, že každé jednotlivé periferní zařízení je připojené na samostatný vstup IR a programovacími prostředky byly zaregistrovány obslužné rutiny jednotlivých zařízení. Zařízení, jenž vyžaduje pozornost procesoru, oznámí požadavek obvodu 8259A zvýšením úrovně - popřípadě pulsem na přiřazeném kanálu IR. Přijme-li obvod žádost o přerušení, zvýší úroveň na výstupu INT který je propojen na vstup INTR procesoru a takto požádá procesor o přerušení (viz obr. 7.). Procesor potvrdí přijetí žádosti impulsy, během kterých obdrží index do tabulky vektorů přerušení. Hodnota indexu je pro každý IR vstup jedinečná a je obvodu programově sdělena při inicializaci. V tabulce vektorů přerušení se nachází adresa kódového segmentu a ukazatele instrukcí obslužné rutiny přerušení. Procesor následně tuto rutinu začne vykonávat a po ukončení se navrátí zpět do totožného místa před vznikem přerušení. V počítačích IBM PC a PC/XT byl použit pouze jeden obvod přerušení 8259A, kterým bylo k dispozici osm kanálů IR. S příchodem počítačů PC/AT byl počet IR kanálů rozšířen na 5 přidáním dalšího obvodu přerušení [ASPINWALL, MUELLER]. Obvody jsou řazeny do kaskády, kde podřízený obvod je propojen na vstup IR2 nadřízeného obvodu (viz obrázek 7.). Adresní sběrnice Datová sběrnice CPU Řídící sběrnice INTR CS A0 D0 D7 INTA 8259A Slave A0 H RD WR INT CAS 0 CAS CAS 2 CS A0 CAS 0 CAS CAS 2 D0 D7 INTA 8259A Master 20 H RD WR INT IR5 IR4 IR3 IR2 IR IR0 IR9 IR8 IR7 IR6 IR5 IR4 IR3 IR2 IR IR0 Obr. 7. Zjednodušené schéma standardního zapojení obvodu 8259A

13 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 3 Původní vstup IR2 je nahrazen vstupem IR podřízeného obvodu tak, že starší zařízení využívající IRQ2 jsou automaticky přesměrovány k používaní IRQ9. V případě použití speciálního režimu úplného vnoření mají žádosti o přerušení podřízeného obvodu vyšší prioritu, nežli žádosti na vstupech IR3 IR7 řídicího obvodu (tab. 7.). Tab. 7. Kanály přerušení v počítačích PC/AT Priorita IRQ Zařízení Nejvyšší 0 Systémové hodiny Klávesnice 8 Hodiny reálného času 2,9 Původní IR2/Rezervováno 0 Rezervováno Rezervováno 2 PS/2 Myš 3 Matematický koprocesor 4 Pevný disk 5 Rezervováno 3 Sériové rozhraní COM2/COM4 4 Sériové rozhraní COM/COM3 5 Rezervováno/Zvuková karta 6 Disketová jednotka Nejnižší 7 Paralelní port 7.2 Hardwarová správa přerušení s využitím obvodů APIC I přes nesporně výbornou koncepci, díky které obvod 8259 původně navržený již pro 8-mi bitové procesory Intel 8080 je s drobnými úpravami používán dodnes, se stal z pohledu požadavků kladených na dnešní počítače PC poněkud zastaralým. Hlavními důvody jsou zejména: a) malý počet kanálů přerušení, b) správa priorit požadavků fyzicky závislá na připojeném kanálu, c) nepoužitelnost obvodu ve víceprocesorových systémech. Architektura APIC [INTEL CORPORATION 996, INTEL CORPORATION 997A, INTEL CORPORATION 997B, INTEL CORPORATION 997D] byla od počátku navrhována pro užití jak v jednoprocesorových tak především ve víceprocesorových systémech, ale také s ohledem na možné nasazení starších operačních systémů vyžadující plnou kompatibilitu s obvodem 8259A. Prakticky jsme se s ní až donedávna mohli setkat pouze ve víceprocesorových systémech. S příchodem procesorů Pentium 4 se však podpora architektury zahrnula i do čipových sad jednoprocesorových systémů [INTEL CORPORATION 2002]. Systém APIC se skládá ze dvou vzájemně komunikujících vrstev: a) z vrstvy označované jako IOAPIC (I/O Advanced Programmable Interrupt Controller) [INTEL CORPORATION 996, INTEL CORPORATION 2002], která přijímá požadavky na přerušení od periferních zařízení a podle softwarového nastavení jej předává druhé vrstvě, b) z vrstvy LAPIC (Local Advanced Programmable Interrupt Controller) [INTEL CORPORATION 997B], která je samostatná pro každý procesor systému a přijímá (nebo také generuje) požadavky na přerušení a distribuuje je procesoru. Jednotliví členové systému jsou propojeni interní sériovou sběrnicí (APIC Bus) o třech vodičích (viz obr. 7.2). Přes tuto sběrnici jsou vznášeny a stvrzovány všechny žádosti směrem Souhrn disertační práce

14 4 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT od obvodu IOAPIC k procesorům i navzájem mezi jednotlivými procesory (vše přes vlastní LAPIC obvody). Local Interrupt CPU Local Interrupt CPU 2 Local Interrupt CPU 3 LINT0 LINT LAPIC LINT0 LINT LAPIC LINT0 LINT LAPIC APIC Bus PICCLK PICD0 PICD IR0 IR5 2x 8259A (82C59) Clock I/O APIC (82093AA) PIIX3/4 Obr. 7.2 Zjednodušené schéma konfigurace systému APIC 7.2. I/O APIC (IOAPIC) IOAPIC je obvykle součástí čipových sad především víceprocesorových systémů. Hlavní náplní obvodu je přijímat požadavky na přerušení od periferních zařízení a ihned je přes interní sběrnici distribuovat jednotkám LAPIC. Obvod poskytuje 24 IR vstupů, které lze navzájem nezávisle programově řídit. Při návrhu obvodu byl také brán zřetel na zachování kompatibility a podporu souběžné činnosti s obvodem 8259A. S patřičným nastavením je tak možné i na víceprocesorovém systému provozovat starší operační systémy vyžadující činnost 8259A. V jednoprocesorových systémech je navíc často možné prostřednictvím BIOSu počítače si zvolit mechanizmus správy s podporu APIC nebo 8259A (obvykle v BIOSu označované zkratkou PIC). Obvod IOAPIC nevyhodnocuje priority požadavků na přerušení, ale ihned všechny žádosti dle nastavení distribuuje procesorům. O přijetí či pozdržení požadavku tak rozhoduje lokální jednotka LAPIC Local APIC (LAPIC) Jednotka Local APIC byla poprvé integrována již do druhé generace procesorů Pentium (od verze 735/90 a 85/00) [INTEL CORPORATION 997B] a je od té doby součástí všech modelů řady Pentium. Hlavní náplní lokální jednotky APIC lze shrnout do následujících bodů: Identifikovat a přijímat na sběrnici APIC požadavky na přerušení zaslaných obvodem I/O APIC nebo jinou lokální jednotkou LAPIC. Vyhodnocovat prioritu právě zpracovávaného přerušení a porovnávat ji s prioritou nově došlých požadavků. Na základě vyhodnocení priorit a typu požadavků generovat příslušné přerušení na procesoru (INTR/NMI) a následně předat patřičný vektor přerušení. Spravovat a generovat (odesíláním požadavků na sběrnici APIC Bus) požadavky na meziprocesorové přerušení. Jednotka LAPIC provádí řízení požadavků výhradně pro žádosti zpracovávané primárně obvodem I/O APIC. Každý takovýto požadavek je obvodem I/O APIC doplněn o příslušný vektor přerušení a odeslán jednotkám LAPIC. Právě vektor přerušení rozhoduje o prioritě požadavku. Lokální jednotka APIC rozlišuje 240 vektorů v intervalu Z toho však 6 3 je exkluzivně vyhrazeno pro procesor. Vlastní úroveň priority se vyhodnocuje vztahem Priorita = Vektor / 6, kde je nejnižší priorita a 5 nejvyšší [INTEL CORPORATION 997B].

15 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 5 8 Správa přerušení v MS Windows NT/2000/XP 8. Správa přerušení v systémech s obvody 8259A Operační systém přiřazuje obsluhám přerušení úroveň IRQL již při zavádění ovladače [MICROSOFT 998A, MICROSOFT 2000]. V systémech založených na obvodu 8259A je vztah přiřazené úrovně IRQL pro daný požadavek IRQ uveden v tabulce 8.. Tab. 8. Vztah mezi úrovněmi IRQL a žádostmi IRQ IRQL IRQ Popis 3 - Kritická chyba hardwaru Výpadek napájení Přerušení pro víceprocesorovou synchronizaci Přerušení časovače Profily. 26 Klávesnice Výstup INT podřízeného řadiče Sériové rozhraní COM2/COM Sériové rozhraní COM/COM Rezervováno/Zvuková karta. 2 6 Disketová mechanika Paralelní port. 9 8 Hodiny reálného času. 8 9,2 Původní IRQ2 nebo IRQ9. 6,7,0 Rezervováno. 5 2 PS/2 Myš. 4 3 Matematický koprocesor. 3 4 Pevný Disk. 2 5 Rezervováno. 4 - Nepoužité priority. 3 - Softwarové přerušení pro ladící účely. 2 - Softwarové přerušení pro DPC. - Softwarové přerušení pro APC. 0 - Softwarová úroveň přerušení, na které běží veškeré aplikace. Porovnáme-li tabulku úrovní priorit IRQL s prioritním uspořádáním v módu speciálního úplného vnoření obvodu 8259A zjistíme, že si neodpovídají. Připočteme-li k tomu jaké možnosti obvod 8259A nabízí, zjistíme, že hardwarově nelze takovéto prioritní uspořádání dosáhnout. Vzniká tak otázka, jak operační systémy rodiny Windows NT na platformě x86 fyzicky zajišťují proklamovaný prioritní systém a v jakém módu pak obvod 8259A pracuje? Bohužel konkrétní způsob spolupráce jádra operačního systému s obvodem přerušení nebyl dosud publikován. Vyjdeme-li však z detailní znalosti obvodu a provedeme-li několik experimentů, při kterých budeme přímým čtením obsahů registrů zjišťovat aktuální stav obvodu, je možné použitý mechanizmus identifikovat. Na tomto základě byla provedena analýza mechanizmu správy přerušení zvlášť pro MS Windows NT a MS Windows 2000/XP. Analýzy byly provedeny odděleně z důvodu interní Souhrn disertační práce

16 6 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT odlišnosti správy ovladačů mezi Windows NT [MICROSOFT 998A] a Windows 2000/XP [MICROSOFT 2000], kde přibyla podpora Plug and Play. 8.. Vyhodnocení analýzy MS Windows NT + SP6a Nejpravděpodobněji je použita kombinace standardního módu úplného vnoření s módem speciální masky [NĚMEC]. Systém u každé žádosti nejprve vyhodnotí úroveň IRQL. Má-li nový požadavek vyšší úroveň IRQL než aktuálně prováděná činnost, je ihned potvrzen příkazem EOI (End Of Interrupt). Následně poté je zahájena jeho obsluha, která takto může být kdykoliv přerušena jinou žádostí bez rozdílu priorit. Nastane-li takováto situace a obsluha bude přerušena žádostí s nižší nebo shodnou prioritou IRQL, systém žádost přijme avšak nepotvrdí. Namísto toho zamaskuje všechna přerušení shodné a nižší úrovně (vzhledem k původní obsluze) a zavede mód speciální masky [NĚMEC]. Ihned poté předá nazpět řízení původní obsluze, neboť má neustále nejvyšší úroveň IRQL. Od této chvíle již nemůže být činnost obsluhy přerušena žádostí s nižší úrovní IRQL. Jakmile je obsluha dokončena, systém zjistí, že byla přijata žádost s jistou úrovní IRQL, avšak nikdy nebyla zahájena. Nejprve zruší mód speciální masky a navrátí registr masky do původního stavu. Následuje potvrzení zjištěné žádosti a zahájení její činnosti. Od této chvíle je systém v obdobném stavu jako při přijetí první žádosti Vyhodnocení analýzy MS Windows 2000/XP Konkrétně použitý mód není možné jednoznačně určit. Nejpravděpodobněji je však použit mód automatického EOI [NĚMEC]. Systém u každé přijaté žádosti nejprve vyhodnotí přiřazenou úroveň IRQL. Na základě zjištěné úrovně IRQL určí potřebnou masku, kterou ihned u obou obvodů aplikuje. Je-li identifikovaná úroveň IRQL 28, jsou maskována všechna přerušení. V opačném případě jsou maskována pouze přerušení se shodnou nebo nižší úrovní IRQL mimo IR8 (hodin reálného času). Po aplikaci masky je opět povolen vstup INTR, který byl automaticky hardwarem maskován v okamžiku přijetí žádosti. Na to zahájí asociovanou obsluhu přerušení. Obsluha tak již může být přerušena pouze žádostí s vyšší úrovní IRQL. Po ukončení rutiny jsou masky obou obvodů uvedeny zpět do předchozího stavu Zhodnocení standardní obsluhy přerušení založené na obvodu 8259A z pohledu využití v systémech reálného času Přestože systémy MS Windows NT a MS Windows 2000/XP spravují přerušení dle shodného rozvržení úrovní priorit IRQL, jejich konkrétní realizace se liší. Z pohledu požadavků na zpracování v reálném čase mají však obě řešení určité nedostatky:. Ani jeden systém nevyužívá standardní mód úplného vnoření. Lze předpokládat, že interní priority vstupů IR obvodu 8259 nejsou vůči standardu pozměněny. Ve svém důsledku tak existují dva prioritní systémy a to logický (úrovně IRQL), spravovaný operačním systémem a hardwarový, jenž je interně spravován obvody 8259A. Problém tak vzniká v okamžiku, kdy dva vstupy IR současně vznesou své požadavky. V takovémto případě je předán vektor na obsluhu dle hardwarových priorit a ne podle úrovní IRQL. Jsou-li tyto priority v rozporu, dojde k situaci, kdy žádost o obsluhu IR vstupu s vyšší logickou prioritou je pozastavena žádostí nižší logické priority až do doby, než systém opět přerušení povolí. 2. Jedním z největších nedostatků obou systémů je absence informací o dobách trvání jednotlivých částí obsluh a systémových volání. Takto není možné předem určit dobu, za kterou se obsluha vykoná či jak dlouho bude trvat, než systém rutinu začne vykonávat. Pro MS Windows NT navíc platí: 3. Systém nevylučuje možnost přerušení obsluhy vyšší logické priority IRQL žádostí nižší priority. Z výše uvedeného popisu (platí pouze pro MS Windows NT) vyplývá, že standardně při běhu obslužné rutiny jsou všechna přerušení povolena. Systém sice hardwarově maskuje přerušení nižší a shodné priority, ale až poté, co se takovéto nežádané přerušení vyskytne. I když je ihned po vyhodnocení priorit opětovně zahájeno zpracování obsluhy s vyšší prioritou, nic se nemění na tom, že obsluha s vyšší úrovní IRQL je dočasně pozastavena přerušením nižší úrovně.

17 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Správa přerušení v systémech s technologií APIC Architektura APIC byla navržena především se záměrem na použití ve víceprocesorových systémech, kde se také donedávna výhradně používala. Teprve s příchodem procesorů Intel Pentium 4 se technologie APIC též zavedla do čipových sad jednoprocesorových systémů. Také v těchto systémech je někdy možné (obvykle změnou příslušné položky v BIOSu) vynutit použití dvojice řadičů 8259A (PIC mód). Navíc použití navrženého řešení ve víceprocesorových systémech lze považovat za zcela vyjímečné. Především z těchto důvodu se práce mechanizmem správy využívající technologii APIC (tedy i případnými postupy zlepšující determinovatelnost tohoto mechanizmu) nezabývá tak podrobně jako v případě obvodů 8259A. U systémů na bázi Pentium 4 předpokládám zavedení kompatibilního módu využívajícího obvody 8259A. Z předběžné analýzy vyplývá, že moderní operační systémy Windows XP/2000 nevkládají další softwarovou správu priorit, pouze využívají prioritního uspořádání požadavků podle přiděleného vektoru. Konkrétně přidělený vektor přerušení je však v plné kompetenci jádra operačního systému a tudíž priorita požadavků je programátorem velmi těžko ovlivnitelná ne-li zcela nemožná (toto tvrzení však vyžaduje hlubší analýzu). Ke všemu systém přiděluje vektory přerušení a tím i prioritu nezávisle na vstupu IR. Dokonce s největší pravděpodobností se konkrétní hodnota vektoru odvíjí podle pořadí instalace ovladačů. Takto nelze předem odhadnout na jaké úrovni IRQL bude dané zařízení obsluhováno a není vyloučeno, že v různých instalacích budou mít dvě zařízení vůči sobě naprosto převrácené priority. Jinak řečeno, operační systémy MS Windows 2000 a XP z pohledu systému reálného času technologii APIC zcela nevhodně používají. Zjištěné skutečnosti vedou k závěru, že z pohledu determinovatelnosti správy přerušení a tedy použití v systémech reálného času je daleko vhodnější v jednoprocesorových systémech vynutit (je-li to možné) použití starší technologie a používat obvody 8259A kompatibilní. 9 Návrh úprav systému správy přerušení využívající obvodů 8259A k dosažení zpracování v reálném čase Pro případ využití přerušení spolu se speciálním hardwarem jako zdrojem přesného periodického vykonávání činnosti v reálném čase (v našem případě vzorkovací perioda řízení), je nutné standardní chování systému a jeho výše uvedené nevýhody obejít či odstranit. Jelikož nelze bez zdrojových textů a práv měnit standardní chování systému (a to také není cílem této práce), je nutné nalézt skulinky v systému, kterými je možné obsluhu přerušení vylepšit bez přepracování jádra. Z tabulky 8. vyplývá, že nejvyšší úroveň IRQL má přerušení časovače (IRQL 28), následován přerušením klávesnice (IRQL 26) a podřízeného obvodu. Tato zařízení mají pevně přidělen vstup IR a tudíž kanály IR0, IR a IR2 není možné použít pro vlastní účely. Prvním volitelným kanálem, který je možné uživatelsky využít je až vstup IR3, který je standardně používán sériovými porty COM2/COM4. Máme-li měřicí kartu, která umožňuje generovat přerušení IR3, lze tak standardním způsobem získat úroveň přerušení IRQL 24. Z našeho pohledu je však tato úroveň nedostačující. Také ne vždy máme k dispozici uvedený kanál, nebo měřicí kartu, jenž tento kanál umí využít. Shrneme-li informace z předchozí kapitoly a doplníme-li je o zmíněný problém, dostaneme souhrn požadavků, které je nutno vyřešit:. Prvním požadavkem je nalézt způsob, jak přidělit obsluze jinou vyšší prioritu IRQL nežli tu, která je přidělena automaticky. 2. Dále je potřeba, aby rozpor mezi hardwarovou prioritou IR obvodu 8259A a softwarovou prioritou IRQL nezpůsoboval oddálení vykonání námi zvolené obsluhy v případě současného vzniku přerušení od dvou zdrojů. 3. U operačního systému MS Windows NT je také třeba zajistit, aby námi zvolená obsluha nemohla být přerušena jakýmkoliv jiným zdrojem IR. Souhrn disertační práce

18 8 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 9. Přiřazení vlastní úrovně IRQL Každé obslužné rutině ISR je při její registraci systémem přidělena úroveň IRQL podle tabulky 8.. Na této úrovni je pak daná obsluha vykonána. Vlastní registrace se ve Windows NT [MICROSOFT 998A] provádí ve dvou krocích:. mapování vektoru přerušení pro zvolený vstup IR, při kterém je systémem navrácena IRQL úroveň, 2. napojení obslužné rutiny ISR k získanému vektoru přerušení. MappedVector = HalGetInterruptVector(Isa, // Interface type 0, // Bus number irq, // Bus interrupt level irq, // Bus interrupt vector Systémem přidělená úroveň IRQL &irql, // IRQ level &Affinity // Affinity mask ); ioconnectstatus = IoConnectInterrupt( &extension->interruptobject,//interrupt Object LPTInterruptServiceRoutine, //Interrupt Service Routine extension->deviceobject, //Device Object NULL, //SpinLock MappedVector, //Mapped Vektor irql, //System IRQL RunIrql, //SynchronizeIrql Latched, //InterruptMode (is LevelSensitive or Latched) Skutečná úroveň FALSE, //ShareVector IRQL, na které Affinity, //ProcessorEnableMask obsluha poběží FALSE //FloatingSave (For X86 FALSE) ); Obr. 9. Mapování vektoru přerušení a připojení obsluhy s nastavením IRQL ve Windows NT V systému MS Windows 2000/XP [MICROSOFT 2000] odpadá první krok, neboť systém Plug and Play provádí veškeré registrace automaticky. Systémové funkci, která zajišťuje napojení rutiny k danému vektoru přerušení, se kromě jiného předává získaná úroveň IRQL z předchozího mapování a současně také synchronizační úroveň IRQL. Zatímco první hodnota musí být shodná se systémem přidělenou úrovní, druhá hodnota může být i vyšší úrovně IRQL. Synchronizační úroveň IRQL je ve skutečnosti tou úrovní, na které se bude obslužná rutina fyzicky vykonávat. 9.2 Změna hardwarových priorit Obvod 8259A spravuje žádosti jednotlivých vstupů podle priorit v tzv. úplném módu vnoření. Implicitně má vstup IR0 nejvyšší prioritu a vstup IR7 nejnižší prioritu. Tyto priority lze však programově ovlivnit a to několika způsoby. V našem případě je nejvhodnější použít příkaz nastavení priority, kterým je možné zvolenému vstupu IR přiřadit nejnižší prioritu. Priority ostatních vstupů se pak uspořádají tak, aby tvořily souvislou řadu. Například, nastavíme-li na nejnižší prioritu vstup IR 2, získá vstup IR3 nejvyšší prioritu (viz obr. 9.2). IR IR7 IR6 IR5 IR4 IR3 IR2 IR IR0 Priorita Nejvyšší Nejnižší Obr. 9.2 Stav interních priorit obvodu 8259A po nastavení nejnižší priority na kanál IR2 Je tedy v kombinaci s nastavením úrovně IRQL možné přiřadit konkrétnímu vstupu nejvyšší prioritu jak hardwarovou tak softwarovou. 9.3 Zabezpečení obsluhy před nežádoucím přerušením Přerušení prováděné obsluhy žádostí s nižší úrovní IRQL je problémem mechanizmu použitého v MS Windows NT. Ve Windows 2000/XP je činnost obsluhy s úrovní IRQL 3 prakticky nepřerušitelná (veškeré vstupy jsou maskovány). Zabezpečení lze realizovat nejlépe zamaskováním vstupu INTR a to jednoduchou instrukcí procesoru (CLI).

19 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 9 BOOLEAN LPTInterruptServiceRoutine( IN PKINTERRUPT Interrupt, IN OUT PVOID Context) { PDEVICE_OBJECT DeviceObject; PLPT_DEVICE_EXTENSION extension; asm CLI //Maskovani vstupu INTR Obr. 9.3 Počáteční část obsluhy přerušení s maskováním vstupu INTR procesoru Aplikací uvedených postupů na systém využívající přerušení k přesnému časování periodických činností lze dosáhnout z pohledu reálného času kvalitnějších výsledků. Přesto však ani po této úpravě nelze uvést, že námi definovaný vstup IR je zpracováván v reálném čase. K tomuto závěru vede hned několik důvodů:. Nejsou známé doby trvání systémových funkcí jádra operačního systému a tudíž nelze předem vypočíst maximální limit, do kterého bude rutina po vzniku přerušení zahájena. 2. Výrobce systémů uvádí [MICROSOFT 998B], že v určitých blíže nespecifikovaných případech činnosti jádra je maskován vstup procesoru INTR a tudíž jsou veškerá přerušení zakázána. 3. Taktéž nelze vyloučit, že tytéž postupy neužívá některý standardní ovladač z dílen Microsoftu nebo třetích stran. 4. Při aplikaci uvedených úprav nelze vyloučit stav, kdy obsluha s nižší prioritou IRQL bude po dobu své činnosti blokovat žádost o obsluhu s vyšší prioritou IRQL. Tento problém vzniká při hardwarovém maskování přerušení, kdy systém zamaskuje IR kanál, kterým jsou vznášeny požadavky s uživatelsky zvýšenou prioritou IRQL, jež by při standardním použití měly úroveň nižší. 9.4 Ověření návrhu měřením latence odezvy na vznik IRQ Prioritním cílem měření je zjistit, s jakou latencí jsou zvolené operační systémy schopné zareagovat a vykonat určitý algoritmus na vznik přerušení. Dalším cílem měření je vzájemné porovnání výkonnostně odlišných hardwarových platforem s použitím různých operačních systémů rodiny Windows NT zatížených a nezatížených činnostmi jiných aplikací v závislosti na tomto měření. Významnou částí měření je také ověření výše uvedených interních úprav systému, které vylepšují správu přerušení s ohledem na zpracování v reálném čase Princip měření Základní princip spočívá ve vynesení požadavku generující přerušení IRQ v měřeném systému vnějším zdrojem, který současně vyhodnocuje dobu, za kterou je měřený systém schopen odeslat odpověď jako důsledek onoho přerušení. Měřený systém: MS Windows NT/2000/XP Měřící systém: MS DOS/Windows 98 Speciální ovladač IRQ Hardware Hardware Měřící program Algoritmus odezvy (Rutina ISR) I/O zařízení LPT PCA26 Zahájení měření Vyhodnocení Obr. 9.4 Princip měření latence odezvy na vznik přerušení Umělé zatížení operačních systémů Z architektury MS Windows NT/2000/XP vyplývá, že můžeme veškeré prováděné činnosti rozdělit do dvou skupin [MICROSOFT 2000]: a) činnosti prováděné v uživatelském (chráněném) režimu, b) činnosti prováděné v režimu jádra. Souhrn disertační práce

20 20 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Zatížení omezené pouze na úroveň chráněného režimu je provedeno programem z dílny Microsoftu CPU Stress [MICROSOFT 2000]. Program umožňuje zavést až čtyři početní vlákna s různou úrovní aktivity provádějící s volenou prioritou. O něco složitější je zatížení systému na úrovni režimu jádra. V tomto případě je nutné založit úlohy, které výhradně pracují s periferními zařízeními používající IRQ a tudíž z podstatné části vykonávané ovladači. Vlastní realizace je možná například zavedením úlohy objemného kopírování souborů z CD na pevný disk nebo přenášení dat po síti apod. Problémem takto generovaného zatížení je však silná závislost na použitém hardwaru. Pak případné srovnávání výkonnostně odlišných systémů je velmi rozporuplné. Pro minimalizaci tohoto vlivu byly vyrobeny dva speciální programy:. program IRQ_HD, který na pevný disk ukládá velké množství náhodně generovaných dat a v souvislosti tak generuje přerušení IRQ 0, 2. program COM To COM, který zasílá a čte sadu znaků přes sériový port a využívá tak přerušení IRQ 3 nebo IRQ 4. U obou programů je možné nastavit množství přenesených dat za jednotku času. Obr. 9.5 Nastavení zatěžujících programů IRQ_HD a COM To COM během měření Ověření navržených úprav Vlastní ověření spočívá v porovnání souborů naměřených dob odezvy na systému používající neupravený a poté upravený mechanizmus správy přerušení. Konkrétně použitý měřený systém lze po hardwarové stránce charakterizovat takto: CPU Pentium 90 MHz, Hard disk o kapacitě 4 GB připojený přes SCSI řadič na PCI sběrnici (IRQ0), 64 MB RAM, CD ROM 4x, připojený přes rozhraní ID (IRQ4). K měření byly použity speciální ovladače paralelního portu (IRQ7) postupně nainstalované na operačních systémech MS Windows NT 4.0 se servisním balíčkem SP6A a MS Windows 2000 se servisním balíčkem SP3. (Díky shodnému mechanizmu správy přerušení nebyl zvlášť testován MS Windows XP.) V jednom souboru měření je vykonáno dotazů sériově prováděných v intervalech cca 60 µs. Během jednoho souboru měření je systém buď: a) nezatížen to znamená, že v měřeném systému není spuštěna žádná aplikace a periferní zařízení nejsou uživatelsky používány, b) zatížen v systému běží program CPU Stress a je prováděno kopírování celého obsahu zvoleného CD na pevný disk. Konkrétní nastavení programu CPU Stress bylo voleno tak, aby procesor počítače byl na hranici 00 % zatížení. Kopírováním obsahu CD na pevný disk do systému vstupují obsluhy přerušení IRQ4 a IRQ0, které spolu s ostatními žádostmi již výrazně ovlivňují správu přerušení. K zajištění objektivity byla před každým měřením předchozí kopírovaná data smazána, pevný disk defragmentován a počítač restartován.

21 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 2 Jednotlivé soubory naměřených vzorků byly vyhodnocovány a graficky zpracovány. Hlavním vyhodnocovaným kritériem je doba, do které odpoví 99,9 % vzorků a doba nejpozději přijaté odezvy. Jako první bylo provedeno měření na systémech používající standardní mechanizmus správy přerušení (IRQL 20). Získané hodnoty zpracované do grafické podoby ve formě grafu jsou uvedeny jak pro nezatížené tak pro zatížené systémy na obrázcích 9.6 a 9.7. Rozložení vzorků podle času odezevy v MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Bez zatížení Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Bez zatížení V 99,9% odezva přijata do 3 µs Všechny odezvy přijaty do 33 µs V 99,9% odezva přijata do 3 µs Všechny odezvy přijaty do 26 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.6 Reakční doby na vznik přerušení nezatíženého standardního systému MS Windows NT (vlevo) a MS Windows 2000 Rozložení vzorků podle času odezevy v MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo: CPU Stress a kopírování z CD na HD Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo: CPUStress a kopírování z CD na HD V 99,9% odezva přijata do 26 µs Všechny odezvy přijaty do 97 µs V 99,9% odezva přijata do 2 µs Všechny odezvy přijaty do 5 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.7 Reakční doby na vznik přerušení zatíženého standardního systému MS Windows NT (vlevo) a MS Windows 2000 Ze srovnání uvedených grafů je patrný silný vliv zatížení systému především na nejpozději přijatou odezvu. Zatímco u nezatíženého systému MS Windows NT 4.0 byly všechny odezvy přijaté do 33 µs, tak u zatíženého systému byla nejpozději přijatá odezva v 97 µs, to odpovídá 200% nárůstu. Také doba, do které odpovědělo 99,9 % vzorků vzrostla na dvojnásobek z 3 µs na 26 µs. Obdobné závěry lze vysledovat také srovnáním grafů získaných na MS Windows Porovnáme-li však grafy napříč mezi operačními systémy, lze vypozorovat vliv rozdílné správy priorit. Co se týče kritéria nejdelší odezvy je na tom lépe MS Windows NT. Naopak v druhém kritériu je na tom výrazně lépe MS Windows Na následujícím obrázku 9.8 jsou již zobrazeny výsledné soubory měření nad systémem používající všechny navržené úpravy současně. Zaměříme-li se na operační systém MS Windows NT zjistíme, že kombinací všech úprav se výrazně zkrátily oba sledované parametry. Především termín nejpozději získané odezvy (25 µs) je vůči neupravenému systému (97 µs) zkrácen na čtvrtinu a je dokonce kratší nežli limit, do kterého původně odpovědělo 99,9 % vzorků. Díky tomu se snížil celkový rozptyl odezev a tím i použitelnost k real-time operacím. Také v operačním systému MS Windows 2000 došlo ke zlepšení obou sledovaných parametrů. Oproti svému předchůdci však nejsou rozdíly až tak výrazné. Robustnější mechanizmus správy Souhrn disertační práce

22 22 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT přerušení výrazněji odolává požadovaným změnám v prioritním uspořádání požadavků IRQ. Přesto obě použité úpravy prokazatelně zkrátily oba sledované parametry a vylepšily tak determinovatelnost zvolené obsluhy. Rozložení vzorků podle času odezevy v MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows Pentium 90 MHz, IRQ7 - paralelní port Společně všechny úpravy: maska INTR, IRQL 3, max IR7 Zatíženo: CPU Stress a kopírování z CD na HD Pentium 90 MHz, IRQ7 - paralelní port Obě úpravy společně: nejvyšší IR7, IRQL 3 Zatíženo: CPUStress a kopírování z CD na HD V 99,9% odezva přijata do 4 µs Všechny odezvy přijaty do 25 µs V 99,9% odezva přijata do 8 µs Všechny odezvy přijaty do 87 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.8 Reakční doby na vznik IRQ zatíženého systému používající všechny navržené úpravy Porovnání dob odezvy mezi výkonnostně odlišnými počítači Cílem této kapitoly je poodhalení vlivu výkonu počítačové sestavy na determinovatelnost doby potřebné k zahájení obslužné rutiny od vzniku požadavku na přerušení. Vlastní měření se provádělo na třech základních typech v současnosti dostupných operačních systémů rodiny MS Windows NT a to konkrétně na: MS Windows NT 4.0 včetně servisního balíčku SP6a, MS Windows 2000 Proffesional se servisním balíčkem SP3, MS Windows XP Proffesional se servisním balíčkem SP. Jako referenční byly zvoleny čtyři výkonnostně odlišné sestavy... A. Pentium 90 MHz: C. Celeron 00 MHz: CPU Intel Pentium 90 MHz, takt sběrnice 66 MHz, 64 MB RAM. B. Celeron 400 MHz: CPU Intel Celeron A 400 MHz, takt sběrnice 66 MHz, CPU Intel Celeron 00 MHz, takt sběrnice 00 MHz, 52 MB RAM. D. Pentium MHz: CPU Intel Pentium 4 2 GHz, takt sběrnice 400 MHz, 28 MB RAM. 52 MB RAM. K zatížení byly výhradně použity již zmíněné programy COM To COM a IRQ_HD s nastavenými parametry dle obrázku 9.5. Jako příklad jsou uvedeny získané hodnoty pro výkonnostně nejslabší a nejsilnější sestavu Pentium: 90 MHz Na výkonově nejslabší sestavě nebyl vyhodnocován MS Windows XP především z důvodu malého výkonu stanice. Z grafů je patrný pozitivní vliv navržených úprav na obou měřených operačních systémech.

23 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 23 Rozložení vzorků podle času odezevy v MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows NT Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM Pentium 90 MHz, IRQ7 - paralelní port Všechny úpravy: IRQL3, max IR7, mask INTR Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 36 µs Všechny odezvy přijaty do 64 µs V 99,9% odezva přijata do 6 µs Všechny odezvy přijaty do 37 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.9 Reakční doby na vznik přerušení sestavy Pentium 90 MHz s MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows 2000 Rozložení vzorků podle času odezevy v MS Windows Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM Pentium 90 MHz, IRQ7 - paralelní port Všechny úpravy: IRQL 3, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 40 µs Všechny odezvy přijaty do 77 µs V 99,9% odezva přijata do 2 µs Všechny odezvy přijaty do 40 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.0 Reakční doby na vznik přerušení sestavy Pentium 90 MHz s MS Windows Pentium 4: 2000 MHz Tato nejvýkonnější měřená stanice se od ostatních liší především použitou čipovou sadou Intel MCH a Intel 8280 DB ICH4 [INTEL CORPORATION 2002], která má standardně integrovaný řadič IOAPIC. Oproti předchozím sestavám tak implicitně používá ke správě přerušení technologii APIC. Z důvodu kompatibility je v čipové sadě také integrována dvojice řadičů 82C59, jejíž použití je možné volbou v BIOSu vynutit. Této skutečnosti bylo pochopitelně pro následující měření využito. Rozložení vzorků podle času odezevy v MS Windows NT 4.0 Rozložení vzorků podle času odezevy v MS Windows NT Pentium 4-2 GHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM Pentium 4-2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL3, max IR7, mask INTR Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 20 µs Všechny odezvy přijaty do µs V 99,9% odezva přijata do 2 µs Všechny odezvy přijaty do 6 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9. Reakční doby na vznik přerušení sestavy Pentium 4 2 GHz s MS Windows NT 4.0 Souhrn disertační práce

24 24 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Rozložení vzorků podle času odezevy v MS Windows 2000 Rozložení vzorků podle času odezevy v MS Windows Pentium 4-2 GHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM Pentium 4-2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL3, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 28 µs Všechny odezvy přijaty do 42 µs V 99,9% odezva přijata do 20 µs Všechny odezvy přijaty do 38 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.2 Reakční doby na vznik přerušení sestavy Pentium 4 2 GHz s MS Windows 2000 Rozložení vzorků podle času odezevy v MS Windows XP Rozložení vzorků podle času odezevy v MS Windows XP Pentium 4-2 GHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM Pentium 4-2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL3, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 30 µs Všechny odezvy přijaty do 44 µs V 99,9% odezva přijata do 2 µs Všechny odezvy přijaty do 38 µs Násobek odezvy Násobek odezvy ,9% Čas odezvy [µs] 99,9% Čas odezvy [µs] Obr. 9.3 Reakční doby na vznik přerušení sestavy Pentium 4 2 GHz s MS Windows XP 0 Ovladač realizující řízení v reálném čase Cílem je navrhnout strukturu a rozhraní ovladače snadno aplikovatelnou na převážnou část multifunkčních analogových karet. Při návrhu ovladače je nutné brát zřetel na následující oblasti použití:. přímé užití analogových vstupů a výstupů, 2. nepřetržité měření s determinovatelnou vzorkovací periodou, 3. regulace v reálném čase s možností čtení jejího průběhu. Kromě těchto funkčních požadavků jsou navíc kladeny další, zaměřené na přenositelnost a rozšiřitelnost řešení a to: 4. snadná přenositelnost na jiné multifunkční analogové karty, 5. relativně snadná rozšiřitelnost o nové algoritmy řízení. 0. Třívrstvý model ovladače Snadné přenositelnosti ovladače lze nejlépe dosáhnout použitím vrstvové architektury. Pro tento účel optimálně vyhovuje třívrstvá architektura skládající se: z vrstvy rozhraní, která zajistí jednotný způsob komunikace a výměny dat mezi Windows aplikací a samotným ovladačem, z logicko-funkční vrstvy, která provádí všechny ovladačem realizované služby a činnosti zajišťující potřebnou funkcionalitu ovladače, a fyzické vrstvy, která již provádí fyzické přístupy ke konkrétní multifunkční kartě a stírá rozdíly mezi nimi.

25 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 25 Win32 API aplikace Ovladač Uživatelský režim Režim jádra Rozhraní Logicko-funkční vrstva Fyzická vrstva Hardware Multifunkční karta Obr. 0. Zjednodušené schéma třívrstvého modelu ovladače Při dobře provedeném návrhu dochází ke komunikaci a výměně dat pouze mezi jednotlivými vrstvami. Takže při požadavku přenést ovladač na jiné nové zařízení je pouze nezbytné upravit fyzickou vrstvu bez nutnosti opravovat ostatní vrstvy nebo dokonce uživatelskou Windows aplikaci. 0.2 Rozhraní ovladače Smyslem rozhraní je oddělit interní realizaci požadovaných činností od jejich ovládání. Aplikacím Win32 API se tak nabízí jednotný způsob komunikace s ovladačem pro všechny typově odpovídající multifunkční karty. Komunikace a výměna dat s aplikacemi Win32 API je v závislosti na operačním systému možná hned několika způsoby. V tomto případě jsou použity dvě standardní metody:. komunikace prostřednictvím řídicích kódů IOCTL (I/O Control Code) realizované standardní funkcí Win32 API DeviceIoControl( ), 2. standardní čtení dat ze zařízení (ovladače) realizované funkcí Win32 API ReadFile( ). První metoda komunikace je použita především pro nastavení ovladače nebo zjištění aktuálního nastavení a k přímému ovládání analogových vstupů a výstupů. Oproti tomu druhá metoda slouží pouze ke čtení rozsáhlého množství naměřených dat nepřetržitého měření, nebo dat průběžně popisujících sledované veličiny regulace Rozhraní realizované prostřednictvím řídicích kódů IOCTL Tato část rozhraní definuje obecnou sadu řídicích kódů spolu s datovými strukturami k realizaci základních nastavení ovladače a přímého přístupu k analogovým jednotkám. Souhrnně tyto činnosti lze charakterizovat výčtem funkčních okruhů na funkce:. informační obecné (informující o vlastnostech a schopnostech karty), 2. pro nastavení napěťových rozsahů vstupů a výstupů, 3. pro přímou práci s analogovými vstupy a výstupy, 4. k nastavení typu periodické činnosti, jejího chování a ovládání, 5. pro nastavení parametrů nepřetržitého měření (které vstupy, perioda apod.), 6. pro nastavení parametrů regulace (typ regulátoru, parametry, apod.), 7. k úpravě správy přerušení k dosažení vyšší determinovatelnosti a 8. specializovaného rozhraní pro nastavení závislých voleb na použité měřicí kartě. Ovladač rozlišuje čtyři různé periodické činnosti: a) nepřetržité měření vybraných vstupů, Souhrn disertační práce

26 26 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT b) jednorozměrnou regulaci, c) vícenásobnou regulaci, d) uživatelskou regulaci Rozhraní pro nepřetržité čtení dat z ovladače Předchozí technika svým principem není vhodná pro přenos většího množství dat, jejíž velikost nelze předem odhadnout nebo dat s nepřetržitým tokem. V těchto případech vyžadujeme asynchronní komunikaci (aplikace zahájí komunikaci avšak pokračuje v jiné činnosti do doby než ovladač data nevyřídí) s možností zadávat nové požadavky dříve nežli jsou předchozí dokončeny. Pro čtení takovýchto dat jsou ve Win32 API speciálně vyvinuté funkce ReadFile( ) a WriteFile( ). Funkce umožňují asynchronní čtení/zápis rozsáhlého množství dat z/do ovladače. Díky asynchronnímu přístupu je možné založit několik požadavků najednou a zásobit tak v dostatečném množství ovladač vyrovnávací pamětí k bezztrátovému přenosu dat. Samozřejmě je pro tento účel také nutná podpora i na straně ovladače. Všechny ovladačem prováděné periodické činnosti jsou potenciálním zdrojem obrovského množství dat. Navíc v případě nepřetržitého měření je průběžné bezztrátové získávání dat z ovladače jediným cílem činnosti. U regulace nás zase často zajímá aktuální stav regulované a akční veličiny k okamžité vizualizaci či jinému zpracování těchto informací. Proto ovladač plně implementuje vlastní mechanizmus bezztrátového předávání těchto dat s využitím zmíněné techniky asynchronního čtení. 0.3 Logicko-funkční vrstva Logicko funkční vrstvou jsou realizované všechny požadované činnosti (jako je např. měření a regulace) a služby závislé na operačním systému (např. registrace ovladače ve Windows NT 4.0 nebo interní funkcionalita PNP ve Windows 2000/XP). Je tak odpovědná za řádné zavedení ovladače, zajištění všech systémem požadovaných služeb, registraci a připojení obsluhy přerušení, mapování paměti, portů, realizaci algoritmů řízení, zápisu dat do bufferů, uchovávání všech nastavení apod. Vrstva především odpovídá za bezchybné periodicky opakované vykonávání obsluhy přerušení. Pro případ nepřetržitého měření takto zajišťuje vykonání funkce fyzické vrstvy, která již v dané periodě data z karty načte do přiloženého bufferu. V případě jednorozměrné regulace zase voláním funkce fyzické vrstvy získá hodnotu regulované veličiny a po provedení patřičného algoritmu regulace opět prostřednictvím fyzické vrstvy provede akční zásah apod. Je tedy patrné, že interní mechanizmy jsou odlišné v závislosti na vykonávané periodické činnosti a bohužel také na operačním systému. Ovladače Windows NT 4.0 totiž nemohou dynamicky měnit obsluhu přerušení, naopak obsluha musí být známá a jedinečná již v okamžiku kompilace. Ve Windows 2000/XP je oproti tomu možné vytvořit několik takovýchto rutin a až dle konkrétních požadavků patřičnou obsluhu zvolit a dynamicky zavést. 0.4 Fyzická vrstva Náplní fyzické vrstvy je oddělit hardwarově závislé operace od ostatních činností ovladače. Jako jediná přistupuje k registrům popřípadě paměti použité multifunkční karty a realizuje tak překlad obecných požadavků logicko-funkční vrstvy na konkrétní instrukce dle možností a potřeb daného typu zařízení. Díky tomu lze poměrně snadno (pouhou modifikací vrstvy) implementovat ovladač nad různými typy multifunkčních analogových karet splňujících základní předpoklady. Konkrétně je vrstva realizována sadou funkcí s pevně stanovenou strukturou. Každá z nich má jasně vyhraněný charakter činnosti, který je zpřesňován jejími parametry. Seznam vybraných funkcí spolu s jednoduchým popisem je uveden v tabulce 0..

27 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 27 Tab. 0. Seznam funkcí fyzické vrstvy Název funkce HwSetAIValRange HwSetAOValRange HwSetSpecialCardData HwCardInitialize HwReadMultipleAI HwWriteMultipleAO HwSetTimerPriode HwTimerStart HwTimerStop HwClrIntr HwSetScanning HwScanning HwSetSingleReg HwSetMultipleReg HwSetUserReg HwReadY HwWriteU HwReadGroupY HwWriteGroupU Popis Nastavení měřicího rozsahu A/D vstupů. Nastavení rozsahu D/A výstupů. Nastavení specifických voleb multifunkční karty. Provede počáteční inicializaci karty po zavedení ovladače. Ihned změří požadované A/D vstupy. Ihned nastaví požadované D/A výstupy. Inicializuje časovače a nastavuje vzorkovací periodu. Spouští činnost časovačů. Pozastavuje činnost časovačů. Maže příznak přerušení potvrzení ukončení obsluhy IRQ. Inicializuje měřicí kartu k provádění nepřetržitého měření. Měřicí sekvence periodické činnosti nepřetržitého měření. Inicializuje měřicí kartu k provádění jednorozměrné regulace. Inicializuje měřicí kartu k provádění soustavy regulátorů. Inicializuje měřicí kartu k provádění uživatelského regulátoru. Změří regulovanou veličinu jednorozměrného regulátoru. Nastaví akční veličinu jednorozměrného regulátoru. Změří soustavu regulovaných veličin vícerozměrného regulátoru. Nastaví soustavu akčních veličin vícerozměrného regulátoru. 0.5 Regulátory Celý algoritmus regulace spočívá ve výpočtu akční veličiny podle aktuální regulační odchylky a stavu parametrů regulátoru. Vlastní výpočet je realizován interní funkcí uacdactuatingvalreg( ). Funkce prostřednictvím parametrů obdrží aktuální regulační odchylku, identifikátor typu regulátoru a union, který obsahuje interní strukturu se všemi potřebnými údaji prováděného regulátoru. Podle těchto údajů zvolí příslušný typ algoritmu, jimž vypočte a následně vrátí akční veličinu. Standardně je ovladač vybaven čtyřmi typy regulačních algoritmů:. PID (PSD) polohový, 2. PID (PSD) přírůstkový, 3. PID (PSD) polohový s filtrací regulované veličiny, 4. PID (PSD) polohový s filtrací derivačního členu. 0.6 Uživatelský regulátor Jak vyplývá z názvu, není tento regulátor předem specifikován, neboť jeho konkrétní algoritmus definuje až uživatel. V závislosti na zvoleném nastavení může tento regulátor mít jednu či více vstupních a výstupních veličin. Implementace uživatelského regulátoru je poměrně snadná záležitost. Stačí pouze upravit funkci uacduserregulator( ) a následně překompilovat ovladač. Komplikace nastává až s potřebou odladit algoritmus regulátoru. Jelikož je algoritmus součástí ovladače je jeho ladění poměrně složité vyžadující nejen hlubší znalosti principů ladění Souhrn disertační práce

28 28 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT ovladačů, ale také speciální nástroje a prostředky. Pokud má být implementace algoritmu snadnou záležitostí, musíme nalézt méně náročné postupy. Navržené řešení se opírá o fakt, že je potřeba odladit pouze algoritmus regulátoru a ne celý ovladač. Jelikož algoritmus funkce není ovlivněn skutečností zda běží interně v ovladači či v aplikaci uživatelského módu je možné ladění provádět odděleně. To znamená, že vlastní algoritmus se nejprve vytvoří ve speciální aplikaci uživatelského módu, která obdobně jako v těle ovladače periodicky volá uvedenou funkci. Po odladění algoritmu se již bezchybná verze pouze implementuje do těla ovladače. 0.7 Implementace ovladače na konkrétní zařízení Po celý proces návrhu ovladače byl brán značný zřetel na pozdější jednoduchou implementaci ovladače na libovolnou měřicí/multifunkční analogovou kartu. K úspěšnému splnění požadavku je mimo jiné důležitý návrh souborové struktury zdrojových textů ovladače. Stručný popis některých souborů je uveden v tab. 0.. Tab. 0. Seznam vybraných zdrojových souborů ovladače Název souboru INIVAL.h MYDRIVER.c Popis Deklarace konstant popisující základní vlastnosti karty. Zdrojový soubor funkcí fyzické vrstvy. MYDRIVER.inf nebo.reg Instalační soubor ovladače pro Win 2K/XP nebo Win NT 4.0. MYDRIVER.RC SOURCES Soubor zdrojů. Seznam zdrojových souborů ovladače a cílový název ovladače. IEEE_REAL32_SYS.h Deklarace typu reálného čísla a funkcí základních operací. UACD_HWLAYER.h UACD_IOCTL.h UACD_MAIN.h Deklarace hlaviček funkcí fyzického rozhraní. Rozhraní obecného ovladače. Definice základních rutin ovladače. Implementace ovladače na nové zařízení lze shrnout do následujících bodů:. Dle cílové platformy ovladače zvolit složku buď UniversalDriver_NT nebo UniversalDriver_2K-XP. 2. Vytvořit/modifikovat soubor INIVAL.H s konstantními hodnotami popisující základní vlastnosti použité multifunkční karty. 3. Vytvořit/modifikovat hlavní soubor (MYDRIVER.C). 4. Do uvedeného souboru vložit referenci na hlavní hlavičkový soubor UACD_MAIN.H a vytvořený soubor INIVAL.H. 5. Definovat-realizovat všechny funkce fyzické vrstvy. 6. Pro Windows 2000/XP vytvořit či modifikovat soubor zdrojů (MYDRIVER.RC). 7. Upravit soubor SOURCE. 8. V konzole kompilátoru DDK zkompilovat ovladač příkazem BUILD CEF. 9. Dle cílové platformy upravit instalační soubor. 0. Provést instalaci nového ovladače. 0.8 Realizace ovladače pro měřicí karty PCA408 a PCA208 Úpravou popisovaných souborů byl vytvořen ovladač pro multifunkční měřicí kartu PCA408 a později také pro kartu PCA208. Výsledkem je soubor ovladače CDPCA408.SYS (CDPCA208.SYS) a instalační soubor CDPCA408.INF

29 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 29 (CDPCA208.INF) pro Windows 2000/XP a CDPCA408.REG (CDPCA208.REG) pro Windows NT 4.0. Použití ovladače v aplikacích Win32 API V převážné většině případů bude ovladač součástí aplikací provádějících, kromě vlastního řízení či měření, operace spjaté s dispečerskými nebo jinak data zpracujícími činnostmi. V těchto aplikacích bude vlastní komunikace s ovladačem stěžejní činností. Vlastní komunikace nativní funkcionalitou Win32 API však nepatří mezi zcela jednoduché záležitosti. Na její tvůrce se kladou nemalé nároky nejen ze strany potřebných znalostí daného rozhraní ovladače, ale také interních principů jeho činností. Má-li být nasazení ovladače poměrně snadnou záležitostí, je nezbytné vlastní komunikaci mezi ovladačem a aplikacemi zjednodušit. V principu to znamená navrhnout a vytvořit vyšší vrstvy realizované na úrovni uživatelského módu nad rozhraním ovladače, které zakryjí složitou metodiku komunikace ve Win32 API. Windows aplikace Obsluha komunikace s ovladačem COM Knihovna funkcí snadného přístupu k rozhraní Funkcionalita Win32 API Ovladač Uživatelský režim Režim jádra Hardware Multifunkční karta Obr.. Metody přístupu k rozhraní ovladače z aplikací uživatelského módu Za tímto účelem byla navržena a realizována knihovna funkcí zjednodušující přístup k rozhraní ovladače a spolu s ní i komponenta COM, která celou komunikaci zaobaluje do objektové technologie. To, zda programátor využije přímý přístup k rozhraní přes funkcionalitu Win32 API, nebo použije jednu z uvedených zjednodušujících metod záleží čistě na jeho schopnostech, popřípadě omezeních použitého vývojového nástroje.. Knihovna funkcí snadného přístupu k rozhraní Knihovna byla navržena a realizována za účelem zjednodušení přístupu k rozhraní ovladače především při vývoji aplikací prostřednictvím jazyka C. Ve své podstatě jednotlivé funkce překrývají obecné nástroje Win32 API tak, aby vývojáři byly oproštěny od detailů mechanizmů vzájemné komunikace..2 Zaobalení komunikace do objektu COM Pro umožnění tvorby uživatelských aplikací i ve vyšších programovacích jazycích (např. ve Visual Basicu) byla komunikace zaobalena do komponenty COM [KAČMÁŘ 2000]. Standardně je komponenta vybavena těmito COM rozhraními: Rozhraní ICDMain, které slouží jako společné základní rozhraní, jimiž je možné v jazyce Visual Basic založit instanci komponenty. Rozhraní nabízí metody k navázání a ukončení spojení s ovladačem a poskytuje nástroje (události) pro čtení dat o průběhu regulací nebo naměřených dat v případě nepřetržitého měření. Individuální předem nepojmenované rozhraní představující specifické vlastnosti konkrétní měřicí karty (např. IPCA408). Souhrn disertační práce

30 30 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Rozhraní IAnalogIO, které zprostředkovává základní práci s analogovými jednotkami karty. Prostřednictvím tohoto rozhraní je možné měřit/nastavit libovolný vstup/výstup, nastavovat jeho rozsah apod. Rozhraní IScanning, které slouží k nastavení nepřetržitého měření. Prostřednictvím rozhraní lze tak plně realizovat nepřetržité měření vybraných vstupů. Naměřená data předávají události v přepočtené podobě ve tvaru skutečného napětí. Rozhraní ISingleReg nastavuje obecné parametry periodické činnosti jednorozměrného regulátoru. Umožňuje také změnit určité veličiny také během regulace a spustit či pozastavit samotnou regulaci. Rozhraní IRegPIDPos, IRegPIDInc, IRegPIDPosF, IRegPIDPosFD, jejíž výběrem se zvolí a nastaví patřičný typ jednorozměrné PID regulátoru. Rozhraní IMultipleReg, které slouží k výběru soustavy regulátorů. Rozhraní je ve své podstatě kolekcí jednotlivých jednorozměrných regulátorů Rozhraní IUserReg a IUserRegParameter umožňuje vybrat a nastavit jako periodickou činnost uživatelský regulátor. Rozhraní IRealTimeIRQ slouží k nastavení mechanizmů zvyšující determinovatelnost provádění periodických činností. Pro snadnou integraci do různorodých vývojových prostředí jsou všechna uvedená rozhraní součástí jedné typové knihovny ControlDrivers. Vlastní realizace byla rozšířena o plně funkční rozhraní IPCA408 (nahrazuje nespecifikované rozhraní), které reprezentuje individuální nastavení multifunkční karty PCA408 (viz obr..2). IUnknown ICDMain IAnalogIO IPCA408 IScanning ISingleReg IRegPIDPos IRegPIDInc IRegPIDPosF IRegPIDPosFD COM Pro ovladač CDPCA408 IMultipleReg IUserReg IUserRegParameter IRealTimeIRQ Obr..2 Rozhraní komponenty COM s plnou podporou ovladače multifunkční karty PCA408.3 Uživatelská ovládací aplikace Uživatelská ovládací aplikace byla zcela vytvořena v MS Visual Basicu 6.0 s využitím uvedené komponenty COM. Ve své podstatě pouze zprostředkovává veškerou funkcionalitu komponenty v uživatelsky přívětivém prostředí. Aplikace není vázaná na konkrétní typ ovladače a tudíž spolupracuje s libovolnou měřicí kartou respektive s libovolným kompatibilním ovladačem. Je tak připravená na případné rozšíření ovladačů o nové multifunkční zařízení. Samozřejmostí aplikace je také export naměřených dat či dat průběhu regulace do textového souboru, popřípadě dokumentu MS Excelu.

31 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 3 Obr..3 Uživatelská ovládací aplikace 2 Řízení levitace feromagnetického předmětu v elektromagnetickém poli Realizovaný systém pro podporu řízení v reálném čase v operačních systémech rodiny MS Windows NT bylo nutné ověřit na reálném fyzikálním zařízení. Za tímto účelem byl zvolen model levitace feromagnetického předmětu v elektromagnetickém poli, jehož řízení klade vysoké nároky na zpracování v reálném čase. Realizací řízení je možné ověřit následující vlastnosti řídicího systému: početní správnost realizovaných algoritmů, schopnost realizovat řízení se zvolenou vzorkovací periodou a tuto periodu dlouhodobě udržet bez zhoršení kvality regulačního procesu, schopnost mechanizmu vykonávat čtení dat průběhu regulace bez vlivu na regulační proces, funkčnost uživatelské ovládací aplikace spolu s komponentou COM a knihovnou funkcí snadného přístupu k ovladači, neovlivnitelnost řešení na ostatních činnostech spojených s užíváním jiných aplikací a provádění běžných úkonů v operačním systému. 2. Technický popis modelu levitace Model levitace feromagnetického předmětu v elektromagnetickém poli byl navržen a realizován v rámci grantového projektu GAČR [KAČMÁŘ & KOL]. Je založen na vertikálním přitahování feromagnetického předmětu elektromagnetickým polem vytvořeným cívkou elektromagnetu. Cílem řízení je pozvednout a udržet předmět v požadované poloze změnou napětí na cívce elektromagnetu. Napájení cívky je realizované speciální elektronikou galvanicky oddělující a upravující vstupní ovládací napětí akční veličiny z 0 0 V na 0 24 V (0 2 A). Levitující předmět je realizován permanentním magnetem. Pro svou malou velikost (jenž mimo jiné ztěžuje snímání polohy) je zapuštěn do pingpongového míčku. Souhrn disertační práce

32 32 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Ø70 Rám 80 Cívka 2500 závitů Ø25 Jádro cívky 295 Levitující předmět (permanentní magnet v pingpongovém míčku) Analogové signály Napájení 24V 2A Laserový triangulační snímač polohy 60 El ektronik a: Galvanické oddělení a přizpůsobení akčního zásahu Obr. 2. Technický schéma soustavy levitujícího předmětu (vlevo) a detailní pohled na model levitace během řízení (vpravo) Vlastní měření polohy je realizované laserovým snímačem firmy SICK [KAČMÁŘ & KOL.] pracující na triangulačním principu. Výstupní signál aktuální polohy v rozmezí 20 mm snímač realizuje proudovým výstupem v rozsahu 4 20 ma. 2.2 Popis soustavy řízení levitace z počítače PC Pro náš účel byl fyzikální model připojen k počítači PC prostřednictvím již zmiňované multifunkční karty PCA408 a později též karty PCA208 [TEDIA S.R.O.]. Zvolený počítač PC lze stručně charakterizovat takto: CPU Intel Pentium II 333 MHz, takt sběrnice 00 MHz, 28 MB RAM, pevný disk o kapacitě 5 GB, rozhraní IDE ATA 33 (IRQ4). Na počítač byl nainstalován operační systém MS Windows 2000 se servisním balíčkem SP4. Do systému byly nainstalovány ovladače CDPCA408.sys a CDPCA208.sys spolu s komponentou COM a uživatelskou aplikací. 2.3 Dosažené výsledky v řízení levitace K řízení byly postupně úspěšně vyzkoušeny všechny realizované algoritmy regulátorů společně se vzorkovací periodou ms. Prakticky se však stabilní řízení podařil zrealizovat pouze PID regulátory s filtrací. Nejlepší výsledky byly dosaženy polohovým PID regulátorem s filtrem prvního řádu derivační složky. Nejprve byly provedeny pokusy s pozvednutím levitujícího předmětu z pevné podložky (dolní úvratě) do požadované polohy. Jak dokládá graf na obrázku 2.2, regulátor tento úkol zvládl.

33 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT 33 Obr. 2.2 Průběh regulace polohovým PID regulátorem s filtrem D-složky, pozvednutí předmětu z pevné podložky do výše cca 6,8 mm Následně byly prováděny skokové změny žádané hodnoty a tím i polohy předmětu. Zde se však již projevila silná nelinearita elektromagnetické levitace. Jejím důsledkem nebylo možné nalézt optimální parametry regulátoru, jenž by zajistily kvalitní a stabilní řízení ve všech polohách přípustného rozsahu. Obr. 2.3 Průběh regulace polohovým PID regulátorem s filtrem D-složky, změny polohy Typickým příkladem je průběh levitace na obrázku 2.3, kdy po pozvednutí předmětu byla postupně skokově zvyšována žádaná hodnota a tím přibližován předmět k cívce. Z grafu vyplývá, že regulátor změny žádané veličiny v rozsahu -3 -,5 V (což odpovídá poloze 0 8,2 mm) velmi dobře zvládl. Avšak při změně veličiny na hodnotu - V (9,5 mm) se řízení stalo již nestabilním. Jiným nastavením regulátoru (viz obr. 2.4) se sice pracovní rozsah (0 5,2 mm) a i velikost přípustné skokové změny zvýšil, avšak na úkor kvality regulace. Souhrn disertační práce

34 34 Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT Obr. 2.4 Průběh regulace polohovým PID regulátorem s filtrem D-složky, změny polohy 2.4 Dosažené výsledky z pohledu zpracování v reálném čase Úspěšná realizace řízení zcela ověřila funkčnost celého navrženého systému. Všechny předvedené záznamy byly získány uvedeným mechanizmem čtení dat o průběhu regulace bez zjištění sebemenšího vlivu na daný proces. Záznam byl prováděn vždy pro všechny vzorky, přičemž při jinak nezatěžovaném systému a (vzhledem k frekvenci) dostatečné velikosti bufferů nebyla zjištěna sebemenší ztráta dat ani při realizaci řízení s limitní vzorkovací frekvencí 0 khz. Poté byly během řízení úmyslně prováděny různé operace zatěžující systém na všech úrovních. Například byly prováděny samostatně i společně tyto operace : kopírování rozsáhlého množství dat v lokálních složkách, kopírování rozsáhlého množství dat v rámci lokální sítě, kompletní instalace aplikace MS Office 2000 z CD nosiče, přehrávání hudby ve formátu MP3 a videa formátu DivX, zpracovávání získaných dat v aplikaci MS Excel. I když z uživatelského hlediska byl operační systém těmito operacemi mnohdy zjevně přetížen, vlastní řízení nebylo žádným způsobem ovlivněno. Z pochopitelných důvodů však zatížení systému mělo vliv na ztrátu informačních dat s průběhem regulace. Tomu se však poměrně úspěšně dařilo zabránit zvýšením priority procesu uživatelské aplikace. 3 Závěr Tato disertační práce je zaměřena na problematiku využití operačních systémů rodiny MS Windows NT k realizaci řízení technologických procesů v reálném čase. V první části práce je proveden rozbor operačních systémů společnosti Microsoft. Pozornost je věnována operačním systémům rodiny MS Windows NT z hlediska využití v systémech řízení technologických procesů a v systémech reálného času. Další část práce se věnuje návrhu vlastního řešení zmíněné problematiky. Návrh vychází z možnosti přenést časově kritické operace do nižších vrstev operačního systému, konkrétně do obsluhy přerušení. Využívá tak časovačů přídavného zařízení ke generování přesné vzorkovací periody ve formě požadavků IRQ. Práce také řeší doprovodné problémy vznikající s přenesením výpočetní části algoritmu do nitra ovladače. Především se jedná o problematiku aritmetiky reálných čísel, jenž není do překladače implementována.