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

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: Studijní obor: Doktorand: Školitel: Školitel specialista:

23 01 V Strojní inženýrství Automatizace technologických procesů, 39-12-9 Ing. David FOJTÍK Prof. Ing. Jiří Tůma, CSc. Dr. Ing. Dalibor Kačmář

Ostrava 2004

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:

Obhajoba

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ě

disertační

práce

se

koná

dne

……………………

v zasedací

místnosti

…………………… v …………………… hodin, v budově VŠB–TU Ostrava, tř. 17. listopadu 15, 708 33 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ř. 17. listopadu 17, 708 33, Ostrava–Poruba, místnost A 132.

Ing. David Fojtík


3

1 Ú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


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 16-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.1

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 16-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 LS251, 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ěť (12 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 Ing. David Fojtík


5

MS Windows NT 4.0 jsou k dispozici systémy [KUCHAŘ]: OpenControl, Pyradim-31, 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 1998B, 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 systémy reálného času

MS Windows NT

a

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

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


6


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]: 1. 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í.

4.2.1

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í, 1 - nejnižší možná, 31 - 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í 16 až 31). 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 (16, 22 ÷ 26, 31), 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.

Ing. David Fojtík

7


Priorita

Průběh… Úloha C

- Vlákno běží

Úloha B

- Vlákno čeká

Úloha A

- Uzamčený zdroj

Zdroj 0

1

2

3

4

5

Čas [ms]

Obr. 4.1 Princip vzniku inverze priorit

Tento jev vzniká (viz obr. 4.1), 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.

4.2.2

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 31) 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 Nejnižší priorita

31 Časově kritická …

27 ISR - Zařízení 1 26 ISR - Zařízení 2

24 Normální …

Softwarová přerušení

… 4

ISR - Zařízení n

3

Ladění programů/aplikací

2

DPC

1

APC

0

Vlákna Win32 API

16 Klidová 15 Kritická: všechny třídy … 13 Normální: třída vysoká …

Uživatelský režim

Režim jádra

8 Normální: třída normální … 4 Normální: třída klidová … 1

Klidová: všechny třídy

0

Podproces nulové stránky

Priority reálného času

Priority Win32 API vláken

29 Meziprocesorová synch. 28 Přerušení časovače

Proměnné úrovně priorit Třída: Vysoká, Normální, Klidová

Hardwarová přerušení

31 Kritická chyba HW 30 Výpadek napájení

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é


8


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 1. 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 1 [JEFFREY]. Na těchto úrovních jsou již vlákna zpracována podle již zmíněného mechanizmu priorit (0 ÷ 31). 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.

4.2.3

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ž 1 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

Ing. David Fojtík


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

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 Uživatelský software Výběr typu regulátoru včetně nastavení všech jeho parametrů

Nízkoúrovňový ovladač karty

Řízená soustava

IRQ

Multifunkční karta

Technologický proces

Časovače w

Výpočet e odchylky

Algoritmus regulace

u

D/A

Akční veličina

A/D

Regulovaná veličina

(Rutina – ISR)

y

Obr. 5.1 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ů: 1. 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.


10


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. 10. 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. 11. 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. 12. 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: 1. 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.

Ing. David Fojtík

11


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

8

23

S

E

M

Exponent

Mantissa

Sign

FloatValue = (-1)S · 2E-127 · 1,M

Obr. 6.1 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ě 1,M. Předpokládáme-li použití maximálně 16-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 6.2. 10 ,625

10 ,625

… 0

0

… 0 0 0 1 0 1 0 1 0 1 0 0 0 … … 0

0 1

0

1 0

1

+

-

1 0

1

0

1 0

0

0 …

127 + 3 = 130 0

1 0

0

0 …

0,25 + 0,0625 + 0,015625

0,125

01000001001010100000000000000000 S

8 + 2 = 10

0

0,5

8

0

+3

26 25 24 23 22 21 20 2-1 2-2 2-3 2-4 2-5 2-6 2

0 1

E = 130

M = 0,328125

0,5 + 0,125 = 0,625 (-1)S · 2E-127 · 1,M = 23 · 1,328125 = 10,625

Obr. 6.2 Příklad binární podoby 32 bitového reálného čísla 10,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.1. Tab. 6.1 Seznam vybraných funkcí a maker pro práci s reálnými čísly v rutinách ovladačů Název funkce/makra

Popis

R32TOUSHORT

Makro převádějící reálné číslo na celočíselný USHORT.

R32FROMUSHORT

Makro převádějící celočíselný USHORT na reálné číslo.


12


Název funkce/makra

Popis

r32sum

Funkce součtu dvou reálných 32 bitových čísel.

r32add

Funkce přičtení druhého 32 bitového reálného čísla k prvnímu.

r32diff

Funkce rozdílu dvou reálných 32 bitových čísel.

r32mul

Funkce součinu dvou reálných 32 bitových čísel.

r32div

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

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.1). 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 15 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.1). Adresní sběrnice Datová sběrnice

CPU

Řídící sběrnice INTR

CS A0

D0 – D7

INTA

RD WR

8259A Slave – A0H 7

6

5

4

3

2

IR15 IR14 IR13 IR12 IR11 IR10

INT

CS A0

CAS 0

CAS 0

CAS 1

CAS 1

CAS 2

CAS 2

D0 – D7

INTA

RD WR

INT

8259A Master – 20H

1

0

7

6

5

4

3

2

1

0

IR9

IR8

IR7

IR6

IR5

IR4

IR3

IR2

IR1

IR0

Obr. 7.1 Zjednodušené schéma standardního zapojení obvodu 8259A

Ing. David Fojtík


13

Původní vstup IR2 je nahrazen vstupem IR1 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.1). Tab. 7.1 Kanály přerušení v počítačích PC/AT IRQ

Nejvyšší

0

Systémové hodiny

1

Klávesnice

8

Hodiny reálného času

Nejnižší

7.2

Zařízení

Priorita

2,9

Původní IR2/Rezervováno

10

Rezervováno

11

Rezervováno

12

PS/2 Myš

13

Matematický koprocesor

14

Pevný disk

15

Rezervováno

3

Sériové rozhraní COM2/COM4

4

Sériové rozhraní COM1/COM3

5

Rezervováno/Zvuková karta

6

Disketová jednotka

7

Paralelní port

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 1996, INTEL CORPORATION 1997A, INTEL CORPORATION 1997B, INTEL CORPORATION 1997D] 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 1996, 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 1997B], 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


14


od obvodu IOAPIC k procesorům i navzájem mezi jednotlivými procesory (vše přes vlastní LAPIC obvody).

CPU 1

Local Interrupt LINT0 LINT1

LAPIC


CPU 2 LAPIC


CPU 3 LAPIC

APIC Bus

PICCLK PICD0 PICD1

IR0 – IR15

Clock

2x 8259A (82C59)

I/O APIC (82093AA) PIIX3/4

Obr. 7.2 Zjednodušené schéma konfigurace systému APIC

7.2.1

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.

7.2.2

Local APIC (LAPIC)

Jednotka Local APIC byla poprvé integrována již do druhé generace procesorů Pentium (od verze 735/90 a 815/100) [INTEL CORPORATION 1997B] 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 16 ÷ 255. Z toho však 16 ÷ 31 je exkluzivně vyhrazeno pro procesor. Vlastní úroveň priority se vyhodnocuje vztahem Priorita = Vektor / 16, kde 1 je nejnižší priorita a 15 nejvyšší [INTEL CORPORATION 1997B].

Ing. David Fojtík


15

8 Správa přerušení v MS Windows NT/2000/XP 8.1

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 1998A, 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.1. Tab. 8.1 Vztah mezi úrovněmi IRQL a žádostmi IRQ IRQL

IRQ

Popis

31

-

Kritická chyba hardwaru.

30

-

Výpadek napájení.

29

-

Přerušení pro víceprocesorovou synchronizaci.

28

0

Přerušení časovače.

27

-

Profily.

26

1

Klávesnice.

25

2

Výstup INT podřízeného řadiče.

24

3

Sériové rozhraní COM2/COM4.

23

4

Sériové rozhraní COM1/COM3.

22

5

Rezervováno/Zvuková karta.

21

6

Disketová mechanika.

20

7

Paralelní port.

19

8

Hodiny reálného času.

18

9,2

16,17

11,10

15

12

PS/2 Myš.

14

13

Matematický koprocesor.

13

14

Pevný Disk.

12

15

Rezervováno.

4 ÷ 11

-

Nepoužité priority.

3

-

Softwarové přerušení pro ladící účely.

2

-

Softwarové přerušení pro DPC.

1

-

Softwarové přerušení pro APC.

0

-

Softwarová úroveň přerušení, na které běží veškeré aplikace.

Původní IRQ2 nebo IRQ9. Rezervováno.

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í


16


odlišnosti správy ovladačů mezi Windows NT [MICROSOFT 1998A] a Windows 2000/XP [MICROSOFT 2000], kde přibyla podpora Plug and Play.

8.1.1

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.

8.1.2

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.

8.1.3

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: 1. 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ě. Ing. David Fojtík


8.2

17

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.1 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, IR1 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: 1. 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.


18


9.1

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.1. Na této úrovni je pak daná obsluha vykonána. Vlastní registrace se ve Windows NT [MICROSOFT 1998A] provádí ve dvou krocích: 1. 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, 0, irq, irq, &irql, Systémem přidělená &Affinity ); úroveň IRQL

// // // // // //

Interface type Bus number Bus interrupt level Bus interrupt vector IRQ level 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 FALSE //FloatingSave (For X86 FALSE) obsluha poběží );

Obr. 9.1 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 IR1 IR0 Priorita 4 3 2 1 0 7 6 5 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 31 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).

Ing. David Fojtík


19

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ů: 1. 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 1998B], ž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.

9.4.1

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

Speciální ovladač

Algoritmus odezvy (Rutina – ISR)

IRQ

Hardware

I/O zařízení

Měřící systém: MS DOS/Windows 98

Hardware

Měřící program

LPT

Zahájení měření

PCA1216

Vyhodnocení

Obr. 9.4 Princip měření latence odezvy na vznik přerušení

9.4.2

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.


20


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: 1. 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 10, 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í

9.4.3

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 (IRQ10), • 64 MB RAM, • CD ROM 4x, připojený přes rozhraní ID (IRQ14). 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 600 000 dotazů sériově prováděných v intervalech cca 160 µ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 100 % zatížení. Kopírováním obsahu CD na pevný disk do systému vstupují obsluhy přerušení IRQ14 a IRQ10, 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.

Ing. David Fojtík

21


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í 600 000 vzorků podle času odezevy v MS Windows 2000

Rozložení 600 000 vzorků podle času odezevy v MS Windows NT 4.0 1 000 000

1 000 000

389 440

295 060

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Bez zatížení

100 000

V 99,9% odezva přijata do 13 µs Všechny odezvy přijaty do 33 µs

1 000

100


10 000

Násobek odezvy

Násobek odezvy

10 000

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Bez zatížení

100 000

10

1 000

100

10

99,9%

99,9%

1

1 1

3

5

7

9

11 13 15 17

19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

1

3

5

7

9

11 13 15 17 19 21

Čas odezvy [µs]

23 25 27 29 31 33 35

37 39 41 43 45 47 49

Č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í 600 000 vzorků podle času odezevy v MS Windows NT 4.0

Rozložení 600 000 vzorků podle času odezevy v MS Windows 2000 1 000 000

1 000 000

190 651

235 296 100 000


1 000

100

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo: CPUStress a kopírování z CD na HD

100 000


10 000

Násobek odezvy

10 000

Násobek odezvy

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo: CPU Stress a kopírování z CD na HD

1 000

100

10

10

99,9%

99,9% 1

1 1

3

5

7

9

11 13 15 17 19 21 23 25 27 29

Čas odezvy [µs]

31 33 35 37 39 41 43 45 47 49

1

3

5

7

9

11 13 15 17

19 21 23 25 27

29 31 33 35 37 39

41 43 45 47 49

Č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 13 µs na 26 µs. Obdobné závěry lze vysledovat také srovnáním grafů získaných na MS Windows 2000. 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 2000. 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


22


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í 600 000 vzorků podle času odezevy v MS Windows NT 4.0

Rozložení 600 000 vzorků podle času odezevy v MS Windows 2000

1 000 000

1 000 000

238 592

217 018

Pentium 90 MHz, IRQ7 - paralelní port Společně všechny úpravy: maska INTR, IRQL 31, max IR7 Zatíženo: CPU Stress a kopírování z CD na HD

100 000



10 000

Násobek odezvy

Násobek odezvy

10 000

Pentium 90 MHz, IRQ7 - paralelní port Obě úpravy společně: nejvyšší IR7, IRQL 31 Zatíženo: CPUStress a kopírování z CD na HD

100 000

1 000

100

10

1 000

100

10

99,9%

99,9% 1

1 1

3

5

7

9

11 13 15 17

19 21 23

25 27 29

31 33 35

Čas odezvy [µs]

37 39 41 43

45 47 49

1

3

5

7

9

11 13 15 17

19 21 23

25 27 29

31 33 35

37 39 41 43

45 47 49

Č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

9.4.4

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 SP1. Jako referenční byly zvoleny čtyři výkonnostně odlišné sestavy... A. Pentium – 90 MHz: C. Celeron – 1100 MHz: • CPU Intel Pentium 90 MHz, • CPU Intel Celeron 1100 MHz, • takt sběrnice 66 MHz, • takt sběrnice 100 MHz, • 64 MB RAM. • 512 MB RAM. B. Celeron – 400 MHz: D. Pentium 4 – 2000 MHz: • CPU Intel Celeron A 400 MHz, • CPU Intel Pentium 4 – 2 GHz, • takt sběrnice 66 MHz, • takt sběrnice 400 MHz, • 128 MB RAM. • 512 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.

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

Ing. David Fojtík


Rozložení 600 000 vzorků podle času odezevy v MS Windows NT 4.0


1 000 000

117 806

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM

100 000


117 623

1 000

100

Pentium 90 MHz, IRQ7 - paralelní port Všechny úpravy: IRQL31, max IR7, mask INTR Zatíženo programy IRQ_HD a COM To COM

100 000


10 000

Násobek odezvy

10 000

Násobek odezvy

23

1 000

100

10

10

99,9%

99,9% 1

1 1

3

5

7

1

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

Č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í 600 000 vzorků podle času odezevy v MS Windows 2000


1 000 000

105 971

Pentium 90 MHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM

100 000


1 000

100

Pentium 90 MHz, IRQ7 - paralelní port Všechny úpravy: IRQL 31, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM V 99,9% odezva přijata do 21 µs Všechny odezvy přijaty do 40 µs

10 000

Násobek odezvy

Násobek odezvy

10 000

116 695 100 000

10

1 000

100

10

99,9%

99,9%

1

1

1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

Čas odezvy [µs]

Obr. 9.10 Reakční doby na vznik přerušení sestavy Pentium 90 MHz s MS Windows 2000

9.4.4.2 Pentium 4: 2000 MHz Tato nejvýkonnější měřená stanice se od ostatních liší především použitou čipovou sadou Intel 82845 MCH a Intel 82801 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í 600 000 vzorků podle času odezevy v MS Windows NT 4.0


1 000 000

315 700

312 614

Pentium 4 - 2 GHz, IRQ7 - paralelní port Standardní mechanizmus - bez úprav Zatíženo programy IRQ_HD a COM To COM

100 000

V 99,9% odezva přijata do 20 µs Všechny odezvy přijaty do 2 673 µs

1 000

100


10 000

Násobek odezvy

Násobek odezvy

10 000

Pentium 4 - 2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL31, max IR7, mask INTR Zatíženo programy IRQ_HD a COM To COM

100 000

1 000

100

10

10

99,9%

99,9% 1

1 1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

Obr. 9.11 Reakční doby na vznik přerušení sestavy Pentium 4 – 2 GHz s MS Windows NT 4.0


24




156 499


1 000

100

Pentium 4 - 2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL31, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM

100 000


10 000

Násobek odezvy

10 000

Násobek odezvy

159 456


100 000

1 000

100

10

10

99,9%

99,9% 1

1

1

3

5

7

1

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

Čas odezvy [µs]

Obr. 9.12 Reakční doby na vznik přerušení sestavy Pentium 4 – 2 GHz s MS Windows 2000 Rozložení 600 000 vzorků podle času odezevy v MS Windows XP

Rozložení 600 000 vzorků podle času odezevy v MS Windows XP 1 000 000

1 000 000

301 008

100 000


1 000

100

Pentium 4 - 2 GHz, IRQ7 - paralelní port Všechny úpravy: IRQL31, nejvyšší priorita IR7 Zatíženo programy IRQ_HD a COM To COM

100 000


10 000

Násobek odezvy

10 000

Násobek odezvy

296 397


1 000

100

10

10

99,9%

99,9% 1

1 1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

1

3

5

7

9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59

Čas odezvy [µs]

Čas odezvy [µs]

Obr. 9.13 Reakční doby na vznik přerušení sestavy Pentium 4 – 2 GHz s MS Windows XP

10 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í: 1. 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í.

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

Ing. David Fojtík


25

Win32 API aplikace Uživatelský režim Režim jádra

Ovladač Rozhraní

Logicko-funkční vrstva

Fyzická vrstva

Hardware Multifunkční karta

Obr. 10.1 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.

10.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: 1. 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.

10.2.1 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: 1. 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ů,


26


b) jednorozměrnou regulaci, c) vícenásobnou regulaci, d) uživatelskou regulaci.

10.2.2 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í.

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

10.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 10.1.

Ing. David Fojtík


27

Tab. 10.1 Seznam funkcí fyzické vrstvy Název funkce

Popis

HwSetAIValRange

Nastavení měřicího rozsahu A/D vstupů.

HwSetAOValRange

Nastavení rozsahu D/A výstupů.

HwSetSpecialCardData

Nastavení specifických voleb multifunkční karty.

HwCardInitialize

Provede počáteční inicializaci karty po zavedení ovladače.

HwReadMultipleAI

Ihned změří požadované A/D vstupy.

HwWriteMultipleAO

Ihned nastaví požadované D/A výstupy.

HwSetTimerPriode

Inicializuje časovače a nastavuje vzorkovací periodu.

HwTimerStart

Spouští činnost časovačů.

HwTimerStop

Pozastavuje činnost časovačů.

HwClrIntr

Maže příznak přerušení – potvrzení ukončení obsluhy IRQ.

HwSetScanning

Inicializuje měřicí kartu k provádění nepřetržitého měření.

HwScanning

Měřicí sekvence periodické činnosti nepřetržitého měření.

HwSetSingleReg

Inicializuje měřicí kartu k provádění jednorozměrné regulace.

HwSetMultipleReg

Inicializuje měřicí kartu k provádění soustavy regulátorů.

HwSetUserReg

Inicializuje měřicí kartu k provádění uživatelského regulátoru.

HwReadY

Změří regulovanou veličinu jednorozměrného regulátoru.

HwWriteU

Nastaví akční veličinu jednorozměrného regulátoru.

HwReadGroupY

Změří soustavu regulovaných veličin vícerozměrného regulátoru.

HwWriteGroupU

Nastaví soustavu akčních veličin vícerozměrného regulátoru.

10.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ů: 1. 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.

10.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í


28


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.

10.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. 10.1. Tab. 10.1 Seznam vybraných zdrojových souborů ovladače Název souboru

Popis

INIVAL.h

Deklarace konstant popisující základní vlastnosti karty.

MYDRIVER.c

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

Soubor zdrojů.

SOURCES

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

Deklarace hlaviček funkcí fyzického rozhraní.

UACD_IOCTL.h

Rozhraní obecného ovladače.

UACD_MAIN.h

Definice základních rutin ovladače.

Implementace ovladače na nové zařízení lze shrnout do následujících bodů: 1. 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. 10. Provést instalaci nového ovladače.

10.8 Realizace ovladače pro měřicí karty PCA1408 a PCA1208 Úpravou popisovaných souborů byl vytvořen ovladač pro multifunkční měřicí kartu PCA1408 a později také pro kartu PCA1208. Výsledkem je soubor ovladače CDPCA1408.SYS (CDPCA1208.SYS) a instalační soubor CDPCA1408.INF

Ing. David Fojtík


29

(CDPCA1208.INF) pro Windows 2000/XP a CDPCA1408.REG (CDPCA1208.REG) pro Windows NT 4.0.

11 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 Uživatelský režim Režim jádra

Ovladač Ovladač

Hardware Multifunkční karta

Obr. 11.1 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.

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

11.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ř. IPCA1408).


30


•

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, IRegPIDPosF1, IRegPIDPosF1D, 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í IPCA1408 (nahrazuje nespecifikované rozhraní), které reprezentuje individuální nastavení multifunkční karty PCA1408 (viz obr. 11.2). IUnknown

ICDMain

IPCA1408

IAnalogIO IScanning ISingleReg IRegPIDPos IRegPIDInc IRegPIDPosF1

COM Pro ovladač CDPCA1408

IRegPIDPosF1D IMultipleReg IUserReg IUserRegParameter IRealTimeIRQ

Obr. 11.2 Rozhraní komponenty COM s plnou podporou ovladače multifunkční karty PCA1408

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

Ing. David Fojtík


31

Obr. 11.3 Uživatelská ovládací aplikace

12 Řízení levitace feromagnetického v elektromagnetickém poli

předmětu

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.

12.1 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 ÷ 10 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.


32


Rám

80

Ø70

Cívka 2500 závitů

Jádro cívky Ø25

295

Le vitující pře dmět (permanentní magnet v pingpongovém míčku)

Analogové signály

Laserový triangulační snímač polohy

30

Elektronika: Galvanické oddělení a přizpůsobení akčního zásahu

60

Napájení 24V 2A

15

220

50

140

Obr. 12.1 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.

12.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 PCA1408 a později též karty PCA1208 [TEDIA S.R.O.]. Zvolený počítač PC lze stručně charakterizovat takto: • CPU Intel Pentium II 333 MHz, takt sběrnice 100 MHz, • 128 MB RAM, • pevný disk o kapacitě 15 GB, rozhraní IDE ATA 33 (IRQ14). 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 CDPCA1408.sys a CDPCA1208.sys spolu s komponentou COM a uživatelskou aplikací.

12.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 1 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 12.2, regulátor tento úkol zvládl.

Ing. David Fojtík


33

Obr. 12.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. 12.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 12.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 ÷ -1,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 -1 V (9,5 mm) se řízení stalo již nestabilním. Jiným nastavením regulátoru (viz obr. 12.4) se sice pracovní rozsah (0 ÷ 15,2 mm) a i velikost přípustné skokové změny zvýšil, avšak na úkor kvality regulace.


34


Obr. 12.4 Průběh regulace polohovým PID regulátorem s filtrem D-složky, změny polohy

12.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í 10 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.

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

Ing. David Fojtík


35

Poměrně značná část práce se zabývá identifikací interních mechanizmů správy obsluh přerušení v závislosti na použitém hardwarovém řadiči a konkrétní verzi operačního systému. Na jejím základě jsou navrženy a realizovány úpravy minimalizující a determinující prodlevu od vzniku požadavku na přerušení k zahájení jeho obsluhy. Vše je důkladně ověřeno přesným měřením prováděným na různých výkonnostně odlišných hardwarových platformách a verzích operačních systémů. Následně práce popisuje architekturu fyzické realizace navrženého řešení. Konkrétně se jedná o obecný polotovar nízkoúrovňového ovladače snadno implementovatelný na převážnou část multifunkčních analogových karet. Standardně ovladač poskytuje několik typů plně stavitelných regulátorů a funkci nepřetržitého měření s vysokou vzorkovací frekvencí zvolených analogových vstupů. Součástí práce je podrobný návod na přidání dalších řídicích algoritmů a na implementaci ovladače pro konkrétní zařízení. Funkčnost byla ověřena vytvořením ovladačů pro dvě multifunkční karty PCA1408 a PCA1208. Programátorské použití ovladačů velmi usnadňuje realizovaná komponenta COM, která umožňuje tvorbu ovládacích aplikací v různorodých programovacích jazycích. Komponenta byla použita při vytváření uživatelské ovládací aplikace, jenž umožňuje snadno používat všechny funkce ovladače a zpracovávat získaná data v příjemném uživatelském prostředí. Závěr práce je věnován ověření realizovaného systému na řízení levitace feromagnetického předmětu v elektromagnetickém poli. Úspěšná realizace prověřila funkčnost všech částí systému včetně komponenty a uživatelské aplikace, především však nezávislost řídícího procesu na libovolné uživatelské činnosti v systému. Spojením ovladače, komponenty a uživatelské aplikace vzniká snadno implementovatelný doplněk, jenž umožňuje spojit vlastní řízení technologických procesů náročných na rychlost a dobu zpracování s možnostmi operačních systémů architektury MS Windows NT. Vlastní algoritmus regulace se dělí o výpočetní výkon jednoho počítače spolu s jinými programy, které vizualizují či jinak zpracovávají vlastní regulační proces. Systém je navržen tak, aby algoritmus regulace byl vždy přednostně zpracován před požadavky jakékoliv aplikace včetně systémových služeb a jiných systémových činností. Mezi významné přínosy práce patří prakticky ověřený plně funkční doplněk, umožňující zcela bez omezení využívat počítač PC s nainstalovaným operačním systémem MS Windows NT/2000/XP a současně realizovat řízení systémů, které vyžadují vysoce rychlé zpracování řídicích algoritmů v reálném čase. Těžiště hlavního přínosu práce leží v principu časování periodických operací, jenž atypicky využívá obsluhu přerušení nezávislých hardwarových časovačů k provádění časově kritických algoritmů. Tento princip umožňuje spolehlivě provádět řízení případně i měření se vzorkovací periodou v řádu až desítek mikrosekund, která je jinak dosažitelná pouze ve specializovaných operačních systémech. Neméně významným přínosem práce je detailní popis interních mechanizmů správy přerušení realizovaných v operačních systémech MS Windows NT/2000/XP spolu s návodem na jejich úpravu zvyšující determinovatelnosti vybrané obsluhy přerušení. Díky tomu je možné v počítačových systémech s obvody 8259A zajistit spolehlivé časování i při značných frekvencích, nezávisle na konkrétně použitém kanálu přerušení. Další přínos práce spočívá v architektuře zmíněného doplňku, jehož přednost tkví v jednoduchosti použitého řešení, které oproti ostatním nemodifikuje či nerozšiřuje jádro systému, nýbrž jej využívá neobvyklým způsobem. Tím jsou zachovány veškeré vlastnosti operačního systému MS Windows NT/2000/XP, včetně jeho podpory ze strany výrobce. Nasazení modulu se tak omezuje pouze na instalaci vstupně/výstupní karty, daného ovladače, komponenty COM a případně uživatelské aplikace. Současně je pamatováno na maximální a snadnou rozšiřitelnost a přenositelnost řešení, umožňující doplnit modul o nové algoritmy řízení nebo přenést řešení na nové typy multifunkčních analogových měřicích karet. Tato flexibilita umožňuje doplněk dále rozvíjet a přizpůsobovat konkrétním potřebám, což je nezbytný předpoklad k širšímu využití v technické praxi. Souhrn disertační práce

36


Abstract System Modules Implementation for Process Control Support at MS Windows NT Operating System This dissertation thesis is devoted to utilisation operating system MS Windows NT family for technological process control implementation at the real time mode. The first part contains analysis of operating system of Microsoft Corporation. The attention is devoted to MS Windows NT operating systems from the point of view exploitation at the technological control systems and also real-time systems. Important part of work is devoted to design of own solution of real-time process control in MS Windows environment. Design is standing on the fact, that we have possibility to transfer critical operation to lower layer of operating system especially into interrupt handling. The solution uses timer of special devices for exact sample period generating in form of IRQ request. In this work is an also resolved accompanying problem, beginning with transfer computation part of mathematical algorithm into driver kernel. The major problem is float arithmetic, which is not implemented into compiler. Rather a lot of work deal with internal mechanisms identification of interrupts handling in depending of used hardware controller and version of operating system. On the basis of that are designed and implemented settings to minimize and determine delay from interrupt request creation. All is properly validated by set of correct measurement executed on different hardware platform and operating system versions. Next chapters are devoted to architecture of physical realization of solution. In particular is described low-level driver for the implementation of a lot of multifunction analog card. Standard driver provided several type of fully adjustable controller and function of continuous measurement with large sample period of selected analog input. Necessary part of work is the instruction guide for adding another control algorithms and driver implementation for concrete devices. Functionality was verified by implementation of drivers for two multifunction cards PCA1408 and PCA1208. Executed COM component, which enable the implementation of control application in different program language, makes easy programmer usage of drivers. The component has been used for user command application, which enables easy usage of all function of driver and processing acquired data in user-friendly environment. The conclusion is devoted to the verification of the implemented system for control of levitation of ferromagnetic object in the electromagnetic field (Electro-Magnetic Suspension). The Validation of all part of whole system was successful complete with component and user application, above all control process independence on any user task in the system..

Ing. David Fojtík


37

14 Přehled publikací autora FOJTÍK, D. 1999. Využití OS Windows NT s Windows CE k řízení v reálném čase. In Proceedings of XXIII. ASR Seminary ’99 “Instruments and Control“, Ostrava : KAKI, 1999, vol. 44. pp. 1-9. ISBN 80-7078-666-3. CEZ 011. Kód: JC. Anotace: Utilization of the OS Windows NT with Windows CE to the real time control FOJTÍK, D. 2000A. Řízení teplo-vzdušného modelu v prostředí MS Windows NT. Závěrečná zpráva interního doktorského grantu FS VŠB – TUO. Ostrava: VŠB-TU Ostrava, 1999. 36s. + 24s. příloh. FOJTÍK, D. 2000B Ovladač karty PCA1408 pro MS Windows NT realizující řízení v reálném čase. In Proceedings of XXIV. ASR '2000 Seminar "Instruments and Control" [online]. Ostrava : VŠB-TU Ostrava, 2000, vol. 6, 8 p. [cited 2000-05-04]. ISBN 80-7078-774-0. FOJTÍK, D. 2001. Řízení modelu Levitace ocelového válečku v magnetickém poli prostřednictvím MS Windows NT. Závěrečná zpráva interního doktorského grantu FS VŠB – TUO. Ostrava: VŠB-TU Ostrava, 2001. 25s. FOJTÍK, D. 2003A Měření latence odpovědi na vznik přerušení v operačním systémech MS Windows NT/2000. In Workshop 2003 Fakulty strojní. Ostrava : VŠB-TU Ostrava, 17. 1. 2003, s. 109-112. ISBN 80-248-0233-3. FOJTÍK, D. 2003B Správa požadavků na přerušení v MS Windows NT/2000/XP využívající obvody PIC-8259A. In Proceedings of XXVIII Seminary ASR 2003 „Instruments and Control“. Ostrava : VŠB-TU Ostrava, 6. 5. 2003, pp. 82-93. ISBN 80-248-0326-7. FOJTÍK, D. 2003C Návrh a realizace úprav zvyšující determinovatelnost zpracování zvoleného požadavku IRQ v MS Windows NT/2000/XP využívající obvody PIC-8259A. In Proceedings of XXVIII Seminary ASR 2003 „Instruments and Control“. Ostrava : VŠBTU Ostrava, 6. 5. 2003, pp. 69-81. ISBN 80-248-0326-7. FOJTÍK, D. 2004 Ovladač realizující řízení v reálném čase pod operačním systémem MS Windows 2000. In Workshop 2004 Fakulty strojní. Ostrava : VŠB-TU Ostrava, 12. 2. 2004, s. 55. ISBN 80-248-0521-9.


38


15 Literatura ASPINWALL, J. 1999. IRQ, DMA a I/O Předcházení a řešení konfliktů v konfiguraci počítače. Praha: Computer Press, 2000, první vydání. ISBN 80-7226-264-5 BELLO, CH. 1999. Vývoj aplikací ve Windows CE. Mistrovství ve MS Visual Basicu 6.0. Praha: Compurte Press, 1999, s. 165-208. ISBN 80-7226-205-x COMP.REALTIME Diskusní fórum. Dostupné z: FARANA, R., SMUTNÝ, L., VÍTEČEK, A. 1999. Zpracování odborných textů z oblasti automatizace a informatiky. 1. vyd. Ostrava : VŠB-TU Ostrava, 1999. 68 s. ISBN 80-7078-737-6. HEGER, M. 1991 Prostředky řídících systémů. Ostrava : VŠB-TU Ostrava, 1991. ISBN 80-7078072-X. HOUŠKA, J. 1999. Operační systémy Microsoft jako systémy reálného času. Automatizace, 1999, roč. XLII, č.5, str. 325-328. ICS, Windows NT for real-time control: Which way to go? [online]. 1997, Dostupné z INTEL CORPORATION 1988. 8259A Programmable interrupt controller [online]. Intel Corporation December 1988. PDF format. Available from WWW: . Order Number 231468-003 INTEL CORPORATION 1996. 82093AA I/O Advanced programmable interrupt controller (IOAPIC) [online]. Intel Corporation May 1996. PDF format. Available from WWW: . Order Number 290566-001. INTEL CORPORATION 1997A. Pentium® Processor Family Developer’s Manual. 2.9 APIC INTERRUPT CONTROLLER [online]. Intel Corporation 1997. PDF format. Available from WWW: . INTEL CORPORATION 1997B. Intel Architecture Software Developer’s Manual, Volume 3. 7.4 ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) [online]. Intel Corporation 1997. PDF format. Available from WWW: . Order Number 245472-010. INTEL CORPORATION 1997C. 82371AB PCI-TO-ISA / IDE XCELERATOR (PIIX4) [online]. Intel Corporation April 1997. PDF format. Available from WWW: . Order Number 290562-001. INTEL CORPORATION 1997D. MultiProcessor Specification. D Multiple I/O APIC Multiple PCI Bus Systems [online]. Intel Corporation May 1997. PDF format. Available from WWW: . INTEL CORPORATION 2002. Intel® 82801DB I/O Controller Hub 4 (ICH4) [online]. Intel Corporation May 2002. PDF format. Available from WWW: . Order Number 290744-001.

JEFFREY, R. 1997. Windows pro pokročilé a experty. Brno: Computer Press, 1997. ISBN 8085896-89-3 KABEŠ, K. 1999. Operátorský multifunkční panel SIMATIC MP270. Automatizace, 1999, roč. XLII, č.2, s. 96 –97 KAČMÁŘ, D. 2000. Programujeme v COM a COM+. Praha: Computer Press, 2000. ISBN 80-7226381-1. KAČMÁŘ, D. 2001. Microsoft Windows CE verze 2.12 a 3.0 a reálný čas. Automa, 2001, roč. 7, č.1. KAČMÁŘ, D. KULHÁNEK, J. SMUTNÝ, L. VÍTEČEK, A. WAGNEROVÁ, R. LESŇÁK, M. 2002. Nové přístupy k systému řízení v reálném čase technologických procesů prostřednictvím počítače na bázi Windows CE. Ostrava: VŠB-TU, 2002. 96 s. Technická zpráva grantového projektu GA ČR 101/00/0189.

Ing. David Fojtík

39


KAHAN, W. 1996. IEEE Standard 754 for Binary Floating-Point Arithmetic [online]. Elect. Eng. & Computer Science University of California: University of California. PDF format. Available from WWW: . KLIMEŠ, C. Operační systémy 1a. Ostrava : Ostravská univerzita v Ostravě, 2003. 81 s. ISBN 807042-850-3. KUCHAŘ, P. 1998 Přehled trhu: softPLC - nový způsob řízení? Automatizace, 1998, roč. XLI, č.10, s. 709 –713 LORIA 2003. IEEE standard 754 for binary floating-point arithmetic [online]. Laboratoire lorrain de rechercheen informatique et ses applications. Available from WWW: . MICROSOFT 1998A. Microsoft Windows NT DDK. Redmond: Microsoft Corporation Redmond USA, 1998. MICROSOFT 1998B. Microsoft Development Network - April. Redmond : Microsoft Corporation Redmond USA, 1998. MICROSOFT 2000. Microsoft Windows 2000 DDK. Redmond: Microsoft Corporation Redmond USA, June 28, 2000. MICROSOFT 2003. Microsoft Development Network - April. Redmond : Microsoft Corporation Redmond USA, 2003. MUELLER, S. 2001 Osobní počítač. Praha: Computer Press, 2001. ISBN 80-7226-470-2 NĚMEC, D. 1988. Návody a vzory realizací s 8086. Praha: ČSVTS, 1988. O’KEEFE J, A. 2002. Venturcom RTX™ Enabling Microsoft® Windows® Windows XP and Windows XP Embedded for Hard Real-Time. [online]. Venturcom, Inc. 2002. PDF format. Available from WWW: . PROKEŠ, J. 2000. Nové trendy v oblasti automatizační techniky. Automatizace, 2000, roč. XLIII, č.4, s. 238 –239 REISNER, L. 2002. Windows XP a RTX – platforma reálného času. Automatizace, 2002, roč. 45, č.8, str. 464-465. AUTOMATION, SOFT Logic 5 ROCKWELL

Controller,

[online]

Dostupný

z

SHAABAN, M. 1999. Floating Point Arithmetic Using The IEEE 754 Standard Revisited [online]. Lecture notes1999. PDF format. Available from WWW: . SIEMENS, Windows Automation Center – Siemens vstupuje na trh softPLC. Automatizace, 1998, roč. XLI, č.10, s. 717 –718 SOLOMON, A. D. 1999. Windows NT pro administrátory a vývojáře. Praha: Computer Press, 1999. ISBN 80-7226-147-9 ŠVARC, I. 1993. Teorie automatického řízení II. Brno: Vysoké učení technické v Brně, 1993, třetí přepracované vydání. ISBN 80-214-0550-3 TEDIA S.R.O. 1992. Uživatelská příručka PCA-1408. Firemní literatura Tedia s.r.o. 1992 TŮMA, J. 1998. Složité systémy řízení. I. díl, Regulace soustav s náhodnými poruchami. 1. vyd. Ostrava : VŠB-TU Ostrava, 1998. 151 s. ISBN 80-7078-534-9. VAŠEK, V. 1990 Teorie automatického řízení II. Praha: Mezinárodní organizace novinářů, Praha, 1990, 139 p. ISBN 80-214-0115-X Brož. VÍTEČEK, A. 1999. Optimální systémy řízení. Ostrava: VŠB-TU Ostrava, 1999. ISBN 80-7078-736-8 YAMAMOTO, S. & KIMURA, H. 1995. Robust stabilization for parametric uncertainty with application to magnetic levitation. In: Francis, B.A. – Khargonekar, P.P. (editors): Robust control theory, New York, Springer – Verlag, Inf. 1995. p.129-141.


40


Curriculum vitae JMÉNO

Ing. David Fojtík

VZDĚLÁNÍ 1998 – 2004

PhD., Vysoká škola báňská – Technická Univerzita Ostrava, Fakulta strojní. Doktorské studium na katedře Automatizační techniky a řízení. Studijní obor: Automatizace technologických procesů. Název doktorské disertační práce: Tvorba systémových modulů pro podporu řízení v operačním systému MS Windows NT.

1992 – 1998

Inženýr, Vysoká škola báňská – Technická Univerzita Ostrava, Fakulta strojní. Katedra Automatizační techniky a řízení. Studijní obor: Automatické řízení a inženýrská informatika. Název diplomové práce: Algoritmy pro výpočetní systémy s masivně paralelní architekturou.

1988 – 1992

Maturita, Střední odborné učiliště energetické, 1. máje 11, Ostrava. Studijní obor: Mechanik strojů a zařízení

PRAXE 2003 – doposud

Odborný Asistent, VŠB-TU Ostrava, Fakulta strojní. Katedra Automatizační techniky a řízení.

1995 – doposud

Lektor, Školicí středisko AutoCont Ostrava.

1999 – 2003

Asistent, VŠB-TU Ostrava, Fakulta strojní. Katedra Automatizační techniky a řízení.

NAME

Ing. David Fojtík

EDUCATION 1998 – 2004

PhD., Vysoká škola báňská – Technical University of Ostrava, Faculty of Mechanical Engineering. PhD study on Department of Control Systems and Instrumentation. Programme of study: Automation of technological processes. Title of dissertation work: System Modules Implementation for Process Control Support at MS Windows NT Operating System.

1992 – 1998

M.Sc, Vysoká škola báňská Technical University of Ostrava, Faculty of Mechanical Engineering. Department of Control Systems and Instrumentation. Programme of study: Automatic Control Systems and Engineering Informatics. Title of thesis: Computation systems algorithms with massive parallel architecture.

1988 – 1992

Energetic Vocational School, 1. máje 11, Ostrava. Programme of study: Mechanic of Machines and Devices.

EXPERIENCE 1999 – till now

Lecturer, Vysoká škola báňská Technical University of Ostrava, Faculty of Mechanical Engineering. Department of Control Systems and Instrumentation.

1995 – till now

Tutor in AutoCont CZ a.s. – Education center Ostrava.

Ing. David Fojtík

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

Recommend Documents