Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Transkript

1 Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti MI-SOC: 6 OPERAČNÍ SYSTÉMY REÁLNÉHO ČASU doc. Ing. Hana Kubátová, CSc. Katedra číslicového návrhu Fakulta informačních technologii ČVUT v Praze Hana Kubátová MI-SOC 2011/12 1

2 ÚVOD Osnova: Základní charakteristika RTOS Definice RTOS Příklady RTOS Hard real time OS Soft real time OS Plánovač RTOS zdroje: podklady pro předmět Programování systémů reálného času, Operační systémy reálného času heslo RTOS 2

3 ZÁKLADNÍ CHARAKTERISTIKA RTOS se snaží o systém reálného času, ale negarantuje ho. RTOS ani nemusí být systém vysoké výkonnosti. Snahou real-time aplikací je dodržet jisté milníky a to buď více méně u tzv. soft real time OS (měkké RTOS) nebo deterministicky hard real time (tvrdé RTOS). (Dělení na soft a hard je jedno ze základních dělení RTOS.) RTOS typicky používají speciální plánovače (scheduler), aby bylo dosahováno deterministického chování (vzhledem ke spuštěným procesům). 3

4 HLAVNÍ FAKTORY Minimální latence při reakci na událost Minimální latence při přepínání vláken Někdy nutnost malých rozměrů (vestavné systémy) Minimalizace časových okamžiků, kdy je vypnuto přerušení Preemptivní plánování založené na prioritách Správná funkce závisí nejen na výpočetním výsledku, ale také na čase, kdy ho bude dosaženo. Obvykle malé systémy se specializovaným použitím, případně jako nadstavba větších OS (Windows, Linux) 4

5 DEFINICE RTOS (3 VERZE) Real-time systém je systém, ve kterém správnost výstupu je závislá nejen na správnosti výsledku výpočtu, ale též na čase, v němž je výsledek spočten. Real-time systém je systém, který reaguje předvídatelným způsobem na nepředvídatelné externí události. Pokud lze dokázat, že RT systém splní svá meze (deadlines) (a to v nejhorším možném případě, nikoliv analýzou průměrného chování systému), potom můžeme říci, že chování systému je předvídatelné. 5

6 PŘÍKLADY RTOS RTOS může být jak systém speciálně vyvinutý jako RT nebo klasický systém (Windows, Linux) s doinstalovaným vybavením, případně upraveným jádrem. PikeOS ( Operační systém pracující v reálném čase pro bezpečnostně kritické aplikace Snadné oddělení či verifikaci jednotlivých částí elektronického systému. Založený na mikrojádře a používá se převážně v vestavných systémech a serverech. Deterministické chování a konfigurovatelné paravirtualizační schopnosti Využití v letectví a dopravní a automobilové technice (MPC5200), kosmonautice (LEON3), zdravotnictví (X86), automatizaci (ARM) a dalších odvětvích. 6

7 PŘÍKLADY RTOS WINDOWS hlavní důvody proč nemohou být Windows v základním provedení použity jako RTOS: málo priorit vláken nedeterminismus plánovače kvantitativní parametry OS musí být známé malé rozlišení časovače (5ms) nedostatečná rychlost přepínání kontextu Existují však doplňky, které mají rozšířit možnosti Windows na RTOS. Jedním z nich je například RTX (Real- Time extension) od společnosti VenturCom. RTX zkracuje rozlišitelnou jednotku času z 5ms na 20mikrosekund nezávislý plánovač vláken po nainstalování RTX zůstávají zachovány vlastnosti Windows jako běžného operačního systému. 7

8 PŘÍKLADY RTOS RTLINUX Malý a rychlý operační systém podle normy POSIX (architektura pro minimální RTOS, Úplný operační systém s předvídatelnou činností v reálném čase, bez rozhraní pro standardní Linux bez reálného času. Vlákna jsou zpracovány přímo plánovacím algoritmem s pevnou prioritou. Jádro a všechny procesy standardního Linuxu jsou řízeny plánovačem jako úlohy v pozadí. RTLinux vytváří úplný obecný operační systém, který běží nad malým předem definovaným jádrem RTOS. 8

9 PŘÍKLADY RTOS VXWORKS 6.X Nejrozšířenější RTOS pro průmyslové aplikace vestavných systémů: Neomezený počet procesů/úloh Preemptivní plánování 256 úrovní priorit rychlá a flexibilní meziprocesová komunikace dědění priorit, fronty zpráv, signály, roury. sokety podporované CPU: PowerPC, ARM, Intel x86,... není POSIX kompatibilní Mikrojádro s minimální režií systému rychlá a deterministická odezva na externí událost. Použití i v kritických aplikačních úlohách (letěl na Mars). 9

10 HARD REAL TIME OS, SOFT REAL TIME OS Hard RTOS (tvrdý real time OS). požadavek na stanovení času reakce absolutní. preemptivní plánovač velký počet nastavitelných priorit vláken přesné hodiny reálného času Můžeme také říci: systém je hard-real time, pokud by případné nedodržení časových limitů mělo katastrofální následky Soft real time OS. dovoleny drobné odchylky v reakcích. 10

11 PLÁNOVAČ RTOS - SCHEDULER RTOS mnohdy využívají plánovací algoritmy, které se liší od plánovačů běžných OS. Nejčastější z nich jsou: Rate monotonic scheduling (RMS) Statické přidělování priorit Earliest deadline First (EDF) 11

12 RATE MONOTONIC SCHEDULING (RMS) Př. 5 úloh, z nichž každá trvá 100ms. Systém může vykonat jednu po druhé podle pořadí. Práce systému zabere 500ms. Ale co když se jedna zablokuje a 4. úlohu musíme vykonat do 300ms (například akční zásah do systému v případě řízení)? Pokud ji vykonáme jako 4., bude splněna až po 400ms a to je pozdě. Dále předpokládejme, že výše zmíněné úlohy jsou periodické. Jde například o počítač, který řídí jistý proces (např. průmyslová automatizace) a má za úkol: snímat data odesílat je po síti zobrazovat vyhodnocovat akční zásahy vykonat akční zásah na V/V zařízení. periodické úlohy vyžadující konstantní čas CPU, musí skončit během své periody (sebrání dat a vyvození akčního zásahu).. fixed-priority preemptive RTOS (Operační systém reálného času s preempcí a fixní prioritou úloh). 12

13 KDY MŮŽEME ALGORITMUS RMS POUŽÍT Procesy nesdílejí zdroje Deadlines jsou rovny periodám procesů Statické priority s preempcí (úloha s vyšší statickou prioritou, která je připravena, způsobí okamžitě preempci ostatních úloh s nižší prioritou) Statické priority jsou stanovovány podle délky periody (úloha s vyšší periodou má nižší prioritu) Přepínání kontextů a jiné vláknové operace jsou "zdarma" a nemají dopad na model Plánovatelnost skupiny úloh Skupina úloh je plánovatelná, pokud všechny úlohy ze skupiny pokaždé splní svůj deadline (časový okamžik, do kterého musí proběhnout). 13

14 LIU & LEYLANDŮV LIMIT Pro skupinu n periodických procesů, existuje plánování, které vždy splní deadline, pokud je využití CPU U: kde C i je výpočetní čas potřebný pro proces T i je perioda procesu Pokud roste počet procesů k nekonečnu, je limita výrazu: 14

15 VLASTNOSTI A VÝHODY RMS Priorita je úlohám přidělována podle jejich periody: čím kratší perioda úlohy, tím větší priorita. Úlohy jsou periodicky spouštěny za sebou podle přidělené priority. Chceme dodržet deadlines všech úloh a splnit je v rámci jejich periody. RMA je static-priority algoritmus = priorita je pro danou úlohu statická, nemění se. Algoritmus RMA je optimální static-priority plánovač. Pokud skupina úloh nemůže být úspěšně plánována pomocí algoritmu RMA, neexistuje static-priority algoritmus, který by plánování provedl úspěšně. Není vždy možné plně využít kapacity CPU. Někdy není možné pomoci fixních priorit dosáhnout plánovatelnosti úloh a řešení je jen dynamické přidělování priorit. Analyticky domyšlený algoritmus: analyticky určena podmínka dodržení termínů dokončení: viz Liu, Leylandův limit Používáno v mnoha RTOS Vypracovány i způsoby spolupráce sdílených systémových prostředků 15

16 EARLIEST DEADLINE FIRST (EDF) na rozdíl od RMS nevyžaduje periodické úlohy a zpracování úloh probíhá na základě mezní doby platnosti procesu. Základní vlastnosti Každý proces oznamuje při svém příchodu do fronty dobu platnosti (nejčastěji mezní termín splnění - deadline). Scheduler udržuje informace o všech spuštěných úlohách ve frontě seřazené podle deadline. Plánovač spouští úlohu s nejbližším časem deadline a kdykoliv se spustí úloha s bližším časem deadline, scheduler odstaví právě obsluhovanou úlohu a spouští novou - v tomto případě příchozí. 16

17 ROZDÍL MEZI RMS A EDF Při větším zatížení procesoru algoritmus RMS selže (viz Liu a Layland, slide 14). Pro EDF platí: kde: C i je doba trvání události, T i je prioda události. Je vidět, že využití CPU je při použití algoritmu EDF větší. 17

18 ALGORITMY PLÁNOVÁNÍ PROCESŮ Completely Fair Scheduler (CFS) Earliest deadline first (EDF) Priority scheduling Rate monotonic scheduling (RMS) Round-robin scheduling 18

19 COMPLETELY FAIR SCHEDULER CFS česky doslova Zcela férový plánovač) je začleněn do linuxového jádra od verze (2007) Na rozdíl od fronty úloh, spravuje CFS všechny procesy v jediném červeno-černém stromě. Frekvenci přepínání lze nastavit na úrovni ns buď tak aby systém rychle reagoval (typicky u stolních počítačů), nebo aby měl celkově co nejvyšší výkon (typicky u serverů). [3] Asymptotická časová složitost plánovacího algoritmu je O(log N), přičemž samotné naplánování sice probíhá v konstantním čase, ale znovuzařazení procesu do červeno-černého stromu vyžaduje O(log N) operací ?highlightWords=j%C3%A1dro 19

20 PRIORITY SCHEDULING NELZE POUŽÍT PRO RTOS Vlastnosti: přidělování procesoru podle priorit, obsluha procesů s nižší prioritou je zajištěna tak, že procesům s vyšší prioritou, kterým je právě přidělen procesor, se priorita snižuje o 1 podle tiku hodin. Problém: Inverze priorit Proces s nízkou prioritou zablokuje proces s vysokou prioritou (proces s nízkou prioritu vstoupí do kritické sekce, je plánovačem odstaven od CPU a následně je spuštěn proces s vysokou prioritou. Po nějaké době je znovu zpracován proces s nízkou prioritou a kritická sekce je znovuzpřístupněna ostatním procesům, ale. proces s vysokou prioritou bude ukončen později než ten s nízkou. 20

21 ROUND-ROBIN SCHEDULING RR Jeden z nejzákladnějších, nejstarších a velmi často implementovaných plánovacích algoritmů Přiřazuje běžícímu procesu kvantum času, po který může být proces zpracováván na procesoru. Po uběhnutí tohoto času je proces odstaven a na místo něj je spuštěn jiný. Algoritmus předpokládá konstantní prioritu všech procesů, které plánuje. Kvantum času příliš časté přepínání vede k velké režii operačního systému (např. přepnutí po 1ms je značně neefektivní). Ve Windows je kvantum 20ms, ve Windows CE asi 25ms. 21

22 BUDOUCNOST VÝVOJE RT APLIKACÍ Při komponentovém vývoji aplikací je obtížné zaručit, aby byly dodrženy časové požadavky všech komponent po integraci do aplikace. Řešení: Programování pomocí kontraktů (projekt FRESCOR) Každá komponenta specifikuje své požadavky na časování ve formě kontraktu, který se pokusí vyjednat s realtime middlewarem. Při vyjednávání kontraktu provede middleware testy rozvrhnutelnosti a přijme kontrakt pouze pokud lze dodržet všechny časové požadavky. Za běhu aplikace middleware kontroluje zda nejsou překročeny vyjednané parametry (např. čas běhu vlákna), čímž jsou chráněny ostatní části aplikace. Podpora pro distribuované systémy. 22

23 PŘEDPOKLADY PRO POUŽITÍ R-T TEORIE Nejhorší doba běhu se dá změřit a je známa Všechny časové požadavky jsou pevné (harddeadline) Průmysl je obeznámen s real-time teorií Operační systémy poskytují odpovídající prostředky (nulová doba přepnutí kontextu, atd.) 23

24 PROBLÉMY V PRAXI Žádné odhady doby běhu Rozdílné časové požadavky (hard-rt část je malá) Chce se maximálně využít dostupných zdrojů (CPU) Žádná detekce natož pak ochrana proti časovým chybám (složité na implementaci) Žádná časová analýza výsledných aplikací Časování je ověřeno testováním. Není jisté, byl-li otestován nejhorší případ. Metodologie napiš, pusť a doufej, že to chodí dobře. Hard RT analýza je příliš pesimistická. Real-time teorie je často označována jako řešení nesprávného problému! 24

25 VIZE Real-time teorie je správné řešení problému, ale potřebuje náležitou abstrakci, aby byla jednodušeji použitelná. musí být integrována do vývojového procesu. Vývojář: Řekne co by od systému potřeboval (platformě nezávislé) Podpora pro komponentový vývoj (Skládání komponent vyvinutých nezávislými vývojáři) Middleware: Používá nejmodernější real-time teorii Vestavěná analýza Dopředu bude jasné, mohou-li být garantovány minimální požadavky aplikací Bezpečná reakce na přetížení systému Distribuuje volnou (zbývající) kapacitu zdrojů zpět mezi aplikace (quality-od-service management) Časová izolace jednotlivých aplikací/komponent/... (pro procesory, sítě, disk, baterie atd.) 25

26 Hana Kubátová MI-SOC 2011/12 ŘEŠENÍ: KONTRAKTY NA ALOKACI ZDROJŮ ( SERVICE CONTRACTS ) 26

27 KONTRAKTY Rozvrhování na základě kontraktu Kontakt obsahuje: Minimální požadavky na daný zdroj (Perioda, deadline, doba běhu) Zda-li umí aplikace využít volnou kapacitu navíc Online přijímací test Na základě přijatého kontraktu je vytvořen virtuální zdroj (VRES) reprezentující část skutečného zdroje Middleware rozdělí volnou kapacitu mezi VRESy Možnost změny kontraktu za běhu 27

28 VIRTUÁLNÍ ZDROJ Abstraktní pojem Představuje část skutečného zdroje konkrétní podoba je dána typem zdroje a implementací Nedovolí překročení vyjednaných parametrů Poskytuje časovou izolaci vůči ostatním VRESům Implementace CPU: Sporadický server, partitioning (Pike-OS) Síť: limiter síťového provozu,... 28

29 Hana Kubátová MI-SOC 2011/12 ARCHITEKTURA FRSH MIDDLEWARE Contract path 29

30 VLASTNOSTI Implementováno na Linuxu, MarteOS, OSE, PaRTikle Podpora zdrojů na Linuxu CPU: AQuoSA, Cgroup Disk: BFQ I/O scheduler Síť: částečná podpora IEEE e (WiFi QoS) 30