A valós idejű operációs rendszer ( RTOS , angol real-time operációs rendszer, RTOS ) a speciális operációs rendszer egy fajtája , amelynek fő célja, hogy a szükséges és elegendő funkciókészletet biztosítsa a valós- időrendszerek meghatározott hardvereszközökön.
A UNIX specifikáció 2. változata a következőket határozza meg:
A valós idő az operációs rendszerekben az operációs rendszer azon képessége, hogy egy bizonyos időtartamon belül a szükséges szintű szolgáltatást nyújtsa. [egy]
Eredeti szöveg (angol)[ showelrejt] Valós idejű operációs rendszerekben: az operációs rendszer azon képessége, hogy meghatározott válaszidőn belül a szükséges szintű szolgáltatást nyújtsa. [2]Az ideális RTOS kiszámítható viselkedést mutat minden terhelési forgatókönyv esetén, beleértve a párhuzamos megszakításokat és a szálvégrehajtást [3] .
A valós idejű operációs rendszereket néha két típusra osztják: kemény valós idejű rendszerekre és puha valós idejű rendszerekre [4] .
Az olyan operációs rendszert, amely a legrosszabb esetekben is képes biztosítani a szükséges végrehajtási időt egy valós idejű feladathoz, kemény valós idejű operációs rendszernek nevezzük . Az olyan rendszert, amely átlagosan egy valós idejű feladathoz szükséges végrehajtási időt tudja biztosítani, soft real-time operációs rendszernek nevezzük .
A kemény valós idejű rendszerek nem engedik meg a rendszer reagálásának késleltetését, mivel ez az eredmények relevanciájának elvesztéséhez, jelentős anyagi veszteségekhez, sőt balesetekhez és katasztrófákhoz vezethet. Az a helyzet, amelyben az eseményfeldolgozás a megengedett időn túl történik, végzetes hibának minősül egy kemény valós idejű rendszerben. Ilyen helyzet esetén az operációs rendszer megszakítja a műveletet és blokkolja azt, hogy amennyire lehetséges, a rendszer többi részének megbízhatósága és rendelkezésre állása ne legyen hatással. A kemény valós idejű rendszerek példái lehetnek a fedélzeti vezérlőrendszerek (repülőgépen, űrhajón, hajón stb.), vészvédelmi rendszerek, vészhelyzeti eseményrögzítők [5] .
Egy lágy valós idejű rendszerekben a válaszkésleltetés helyrehozható hibának minősül, amely növelheti az eredmények költségét és csökkentheti a teljesítményt, de nem végzetes. Ilyen például a számítógépes hálózat működése [6] . Ha a rendszernek nem volt ideje feldolgozni a következő fogadott csomagot, az a küldő oldalon leálláshoz és újraküldéshez vezet ( protokolltól függően ). Nem vesznek el adatok, de a hálózat teljesítménye csökken.
A kemény és lágy valós idejű rendszerek közötti fő különbség a következőképpen írható le: egy kemény valós idejű rendszer soha nem késik el egy eseményre adott reakcióval, egy puha valós idejű rendszer nem késhet el egy eseményre adott reakcióval [6] .
A valós idejű operációs rendszert gyakran csak olyan rendszernek tekintik, amely nehéz valós idejű problémák megoldására használható. Ez a definíció azt jelenti, hogy az RTOS rendelkezik a szükséges eszközökkel, de azt is jelenti, hogy ezeket az eszközöket helyesen kell használni [5] .
A legtöbb szoftver a lágy valós időre orientálódik. Az ilyen rendszereket a következők jellemzik:
Klasszikus példa arra a feladatra, ahol RTOS-ra van szükség, egy robot vezérlése, amely egy alkatrészt egy futószalagról vesz fel . Az alkatrész mozog, és a robotnak csak egy kis ideje van, amikor fel tudja venni. Ha késik, akkor az alkatrész már nem lesz a szállítószalag megfelelő szakaszában, így a munka nem történik meg, annak ellenére, hogy a robot a megfelelő helyen van. Ha korábban készül, akkor az alkatrésznek még nem lesz ideje felhajtani, és elzárja az útját.
Ezenkívül az operációs rendszerek esetében az „ interaktív valós idejű ” fogalmát néha használják, amely meghatározza a grafikus felület eseményeire való reagálás minimális küszöbértékét, amely alatt a kezelő - egy személy - nyugodtan, idegesség nélkül várhat. hogy a rendszer reagáljon a nekik adott utasításokra.
Az RTOS-t és a hagyományos operációs rendszereket összehasonlító táblázat [5] :
| valós idejű operációs rendszer | általános célú operációs rendszer | |
|---|---|---|
| A fő feladat | Képes reagálni a berendezésen előforduló eseményekre | A számítógépes erőforrások optimális elosztása a felhasználók és feladatok között |
| Mire összpontosít | Külső események kezelése | Felhasználói műveletek kezelése |
| Hogyan van elhelyezve | Egy adott valós idejű hardver-szoftver komplex létrehozására szolgáló eszköz | A felhasználó használatra kész alkalmazások halmazaként érzékeli |
| Kinek szánták | Minősített Fejlesztő | Köztes felhasználó |
Fejlesztésük során az RTOS a következő architektúrák alapján épült fel :
| Monolit építészet | Többszintű (réteges) architektúra | Kliens-szerver architektúra |
Az RTOS mag biztosítja a köztes absztrakt OS szint működését, amely elrejti az alkalmazói szoftverek elől a processzor (több processzor) és a hozzá tartozó hardver technikai eszközének sajátosságait [7] .
Ez az absztrakt réteg öt fő szolgáltatási kategóriát biztosít az alkalmazásszoftverek számára [7] [8] :
Az alapszolgáltatásokon kívül számos RTOS kiegészítő összetevőket kínál olyan magas szintű koncepciók megszervezéséhez, mint a fájlrendszer , hálózatkezelés, hálózatkezelés, adatbázis -kezelés , grafikus felhasználói felület stb. Bár ezen összetevők közül sok sokkal nagyobb és több összetettebbek, mint maga az RTOS mag, ennek ellenére a szolgáltatásain alapulnak. Ezen összetevők mindegyike csak akkor szerepel a beágyazott rendszerben, ha a szolgáltatásai szükségesek a beágyazott alkalmazás futtatásához, és csak a memóriafogyasztás minimális szinten tartásához [7] .
Számos általános célú operációs rendszer is támogatja a fenti szolgáltatásokat. Az RTOS alapszolgáltatásai között azonban a legfontosabb különbség a munkájuk determinisztikus , szigorú időszabályozáson alapuló jellege. Ebben az esetben determinizmus alatt azt a tényt értjük, hogy az operációs rendszer egy szolgáltatásának végrehajtásához egy ismert időtartamú időintervallumra van szükség. Elméletileg ez az idő matematikai képletekkel számítható ki , amelyeknek szigorúan algebrainak kell lenniük, és nem tartalmazhatnak véletlenszerű időparamétereket. Bármely valószínűségi változó , amely meghatározza egy feladat végrehajtási idejét az RTOS-ban, nemkívánatos késést okozhat az alkalmazásban, ekkor a következő feladat nem fog beleférni az időkvantumába, ami hibát okoz [7] .
Ebben az értelemben az általános célú operációs rendszerek nem determinisztikusak. Szolgáltatásaik véletlenszerű késéseket tehetnek lehetővé munkájuk során, ami az alkalmazás felhasználói műveletekre adott válaszának lelassulásához vezethet egy ismert, ismeretlen időpontban. A hagyományos operációs rendszerek tervezésekor a fejlesztők nem az adott feladat és szolgáltatás végrehajtási idejének kiszámításához szükséges matematikai berendezésre helyezik a hangsúlyt. Ez nem kritikus az ilyen típusú rendszerek esetében [7] .
A legtöbb RTOS a feladatütemezést a következő séma szerint hajtja végre [7] . Az alkalmazásban minden feladathoz egy bizonyos prioritás van hozzárendelve. Minél magasabb a prioritás, annál nagyobbnak kell lennie a feladat reaktivitásának. A nagy reaktivitást preemptív prioritású ütemezési megközelítés megvalósításával érjük el , melynek lényege, hogy az ütemező egy tetszőleges időpontban leállíthatja bármely feladat végrehajtását, ha úgy dönt, hogy egy másik feladatot azonnal el kell indítani.
A leírt séma a következő szabály szerint működik: ha két feladat egyidejűleg futásra kész, de az elsőnek magas, a másodiknak alacsony a prioritása, akkor az ütemező az elsőt részesíti előnyben. . A második feladat csak az első befejezése után indul el.
Lehetséges, hogy egy alacsony prioritású feladat már fut, és az ütemező üzenetet kap, hogy egy másik magasabb prioritású feladat futásra készen áll. Ezt valamilyen külső hatás (hardveres megszakítás) okozhatja, például az RTOS által vezérelt eszköz kapcsolóállapotának változása . Ilyen helyzetben a feladatütemező az elsőbbségi megelőző ütemezési megközelítés szerint fog viselkedni a következőképpen. Egy alacsony prioritású feladat végrehajthatja az aktuális gépi utasítást (de nem a programforrásban magas szintű nyelven leírt utasítást ), amely után a feladat végrehajtása felfüggesztésre kerül [7] . Ezután elindul egy magas prioritású feladat. Miután befejeződött, az ütemező elindítja a megszakított első feladatot az utoljára végrehajtott gépi utasítással.
Minden alkalommal, amikor a feladatütemező valamilyen külső esemény (trigger) bekövetkezéséről kap jelet, amelynek oka lehet hardveres és szoftveres is, a következő algoritmus szerint jár el [7] :
Az algoritmus ezen öt lépését feladatváltásnak is nevezik.
A hagyományos RTOS-ban egy feladat három lehetséges állapotban lehet:
Legtöbbször a feladatok többsége blokkolva van. Egyszerre csak egy feladat futhat a CPU-n. A primitív RTOS-ban a végrehajtásra kész feladatok listája általában nagyon rövid, legfeljebb két-három elemből állhat.
Az RTOS adminisztrátor fő feladata egy ilyen feladatütemező összeállítása.
Ha az utolsó végrehajtásra kész feladatok listájában nincs több mint kettő vagy három feladat, akkor feltételezzük, hogy minden feladat az optimális sorrendben található. Ha vannak olyan helyzetek, amikor a listában szereplő feladatok száma meghaladja a megengedett határértéket, akkor a feladatok prioritási sorrendbe kerülnek.
Jelenleg az RTOS hatékony tervezésének problémájának megoldására két megközelítést fejlesztenek a legintenzívebben [9] :
Nagy rendszerterhelések esetén az EDF hatékonyabb, mint az RMS.
A többfeladatos rendszereknek el kell osztaniuk az erőforrásokhoz való hozzáférést. Két vagy több folyamat egyidejű hozzáférése bármely memóriaterülethez vagy más erőforrásokhoz bizonyos veszélyt jelent. A probléma megoldásának három módja van: a megszakítások ideiglenes blokkolása , bináris szemaforok , jelek küldése. Az RTOS általában nem az első módot használja, mert a felhasználói alkalmazás nem tudja annyira vezérelni a processzort, amennyire akarja. Számos beágyazott rendszer és RTOS azonban lehetővé teszi az alkalmazások számára, hogy kernel módban fussanak, hogy az operációs rendszer beavatkozása nélkül hozzáférjenek a rendszerhívásokhoz és vezéreljék a végrehajtási környezetet.
Egyprocesszoros rendszereken a legjobb megoldás egy kernel módban futó alkalmazás, amely blokkolhatja a megszakításokat. Amíg a megszakítás le van tiltva, az alkalmazás egyedül a folyamat erőforrásait használja, és semmilyen más feladat vagy megszakítás nem futhat. Így minden kritikus erőforrás védett. Miután az alkalmazás befejezte a kritikus tevékenységeket, engedélyeznie kell a megszakításokat, ha vannak ilyenek. A megszakítás blokkolása csak akkor engedélyezett, ha a leghosszabb kritikus szakasz végrehajtási ideje kisebb, mint a megengedett megszakítási válaszidő. Ezt a védelmi módszert általában csak akkor használják, ha a kritikus kód hossza nem haladja meg a néhány sort, és nem tartalmaz hurkokat . Ez a módszer ideális a regiszterek védelmére .
Ha a kritikus szakasz hossza nagyobb, mint a maximális hossz, vagy ciklusokat tartalmaz, a programozónak olyan mechanizmusokat kell alkalmaznia, amelyek megegyeznek az általános célú rendszerek viselkedésével, vagy utánozzák azokat, például szemaforokat és jelzéseket.
Az alábbi memóriafoglalási problémák nagyobb figyelmet kapnak az RTOS-ban, mint az általános célú operációs rendszerekben.
Először is a memóriakiosztás sebessége. A szabványos memóriakiosztási séma magában foglalja egy határozatlan hosszúságú lista szkennelését egy adott méretű szabad memóriaterület megtalálásához, és ez elfogadhatatlan, mivel az RTOS-ban a memóriafoglalásnak meghatározott időn belül kell megtörténnie.
Másodszor, a memória töredezetté válhat, ha szabad területeit felosztják a már futó folyamatok. Ez a program leállását okozhatja, mivel nem tudja használni az új memóriahelyet. A memória-feldarabolást fokozatosan növelő memória-lefoglaló algoritmus jól működhet asztali rendszereken, ha legalább havonta újraindulnak, de elfogadhatatlan azoknál a beágyazott rendszereknél, amelyek évekig futnak újraindítás nélkül.
Egy egyszerű algoritmus rögzített hosszúságú memóriablokkokkal nagyon jól működik egyszerű beágyazott rendszerekben.
Ez az algoritmus jól működik asztali rendszereken is, különösen akkor, ha egy memóriablokk egyik mag általi feldolgozása során a következő memóriablokkot egy másik mag dolgozza fel. Az asztali számítógépre optimalizált RTOS, például a Unison Operating System vagy a DSPnano RTOS biztosítja ezt a lehetőséget.
| Valós idejű operációs rendszerek | |
|---|---|
| |
| nyisd ki | |
| Szabadalmazott |
|
| történelmi |
|
| |
| Az operációs rendszerek szempontjai | |||||
|---|---|---|---|---|---|
| |||||
| Típusok |
| ||||
| Sejtmag |
| ||||
| Folyamatmenedzsment _ |
| ||||
| Memóriakezelés és címzés | |||||
| Betöltési és inicializálási eszközök | |||||
| Héj | |||||
| Egyéb | |||||
| Kategória Wikimedia Commons Wikikönyvek Wikiszótár | |||||