Realizace řízení v reálném čase pod Microsoft Windows 2000/XP

Realizace řízení v reálném čase pod Microsoft Windows 2000/XP

Článek popisuje princip řešení doplňku operačních systémů technologie MS Windows NT k řízení v reálném čase, jež vychází z možnosti realizovat časově kritické operace v nižších vrstvách operačního systému, konkrétně v obsluze přerušení. Jsou tak využity časovače přídavného zařízení (běžné multifunkční měřicí karty) ke generování přesné vzorkovací periody v řádu až desítek mikrosekund ve formě požadavků IRQ.

1. Úvod

Počítače architektury PC jsou neustále v permanentním zájmu tvůrců řídicích systémů. Poměrně nízká cena, neustálý růst výkonu, velká podpora moderních softwarových i hardwarových komponent a nepřeberné množství výrobců jsou pádnými argumenty pro jejich použití. Důležitým faktorem je také skutečnost, že v současnosti jsou téměř nezbytnou a mnohdy jedinou platformou podnikových informačních systémů. Aplikace osobních počítačů tak nabízí možnost snadno vybudovat zcela uniformní celopodnikový systém. Tím je možné ušetřit nemalé peněžní prostředky.

K tomu, aby se tento požadavek podařilo zcela naplnit, je také třeba sjednotit používané operační systémy. Na platformě PC zcela zjevně dominují operační systémy typu MS Windows NT¹⁾. V této souvislosti se objevuje zcela legitimní požadavek na použití uvedených operačních systémů také k provozu aplikací pracujících v reálném čase.

Této skutečnosti si je vědom i samotný výrobce systému, který mimo to, že již nabízí specializované verze operačních systémů MS Windows NT Embedded a MS Windows XP Embedded, se navíc podílí na vývoji kvalitního doplňku reálného času RTX (Real Time eXtension; autorem je firma VenturCom).

V určitých případech nemusí zmíněný doplněk uživateli zcela vyhovovat. Ne snad proto, že by v něm nebylo možné některé úlohy realizovat, spíše naopak může vyžadovat jednodušší, levné a již specializované řešení, které bude ihned k dispozici bez nutnosti studovat nové prostředí a dotvářet potřebné algoritmy. Jedno takové specializované řešení – doplněk pro oblast řízení v reálném čase – popisuje předkládaný článek.

2. Reálný čas na architektuře MS Windows NT

Je obecně známo, že operační systémy Windows NT nejsou koncipovány jako systémy reálného času. Na toto téma již bylo publikováno mnoho příspěvků. Nebudeme zde znovu probírat, která kritéria Windows NT nesplňují a proč je nelze považovat za systém reálného času, pouze se zaměříme na ty aspekty, jež zásadně komplikují jejich použití v aplikacích specializovaných na řízení a regulaci v reálném čase. Pro potřebu těchto aplikací lze na systému minimálně vyžadovat:

• okamžitý přístup k hardwaru – vstupně-výstupní jednotce,

• přesný, rychlý a za všech okolností spolehlivý časovač, který zajistí opakované probuzení řídicí úlohy ve stanovený okamžik (vzorkovací perioda řízení),

• nepřerušitelnost celé periodické operace, skládající se ze získání regulované veličiny, výpočtu algoritmu regulace a aplikace akční veličiny.

K tomu, aby čtenář pochopil, jak operační systémy Windows NT naplňují či nenaplňují zmíněné požadavky, je nutné se v krátkosti seznámit s jejich architekturou.

Předně je třeba uvést, že systém rozlišuje dva pracovní režimy: uživatelský režim a režim jádra. Bez výjimky všechny spuštěné aplikace (procesy) běží v uživatelském režimu, odkud nelze přímo přistupovat k hardwaru. Procesy jsou tak odkázány na ovladače zařízení, s nimiž komunikují prostřednictvím služeb subsystému Win32 API.

Každý proces (spuštěná aplikace) vlastní nejméně jedno prováděcí vlákno, které vykonává kód procesu. Jednotlivá vlákna všech procesů jsou střídavě zpracovávána procesorem. O tom, které vlákno má běžet, rozhoduje plánovač podle aktuálních potřeb vláken a přidělených priorit. Například vlákno s nejvyšší prioritou může být na stanovenou dobu uspáno nebo může čekat na uvolnění zdroje, čímž se umožní běh vláken s nižší prioritou. Na obdobném principu pracují časové a synchronizační funkce Win32 API (zkráceně časovače). Vlákno se jednoduše po vykonání příslušné operace uspí a čeká, dokud jej časovač znovu neprobudí.

Pro tyto účely systém nabízí několik nástrojů, které lze teoreticky nastavit s přesností až na jednu milisekundu. V praxi však uvedené přesnosti za určitých okolností dosahuje pouze multimediální časovač. Nicméně ani tento časovač nelze pro reálný čas použít. Důvodem je, že samotný plánovač podléhá ještě jinému prioritnímu uspořádání, tzv. úrovním IRQL (Interrupt ReQuest Level). Systém rozlišuje 32 těchto úrovní, kde nejvyšší prioritu má úroveň IRQL 31 a nejnižší IRQL 0. A právě plánovač (tím i veškerá vlákna) běží prioritně na nejnižší úrovni IRQL 0 nebo IRQL 1. Na vyšších úrovních běží všechny obsluhy přerušení a úlohy z fronty DPC (Deferred Procedure Call), které opět zakládají obsluhy přerušení. Zmíněné úlohy převážně nejsou kritické, avšak často bývají časově náročné.

Jinak řečeno, jakákoliv obsluha hardwarového přerušení, včetně jí odložených činností, je vykonána přednostně před libovolným vláknem. Probuzení vlákna se tak v závislosti na intenzitě úloh svázaných s obsluhou periferních zařízení (spouštění aplikací, síťová komunikace, otevírání dokumentů apod.) může odložit až o stovky milisekund. Z toho je také zřejmé, že i když časovač probudí vlákno ve stanovený okamžik, neznamená to, že daná úloha se již bezodkladně vykoná celá, neboť kdykoliv může hardware opět generovat přerušení a tím nekompromisně odložit její vykonání.

Ze zkráceného popisu systému je zřejmé, že požadavky kladené na systémy reálného času systém Windows NT nenaplňuje. Přístup hardwaru není přímý a vyžaduje ovladač. Neexistuje spolehlivý časovač a úloha může být během své činnosti kdykoliv přerušena.

3. Funkční princip řešení doplňku

Zmíněné nedostatky lze obejít přenesením časově kritických operací do nižších vrstev operačního systému, přesněji do obsluhy přerušení hardwarového časovače. Právě na této možnosti je postaveno zde prezentované řešení, které využívá schopnosti většiny multifunkčních měřicích karet dostupných v současné době, a to generovat přerušení obvykle jako důsledek ukončení měření jednoho vzorku či sady vzorků. Reakcí na toto přerušení je zahájení obsluhy přerušení speciálně navrženého ovladače, která již vykoná celý kód algoritmu řízení. Uživatelská aplikace potom plní úlohu pouze jakéhosi zprostředkovatele; uživatel pomocí ní vybírá typ a parametry regulátoru, popř. vizualizuje či jinak zpracovává data s informacemi o průběhu regulace. Nejlépe tento princip vysvětluje následující text a obr. 2:

1. Ovládací aplikace nejprve podle voleb uživatele předá ovladači data o typu regulátoru, včetně všech parametrů, použitých vstupů apod.

2. Následně ovladač zavede příslušnou obsluhu přerušení, nastaví obvody měřicí multifunkční karty a inicializuje časovač tak, aby zajistil žádanou vzorkovací periodu.

3. Od této chvíle naprosto přesně a zcela nezávisle na stavu počítače spouštějí časovače měřicí karty opakovaně A/D převod, načež karta generuje požadavek na přerušení.

4. U tohoto požadavku vyšetří hardware spolu s operačním systémem prioritu, a jestliže ji vyhodnotí jako nejvyšší, ihned zahájí jeho obsluhu.

5. Obsluha přerušení přečte již naměřenou hodnotu vstupu, vykoná příslušný výpočet a ihned nastaví výstup.

6. Jestliže ovládací aplikace dříve požádala o průběžné informování, rutina před svým ukončením navíc zapíše stavy jednotlivých veličin do vyrovnávací paměti.

7. Po naplnění vyrovnávací paměti předá aplikace její obsah přes úlohu fronty DPC nazpět ovládací aplikaci, která již data podle požadavků uživatele zpracuje.

Z pohledu potřeb reálného času přináší toto řešení mnoho výhod. Uvedeme ty nejzajímavější:

• Jelikož časování je generováno nezávislými hardwarovými čítači, je možné nezávisle na systému volit vzorkovací periodu běžně s přesností jedné mikrosekundy. Navíc u většiny karet čítače samy zahájí A/D převod a až poté generují přerušení; tím je vzorkování naprosto přesné a současně nevzniká časová prodleva při čekání na ukončení převodu.

• Protože veškerá činnost ovladačů běží v režimu jádra, je možné přímo a zcela bez omezení přistupovat k hardwaru počítače, tedy k registrům i paměti měřicí karty.

• Obsluha přerušení se vykonává na vysoké úrovni IRQL, takže systémové úlohy předávající data o průběhu řízení včetně činnosti vláken, jež je zpracovávají, nemohou vlastní regulaci nijak ovlivnit.

Jak už to bývá, výhody na jedné straně jsou doprovázeny nevýhodami na straně druhé. Základní komplikace popsaného řešení jsou:

• Realizace je programátorsky velmi náročná. Tvorba ovladačů vyžaduje erudovaného programátora znalého jazyka C, architektury Windows NT a principů funkce I/O systému. Nezbytné kompilátory spolu s kvalitní dokumentací a příklady lze získat zdarma jako soupravu DDK (Device Driver Kit) na webovém serveru firmy Microsoft. Ladění ovladače navíc vyžaduje další počítač s nainstalovanou speciální verzí operačního systému Check Build. (Veškeré podrobnosti jsou uvedeny v dokumentaci DDK.)

• V ovladačích není podpora aritmetiky reálných čísel, která je pro tvorbu řídicích algoritmů téměř nezbytná.

• Vlastní algoritmus je vykonáván ovladačem, tudíž úprava existujícího nebo doplnění nového algoritmu vyžadují zásah do ovladače.

• Ovladač je svázán s konkrétním typem měřicí karty, takže jiný typ karty vyžaduje opět tvorbu nového ovladače.

• Každý typ regulátoru může mít jiné nastavitelné parametry, tedy změna či dotvoření algoritmu vyžaduje také obdobný zásah do komunikačního protokolu a do ovládací aplikace.

• Vzorkování hardwarovými čítači a generování přerušení sice jsou naprosto přesné, avšak nezaručují okamžité zahájení svázané obsluhy. Jak již bylo zmíněno, jednotlivé obsluhy jsou zpracovávány podle úrovní IRQL, takže vlastní vykonání algoritmu může být opožděno po dobu vykonávaní obsluh s vyšší prioritou. Tím současně vzniká nepříjemný problém, kdy je vypočítáván akční zásah na základě relativně staré hodnoty. Je evidentní, že problém je tím významnější, čím nižší prioritu má obsluha a čím více se vyskytují přerušení s vyšší prioritou.

4. Realizace a struktura doplňku

V předchozí kapitole byl uveden funkční princip řešení spolu s problémy, které s sebou přináší. Následující text se již zaměřuje na popis realizovaného doplňku, který funkčně odpovídá popsanému principu. Doplněk není koncovým řešením, ale jen specializovaným „polotovarem„ nabízejícím sadu vzájemně spolupracujících knihoven a modulů, jež umožňují snadno vybudovat koncové řešení. Doplněk řeší mnohé z uvedených problémů. Jiné problémy (např. problém s rozptylem doby odezvy na vznik přerušení) jsou plně vyřešeny na úrovních jednotlivých modulů a knihoven.

4.1 Minimalizace rozptylu doby odezvy na vznik přerušení
Z letmého popisu lze mylně usoudit, že celý problém spočívá pouze ve zvýšení úrovně IRQL. Bohužel tomu tak není. Vše je výrazně složitější a závislé na mnoha faktorech. Přesněji na jádrem realizovaném mechanismu správy přerušení, který není jednotný a je výrazně ovlivněn hardwarem počítače (jmenovitě řadičem přerušení) a verzí operačního systému (ve Windows NT pracuje jinak než ve Windows 2000 a Windows XP).

Na platformě PC se vyskytují dva typy řadičů. Starší, obvykle označovaný zkratkou PIC (Programmable Interrupt Controller), vychází z kaskádovitě zapojených obvodů 8259A, jež se používaly již s procesorem Intel 8080. Přes své stáří byl do příchodu procesorů Pentium 4 výhradně používán na všech jednoprocesorových systémech. Novější je řadič APIC (Advanced Programmable Interrupt Controller), který byl vyvíjen především pro potřebu víceprocesorových systémů.

Z našeho pohledu je zajímavé, že v případě, kdy se v počítači používá starší typ řadiče, je úroveň IRQL příslušné obsluhy jednoznačně dána kanálem přerušení (tab. 1). Vždy je tudíž jasné, na které úrovni bude ten či onen požadavek standardně zpracován.

Je-li však použit nový řadič APIC, tato vazba neexistuje. Každá instalace systému může mít přiřazeny jiné úrovně. Jinak řečeno, stejná verze operačního systému na shodném hardwaru může mít pro shodný kanál přiřazenu jinou úroveň IRQL.

Zatím je úspěšně vyřešen vztah doplňku se standardním řadičem přerušení, který lze mnohdy vynutit i na nejnovějších systémech prostřednictvím systému BIOS. Specifickými postupy bylo dosaženo změny v chování tak, že obsluha definovaného požadavku je téměř vždy přednostně provedena před ostatními. Výjimkou je pouze situace, kdy již dříve byla zahájena obsluha jiného požadavku s původně vyšší prioritou. Ale i poté je v pomyslné frontě čekajících požadavků na prvním místě. Výsledný efekt nejlépe dokládá obr. 3. Zde je možné vidět rozptyl doby odezvy na vznik přerušení pořízený za naprosto stejných podmínek na stejném systému, avšak nejprve s původní správou přerušení a poté s upravenou.

4.2 Architektura doplňku
Celý komplet se skládá ze tří navzájem spolupracujících částí:

• z obecného nízkoúrovňového ovladače,
• z vrstev zjednodušujících komunikaci mezi ovladačem a aplikacemi,
• z uživatelské ovládací aplikace.

Dohromady všechny tyto části tvoří snadno implementovatelný doplněk, jenž umožňuje okamžitou realizaci řízení jednorozměrných obvodů. Pro vícerozměrné obvody je nutné ovladač doplnit patřičným algoritmem. Vlastní ovladač je tvořen obecně, tzn. že vyžaduje přizpůsobení pro konkrétní typ multifunkční karty. Více napoví podrobnější popis jednotlivých částí.

4.2.1 Obecný nízkoúrovňový ovladač
Nejdůležitějším článkem je obecně navržený nízkoúrovňový ovladač, jehož architektura (obr. 4) umožňuje snadno se přizpůsobit libovolnému typu multifunkční měřicí karty, která však splňuje nezbytné požadavky na existenci časovačů a schopnost generovat přerušení. Vlastní ovladač se skládá ze tří vrstev:

• z vrstvy rozhraní,
• z logicko-funkční vrstvy,
• z fyzické vrstvy.

Jádro tvoří logicko-funkční vrstva, která zajišťuje všechny funkce (včetně regulace, zavádění a registrace ovladače apod.) a uchovává veškerá nastavení. Tato vrstva přímo nepřistupuje k prostředkům měřicí karty ani nekomunikuje s aplikacemi Win32 API. Tyto činnosti zajišťují dvě sousední vrstvy, se kterými úzce spolupracuje. K přímému přístupu k hardwaru je využívána fyzická vrstva, která jako jediná je závislá na konkrétní měřicí kartě. Komunikaci s prostředím Win32 API zabezpečuje nejvyšší vrstva rozhraní. Ta je vytvořena tak, aby nebyla závislá na konkrétním typu multifunkční karty (tudíž pokrývá všechny přípustné typy) a také umožnila snadné rozšíření funkční vrstvy o nové typy úloh. Díky této koncepci je velmi snadné přenést řešení na jiný typ multifunkční měřicí karty – v podstatě je nutné pouze modifikovat těla funkcí fyzické vrstvy.

Architektura ovladače také pamatuje na možnost rozšíření o další typy regulátorů. Interně se logicko-funkční vrstva dělí na pevnou část, která zůstává neměnná, a na část, ve které jsou realizovány vlastní algoritmy regulace. Tato část je oddělena nejen logicky, ale také fyzicky, proto lze nové algoritmy velmi snadno realizovat. Standardně jsou v ovladači již realizovány běžné typy regulátorů. Například je zde obecný PID regulátor v polohové i v přírůstkové verzi s možností přidat filtr buď separátně na derivační složku, nebo na regulovanou veličinu.

Pro bezproblémové vytváření nových algoritmů je k dispozici (speciálně pro tento účel vytvořená) knihovna funkcí vykonávající základní matematické operace s reálnými čísly. Tyto algoritmy lze vytvářet odděleně, mimo ovladač v připravené aplikaci pro Windows. Ta simulací činnosti ovladače výrazně zjednodušuje vývoj algoritmu, který se po odladění již pouze přenese do ovladače.

4.2.2 Komunikační vrstvy
I když je ovladač schopen zcela samostatného vykonávání řízení, bez komunikace s aplikacemi Win32 API se neobejde (obr. 5). Ovladači je nutné přinejmenším sdělit typ a parametry regulátoru, používané vstupy a jejich napěťový rozsah a dát povel k zahájení regulace. Navíc aplikace může vyžadovat informace o průběhu regulace, které následně zpracovává, apod. Je zřejmé, že komunikace je velmi důležitá.

Na úrovni ovladače se o komunikaci stará vrstva rozhraní. K této vrstvě má prostřednictvím subsystému Win32 API přístup libovolná aplikace. Nicméně komunikace přímo s vrstvou rozhraní není jednoduchá. Na programátora jsou kladeny velké nároky nejen ohledně znalosti principů tohoto rozhraní, ale také ohledně znalosti obecné komunikace mezi aplikacemi a ovladači. Pro ulehčení jeho práce byla vyhotovena knihovna funkcí snadného přístupu. Ve svém principu knihovna překrývá obecnou funkci subsystému Win32 API vlastními funkcemi, jež jsou speciálně vyvinuty pro výměnu dat s rozhraním ovladače.

Nicméně i tuto knihovnu není snadné používat, především v případě, kdy se aplikace tvoří v jiném programovacím jazyku, než je C či C++. Proto byla navíc vytvořena komponenta COM, která celou komunikaci „balí“ do objektově orientované struktury. Komponenta je opět navržena se zřetelem na další rozšíření ovladače nebo jeho přenos na jinou měřicí kartu. Díky této komponentě je možné vytvářet aplikace v libovolném programovacím jazyku, např. v oblíbeném MS Visual Basic apod.

Prostřednictvím uvedených nástrojů je možné ovladač snadno integrovat do libovolné aplikace, přičemž programátor si může vybrat, jaký způsob komunikace mu nejlépe vyhovuje. Rozhodnout se tak může podle aktuálních možností či potřeb, popř. může zvolit i kombinaci všech těchto metod.

4.2.3 Uživatelská ovládací aplikace
Posledním článkem řešení je uživatelská ovládací aplikace, která zprostředkovává veškeré funkce doplňku v uživatelsky přívětivém prostředí. Zkráceně, aplikace umožňuje zvolit a nastavit všechny podporované typy regulátorů, umožňuje sledovat a vizualizovat průběh regulace a zaznamenaná data exportovat do textových souborů, popř. i do souboru MS Excel. Aplikace opět není vázána na konkrétní typ ovladače, a tudíž spolupracuje s libovolnou měřicí kartou, resp. s libovolným kompatibilním ovladačem.

5. Závěr

Doplněk svou specializací a zároveň přizpůsobivou architekturou je na pomezí vývojového prostředku a koncového řešení. Koncové uživatele bude spíše zajímat doplněk již svázaný s konkrétní multifunkční kartou. Pro výrobce měřicích karet je zase zajímavé obecné řešení ovladače.

V současnosti je ovladač implementován na dvě měřicí multifunkční karty, a to PCA 1408 a PCA 1208. Na těchto kartách byly také ověřeny všechny funkce a schopnosti. Funkčnost algoritmů se ověřovala na řízení modelu elektromagnetické levitace. Pro objektivitu byl ovladač testován na několika výkonově odlišných sestavách s procesory od Pentium 90 MHz až po Pentium 4 s kmitočtem 2 GHz. Systém byl vždy schopen bezpečně zajistit řízení se vzorkovací frekvencí nejméně 10 kHz. Během testů byl systém uměle zatěžován vybranými úlohami (např. kopírováním obsahu CD-ROM na pevný disk, síťovou komunikací apod.). Tyto úlohy však nikdy zásadně neovlivnily vzorkovací periodu, potažmo vlastní regulaci.

Toto řešení „nekatapultuje„ operační systémy architektury Windows NT do kategorie systémů reálného času, ale umožňuje snadno realizovat řízení systémů náročných na rychlost a dobu zpracování. Je tak zajímavou alternativou pro oblast řízení v laboratořích a v průmyslu, kde je spolu s architekturou MS Windows NT vyžadována velká flexibilita a rychlá a snadná implementace.

Ing. David Fojtík, Ph.D.,
VŠB – Technická univerzita Ostrava
(david.fojtik@vsb.cz)

Lektoroval: Ing. Petr Štefka,
dataPartner s. r. o.

Ing. David Fojtík, Ph.D. (1974), je odborný asistent na katedře automatizační techniky a řízení Fakulty strojní VŠB-TU Ostrava. Vede v magisterských a bakalářských studijních programech předměty operační systémy a programování, informační technologie a programovací techniky. Zabývá se také poradenstvím v oblasti softwaru. Současně působí jako lektor pro společnosti AutoCont CZ a EIIT Education, s. r. o.

¹⁾ Tímto souhrnným názvem jsou zde pro jednoduchost označeny operační systémy Microsoft Windows NT, Microsoft Windows 2000 a Microsoft Windows XP.