Realtidsoperativsystem ( RTOS , engelska realtidsoperativsystem, RTOS ) är en typ av specialiserat operativsystem , vars huvudsakliga syfte är att tillhandahålla den nödvändiga och tillräckliga uppsättningen funktioner för design, utveckling och drift av real- tidssystem på specifik hårdvaruutrustning.
UNIX-specifikationen, version 2, definierar:
Realtid i operativsystem är operativsystemets förmåga att tillhandahålla den nödvändiga servicenivån under en viss tidsperiod. [ett]
Originaltext (engelska)[ visaDölj] Realtid i operativsystem: operativsystemets förmåga att tillhandahålla en nödvändig servicenivå inom en begränsad svarstid. [2]Den ideala RTOS har förutsägbart beteende under alla belastningsscenarier, inklusive samtidiga avbrott och trådexekvering [3] .
Realtidsoperativsystem delas ibland in i två typer - hårda realtidssystem och mjuka realtidssystem [4] .
Ett operativsystem som kan ge den erforderliga exekveringstiden för en realtidsuppgift även i de värsta fallen kallas ett hårt realtidsoperativsystem . Ett system som i genomsnitt kan ge den nödvändiga exekveringstiden för en realtidsuppgift kallas ett mjukt realtidsoperativsystem .
Hårda realtidssystem tillåter inte förseningar i systemets svar, eftersom detta kan leda till förlust av relevans för resultaten, stora ekonomiska förluster eller till och med olyckor och katastrofer. En situation där händelsebearbetning sker efter den tillåtna tiden anses vara ett fatalt fel i ett hårt realtidssystem. När en sådan situation uppstår avbryter operativsystemet operationen och blockerar den så att tillförlitligheten och tillgängligheten för resten av systemet inte påverkas så långt det är möjligt. Exempel på hårda realtidssystem kan vara styrsystem ombord (på ett flygplan, rymdfarkost, fartyg, etc.), nödskyddssystem, nödhändelseregistratorer [5] .
I ett mjukt realtidssystem anses svarsfördröjning vara ett återställbart fel som kan öka kostnaden för resultat och minska prestanda, men som inte är dödligt. Ett exempel är driften av ett datornätverk [6] . Om systemet inte hade tid att bearbeta nästa mottagna paket kommer detta att leda till ett stopp på sändningssidan och återsändning (beroende på protokoll ). Ingen data går förlorad, men nätverkets prestanda försämras.
Huvudskillnaden mellan hårda och mjuka realtidssystem kan beskrivas på följande sätt: ett hårt realtidssystem kommer aldrig att vara sent med en reaktion på en händelse, ett mjukt realtidssystem ska inte vara sent med en reaktion på en händelse [6] .
Ofta anses ett realtidsoperativsystem endast vara ett system som kan användas för att lösa svåra realtidsproblem. Denna definition innebär att RTOS har de nödvändiga verktygen, men betyder också att dessa verktyg måste användas korrekt [5] .
De flesta program är inriktade på mjuk realtid. Sådana system kännetecknas av:
Ett klassiskt exempel på en uppgift där en RTOS krävs är styrningen av en robot som tar en del från ett transportband . Delen rör sig och roboten har bara ett litet tidsfönster när den kan plocka upp den. Om det är sent, kommer delen inte längre att vara i rätt sektion av transportören, och därför kommer arbetet inte att utföras, trots att roboten är på rätt plats. Om han förbereder sig tidigare, kommer delen inte att ha tid att köra upp ännu, och han kommer att blockera dess väg.
För operativsystem används ibland begreppet " interaktiv realtid ", som definierar den lägsta tröskeln för att svara på händelser i det grafiska gränssnittet, under vilken operatören - en person - kan lugnt, utan nervositet, vänta på systemet att reagera på de instruktioner som ges till dem.
Tabell som jämför RTOS och konventionella operativsystem [5] :
| realtids OS | OS för allmänna ändamål | |
|---|---|---|
| Huvuduppgiften | Hantera att svara på händelser som inträffar på utrustningen | Optimal fördelning av datorresurser mellan användare och uppgifter |
| Vad är det fokuserat på | Hantering av externa händelser | Hantera användaråtgärder |
| Hur är den placerad | Ett verktyg för att skapa ett specifikt maskin- och mjukvarukomplex i realtid | Uppfattas av användaren som en uppsättning applikationer redo att användas |
| Vem är tänkt | Kvalificerad utvecklare | Mellanvändare |
I sin utveckling byggdes RTOS på basis av följande arkitekturer :
| Monolitisk arkitektur | Tiered (skiktad) arkitektur | Klient-server-arkitektur |
RTOS-kärnan tillhandahåller funktionen hos den mellanliggande abstrakta OS-nivån, som döljer från applikationsmjukvaran specifikationerna för den tekniska enheten för processorn (flera processorer) och tillhörande hårdvara [7] .
Detta abstrakta lager tillhandahåller fem huvudkategorier av tjänster för tillämpningsprogram [7] [8] :
Förutom kärntjänster erbjuder många RTOS rader av tilläggskomponenter för att organisera sådana högnivåkoncept som filsystem , nätverk, nätverkshantering, databashantering , grafiskt användargränssnitt , etc. Även om många av dessa komponenter är mycket större och fler komplexa, än själva RTOS-kärnan, är de ändå baserade på dess tjänster. Var och en av dessa komponenter ingår i det inbäddade systemet endast om dess tjänster behövs för att köra den inbäddade applikationen, och endast för att hålla minnesförbrukningen till ett minimum [7] .
Många generella operativsystem stöder även ovanstående tjänster. Den viktigaste skillnaden mellan RTOS kärntjänster är dock den deterministiska karaktären av deras arbete, baserat på strikt tidskontroll. I detta fall förstås determinism som det faktum att exekveringen av en tjänst i operativsystemet kräver ett tidsintervall av en känd varaktighet. Teoretiskt kan denna tid beräknas med matematiska formler , som bör vara strikt algebraiska och inte bör inkludera några tidsparametrar av slumpmässig karaktär. Varje slumpvariabel som bestämmer exekveringstiden för en uppgift i RTOS kan orsaka en oönskad fördröjning i applikationen, då kommer nästa uppgift inte att passa in i dess tidskvantum, vilket kommer att orsaka ett fel [7] .
I denna mening är generella operativsystem inte deterministiska. Deras tjänster kan tillåta slumpmässiga förseningar i deras arbete, vilket kan leda till en avmattning i applikationens svar på användaråtgärder vid en känd okänd tidpunkt. När man designar konventionella operativsystem fokuserar utvecklarna inte på den matematiska apparaten för att beräkna exekveringstiden för en specifik uppgift och tjänst. Detta är inte kritiskt för denna typ av system [7] .
De flesta RTOS utför uppgiftsschemaläggning enligt följande schema [7] . Varje uppgift i applikationen tilldelas en viss prioritet. Ju högre prioritet, desto högre reaktivitet bör uppgiften vara. Hög reaktivitet uppnås genom att implementera en förebyggande prioritetsschemaläggningsmetod, vars essens är att schemaläggaren tillåts stoppa exekveringen av vilken uppgift som helst vid en godtycklig tidpunkt om det bestäms att en annan uppgift ska startas omedelbart.
Det beskrivna schemat fungerar enligt följande regel: om två uppgifter är redo att köras samtidigt, men den första har hög prioritet och den andra har en låg, kommer schemaläggaren att ge företräde åt den första . Den andra uppgiften kommer att lanseras först efter att den första har slutfört sitt arbete.
Det är möjligt att en aktivitet med låg prioritet redan körs och schemaläggaren får ett meddelande om att en annan uppgift med högre prioritet är redo att köras. Detta kan orsakas av viss extern påverkan (maskinvaruavbrott), såsom en växlingslägesändring på en enhet som styrs av RTOS. I en sådan situation kommer uppgiftsschemaläggaren att bete sig enligt den prioriterade förebyggande schemaläggningsmetoden enligt följande. En uppgift med låg prioritet kommer att tillåtas slutföra den aktuella maskininstruktionen (men inte den instruktion som beskrivs i programkällan på högnivåspråk ), varefter utförandet av uppgiften avbryts [7] . Därefter lanseras en uppgift med hög prioritet. När den är klar startar schemaläggaren den avbrutna första uppgiften med maskininstruktionen efter den senast körda.
Varje gång uppgiftsschemaläggaren får en signal om förekomsten av någon extern händelse (trigger), vars orsak kan vara både hårdvara och mjukvara, agerar den enligt följande algoritm [7] :
Dessa fem steg i algoritmen kallas även uppgiftsväxling.
I konventionell RTOS kan en uppgift vara i tre möjliga tillstånd:
För det mesta är de flesta av uppgifterna blockerade. Endast en uppgift kan köras på processorn vid en given tidpunkt. I primitiv RTOS är listan över uppgifter redo att utföras vanligtvis mycket kort, den kan inte bestå av mer än två eller tre poster.
Huvudfunktionen för RTOS-administratören är att kompilera en sådan uppgiftsschemaläggare.
Om det inte finns mer än två eller tre uppgifter i listan över de sista uppgifterna som är klara för utförande, antas det att alla uppgifter är placerade i optimal ordning. Om det finns situationer när antalet uppgifter i listan överskrider den tillåtna gränsen, sorteras uppgifterna i prioritetsordning.
För närvarande, för att lösa problemet med effektiv planering i RTOS, utvecklas två tillvägagångssätt mest intensivt [9] :
För stora systembelastningar är EDF effektivare än RMS.
Multitasking-system måste distribuera åtkomst till resurser. Samtidig åtkomst av två eller flera processer till valfritt minnesområde eller andra resurser utgör ett visst hot. Det finns tre sätt att lösa detta problem: tillfällig blockering av avbrott , binära semaforer , sändning av signaler. RTOS använder vanligtvis inte det första sättet eftersom användarapplikationen inte kan styra processorn så mycket som den vill. Många inbyggda system och RTOS tillåter dock att applikationer körs i kärnläge för att få åtkomst till systemanrop och styra exekveringsmiljön utan OS-intervention.
På enprocessorsystem är den bästa lösningen en applikation som körs i kärnläge som tillåts blockera avbrott. Medan avbrottet är inaktiverat använder programmet bara processens resurser och ingen annan uppgift eller avbrott kan köras. Därmed skyddas alla kritiska resurser. Efter att applikationen har slutfört kritiska aktiviteter måste den möjliggöra eventuella avbrott. Avbrottsblockering är endast tillåten när den längsta kritiska sektionsexekveringstiden är kortare än den tillåtna avbrottssvarstiden. Vanligtvis används denna skyddsmetod endast när längden på den kritiska koden inte överstiger några rader och inte innehåller loopar . Denna metod är idealisk för att skydda register .
När den kritiska sektionslängden är större än den maximala längden eller innehåller cykler måste programmeraren använda mekanismer som är identiska med eller efterliknar beteendet hos generella system, såsom semaforer och signalering.
Följande minnesallokeringsproblem ägnas mer uppmärksamhet i RTOS än i generella operativsystem.
Först, hastigheten för minnesallokering. Standardminnestilldelningsschemat innebär att man skannar en lista med obestämd längd för att hitta ett ledigt minnesområde av en given storlek, och detta är oacceptabelt, eftersom minnesallokering i en RTOS måste ske inom en fast tid.
För det andra kan minnet bli fragmenterat om dess fria områden delas av processer som redan körs. Detta kan göra att programmet stoppas på grund av dess oförmåga att använda den nya minnesplatsen. En minnesallokeringsalgoritm som gradvis ökar minnesfragmenteringen kan fungera bra på stationära system om de startar om minst en gång i månaden, men är oacceptabelt för inbyggda system som körs i flera år utan att starta om.
En enkel algoritm med en fast längd på minnesblock fungerar mycket bra i enkla inbyggda system.
Den här algoritmen fungerar också bra på skrivbordssystem, speciellt när, under bearbetningen av ett minnesblock av en kärna, nästa minnesblock bearbetas av en annan kärna. Desktop-optimerad RTOS som Unison Operating System eller DSPnano RTOS ger denna möjlighet.
| Operativsystem i realtid | |
|---|---|
| |
| öppna | |
| Proprietär |
|
| historisk |
|
| |
| Aspekter av operativsystem | |||||
|---|---|---|---|---|---|
| |||||
| Typer |
| ||||
| Kärna |
| ||||
| Processledning _ |
| ||||
| Minneshantering och adressering | |||||
| Ladda och initieringsverktyg | |||||
| Skal | |||||
| Övrig | |||||
| Kategori Wikimedia Commons Wikibooks Wiktionary | |||||