Aktuální vydání

celé číslo

06

2020

Automatizace v potravinářství a farmacii

celé číslo

Návrh časově kritických systémů IV: realizace prostředky RTOS

V článku je na jednoduchém příkladu ukázán vztah mezi formální specifikací časo­vě kritického systému (RTS, systém RT), množinou úloh RT a realizací systému RT s použitím služeb operačního systému reálného času (RTOS). Aby ilustrace byla jednoduchá, stručná a výstižná, vychází se z formální specifikace systému RT vyjá­dřené prostředky časovaných automatů (TA) a jeho realizace s použitím prostřed­ků RTOS μC/OS-II.
 
Ve čtvrtém, posledním ze série článků na téma návrhu časově kritických systémů (systémy reálného času, Real-Time Systems, systémy RT) je ukázán vztah mezi formální specifikací systému RT, množinou úloh RT (blíže viz [5], [6], [7]) a realizací systému RT s použitím prostředků RTOS (Real-Time Operating System). Vztah je ilustrován na jednoduchém demonstračním systému RT tvořeném tlačítkem určeným ke generová­ní podnětů, řídicí částí sloužící k vyhodno­cování podnětů a generování reakcí a svíti­dlem, intenzita jehož svitu bude ovlá­dána tlačítkem.
 

Specifikace demonstračního systému

Chování uvažovaného systému lze popsat v přirozeném jazyce následov­ně (specifikace systému pochází z [1]):
  • svítidlo se může nacházet v jednom ze tří stavů:
  • off (zhasnuto),
  • low (svítí slabě),
  • bright (svítí silně);
  • počátečním stavem svítidla je stav off;
  • je-li stisk tlačítka detekován v době, kdy se svítidlo nachází ve stavu off, svítidlo začne svítit slabě, tj. přejde do stavu low;
  • bude-li nejpozději za 500 ms od přecho­du do stavu low stisknuto tlačítko, svíti­dlo začne svítit silně, tj. přejde do stavu bright;
  • je-li stisk tlačítka detekován v době, kdy se svítidlo nachází v jednom ze stavů low, bright, svítidlo zhasne, tj. přejde do výcho­zího stavu off.
Toto chování lze popsat použitím např. prostředků TA (Timed Automaton), jak je ukázáno na obr. 1, přičemž chování (stis­ky) tlačítka je modelováno automatem podle obr. 1b, zatímco chování části pro řízení in­tenzity svitu svítidla automatem vyobraze­ným na obr. 1a.
 
Automat podle obr. 1b má jediný stav, který je současně stavem počátečním. Jediná hrana tohoto automatu je vždy proveditelná, tzn. že automat je schopen v libovolném čase vyslat po kanálu PRESS signál informující o stisku tlačítka. Toto chování je reálné, pro­tože i reálný uživatel může tlačítko stisknout v libovolném čase.
 
Automat z obr. 1a má tři stavy s názvy odpovídajícími slovní specifikaci systému. V každém ze stavů se čeká na stisk tlačít­ka – v případě daného modelu na příjem sig­nálu na kanálu PRESS. Přechod z počáteční­ho stavu (off) do stavu low je tedy možný až poté, co je detekován stisk tlačítka. Současně s provedením tohoto přechodu jsou nulovány hodiny (x = 0), aby bylo možné následně vy­hodnocovat dobu strávenou ve stavu low. Je-li v tomto stavu stisknuto tlačítko a přitom neuplynulo více než 500 ms, automat přejde do stavu bright. Stisk tlačítka za více než 500 ms od vstupu do stavu low vede k přechodu au­tomatu do stavu off. Ve stavu bright automat čeká na stisk tlačítka; po stisku tlačítka pře­chází do stavu off.
 

Množina úloh RT

 
Nyní následuje krátká úvaha související s modelováním chování systému na úrovni množin úloh RT: Jelikož úkolem systému je zpracovat pouze jediný podnět, množi­na úloh RT bude jednoprvková (tj. |G| = 1) a bude obsahovat pouze úlohu τpress zajiš­ťující reakci na stisk tlačítka. Jelikož tla­čítko může být obecně stisknuto v libovol­ném čase, tato úloha jistě nebude periodic­ká, ale aperiodická či sporadická (s ohledem na konstrukci tlačítka lze totiž stanovit nejkratší možnou dobu mezi dvěma stisky tlačítka prs­tem lidské ruky, a tedy i nejkratší dobu mezi příchody podnětů ve­doucích k vyvolání úlohy τpress). Pro plánování této (jednoprvko­vé) množiny úloh tedy nelze použít mecha­nismus přiřazující priority podle hodnot pa­rametru (např. mechanismus RM), ale je nutné použít jiné mechanismy, např. DM či EDF [7]. Avšak vzhledem k tomu, že množi­na je tvořena pouze jedinou úlohou, nejjed­nodušším řešením je přiřadit jí nejvýznam­nější prioritu a použít preemptivní či nepre­emptivní plánovač.
 
Bez ohledu na to, zda po realizaci systé­mu bude modelu úlohy τpress odpovídat jed­na či několik úloh běžících nad konkrétním RTOS, je důležité si uvědomit, že model úlo­hy τpress musí zahrnovat zejména režie spoje­né s detekcí stavu tlačítka (tj. nejdelší mož­nou prodlevu mezi stiskem tlačítka a zazna­menáním informace o stisku systémem), se šířením informace o stisku (tj. nejdelší mož­nou prodlevu mezi vysláním signálu infor­mujícího o stisku a příjmem tohoto signálu) a s vyhodnocením podnětu a generováním příslušné odezvy (v daném případě změny intenzity svitu svítidla v závislosti na aktuál­ním stavu systému).
 
Poznamenejme, že v případě uvažované­ho triviálního systému by pravděpodobně bylo možné obejít se i bez RTOS a vysta­čit s pouhým využitím přerušovacího pod­systému cílové platformy a realizací řídicí části systému v podobě konečného stavového automatu. Z demonstračních důvodů je však následující část článku zaměřena na způsob realizace již popsaného systému RT právě prostřednictvím RTOS. Pro reali­zaci daného systému byl zvolen μC/OS-II a jeho mechanismus zasílání zpráv. Systém μC/OS-II byl zvolen zejména pro jednodu­chost a přehlednost jeho jádra, služeb a pro dostupnost podrobné dokumentace [2] [4]. V současné době je μC/OS-II k dispozi­ci pro většinu existujících platforem a díky jeho dostupnosti ve formě zdrojových kódů může být snadno přenesen na libovolnou další platformu.
 

Realizace prostředky RTOS μC/OS-II

 
Základní definice a deklarace potřebné k realizaci jsou uvedeny na obr. 2 a deklara­ce proměnných pro příjem zprávy v systému μC/OS-II na obr. 3 (na řádku 00 je deklarována proměnná msg_press typu ukazatel na schránku zpráv, na řádku 01 vyrovnávací pa­měť buf_msg_press, určená k uložení obsa­hu zprávy). Z rozhraní μC/OS-II byly využi­ty zejména tyto služby:
  • OSMboxCreate, sloužící k vytvoření schránky zpráv; ukazatel na ni je uložen do proměnné msg_press (obr. 4, řádek 06);
  • OSMboxPost pro uložení zprávy infor­mující o stisku tlačítka do schránky zpráv určené ukazatelem msg_press (obr. 5, řádek 17);
  • OSMboxPend pro čekání na příchod zprá­vy informující o stisku tlačítka do schrán­ky zpráv určené ukazatelem msg_press (obr. 6, řádky 10, 15, 20, 25);
  • OSTaskCreate, určená k vytvoření úloh:
  • StartupTask, jejímž úkolem je zavést do systému úlohu LampTask (obr. 5, řádky 05–08) a poté v dotazovací smyčce testovat příznak stisku tlačítka (obr. 5, řád­ky 10–22),
  • LampTask, obsahující realizaci automa­tu z obr. 1a.
V dalším textu je blíže popsáno chování úloh StartupTask LampTask.
 

Úloha StartupTask

 
Po zavedení úlohy LampTask do systému (obr. 5, řádky 05 až 08) běží úloha Startup­Task v nekonečné smyčce, v níž na začát­ku každé iterace testuje (obr. 5, řádek 12), zda došlo ke stisku tlačítka (pozn.: tlačít­ko je připojeno na bit 4 portu A mikrořadiče a jeho stisk je indi­kován načtením hodnoty log 0 na vývodu příslušejícím tomu­to bitu). Jakmile je na čtvrtém bitu portu A detekována log 0, tělo úlohy pokračuje na řádku 14, tj. úloha sebe sama uspí na dobu 10 ms, což postačuje k tomu, aby odezněly zákmity související se stis­kem tlačítka. Je-li po uplynutí této doby tlačítko stále stisknu­to (obr. 5, řádek 15), stisk tlačítka je vy­hodnocen jako plat­ný a úloha uloží zprá­vu do schránky zpráv (obr. 5, řádek 17), na dobu jedné jednotky logického času pře­dá k dispozici proce­sor úloze LampTask k obsloužení stisku (obr. 5, řádek 18) a poté čeká na uvolně­ní tlačítka (obr. 5, řá­dek 19). Uvedené ře­šení bylo zvoleno ze­jména s ohledem na jeho ilustrativnost, neboť z hlediska pra­xe by mohlo být vý­hodnější řešit de­tekci stisku tlačítka s následným ulože­ním zprávy do schránky zpráv přes přerušovací podsystém cí­lové platformy, čímž by odpadla nutnost aktivního testování pří­znaku stisku tlačítka v nekoneč­né smyčce, a tím i plýtvání výpo­četním časem.
 

Úloha LampTask

 
Úloha LampTask běží také v nekonečné smyčce (obr. 6, řádky 06 až 29). Začátek těla smyčky představuje stav off systému, tj. svíti­dlo je zhasnuto (obr. 6, řádek 09), a poté úlo­ha čeká na příchod zprávy (obr. 6, řádek 10). Během čekání je úloha blokována, tj. je vyřa­zena z množiny připravených úloh. Zpět mezi připravené úlohy je zařazena po příchodu oče­kávané zprávy do schránky zpráv. Po přijetí zprávy (obr. 6, řádky 11 a další) přechází úlo­ha do stavu odpovídajícího stavu low systé­mu, tj. svítidlo začne svítit slabě (obr. 6, řá­dek 14). Poté úloha čeká po dobu 500 ms na příchod zprávy (obr. 6, řádek 15). Nepřijde-li zpráva do uplynutí této doby, úloha pokračuje vykonáváním úseku kódu určeného k obsluze vypršení časového limitu pro příchod zprávy (obr. 6, řádky 24 až 26), tj. čekáním na stisk tlačítka pro přechod do stavu off automatu (obr. 6, řádek 25). Přijde-li zpráva před uply­nutím této doby (tj. tlačítko je stisknuto do 500 ms), úloha pokračuje prováděním kódu odpovídajícího chování automatu ve stavu bright, tj. zajistí silný svit svítidla a čeká na přijetí zprávy pro přechod do stavu off (obr. 6, řádky 18 až 21).
 
Konkrétní realizace funkcí lamp_off(), lamp_low(), a lamp_bright() zde není uvede­na; je ponechána k zamyšlení čtenáři/čtenář­ce tohoto článku. Obecně se však očekává, že funkce volané v rámci těl úloh RT budou realizovány tak, že doby jejich běhů budou pokud možno konstantní a co nejkratší. Jinými slovy, očekává se, že úloha nebude konzumovat čas procesoru déle než po dobu nezbytně nutnou k vykonání požadované funkce. Jelikož obvyk­lou cílovou platformou pro realizaci systémů RT jsou mikrořadiče, je pro realizaci funkcí lamp_off(), lamp_low(), a  lamp_bright() vý­hodné využít periferie, které jsou v mikrořadi­čích běžně dostupné – např. časovače. Ty jsou schopny, paralelně s činností procesoru, řídit intenzitu svitu svítidla např. s použitím pulzní šířkové modulace. Důležité je, že řízením in­tenzity svitu svítidla se pak procesor, kromě potřebného nastavení časovače formou přiřa­zovacího příkazu zajišťujícího změnu střídy signálu, nemusí aktivně zabývat.
 

Závěrem

 
V článku byl na jednoduchém příkladu na­stíněn vztah mezi třemi významnými etapami vývojového cyklu systému RT – etapou speci­fikace a verifikace, etapou modelování a simu­lace a etapou realizace systému RT. Cílem bylo jednak upozornit na typická úskalí, kterými je třeba se při přechodech mezi jednotlivými eta­pami zabývat, a jednak shrnout a o další souvislosti doplnit informace odděleně představe­né v předchozích článcích seriálu na téma navr­hování časově kritických systémů. Následující odstavce celý seriál stručně shrnují.
 
První článek seriálu je věnován úvodu do problematiky návrhu časově kritických sys­témů, klasifikaci mezí odezev úloh a systémů RT a také základním pojmům a principům souvisejícím se specifikací a verifikací systé­mů RT. Při tvorbě článku byla upřednostněna ilustrativnost před teoreticky vyčerpávajícím obsahem, což platí o všech článcích seriálu.
 
Ve druhém článku jsou představeny zá­kladní pojmy související s modelem úloh RT a plánováním množin úloh RT. Je zdůrazněna klíčová role mechanismu přiřazová­ní priorit, realizovaného v rámci plánovače, na chod systému RT.
 
Třetí článek je věnován základním me­chanismům přiřazování priorit úlohám RT. Jsou představeny dva mechanismy statického (RM, DM) a dva mechanismy dyna­mického (EDF, LLF) přiřazování priorit, shrnuty jejich hlavní vlastnosti a naznače­ny hlavní přednosti a nedostatky spojené s jejich použitím. Je ilustrováno, že mecha­nismy garantující plánovatelnost větší mno­žiny úloh RT vedou k výpočetně náročnější konstrukci plánovačů. Jelikož volba vhod­ného mechanismu přiřazování priorit patří k nejdůležitějším úkolům návrháře systé­mu RT, je nutné ji pečlivě zvážit. Z tohoto pohledu je nezbytné, aby návrháři časově kritických systémů měli dostatečný přehled v oblasti mechanismů přiřazování priorit – není možné spokojit se pouze se znalostí mechanismů představených v tomto seriá­lu, ale je nutné studovat další mechanismy použitelné např. pro plánování závislých úloh, pro plánování při přetížení systému, pro plánování v síťovém či víceprocesoro­vém prostředí apod.
 
Závěrečný článek seriálu byl shrnující, s cílem zdůraznit vztah mezi tématy před­stavenými v předchozích statích a nazna­čit základní problémy spojené s realizací systému RT. V seriálu bylo záměrně odka­zováno pouze na produkty volně dostupné široké veřejnosti k nekomerčnímu využi­tí (Uppaal, TimesTool, Cheddar, μC/OS-II) s tím záměrem, aby po přečtení jednotlivých článků seriálu měl každý možnost si vhod­né produkty zdarma nainstalovat a vyzkou­šet si s jejich použitím jednotlivé etapy ná­vrhu systémů RT.
 
Poděkování
Článek vznikl za podpory výzkumného záměru MSM0021630528 Výzkum informač­ních technologií z hlediska bezpečnosti (agen­tura CEZ MŠMT) a projektu specifického vý­zkumu FIT-S-10-1 (VUT v Brně).
 
Literatura:
[1] BEHRMANN, G. – DAVID, A. – LARSEN, K. G.: A Tutorial on Uppaal. In: Formal Me­thods for the Design of Real-Time Systems, 4th International School on Formal Methods for the Design of Computer, Communication, and Software Systems. Springer-Verlag, 2004, pp. 200–236, LNCS 3185.
[2] LABROSSE, J. J.: MicroC/OS-II – The Real-Time Kernel. CMP Books, 2002, 648 s., ISBN 978-1-57820-103-7.
[3] SROVNAL, V.: Operační systémy pro řízení v reálném čase. VŠB TU, Ostrava, 2003, 218 s., ISBN 80-248-0503-0.
[4] Micrium [online]. 2010 [cit. 2010-03-26]. Doku­ment dostupný z <www.micrium.com>.
[5] STRNADEL, J.: Návrh časově kritických sys­témů I: specifikace a verifikace. Automa, 2010, roč. 16, č. 10, s. 42–44, ISSN 1210-9592.
[6] STRNADEL, J.: Návrh časově kritických sys­témů II: úlohy reálného času. Automa, 2010, roč. 16, č. 12, s. 18–19, ISSN 1210-9592.
[7] STRNADEL, J.: Návrh časově kritických sys­témů III: priorita úloh. Automa, 2011, roč. 17, č. 2, s. 50–52, ISSN 1210-9592.
 
Ing. Josef Strnadel, Ph.D.,
Fakulta informačních technologií,
Vysoké učení technické v Brně
 
Ing. Josef Strnadel, Ph.D., je odborným asistentem na Fakultě informačních technologií Vysokého učení technického v Brně. Své vědeckovýzkumné i pedagogické aktivity dlouhodobě směruje do oblastí vestavných systémů, systémů pracujících v reálném čase a testování číslicových systémů.
 
Obr. 1. Specifikace vyjádřená prostředky TA (Ti­med Automaton): a) automat řídící intenzitu svitu, b) automat modelující chování (stisky tlačítka)
Obr. 2. Základní definice a deklarace
Obr. 3. Deklarace proměnných pro využití schránky zpráv indikujících stisk tlačítka
Obr. 4. Tělo funkce main
Obr. 5. Tělo úlohy StartupTask
Obr. 6. Tělo úlohy LampTask