Et sanntidsoperativsystem er et som er utviklet for sanntidsapplikasjoner . Som sådan er du pålagt å korrigere svarene dine under visse tidsbegrensninger. Hvis du ikke respekterer dem, vil systemet sies å ha feilet. For å garantere riktig oppførsel innen nødvendig tid, må systemet være forutsigbart...
Disse typer systemer brukes vanligvis for innebygde applikasjoner som normalt har følgende egenskaper:
Vanligvis brukt for innebygde applikasjoner, har den vanligvis følgende egenskaper:
Kommunikasjon mellom prosesser støttes på en presis og stabil måte, ved bruk av mekanismer som bruk av semaforer, meldingsoverføring og bruk av delt minne.
Den utfører operasjoner på forhåndsbestemte faste tidspunkter eller innenfor forhåndsbestemte tidsintervaller. Når flere prosesser konkurrerer om ressurser og prosessortid, kan intet system være helt deterministisk. I et sanntidsoperativsystem er tjenesteforespørsler fra prosesser drevet av eksterne hendelser og tidspunkter. I hvilken grad et operativsystem deterministisk kan tilfredsstille forespørsler avhenger for det første av hastigheten som det er i stand til å svare på avbrudd og for det andre av om systemet har tilstrekkelig kapasitet til å håndtere alle forespørsler innenfor systemets nødvendige tid. I ikke-sanntidsoperativsystemer kan denne forsinkelsen være i området fra titalls til hundrevis av millisekunder, mens i et sanntidsoperativsystem kan denne forsinkelsen ha en øvre grense et sted mellom noen få mikrosekunder og et millisekund.
Hvor lang tid det tar før operativsystemet, etter bekreftelse, serverer avbruddet. Reaktivitet inkluderer følgende aspekter: 1. Hvor lang tid som kreves for å innledningsvis håndtere avbruddet og begynne å utføre avbruddsservicerutinen (RSI). Hvis utførelsen av RSI krever en prosessendring, vil forsinkelsen være større enn hvis RSI kan utføres innenfor konteksten av den gjeldende prosessen. 2. Hvor lang tid det tar å utføre RSI. Dette avhenger vanligvis av maskinvareplattformen. 3. Effekten av å avbryte hekking. Hvis en RSI kan bli avbrutt ved ankomst av et annet avbrudd, vil tjenesten bli forsinket. Determinisme og reaktivitet utgjør til sammen responstiden på eksterne hendelser. Krav til responstid er kritiske for sanntidssystemer, siden disse systemene må oppfylle tidskrav pålagt av enkeltpersoner, enheter eller datastrømmer utenfor systemet.
I et ikke-sanntidsoperativsystem har brukeren ingen kontroll over planleggingsfunksjonen, eller operativsystemet kan bare gi grov veiledning, for eksempel å gruppere brukere i mer enn én prioritetsklasse. I et sanntidssystem er det viktig å tillate brukeren finmasket kontroll over oppgaveprioritet. Brukeren må kunne skille mellom harde og myke oppgaver og spesifisere relative prioriteringer innenfor hver klasse. Et sanntidssystem kan også tillate brukeren å spesifisere funksjoner som bruk av personsøking i prosesser, hvilke prosesser som alltid skal ligge i hovedminnet, hvilke diskoverføringsalgoritmer som skal brukes, hvilke rettigheter prosesser har i de ulike prioritetsbåndene. , og så videre.
Et sanntidssystem må reagere og kontrollere hendelser i sanntid. Tap eller forringelse av fordelene kan få katastrofale konsekvenser.
Det refererer til systemets evne til å svikte på en slik måte at det bevarer så mye kapasitet og data som mulig. Et sanntidssystem vil prøve å enten rette opp problemet eller minimere effekten ved å fortsette å kjøre i alle fall. Et sanntidssystem er stabilt hvis, i tilfeller hvor det er umulig å overholde tidsfristene for alle oppgaver, vil systemet overholde tidsfristene for sine høyest prioriterte, mest kritiske oppgaver, selv om fristene for noen mindre kritiske oppgaver ikke vil er fornøyd. For å oppfylle kravene ovenfor inkluderer sanntidsoperativsystemer representativt følgende funksjoner
Det viktigste i et sanntidssystem er den kortsiktige oppgaveplanleggeren. I utformingen av en slik planlegger er rettferdighet og minimering av gjennomsnittlig responstid ikke det viktigste. Det som er viktig er at alle harde sanntidsoppgaver fullføres (eller starter) på deadline, og at så mange myke sanntidsoppgaver som mulig også fullfører (eller starter) på deadline.
Fordel
Et sanntidsoperativsystem er lite, raskt, responsivt og deterministisk. Dette betyr at den vil utføre oppgaver raskt og effektivt, og reagere som forventet hver gang. På grunn av viktigheten av vertsenheten, er RTOS-infrastrukturen sikrere og mindre sannsynlighet for å krasje eller mislykkes. Endelig er en RTOS utviklervendt, noe som betyr at den fortsetter å rulle ut oppdateringer som hjelper brukere med å kode mer effektivt.
Komponenter i et operativsystem
Et operativsystem har tre essensielle komponenter eller programvarepakker som tillater interaksjon med maskinvaren.
Denne typen operativsystemer er ikke nødvendigvis effektive i den forstand at de har høy prosesseringskapasitet. Den spesialiserte planleggingsalgoritmen, og noen ganger en høy klokkeavbruddsfrekvens, kan forstyrre prosessorkraften.
Selv for generelle formål er en moderne prosessor vanligvis raskere, for sanntidsprogrammering bør prosessorer som er så forutsigbare som mulig brukes, uten personsøking. Alle disse faktorene i en prosessor legger til en tilfeldighet som gjør det vanskelig å demonstrere at systemet er levedyktig, det vil si at det oppfyller tidsgrensene for utførelse av oppgaver og oppmerksomheten til tjenester eller avbrudd.
Et sanntidsoperativsystem kan implementeres i mikrokontrollere eller digitale signalprosessorer "DSP-er", og dermed kan innebygde applikasjoner utvikles i forskjellige områder av elektronikk.
Det er to grunnleggende design:
Tidsdelingsdesignet bruker mer CPU-tid på unødvendig oppgavebytte. Det gir imidlertid en bedre illusjon av multitasking . Et system med faste prioriteringer brukes normalt.
En av de vanligste algoritmene for prioritering er Rate-Monotonic Schedule . Hvis settet med oppgaver vi har er gjennomførbart med en fast prioritert oppgave, er det også mulig med Rate-Monotonic Schedule, der den høyest prioriterte oppgaven er den med lavest periode. Dette er ikke å si at hvis det ikke er gjennomførbart med Rate-Monotonic Schedule, er det ikke mulig med variable prioriterte oppdrag. Det kan være slik at vi befinner oss med et levedyktig system med variable prioriteringer og et som ikke er levedyktig med faste prioriteringer.
I typiske design har en oppgave tre tilstander: kjører, klar og blokkert. De fleste oppgavene er blokkert nesten hele tiden. Bare én oppgave per CPU utføres. Listen over forberedte oppgaver er vanligvis kort, to eller tre oppgaver på det meste.
Hovedproblemet er å designe programmereren. Vanligvis er strukturen til klar-å-gjøre-listedataene i planleggeren utformet slik at hvert søk, innsetting og sletting trenger nære avbrudd kun i en veldig liten periode, når svært definerte deler av listen søkes.
Dette betyr at andre oppgaver kan operere på listen asynkront mens den søker. En typisk god timeplan er en toveis koblet liste over klare oppgaver, ordnet i prioritert rekkefølge. Husk at det ikke er raskt å søke, men snarere deterministisk. De fleste klar-å-gjøre-lister har bare to eller tre oppføringer, så et sekvensielt søk er vanligvis det raskeste, fordi det krever svært lite installasjonstid.
Den kritiske responstiden er tiden det tar å sette en ny klar oppgave i kø og gjenopprette statusen til den høyest prioriterte oppgaven.
I et godt utformet sanntidsoperativsystem krever forberedelse av en ny oppgave 3 til 20 instruksjoner for hver oppføring i køen, og gjenoppretting av den forberedte oppgaven med høyest prioritet krever 5 til 30 instruksjoner. På en 68000 20MHz prosessor er oppgavebyttetiden 20 mikrosekunder med to oppgaver klare.
Hundrevis av MIP ARM CPUer kan endres på noen få mikrosekunder.
Sanntidsoperativsystemobjekter er i stand til å dele informasjon og synkronisere utførelsen av oppgaver. De fleste av disse systemene har objekter som:
Ulike oppgaver i et system kan ikke bruke samme data eller fysiske komponenter samtidig. Det er to metoder for å håndtere dette problemet.
En av metodene bruker semaforer. Generelt kan den binære semaforen være lukket eller åpen. Når den er stengt, er det en kø med oppgaver som venter på at semaforen skal åpne.
Problemene med semafordesign er velkjente: prioritert inversjon og vranglås .
Ved prioritetsinversjon venter en oppgave med høy prioritet fordi en annen oppgave med lav prioritet har en semafor. Hvis en oppgave med middels prioritet forhindrer oppgaven med lavere prioritet fra å kjøre, vil den høyere prioriterte oppgaven aldri kjøres. En typisk løsning vil være å gi oppgaven som har semaforen prioritet til den høyest prioriterte oppgaven som venter på den semaforen. Dette kalles den prioriterte grunnleggende arvealgoritmen .
I en vranglås har to oppgaver (T1,T2) til hensikt å tilegne seg to semaforer (semA, semB) i omvendt rekkefølge. I dette tilfellet hvis T1 skaffer semA og T2 skaffer semB når de prøver å få den andre semaforen, vil de ikke kunne gjøre det siden den andre oppgaven har det. På denne måten havner de i en fastlåsning som ingen av de to oppgavene kan komme seg ut av uten ytre innblanding. Dette løses vanligvis med et design, f.eks. tvinge til å tilegne seg semaforene i en bestemt rekkefølge.
Den andre løsningen er at oppgavene sender meldinger til hverandre. Dette har de samme problemene: Reversering av prioritet skjer når en oppgave håndterer en melding med lav prioritet, og ignorerer en melding med høyere prioritet i e-posten. Vålås oppstår når to oppgaver blokkerer sendinger (blir i sendefunksjonen og venter på at mottakeren skal motta meldingen). Hvis T1 sender en melding på en blokkerende måte til T2 og T2 sender en melding på samme måte til T1, vil ingen av de to oppgavene forlate sendefunksjonen, og begge blokkeres siden de ikke vil kunne nå mottaksfunksjonen. Det kan løses ved å omorganisere sendinger og mottak eller ved å bruke ikke-blokkerende eller tidsbestemte sendinger.
Selv om sanntidsatferden deres er noe vanskeligere å analysere enn semaforsystemer, er meldingsbaserte systemer vanligvis lettere å utvikle enn semaforsystemer.
Avbrudd er den vanligste måten å overføre informasjon fra omverdenen til programmet på og er av natur uforutsigbare. I et sanntidssystem kan disse avbruddene rapportere om forskjellige hendelser som tilstedeværelsen av ny informasjon i en kommunikasjonsport, en ny lydprøve i et lydsystem eller en ny bilderamme i en digital videoopptaker.
For at programmet skal oppfylle sitt oppdrag om å være sanntid, er det nødvendig for systemet å ivareta avbruddet og behandle informasjonen som er innhentet før neste avbrudd inntreffer. Siden mikroprosessoren normalt bare kan betjene ett avbrudd om gangen, er det nødvendig for sanntidskontrollerne å kjøre på kortest mulig tid. Dette oppnås ikke ved å behandle signalet inne i avbruddet, men ved å sende en melding til en oppgave eller løse en semafor som blir ventet på av en oppgave. Programmereren er ansvarlig for å aktivere oppgaven, og den er ansvarlig for å innhente informasjonen og fullføre behandlingen.
Tiden som går mellom genereringen av avbruddet og øyeblikket det betjenes kalles avbruddsforsinkelse . Den inverse av denne latensen er en frekvens som kalles metningsfrekvensen , hvis signalene som behandles har en frekvens som er større enn metningsfrekvensen, vil systemet være fysisk ute av stand til å behandle dem. I alle fall er den høyeste frekvensen som kan behandles mye lavere enn metningsfrekvensen og avhenger av operasjonene som må utføres på den mottatte informasjonen.
Det er to problemer med minneallokering i SOTR (sanntidsoperativsystemer).
For det første er leveringshastigheten viktig. Et standard minneallokeringsskjema itererer gjennom en tilkoblet liste med ubestemt lengde for å finne en ledig minneblokk; dette er imidlertid ikke akseptabelt siden minnetildeling må skje på et fast tidspunkt i SOTR.
For det andre kan minnet bli fragmentert når ledige områder kan skilles fra områder som er i bruk. Dette kan føre til at et program krasjer, ikke klarer å få minne, selv om det er teoretisk nok minne. En løsning er å ha en LIFO - lenket liste over minneblokker med fast størrelse. Dette fungerer utrolig bra på et enkelt system.
Personsøking er vanligvis deaktivert i sanntidssystemer, siden det er en ganske tilfeldig og uforutsigbar faktor, som varierer responstiden og ikke lar oss sikre at fristene overholdes, på grunn av overføring av minnesider med en lagringsenhet . ( banking )
De ulike tilnærmingene til planlegging avhenger av 1. når systemet utfører planleggingsanalyse; og hvis det gjør det, 2. om det gjøres statisk eller dynamisk; og 3. hvis resultatet av analysen gir en planleggingsplan i henhold til hvilken oppgavene skal utføres på utførelsestidspunktet. Basert på disse betraktningene identifiseres følgende klasser av algoritmer: • Tabelldrevne statiske tilnærminger. I disse gjennomføres en statisk analyse av gjennomførbarheten av planleggingen. Resultatet av analysen er en tidsplan som bestemmer når, på kjøretid, hver oppgave skal begynne å utføre. • Prioriterte utstøtende statiske tilnærminger. Det utføres også en statisk analyse, men det oppnås ingen planlegging. I stedet brukes analyse for å prioritere oppgaver, og dermed kan en tradisjonell prioritetsbasert push-planlegger brukes. • Dynamiske tilnærminger basert på en plan. Gjennomførbarhet bestemmes ved kjøring (dynamisk) i stedet for før kjøring starter (statisk). En ny oppgave vil bli akseptert som kjørbar bare hvis tidsbegrensningene kan tilfredsstilles. Et av resultatene fra mulighetsanalysen er en plan som skal brukes til å bestemme når oppgaven skal startes. • Dynamiske best-innsats-tilnærminger. Mulighetsanalyse utføres ikke. Systemet prøver å overholde alle frister og avbryter gjennomføringen av enhver prosess hvis fristen har sviktet.
2.1) Tabelldrevet statisk planlegging. Gjelder for oppgaver som er periodiske. Inndataene for analysen er: periodisk ankomsttid, utførelsestid, periodisk fullføringstid og relativ prioritet for hver oppgave. Planleggeren prøver å finne en plan som gjør at den oppfyller alle kravene til alle tilbakevendende oppgaver. Dette er en forutsigbar, men ikke fleksibel tilnærming, en endring i noen av oppgavekravene krever å gjøre om hele planleggingen. Planleggingsalgoritmer: nærmeste frist først, periodiske fristteknikker. 2.2) Statisk planlegging med utkast rettet etter prioritet. Den benytter seg av den prioritetsdrevne utdrivende planleggingsmekanismen, fig. 2. I et sanntidssystem er tildelingen av prioriteter relatert til tidsbegrensningene knyttet til hver oppgave. Planleggingsalgoritmer: monoton hastighetsalgoritme; tildeler statiske prioriteringer til oppgaver basert på deres lengder og deres perioder. 2.3) Dynamisk planlegging basert på en plan. Når en ny oppgave kommer, men før utførelsen av den starter, vil den prøve å lage en plan som inneholder de tidligere planlagte oppgavene så vel som den nye. Hvis den nylig ankomne oppgaven kan planlegges til å overholde tidsfristene uten at noen andre tidligere planlagte oppgaver mangler en tidsfrist, vil den nye oppgaven bli akseptert og den nye planleggingsplanen settes i verk. 2.4) Dynamisk beste innsatsplanlegging. Når en oppgave kommer, tildeler systemet en prioritet basert på dens egenskaper. Vanligvis brukes en eller annen form for lead-basert planlegging, for eksempel planlegging av nærmeste sikt. Dermed er ikke oppgavene periodiske og derfor er det ikke mulig å gjennomføre en statisk analyse av planlegging. Med denne typen planlegging vet vi ikke om en gitt tidsbegrensning vil være oppfylt før fristen er ute eller oppgaven er fullført.
For kommunikasjon brukes vanligvis CAN-bussforbindelser eller deterministiske nettverk eller serielle porter , siden de vanligste nettverkene, som Ethernet , er indeterministiske og ikke kan garantere responstiden. CAN -bussystemet brukes for sammenkobling av elektroniske kontrollenheter (ECU) i kjøretøy.
I denne typen operativsystemer er tidsfristene svært strenge, noe som betyr at oppgavene som utføres må begynne utføringen til angitt planlagt tid og skal være ferdig innen den tidsperioden som er tildelt dem.
I denne typen operativsystemer må også tidsfrister overholdes, men unnlatelse av å overholde en frist kan ikke ha stor betydning, så det er en viss fleksibilitet med gjennomføringstiden for oppgaven, noe som kan gi uønskede effekter. systemet som reduksjon av kvalitet.
I denne typen aksepteres forsinkelser av operativsystemet selv. Det er en tidsbegrensning for en spesifikk oppgave, men forsinkelser er akseptable så lenge tiden ikke er for høy, det vil si at forsinkelser håndteres problemfritt.
Mange sanntidsoperativsystemer er bygget for svært spesifikke applikasjoner som flykontroll, børser, raffinerikontroll, kontroll av valseverk. Også i bilindustrien og forbrukerelektronikkindustrien vokser sanntidsapplikasjoner veldig raskt.
Andre bruksområder for sanntidsoperativsystemer er følgende:
Innebygde systemer er systemer designet for å utføre spesifikke funksjoner med begrensede fysiske egenskaper der de fleste av komponentene deres vanligvis er inkludert i et hovedkort (sonder og sensorer, knapper, kontrollknott, etc.) og med korte responstider.
Sanntidsprogramvare er ideell for systemer som må overholde spesifikke tidsfrister der det må sikres at varighetsforutsigelse av oppgaveutførelse gjøres nøyaktig. Innebygde systemer i sanntid er en underkategori av innebygde systemer som fokuserer på rettidig utførelse av oppgavene sine, og bruker sanntidsprogramvare for å oppnå målet.
Innebygde systemer har beskyttelsesprosesser som gjenoppretter ressurser når en prosess er utilsiktet avsluttet for å forhindre ressurslekkasjer. Operativsystemet er avhengig av programvareteknikker, beskyttelse av maskinvareminne og distinksjon mellom veileder/bruker innenfor prosessorens instruksjonssett for å forhindre prosesskrasj eller ondsinnede handlinger som skader andre prosesser og operativsystemet , så bruken av et sanntidsoperativsystem kan i stor grad forbedre ytelsen og sikkerheten til det innebygde systemet .
Sanntidsoperativsystemer kan betraktes som en praktisk løsning for bruk av innebygde systemer , spesielt i scenarier der det kreves flere kontrollpunkter for å oppføre seg forutsigbart under kontrollerte prioritetsnivåer.
Ledende produsenter av RTOS-systemer i 2009 [ 3 ]