Projekt operačních systémů v reálném čase. Operační systémy v reálném čase (RTOS). Systém regulace požadavků

Charakteristické rysy RTOS z OS obecný účel

Jsou zaměřeny na operační systémy pro všeobecné použití, zejména na víceuživatelské, jako je UNIX optimální distribuce počítačových zdrojů mezi uživateli a úkoly. V operačních systémech pracujících v reálném čase taková úloha ustupuje do pozadí - vše ustupuje dříve hlavní úkol- mít čas reagovat na události vyskytující se v zařízení Dalším rozdílem je, že použití operačního systému v reálném čase je vždy spojeno se zařízením, s objektem, s událostmi v zařízení. Operační systém pracující v reálném čase je zaměřen na zpracování externích událostí. Operační systém v reálném čase může být podobný uživatelské rozhraní na univerzálním OS, ale je strukturován úplně jinak. Navíc použití operačních systémů v reálném čase je vždy specifické. Pokud je obecný operační systém obecně vnímán uživateli (ne vývojáři) jako již dříve připravená sada aplikací, pak operační systém reálného času slouží pouze jako nástroj pro tvorbu konkrétního hardwarového a softwarového komplexu v reálném čase. A proto nejširší třídu uživatelů operačních systémů pracujících v reálném čase tvoří vývojáři systémů pracujících v reálném čase, lidé navrhující systémy řízení a sběru dat. Při navrhování a vývoji specifického systému v reálném čase programátor vždy přesně ví, jaké události se mohou v zařízení vyskytnout, a zná kritický časový rámec pro obsluhu každé z těchto událostí. Systém RT musí mít čas reagovat na událost, která nastala v zařízení v době kritické pro tuto událost. Hodnota kritického času pro každou událost je určena objektem a událostí samotnou a může být různá, ale reakční dobu systému je nutné předpovědět (vypočítat) při vytváření systému. Nereagování v předpokládaný čas je u systémů v reálném čase považováno za chybu. Systém musí být schopen reagovat na současně se vyskytující události. I když dojde ke dvěma nebo více externím událostem současně, systém musí mít čas na každou z nich reagovat v časových intervalech kritických pro tyto události.

Tvrdé a měkké systémy v reálném čase

Existují dva typy systémů reálného času – tvrdé systémy reálného času a měkké systémy reálného času.

Tvrdé systémy v reálném čase neumožňují za žádných okolností žádné zpoždění v reakci systému, protože:

• výsledky mohou být zbytečné, pokud jsou pozdě
• Pokud je reakce zpožděná, může dojít ke katastrofě

• cena za zpoždění může být nekonečná.

Příklady tvrdých systémů v reálném čase - palubní systémyřídicí systémy, systémy havarijní ochrany, záznamníky nouzových událostí.

Měkké systémy v reálném čase se vyznačují tím, že zpoždění odezvy není kritické, i když může vést ke zvýšení nákladů na výsledky a snížení výkonu systému jako celku. Pokud systém nestihl zpracovat další přijatý balíček, to povede k vypršení časového limitu na straně odesílání a opětovnému odeslání (samozřejmě v závislosti na protokolu). Data se neztratí, ale výkon sítě se sníží Hlavní rozdíl mezi tvrdými a měkkými systémy v reálném čase lze vyjádřit následovně: tvrdý systém v reálném čase se nikdy neopozdí v reakci na událost, měkký systém reálného času by se neměl zpozdit v reakci na událost

Jádro operačního systému

Jádro je centrální částí operačního systému (OS), poskytuje aplikacím koordinovaný přístup ke zdrojům počítače, paměti, externímu hardwaru, externím vstupním a výstupním zařízením, převádí příkazy jazyka aplikace do jazyka binárního kódu, kterému počítač rozumí jako základ kernel představuje pro aplikace nejnižší úroveň abstrakce pro přístup k systémovým prostředkům nezbytným pro jejich provoz. Jádro obvykle poskytuje takový přístup ke spouštěcím procesům odpovídajících aplikací pomocí mechanismů meziprocesové komunikace a volání aplikací do systémových volání OS.

Monolitické jádro

Monolitické jádro poskytuje bohatou sadu hardwarových abstrakcí. Všechny části monolitického jádra fungují ve stejném adresním prostoru. Toto je návrh operačního systému, ve kterém jsou všechny součásti jeho jádra komponenty jeden program, použijte obecné struktury data a interagují spolu přímým voláním procedur. Monolitické jádro - nejstarší způsob organizace operačních systémů. Příkladem systémů s monolitickým jádrem je většina systémů UNIX.

Výhody: Rychlost provozu, zjednodušený vývoj modulů.

Nedostatky: Vzhledem k tomu, že celé jádro funguje ve stejném adresovém prostoru, může selhání jedné z komponent narušit celý systém.

Některá stará monolitická jádra, zejména systémy třídy UNIX/Linux, vyžadovaly rekompilaci, kdykoli se změnilo složení hardwaru. Většina moderní jádra umožňují za provozu načítat moduly, které provádějí část funkcí jádra. V tomto případě nejsou součásti operačního systému nezávislé moduly a součásti jednoho velký program nazývané monolitické jádro, což je sada procedur, z nichž každá může každou volat. Všechny procedury běží v privilegovaném režimu.

Mikrokernel

Mikrokernel poskytuje pouze základní funkce řízení procesů a minimální sadu abstrakcí pro práci s hardwarem. Většina z práce se provádí pomocí speciálních uživatelských procesů nazývaných služby. Rozhodujícím kritériem pro „mikrokernelismus“ je umístění všech nebo téměř všech ovladačů a modulů v servisních procesech.

Výhody: Odolnost proti selhání hardwaru, chybám v komponentách systému. Hlavní výhodou mikrokernelové architektury je vysoký stupeň modularity jádra operačního systému. Díky tomu je mnohem snazší do něj přidávat nové komponenty. V mikrokernelovém operačním systému můžete načítat a uvolňovat nové ovladače, systémy souborů atd., aniž byste přerušili jeho činnost. Proces ladění komponent jádra je od té doby výrazně zjednodušen novou verzi ovladače lze načíst bez restartování celého operačního systému. Komponenty jádra operačního systému se nijak zásadně neliší od uživatelských programů, takže je můžete použít k ladění obvyklými prostředky. Architektura mikrojádra zlepšuje spolehlivost systému, protože selhání na úrovni neprivilegovaného programu je méně nebezpečné než selhání na úrovni režimu jádra.

Nedostatky: Předávání dat mezi procesy vyžaduje režii.

Runtime prostředí

Požadavky na spouštěcí prostředí systémů v reálném čase jsou následující:

• malá systémová paměť - pro možnost jejího zabudování;
• systém musí být zcela rezidentní v paměti, aby nedocházelo k odkládání nebo odkládání paměťových stránek;
• systém musí být multitasking - zajistit maximum efektivní využití všechny systémové prostředky;
• jádro s prioritou pro obsluhu přerušení. Priorita přerušení znamená, že proces, který je připraven ke spuštění a má určitou prioritu, má nutně prioritu ve frontě před procesem s nižší prioritou, rychle ho nahradí a pokračuje ke spuštění. Jádro dokončí jakoukoli servisní práci, jakmile dorazí úloha s nejvyšší prioritou. Tím je zajištěna předvídatelnost systému;
• správce priorit – umožňuje vývojáři aplikace přiřadit každému spouštěcímu modulu prioritu, která nepodléhá systému. Přiřazení priority se používá k určení pořadí, ve kterém se spouštějí programy, které jsou připraveny ke spuštění. Alternativou k tomuto typu plánování je karuselové plánování, ve kterém má každý program, který je připraven pokračovat, stejnou šanci na spuštění. U této metody neexistuje žádná kontrola nad tím, který program bude spuštěn a kdy. To je v prostředí reálného času nepřijatelné. Odesílání na základě priority a jádro s prioritou přerušení dává vývojářům aplikací plnou kontrolu nad systémem. Pokud dojde k události s vyšší prioritou, systém zastaví zpracování úlohy s nižší prioritou a odpoví na nově přijatý požadavek.

Kombinace výše popsaných vlastností vytváří výkonné a efektivní prostředí pro provádění v reálném čase.

Kromě vlastností runtime prostředí je nutné vzít v úvahu také službu, kterou poskytuje jádro OS reálného času. Jádrem každého běhového prostředí v reálném čase je jádro nebo dispečer. Jádro řídí hardware cílový počítač: centrální procesor, paměť a vstupní/výstupní zařízení; řídí provoz všech ostatních systémů a software aplikovaného charakteru. V systému reálného času zaujímá dispečer místo mezi hardwarem cílového počítače a aplikací software. Poskytuje speciální službu potřebnou pro spouštění aplikací v reálném čase. Služba poskytovaná jádrem poskytuje aplikačním programům přístup k systémovým zdrojům, jako je paměť nebo vstupní/výstupní zařízení.

Jádro může poskytovat různé typy služeb:

• Meziúkolová výměna. Často je nutné přenášet data mezi programy v rámci stejného systému Kromě toho mnoho aplikací potřebuje komunikovat s jinými systémy přes síť. Interkom lze provést prostřednictvím systému zpráv. Externí komunikace lze organizovat buď prostřednictvím datagramu ( Nejlepší cesta doručení), nebo prostřednictvím komunikačních linek (garantované doručení). Volba jedné nebo druhé metody závisí na komunikačním protokolu.
• Oddělení dat. V aplikacích v reálném čase trvá sběr dat nejdelší dobu. Data jsou často nezbytná pro provoz jiných programů nebo je potřebuje systém k plnění některých svých funkcí. Mnoho systémů poskytuje přístup k obecné sekce Paměť. Datové fronty jsou rozšířené. Používá se mnoho typů front, z nichž každá má své výhody.
• Zpracování požadavků z externích zařízení. Každý aplikační program je v reálném čase připojen k externímu zařízení určitý typ. Jádro musí poskytovat I/O služby, které aplikačním programům umožňují číst z těchto zařízení a zapisovat na ně. Pro aplikace v reálném čase je běžné mít a tato aplikace externí zařízení. Jádro musí poskytovat službu, která usnadňuje práci s ovladači zařízení. Poskytněte například schopnost psát v jazycích vysoké úrovně - jako je C nebo Pascal.
• Léčba zvláštní situace. Výjimkou je událost, která nastane během provádění programu. Může být synchronní, pokud je jeho výskyt předvídatelný, například dělení nulou. A může být také asynchronní, pokud k němu dojde nepředvídatelně, například při poklesu napětí. Poskytování schopnosti zpracovávat tyto typy událostí umožňuje aplikacím v reálném čase reagovat rychle a předvídatelně na interní a externí události. Existují dva způsoby zpracování výjimek – použití stavových hodnot k detekci chybových stavů a ​​použití obslužné rutiny výjimek k zachycení chybových stavů a ​​jejich opravě.

Přehled architektur RTOS

Architektura operačního systému prošla během své historie výrazným vývojem. Jeden z prvních stavebních principů, monolitické OS (obrázek 1) spočíval v prezentaci OS jako sady modulů, které spolu různými způsoby interagují v rámci jádra systému a poskytují aplikačním programům vstupní rozhraní pro přístup k hardwaru.

úroveň OS (obrázek 2) Příkladem takového OS je dobře známý systém MS-DOS. V systémech této třídy mohly aplikační aplikace přistupovat k hardwaru nejen prostřednictvím jádra systému nebo jeho rezidentních služeb, ale také přímo. Na tomto principu jsou RTOS postaveny již řadu let. Ve srovnání s monolitickými operačními systémy poskytuje tato architektura výrazně větší míru předvídatelnosti reakcí systému a také umožňuje rychlý přístup hardwarové aplikace. Nevýhoda

Co dělá tyto systémy tak špatné, je jejich nedostatek multitaskingu. V rámci této architektury byl problém zpracování asynchronních událostí zredukován na ukládání zpráv do vyrovnávací paměti a následné sekvenční dotazování vyrovnávacích pamětí a jejich zpracování. Dodržení kritických servisních termínů bylo zároveň zajištěno vysokým výkonem výpočetního komplexu ve srovnání s rychlostí externích procesů.

Obrázek 2. Vrstvená architektura OS

Jednou z nejúčinnějších architektur pro vytváření operačních systémů v reálném čase je architektura klient-server. Obecné schéma OS pracujícího pomocí této technologie je uvedeno na obrázku 3. Hlavním principem této architektury je přenos služeb OS ve formě serverů na uživatelskou úroveň a mikrokernel plní funkce správce zpráv mezi klienty uživatelské programy a servery – systémové služby. Tato architektura poskytuje mnoho výhod z hlediska požadavků na RTOS a vestavěné systémy. Mezi tyto výhody patří:

1. Zvyšuje se spolehlivost OS, protože každá služba je v podstatě samostatná aplikace a je snazší ladit a sledovat chyby.

2. Takový systém se lépe škáluje, protože zbytečné služby lze ze systému vyloučit, aniž by to ovlivnilo jeho výkon.

3. Zvyšuje se odolnost systému proti poruchám, protože Zamrzlou službu lze restartovat bez

restartujte systém.

Obrázek 3. Sestavení operačního systému pomocí architektury klient-server

Bohužel v dnešní době není mnoho operačních systémů implementovaných na principu klient-server. Mezi známé RTOS, které implementují architekturu mikrojádra, patří OS9 a QNX.

Seznam použité literatury:

1) http://ru.wikipedia.org/wiki/Real_time_operating system

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5) http://www.ozon.ru/context/detail/id/3092042/

Prezentována recenze srovnávací charakteristiky OS RV přítomen na ruský trh, s odkazem na použití v systémech řízení letectví.

Díky vývoji počítačová technologie V poslední době je možné přiřadit jednomu modulu úkoly, které dříve vykonávalo několik moduly procesoru při současném zlepšení hmotnostních a rozměrových charakteristik řídicího systému a snížení jeho nákladů. Tento trend v letecké technice vedl ke vzniku konceptu integrované modulární avioniky – IMA (Integrated Modular Avionics, IMA).

Problém integrace řídicích funkcí do jednoho modulu spočívá v tom, že je nutné oddělit nyní sdílené zdroje(čas procesoru, paměť, komunikační kanály) mezi různými úkoly, přičemž poskytuje stejnou úroveň spolehlivosti a nezávislosti funkcí jako dříve. Klíčová role Při řešení tohoto problému hraje roli operační systém v reálném čase.

V současné době existuje na světovém trhu několik komerčních RTOS pro kritické aplikace (tabulka 1). Tento článek poskytuje přehled RTOS dostupných na ruském trhu na základě informací z otevřených zdrojů a osobní zkušenost autorů.

Dokumenty upravující požadavky na RTOS

Standard DO-178 (Softwarové zvažování certifikace leteckých systémů a zařízení) definuje požadavky na proces vývoje softwaru a důkladnost jeho ověřování v závislosti na jeho kritičnosti. Úroveň kritickosti softwaru se určuje na základě analýzy závažnosti důsledků selhání softwaru. Existuje celkem pět úrovní kritičnosti softwaru (od A do E).

MILS (Multiple Independent Levels of Security) je speciální přístup k návrhu OS, který zabraňuje šíření chyb aplikačního softwaru za běhu a také zjednodušuje ověřování programu díky modularitě softwaru. Všechny aplikace jsou umístěny v tzv. sekcích (oddílech). Oddíly mají přidělené zdroje (paměťová oblast, čas procesoru během každého cyklu systému, přístup ke komunikačním kanálům atd.). Přístup k přiděleným prostředkům je zaručen operačním systémem běžícím v režimu dohledu. Na jednom procesorovém modulu s jedním operačním systémem tedy může běžet aplikační software různé úrovně kritičnosti - pokud dojde k poruše v méně kritickém (a tedy méně testovaném) softwaru, nijak to neovlivní činnost ostatních sekcí, protože pokusy o „uzurpování“ cizích zdrojů budou operačním systémem blokovány. Myšlenky MILS odrážejí myšlenky IMA a DO-178B.

Chyba 404: Stránku nelze nalézt.

Mohlo k tomu dojít z jednoho z těchto důvodů:

– chyba při zadávání adresy stránky (URL)
– po „nefunkčním“ (nefunkčním, nesprávném) odkazu
– požadovaná stránka nikdy nebyla na webu nebo byla smazána

Můžeš:

– vrátit se zpět pomocí tlačítka Zpět v prohlížeči
– zkontrolujte správnost pravopisu adresy stránky (URL)
– použijte mapu webu nebo přejděte na hlavní stránku

Standard ARINC-653 (Avionics Application Software Standard Interface) specifikuje aplikační softwarové rozhraní APEX, které podporuje koncept oddílů ve stylu MILS. Toto rozhraní zahrnuje funkce pro správu oddílů, procesů, sdílení času, komunikaci mezi oddíly a v rámci nich a monitorování stavu systému. Je třeba poznamenat, že standard ARINC-653 popisuje obecně přijímaný přístup k implementaci nápadů MILS pro IMA, ačkoli mohou existovat i jiné implementace. Letecký RTOS, který vyhovuje ARINC-653, má výhody, protože tento standard je dobře známý a srozumitelný mezinárodním certifikačním orgánům, takže je jednodušší získat certifikát shody DO-178B pro systém postavený podle tohoto standardu.

Standard opakovaně použitelných softwarových komponent. V souladu s DO-178B software konkrétního leteckého aplikačního systému prochází celým certifikačním postupem, i když používá moduly (komponenty), které již byly certifikovány dříve jako součást jiného systému. Jedna z nejnovějších iniciativ FAA ( Federální agentura pro certifikaci civilního letectví, USA) je stanovit kritéria pro možnost opětovného použití softwaru bez opětovné certifikace. Komponenty, které nemusí být znovu certifikovány, se nazývají RSC (Reusable Software Components). Chcete-li získat certifikát pro RSC, musíte utratit více úsilí, ale pak RSC poskytuje značné úspory.

Ruské dokumenty definující požadavky na software (včetně RTOS):

• GOST R ISO/IEC 51904-2002 („Software pro vestavěné systémy. Obecné požadavky pro vývoj a dokumentaci") - analog DO-178B pro vojenské letectví;
• KT-178A ("Kvalifikační požadavky část 178A") - analog DO-178B pro civilní letectví;
• GOST R ISO/IEC 12207-99 (" Informační technologie. Procesy životního cyklu softwaru“).

Porovnání RT OS bylo provedeno podle 13 parametrů, které zohledňují technická kritéria, jednoduchost vývoje a ekonomické parametry.

Parametry časování OS

Jedním z hlavních požadavků na RT OS je minimální doba zpoždění pro zpracování události. V praxi to znamená, že následující parametry musí být malé:

• doba odezvy přerušení - doba mezi skutečným výskytem přerušení a zahájením zpracování první instrukce obsluhy přerušení;
• doba přepínání řídícího vlákna - doba přepínání mezi dvěma vlákny v jednom procesu;
• čas přepínání kontextu procesu (pouze pro OS, které podporují model procesu) - čas přepínání mezi dvěma řídicími vlákny patřícími dvěma různým procesům.

Bohužel to nelze objektivně srovnávat zadané parametry Určení různých RTOS není jednoduché, protože tyto parametry závisí nejen na kvalitě OS, ale také na možnostech použité hardwarové platformy. V ideálním případě by všechny porovnávané operační systémy měly být nainstalovány na stejné hardwarové platformě a poté by měla být provedena příslušná měření. Ani tato měření ale neposkytnou objektivní výsledek, protože různé operační systémy lze více či méně přizpůsobit konkrétnímu hardwaru.

K porovnání parametrů časování používá tento článek fragmentovaná data nalezená na internetu, která se často získávají při testování operačního systému různé vybavení, přičemž složení a povaha testů nejsou vždy jasné.

Za zcela objektivní data lze považovat výsledky získané odborníky z časopisu Dedicated System, kteří provedli testování a praktické srovnání QNX RTOS 6.1, VxWorks AE 1.1 a Windows CE.NET na platformě x86. Přestože jsou tato data v současné době zastaralá, autoři tohoto článku nebyli schopni najít novější materiál. V tabulce Obrázek 2 ukazuje vybraná data srovnání výkonu mezi QNX Neutrino 6.1 a VxWorks AE 1.1. Zpráva Dedicated Systems dala přednost z hlediska výkonu QNX s poměrem skóre nastaveným na 9:5 (QNX:VxWorks), protože během testování byly ve VxWorks objeveny dvě chyby, kvůli kterým bylo nutné kontaktovat podporu, aby je opravila.

V tabulce 3 ukazuje údaje o vlastnostech LynxOS. Složení použitých testů není stanoveno. Co se týče údajů o vlastnostech LynxOS, zajímavý je čtvrtý sloupec (testování na platformě x86). Ve srovnání s VxWorks a QNX vykazuje LynxOS RT OS obrovské zpoždění v reakci na přerušení (více než 5krát). Čas přepnutí kontextu (což znamená čas přepnutí mezi dvěma vlákny v jednom procesu) je stejný jako u QNX a je asi 1,5krát kratší než u VxWorks.

Stabilita parametrů časování

Kromě časových charakteristik je pro RT OS důležitá také stabilita těchto charakteristik. Právě toto kritérium do značné míry určuje „tuhost“ RT OS, tzn. předvídatelnost doby zpracování dat, okamžik vydání výsledků atd.

Na základě údajů z deníku Dedicated System je QNX v tomto kritériu před VxWorks jak z hlediska rozložení charakteristik v sérii podobných testů (poměr maximální doby k průměrné hodnotě je výrazně nižší), tak s rostoucí zátěží. (doba přepínání vlákna při zvýšení počtu vláken 2...128 jednotek pro QNX se zvýšila pouze 1,65krát, zatímco pro VxWorks - 2,24krát).

Podle údajů získaných od RTSoft je známo, že LynxOS má přibližně stejné vlastnosti jako VxWorks.

Správa přístupu ke zdrojům

Pojďme zhodnotit kvalitu řízení přístupu nabízeného jedním nebo druhým RT OS ke kritickým zdrojům výpočetní systém, jako je paměť a čas procesoru.

První otázkou, kterou je třeba zodpovědět, je, zda OS podporuje procesní model. Proces je logická entita, která vlastní jedno nebo více vláken, jejich přidružené zdroje a kontext – obsah registrů a čítačů v daném okamžiku.

Úkolem procesů je:

• v omezení přístupu paměť s náhodným přístupem mezi různé programy v procesu provádění;
• při vymezování rozsahu globálních proměnných v době kompilace (kritické, pokud je aplikační software napsán v jazyce C, který takové vymezení nepodporuje).

Segmentace také zajišťuje oddělení adresních prostorů (v tomto smyslu jsou možnosti shardingu a procesů duplikovány). Navíc sharding poskytuje každému segmentu obsahujícímu jeden nebo více procesů (nebo vláken, pokud OS nepodporuje model procesu) garantovaný časový rozpočet. Tímto způsobem, pokud vlákno s vysokou prioritou přejde do smyčky a naruší svůj segment, všechny ostatní segmenty obdrží čas CPU podle nastavení návrhu a budou nadále fungovat normálně.

LynxOS a QNX podporují procesní model i sharding. VxWorks OS má mechanismus sdílení, ale nepodporuje model procesu. Obecně je to přijatelné, protože sharding poskytuje oddělení adresních prostorů. Ale nedostatek procesů přináší některé nepříjemnosti. Obvykle se rozdělení do segmentů provádí na základě zamýšleného účelu softwaru a jeho kritičnosti. Například některý segment může obsahovat řídicí software pro letový navigační systém, který má vysoká úroveň kritičnost. Tento software je ale také poměrně složitým komplexem, který by bylo logické rozdělit na nezávislé (paměťové) moduly. VxWorks OS tuto funkci neposkytuje, to znamená, že segment se bude skládat z vláken s sdílená paměť, což komplikuje organizaci paralelní vývoj a v konečném důsledku snižuje spolehlivost softwaru.

Podpora pro multiprocesorové a distribuované systémy

Cena multiprocesorových modulů se v poslední době výrazně snížila, a proto se stále více používají ve vestavěných systémech. RT OS samozřejmě musí poskytovat podporu pro takové desky.

jiný slibný směr v konstrukci samohybných děl je distribuované systémy, kde jsou moduly odděleny v prostoru a komunikace mezi nimi probíhá prostřednictvím nějakého síťového prostředí. Opět platí, že použitý operační systém RT musí mít pohodlné a spolehlivé prostředky pro organizaci interakce modulů: podporu pro různé síťových protokolů, prostředky k zajištění transparentnosti sítě.

QNX RTOS nabízí podporu pro víceprocesorové desky. Pro VxWorks byla taková podpora teprve oznámena. Letecká verze LynxOS s podporou víceprocesorových desek zatím neexistuje.

S ohledem na podporu síťových protokolů je třeba poznamenat, že RT OS LynxOS, VxWorks a QNX mají přibližně stejné (a široké) schopnosti. Další výhodou QNX RT OS je jeho speciální architektura síťového subsystému, která zajišťuje síťovou „transparentnost“ aplikačních programů: každý proces může volat jiný proces na vzdáleném modulu stejným způsobem jako proces na lokálním modulu.

Podpora souborového systému

Možnost ukládat informace ve formě souborů je pohodlná a tradiční. Naopak nedostatek takové možnosti vytváří potíže při ukládání zřídka změněných dat a vytváření distribuovaných systémů.

V tabulce Obrázek 4 ukazuje podporu souborového systému pro každý z uvažovaných operačních systémů.

QNX má nejrozsáhlejší podporu pro souborové systémy. Navíc je jeho systém souborů flash odolný proti chybám.

Kvalita dokumentace

Kvalita dokumentace pro RT OS LynxOS, VxWorks, QNX je poměrně vysoká. Existují však také stížnosti na dokumentaci:

• QNX je výborný popis architektury a principů designu, ale nedostatečný popis rozhraní programování aplikací(nejsou popsány všechny parametry; existují nesrovnalosti);
• VxWorks - žádné vysvětlení principů fungování a nedostatečný popis složitého procesu konfigurace OS.

Firmy však na kvalitě materiálu pracují. Dokumentace pro současná verze QNX (6.3.2) byl výrazně rozšířen, některé díly byly přepracovány.

Kvalitní technická podpora

Z hlediska kvality oficiální technické podpory je nepochybným lídrem LynxOS. LynuxWorks slibuje odpovědět na všechny technická otázka do 4 hodin od zveřejnění žádosti. LynxOS je v Rusku distribuován společností RTSoft, která má velký tým zaměstnanců schopných poskytovat kvalifikovanou pomoc. Nevýhodou LynxOS je, že OS není v Rusku zatím příliš rozšířen, neexistuje zde žádná zavedená uživatelská komunita a dokonce neexistuje ani ruskojazyčné fórum.

QSS (výrobce QNX) také nabízí dobrou technickou podporu, ale rychlé odezvy nejsou zaručeny. Na rozdíl od LynxOS má QNX RT OS dobře organizovanou uživatelskou komunitu v zahraničí i v Rusku. Odpovědi na většinu otázek lze nalézt na těchto fórech. QNX u nás distribuuje společnost SVD Embedded Systems, jejíž zaměstnanci jsou schopni poskytnout kompetentní technickou podporu a provádět práce na přizpůsobení OS konkrétním procesorovým deskám. Kromě toho má společnost přímé kontakty s QSS a může získat radu ohledně složitých problémů od vývojáře operačního systému QNX RT.

WindRiver, vývojář VxWorks, tradičně dodržuje uzavřenou technickou politiku, to znamená, že informace o principech fungování operačního systému je poměrně obtížné získat. Tento OS také nemá ruskojazyčné fórum. OS VxWorks RT u nás distribuuje společnost AVD Systems, která se zabývá především prodejem hotových softwarových a hardwarových řešení zahraniční provenience.

Open source

Otevřený RT OS má alespoň tři výhody:

• Vývojáři aplikačního softwaru mohou pochopit komplexní problémy bez zapojení technické podpory;
• snadnější certifikace (žádné záložky atd.);
• dynamičtější vývoj, protože vývojářská společnost RT OS často dostává nejen požadavky na opravu chyb, ale i návrhy na odstranění chyb a vylepšení systému. Komunity open source vývojářů RTOS zpravidla rostou mnohem rychleji a jsou lépe organizované. Zdá se, že nezávislí odborníci pomáhají řešit problémy služby technické podpory a podílejí se na vývoji, ladění a testování systému.

Od září 2007 má QSS jádro QNX s otevřeným zdrojem (včetně balíčku Adaptive Partitioning, balíčku High Availability). O něco později byly otevřeny zdrojové kódy síťového subsystému. V současné době je na oficiálních stránkách k dispozici ke stažení beta verze 6.4.0.

Je třeba poznamenat, že dnes nejsou všechny moduly QNX otevřené (například neexistují žádné kódy pro grafiku a souborové systémy) a licence ukládá omezení na použití „zdrojového kódu“: pouze pro nekomerční použití. Uživatel QNX však získává výše uvedené výhody zdarma.

Zdrojové kódy LynxOS a VxWorks jsou komerčně dostupné. Cena za takový produkt je dohodou.

Nástroje

Dostupnost dobrých nástrojů do značné míry určuje kvalitu a rychlost vývoje aplikačních programů pro konkrétní OS. Je třeba poznamenat, že v současné době poskytují LynxOS, VxWorks a QNX dobrá kvalita nástroje, které zahrnují integrované vývojové prostředí (IDE) a ladění aplikačního softwaru, nástroje pro profilování programů (pro detekci úzkých míst ve výkonu, paměti atd.). Ergonomie ISD pro tyto RT OS obecně není horší než vyvinuté vývojové nástroje pro konvenční OS (například MS Windows).

Přenositelnost aplikačního softwaru

Přenositelnost aplikačního softwaru umožňuje jeho použití pod jinými operačními systémy (včetně OS bez RT). Přenositelnost poskytuje vývojáři aplikačního softwaru určitou nezávislost na RT OS: v případě potřeby můžete přejít na jiný OS za nízkou cenu.

Schopnost psát přenosný software je určena tento moment soulad se standardem POSIX. Všechny uvažované RT OS podporují standard POSIX 1003.1. LynxOS má výhodu – tento OS je binárně kompatibilní s Linuxem. To znamená Linuxové aplikace lze spustit pod LynxOS bez rekompilace. Naopak aplikace LynxOS lze provozovat na Linuxu (verze 2.4.x s jazykovou knihovnou glibs C verze 2.2.2).

Zbytek RT OS vyžaduje jejich rekompilaci pro běh linuxových aplikací. V tomto případě může být proces portování i aplikací kompatibilních s POSIX často značně pracný kvůli rozdílům v implementaci knihoven a kompilátorů.

Podpora architektury procesoru

Tuzemští vývojáři řídicích systémů pro letectví se v dnešní době přechodu od in-house operačních systémů ke komerčním často dostávají do situace, kdy potřebují vybrat a přizpůsobit RTOS stávající procesorové desce. V tomto případě je jedním z klíčových argumentů při výběru OS podpora procesorové architektury použité na desce.

Dodržování leteckých norem

V zahraniční praxi musí mít software pro avionické systémy certifikát o shodě s normou DO-178B. Pokud software různé úrovně kritičnost se provádí na jednom procesorovém modulu, pak musí použitý RTOS podporovat koncept oddílů. (Jinak je téměř nemožné prokázat nepropagaci chyby). Jak již bylo zmíněno, je lepší, když programovací rozhraní RTOS odpovídá standardu ARINC-653, protože standard je dobře znám zahraničním certifikačním orgánům.

LynxOS je lídrem, pokud jde o dodržování standardů. Podporuje ARINC-653 a existuje spousta příkladů certifikovaných systémů DO-178B na něm postavených. Klíčový bod je, že LynuxWorks nabízí sadu RSC (ačkoli autoři článku nevědí nic o ceně).

VxWorks vyhovuje standardu ARINC-653 a systémy postavené na jeho základě mohou být certifikovány podle DO-178B (existuje velké číslo příklady).

QNX nevyhovuje ARINC-653 a zatím neexistují žádné certifikované systémy DO-178B na jeho základě.

Je třeba poznamenat, že systémy QNX lze v zásadě použít k sestavení IMA, protože QNX podporuje vlastní metodu poskytování konceptu oddílů, což je velmi dobrá alternativa k ARINC-653 a navíc umožňuje ušetřit čas procesoru .

Z hlediska podobného Ruské standardy pro vojenské letectví (GOST R ISO/IEC 51904-2002) zatím neexistuje jediný příklad certifikovaného systému, i když v zásadě lze takový systém vyvinout na základě kteréhokoli z uvažovaných OS. Pro operační systém QNX RT v současné době probíhají práce na přípravě hlavních modulů OS pro certifikaci.

Rozvoj systému odborného vzdělávání

Rychlost a kvalita školení personálu pracujícího s OS RT a různými nástroji pro vývoj a ladění softwaru přímo souvisí s rychlostí vývoje softwaru a jeho kvalitou. Přední společnosti v oblasti vestavěného a systémového softwaru, jako je WindRiver, LynuxWorks, QSS, provádějí rozsáhlý program kurzů a školení ke studiu použití produktů společnosti, včetně RT OS.

Výsledky srovnání

QNX Neutrino RTOS je nejpokročilejší operační systém technický bod pohled, má dobrá sada nástroje, má relativně nízká cena. Architektura mikrojádra zajišťuje vysokou spolehlivost a modularitu vyvíjených systémů. Další výhodou je otevřený zdrojový kód. Ale je tu také „moucha“: v současnosti se QNX prakticky nikde v letectví nepoužívá a v tomto ohledu tento OS na své konkurenty (LynxOS a VxWorks) ztrácí. Další nevýhoda QNX: neshoda se standardem ARINC-653.

Je třeba poznamenat, že v zásadě má QNX Neutrino všechny potřebné mechanismy pro práci v systémech avioniky. Spolehlivost a vysoká dostupnost systémů na bázi QNX byla navíc prokázána i v jiných odvětvích, kde jsou náklady na chyby ještě vyšší než v letectví (řízení jaderných reaktorů).

Práce na přípravě certifikace QNX Neutrino podle požadavků tuzemských leteckých norem v současné době provádí SWD Software.

RTOS LynxOS-178 má naopak všechny potřebné certifikáty v zahraničí, i když podle mnoha dalších kritérií vypadá méně vhodně než QNX Neutrino. Upozorňujeme, že pro použití v ruském leteckém průmyslu musí být LynxOS-178 RTOS také certifikován podle domácích GOST.

VxWorks OS má dlouhou historii používání v kritických aplikacích v zahraničí. Naše analýza však ukazuje, že podle mnoha kritérií vypadá méně vhodnější než první dva operační systémy. Důvěryhodnost VxWorks navíc podkopává její uzavřená vývojová strategie.

Expertní skupina / R&D.CNews

Ministerstvo školství a vědy Ruské federace

Volžská státní technologická univerzita

Abstrakt o disciplíně

„Operační systémy v reálném čase: funkce a aplikace“

Vyplnil: student EF (skupina PI-12)

Mikušov Ju.

[e-mail chráněný]

Učitel: Borodin A.V.

Yoshkar-Ola

●Úvod

●Definice

●Vývoj moderních operačních systémů

●Aktuální stav předmětné oblasti

●Odlišnosti od obecných operačních systémů

●Architektura RTOS

●Typy úloh OS

●Pět nejdůležitějších neviditelných úloh OS

●Vlastnosti

●Aplikace

●Trh operačních systémů

●Budoucnost RTOS

●Závěr

●Seznam použitých zdrojů

Úvod

Operační systémy v reálném čase (RTOS) jsou navrženy tak, aby poskytovaly rozhraní ke zdrojům časově kritických systémů v reálném čase. Hlavním úkolem v takových systémech je včasnost zpracování dat.

Hlavním požadavkem na RTOS je zajistit předvídatelnost nebo determinismus chování systému v nejhorších vnějších podmínkách, které se výrazně liší od požadavků na výkon a rychlost univerzálních operačních systémů. Dobrý RTOS má předvídatelné chování při všech scénářích zatížení systému (současná přerušení a spouštění vláken).

Mezi systémy pracujícími v reálném čase a vestavěnými systémy existuje určitý rozdíl. Vestavěný systém nemusí mít vždy předvídatelné chování, v takovém případě se nejedná o systém v reálném čase. I letmý pohled na možné vestavěné systémy však naznačuje, že většina vestavěných systémů vyžaduje předvídatelné chování pro alespoň některé funkce, a proto lze tyto systémy klasifikovat jako systémy pracující v reálném čase.

Je obvyklé rozlišovat mezi měkkými a tvrdými systémy reálného času. V tvrdých systémech reálného času vede neschopnost poskytnout odpověď na jakékoli události v daný čas k poruchám a neschopnosti dokončit zadaný úkol. Ve většině ruskojazyčné literatury se takovým systémům říká systémy s deterministickým časem. Na praktická aplikace reakční doba by měla být minimální. Měkké systémy v reálném čase jsou systémy, které nespadají pod definici „tvrdého“, protože V literatuře pro ně zatím neexistuje jednoznačná definice. Měkké systémy v reálném čase nemusí mít čas vyřešit problém, ale to nevede k selhání systému jako celku. V real-time systémech je nutné zavést určitý termín (v anglické literatuře - deadline), před jehož vypršením musí být úkol nutně (u soft real-time systémů - nejlépe) dokončen. Tento termín používá plánovač úloh jak k přiřazení priority úloze při jejím spuštění, tak k výběru úlohy k provedení.

Definice

Systém reálného času je typ operačního systému, jehož hlavním účelem je poskytovat nezbytnou a dostatečnou sadu funkcí pro zajištění softwarového vývoje systémů reálného času na konkrétním hardwaru.

Systém se nazývá systém reálného času, pokud správnost jeho fungování závisí nejen na logické správnosti výpočtů, ale také na době, po kterou jsou tyto výpočty prováděny. To znamená, že pro události vyskytující se v takovém systému je, kdy k těmto událostem dojde, stejně důležité jako logická správnost událostí samotných.

Komponenty systému reálného času.

Dešifrování Mac OS X:

„Mac“ odkazuje na název společnosti Macintosh.

"OS" - operační systém, tedy operační systém.

„X“ je římská číslice deset, která označuje číslo verze operačního systému.

Vývoj moderních operačních systémů

Ve vývoji moderních operačních systémů je tendence k dalšímu přesunu kódu do vyšších úrovní a zároveň odstranění všeho, co je možné z režimu jádra a ponechání minimálního mikrokernelu. To se obvykle provádí přenesením většiny úloh operačního systému na uživatelské procesy.

Při přijetí požadavku na operaci, jako je čtení bloku souboru, odešle uživatelský proces (nyní nazývaný obsluhovaný proces nebo klientský proces) požadavek na serverový (serverový) proces, který jej zpracuje a odešle zpět odpověď.

Rozdělením operačního systému na části, z nichž každá spravuje pouze jeden prvek systému (souborový systém, procesy, terminál nebo paměť), se všechny části stanou malými a spravovatelnými.

Navíc, protože všechny servery běží jako procesy v uživatelském režimu spíše než procesy v režimu jádra, nemají přímý přístup k hardwaru. Pokud tedy na souborovém serveru dojde k chybě, může dojít k selhání služby zpracování požadavku na soubor, ale to obvykle nezpůsobí zastavení celého počítače.

Další výhodou modelu klient-server je, že jej lze snadno přizpůsobit pro použití v distribuovaných systémech. Pokud klient komunikuje se serverem odesíláním zpráv, klient nemusí vědět, zda je jeho zpráva zpracovávána lokálně na jeho vlastním počítači, nebo zda byla odeslána přes síť na server na vzdáleném počítači. Z pohledu klienta se v obou případech děje to samé: požadavek byl odeslán a byla přijata odpověď.

Výše uvedený příběh o jádru, které řídí přenos zpráv z klientů na servery a zpět, není zcela realistický. Některé funkce operačního systému, jako je načítání instrukcí do fyzických registrů I/O zařízení, je obtížné, ne-li nemožné, provádět z programů v uživatelském prostoru. Tento problém lze vyřešit dvěma způsoby.

První je, že některé kritické serverové procesy (jako jsou ovladače I/O zařízení) skutečně běží v režimu jádra s plným přístupem k hardwaru, ale komunikují s jinými procesy pomocí normálního předávání zpráv.

Druhým způsobem je zabudovat do jádra minimální mechanismus zpracování informací, ale rozhodnutí o politice ponechat na serverech v uživatelském prostoru. Například jádro dokáže rozpoznat zprávy odeslané na konkrétní adresy. Pro jádro to znamená, že potřebuje vzít obsah zprávy a načíst ji například do některých diskových I/O registrů, aby spustilo operaci čtení disku.

V tomto příkladu jádro nemusí ani zkoumat bajty zprávy, pokud jsou platné nebo smysluplné; umí je slepě zkopírovat do diskových registrů. (Samozřejmě je třeba použít nějaké schéma k omezení rozsahu procesů, které mají právo takové zprávy odesílat.)

Aktuální stav předmětné oblasti

Asociace, společnosti a produkty

Microsoft a Apple Inc. jsou nejoblíbenějšími výrobci operačních systémů a softwaru pro ně v moderním světě.

Moderní operační systémy od společnosti Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Moderní operační systémy od společnosti Apple Inc:

Moderní mobilní operační systémy:

1. Linuxové systémy (Android)

Rozdíly od obecných operačních systémů

Klíčovým rozdílem mezi základními službami RTOS je deterministická povaha jejich práce, založená na přísné časové kontrole. V v tomto případě Determinismem rozumíme, ž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 zahrnovat žá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 pak nesplní své časové kvantum, což způsobí chybu.

V tomto smyslu nejsou operační systémy pro obecné účely deterministické. Jejich služby mohou umožňovat občasné prodlevy v jejich provozu, což může vést ke zpomalení reakce aplikace na akce uživatele v neznámém okamžiku. Při návrhu konvenčních operačních systémů vývojáři nezaměřují svou pozornost na matematický aparát pro výpočet doby provedení konkrétního úkolu a služby. Toto není pro tento druh systémy

Architektura RTOS

Architektura operačního systému prošla během své historie výrazným vývojem. Jedním z prvních principů výstavby, tzv. monolitický OS (obrázek 1), měl prezentovat OS jako sadu modulů, které se vzájemně ovlivňují různými způsoby v rámci jádra systému a poskytují aplikačním programům vstupní rozhraní pro přístup k hardwaru. Hlavní nevýhodou této architektury je špatná předvídatelnost jejího chování, způsobená složitou interakcí systémových modulů mezi sebou.

Většina moderních operačních systémů, real-time i univerzálních, je však postavena právě na tomto principu.

V úlohách automatizace se OS úrovně široce používají jako RTOS (obrázek 2). Příkladem takového OS je známý systém MS-DOS. V systémech této třídy mohly aplikační aplikace přistupovat k hardwaru nejen prostřednictvím jádra systému nebo jeho rezidentních služeb, ale také přímo. Na tomto principu jsou RTOS postaveny již řadu let. Ve srovnání s monolitickými operačními systémy poskytuje tato architektura výrazně větší míru předvídatelnosti reakcí systému a také umožňuje aplikačním aplikacím rychlý přístup k hardwaru. Nevýhodou těchto systémů je nedostatek multitaskingu. V rámci této architektury byl problém zpracování asynchronních událostí zredukován na ukládání zpráv do vyrovnávací paměti a následné sekvenční dotazování vyrovnávacích pamětí a jejich zpracování. Dodržení kritických servisních termínů bylo zároveň zajištěno vysokým výkonem výpočetního komplexu ve srovnání s rychlostí externích procesů.

Jednou z nejúčinnějších architektur pro vytváření operačních systémů v reálném čase je architektura klient-server. Obecné schéma OS pracujícího pomocí této technologie je uvedeno na obrázku 3. Hlavním principem této architektury je přenos služeb OS ve formě serverů na uživatelskou úroveň a mikrokernel plní funkce správce zpráv mezi klienty uživatelské programy a servery - systémové služby. Tato architektura poskytuje mnoho výhod z hlediska požadavků na RTOS a vestavěné systémy. Mezi tyto výhody patří:

1. Zvyšuje se spolehlivost OS, protože Každá služba je ve skutečnosti nezávislou aplikací a lze ji snadněji ladit a sledovat chyby.

2. Takový systém se lépe škáluje, protože nepotřebné služby mohou být ze systému vyloučeny, aniž by došlo ke snížení jeho výkonu.

3. Zvyšuje se odolnost systému proti poruchám, protože Zamrzlou službu lze restartovat bez restartování systému.

Bohužel dnes není mnoho operačních systémů implementováno na principu klient-server. Mezi známé RTOS, které implementují architekturu mikrojádra, patří OS9 a QNX.

Typy úkolů

Každý proces obsahuje jeden nebo více úkolů. Operační systém umožňuje úkolu vytvářet nové úkoly. Úkoly lze rozdělit do 3 kategorií podle způsobu jednání.

1. Cyklické úlohy. Charakteristika řídicích procesů a interaktivních procesů.

2. Periodické úkoly. Pro mnohé charakteristické technologických postupů a synchronizační úlohy.

3. Impulzní úkoly. Typické pro signalizační problémy a asynchronní technologické procesy.

Pět nejdůležitějších neviditelných úkolů operačního systému

1. Poskytuje „spojení“ hardware-software

Operační systém slouží jako jakýsi „překladač“ mezi hardwarem počítače a jeho softwarem. Pokud otevřete skříň počítače, můžete vidět různé desky, čipy, kabely a další komponenty. Toto je fyzický základ, který umožňuje provádění programu. Ale program nemůže jednoduše vzít a použít hardwarové prostředky počítače. Dělá to prostřednictvím operačního systému.

V poslední době se operační systémy stále častěji nazývají „platformy“. A tento název velmi přesně odráží podstatu. OS je platforma, na které jsou programy umístěny. Nebo, jak se nyní říká, aplikace do operačního systému. Je to operační systém, který umožňuje softwaru „mluvit“ s hardwarem. To platí také pro vstupní a výstupní zařízení. Nejvíc jednoduchý příklad Vstupním zařízením je klávesnice a výstupním zařízením je monitor.

Toto je velmi důležitou práci. K jednomu počítači lze teoreticky připojit stovky zařízení různá zařízení vstup a výstup. Pojďme vzít běžná myš. Ale „myš“ je obecný pojem. Existují desítky různých modelů tohoto manipulátoru. Bylo by nemožným úkolem zajistit oddělené softwarová podpora každý typ myši tak, aby přímo „komunikovala“ s počítačovými prostředky. Řešením je ale databáze ovladačů obsažená v operačním systému. Pro uživatele to vypadá, jako by si k počítači jednoduše připojil libovolnou myš a ta okamžitě začala fungovat.

2. Přinutí stejnou aplikaci pracovat na jiném hardwaru

Je to operační systém, který umožňuje, aby software běžel na různých počítačích, a ne pouze na jedné konkrétní konfiguraci. Kdysi se programy psaly pro konkrétní model počítače. Programovací jazyk vlastně fungoval jako operační systém předchůdců moderních PC, mikropočítačů z konce sedmdesátých let minulého století.

V těchto dnech však OS převzal roli jakéhosi „adaptéru“ mezi programy a počítačovým hardwarem. Pokud vezmete jakékoli dva modely počítačů, sady komponent, ze kterých jsou sestaveny, se budou lišit. To platí i pro Macintoshe známé svou vzájemnou podobností, nemluvě o celé té obrovské rozmanitosti, kterou lze nalézt moderní trh PC.

Operační prostředí vytváří pro program tzv. abstraktní prostředí. To může být reprezentováno jako dialog mezi OS a programem. Během tohoto pro člověka nepochopitelného „rozhovoru“ program platformě „řekne“ o svých potřebách a operační systém musí „přemýšlet“, jak je racionálně uspokojit. Jde o to, že musíte přemýšlet velmi rychle. Moderní hráč není připraven čekat hodinu nebo dvě, než se načte jeho oblíbená hra.

Program tedy operačnímu systému „řekne“, co přesně potřebuje, aby správně fungoval. Koneckonců, aplikace není přímo obeznámena s počítačovými prostředky. A OS zase rozděluje úkoly, které mu program zadává, mezi zdroje digitálního zařízení. A typ Hardware nemá pro program žádný význam. Platforma se o vše postará! Operační systém umí „mluvit“, když ne se všemi, tak s mnoha zařízeními a hardwarovými moduly.

Nebýt této cenné dovednosti operačního systému, museli by programátoři přepisovat své programy pro každou konkrétní konfiguraci počítače, pro každou sadu komponent. A nebýt operačního systému, program nemusí vůbec fungovat na počítači, jehož vlastnosti se liší od vlastností předpokládaných programátorem při vytváření programu.

Dnes vývojáři vytvářejí své aplikace pro platformy, a ne pro nějakou známou hardwarovou konfiguraci. Jednoduše řečeno ne pro konkrétní počítač, ale pro konkrétní operační systém. To je samozřejmě mnohem jednodušší. Miliony zařízení mohou provozovat stejný operační systém. Proto se staly možnými desítky a dokonce stovky tisíc aplikací, které jsou dostupné modernímu uživateli každé z populárních platforem.

3. Vyhledejte soubor požadovaný aplikací

Samotné fyzické zdroje počítače by nestačily na to, aby se programy správně vypořádaly se svými úkoly. Všechny informace jsou uloženy v souborech a tyto soubory musí splňovat určitá pravidla. Tato pravidla popisují, jak pojmenovávat a ukládat soubory. Tuto obecnou sadu pravidel nazýváme „systém správy souborů“ nebo jednoduše „správce souborů“.

Různé operační systémy implementují různé přístupy ke správě souborů. Uživatel si navíc může nainstalovat další software, který mu umožní efektivněji spravovat soubory. Je to operační systém, který si „pamatuje“ soubory uložené v počítači. Když chce aplikace získat přístup k určitému souboru, OS ukáže programu cestu k němu.

Bez systému správy souborů jsou digitální informace v počítači jednoduše bezvýznamnou sbírkou dat. Chaos, ve kterém nelze nic najít. A ještě více, najít to v nejkratších zlomcích sekundy.

Operační systém se pro nás neviditelně řídí svými vlastními pravidly, takže nemusíte ručně přistupovat k těm paměťovým buňkám, kde je fyzicky uložen požadovaný soubor. Ale co je nejdůležitější, uživatel moderního operačního systému nemusí nutně znát tato pravidla, aby mohl pracovat na počítači.

4. Efektivní přidělování dostupné paměti RAM

Protože mluvíme o paměti, má smysl pamatovat na paměť s náhodným přístupem (RAM). Právě o tom úložišti, které má procesor vždy „po ruce“.

Je třeba zdůraznit, že tento nejdůležitější počítačový zdroj je také spravován operačním systémem. RAM je zdrojem, který mnoho uživatelů velmi podceňuje. Jak zrychlit váš počítač? Mnozí věří, že naléhavě potřebují více výkonný procesor. V praxi však často stačí jednoduše zvýšit množství paměti RAM, aby došlo k výraznému zvýšení výkonu počítače.

V paměti RAM počítač ukládá informace, které může vyžadovat procesor provádějící výpočty. Považujte tento typ paměti jednoduše za dočasné úložiště informací, které musí být „blíže k procesoru“.

Když pracujeme s počítačem, někdy nám běží několik programů současně. Operační systém přiděluje každé úloze určité množství paměti. Pokud procesor potřebuje informace, které nenajde v RAM, bude je muset hledat jinde. Zejména na pevném disku počítače. Bude to trvat déle než načítání dat z paměti RAM. Pro uživatele bude tato situace vypadat jako dočasné „zamrznutí“ aplikace. V takových případech je obvyklé říkat, že „počítač myslí“.

Jedním z úkolů, které operační systém přebírá, pro uživatele neviditelně, je minimalizace prodlevy, tedy té velmi nepříjemné doby, během níž je počítač zaneprázdněn svým vlastním podnikáním a nereaguje na vaše volání do něj. Problém je v tom, že v daném okamžiku operační systém

má určité množství paměti RAM, které je vždy omezené. Tento objem také závisí na tom, kolik programů současně používáte. Operační systém musí „vědět“ každou chvíli, kolik paměti RAM mu zbývá, aby ji mohl včas přidělit procesu, který tento důležitý zdroj potřebuje.

Operační systém „vyhodnocuje“ požadavky každého běžícího procesu a rozhoduje, jak je inteligentně uspokojit. V ideálním případě by to mělo být provedeno tak, aby uživatel nezaznamenal vůbec žádné zpoždění. Ale v praxi se OS jednoduše snaží snížit taková zpoždění na minimum a racionálně rozděluje zdroje, které ve skutečnosti má.

Na Zemi nejsou žádné počítače s neomezenou pamětí RAM. Systém tedy musí vždy volit, který proces je v danou chvíli považován za prioritní a který je sekundární. Kdo by měl naléhavě alokovat paměť a kdo si zatím poradí a bude trpělivý. Uživatel nemusí vždy souhlasit s pravidly, kterými se operační systém při přidělování paměti řídí. Nezávislé přidělení volné paměti RAM k procesům by však bylo mnohem obtížnější a časově náročnější než její svěření softwarové platformě.

5. Soustředí pozornost procesoru na konkrétní úkol

Centrální procesorová jednotka (CPU) je fyzický modul, který řeší úlohy, které uživatel nastavuje pro svůj počítač. Další věc je, že vzácný uživatel mluví jazykem, kterému procesor rozumí. A co víc, ne každý programátor dobře zná strojový kód. Člověk možná ani nepomyslí na to, že jakýkoli program je komplexní soubor matematických problémů.

Centrální procesor provádí výpočty, tedy nalézá řešení těchto problémů, a dává vám hotové výsledky, které ani zdaleka nepřipomínají vzorce z učebnice algebry. Běžného uživatele prostě celá tato matematika nezajímá. On ho chce herní postava přeskočil překážku ve zlomku vteřiny nebo chce zkontrolovat pravopis textu, který právě napsal. Za těmito zdánlivě daleko od nudných číselných úloh se skrývá nejsložitější matematika.

Každý spuštěný program vyžaduje část výpočetního výkonu procesoru. Jak více programů běžíte současně, tím více se zatížení procesoru blíží maximu. Úkolem operačního systému je koordinovat dodání informací ke zpracování procesoru tak, aby vše proběhlo hladce a bez povšimnutí uživatele. OS může přepínat pozornost procesoru z jedné úlohy na druhou.

Jeden z důležité role Role operačního systému je jako správce zdrojů. Pokud se s tímto úkolem vypořádá dobře, pak ani nevíme, ve kterém okamžiku procesor odložil jeden úkol a obrátil svou pozornost na jiný.

Neviditelný a nenahraditelný pomocník

Nejtěžším úkolem operačního systému je přimět vás, abyste jej ignorovali a zaměřili se na aplikace, které vás zajímají. A zatímco vše jde dobře, uživatel o platformě vůbec nepřemýšlí. A teprve když začnou selhání softwaru, uživatel si uvědomí, jak důležité je poslání operačního systému.

Tyto „rozdíly“ mezi operačními systémy, které si většina uživatelů všimne, jsou čistě kosmetické. Je to vzácný uživatel, který rozumí programování natolik, aby za skořápkou grafického rozhraní viděl, co vlastně odlišuje jeden operační systém od druhého. Ani vzhled desktop, ani design ikon aplikací nemá nic společného s vnitřní podstatou operačního systému.

Výše popsané úkoly plní každý sám moderní operační systém, který ovládá jakékoli počítačové zařízení. Bez ohledu na to, jak operační systém vypadá a na jakém zařízení je nainstalován: na PC, mobilním zařízení nebo herní konzoli.

Zvláštnosti

Pozitivní vlastnosti

Široká dostupnost produktu

V naprosté většině případů je na počítačích nainstalován systém Windows. Proto, když přijedete navštívit přítele nebo své pracoviště, můžete snadno přenést pár obrázků z flash disku, textové soubory nebo klipy. Snadné použití a podpora OS Windows pro jakýkoli hardware a jakékoli programy přispěly ke globální distribuci tohoto OS.

Pěkné rozhraní

Moderní operační systémy mají docela pěkné a intuitivní rozhraní. To podporuje rychlé vnímání informací, snadné používání počítače a rychlé učení se práci s OS.

Stabilita OS

Obecně lze stabilitu moderního OS nazvat přijatelnou. Slovo „přijatelné“ zde však musí být doprovázeno mnoha výhradami:

1. Stabilita OS se stává přijatelnou až po jeho kvalitě a správnou konfiguraci- tady nemá cenu mluvit o nenaladěném systému (stejně jako o nenaladěné kytaře).

2. Stabilita moderního OS také do značné míry závisí na verzi produktu a přítomnosti nainstalovaných servisních balíčků a doplňků - bohužel, bez jejich přítomnosti dochází v provozu OS k častým poruchám.

3. Stabilita OS závisí také na samotných aplikacích nainstalovaných uživatelem na OS: čím stabilnější jsou v provozu a tím kompatibilnější se samotným softwarem Shell Windows, tím méně poruch budeme moci pozorovat v provozu hlavního OS.

4. Stabilita moderního OS je značně ovlivněna samotným hardwarem, který se používá ve spojení s běžícím OS.

5. Také na stabilní práci V moderních operačních systémech nejsou ovladače zařízení zdaleka nejméně vlivné. Jedná se o miniprogramy zodpovědné za spárování určitého softwaru s určitým hardwarem.

Dobrá kompatibilita s produkty od různých vývojářů (asiO.C. Okna)

Moderní OS je schopen správně porozumět všem typům souborů, které se objevily v jeho raných reinkarnacích. Pokud si vzpomeneme na stejné přípony souborů, bude jasné, že jejich předkem je ve skutečnosti ten samý primitivní a archaický OS, kdysi zakoupený od vývojáře třetí strany a připomenutý společností Microsoft - MS-DOS. Tato kontinuita formátů souborů se jako vlákno táhne všemi verzemi Windows, což je samo o sobě prostě úžasné.