Operační systém reálného času ( RTOS , anglicky real-time operační systém, RTOS ) je druh specializovaného operačního systému , jehož hlavním účelem je poskytnout potřebnou a dostatečnou sadu funkcí pro návrh, vývoj a provoz reálných operačních systémů. časové systémy na konkrétním hardwarovém vybavení.
Specifikace UNIX, revize 2, definuje:
Reálný čas v operačních systémech je schopnost operačního systému poskytovat požadovanou úroveň služeb v určitém časovém období. [jeden]
Původní text (anglicky)[ zobrazitskrýt] Reálný čas v operačních systémech: schopnost operačního systému poskytovat požadovanou úroveň služeb v omezené době odezvy. [2]Ideální RTOS má předvídatelné chování při všech scénářích zatížení, včetně souběžných přerušení a spouštění vláken [3] .
Operační systémy reálného času se někdy dělí na dva typy – tvrdé systémy reálného času a měkké systémy reálného času [4] .
Operační systém, který může poskytnout požadovanou dobu provádění úlohy v reálném čase i v těch nejhorších případech, se nazývá tvrdý operační systém v reálném čase . Systém, který může v průměru poskytnout požadovanou dobu provádění úlohy v reálném čase, se nazývá měkký operační systém v reálném čase .
Tvrdé systémy v reálném čase neumožňují zpoždění v reakci systému, protože to může vést ke ztrátě relevance výsledků, velkým finančním ztrátám nebo dokonce nehodám a katastrofám. Situace, kdy ke zpracování události dojde po uplynutí povolené doby, se v systému tvrdého reálného času považuje za fatální chybu. Když taková situace nastane, operační systém přeruší operaci a zablokuje ji, aby pokud možno nebyla ovlivněna spolehlivost a dostupnost zbytku systému. Příkladem tvrdých systémů v reálném čase mohou být palubní řídicí systémy (v letadle, kosmické lodi, lodi atd.), systémy nouzové ochrany, záznamníky nouzových událostí [5] .
V měkkém systému v reálném čase je zpoždění odezvy považováno za odstranitelnou chybu, která může zvýšit náklady na výsledky a snížit výkon, ale není fatální. Příkladem je provoz počítačové sítě [6] . Pokud systém nestihl zpracovat další přijatý paket, povede to k zastavení na vysílací straně a opětovnému odeslání (v závislosti na protokolu ). Nedochází ke ztrátě dat, ale ke snížení výkonu sítě.
Hlavní rozdíl mezi tvrdými a měkkými systémy reálného času lze popsat takto: tvrdý systém reálného času se nikdy neopozdí s reakcí na událost, měkký systém reálného času by se neměl opozdit s reakcí na událost [6] .
Operační systém v reálném čase je často považován pouze za systém, který lze použít k řešení těžkých problémů v reálném čase. Tato definice znamená, že RTOS má potřebné nástroje, ale také znamená, že tyto nástroje musí být používány správně [5] .
Většina softwaru je orientována na soft real time. Takové systémy se vyznačují:
Klasickým příkladem úlohy, kde je vyžadován RTOS, je řízení robota odebírajícího součást z dopravního pásu . Součást se pohybuje a robot má jen malé okno, kdy ji může zvednout. Pokud se opozdí, díl už nebude ve správné sekci dopravníku, a proto se práce neprovede, přestože je robot na správném místě. Pokud se připraví dříve, součástka se ještě nestihne rozjet a zablokuje jí cestu.
Také pro operační systémy se někdy používá koncept „ interaktivního reálného času “, který definuje minimální práh pro reakci na události grafického rozhraní, během kterého je operátor - člověk - schopen v klidu, bez nervozity čekat systém reagovat na pokyny, které jim byly dány.
Tabulka porovnání RTOS a konvenčních operačních systémů [5] :
| OS v reálném čase | OS pro všeobecné použití | |
|---|---|---|
| Hlavním úkolem | Zvládněte reagovat na události, ke kterým dochází na zařízení | Optimální rozdělení počítačových zdrojů mezi uživatele a úkoly |
| Na co je zaměřena | Zpracování externích událostí | Zpracování uživatelských akcí |
| Jak je umístěn | Nástroj pro vytváření specifického hardwarově-softwarového komplexu v reálném čase | Uživatel vnímá jako sadu aplikací připravenou k použití |
| Kdo je určen | Kvalifikovaný vývojář | Středně pokročilý uživatel |
Při jejich vývoji byly RTOS postaveny na základě následujících architektur :
| Monolitická architektura | Vrstvená (vrstvená) architektura | Architektura klient-server |
Jádro RTOS zajišťuje fungování střední abstraktní úrovně OS, která před aplikačním softwarem skrývá specifika technického zařízení procesoru (více procesorů) a souvisejícího hardwaru [7] .
Tato abstraktní vrstva poskytuje pět hlavních kategorií služeb pro aplikační software [7] [8] :
Kromě základních služeb nabízí mnoho RTOS řady přídavných komponent pro organizaci takových konceptů na vysoké úrovni, jako je souborový systém , síť, správa sítě, správa databází , grafické uživatelské rozhraní atd. Ačkoli mnohé z těchto komponent jsou mnohem větší a více komplexnější než samotné jádro RTOS, jsou nicméně založeny na jeho službách. Každá z těchto komponent je do vestavěného systému zahrnuta pouze v případě, že jsou její služby potřebné pro běh vestavěné aplikace, a to pouze za účelem udržení spotřeby paměti na minimu [7] .
Mnoho operačních systémů pro všeobecné použití také podporuje výše uvedené služby. Klíčovým rozdílem mezi základními službami RTOS je však deterministický charakter jejich práce založený na přísné časové kontrole. V tomto případě je determinismus chápán jako skutečnost, že provedení jedné služby operačního systému vyžaduje časový interval známého trvání. Teoreticky lze tento čas vypočítat pomocí matematických vzorců , které by měly být přísně algebraické a neměly by obsahovat žádné časové parametry náhodného charakteru. Jakákoli náhodná veličina , která určuje dobu provedení úlohy v RTOS, může způsobit nežádoucí zpoždění v aplikaci, další úloha se pak nevejde do jejího časového kvanta, což způsobí chybu [7] .
V tomto smyslu nejsou operační systémy pro obecné účely deterministické. Jejich služby mohou umožňovat náhodná zpoždění v jejich práci, což může vést ke zpomalení reakce aplikace na akce uživatele ve známém neznámém okamžiku. Při návrhu konvenčních operačních systémů se vývojáři nezaměřují na matematický aparát pro výpočet doby provedení pro konkrétní úlohu a službu. To není pro tento druh systémů kritické [7] .
Většina RTOS provádí plánování úloh podle následujícího schématu [7] . Každé úloze v aplikaci je přiřazena určitá priorita. Čím vyšší priorita, tím vyšší by měla být reaktivita úkolu. Vysoké reaktivity je dosaženo implementací preemptivního prioritního plánování, jehož podstatou je, že plánovači je dovoleno zastavit provádění libovolné úlohy v libovolném okamžiku, pokud je určeno, že by měla být okamžitě spuštěna jiná úloha.
Popsané schéma funguje podle následujícího pravidla: pokud jsou dvě úlohy připraveny ke spuštění současně, ale první má vysokou prioritu a druhá nízkou, pak plánovač upřednostní první . Druhá úloha bude spuštěna až poté, co první dokončí svou práci.
Je možné, že úloha s nízkou prioritou již běží a plánovač obdrží zprávu, že je připravena ke spuštění jiná úloha s vyšší prioritou. To může být způsobeno nějakým vnějším vlivem (hardwarové přerušení), jako je změna stavu spínače na zařízení řízeném RTOS. V takové situaci se bude plánovač úloh chovat podle preemptivního plánování priorit následovně. Úkolu s nízkou prioritou bude umožněno dokončit aktuální strojovou instrukci (nikoli však instrukci popsanou ve zdrojovém kódu programu ve vysokoúrovňovém jazyce ), poté je provádění úlohy pozastaveno [7] . Dále se spustí úloha s vysokou prioritou. Po jejím skončení plánovač spustí přerušenou první úlohu, přičemž strojová instrukce následuje po poslední provedené.
Pokaždé, když plánovač úloh obdrží signál o výskytu nějaké vnější události (spouštěče), jejíž příčinou může být jak hardware, tak software, postupuje podle následujícího algoritmu [7] :
Těchto pět kroků algoritmu se také nazývá přepínání úloh.
V konvenčním RTOS může být úloha ve třech možných stavech:
Většinu času je většina úkolů zablokována. V daném okamžiku může na CPU běžet pouze jedna úloha. V primitivním RTOS je seznam úloh připravených k provedení obvykle velmi krátký, může se skládat maximálně ze dvou nebo tří položek.
Hlavní funkcí správce RTOS je sestavení takového plánovače úloh.
Pokud v seznamu posledních úloh připravených k provedení nejsou více než dvě nebo tři úlohy, pak se předpokládá, že všechny úlohy jsou umístěny v optimálním pořadí. Pokud nastanou situace, kdy počet úkolů v seznamu překročí povolený limit, budou úkoly seřazeny podle priority.
V současné době se k řešení problému efektivního plánování v RTOS nejintenzivněji rozvíjejí dva přístupy [9] :
Pro velké zatížení systému je EDF efektivnější než RMS.
Multitaskingové systémy potřebují distribuovat přístup ke zdrojům. Současný přístup dvou nebo více procesů do jakékoli oblasti paměti nebo jiných zdrojů představuje určitou hrozbu. Existují tři způsoby, jak tento problém vyřešit: dočasné blokování přerušení , binární semafory , odesílání signálů. RTOS obvykle nepoužívá první způsob, protože uživatelská aplikace nemůže ovládat procesor tak, jak by chtěla. Mnoho vestavěných systémů a RTOS však umožňuje aplikacím běžet v režimu jádra pro přístup k systémovým voláním a řízení spouštěcího prostředí bez zásahu OS.
Na jednoprocesorových systémech je nejlepším řešením aplikace běžící v režimu jádra, která má povoleno blokovat přerušení. Zatímco je přerušení zakázáno, aplikace využívá prostředky procesu samostatně a nelze spustit žádnou jinou úlohu ani přerušení. Všechny kritické zdroje jsou tak chráněny. Poté, co aplikace dokončí kritické činnosti, musí povolit přerušení, pokud existují. Blokování přerušení je povoleno pouze tehdy, když je nejdelší doba provádění kritické sekce kratší než povolená doba odezvy přerušení. Obvykle se tato metoda ochrany používá pouze tehdy, když délka kritického kódu nepřesahuje několik řádků a neobsahuje smyčky . Tato metoda je ideální pro ochranu registrů .
Když je délka kritického úseku větší než maximální délka nebo obsahuje cykly, musí programátor použít mechanismy, které jsou identické nebo napodobují chování systémů pro všeobecné použití, jako jsou semafory a signalizace.
Následujícím problémům s alokací paměti je v RTOS věnována větší pozornost než v operačních systémech pro všeobecné použití.
Za prvé, rychlost alokace paměti. Standardní schéma přidělování paměti zahrnuje skenování seznamu neurčité délky za účelem nalezení volné paměťové oblasti dané velikosti, a to je nepřijatelné, protože v RTOS musí k alokaci paměti dojít v pevně stanoveném čase.
Za druhé, paměť se může fragmentovat, pokud jsou její volné oblasti rozděleny již běžícími procesy. To může způsobit zastavení programu kvůli neschopnosti použít nové umístění v paměti. Algoritmus alokace paměti, který postupně zvyšuje fragmentaci paměti, může dobře fungovat na desktopových systémech, pokud se restartují alespoň jednou za měsíc, ale je nepřijatelný pro vestavěné systémy, které běží roky bez restartu.
Jednoduchý algoritmus s pevnou délkou paměťových bloků funguje velmi dobře v jednoduchých vestavěných systémech.
Tento algoritmus také funguje dobře na stolních systémech, zvláště když během zpracování paměťového bloku jedním jádrem je další paměťový blok zpracováván jiným jádrem. Tuto schopnost poskytují RTOS optimalizované pro stolní počítače, jako je Unison Operating System nebo DSPnano RTOS .
| Operační systémy v reálném čase | |
|---|---|
| |
| OTEVŘENO | |
| Proprietární |
|
| historický |
|
| |
| Aspekty operačních systémů | |||||
|---|---|---|---|---|---|
| |||||
| Typy |
| ||||
| Jádro |
| ||||
| Řízení procesů |
| ||||
| Správa a adresování paměti |
| ||||
| Nástroje pro načítání a inicializaci | |||||
| Shell | |||||
| jiný | |||||
| Kategorie Wikimedia Commons Wikibooks Wikibooks | |||||