Know-how, előadás, mobil robot automatizált irányítása

7.1. Bevezetés: A valós idejű operációs rendszerek jellemzői

Ha valódi mozgó eszközökkel dolgozunk (ami lényegében egy robot), akkor szembe kell néznünk azzal, hogy a lehető leggyorsabban reagálunk a külső eseményekre. A probléma megoldásához speciális operációs rendszerek léteznek.

A valós idejű operációs rendszerek (RTOS) úgy lettek kialakítva, hogy felületet biztosítsanak az idő kritikus valós idejű rendszerek erőforrásainak. Az ilyen rendszerek fő feladata az adatok feldolgozásának időszerűsége.

Az RTOS alapvető követelménye, hogy a legrosszabb külső körülmények között biztosítsa a rendszer viselkedésének kiszámíthatóságát vagy determinizmusát, ami élesen eltér az általános operációs rendszer teljesítményétől és sebességétől. A jó RTOS-nak előre látható viselkedése van minden rendszerindítási forgatókönyv esetén (egyidejű megszakítások és menetvágás).

Van némi különbség a valós idejű rendszerek és a beágyazott rendszerek között. A beépített rendszer nem mindig követeli meg a kiszámítható viselkedést, és ebben az esetben nem valós idejű rendszer. Az esetleges beágyazott rendszerek áttekintése azonban lehetővé teszi számunkra, hogy kijelentjük, hogy a legtöbb beágyazott rendszernek kiszámítható viselkedésre van szüksége, legalábbis bizonyos funkcionalitásokhoz, így ezek a rendszerek valós idejű rendszerekhez kapcsolódhatnak.

Általában különbséget kell tenni a puha és kemény valós idejű rendszerek között. A kemény valós idejű rendszereknél az a tény, hogy egy adott időpontban nem lehet reagálni bármely eseményre, hibákat és a feladat megvalósításának képtelenségét eredményezi. A legtöbb orosz irodalomban az ilyen rendszereket determinisztikus idővel rendelkező rendszereknek hívják. Gyakorlati használatban a reakcióidő minimális. A lágy, valós idejű rendszerek olyan rendszerek, amelyek nem tartoznak a "kemény", tk. a szakirodalomban még nincs egyértelmű meghatározás. A puha, valós idejű rendszereknek nincs ideje megoldani a problémát, de ez nem vezet a rendszer egészének hiányához. A valós idejű rendszereknél szükség van néhány irányelv kifejezés bevezetésére (az angol nyelvű szakirodalomban - a határidőre), amelynek lejárata előtt a feladatot (lehetőleg a puha, valós idejű rendszereknél) kell elvégezni. Ezt az ütemezési időszakot a feladatütemező használhatja mind a prioritás hozzárendeléséhez a feladathoz, amikor elindul, vagy egy végrehajtandó feladat kiválasztásakor.

• Az operációs rendszernek többfeladatosnak és elővigyázatosnak (preemptable) kell lennie,
• Az operációs rendszernek meg kell felelnie a szálak elsőbbségének,
• Az operációs rendszernek támogatnia kell a kiszámítható szinkronizációs mechanizmusokat,
• Az operációs rendszernek biztosítania kell a prioritások öröklésének mechanizmusát,
• az operációs rendszer viselkedésének ismernie és kiszámíthatónak kell lennie (késedelem a megszakítások feldolgozásában, a feladatkapcsolási késedelmek, a vezetők késései stb.); ez azt jelenti, hogy a rendszer munkaterhelésének minden forgatókönyvében meg kell határozni a maximális válaszidőt.

Az elmúlt 25-30 évben az operációs rendszerek struktúrája egy monolitikus, egy többrétegű operációs rendszer struktúrájából és egy ügyfél-kiszolgáló architektúrájából alakult ki. Egy monolitikus struktúrával az operációs rendszer modulokból áll, és az egyik modullal kapcsolatos változások hatással vannak más modulokra. Minél több modul van, annál nagyobb a káosz egy ilyen rendszer működésében. Továbbá lehetetlen az operációs rendszert többprocesszoros rendszerben is elosztani. Egy többrétegű struktúrában az egyik rétegben bekövetkezett változások a szomszédos rétegeket érintik; ráadásul a réteggel történő kezelés nem lehetséges. A valós idejű rendszerekhez közvetlen hozzáférést kell biztosítani az egyes operációs rendszerrétegekhez, és néha közvetlenül a hardverhez.

Az operációs rendszer kliens-kiszolgáló technológiájának fő elgondolása az operációs rendszer alapjainak minimálisra csökkentése (ütemező és szinkronizációs primitívek). Minden más funkciót egy másik szintre hoznak és szálakkal vagy feladatokkal valósítják meg. Az ilyen kiszolgálói feladatok teljes száma felelős a rendszerhívásokért. Az alkalmazások olyan ügyfelek, amelyek szolgáltatásokat kérnek rendszerhívásokon keresztül.

Az ügyfél-kiszolgáló technológia lehetővé teszi skálázható operációs rendszerek létrehozását és egyszerűsíti az elosztást egy többprocesszoros rendszerben. A rendszer használata során az egyik modul cseréje nem okoz hógolyó hatását; Ezenkívül a modul meghibásodása nem mindig okoz rendszerhibát. Volt lehetőség a modulok dinamikus betöltésére és szállítására. A fő probléma ebben a modellben a memória védelme. Mivel a szerverfolyamatokat védeni kell. Minden alkalommal, amikor a szolgáltatást kérték, a rendszernek át kell térnie az alkalmazás környezetéről a szerver környezetére. A memóriavédelem támogatásával megnő a kapcsolási idő egy folyamatból a másikba.

Rendszerint a modern RTOS többsége egy mikrokernel (kernel vagy nucleus) alapján épül fel, amely ütemezési és feladási feladatokat biztosít, és kölcsönhatásba lép. Az operációs rendszer absztrakcióinak minimalizálása ellenére a mikrokernelnek még el kell képzelnie a folyamat absztrakcióját. Az operációs rendszerek minden más fogalmi absztrakciója ki van kapcsolva a rendszermagból, igény szerint igényelnek és alkalmazásként hajtják végre.

Tekintse meg az operációs rendszer fogalmi absztrakcióit a valós idejű rendszerek követelményeinek prizmáján keresztül.

7.2. Folyamatok, folyamatok, feladatok

Tehát a valós idejű rendszerekben a folyamat feladatokra vagy szálakra bomlik. Mindenesetre minden folyamatot alkalmazásként kezelnek. Az alkalmazások között nem szabad túl sok interakciót végezni, és a legtöbb esetben eltérő természetű - kemény valós idejű, puha valós idő, nem valós idő.

7.3. Tervezés, prioritások

A határidők problémájával kapcsolatban az RTOS fő problémája az ütemezés, amely minden körülmények között biztosítja a rendszer kiszámítható viselkedését. A határidővel járó folyamatot el kell kezdeni és végre kell hajtani, hogy ne maradjon le a határidők közül. Ha ez nem lehetséges, akkor a folyamatot el kell utasítani.

Az RTOS tervezési problémáival kapcsolatban két megközelítést tanulmányoznak és fejlesztenek: a statikus ütemezési algoritmusokat (RMS) és a dinamikus tervezési algoritmusokat (EDF-Earliest Deadline First).

Az RMS-t arra használják, hogy hivatalosan bizonyítsa a rendszer kiszámíthatóságát. Ennek az elméletnek a megvalósításához meg kell tervezni a megelőző prioritási ütemezés alapján. Az RMS elméletben minden egyes folyamat előtt prioritást kapunk. A folyamatoknak az alábbi feltételeknek kell megfelelniük:

• a folyamatot időtartamuk alatt be kell fejezni,
• a folyamatok nem függenek egymástól,
• mindegyik folyamatnak meg kell felelnie ugyanazon CPU időnek minden intervallumban,
• nem periodikus folyamatokban nincsenek merev kifejezések,
• a folyamat korlátozott ideig megszakad.

A folyamatokat a prioritásoknak megfelelően végzik. Az RMS tervezésekor előnyben részesítik a legrövidebb végrehajtási periódusú feladatokat.

Az EDF-ben a prioritás dinamikusan van kijelölve, és a legmagasabb prioritás a legrövidebb végrehajtási idővel rendelkező folyamat. Nagy rendszerterhelések esetén az EDF előnyökkel rendelkezik az RMS-nél.

Minden valós idejű rendszerhez tervezési politika szükséges. a határidőkkel kezelt -driven scheduling. Ez a megközelítés azonban folyamatban van.

Általában az RTOS az ütemezést használja az olyan prioritásokkal, amelyek megszakítják a szolgáltatást, amely az RMS-en alapul. Az elsőbbségi szolgáltatás megszakítása (preemption) az RTOS szerves része. egy valós idejű rendszerben garantálni kell, hogy egy kiemelt fontosságú esemény kerüljön feldolgozásra alacsonyabb prioritási esemény előtt. Mindez arra a tényre vezet, hogy az RTOS-nak nem csak a karbantartást megszakító prioritásokon alapuló ütemezési mechanizmusra, hanem a megfelelő megszakításvezérlő mechanizmusra is szüksége van. Ezenkívül az RTOS-nak képesnek kell lennie arra, hogy megakadályozza a megszakításokat, ha szükséges olyan kritikus kód végrehajtása, amely nem szakítható meg. A megszakítás feldolgozásának hosszát minimálisra kell csökkenteni.

Az RTOS-nak fejlett prioritási rendszerrel kell rendelkeznie. Először is azért van szükség, mert maga a rendszer tekinthető szálakra osztott kiszolgálóalkalmazások készletének, és több magas prioritású szintet kell felosztani a rendszerfolyamatokhoz és a szálakhoz. Másodszor, nehéz üzemi kell minden élő közvetítés elhelyezni a különböző prioritási szintek és a forgalom nem valós idejű, hogy ugyanazon a szinten (kisebb, mint bármely valós idejű lejátszás). Ha ez az áramlás nem lehet feldolgozni valós időben körmérkőzéses ütemezett (RRS - round-robin ütemezés), ahol minden egyes folyamat egy kvantum CPU-időt, és amikor a kvantum leállítja a folyamatot összefüggésben van mentve, és ez kerül a sorban. Sok RTOS-ban az RRS-t a feladatok ugyanazon a szinten történő ütemezésére használják. A 0 elsőbbségi szintet általában készenléti üzemmódban használják.

A prioritások alapján történő tervezés során két kötelező problémát kell megoldani:

• Biztosítsa a legmagasabb prioritású folyamat végrehajtását,
• A prioritások inverziójának megakadályozása, amikor a kiemelt feladatokkal rendelkező feladatok az alacsonyabb prioritású feladatok által elfoglalt erőforrásokra várnak.

Az RTOS elsőbbségi inverziójának leküzdése érdekében gyakran használják az elsőbbségi öröklési mechanizmust, de el kell hagynia az RMS alapján történő tervezést. mivel a prioritások dinamikussá válnak.