Real-time operativsystem ( RTOS , engelsk real-time operativsystem, RTOS ) er en type specialiseret operativsystem , hvis hovedformål er at levere det nødvendige og tilstrækkelige sæt funktioner til design, udvikling og drift af real-time operativsystem. tidssystemer på specifikt hardwareudstyr.
UNIX-specifikationen, revision 2, definerer:
Realtid i operativsystemer er operativsystemets evne til at levere det krævede serviceniveau i en bestemt periode. [en]
Originaltekst (engelsk)[ Visskjule] Realtid i operativsystemer: styresystemets evne til at levere et påkrævet serviceniveau inden for en begrænset responstid. [2]Den ideelle RTOS har forudsigelig adfærd under alle belastningsscenarier, inklusive samtidige afbrydelser og trådudførelse [3] .
Realtidsoperativsystemer er nogle gange opdelt i to typer - hårde realtidssystemer og bløde realtidssystemer [4] .
Et operativsystem, der kan give den nødvendige udførelsestid til en realtidsopgave selv i de værste tilfælde, kaldes et hårdt realtidsoperativsystem . Et system, der i gennemsnit kan levere den nødvendige udførelsestid til en realtidsopgave, kaldes et blødt realtidsoperativsystem .
Hårde realtidssystemer tillader ikke forsinkelser i systemets respons, da dette kan føre til tab af relevans af resultaterne, store økonomiske tab eller endda ulykker og katastrofer. En situation, hvor hændelsesbehandling finder sted ud over den tilladte tid, betragtes som en fatal fejl i et hårdt realtidssystem. Når en sådan situation opstår, afbryder operativsystemet operationen og blokerer den, så pålideligheden og tilgængeligheden af resten af systemet så vidt muligt ikke påvirkes. Eksempler på hårde realtidssystemer kan være kontrolsystemer om bord (på et fly, rumfartøj, skib osv.), nødbeskyttelsessystemer, nødoptagere [5] .
I et blødt realtidssystem betragtes svarforsinkelse som en genskabelig fejl, der kan øge omkostningerne ved resultater og reducere ydeevnen, men som ikke er fatal. Et eksempel er driften af et computernetværk [6] . Hvis systemet ikke havde tid til at behandle den næste modtagne pakke, vil dette føre til et stop på sendesiden og genafsendelse (afhængigt af protokollen ). Ingen data går tabt, men netværkets ydeevne er forringet.
Den største forskel mellem hårde og bløde realtidssystemer kan beskrives som følger: et hårdt realtidssystem vil aldrig komme for sent med en reaktion på en hændelse, et blødt realtidssystem bør ikke være forsinket med en reaktion på en hændelse [6] .
Ofte betragtes et realtidsoperativsystem kun som et system, der kan bruges til at løse hårde realtidsproblemer. Denne definition betyder, at RTOS'en har de nødvendige værktøjer, men betyder også, at disse værktøjer skal bruges korrekt [5] .
Det meste software er orienteret mod blød realtid. Sådanne systemer er kendetegnet ved:
Et klassisk eksempel på en opgave, hvor en RTOS er påkrævet, er styringen af en robot , der tager en del fra et transportbånd . Delen bevæger sig, og robotten har kun et lille tidsrum, hvor den kan samle den op. Hvis det er for sent, vil delen ikke længere være i den korrekte sektion af transportøren, og derfor vil arbejdet ikke blive udført, på trods af at robotten er på det rigtige sted. Hvis han forbereder sig tidligere, har delen ikke tid til at køre op endnu, og han vil blokere dens vej.
Også for operativsystemer bruges begrebet " interaktiv realtid " nogle gange, som definerer minimumstærsklen for at reagere på hændelser i den grafiske grænseflade, hvor operatøren - en person - er i stand til roligt, uden nervøsitet, at vente på systemet til at reagere på de instruktioner, de får.
Tabel, der sammenligner RTOS og konventionelle operativsystemer [5] :
| OS i realtid | OS til generelle formål | |
|---|---|---|
| Hovedopgaven | Formå at reagere på hændelser, der opstår på udstyret | Optimal fordeling af computerressourcer mellem brugere og opgaver |
| Hvad er det fokuseret på | Håndtering af eksterne begivenheder | Håndtering af brugerhandlinger |
| Hvordan er den placeret | Et værktøj til at skabe et specifikt hardware-softwarekompleks i realtid | Opfattes af brugeren som et sæt applikationer klar til brug |
| Hvem er tiltænkt | Kvalificeret udvikler | Mellembruger |
I deres udvikling blev RTOS bygget på basis af følgende arkitekturer :
| Monolitisk arkitektur | Lagdelt (lagdelt) arkitektur | Klient-server arkitektur |
RTOS-kernen sørger for funktionen af det mellemliggende abstrakte OS-niveau, som skjuler detaljerne for processorens tekniske enhed (flere processorer) og tilhørende hardware fra applikationssoftwaren [7] .
Dette abstrakte lag giver fem hovedkategorier af tjenester til applikationssoftware [7] [8] :
Ud over kernetjenester tilbyder mange RTOS linjer af tilføjelseskomponenter til at organisere koncepter på højt niveau som filsystem , netværk, netværksstyring, databasestyring , grafisk brugergrænseflade osv. Selvom mange af disse komponenter er meget større og mere komplekse, end selve RTOS-kernen, er de ikke desto mindre baseret på dens tjenester. Hver af disse komponenter er kun inkluderet i det indlejrede system, hvis dets tjenester er nødvendige for at køre den indlejrede applikation, og kun for at holde hukommelsesforbruget på et minimum [7] .
Mange generelle operativsystemer understøtter også ovenstående tjenester. Imidlertid er den vigtigste forskel mellem RTOS-kernetjenester den deterministiske , baseret på streng tidskontrol, karakteren af deres arbejde. I dette tilfælde forstås determinisme som det faktum, at udførelsen af en tjeneste i operativsystemet kræver et tidsinterval af kendt varighed. Teoretisk set kan denne tid beregnes ved hjælp af matematiske formler , som bør være strengt algebraiske og ikke bør indeholde nogen tidsparametre af tilfældig karakter. Enhver tilfældig variabel , der bestemmer udførelsestiden for en opgave i RTOS'en, kan forårsage en uønsket forsinkelse i applikationen, så vil den næste opgave ikke passe ind i dens tidskvante, hvilket vil forårsage en fejl [7] .
I denne forstand er operativsystemer til generelle formål ikke deterministiske. Deres tjenester kan tillade tilfældige forsinkelser i deres arbejde, hvilket kan føre til en opbremsning i applikationens respons på brugerhandlinger på et kendt ukendt tidspunkt. Ved design af konventionelle operativsystemer fokuserer udviklere ikke på det matematiske apparat til beregning af eksekveringstiden for en specifik opgave og tjeneste. Dette er ikke kritisk for denne type systemer [7] .
De fleste RTOS udfører opgaveplanlægning i henhold til følgende skema [7] . Hver opgave i applikationen tildeles en vis prioritet. Jo højere prioritet, jo højere reaktivitet bør opgaven være. Høj reaktivitet opnås ved at implementere en forebyggende prioritetsplanlægningstilgang, hvis essens er, at planlæggeren har lov til at stoppe udførelsen af enhver opgave på et vilkårligt tidspunkt, hvis det bestemmes, at en anden opgave skal startes med det samme.
Det beskrevne skema fungerer i henhold til følgende regel: hvis to opgaver er klar til at køre på samme tid, men den første har en høj prioritet, og den anden har en lav, så vil planlæggeren give fortrinsret til den første . Den anden opgave vil først blive lanceret, når den første er færdig med sit arbejde.
Det er muligt, at en opgave med lav prioritet allerede kører, og planlæggeren modtager en besked om, at en anden opgave med højere prioritet er klar til at køre. Dette kan være forårsaget af en vis ekstern påvirkning (hardwareafbrydelse), såsom en skiftetilstandsændring på en enhed styret af RTOS. I en sådan situation vil opgaveplanlæggeren opføre sig i overensstemmelse med den prioriterede forebyggende planlægningstilgang som følger. En opgave med lav prioritet vil få lov til at fuldføre den aktuelle maskininstruktion (men ikke instruktionen beskrevet i programkilden på højt niveau ), hvorefter udførelsen af opgaven suspenderes [7] . Dernæst igangsættes en opgave med høj prioritet. Når den er færdig, starter planlæggeren den afbrudte første opgave med maskininstruktionen efter den sidst udførte.
Hver gang opgaveplanlæggeren modtager et signal om forekomsten af en ekstern hændelse (trigger), hvis årsag kan være både hardware og software, handler den i henhold til følgende algoritme [7] :
Disse fem trin i algoritmen kaldes også opgaveskift.
I konventionel RTOS kan en opgave være i tre mulige tilstande:
Det meste af tiden er de fleste af opgaverne blokeret. Kun én opgave kan køre på CPU'en på et givet tidspunkt. I primitiv RTOS er listen over opgaver klar til udførelse normalt meget kort, den kan ikke bestå af mere end to eller tre elementer.
RTOS-administratorens hovedfunktion er at kompilere en sådan opgaveplanlægger.
Hvis der ikke er mere end to eller tre opgaver på listen over de sidste opgaver klar til udførelse, så antages det, at alle opgaver er placeret i den optimale rækkefølge. Hvis der er situationer, hvor antallet af opgaver på listen overstiger den tilladte grænse, så sorteres opgaverne i prioriteret rækkefølge.
I øjeblikket, for at løse problemet med effektiv planlægning i RTOS, er to tilgange mest intensivt udviklet [9] :
For store systembelastninger er EDF mere effektiv end RMS.
Multitasking-systemer skal distribuere adgang til ressourcer. Samtidig adgang til to eller flere processer til ethvert hukommelsesområde eller andre ressourcer udgør en vis trussel. Der er tre måder at løse dette problem på: midlertidig blokering af interrupts , binære semaforer , afsendelse af signaler. RTOS bruger normalt ikke den første måde, fordi brugerapplikationen ikke kan kontrollere processoren så meget, som den ønsker. Mange indlejrede systemer og RTOS'er tillader dog, at applikationer kører i kernetilstand for at få adgang til systemkald og styre eksekveringsmiljøet uden OS-intervention.
På uniprocessor-systemer er den bedste løsning et program, der kører i kernetilstand, som har lov til at blokere afbrydelser. Mens afbrydelsen er deaktiveret, bruger applikationen processens ressourcer alene, og ingen anden opgave eller afbrydelse kan køre. Dermed er alle kritiske ressourcer beskyttet. Efter at applikationen har gennemført kritiske aktiviteter, skal den aktivere eventuelle afbrydelser. Blokering af interrupt er kun tilladt, når den længste kritiske sektions udførelsestid er mindre end den tilladte interrupt-svartid. Typisk bruges denne beskyttelsesmetode kun, når længden af den kritiske kode ikke overstiger et par linjer og ikke indeholder sløjfer . Denne metode er ideel til at beskytte registre .
Når den kritiske sektionslængde er større end den maksimale længde eller indeholder cyklusser, skal programmøren bruge mekanismer, der er identiske med eller efterligner opførselen af generelle systemer, såsom semaforer og signalering.
Følgende problemer med hukommelsesallokering får mere opmærksomhed i RTOS end i generelle operativsystemer.
For det første hastigheden af hukommelsesallokering. Standardhukommelsesallokeringsskemaet involverer scanning af en liste af ubestemt længde for at finde et ledigt hukommelsesområde af en given størrelse, og dette er uacceptabelt, da hukommelsesallokering i en RTOS skal ske inden for en fast tid.
For det andet kan hukommelsen blive fragmenteret, hvis dens frie områder er opdelt af allerede kørende processer. Dette kan få programmet til at stoppe på grund af dets manglende evne til at bruge den nye hukommelsesplacering. En hukommelsesallokeringsalgoritme, der gradvist øger hukommelsesfragmenteringen, kan fungere godt på desktopsystemer, hvis de genstarter mindst en gang om måneden, men er uacceptabel for indlejrede systemer, der kører i årevis uden at genstarte.
En simpel algoritme med en fast længde af hukommelsesblokke fungerer meget godt i simple indlejrede systemer.
Denne algoritme fungerer også godt på desktop-systemer, især når den næste hukommelsesblok under behandlingen af en hukommelsesblok af en kerne behandles af en anden kerne. Desktop-optimeret RTOS såsom Unison Operating System eller DSPnano RTOS giver denne mulighed.
| Realtids operativsystemer | |
|---|---|
| |
| åben | |
| Proprietære |
|
| historisk |
|
| |
| Aspekter af operativsystemer | |||||
|---|---|---|---|---|---|
| |||||
| Typer |
| ||||
| Nucleus |
| ||||
| Procesledelse _ |
| ||||
| Hukommelseshåndtering og adressering | |||||
| Indlæsnings- og initialiseringsværktøjer | |||||
| skal | |||||
| Andet | |||||
| Kategori Wikimedia Commons Wikibooks Wiktionary | |||||