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

Hva er en RTOS?

Ser vi på Wikipedia ser vi hele 4 definisjoner.
Kort fortalt er en RTOS et operativsystem som reagerer på eksterne hendelser innenfor en viss tidsperiode. Derfor kan vi forstå hovedformålet med RTOS - enheter der en rask respons på hendelser kreves (men ikke i noe tilfelle forveksle RTOS-drift med avbrudd).

Hvorfor trenger vi det?

Det er ganske mange grunner til dette.
For det første støtter RTOS multitasking, prosessprioriteringer, semaforer og 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.

OBS: Det som følger er min personlige mening.

FreeRTOS

En av de mest populære RTOS i dag. Porteres til en enorm mengde jern. Offisiell side.

proffer

1) Gratis
2) Porteres til en stor mengde jern
3) Kraftig funksjonalitet
4) Det finnes ulike biblioteker: grafikk, internett og mer.
5) God dokumentasjon.

Minuser

1) Ganske komplisert 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 det allerede er en port på maskinvaren hans.

KeilRTX

Inntil nylig var denne RTOS kommersiell, men ble nylig åpen. Fungerer kun på armarkitektur. Offisiell side.

proffer

1) Gratis
2) Enkelt portert til ny maskinvare (innenfor armarkitekturen).
3) Det finnes ulike biblioteker: grafikk, internett og mer.

Minuser

1) Å jobbe for Keil med henne er nesten umulig
2) Litt nedstrippet funksjonalitet
3) Kun armen støttes.
4) (fra personlig erfaring) Taper for mange RTOS i hastighet.
Konklusjon: ideell for nybegynnere og små prosjekter.

uc / os

Kraftig kommersiell RTOS. Nettstedet .

proffer

1) Et stort antall funksjoner og biblioteker.
2) Støtter mye jern

Minuser

1) Kommersiell.
2) Vanskelig å bruke.

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

Andre interessante RTOS

RTLinux En 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: RTOS er ikke Windows. Den kan ikke installeres. Dette systemet er ganske enkelt kompilert med programmet ditt.
Når du skriver programmer med RTOS, brukes ikke funksjoner i vanlig forstand. Prosesser (eller oppgaver) brukes i stedet for funksjoner.Forskjellen er at prosesser, i motsetning til funksjoner, er det endeløse sykluser 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 viser maskintid og ressurser én etter én. Det er her konseptet med prosessprioritet oppstår - hvis to prosesser samtidig trenger maskintid, vil RTOS gi det til den med høyest prioritet.
RTOS har spesielle funksjoner forsinkelser - slik at tiden ikke er bortkastet under forsinkelsen av en prosess, blir den andre utført.
La oss nå snakke om en semafor - dette er en slik 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 markør, må prosessen vente på at den blir returnert. Jeg vil gi et eksempel: forskjellige prosesser sender informasjon om en UART. Hvis det ikke var noen semafor, ville de sende byte én etter én, og det ville vært et rot. Og så tok den første prosessen markøren på UART, sendte en melding og ga den til den andre (og så videre - ad infinitum).

Ytterligere RTOS-biblioteker.

RTOS tilbyr ofte ulike biblioteker for å jobbe med for eksempel grafikk, internett osv. De er veldig komfortable 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 noen eksempler:
For RTX

Programvare produkter og systemer № 4, 2001 søppelinnsamling. Teknisk rapport, University of Texas i Austin, 1993. 3. Kim T., Chang N., Kim N., Shin H. Planlegging av søppeloppsamler for innebygde sanntidssystemer. Teknisk rapport, Seoul National University. 4. Sanntidsspesifikasjonen for Java. http://www.rtj.org. 5. Spesifikasjon av internasjonal J-konsortium. Sanntids Core-utvidelser. www.j-consortium.org. 6. Nikiforov V.V., Danilov M.V. Statisk prosessering av spesifikasjoner for sanntids programvaresystemer. // Programvareprodukter og -systemer - 2000. - Nr 4. - S.13-18. 7. Henriksson R. Planlegging av søppelhenting i innebygde systemer. Lund, 1998. 8. Nilsen K., Lee S. PERC sanntids API. NewMonics Inc., 1997. 9. Wilson P.R., Johnstone M.S., Neely N., Boles D. Dynamic storage allocation: a survey and critical review. Teknisk rapport, University of Texas i Austin, 1995. OSEK / VDX INTERNASJONAL STANDARD FOR SANNTIDS OPERATIVSYSTEM M.P. Chervinsky En av trendene for å forbedre designene til moderne biler er den økende introduksjonen av innebygde datasystemer. Følgelig vokser produksjonsvolumet bilapplikasjoner sanntid - programvareprodukter som sikrer at disse systemene fungerer. Veksten i produksjonen er ledsaget av en innstramming av utviklingstiden for programvareapplikasjoner, krav for å redusere kostnadene deres med en samtidig forbedring av pålitelighet, mobilitet, egnethet for gjenbruk ved utvikling av nye produkter. De oppførte faktorene stimulerer utviklingen av standarder som styrer arkitektoniske og teknologiske løsninger, som spesifiserer programvare og nettverksgrensesnitt for sanntids bilapplikasjoner. Slike standarder bør bidra til å forbedre integreringsevnen til programvareprodukter produsert av ulike programvareleverandører. Store bilbedrifter (Chrysler, BMW, Volkswagen og andre) er også interessert i implementeringen av slike standarder, og streber etter å skape konkurranse i markedet for programvareprodukter som de bruker, fordi konkurranse lar dem kjøpe programvareprodukter fra leverandører som tilbyr den beste prisen forhold. /kvalitet. For å sikre at en leverandørendring ikke medfører behov for å omarbeide en betydelig del av applikasjonene, krever leverandører at standarder skal brukes av alle programvareleverandører. De fleste innebygde systemer som brukes i kjøretøy er harde sanntidsapplikasjoner. Behandlingen av hendelser som oppstår i dem er begrenset av strenge tidsfrister, hvis brudd kan føre til katastrofale konsekvenser. For tiden er kjerneteknologien, eller sanntidsoperativsystemet (RTOS), i ferd med å bli hovedteknologien som brukes til å lage sanntids bilapplikasjoner og spesielt harde sanntidsapplikasjoner. RTOS-40 lar applikasjonsutviklere garantere driften til en applikasjon gjennom hele syklusen av systemoperasjonen, forutsatt at oppgavene er riktig prioritert og applikasjonen er utformet riktig. Behovet for å standardisere bilapplikasjoner basert på RTOS førte til opprettelsen i 1995 av en internasjonal komité som implementerte OSEK / VDX-prosjektet for å lage internasjonale standarder for utvikling av programvare for datasystemer innebygd i biler. OSEK / VDX-prosjektet ble initiert av en gruppe ledende europeiske kjøretøy-(bil)produsenter, hvorav de fleste er lokalisert i Tyskland. Det er derfor den valgte forkortelsen OSEK er en forkortelse av det tyske navnet "Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug" - "Open Systems and Interfaces for Automotive Electronics". Forkortelsen VDX står for "Vehicle Distributed eXecutive" - ​​navnet på et annet prosjekt, som integrasjonen fant sted nesten samtidig med starten av OSEK-prosjektet. Dermed gjenspeiler selv navnet på prosjektet og serien av standarder utviklingens internasjonale karakter med en viss dominans av tyske produsenter. Det utvikles flere standarder innenfor OSEK / VDX-prosjektet. 1. OSEK / VDX OS (operativsystem) - RTOS-spesifikasjon. Spesifikasjonen inneholder en beskrivelse av OS-arkitekturen, en definisjon av OS-programmeringsgrensesnittet som en applikasjon skal bruke, og Detaljert beskrivelse oppførselen til operativsystemet og dets komponenter. Det skal bemerkes at standarden i hovedsak spesifiserer arkitekturen og funksjonene til sanntidskjernen, og ikke et fullverdig OS, siden den ikke inneholder slike essensielle OS-komponenter som for eksempel et I/O-kontrollundersystem, eller et undersystem for minnetildeling. 2. OSEK / VDX COM (kommunikasjon) - spesifikasjon av nettverksdelsystemet. Spesifikasjonen definerer programvaregrensesnittene og protokollene beregnet for overføring av data mellom node-programvareproduktene og kjøretøysystemene. En moderne bil inneholder opptil flere dusin mikrokontrollere som utveksler informasjon. Vanligvis brukes minst to undernett: høy hastighet for motor-, gir- og fjæringskontrollsystemer, og lav hastighet for kroppselektronikk. Programvaregrensesnittet gir transparent dataoverføring, det vil si at et enkelt sett med funksjoner brukes til å utveksle meldinger både innenfor en node og mellom nettverksnoder. Til tross for at spesifikasjonen som helhet gir brukere alle nødvendige midler for å lage et lokalt nettverk av en bil og støtter andre standarder som brukes i bilindustrien, er implementeringen av produkter som implementerer OSEK / VDX COM i virkelige prosjekter full av noen problemer. Den viktigste er bruken av andre (ikke-standard) protokoller av store bilprodusenter, noe som kompliserer overgangen til OSEK / VDX COM, siden det kreves enten å endre nettverksprogramvaren i alle noder i bilen, eller for å støtte begge deler standard og ikke-standard protokoller på samme tid. i det minste på noen noder på nettverket. I tillegg inkluderer ikke gjeldende versjon av spesifikasjonen en mekanisme for å overføre data som er flere bit lange, og det er data av denne lengden som utgjør en betydelig andel av kjøretøyets nettverkstrafikk. Derfor fortsetter utviklingen av OSEK / VDX COM-spesifikasjonene. 3. OSEK / VDX NM (Network Management) er enasjon. Spesifikasjonen definerer hvordan informasjon om nåværende tilstand hver av nodene i nettverket overføres til de andre nodene. For dette brukes overvåkingsmetoden, spesielt de to variantene - direkte og indirekte. Direkte overvåking er basert på overføring av spesielle meldinger over en logisk ring eller logisk stjerne. Indirekte overvåking er basert på sporing av normale meldinger sendt av noder. OSEK / VDX NM kan integreres med andre nettverkssystemer (ikke bare OSEK / VDX COM) og brukes derfor i dag sammen med ikke-standard nettverkssystemer. 4. OSEK / VDX OIL (OSEK Implementation Language) - spesifikasjon av systemkonfigurasjonsspråket. Spesifikasjonen beskriver språket som brukes til å konfigurere applikasjoner bygget på OSEK / VDX-implementeringen. I innebygde systemer som brukes i biler, er alle applikasjonsobjekter statisk konfigurert på kompileringstidspunktet. OIL-språket inneholder konstruksjoner som lar deg beskrive egenskaper systemobjekter, for eksempel navn og prioritering av oppgaver, parametere for tidtakere og meldinger, etc. Konfigurasjonsbeskrivelsen er under behandling spesiell nytte (system generator), som genererer overskriftsfiler og kildekode som beskriver systemtabeller. Foreløpig er ikke alle spesifikasjoner fullt dekket av OSEK / VDX OIL (spesielt er det ingen beskrivelser for OSEK / VDX COM-objekter, nr. 4, 2001), så arbeidet med denne standarden pågår. De listede spesifikasjonene er utviklet av ulike arbeidsgrupper stort sett uavhengig av hverandre, men på visse stadier blir spesifikasjonene korrigert og synkronisert. Synkroniserte versjoner legges inn i spesifikasjonen av lenker - et spesielt dokument som inneholder en beskrivelse av hele prosjektet og kommentarer til dets bestanddeler. I tillegg til disse spesifikasjonene utvikler OSEK/VDX-prosjektet spesifikasjoner for tidsutløste systemer. Foreløpig er imidlertid utviklingen ennå ikke brakt til stadiet med publisering av offisielle dokumenter. OSEK / VDX OS-spesifikasjon. Det siste offisielt utgitte dokumentet er revisjon 1 av versjon 2.1 datert 13. november 2000. Denne revisjonen er resultatet av en grundig revisjon av forrige revisjon 1, versjon 2.0, der flere store feil og hundrevis av mindre feil ble funnet. Defekter ble oppdaget både av utviklerne av RTOS selv og av utviklerne av applikasjoner. Flere defekter var så alvorlige at de gjorde det umulig å lage en riktig fungerende RTOS på enkelte maskinvareplattformer. Arbeidsgruppen tok en ekstremt ansvarlig tilnærming til å rette opp mangler og kommentarer. Det er nok å si det full liste problemer og foreslåtte løsninger inneholdt flere sider enn den faktiske spesifikasjonen. OSEK / VDX OS-spesifikasjonen definerer et programmeringsgrensesnitt for å utføre RTOS-funksjoner. Programmeringsgrensesnittet er spesifisert i programmeringsspråket C (ANSI-C-standarden brukes), selv om RTOS kan implementeres i andre programmeringsspråk. Applikasjonsmobilitet opprettholdes på kildekodenivå. Det antas at applikasjonen ganske enkelt kan rekompileres ved å erstatte RTOS-implementeringen. Imidlertid er 100 % portabilitet fortsatt ikke garantert, og når du porterer en applikasjon fra en plattform til en annen, kan det være nødvendig med noen endringer i både kildekoden og konfigurasjonsbeskrivelsen. Dette skyldes det faktum at spesifikasjonen definerer implementeringsavhengige funksjoner, og konfigurasjonen kan inkludere attributter designet for å optimalisere RTOS og applikasjonen for en spesifikk implementering. Men innsatsen for å portere applikasjonen er fortsatt betydelig lavere enn ved bruk av ikke-standard RTOS, og porteringen kan utføres på integrasjonsstadiet, i stedet for selve programvareutviklingen. Innholdet i OSEK / VDX OS-spesifikasjonen. Spesifikasjonen inneholder seksjoner som regulerer: OS-arkitektur, oppgavehåndtering, avbruddshåndtering, hendelseshåndtering, synkronisering ved bruk av delte ressurser, alarmer (kontroll av tidtakere og tellere), meldingsoverføring, feilhåndtering og feilsøking, beskrivelse av systemanrop. 41 Programvareprodukter og -systemer Det er også en del som definerer funksjonene til RTOS-implementering og en liste over endringer (versjonskontroll). Det skal bemerkes at spesifikasjonen skiller regulatoriske krav (obligatoriske) og ganske enkelt beskrivende deler som forklarer spesifikasjonens spesifikasjoner. Hovedfunksjonene til operativsystemet som oppfyller OSEK / VDX OS-spesifikasjonene er diskutert nedenfor. OS-arkitektur. Strengt tatt er ikke RTOS-arkitekturen beskrevet i spesifikasjonen, siden den ikke skiller seg fra den som tradisjonelt brukes i sanntidskjerner, og avsnittet inneholder heller en generell beskrivelse av prinsippene for RTOS-drift. RTOS administrerer to typer objekter som konkurrerer om prosessorbruk - oppgaver og avbruddsbehandlere. Oppgaver konkurrerer basert på programvaredefinerte statiske prioriteter, det vil si at RTOS støtter planlegging med faste prioriteringer. Avbruddsbehandlere har forrang over oppgaver og er maskinvareplanlegging. På grunn av denne prioriteringen blir enhver oppgavekontekstbytte forårsaket av utførelse av systemanrop i avbruddsbehandlere forsinket til avbruddsbehandleren fullfører eller den ytterste behandleren fullfører når nestede avbrudd behandles. Tilsvarende de to typene konkurrerende objekter, definerer spesifikasjonen to operasjonsnivåer - oppgavenivået og avbruddsnivået. Det logiske nivået til planleggeren er også definert, selv om dette nivået ikke brukes i spesifikasjonen og ikke er synlig for RTOS-brukeren. Det skal bemerkes at til tross for den fullstendig statiske tildelingen av prioriteringer av oppgaver og avbruddsbehandlere, kan det oppstå situasjoner med tidsbegrenset prioritetsinversjon under applikasjonskjøring. Dette skjer når en lavprioritet oppgave forutsetter høyere prioriterte oppgaver, eller en oppgave hindrer kjøring av avbruddsbehandlere opp til en eller annen maskinvareavbruddsterskel. Forekomsten av slike situasjoner skyldes bruken av synkroniseringsprotokollen ved tilgang til kritiske seksjoner og er fullstendig kontrollert av applikasjonen. Imidlertid skjer det ikke under noen omstendigheter en tidsbestemt inversjon av prioriteringer, noe som gjør det mulig å garantere aktualiteten til oppgaveutførelsen med korrekt statisk prioritering. Samsvarsklasser. Et av hovedkravene for OSEK / VDX OS er muligheten til å bruke RTOS på prosessorer med forskjellige kapasiteter, som starter med 8-bits mikrokontrollere med flere titalls kilobyte ROM og flere kilobyte RAM, og slutter med 32-bits prosessorer med hundrevis av kilobyte ROM og RAM. For å oppfylle dette kravet beskriver spesifikasjonen spesifikt fire samsvarsklasser. Samsvarsklasser bestemmes av følgende egenskaper: a) aktivering av flere forespørsel 42 nr. 4, 2001 (om det er tillatt i denne klassen eller ikke); b) støtte for oppgaver med en tilstand av venting, det vil si de såkalte utvidede oppgavene; c) antall oppgaver per prioritert nivå; d) obligatoriske (minimum) kvantitative parametere for RTOS (for eksempel antall kjørbare oppgaver, antall støttede ressurser for tilgang til kritiske seksjoner, etc.). Spesifikasjonen definerer følgende samsvarsklasser. Grunnklasse 1 (BCC1 - Basic Conformance Class 1). Ventende oppgaver og flere vekkeforespørsler støttes ikke, kun én oppgave per prioritetsnivå, det vil si at alle oppgaver har en annen prioritet. Grunnklasse 2 (BCC2). Samme som basisklasse 1, men støtter flere vekkeforespørsler og flere oppgaver per prioritetsnivå. Utvidet klasse 1 (ECC1 - Extended Conformance Class 1). Samme som basisklasse 1, men ventende oppgaver støttes. Utvidet klasse 2 (ECC2). Samme som ECC1, men støtter flere vekkeforespørsler for ikke-ventende oppgaver og flere oppgaver på samme prioritetsnivå. Konformitetsklasser hjelper både RTOS-utviklere og brukere til å karakterisere og bruke systemimplementeringer på riktig måte. Det skal bemerkes at OSEK / VDX OS-leverandører bare kan implementere noen få samsvarsklasser for å oppnå sertifisering av samsvar med standarden. Brukere, spesielt store selskaper, krever vanligvis at applikasjonsutviklere bare bruker visse samsvarsklasser, eller til og med bare én klasse, for å lette integrasjon, redusere ressurskrav (som minne) og ha fleksibiliteten til å endre RTOS-leverandøren. Faktum er at hver påfølgende klasse, selv om den ikke er eksplisitt beskrevet, krever en mer tungvint implementering, så det er fornuftig å begrense applikasjonskravene til minimumskravet. For eksempel krever en fleroppvåkningsforespørsel en betydelig overhead i både minne- og CPU-sykluser, så det er ingen vits i å bruke klasser som støtter multi-request hvis denne funksjonen ikke brukes i applikasjonen. Samsvarsklasser gir en grov klassifisering av RTOS som er nyttig å følge. Samtidig står RTOS-leverandører fritt til å legge til forbedringer i implementeringen av samsvarsklassen. For eksempel støtter mange implementeringer flere oppgaver per prioritetsnivå selv for Base Compliance Class 1. Generelt kan applikasjoner som krever høy ytelse, som for eksempel kontrollsystemer for drivstoffinnsprøytning, bruke Base Class 1 fordi det gir den raskeste oppgavevekslingen. kamakselvinkler og reaktivering av oppgaven (dvs. flere forespørsel om aktivering) betraktes som en omstart. For kroppselektronikk brukes ofte utvidet klasse 1 fordi det er praktisk å implementere tilstandsmaskiner ved bruk av ledige oppgaver. Oppgavestyring. RTOS støtter oppgaveplanlegging med faste prioriteter og tre forskjellige måter planlegging - preemptive, non-preemptive og mixed (i spesifikasjonen er planlegging kombinert med planlegging, og dette begrepet brukes ikke separat). Med forebyggende planlegging skyver en oppgave med høyere prioritet alltid den lavere prioriterte oppgaven ut av behandling. Med ikke-forebyggende planlegging skjer en slik forkjøpsrett bare hvis den lavprioriterte oppgaven frigjør selve prosessoren. I blandet planlegging er noen oppgaver forebyggende og noen er ikke-forebyggende. Det skal bemerkes at avbruddshåndtering er den samme for alle forsendelsesmetoder. Når du planlegger peer-to-peer-oppgaver, planlegges prinsippet først - først utført. Vanligvis bruker applikasjoner forebyggende utsendelse for å oppnå forfallsdatoer ved å bruke relativt enkle prioriteringsregler. Tilsynelatende kan ikke-forebyggende utsendelse brukes i applikasjoner med et betydelig begrenset antall oppgaver og delte ressurser. Fordi den uforutsette oppgavekonteksten inneholder færre prosessorregistre, er kontekstsvitsjer raskere, og derfor kan bedre ytelse oppnås med lavere minnebruk. Samtidig planlegging er nyttig når det er flere lavprioriterte oppgaver som kjører så fort at det ikke er fornuftig å kaste bort prosessortid på å unngå dem. OSEK / VDX OS spesifiserer to typer oppgaver - grunnleggende og avanserte. Grunnleggende oppgaver kan bare være i én av tre tilstander - inaktiv, klar og kjører. Utvidede oppgaver kan valgfritt være i ventende tilstand. Inaktiv tilstand for en oppgave ligner på et generell OS-program som ligger på en harddisk. Det antas, selv om det ikke er eksplisitt beskrevet, at den inaktive oppgaven ikke bruker RAM. Spesifikasjonen legger heller ikke begrensninger på antall inaktive oppgaver i applikasjonen, noe som tyder på at det kan være mange flere slike oppgaver enn aktiverte. Grunnleggende oppgaver støtter prinsippet om engangsutførelse, det vil si at når den er aktivert, går oppgaven fra en inaktiv tilstand til en klar, deretter, avhengig av prioritet og utsendelsesmetode, tar den opp prosessoren og går videre til henrettelsestilstand. Når den er ferdig, avsluttes denne oppgaven og går tilbake til en inaktiv tilstand. Oppgaver av denne typen brukes aldri i generelle operativsystemer, men de er effektive i innebygde sanntidsapplikasjoner. nr. 4, 2001. Utvidede oppgaver kan gå til ventetilstand gjennom hendelsesmekanismen. Hvis alle hendelsene som oppgaven venter på ikke er satt, går oppgaven inn i ventende tilstand til minst én av de forventede hendelsene er satt. Spesifikasjonen definerer ikke hvordan en oppgave fullføres fra en annen eller en avbruddsbehandler. Derfor er overgang til inaktiv tilstand kun mulig fra kjøretilstand. Oppgaven kan med andre ord bare gjennomføres på eget initiativ. En variant av oppgavefullføring er fullføring mens du påkaller en annen oppgave eller en ny forekomst av samme oppgave, som lar deg lage kjeder med oppgaver. Reaktivering av en allerede aktiv oppgave resulterer i en feil i samsvarsklassene BCC1 og ECC1. I BCC2- og ECC2-konformitetsklassene genererer dette en multippel aktiveringsforespørsel, noe som betyr at en ny forekomst av oppgaven vil bli påkalt når oppgaven er fullført. Det bør understrekes at for en fleroppvåkningsforespørsel følger det samme prinsippet for å planlegge peer-to-peer-oppgaver: Planlagt først, utført først. Tilsynelatende kan flere vekkeforespørsler brukes i kommunikasjonsapplikasjoner, for eksempel når meldinger som kommer fra nettverket behandles av en oppgave som påkalles hver gang en ny melding kommer. Avbryt håndtering. Kravspesifikasjonen for avbruddshåndtering består av følgende seksjoner: avbruddsbehandlere (for eksempel avbruddsforespørsler fra eksterne enheter), selektiv kontroll av avbruddskilder, rask kontroll av avbruddsgjenkjenning. Avbruddsbehandlere påkalles når avbruddsforespørsler oppstår, vanligvis fra eksterne enheter, eller fra selve prosessoren (for eksempel for å håndtere unntak). Spesifikasjonen definerer tre kategorier av avbruddsbehandlere. Kategori 1 (ISR-kategori 1). Behandlere i denne kategorien ringer ikke til RTOS. Med andre ord, de endrer ikke tilstanden til oppgaver og andre systemobjekter. Vanligvis blir disse behandlerne utført på de høyeste nivåene av maskinvareprioritet og er designet for å håndtere hendelser med kortest utførelsestid, og uten involvering av RTOS. Kategori 2 (ISR-kategori 2). For behandlere av den andre kategorien gir RTOS automatisk nødvendige forhold for å kunne ringe RTOS-tjenester. Teknisk oppnås dette med søkeord ISR, slik at applikasjonsutvikleren ikke trenger å bekymre seg for å lage en kontekst for å få tilgang til RTOS. Kategori 3 (ISR-kategori 3). Behandlerne i den tredje kategorien er så å si en kombinasjon av behandlerne i den første og andre kategorien. Hvis det under utførelsen av behandleren er nødvendig å referere til 43 Programvareprodukter og RTOS-systemer, må EnterISR () systemkallet utføres for å skape den nødvendige konteksten, og på slutten av behandleren kalles LeaveISR () i rekkefølge å informere systemet om at behandleren har fullført (kategoribehandlere 2 inkluderer implisitt disse samtalene). Nesten alle anrop som gir mening å bli anropt fra avbruddsbehandlere er tillatt i behandlere i den andre og tredje kategorien (mellom anrop til EnterISR / LeaveISR). For eksempel kan avbruddsbehandlere aktivere en oppgave, angi en hendelse for en oppgave, sende en melding, stille inn en alarm og så videre. Avbruddsbehandlere kan nestes, noe som betyr at en behandler kan avbryte en annen. For dette må de riktige maskinvarebetingelsene opprettes. Når nestede avbrudd utføres, forsinkes utsendelsen til den ytterste behandleren fullfører. Det er to problemer å merke seg med bruken av avbruddsbehandlere. Den første er relatert til potensielle vanskeligheter med å bruke lokale variabler i behandlere som tilhører kategori 3. Problemet er at kompilatorer gir minneallokering for de lokale variablene til behandlerfunksjonen helt i begynnelsen av funksjonsutførelsen. Når EnterISR () kalles, kan stabelen overskrives, og disse lokale variablene blir uadresserte, det vil si at tilgang til dem etter å ha kalt EnterISR () vil resultere i feil adressering. Dessverre kan denne situasjonen oppstå selv om applikasjonsutvikleren ikke engang definerer lokale variabler eksplisitt. Fordi kompilatoren kan lage skjulte lokale variabler for å utføre noen operasjoner (for eksempel for å utføre bitoperasjoner på 8-bits prosessorer). Det er derfor spesifikasjonen indikerer eksistensen av et slikt problem, som bare kan unngås helt ved å forlate bruken av behandlere i den tredje kategorien helt. Det andre problemet er knyttet til nesting av en kategori 2 eller 3 handler i den første kategorien handler. I dette tilfellet blir utsendelsen utsatt på ubestemt tid, fordi den ikke kan utføres ved fullføring av den nestede behandleren (siden det fortsatt er en ytre behandler), men den utføres heller ikke når den ytre behandleren er fullført, fordi behandleren av den første kategorien samhandler ikke med OS. For å unngå denne situasjonen anbefaler spesifikasjonen å prioritere avbruddsbehandlere riktig. Spesifikasjonen for selektiv avbruddskildekontroll inkludert i spesifikasjonen har blitt kritisert på grunn av at applikasjonsprogramgrensesnitt som støtter deaktivering eller muliggjøring av gjenkjenning av en avbruddsforespørsel fra en bestemt kilde (enhet), ikke kan spesifiseres på en plattformuavhengig måte, derfor oppnås ikke portabiliteten til applikasjoner som bruker slike avbruddskilder. I tillegg, når du bruker disse tjenestene, kan du oppleve en ubegrenset tidsavbrudd deaktivering, noe som fører til maskinvarefeil. For eksempel kan en lavprioritet oppgave som deaktiverer avbrudd ved mottak av en seriell portbyte for en kort tid bli forhindret av høyere prioriterte oppgaver, og deretter vil den "korte tiden" trekke ut i det uendelige, noe som vil føre til tap av neste bytemottak. Spesifikasjonsarbeidsgruppen er enig i denne kritikken. Det er mulig at funksjonene til selektiv kontroll av avbruddskilder vil bli fjernet fra de neste versjonene av spesifikasjonen. Rask kontroll av avbruddsgjenkjenning lar deg aktivere og deaktivere enten alle prosessoravbrudd, eller bare de som påvirker driften av RTOS. Eventhåndtering. Hendelser lar en utvidet oppgave sette seg selv i en ventende tilstand når hendelsen er slettet, og å sette oppgaven i en klar tilstand når hendelsen er satt. Dessverre er ikke spesifikasjonen veldig klar om kartleggingen av globale hendelser til bitene som brukes av en oppgave, men det antas at hver utvidet oppgave har sin egen hendelsesmaske, bitflagg som kan manipuleres ved hjelp av RTOS-systemanrop. For innebygde applikasjoner som er målrettet av spesifikasjonen, medfører ECC1- og ECC2-oppgaver overhead ved å bruke det tildelte RAM-området for hver oppgaves stabel og manipulere hendelsesbiter. Derfor bør applikasjonsutviklere bruke avanserte oppgaver med stor forsiktighet. Synkronisering ved hjelp av delte ressurser. Spesifikasjonen bruker en spesiell protokoll for å få tilgang til ressurser som beskytter kritiske deler av koden. Denne protokollen kalles OSEK Priority Ceiling Protocol, selv om den ikke beskriver selve Priority Ceiling Protocol, men en protokoll som har flere synonymer, for eksempel Highest Locker Protocol eller Priority Protect Protocol (i POSIX-standarden). Protokollen tillater eliminering av dødlås og ubegrenset prioritetsomvending. Dette oppnås ved å umiddelbart heve prioriteten til oppgaven som ber om den delte ressursen til ressursprioritetsterskelen, som beregnes under systemkonfigurasjon som høyeste (eller høyere) prioritet av alle oppgaver som får tilgang til den ressursen. Derfor, når en ressurs forespørres, er det garantert at ingen annen oppgave som har tilgang til den ressursen blir satt i løpende tilstand. En stor prestasjon for OSEK / VDX OS er utvidelsen av denne protokollen, vanligvis bare brukt for oppgaver, for å avbryte behandlere for å beskytte kritiske deler av kode som deles av oppgaver og avbruddsbehandlere. Dette innebærer at prioriteringene til avbruddsbehandlere og -oppgaver så å si er i samme skala, og at RTOS er i stand til å manipulere forbudet og løsningen av avbruddskontrolleravbruddsnivåer. Selvfølgelig er et slikt opplegg degenerert hvis maskinvaren bare støtter ett avbruddsnivå, men det kan fortsatt brukes i dette tilfellet. Men det er spesielt nyttig å bruke en protokollutvidelse på mikroprosessorer som har et multi-level interrupt system, for eksempel Motorola 68K. Alarmer (kontroll av tidtakere og tellere). Spesifikasjonen definerer et generisk objekt kalt en alarm som brukes til å utløse oppgaver basert på verdiene til tidtakere og tellere, for eksempel lineære eller vinkelforskyvningsmålere. Hver alarm innebærer implisitt en underliggende teller som teller en verdi. Spesifikasjonen definerer ikke et programvaregrensesnitt for å administrere tellere fordi de kan implementeres fullt ut i maskinvare, for eksempel ved bruk av sanntidsklokkeavbrudd. Det skal bemerkes at flere alarmer kan kobles til en måler. Spesifikasjonen krever at RTOS gir en systemtimer. Hver alarm er tildelt en oppgave eller oppgave-hendelse-par. Når en alarm utløses, aktiveres oppgaven eller en hendelse er satt for den. Alarmen utløses når telleren når alarminnstillingen. Alarmen kan stilles både til tellerens absolutte verdi og til den relative. Du kan også stille inn den sykliske verdien for alarmen, og dermed organisere behandlingen av periodiske hendelser. Du kan se at alarmer gir en svært fleksibel og kraftig mekanisme for å håndtere hendelser. Implementeringen av alarmer er imidlertid fortsatt ganske tungvint, spesielt hvis flere alarmer er koblet til måleren. Overføring av meldinger. OSEK / VDX OS-spesifikasjonen inneholder ikke en beskrivelse av meldingsmekanismen, med henvisning til OSEK / VDX COM-spesifikasjonen, som spesifikt beskriver to nettverkskonformitetsklasser CCCA og CCCB (CCC står for Communication Conformance Class) for lokale meldinger. CCCA beskriver ubuffrede meldinger, det vil si meldinger hvis innhold oppdateres hver gang en melding sendes. CCCB definerer i tillegg bufrede meldinger som er round robin. Begge typer meldinger har en fast lengde (og størrelsen på den bufrede meldingskøen), som bestemmes under applikasjonskonfigurasjonsfasen. Når en melding kommer, kan måloppgaven aktiveres, en hendelse kan settes for måloppgaven, eller en egendefinert funksjon kan kalles. For å sertifisere OSEK / VDX OS-implementeringen trenger RTOS-leverandøren bare å implementere CCCA-nettverksoverholdelsesklassen. № 4, 2001 Håndtering av feilsituasjoner og feilsøking. For feilsøkings- og sporingsapplikasjoner beskriver spesifikasjonen krokprosedyrer og utvidet feilinformasjon. Feller leveres av brukeren, men påkalles av operativsystemet selv. Ved forekomst systemfeil en feilfelle påkalles for applikasjonen for å identifisere årsaken til feilen og iverksette korrigerende tiltak. To kroker er utformet for å spore kontekstbryteren til en oppgave, og dermed hjelpe med å spore applikasjonen. Ved starten av RTOS kalles en startfelle, der du kan aktivere oppgavene som initialiserer applikasjonen og initialiserer maskinvaren. I tilfelle en fatal feil kan applikasjonen avslutte RTOS, som påkaller en terminalfelle der en tilbakestilling av maskinvare kan utføres. Utvidet feilinformasjon er gitt systemtjenester RTOS hvis systemet er statisk konfigurert for dette. Beskrivelsen av hver systemfunksjon spesifiserer hvilke feilkoder som kan returneres i standard og utvidede konfigurasjoner. For eksempel, i standardkonfigurasjonen, returnerer påkalling av en oppgave bare en suksesskode, mens den i den avanserte konfigurasjonen rapporterer en feil oppgave-ID og en feilaktig forespørsel om flere påkallelser. Den avanserte konfigurasjonen skal brukes av applikasjonsutviklere under feilsøkingsfasen, og den feilsøkte applikasjonen er konfigurert i standardversjon fordi utvidet feilhåndtering introduserer betydelig overhead, spesielt når det gjelder CPU-bruk. Det er imidlertid et problem knyttet til forskjellen i tidspunktet for applikasjonskjøring i standard og utvidede konfigurasjoner (applikasjonsutviklere bør huske på mulige konsekvenser denne forskjellen). OSEK / VDX OS-standarden oppfyller praktisk talt alle dagens krav til bilapplikasjonsutviklere og brukes av selskaper som Chrysler og BMW. Suksessen til stykklisten skyldes det nære samarbeidet mellom RTOS-kunder og leverandører i stykklisteutvikling og grundige detaljer for å finne en balanse funksjonalitet og implementeringseffektivitet, samt for stabiliteten til de innebygde systemene. Referanser 1. Kopetz H. Sanntidssystemer. Designprinsipper for distribuerte innebygde applikasjoner. Kluwer Academic Publishers. MA, 1997.2 OSEK / VDX Operating System, versjon 2.1 revisjon 1, 13. november 2000.3 OSEK / VDX Communication, versjon 2.2.2, 18. desember 2000.45

En oversikt over de komparative egenskapene til RT-operativsystemer som finnes på det russiske markedet i forhold til deres bruk i luftfartssystemer ledelse.

05.05.2008, man, 23:56, Moskva-tid

Takket være utviklingen datateknologi v i det siste det ble mulig å tildele til en modul oppgavene som ble utført tidligere av flere prosessormoduler, samtidig som vekt- og størrelsesegenskapene til kontrollsystemet ble forbedret og kostnadene redusert. Denne trenden innen luftfartsteknologi har ført til fremveksten av konseptet med integrert modulær avionikk - IMA (Integrated Modular Avionics, IMA).

Problemet med å integrere administrasjonsfunksjoner i en enkelt modul er at det er nødvendig å skille nået delte ressurser(prosessortid, minne, utvekslingskanaler) mellom ulike oppgaver, samtidig som det gir samme grad av pålitelighet og uavhengighet av funksjoner som før. Nøkkelrolle sanntidsoperativsystemet spiller for å løse dette problemet.

For tiden er det flere kommersielle RTOS for kritiske applikasjoner på verdensmarkedet (tabell 1). Denne artikkelen gir en oversikt over RTOS tilgjengelig på det russiske markedet, basert på informasjon fra åpne kilder og forfatternes personlige erfaringer.

Dokumenter som regulerer krav til RTOS

DO-178 (Software Consideration in Airborne Systems and Equipment Certification) definerer kravene til programvareutviklingsprosessen og grundigheten av verifiseringen, avhengig av alvorlighetsgraden. Nivået på programvarekritikalitet bestemmes basert på en analyse av alvorlighetsgraden av konsekvensene av en programvarefeil. Det er fem nivåer av programvarekritikk (fra A til E).

MILS (Multiple Independent Levels of Secutiry) er en spesiell tilnærming til OS-design som forhindrer spredning av applikasjonsprogramvarefeil under kjøring, samt forenkler programverifisering på grunn av programvaremodularitet. Alle søknader legges i såkalte partisjoner. Seksjoner har dedikerte ressurser (minneområde, prosessortid under hver systemsyklus, tilgang til utvekslingskanaler osv.). Tilgang til de tildelte ressursene er garantert av operativsystemet som kjører i supervisor-modus. På én prosessormodul under kontroll av ett OS kan applikasjonsprogramvare med forskjellige kritikalitetsnivåer kjøre - hvis det oppstår en feil i mindre kritisk (og følgelig mindre testet) programvare, vil dette ikke påvirke driften av andre partisjoner i uansett, siden forsøk på å "rane" andres ressurser vil bli blokkert av operativsystemet. MILS ideer gjenspeiler ideene til IMA og DO-178B.

Feil 404. Finner ikke siden.

Kanskje dette skjedde av en av disse grunnene:

- feil under inntasting av sideadressen (URL)
- etter en "ødelagt" (ikke-fungerende, feil) lenke
- den forespurte siden har aldri vært på siden eller den har blitt slettet

Du kan:

- gå tilbake ved å bruke nettleserens Tilbake-knapp
- sjekk stavemåten til sideadressen (URL)
- bruk nettstedskartet eller gå til hovedsiden

Avionics Application Software Standard Interface (ARINC-653) spesifiserer et APEX-apsom støtter MILS-stilklausulbegrepet. Dette grensesnittet inkluderer funksjoner for å administrere seksjoner, prosesser, tidsdeling, kommunikasjon mellom seksjoner og innenfor en seksjon, overvåking av systemets tilstand. Det skal bemerkes at ARINC-653-standarden beskriver en generelt akseptert tilnærming til implementering av MILS-ideer for IMA, selv om det kan være andre implementeringer. Et ARINC-653-kompatibelt fly RTOS har fordelene med denne standarden er godt kjent og forstått av internasjonale sertifiseringsorganer, derfor er det lettere å få et DO-178B samsvarssertifikat for et system bygget i henhold til denne standarden.

Gjenbrukbare programvarekomponenter standard. I henhold til DO-178B er programvaren til et eller annet luftfartsapplikasjonssystem fullt sertifisert, selv om det bruker moduler (komponenter) som allerede er sertifisert tidligere som en del av et annet system. Et av de siste initiativene fra FAA (Federal Aviation Certification Agency, USA) er å definere kriterier for gjenbruk av programvare uten ny sertifisering. Komponenter som kanskje ikke re-sertifiseres kalles RSC (Reusable Software Components). Det krever mer innsats å bli sertifisert for RSC, men da gir RSC betydelige besparelser.

Russiske dokumenter som definerer programvarekrav (inkludert RTOS):

• GOST R ISO / IEC 51904-2002 ("Programvare for innebygde systemer. Generelle Krav til utvikling og dokumentasjon ") - analog av DO-178B for militær luftfart;
• KT-178A ("Kvalifikasjonskrav del 178A") - analog av DO-178B for sivil luftfart;
• GOST R ISO / IEC 12207-99 ("Informasjonsteknologi. Prosesser Livssyklus programvare").

Sammenligning av RT OS ble utført i henhold til 13 parametere, som tar hensyn til tekniske kriterier, enkel utvikling og økonomiske parametere.

Tidsparametere til OS

Et av hovedkravene for RT OS er minimumsforsinkelsen for behandling av en hendelse. I praksis betyr dette at følgende parametere må være små:

• avbruddsresponstid - tiden mellom den faktiske forekomsten av et avbrudd og begynnelsen av behandlingen av den første instruksjonen til avbruddsbehandleren;
• kontrollstrømsbyttetid - tidspunkt for veksling mellom to strømmer i en prosess;
• prosesskontekstbyttetid (kun for operativsystemer som støtter prosessmodellen) - tiden for å bytte mellom to kontrolltråder som tilhører to forskjellige prosesser.

Dessverre er det ikke lett å objektivt sammenligne de spesifiserte parametrene til forskjellige RT-operativsystemer, fordi disse parametrene ikke bare avhenger av kvaliteten på operativsystemet, men også av egenskapene til den brukte maskinvareplattformen. Ideelt sett bør alle sammenlignede operativsystemer installeres på samme maskinvareplattform, hvoretter de tilsvarende målingene bør gjøres. Men selv disse målingene vil ikke gi et objektivt resultat, fordi ulike operativsystemer kan være mer eller mindre tilpasset spesifikk maskinvare.

For å sammenligne tidsparametrene bruker denne artikkelen fragmenterte data funnet på nettet, som ofte innhentes når man tester operativsystemet på forskjellig utstyr, mens sammensetningen og arten av testene ikke alltid er klar.

Ganske objektive data kan betraktes som resultatene oppnådd av ekspertene fra magasinet Dedicated System, som utførte testing og praktisk sammenligning av QNX RTOS 6.1, VxWorks AE 1.1 og Windows CE.NET på x86-plattformen. Selv om disse dataene nå er utdaterte, kunne ikke forfatterne av denne artikkelen finne nyere materiale. Bord 2 viser en prøvesammenligning av ytelsen til QNX Neutrino 6.1, VxWorks AE 1.1. Dedikerte systemer-rapporten favoriserte QNX når det gjelder ytelse, med et poengforhold på 9: 5 (QNX: VxWorks), fordi VxWorks møtte to feil under testing og måtte kontakte support for å fikse dem.

Bord 3 gir data om egenskapene til LynxOS. Sammensetningen av testene som er brukt er ikke spesifisert. Når det gjelder dataene om egenskapene til LynxOS, er den fjerde kolonnen interessant (testing på x86-plattformen). Sammenlignet med VxWorks og QNX viser LynxOS RT OS en enorm ventetid som svar på avbrudd (mer enn 5 ganger). Kontekstbyttetiden (som betyr byttetiden mellom to tråder i samme prosess) er den samme med QNX og er omtrent 1,5 ganger mindre enn for VxWorks.

Stabilitet av tidsparametere

I tillegg til tidskarakteristikkene for RT OS, er stabiliteten til disse egenskapene også viktig. Det er dette kriteriet som i stor grad bestemmer "rigiditeten" til RT OS, dvs. forutsigbarhet av databehandlingstid, tidspunkt for utgivelse av resultater, etc.

Basert på dataene fra magasinet Dedicated System, ligger QNX foran VxWorks i dette kriteriet både når det gjelder spredning av egenskaper i en serie tester av samme type (forholdet mellom maksimal tid og gjennomsnittsverdi er mye mindre) , og med en økning i belastningen (tidspunktet for å bytte en strøm med en økning i antall tråder 2 ... 128 enheter for QNX vokste bare 1,65 ganger, mens for VxWorks - 2,24 ganger).

I følge dataene innhentet i RTSoft-selskapet er det kjent at LynxOS har omtrent samme egenskaper som VxWorks.

Ressurstilgangskontroll

Vi vil evaluere kvaliteten på tilgangskontrollen som tilbys av dette eller det andre RT OS til kritiske ressurser datasystem som minne og prosessortid.

Det første spørsmålet som skal besvares er om operativsystemet støtter prosessmodellen. Prosessen er logisk objekt, som eier en eller flere tråder, tilhørende ressurser og kontekst - innholdet i registre og tellere til enhver tid.

Prosessenes oppgave er:

• i å differensiere tilgang til tilfeldig tilgangsminne mellom ulike programmer under utførelse;
• ved å avgrense omfanget av globale variabler på kompileringstidspunktet (det er kritisk om applikasjonsprogramvaren er skrevet i C, som ikke støtter slik avgrensning).

Segmentering gir også separasjon av adresserom (i denne forstand dupliserer sharding og prosessfunksjoner hverandre). I tillegg gir sharding hvert segment som inneholder en eller flere prosesser (eller tråder hvis operativsystemet ikke støtter prosessmodellen) et garantert tidsbudsjett. Således, hvis en høyprioritet tråd går i sløyfe og forstyrrer segmentet, vil alle andre segmenter motta CPU-tid i samsvar med innstillingene som ble bestemt på designstadiet og fortsette å fungere normalt.

LynxOS og QNX støtter både prosessmodell og sharding. VxWorks OS har en sønderdelingsmekanisme, men støtter ikke prosessmodellen. Generelt er dette akseptabelt fordi sharding gir separasjon av adresseområder. Men mangelen på prosesser medfører noen ulemper. Vanligvis utføres segmentering basert på det tiltenkte formålet med programvaren og dens kritikkverdighet. For eksempel kan et bestemt segment inneholde programvare for å kontrollere fly- og navigasjonskomplekset, som har et høyt kritikalitetsnivå. Men denne programvaren gir også nok komplekst kompleks, som ville være logisk å dele inn i uavhengige (minnemessig) moduler. VxWorks OS gir ikke en slik mulighet, det vil si at segmentet vil bestå av tråder med delt minne, noe som kompliserer organiseringen av parallell utvikling og til slutt reduserer påliteligheten til programvaren.

Støtte for multiprosessor og distribuerte systemer

Kostnaden for multiprosessormoduler har falt betydelig i det siste, og derfor brukes de i økende grad i innebygde systemer. Selvfølgelig må RT OS gi støtte for slike kort.

En annen lovende retning i konstruksjonen av ACS er distribuerte systemer, hvor modulene er adskilt fra hverandre, og kommunikasjon mellom dem skjer gjennom et nettverksmiljø. Igjen, det anvendte RT OS må ha praktiske og pålitelige midler for å organisere interaksjonen mellom moduler: støtte for ulike nettverksprotokoller, midler for å sikre nettverksgjennomsiktighet.

PB OS QNX tilbyr støtte for multiprosessorkort. For VxWorks har denne støtten nettopp blitt annonsert. En flyversjon av LynxOS med støtte for multiprosessorkort eksisterer heller ikke ennå.

Når det gjelder støtte for nettverksprotokoller, bør det bemerkes at RT OS LynxOS, VxWorks og QNX har omtrent like (og brede) muligheter. En ekstra fordel med RT OS QNX er dens spesielle arkitektur for nettverksundersystemet, som gir nettverks "gjennomsiktighet" av applikasjonsprogrammer: enhver prosess kan kalle en annen prosess på en ekstern modul akkurat som en prosess på en lokal modul.

Støtte for filsystem

Muligheten til å lagre informasjon i form av filer er praktisk og tradisjonell. Omvendt skaper mangelen på en slik mulighet vanskeligheter med å lagre sjelden endrede data og lage distribuerte systemer.

Bord 4 viser filsystemstøtten for hvert av de betraktede operativsystemene.

QNX har den bredeste filsystemstøtten. I tillegg er flash-filsystemet feiltolerant.

Kvaliteten på dokumentasjonen

Kvaliteten på RV OS-dokumentasjonen LynxOS, VxWorks, QNX er ganske høy. Det er imidlertid noen klager på dokumentasjonen:

• QNX - utmerket beskrivelse av arkitektur og designprinsipper, men utilstrekkelig beskrivelse av API (ikke alle parametere er beskrevet, det er inkonsekvenser);
• VxWorks - det er ingen forklaring på operasjonsprinsippene og en utilstrekkelig beskrivelse av den komplekse prosessen med å konfigurere operativsystemet.

Imidlertid jobber bedrifter med kvaliteten på materialet. Dokumentasjon på gjeldende versjon QNX (6.3.2) er betydelig utvidet, noen deler er omarbeidet.

Kvalitet teknisk støtte

Når det gjelder kvaliteten på offisiell teknisk støtte, er den utvilsomme lederen LynxOS. LynuxWorks lover å svare på alle tekniske spørsmål innen 4 timer etter at forespørselen ble publisert. LynxOS distribueres i Russland av RTSoft, som har en stor stab som er i stand til å tilby kvalifisert bistand... Ulempen med LynxOS er at operativsystemet ennå ikke er veldig vanlig i Russland, derfor er det ikke noe etablert brukerfellesskap, og det er ikke engang et russiskspråklig forum.

QSS (produsent av QNX) tilbyr også teknisk støtte av god kvalitet, men rask respons er ikke garantert. I motsetning til LynxOS har RT OS QNX et godt organisert brukerfellesskap både i utlandet og i Russland. De fleste spørsmål kan besvares i disse foraene. QNX i vårt land distribueres av SVD Embedded Systems, hvis ansatte er i stand til å gi kompetent teknisk støtte og utføre arbeid med å tilpasse OS til spesifikke prosessorkort. I tillegg har selskapet direkte kontakter med QSS og kan få råd om komplekse problemstillinger fra utvikleren av RT OS QNX.

WindRiver, utvikleren av VxWorks, følger tradisjonelt en lukket teknisk policy, det vil si at det er ganske vanskelig å få informasjon om driftsprinsippene til operativsystemet. Dette operativsystemet har heller ikke et russiskspråklig forum. RV OS VxWorks i vårt land distribueres av AVD Systems, som hovedsakelig er engasjert i salg av ferdige programvare- og maskinvareløsninger for utenlandsk produksjon.

Åpen kilde

Et åpent RT OS har minst tre fordeler:

• kan løse komplekse problemer uten å involvere teknisk støtte;
• lettere å sertifisere (for fravær av bokmerker, etc.);
• mer dynamisk utvikling, siden utvikleren av RT OS ofte mottar ikke bare forespørsler om å rette feil, men også forslag for å eliminere feil, forbedre systemet. Åpen kildekode RTOS-utviklingssamfunn har en tendens til å vokse mye raskere og er bedre organisert. Uavhengige eksperter ser ut til å hjelpe til med å løse problemene til den tekniske støttetjenesten og delta i utvikling, feilsøking og testing av systemet.

Siden september 2007 har QSS åpnet kildekoder QNX-kjerner (inkludert adaptiv partisjonering, høy tilgjengelighet). Litt senere ble kildekodene til nettverksundersystemet åpnet. Betaversjonen 6.4.0 er for øyeblikket tilgjengelig for nedlasting på den offisielle nettsiden.

Det skal bemerkes at i dag er ikke alle QNX-moduler åpen kildekode (for eksempel er det ingen koder for grafikk og filsystemer), og lisensen pålegger en begrensning på bruken av "kilde": bare for ikke-kommersiell bruk. En QNX-bruker mottar imidlertid fordelene ovenfor gratis.

Kildekodene for LynxOS og VxWorks er kommersielt tilgjengelige. Prisen for et slikt produkt er omsettelig.

Verktøyverktøy

Tilgjengeligheten av gode verktøy bestemmer i stor grad kvaliteten og hastigheten på utviklingen av applikasjonsprogrammer for et bestemt OS. Det skal bemerkes at LynxOS, VxWorks og QNX for tiden tilbyr verktøy av god kvalitet som inkluderer et integrert utviklingsmiljø (IDE) og feilsøking av applikasjonsprogramvare, programprofileringsverktøy (for å oppdage " flaskehalser"Etter ytelse, minne, etc.). Ergonomikken til IDS for disse RT-operativsystemene er generelt ikke dårligere enn de utviklede utviklingsverktøyene for konvensjonelle operativsystemer (for eksempel MS Windows).

Portabilitet av applikasjonsprogramvare

Portabiliteten til applikasjonsprogramvaren gir muligheten til å bruke den for andre operativsystemer (inkludert ikke-RT-operativsystemer). Portabilitet gir en viss uavhengighet til utvikleren av applikasjonsprogramvare fra RT OS: om nødvendig kan du bytte til et annet OS med lave kostnader.

Evnen til å skrive bærbar programvare er definert i dette øyeblikket samsvar med POSIX-standarden. Alle betraktede RV-operativsystemer støtter POSIX 1003.1-standarden. LynxOS har en fordel - dette operativsystemet har binær kompatibilitet med Linux OS. Det er Linux-applikasjoner kan kjøres under LynxOS uten å rekompilere. Motsatt kan LynxOS-applikasjoner kjøre på Linux (versjon 2.4.x med glibs versjon 2.2.2 C-bibliotek).

Resten av RT-operativsystemene må kompileres på nytt for å kjøre Linux-applikasjoner. I dette tilfellet kan prosessen med å portere selv POSIX-kompatible applikasjoner ofte bli ganske arbeidskrevende på grunn av forskjellen i implementeringen av biblioteker og kompilatorer.

Støtte for prosessorarkitekturer

Innenlandske utviklere av kontrollsystemer for luftfart i den nåværende overgangsperioden fra interne operativsystemer til kommersielle befinner seg ofte i en situasjon hvor det er nødvendig å velge og tilpasse en RTOS til et allerede eksisterende prosessorkort. I dette tilfellet er en av hovedhensynene når du velger et OS støtte for prosessorarkitekturen som brukes på brettet.

Overholdelse av luftfartsstandarder

I utenlandsk praksis må programvare for avionikksystemer ha et sertifikat for samsvar med DO-178B-standarden. Hvis programvare av forskjellige alvorlighetsnivåer kjøres på én prosessorenhet, må RTOS som brukes støtte konseptet med partisjoner. (Ellers er det nesten umulig å bevise at feilen ikke har spredt seg). Som allerede nevnt er det bedre om RTOS-programmeringsgrensesnittet er i samsvar med ARINC-653-standarden, siden standarden er godt kjent for utenlandske sertifiseringsorganer.

LynxOS er bransjeledende innen compliance. Den støtter ARINC-653, og det er mange eksempler på DO-178B-sertifiserte systemer bygget på toppen av den. Nøkkelpunktet er at LynuxWorks tilbyr et sett med RSC-er (selv om forfatterne av artikkelen ikke er klar over prisen).

VxWorks er ARINC-653-kompatibel, og systemer bygget på toppen av den kan DO-178B-sertifisert (finnes stort antall eksempler).

QNX er ikke ARINC-653-kompatibel, og så langt er det ingen DO-178B-sertifiserte systemer basert på den.

Det skal bemerkes at QNX-systemer i prinsippet kan brukes til å bygge IMA, fordi QNX støtter sin egen metode for å gi konseptet partisjoner, som er et veldig godt alternativ til ARINC-653 og dessuten sparer prosessortid.

Når det gjelder lignende russiske standarder for militær luftfart (GOST R ISO / IEC 51904-2002), er det ennå ikke et enkelt eksempel på et sertifisert system, selv om et slikt system i prinsippet kan utvikles på grunnlag av hvilket som helst av operativsystemene under vurdering. For RT OS QNX pågår det for tiden arbeid med å klargjøre de viktigste OS-modulene for sertifisering.

Utvikling av systemet for opplæringsspesialister

Hastigheten og kvaliteten på opplæringen for personell som arbeider med RT OS og ulike verktøy for utvikling og feilsøking av programvare er direkte relatert til hastigheten på programvareutvikling og dens kvalitet. Ledende selskaper innen innebygd programvare og systemprogramvare, som WindRiver, LynuxWorks, QSS, gjennomfører et storstilt program med kurs og opplæring for å studere bruken av selskapets produkter, inkludert RT OS.

Sammenligningsresultater

RTOS QNX Neutrino er det mest avanserte operativsystemet fra et teknisk synspunkt, har et godt sett verktøy, har relativt lav pris... Mikrokjernearkitektur gir høy pålitelighet og modulariteten til systemene som utvikles. Et ekstra pluss er åpen kildekode. Men det er også en flue i salven: for øyeblikket brukes QNX praktisk talt ikke noe sted i luftfarten, og i denne parameteren taper dette operativsystemet til konkurrenter (LynxOS og VxWorks). En ekstra ulempe med QNX: manglende overholdelse av ARINC-653-standarden.

Det skal bemerkes at QNX Neutrino i prinsippet har alle nødvendige mekanismer for å arbeide i avionikksystemer. I tillegg er påliteligheten og den høye tilgjengeligheten til QNX-baserte systemer bevist i andre bransjer hvor kostnadene ved feil er enda høyere enn i luftfart (atomreaktorkontroll).

Arbeid med forberedelse til sertifisering av QNX Neutrino i henhold til kravene i innenlandske luftfartsstandarder utføres for tiden av SWD Software.

RTOS LynxOS-178 har derimot alle nødvendige sertifikater i utlandet, selv om den etter mange andre kriterier ser mindre foretrukket ut enn QNX Neutrino. Merk at for bruk i russisk luftfartsindustri, må LynxOS-178 RTOS også være sertifisert i henhold til russisk GOST.

VxWorks OS har en lang historie med utenlandske virksomhetskritiske applikasjoner. Analysen vår viser imidlertid at det ser mindre gunstig ut for de to første OS på mange måter. I tillegg undergraves VxWorks' troverdighet av en lukket utviklingsstrategi.

Ekspertgruppe / R & D.CNews

Skrive ut

Karakteristiske trekk ved RTOS versus generelle operativsystemer

Generelle operativsystemer, spesielt flerbrukeroperativsystemer som UNIX, er fokusert på optimal fordeling av dataressurser mellom brukere og oppgaver. I sanntidsoperativsystemer går en slik oppgave i bakgrunnen - alt trekker seg tilbake før hovedoppgaven - for å ha tid til å reagere på hendelser som skjer på anlegget.En annen forskjell er at bruk av et sanntidsoperativsystem alltid er knyttet til med utstyret, med anlegget, med hendelser som skjer på anlegget. Sanntidsoperativsystemet er fokusert på å håndtere eksterne hendelser. Et sanntidsoperativsystem kan være likt i brukergrensesnitt på et generellt operativsystem er det imidlertid strukturert på en helt annen måte. Dessuten er bruken av sanntidsoperativsystemer alltid spesifikk. Hvis et operativsystem for generell bruk vanligvis oppfattes av brukere (ikke utviklere) som allerede klart sett applikasjoner, fungerer sanntidsoperativsystemet kun som et verktøy for å lage et spesifikt sanntids maskinvare- og programvarekompleks. Og derfor mest bred klasse brukere av sanntidsoperativsystemer - utviklere av sanntidssystemer, personer som designer kontroll- og datainnsamlingssystemer. Designe og utvikle spesifikt system sanntid, programmereren vet alltid nøyaktig hvilke hendelser som kan oppstå på anlegget, kjenner de kritiske tidsrammene for å betjene hver av disse hendelsene RT-systemet må ha tid til å svare på en hendelse som har skjedd på anlegget innen en tid som er kritisk for denne hendelsen. Den kritiske tiden for hver hendelse bestemmes av objektet og selve hendelsen, og kan være forskjellig, men responstiden til systemet må forutsies (beregnes) når systemet opprettes. Manglende respons på forutsagt tidspunkt anses som en feil for sanntidssystemer Systemet skal kunne reagere på hendelser som inntreffer samtidig. Selv om to eller flere eksterne hendelser inntreffer samtidig, må systemet klare å reagere på hver av dem i de tidsintervallene som er kritiske for disse hendelsene.

	Sanntids OS	OS for generell bruk
Hovedoppgaven	Ha tid til å reagere på hendelser som skjer på utstyret	Optimalt allokere dataressurser mellom brukere og oppgaver
Hva er det fokusert på	Håndtering av eksterne hendelser	Håndtering av brukerhandlinger
Hvordan er den plassert	Et verktøy for å lage et bestemt maskinvare- og programvarekompleks i sanntid	Oppfattes av brukeren som en samling klare applikasjoner
Hvem er det til	Kvalifisert utvikler	Gjennomsnittlig bruker

Harde og myke sanntidssystemer

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

Harde sanntidssystemer tillater ingen forsinkelser i systemets respons under noen forhold, siden:

• resultatene kan være ubrukelige hvis du kommer for sent
• en katastrofe kan oppstå hvis reaksjonen er forsinket

• kostnaden ved å komme for sent kan være uendelig høy.

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

Myke sanntidssystemer er preget av det faktum at responsforsinkelsen ikke er kritisk, selv om det kan føre til en økning i kostnadene for resultater og en reduksjon i ytelsen til systemet som helhet, for eksempel nettverksdrift. Dersom systemet ikke hadde tid til å behandle neste mottatte pakke, vil dette føre til timeout på sendesiden og re-sending (selvfølgelig avhengig av protokollen). Samtidig går ikke data tapt, men nettverksytelsen reduseres Hovedforskjellen mellom harde og myke sanntidssystemer kan uttrykkes som følger: et hardt sanntidssystem vil aldri være sent ute med å svare på en hendelse, en mykt sanntidssystem bør ikke være sent ute med å svare på en hendelse.

Operativsystemkjernen

Kjernen er den sentrale delen av operativsystemet (OS), som gir applikasjoner koordinert tilgang til dataressurser, minne, ekstern maskinvare, eksterne inngangs- og utdataenheter, og oversetter kommandoene til applikasjonsspråket til språket for binære koder som datamaskinen forstår. Som et grunnleggende element i operativsystemet, representerer kjernen det meste lavt nivå abstraksjoner for applikasjonstilgang til systemressurser som er nødvendige for driften. Som regel gir kjernen slik tilgang til de kjørbare prosessene til de tilsvarende applikasjonene gjennom bruk av kommunikasjonsmekanismer mellom prosesser og applikasjonskall til OS-systemanrop.

Monolitisk kjerne

Den monolitiske kjernen gir et rikt sett med maskinvareabstraksjoner. Alle deler av den monolittiske kjernen opererer i samme adresserom. Dette er et skjema for et operativsystem der alle komponentene i kjernen er bestanddeler av ett program, bruker vanlige datastrukturer og samhandler med hverandre ved å ringe prosedyrer direkte. En monolitisk kjerne er den eldste måten å organisere operativsystemer på. De fleste UNIX-systemer er eksempler på systemer med en monolitisk kjerne.

Verdighet: Arbeidshastighet, forenklet utvikling av moduler.

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

Noen eldre monolittiske kjerner, spesielt UNIX / Linux-systemer, krevde rekompilering hver gang maskinvaren endret seg. De fleste moderne kjerner tillater, mens de kjører, å laste inn moduler som utfører deler av kjernens funksjoner. I dette tilfellet er det ikke komponentene i operativsystemet frittstående moduler, men som bestanddeler av ett stort program kalt den monolittiske kjernen, som er en samling av prosedyrer, som hver kan kalle hver. Alle prosedyrer fungerer i privilegert modus.

Mikrokjerne

Mikrokjernen gir bare grunnleggende prosesskontrollfunksjoner og et minimalt sett med abstraksjoner for arbeid med maskinvare. Det meste av arbeidet gjøres gjennom spesielle tilpassede prosesser kalt tjenester. Det avgjørende kriteriet for «mikrokjerne» er plassering av alle eller nesten alle drivere og moduler i serviceprosesser.

Verdighet: Motstandsdyktig mot maskinvarefeil, feil i systemkomponenter. Den største fordelen med mikrokjernearkitekturen er den høye graden av modularitet til operativsystemkjernen. Dette gjør det mye enklere å legge til nye komponenter. I et mikrokjerneoperativsystem er det mulig, uten å avbryte driften, å laste og losse nye drivere, filsystemer osv. Prosessen med å feilsøke kjernekomponenter er betydelig forenklet, siden en ny driverversjon kan lastes inn uten å starte hele operasjonen på nytt system. Operativsystemets kjernekomponenter skiller seg ikke fundamentalt fra brukerprogrammer, så du kan bruke konvensjonelle verktøy for å feilsøke dem. Mikrokjernearkitektur forbedrer systemets pålitelighet fordi en feil på uprivilegert programnivå er mindre farlig enn en krasj på kjernemodusnivå.

ulemper: Overføring av 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 minneresident for å unngå bytting eller personsøking;
• systemet må være multitasking - for å sikre maksimalt effektiv bruk alle systemressurser;
• kjerne med prioritet til tjenesteavbrudd. Avbruddsprioritet betyr at en kjøreklar prosess med en viss prioritet nødvendigvis går foran i køen fremfor en prosess med lavere prioritet, erstatter raskt sistnevnte og går til utførelse. Kjernen fullfører alt servicearbeid så snart den høyest prioriterte oppgaven kommer. Dette sikrer forutsigbarheten til systemet;
• Priority dispatcher - Lar applikasjonsutvikleren tildele hver oppstartsmodul en prioritet som er utenfor systemets kontroll. Prioritering brukes til å bestemme rekkefølgen som programmer kjøres klare for kjøring. Et alternativ til denne typen planlegging er karusellplanlegging, som gir alle programmer som er klare til å fortsette en lik sjanse 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ø. Prioritert planlegging og en avbruddsprioritert kjerne gir applikasjonsutvikleren full kontroll over systemet. Hvis en hendelse med høyest prioritet inntreffer, slutter systemet å behandle oppgaven med lavest prioritet og svarer på den nylig mottatte forespørselen.

Kombinasjonen av egenskapene ovenfor skaper et kraftig og effektivt utførelsesmiljø 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 enhver sanntidskjøring er kjernen eller dispatcheren. Kjernen administrerer måldatamaskinens maskinvare: sentralenhet, minne og inn-/utdataenheter; kontrollerer driften av alle andre systemer og programvare av anvendt art. I et sanntidssystem opptar avsenderen plass mellom maskinvaren til måldatamaskinen og applikasjonen. programvare... Det gir spesiell tjeneste kreves for å kjøre sanntidsapplikasjoner. En tjeneste levert av kjernen gir applikasjonsprogrammer tilgang til systemressurser som minne eller inn-/utdataenheter.

Kjernen kan tilby ulike typer tjenester:

• Utveksling mellom oppgaver. Det er ofte nødvendig å sørge for overføring av data mellom programmer innenfor samme system.I tillegg blir det i mange applikasjoner nødvendig å samhandle med andre systemer via et nettverk. Intern kommunikasjon kan gjøres gjennom et meldingssystem. Ekstern kommunikasjon kan organiseres enten gjennom et datagram (den beste leveringsmetoden) eller over kommunikasjonslinjer (garantert levering). Valget av denne eller den metoden avhenger av kommunikasjonsprotokollen.
• Dataseparasjon. I sanntidsapplikasjoner er datainnsamling den mest tidkrevende. Data er ofte nødvendig for at andre programmer skal kjøre, eller systemet må utføre noen av funksjonene sine. Mange systemer gir tilgang til delte deler av minnet. Datakø er utbredt. Det finnes mange typer køer, hver med sine egne fordeler.
• Behandler forespørsler fra eksterne enheter. Hver applikasjon kobles i sanntid til en ekstern enhet av en bestemt type... Kjernen må tilby I/O-tjenester som lar applikasjoner lese og skrive til disse enhetene. Det er vanlig at sanntidsapplikasjoner har en spesifikk av denne søknaden ekstern enhet... Kjernen skal gi en tjeneste som gjør det enklere å jobbe med enhetsdrivere. Aktiver for eksempel opptak 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. Eller det kan 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 statusverdier for å oppdage feiltilstander, og bruk av en unntaksbehandler for å avbryte og korrigere feiltilstander.

Oversikt over RTOS-arkitekturer

I løpet av sin historie har arkitekturen til operativsystemer gjennomgått en betydelig utvikling. Et av de første prinsippene for konstruksjon, monolittisk OS (Figur 1), skulle representere OS som et sett med moduler som samhandler med hverandre på forskjellige måter innenfor systemkjernen og gir applikasjonsprogrammer inngangsgrensesnitt for tilgang til maskinvare.

lagdelt OS (Figur 2) Et eksempel på et slikt OS er bra kjent system MS-DOS. I systemer av denne klassen kan applikasjonsapplikasjoner få tilgang til maskinvare ikke bare gjennom systemkjernen eller dens residente tjenester, men også direkte. RTOS ble bygget på dette prinsippet i mange år. Sammenlignet med monolittiske operativsystemer, gir denne arkitekturen en mye større grad av forutsigbarhet av systemresponser, og lar også applikasjonsapplikasjoner raskt få tilgang til maskinvare. Ulempe

slike systemer er mangelen på multitasking i dem. I denne arkitekturen ble problemet med å behandle asynkrone hendelser redusert til å bufre meldinger, og deretter sekvensielt polling av buffere og behandling. Samtidig ble overholdelse av de kritiske tjenestevilkårene sikret av den høye hastigheten til databehandlingskomplekset sammenlignet med hastigheten til eksterne prosesser.

Figur 2. Lagdelt OS-arkitektur

En av de mest effektive arkitekturene for å bygge sanntidsoperativsystemer er klient-server-arkitekturen. Det generelle opplegget for operativsystemet som opererer på denne teknologien er vist i figur 3. Hovedprinsippet for denne arkitekturen er å bringe OS-tjenester i form av servere til brukernivået, og mikrokjernen utfører funksjonene til en avsender av meldinger mellom klienten tilpassede programmer og servere - systemtjenester. Denne arkitekturen gir mange fordeler når det gjelder krav til RTOS og innebygde systemer. Disse fordelene inkluderer:

1. Påliteligheten til OS øker, siden hver tjeneste er faktisk en frittstående applikasjon og det er lettere å feilsøke og spore feil.

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

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

start systemet på nytt.

Figur 3. Bygge et OS ved å bruke en klient-server-arkitektur

Dessverre er det i dag ikke mange operativsystemer som er implementert på klient-server-basis. Blant de velkjente RTOS-implementerende mikrokjernearkitekturen er OS9 og QNX.

Liste over brukt litteratur:

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

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/

OS sanntid

1. Introduksjon: Funksjoner i sanntidsoperativsystemer

1.1. Prosesser, tråder, oppgaver

1.2. Planlegging, prioriteringer

1.3. Hukommelse

1.4. Avbryter

1.5. Klokker og tidtakere

1.6. RTOS-standarder

1.6.1. POSIX

1.6.2. DO-178B

1.6.3. ARINC-653

1.6.4. OSEK

1.6.5. Sikkerhetsstandarder

1.7. Konfigurerbarhet av operativsystemer

2. Korte kjennetegn ved de vanligste RTOSene

2.1. VxWorks

2.2. QNX Neutrino RTOS

2.3. RTEMS

2.4. ChorusOS

2.5. Sanntidsutvidelser for Windows NT

2.5.1. RTXtilWindows NT

2.5.2. I tide

2.5.3. Microsoft Windows innebygd

2.6. TinyOS

2.7. OSEK / VDX

2.8. OSE RTOS

2.9. Contiki

2.10. pSOS

2.11. INTEGRITET

2.12. LynxOS

2.13. Mikrovare OS-9

2.14. GRACE-OS

2.15. C UTFØRENDE

2.16. CMX-RTX

2.16.1. CMX-TINY +

2.17. Helvete

3. OS utviklet spesielt for bærbare enheter

3.1. ITRON

3.2. Windows CE

3.3. JavaOS

3.4. Jbed

3.5. Nucleus RTOS

3.6. SMERALDER

3.7. CORTEX

3.8. DeltaOS

3.9. Palm OS

3.10. Symbian OS (EPOC)

4. Tilpassbarhet av operativsystemer

4.1. Menneskelig tilpasning

4.1.1. Statisk tilpasning initiert av designeren

4.1.2. Administrator initierte dynamisk tilpasning

4.2. Søknadsinitiert tilpasning

4.2.1. Tilpasning fra applikasjonsnivå

4.2.2. Kjernetilpasning

4.3. Automatisk tilpasning

5. Sammendragstabeller over kjennetegn ved RTOS-egenskaper

Vedlegg A. Liste over forkortelser

Vedlegg B. Terminologi

Litteratur

Liste over RTOS referert til i denne teksten, print og web

1. Introduksjon: Funksjoner i sanntidsoperativsystemer

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

Hovedkravet for RTOS er kravet om å sikre forutsigbarhet eller determinisme oppførselen til systemet under de verste ytre forholdene, som skiller seg kraftig fra ytelses- og hastighetskravene til generelle operativsystemer. En god RTOS har forutsigbar oppførsel under alle oppstartsscenarier (samtidige avbrudd og trådkjøring).

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

Det er vanlig å skille mellom myke og harde sanntidssystemer. V harde systemer i sanntid fører manglende evne til å gi et svar på eventuelle hendelser på et gitt tidspunkt til feil og umuligheten av å fullføre den tildelte oppgaven. I det meste av russiskspråklig litteratur kalles slike systemer systemer med deterministisk tid. I praktiske applikasjoner bør reaksjonstiden holdes på et minimum. Systemer som ikke faller inn under definisjonen av "hard" kalles myke sanntidssystemer. det er fortsatt ingen klar definisjon for dem i litteraturen. Myke sanntidssystemer har kanskje ikke tid til å løse problemet, men dette fører ikke til systemsvikt som helhet. I sanntidssystemer er det nødvendig å innføre en viss direktivperiode (i den engelskspråklige litteraturen - frist), før utløpet av denne oppgaven må nødvendigvis (for myke sanntidssystemer - helst) fullføres. Denne fristen brukes av oppgaveplanleggeren både til å gi en prioritet til en oppgave når den starter og når du velger en oppgave som skal kjøres.

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

OS må være forgjengelig og multitasking,

OS må ha konseptet prioritet for tråder,

OS må støtte forutsigbare synkroniseringsmekanismer,

OS må gi en mekanisme for å arve prioriteringer,

OS-adferd bør være kjent og forutsigbar (forsinkelser i behandling av avbrudd, forsinkelser i oppgavebytte, sjåførforsinkelser, etc.); dette betyr at i alle scenarier for systemarbeidsbelastning, a maksimal tid respons.

I løpet av de siste 25-30 årene har strukturen til operativsystemer utviklet seg fra en monolittisk til en flerlags OS-struktur og videre til en klient-server-arkitektur. Med 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 under driften av et slikt system. Det er heller ikke mulig å distribuere operativsystemet på et multiprosessorsystem. I en flerlagsstruktur påvirker endringer i ett lag tilstøtende lag; dessuten er referansen gjennom laget umulig. For sanntidssystemer må det gis direkte tilgang til hvert OS-lag, og noen ganger direkte til maskinvaren.

Hovedideen med klient-server-teknologien i OS er å holde OS-basen på et minimum (planlegger og synkroniseringsprimitiver). All annen funksjonalitet tas ut til et annet nivå og implementeres gjennom tråder eller oppgaver. Samlingen av slike serveroppgaver er ansvarlig for systemanrop. Applikasjoner er klienter som ber om tjenester gjennom systemanrop.

Klient-server-teknologi muliggjør skalerbare operativsystemer og forenkler distribusjon på et multiprosessorsystem. Under systemdrift forårsaker ikke utskifting av en modul en "snøball"-effekt; dessuten fører en svikt i en modul ikke alltid til svikt i systemet som helhet. Nå kan du dynamisk laste og losse moduler. Hovedproblemet i denne modellen er minnebeskyttelse, siden serverprosessene må beskyttes. Hver gang en tjenesteforespørsel gjøres, må systemet bytte fra applikasjonskonteksten til serverkonteksten. Med støtte fra 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 planlegging av oppgaver, og implementerer også deres interaksjon. Til tross for å minimere OS-abstraksjoner i kjernen, må mikrokjernen fortsatt være klar over prosessabstraksjonen. Alle andre konseptuelle abstraksjoner av operativsystemer flyttes utenfor kjernen, påkalles på forespørsel og kjøres som applikasjoner.

La oss vurdere de konseptuelle abstraksjonene til operativsystemet gjennom prisme av krav til sanntidssystemer.