Hva er sanntidsoperativsystemer? Sanntidsoperativsystemer for nybegynnere.

OS sanntidssystemer (RTOS) er designet for å gi et grensesnitt til ressursene til tidskritiske sanntidssystemer. Hovedoppgaven i slike systemer er aktualiteten til databehandling.

Hovedkravet for en RTOS er å sikre forutsigbarhet eller determinisme av systematferd i verste fall. ytre forhold, som skiller seg kraftig fra ytelses- og hastighetskravene til universelle operativsystemer. En god RTOS har forutsigbar oppførsel under alle systembelastningsscenarier (samtidige avbrudd og trådutførelse).

Det er en viss forskjell mellom sanntidssystemer og innebygde systemer. Et innebygd system er ikke alltid pålagt å ha forutsigbar oppførsel, i så fall er det ikke et sanntidssystem. Men selv et overfladisk blikk på mulige innebygde systemer tyder på at de fleste innebygde systemer trenger forutsigbar oppførsel, iht. i det minste, for noen funksjonalitet, og dermed kan disse systemene klassifiseres som sanntidssystemer.

Det er vanlig å skille mellom myke og harde sanntidssystemer. I systemer hardt ekte tid manglende evne til å gi et svar på eventuelle hendelser i spesifisert tid fører til feil og manglende evne til å fullføre oppgaven. I det meste av russiskspråklig litteratur kalles slike systemer systemer med deterministisk tid. På praktisk anvendelse reaksjonstiden skal være minimal. Myke sanntidssystemer er systemer som ikke faller inn under definisjonen av "hard", fordi Det er ingen klar definisjon for dem i litteraturen ennå. Myke sanntidssystemer har kanskje ikke tid til å løse et problem, men dette fører ikke til svikt i systemet som helhet. I sanntidssystemer er det nødvendig å innføre en viss frist (i engelsk litteratur - deadline), før utløpet av denne oppgaven må nødvendigvis (for myke sanntidssystemer - helst) fullføres. Denne fristen brukes av oppgaveplanleggeren både til å tildele en prioritet til en oppgave når den startes og når du velger en oppgave for utførelse.

Martin Timmerman formulerte følgende nødvendige krav for RTOS:

  • Operativsystemet må være multitasking og forhåndsaktivert,
  • OS må ha et konsept med prioritet for tråder,
  • OS må støtte forutsigbare synkroniseringsmekanismer,
  • OS må gi en mekanisme for å arve prioriteringer,
  • OS-adferd må være kjent og forutsigbar (forsinkelser i behandling av avbrudd, forsinkelser i oppgavebytte, sjåførforsinkelser, etc.); dette betyr at i alle systemarbeidsscenarier må maksimal responstid bestemmes.

I løpet av de siste 25-30 årene har strukturen til operativsystemer utviklet seg fra en monolittisk til en flerlags OS-struktur og deretter til en klient-server-arkitektur. I en monolittisk struktur består OS av et sett med moduler, og endringer i en modul påvirker andre moduler. Jo flere moduler, jo mer kaos er det under driften av et slikt system. I tillegg er det ikke mulig å distribuere operativsystemet på et multiprosessorsystem. I en flerlagsstruktur påvirker endringer i ett lag tilstøtende lag; i tillegg er inversjon gjennom laget ikke mulig. For sanntidssystemer må det gis direkte tilgang til hvert lag i operativsystemet, og noen ganger direkte til maskinvaren.

Hoved ideen klient-server-teknologi i OS er å redusere OS-grunnlaget til et minimum (planlegger- og synkroniseringsprimitiver). All annen funksjonalitet flyttes til et annet nivå og implementeres gjennom tråder eller oppgaver. Et sett med slike serveroppgaver er ansvarlige for systemanrop. Applikasjoner er klienter som ber om tjenester gjennom systemanrop.

Klient-server-teknologi gjør det mulig å lage skalerbare operativsystemer og forenkler distribusjon i et multiprosessorsystem. Når du bruker systemet, forårsaker ikke utskifting av en modul en "snøball"-effekt; I tillegg innebærer en modulfeil ikke alltid en feil i systemet som helhet. Ha en mulighet dynamisk lasting og forsendelse av moduler. Hovedproblemet i denne modellen er minnebeskyttelse, siden serverprosesser må beskyttes. Hver gang en tjenesteforespørsel gjøres, må systemet bytte fra applikasjonskonteksten til serverkonteksten. Med støtte for minnebeskyttelse øker byttetiden fra en prosess til en annen.

Som regel er de fleste moderne RTOS bygget på grunnlag av en mikrokjerne (kjerne eller kjerne), som gir planlegging og utsendelse av oppgaver, samt deres interaksjon. Selv om kjernen minimerer OS-abstraksjoner, må mikrokjernen fortsatt ha en forståelse av prosessabstraksjoner. Alle andre konseptuelle abstraksjoner av operativsystemer flyttes utenfor kjernen, kalles på forespørsel og kjøres som applikasjoner.

Sanntid? La oss ta hensyn til en detaljert studie av RTOS. Først av alt, dette spesielle typer som skiller seg fra generelle operativsystemer i ytelse og ytelse i de verste situasjonene. Det er mange konsepter som avslører spesifikke:

RTOS er et system som er i stand til å tilby nødvendig service for en viss periode;

Et sanntidssystem, som er preget av konstant tilgjengelighet og tidspunktet for behandling av informasjon er usynlig for brukere;

- “raskt system”, der det som kommer i forgrunnen ikke er responstiden til RTOS, men tilstrekkelig med tid til å jobbe med applikasjonen.

For å fullføre bildet er det verdt å være oppmerksom på kjennetegn sanntids operativsystemer. Mest viktig funksjon er en garantert og stabil reaksjon på pågående hendelser. Oppgaver uansett nivå (høy og lav prioritet) skal ikke komme i konflikt med hverandre og fortrenge hverandre. Høyt krav til responstid spesifikk hendelse i virkeligheten.

Sanntid

De er delt inn avhengig av programmene: harde, myke og interaktive. La oss se kort på hver type.

Harde RTOS-er har strengt tatt Viss tid svar på en hendelse i sanntid. Eksempel: maskinvareavbrudd, visning av kontrollkommandoer må behandles som det skjer i 100 % av tilfellene.

Myke sanntidssystemer lar i 80-90 % av tilfellene avvike fra en viss tidsramme med én størrelsesorden. Men det viktigste er at disse forsinkelsene ikke fører til uopprettelige konsekvenser.

Interaktive RTOS inkluderer (når en person venter på et svar fra systemet etter instruksjoner eller kommandoer gitt av ham).

De vanligste sanntidsoperativsystemene og deres egenskaper

De fleste RTOSer er lukkede og vanskelige å få informasjon om. detaljert informasjon. WindRiver Systems har utviklet VxWorks (en hard RTOS) for programvareutvikling på innebygde PC-er. Den er basert på driften av vertsdatamaskinen som utviklingen utføres på programvare, og klientdatamaskinen, der den brukes under VxWorks-kontroll.

Disse sanntidsoperativsystemene er svært tilpassbare, men programvaremoduler kan ikke brukes i andre miljøer, noe som gjør dem ganske begrenset i bruk. Fordelene inkluderer:

Ubegrenset antall oppgaver som skal løses.

Antall prioriterte oppgaver er opptil 256.

Oppgaver er planlagt syklisk eller etter prioritet.

Semaforer som hjelper til med å kontrollere kritiske systemressurser.

Sanntidsoperativsystemer QNX Neutrino Realtime Operativsystem- ideen om QNX Software Systems. Den er basert på en cross-server arkitektur og har høy multitasking med prioritetsmodus. Hvert element i systemet fungerer uavhengig: i tilfelle feil og funksjonsfeil kan enhver kobling starte på nytt uavhengig uten å påvirke driften av kjernen eller andre komponenter. Den har også en dyp konfigurasjon, knyttet til basiskjernen, som utelukker arbeid i et annet miljø.

ChorusOS er et eksempel på et innebygd OS som er mye brukt i telekommunikasjon. Den støtter ulike telekommunikasjonsprotokoller og Java-teknologier, som tillater implementering av nye utviklinger og applikasjoner.

Forskjell fra generell bruk og formål OS

RTOS-er skiller seg fra generelle systemer i den deterministiske karakteren til arbeidet deres, noe som skyldes streng kontroll av tiden som brukes til å behandle oppgaver. Konseptet "bestemmelse" beskriver et forhåndsbestemt tidsintervall der ett sanntidsprogram utføres.

Karakteristiske trekk ved en RTOS fra et generell OS

Generelle operativsystemer, spesielt flerbruker som UNIX, er rettet mot optimal fordeling dataressurser mellom brukere og oppgaver. I sanntidsoperativsystemer forsvinner en slik oppgave i bakgrunnen - alt forsvinner før hovedoppgave- ha tid til å reagere på hendelser som skjer på anlegget En annen forskjell er at bruk av et sanntidsoperativsystem alltid er knyttet til utstyret, med objektet, med hendelsene som skjer på anlegget. Et sanntidsoperativsystem er fokusert på å behandle eksterne hendelser. Et sanntidsoperativsystem kan være likt i brukergrensesnitt på et generell OS, men det er strukturert helt annerledes. I tillegg er bruken av sanntidsoperativsystemer alltid spesifikk. Hvis et operativsystem for generelle formål vanligvis oppfattes av brukere (ikke utviklere) som et ferdig sett med applikasjoner, fungerer et sanntidsoperativsystem bare som et verktøy for å lage et bestemt sanntids maskinvare- og programvarekompleks. Og derfor er den bredeste klassen av brukere av sanntidsoperativsystemer utviklere av sanntidssystemer, personer som designer kontroll- og datainnsamlingssystemer. Når man designer og utvikler et spesifikt sanntidssystem, vet programmereren alltid nøyaktig hvilke hendelser som kan oppstå på anlegget, og kjenner den kritiske tidsrammen for å betjene hver av disse hendelsene.RT-systemet må ha tid til å svare på en hendelse som har skjedd. på anlegget innen den tid som er kritisk for denne hendelsen. Verdien av den kritiske tiden for hver hendelse bestemmes av objektet og selve hendelsen, og kan være forskjellig, men reaksjonstiden til systemet må forutsies (kalkuleres) når systemet opprettes. Unnlatelse av å svare på forutsagt tidspunkt anses som en feil for sanntidssystemer. Systemet må være i stand til å svare på hendelser som inntreffer samtidig. Selv om to eller flere eksterne hendelser inntreffer samtidig, må systemet ha tid til å reagere på hver av dem innenfor de tidsintervallene som er kritiske for disse hendelsene.

Sanntids OS

Generelt OS

Hovedoppgaven

Ha tid til å reagere på hendelser som skjer på utstyret

Fordel dataressurser optimalt mellom brukere og oppgaver

Hva er det fokusert på?

Håndtering av eksterne hendelser

Behandler brukerhandlinger

Hvordan den er plassert

Et verktøy for å lage et spesifikt maskinvare- og programvarekompleks i sanntid

Oppfattes av brukeren som et sett med applikasjoner klare til bruk

Hvem er den beregnet på?

Kvalifisert utvikler

Middels bruker

Harde og myke sanntidssystemer

Det finnes to typer sanntidssystemer - harde sanntidssystemer og myke sanntidssystemer.

Harde sanntidssystemer tillater ikke noen forsinkelse i systemrespons under noen omstendigheter fordi:

  • resultater kan være ubrukelige hvis sent
  • katastrofe kan oppstå hvis reaksjonen er forsinket
  • kostnadene ved å komme for sent kan være uendelige.

Eksempler på harde sanntidssystemer - systemer om bord kontrollsystemer, nødsikringssystemer, nødhendelsesopptakere.

Myke sanntidssystemer kjennetegnes ved at responsforsinkelsen ikke er kritisk, selv om det kan føre til økte resultatkostnader og en reduksjon i ytelsen til systemet som helhet.Et eksempel er nettverksdrift. Hvis systemet ikke hadde tid til å behandle den neste akseptert pakke, vil dette føre til tidsavbrudd på avsendersiden og resending (selvfølgelig avhengig av protokollen). Data går ikke tapt, men nettverksytelsen reduseres. Hovedforskjellen mellom harde og myke sanntidssystemer kan uttrykkes som følger: hardt system sanntid vil aldri være sent med å reagere på en hendelse, et mykt sanntidssystem bør ikke være sent med å reagere på en hendelse

Operativsystemkjernen

Kjerne - sentral del operativsystem (OS), som gir applikasjoner koordinert tilgang til datamaskinressurser, minne, eksternt Maskinvare, en ekstern inngangs- og utgangsenhet, som oversetter applikasjonsspråkkommandoer til binær kode som datamaskinen forstår. Som det grunnleggende elementet i operativsystemet er kjernen den mest lavt nivå abstraksjoner for applikasjoner for å få tilgang til systemressursene som er nødvendige for driften. Vanligvis gir kjernen slik tilgang til de utførende prosessene til de tilsvarende applikasjonene gjennom bruk av kommunikasjonsmekanismer mellom prosesser og applikasjonstilgang til systemanrop OS.

Monolitisk kjerne

Den monolitiske kjernen gir et rikt sett med maskinvareabstraksjoner. Alle deler av en monolitisk kjerne opererer i samme adresserom. Dette er et operativsystemdesign der alle komponentene i kjernen er komponenter ett program, bruk generelle strukturer data og samhandle med hverandre ved å ringe prosedyrer direkte. Monolittisk kjerne - den eldste måten organisering av operativsystemer. Et eksempel på systemer med en monolitisk kjerne er de fleste UNIX-systemer.

Fordeler: Driftshastighet, forenklet utvikling av moduler.

Feil: Siden hele kjernen opererer i samme adresserom, kan en feil i en av komponentene forstyrre hele systemet.

Noen gamle monolittiske kjerner, spesielt UNIX/Linux-klassesystemer, krevde rekompilering hver gang maskinvaresammensetningen endret seg. De fleste moderne kjerner lar deg laste inn moduler under drift som utfører deler av kjernefunksjonene. I dette tilfellet er komponentene i operativsystemet ikke uavhengige moduler, men komponenter av en stort program kalt en monolittisk kjerne, som er et sett med prosedyrer, som hver kan kalle hver. Alle prosedyrer kjører i privilegert modus.

Mikrokjerne

Mikrokjernen gir bare grunnleggende og minimumssett abstraksjoner for arbeid med utstyr. Det meste av arbeidet gjøres gjennom spesielle brukerprosesser kalt tjenester. Det avgjørende kriteriet for "mikrokernelisme" er plassering av alle eller nesten alle drivere og moduler i serviceprosesser.

Fordeler: Motstand mot maskinvarefeil og feil i systemkomponenter. Den største fordelen med mikrokjernearkitektur er høy grad modularitet til operativsystemkjernen. Dette gjør det mye enklere å legge til nye komponenter. I et mikrokjerneoperativsystem kan du laste og losse nye drivere, filsystemer osv. uten å avbryte driften.Prosessen med å feilsøke kjernekomponenter er betydelig forenklet, siden en ny versjon drivere kan lastes inn uten å starte hele operativsystemet på nytt. Komponentene i operativsystemkjernen er ikke fundamentalt forskjellige fra brukerprogrammer, så du kan bruke vanlige verktøy til å feilsøke dem. Mikrokjernearkitektur forbedrer systemets pålitelighet fordi en feil på uprivilegert programnivå er mindre farlig enn en feil på kjernemodusnivå.

Feil: Sende data mellom prosesser krever overhead.

Runtime miljø

Kravene til utførelsesmiljøet til sanntidssystemer er som følger:

  • lite systemminne - for muligheten for innebygging;
  • systemet må være fullstendig minnerelatert for å unngå å bytte eller bytte minneside;
  • systemet må være multitasking - for å sikre maksimalt effektiv bruk alle systemressurser;
  • kjerne med prioritet for serviceavbrudd. Avbruddsprioritet betyr at en prosess som er klar til å kjøre og har en viss prioritet, nødvendigvis har prioritet i køen fremfor en prosess med lavere prioritet, raskt erstatter sistnevnte og går videre til utførelse. Kjernen fullfører alt servicearbeid så snart en oppgave med høyest prioritet kommer. Dette sikrer forutsigbarheten til systemet;
  • priority manager - lar applikasjonsutvikleren tildele hver oppstartsmodul en prioritet som ikke er underlagt systemet. Prioritetstildeling brukes til å bestemme rekkefølgen som programmer som er klare til å kjøres kjøres i. Et alternativ til denne typen planlegging er karusellplanlegging, der hvert program som er klart til å fortsette gis like store sjanser til å kjøre. Med denne metoden er det ingen kontroll over hvilket program som skal kjøres og når. Dette er uakseptabelt i et sanntidsmiljø. Prioritetsbasert utsendelse og en kjerne med avbruddsprioritet gir applikasjonsutvikleren full kontroll over systemet. Hvis en hendelse med høyere prioritet oppstår, slutter systemet å behandle den lavere prioriterte oppgaven og svarer på den nylig mottatte forespørselen.

Kombinasjonen av egenskapene beskrevet ovenfor skaper en kraftig og effektivt miljø utførelse i sanntid.

I tillegg til egenskapene til kjøretidsmiljøet, er det også nødvendig å vurdere tjenesten som leveres av sanntids OS-kjernen. Kjernen i ethvert kjøretidsmiljø i sanntid er kjernen eller dispatcheren. Kjernen kontrollerer måldatamaskinens maskinvare: sentral prosessor, minne og inn-/utdataenheter; kontrollerer driften av alle andre systemer og programvare av anvendt karakter. I et sanntidssystem sitter avsenderen mellom måldatamaskinens maskinvare og applikasjonsprogramvaren. Det gir spesiell tjeneste, nødvendig for å kjøre sanntidsapplikasjoner. Tjenesten levert av kjernen gir applikasjonsprogrammer tilgang til systemressurser som minne eller inn-/utdataenheter.

Kjernen kan tilby forskjellige typer tjenester:

  • Intertask utveksling. Det er ofte nødvendig å overføre data mellom programmer innenfor samme system.I tillegg må mange applikasjoner kommunisere med andre systemer over et nettverk. Intern kommunikasjon kan utføres gjennom et meldingssystem. Ekstern kommunikasjon kan organiseres enten gjennom et datagram (beste leveringsmetode) eller via kommunikasjonslinjer (garantert levering). Valget av en eller annen metode avhenger av kommunikasjonsprotokollen.
  • Dataseparasjon. I sanntidsapplikasjoner tar datainnsamling lengst tid. Data er ofte nødvendig for driften av andre programmer eller er nødvendig av systemet for å utføre noen av dets funksjoner. Mange systemer gir tilgang til delte minneseksjoner. Datakø er utbredt. Det er mange typer køer i bruk, som hver har sine fordeler.
  • Behandler forespørsler fra eksterne enheter. Hvert applikasjonsprogram er koblet i sanntid til en ekstern enhet av en eller annen type. Kjernen må tilby I/O-tjenester som lar applikasjonsprogrammer lese fra og skrive til disse enhetene. For sanntidsapplikasjoner er det vanlig å ha en denne søknaden ekstern enhet. Kjernen må tilby en tjeneste som gjør arbeidet med enhetsdrivere enklere. Gjør det for eksempel mulig å ta opp på språk høy level- som C eller Pascal.
  • Håndtere spesielle situasjoner. Et unntak er en hendelse som oppstår under programkjøring. Den kan være synkron hvis forekomsten er forutsigbar, for eksempel divisjon med null. Og det kan også være asynkront hvis det oppstår uforutsigbart, for eksempel et spenningsfall. Ved å tilby muligheten til å håndtere denne typen hendelser, kan sanntidsapplikasjoner reagere raskt og forutsigbart på interne og eksterne hendelser. Det er to metoder for å håndtere unntak - bruk av tilstandsverdier for å oppdage feiltilstander og bruk av en unntaksbehandler for å fange feiltilstander og rette dem.

Oversikt over RTOS-arkitekturer

Operativsystemarkitekturen har gjennom historien gjennomgått en betydelig utvikling. Et av de første prinsippene for konstruksjon, monolittisk OS (Figur 1) besto av å presentere OS som et sett med moduler som samhandler med hverandre på ulike måter innenfor systemkjernen og gir applikasjonsprogrammer inngangsgrensesnitt for tilgang til maskinvare.

nivå OS (Figur 2) Et eksempel på et slikt OS er det velkjente MS-DOS system. I systemer av denne klassen kan applikasjonsapplikasjoner få tilgang til maskinvaren ikke bare gjennom systemkjernen eller dens residente tjenester, men også direkte. RTOS-er har blitt bygget på dette prinsippet i mange år. Sammenlignet med monolitiske operativsystemer gir denne arkitekturen en betydelig større grad av forutsigbarhet av systemreaksjoner, og gir også mulighet for rask tilgang maskinvareapplikasjoner. Ulempe

Det som gjør slike systemer så dårlige er mangelen på multitasking. Innenfor denne arkitekturen ble problemet med å behandle asynkrone hendelser redusert til å bufre meldinger, og deretter sekvensielt polle buffere og behandle dem. Samtidig ble overholdelse av kritiske tjenestetidsfrister sikret av høy ytelse datakompleks sammenlignet med hastigheten på eksterne prosesser.

Figur 2. Lagdelt OS-arkitektur

En av de mest effektive arkitekturene for å bygge sanntidsoperativsystemer er klient-server-arkitekturen. Generell ordning Et OS som kjører på denne teknologien er vist i figur 3. Hovedprinsippet for denne arkitekturen er overføring av OS-tjenester i form av servere til brukernivå, og mikrokjernen utfører funksjonene til en meldingsbehandler mellom klienten brukerprogrammer og servere - systemtjenester. Denne arkitekturen gir mange fordeler når det gjelder krav til RTOS og innebygde systemer. Blant disse fordelene er:

1. Påliteligheten til OS øker, fordi hver tjeneste er i hovedsak, frittstående applikasjon og det er lettere å feilsøke og spore feil.

2. Et slikt system skalerer bedre pga unødvendige tjenester kan ekskluderes fra systemet uten å påvirke ytelsen.

3. Feiltoleransen til systemet øker, pga En frossen tjeneste kan startes på nytt uten

start systemet på nytt.

Figur 3. Bygge et OS ved hjelp av klient-server-arkitektur

Dessverre er det i dag ikke mange operativsystemer implementert på klient-server-prinsippet. Blant de velkjente RTOSene som implementerer mikrokjernearkitektur er OS9 og QNX.

Liste over brukt litteratur:

1) http://ru.wikipedia.org/wiki/Real_time_operativsystem

2) http://www.asutp.ru/?p=600591

3) http://www.mka.ru/?p=40774

4) http://www.4stud.info/rtos/lecture1.html

5)http://www.ozon.ru/context/detail/id/3092042/

Hei, Habr!
I dag skal jeg snakke om dette interessant ting som et sanntidsoperativsystem (RTOS). Jeg er ikke sikker på om dette vil være interessant for erfarne programmerere, men jeg tror nybegynnere vil like det.

Hva er en RTOS?

Hvis vi ser på Wikipedia, vil vi se hele 4 definisjoner.
Kort fortalt er en RTOS et operativsystem som reagerer på eksterne hendelser i en viss tidsperiode. Herfra kan vi forstå hovedformålet med en RTOS - enheter som krever en rask respons på hendelser (men ikke i noe tilfelle forveksle driften av en RTOS med avbrudd).

Hvorfor trenger vi det?

Det er ganske mange grunner til dette.
For det første støtter RTOS multitasking, semaforprosessprioriteter og mye mer.
For det andre er den veldig lett og krever nesten ingen ressurser.
For det tredje kan vi få alt det ovennevnte på nesten hvilken som helst maskinvare (for eksempel kjører FreeRTOS selv på 8-bit AtMega).
Og for det fjerde: bare lek og ha det gøy.

Gjennomgang av 3 kjente RTOS-er.

Vennligst merk: følgende er min personlige mening.
FreeRTOS
En av de mest populære RTOS i dag. Overført til en enorm mengde maskinvare. Offesiell nettside.
proffer
1) Gratis
2) Overført til et stort nummer av kjertel
3) Kraftig funksjonalitet
4) Det finnes ulike biblioteker: grafikk, Internett og mer.
5) God dokumentasjon.
Minuser
1) En ganske kompleks prosess med portering til ny maskinvare.

Konklusjon: Dette er en virkelig profesjonell RTOS med god dokumentasjon. Det vil være bra for en nybegynner hvis maskinvaren hans allerede har en port.

KeilRTX
Inntil nylig var denne RTOS kommersiell, men har nylig blitt åpen kildekode. Fungerer bare på armarkitektur. Offesiell nettside.
proffer
1) Gratis
2) Enkelt portert til ny maskinvare (innenfor armarkitekturen).
3) Det finnes ulike biblioteker: grafikk, Internett og mer.
Minuser
1) Det er nesten umulig å jobbe med henne på Keil
2) Noe redusert funksjonalitet
3) Kun armen støttes.
4)(på personlig erfaring) Taper for mange RTOS når det gjelder hastighet.
Konklusjon: ideell for nybegynnere og små prosjekter.
uc/os
Kraftig kommersiell RTOS. Nettsted .
proffer
1) Stor mengde funksjoner og biblioteker.
2) Støtter mye jern
Minuser
1) Kommersiell.
2) Vanskelig å bruke.

Konklusjon: å kalle det en RTOS for en nybegynner er en strek.

Andre interessante RTOS

RTLinux RTOS basert på vanlig Linux.
QNX RTOS basert på Unix.

Funksjoner for utvikling ved hjelp av RTOS

Vel, først og fremst må du forstå følgende: en RTOS er ikke Windows. Den kan ikke installeres. Dette systemet kompilerer ganske enkelt med programmet ditt.
Når du skriver programmer med en RTOS, brukes ikke funksjoner i vanlig forstand. I stedet for funksjoner brukes prosesser (eller oppgaver) Forskjellen er at prosesser, i motsetning til funksjoner, er endeløse løkker og aldri ta slutt (med mindre noen eller han selv dreper ham - det vil si losser ham fra hukommelsen).
Hvis flere prosesser er aktivert, bytter RTOS dem, og gir maskintid og ressurser etter tur. Det er her konseptet med prosessprioritet oppstår - hvis to prosesser trenger maskintid samtidig, så vil RTOS gi det til den med høyest prioritet.
RTOS har spesielle forsinkelsesfunksjoner - slik at tiden ikke er bortkastet mens en prosess er forsinket, en andre blir utført.
La oss nå snakke om en semafor - dette er en ting som kontrollerer en prosess tilgang til applikasjonsressurser. For hver ressurs er det en markør - når en prosess trenger en ressurs, tar den den og bruker denne ressursen. Hvis det ikke er noen token, må prosessen vente til den er returnert. La meg gi deg et eksempel: ulike prosesser sende informasjon over en UART. Hvis det ikke var noen semafor, ville de sende byte etter tur og det ville oppstå forvirring. Og så tok den første prosessen tokenet på UART, sendte en melding og ga den til den andre (og så videre i det uendelige).

Ytterligere RTOS-biblioteker.

RTOS tilbyr ofte ulike biblioteker for å jobbe med for eksempel grafikk, internett osv. De er veldig praktiske, og du bør ikke nøle med å bruke dem. Men husk at uten RTOS som de er skrevet for, vil de ikke fungere.
Her er eksempler:
For RTX

Hastigheten til PLS (datamaskinen) påvirker størrelsen på den dynamiske feilen til automatiseringssystemet og marginen for stabiliteten hvis det er tilbakemelding. For å forbedre disse egenskapene brukes høyhastighets I/O-moduler og en datamaskin (PLC) med en høyytelsesprosessor. Dette lar deg forbedre de dynamiske egenskapene til systemet, men de fleste operativsystemer (OS) kan ikke gi samme utførelsestid for en oppgave når den startes gjentatte ganger, det vil si at utførelsestiden er tilfeldig størrelse.

For å eliminere dette problemet ble det utviklet en klasse operativsystemer som gir deterministiske (dvs. ikke-tilfeldige) oppgavekjøringstider og responstider på maskinvareavbrudd. Slike OS-er ble kalt sanntidsoperativsystemer OS RV og ble delt inn i OS hard og myk sanntid.

I harde sanntidssystemer er det en vanskelig tidsterskel. Hvis den overskrides, oppstår irreversible katastrofale konsekvenser.

I myke sanntidssystemer forringes systemytelsen ettersom kontrollresponstiden øker. Systemet kan fungere dårlig, men uten katastrofale konsekvenser.



For å løse harde sanntidsproblemer brukes en klassisk tilnærming, dvs. bygge et hendelsesdrevet system. Hvor det for hver hendelse i systemet etableres en klart definert reaksjonstid og en viss prioritet. Den praktiske implementeringen av slike systemer er kompleks og krever alltid nøye design og modellering.

Følgelig skiller RT OS-er seg i oppførsel, ikke internt prinsipp konstruksjon. For eksempel operasjonsstue Windows-system XP, når du håndterer langsomme (termiske) prosesser, kan betraktes som RT OS, det vil si hvis sannsynligheten for at det skjer er uakseptabel lange forsinkelser lav nok til å oppnå det nødvendige servicenivået.

I et hardt RT OS sendes en prosess for utførelse samtidig med en indikasjon på nødvendig utførelsestid. OS-planleggeren tillater enten utførelse, garanterer nødvendig tid, eller avviser prosessen som umulig å utføre. For å gjøre dette, må planleggeren vite nøyaktig hvor lang tid hver OS-funksjon tar å fullføre en oppgave.

De grunnleggende kravene for å gi sanntidsmodus er følgende:

1) høyt prioriterte oppgaver skal alltid fullføres først;

2) prioritert inversjon må utelukkes;

3) prosesser og tråder hvis utførelsestid ikke kan planlegges bør aldri oppta systemressurser fullstendig.

Invertering av prioriteringer refererer til en situasjon der en tråd med høy prioritet ber om en ressurs som allerede er okkupert av en tråd med lavere prioritet.

Hovedmetoden for å løse dette problemet i RT OS er arv av prioriteringer, som er som følger. Hvis en tråd med lav prioritet blokkerer kjøringen av flere høyprioriterte tråder, ignorerer tråden med lav prioritet sin opprinnelige prioritet og kjøres med høyeste prioritet i blokken med tråder som venter på den. Etter å ha fullført arbeidet, går tråden tilbake til sin opprinnelige prioritet.

For å sikre sanntidsmodus kan følgende krav implementeres i operativsystemet

1) støtte for dynamiske prioriteringer, som kan endres under oppgavekjøring, i multitasking-modus med en forebyggende kjerne (for både prosesser og tråder);

2) muligheten for å arve prioriteringer;

3) muligheten til å forhindre oppgaver fra OS-kjernen;

4) begrenset avbruddsforsinkelse (tiden da avbrudd er deaktivert - mens den kritiske delen av koden behandles);

5) utførelse av OS-tjenester med en prioritet tildelt av tjenesteklienten.

RT-systemer har vanligvis ikke virtuelt minne fordi denne metoden bruker disksøking, som har uforutsigbare utførelsestider.

De vanligste operativsystemene i PLS-er og datamaskiner for å løse automatiseringsproblemer er Windows CE, QNX Neutrino og OS-9.

QNX Neutrino

QNX Neutrino fra QNX Software Systems er et sanntidsoperativsystem som gir prioritert multitasking. Støtter mikroprosessorer fra ARM, StrongARM, xScale, x86, MIPS, PowerPC, SH-4-familiene, og er i stand til å utføre opptil 250 oppgaver på én node.

QNX refererer til mikrokjerne OS, dvs. bare redskaper grunnleggende funksjoner kjerner - styring av adresserommet til RAM og virtuelt minne, prosesser og tråder, gir interprosessorkommunikasjon. Består av en kjerne, en prosessplanlegger og tjenester. Det er bygget på grunnlag av tjenester - små oppgaver som utfører hovedfunksjonene til operativsystemet. Denne strukturen lar deg deaktivere all unødvendig funksjonalitet uten å endre kjernen. Hver driver, applikasjon, protokoll eller filsystem kjører utenfor kjernen, i et beskyttet adresseområde.

Prioritetsinversjon overvinnes ved å bruke distribuert prioritetsarv. QNX-operativsystemet har funnet applikasjon både på det nedre nivået av prosesskontrollsystemet (OS for kontrollere) og på det øvre nivået (OS for SCADA-programvare).

OS-9-operativsystemet fra Microware System er multitasking og flerbruker, og opererer i myk sanntid. Brukes i innebygde applikasjoner på ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K-plattformer.

OS-9 er en klasse med Unix-lignende sanntidsoperativsystemer og tilbyr mange av de kjente funksjonene i Unix-miljøet. Alle funksjonelle komponenter OS-9, inkludert kjerne, hierarkisk filbehandlere, er input/output-systemet og utviklingsverktøy implementert som uavhengige moduler. Ved å kombinere disse modulene kan utvikleren lage systemer med et bredt utvalg av konfigurasjoner - fra frittstående miniatyrkjerner, ROM-baserte kontrollere, til fullskala flerbrukerutviklingssystemer.

OS-9 gir alle de grunnleggende funksjonene til sanntidsoperativsystemer: avbruddsadministrasjon, informasjonsutveksling mellom oppgaver og oppgavesynkronisering.

OC WINDOWS

operativsystem Windows kjent for alle som et skrivebordssystem. Men dette gjelder først og fremst Windows-plattformer 3.xx/95, som virkelig mangler sanntidsstøtte. Situasjonen endret seg dramatisk med bruken av Windows NT.

Windows NT i seg selv er ikke et sanntidsoperativsystem på grunn av en rekke funksjoner. Systemet støtter maskinvare i stedet for programvareavbrudd, det er ingen prioritert behandling av utsatte prosedyrer osv.

Men på slutten av det tjuende århundre gjorde en rekke selskaper seriøse forsøk på å gjøre Windows NT om til et hardt sanntids-OS. Og disse forsøkene ble kronet med suksess. VenturCom har utviklet Real Time Extension-modulen (RTX), et sanntidsundersystem (RT) for Windows NT. Dette delsystemet har sin egen planlegger med 128 avbruddsprioriteter, som er uavhengig av NT. Maksimal avbruddsresponstid er 20-80 µs, uavhengig av prosessorbelastning. Nå, med hvert timeravbrudd, overføres prioritet til tidskritiske oppgaver. Og i tiden som gjenstår fra arbeidet deres, kan "langsomme" prosesser utføres: input/output, arbeid med disk, nettverk, grafisk grensesnitt og så videre.

Windows CE.NET

Microsofts Windows CE.NET hard sanntids multitasking operativsystem støtter mikroprosessorer med ARM-arkitektur, StrongARM og xScale, MIPS, SH, X86-kompatibel. 32-bit Windows CE ble laget av Microsoft for små datamaskiner (kalkulatorer), men på grunn av en rekke fordeler begynte det å kreve rollen som et standard sanntids OS. Disse fordelene inkluderer:

1) åpenhet og enkel dokking med andre operativsystemer Windows-familien;

2) responstid i størrelsesorden 500 μs;

3) betydelig mindre sammenlignet med andre operativsystemer Windows-krav til minneressurser og muligheten til å bygge diskløse systemer.

4) tillater samtidig utførelse av opptil 32 prosesser;

5) har 256 prioritetsnivåer;

6) støtter forebyggende multitasking;

7) gir karusellutførelse av kjeder med samme prioritet;

8) støtter nestede avbrudd;

9) har en gjennomsnittlig avbruddsbehandlingstid på 2,8 μs, støtter nestede avbrudd;

10) gir behandlingstid for avbruddstråd (Interrupt Service Thread, IST) lik 17,9 μs;

11) i en minimumskonfigurasjon kan installeres med et RAM-volum på 200 KB.

Planlegging gjøres basert på prioriteringer, og prioritert arv brukes til å eliminere inversjon. Til tross for muligheten for å jobbe med virtuell hukommelse, for å sikre hard sanntidsmodus, er den deaktivert.

Windows CE .NET støttes av Microsoft Visuelt studio.NET og Microsoft innebygde Visual C++-språk Visuell programmering C++, Visual C# og Visual Basic.NETT

Og i 1999 av Direct av Koyo Windows CE ble installert på microPLC-plattformen for første gang.

Valg av operativsystem programvare og maskinvare toppnivå Prosesskontrollsystemet bestemmes av applikasjonsoppgaven (generelt bruk OS eller RTOS). Men den mest populære og utbredte ulike alternativer Windows OS (Windows NT/2000). De er utstyrt med programvare og maskinvareverktøy på toppnivået av automatiserte prosesskontrollsystemer, presentert personlige datamaskiner(PC) annen kraft og konfigurasjoner - arbeidsstasjoner til operatører/ekspeditører og spesialister, databaseservere (DB), etc.

Denne situasjonen oppsto som et resultat av en rekke årsaker og trender i utviklingen av moderne informasjons- og mikroprosessorteknologier.

Her er noen av hovedargumentene for Windows:

Windows er veldig utbredt i verden, inkludert i Russland, og derfor er det lett å finne en spesialist som kan vedlikeholde systemer basert på dette operativsystemet;

Dette operativsystemet har mange applikasjoner som gir løsninger på ulike problemer med å behandle og presentere informasjon;

Windows OS og Windows-applikasjoner er enkle å lære og har et standard, intuitivt grensesnitt;

Applikasjoner som kjører under Windows-kontroll, støtte offentlig tilgjengelige datautvekslingsstandarder;

Windows-baserte systemer er enkle å betjene og utvikle, noe som gjør dem kostnadseffektive både når det gjelder støtte og inkrementell vekst;

Microsoft utvikler seg informasjonsteknologi(Det for Høye vinduer i et tempo som lar selskaper som bruker denne plattformen "følge med i tiden."


Oppgaveplanlegging er et av nøkkelbegrepene i multitasking og multiprosessering i både generelle formål og sanntidsoperativsystemer. Planlegging innebærer å tildele prioriteringer til prosesser i en prioritert kø. Programkode Den som utfører denne oppgaven kalles planleggeren