(Realtid Operativ system s - RTOS) är mjukvaruverktyg och är avsedda för underhåll digitala system i fall där:

● systemet måste tillhandahålla inte bara resultatet av behandlingen av den mottagna informationen, utan också hur lång tid det tar att få resultatet. RTOS krävs, tillsammans med att erhålla det erforderliga resultatet, för att implementera specificerade tidsparametrar: tidsintervall mellan händelser och svar eller en specificerad frekvens för att ta emot externa data och utfärda resultat;

● systemet kan utföra flera uppgifter samtidigt. Typisk göra flera saker samtidigt Operativsystemet allokerar lika mycket tid till varje uppgift (program), vilket ger användaren intrycket av att alla program körs samtidigt. Ett realtidsoperativsystem är ett specialfall av ett multitasking-operativsystem optimerat för implementering av kontrollprocesser. Den reagerar snabbt på externa händelser och låter dig simulera driften av flera processorer, som var och en styr en enhet. Därför, för att styra ett komplext system med en enda processor, är det tillrådligt att använda en RTOS som kan koordinera utförandet av olika uppgifter. Ett exempel på en RTOS är ett hisskontrollsystem.

Funktionsprincip för RTOS

När en begäran tas emot kontrolleras indata för att lösa problemet. Om de är närvarande börjar uppgiften att utföras. OM de nödvändiga indata saknas, går RTOS vidare till nästa uppgift (om det finns en begäran om att utföra den). Avbrott används för att ta emot indata och köra motsvarande uppgift. En uppgift startas vanligtvis genom att flytta den från en kö med väntande uppgifter till en kö av uppgifter som ska utföras.

Varje uppgift har en ingångskö av meddelanden, som den endast kan bearbeta under ett tilldelat tidsintervall eller när en avbrottsbegäran görs. Om svaret tar för lång tid placeras uppgiften tillbaka i exekveringskön och kontrollen överförs till nästa uppgift.

Systemresurser ( hårddiskar, timers, inmatnings-/utgångsenheter, etc.) är vanligtvis endast tillgängliga för vissa uppgifter. Detta gör att du kan organisera en kö av förfrågningar om resurser på ett sådant sätt att flera uppgifter förhindrar samtidig åtkomst till en resurs.

Krav för RTOS.

Modernt PB OS måste uppfylla följande krav:

● kort svarstid (att få resultat);

● implementering av multitasking-läge med en flexibel prioriteringsmekanism;

● liten mängd minne (tillräckligt för att placeras i applikationssystemets inbyggda minne);

● tillgång till servicefunktioner och stödverktyg för utveckling av applikationsprogram och ett antal andra.

För närvarande, RTOSer som har olika egenskaper och testade inom sådana användningsområden som produktionsautomationssystem, instrumenteringssystem, telekommunikationsutrustning, flyg- och militärutrustning, transport, säkerhetssystem, etc.

Typer av RTOS

Det finns två typer av RTOS:

● hårda realtidssystem, som upptar en liten mängd minne och har minimal svarstid, men har mycket begränsade serviceverktyg. De är implementerade på modulbasis, vilket gör att du bara kan använda de verktyg som behövs i en given applikation. Resultatet är en betydande minskning av minneskrav och svarstid för en given applikation;

● mjuka realtidssystem, som kräver mer minne, har längre svarstid, men uppfyller ett brett spektrum av användarkrav när det gäller uppgiftsserviceläge och servicenivå. Gränssnittsverktyg för mjuka realtidssystem möjliggör användning av högeffektiva felsökningsverktyg eller integrerade utvecklingsmiljöer.

Mjukt realtidssystem.

Låt oss överväga denna typ av system med exemplet med OS-9-systemet från Microwave Systems. OS-9 använder IBM-PC som en instrumentell dator, som körs in Windows-miljö, eller Sun, HP, IBM RS/6000-arbetsstationer med operativsystem av UNIX-typ. Egenskaper OS-9:

● modularitet, som ger möjlighet att konfigurera mål-RTOS i enlighet med den klass av uppgifter som löses. Genom att eliminera oanvända moduler kan du minska minnesutrymmet och minska systemkostnaderna;

● strukturens flexibilitet, vilket ger omkonfigurering av systemet och utökar dess funktionalitet. Funktionella komponenter OS–9:

● realtidskärna (kärna OS –9);

● allmänna in-/utgångsfaciliteter (I/O-man);

● filhanterare;

● verktyg för mjukvaruutveckling.

OS –9 funktionskomponenter är designade som fristående moduler som kan tas bort eller läggas till med enkla kommandon som inte kräver omkompilering eller omlänkning. Genom att kombinera moduler kan du skapa måloperativsystem med olika funktionalitet.

Tänk på de som anges ovan funktionella komponenter.

Realtidskärna

Systemet innehåller två typer av kärnor:

● Atomic core, som implementerar ett minimum antal servicefunktioner (fjärrladdning, kommunikation med lokalt nätverk, styrning av slavmikrokontroller). Kärnan används i system inbäddade i olika utrustningar, har en liten volym (24 KB) och ger minimal svarstid (3 μs vid en klockfrekvens på 25 MHz);

● Standardkärna, tillhandahåller ett brett utbud av service- och utvecklingsfunktioner applikationsprogram, vars implementering kräver en större mängd minne (upp till 512K byte ROM och 38K byte RAM). Genom att byta funktionella moduler kärnor kan du implementera system av varierande komplexitet och syfte: från styrenheter inbyggda i hårdvara med inbyggd mjukvara och enkla in-/utgångsfaciliteter till komplexa funktionella system klass av arbetsstationer med avancerat nätverksstöd och tillhandahållande av olika servicefunktioner, inklusive multimedia.

OS –9-systemet ger användaren möjlighet att välja en kärna beroende på systemets funktionella syfte. Allmänna in-/utgångsmöjligheter. Det fysiska gränssnittet för OS –9 med en mängd olika externa enheter tillhandahålls av en stor en uppsättning förare, skapat både av Microwave Systems och många utvecklare av utrustning som använder detta operativsystem för specifika applikationer. Filhanterare. Dessa inkluderar moduler som styr logiska dataflöden. Var och en av modulerna har en specifik funktionellt syfte och specifikation. Filhanterare kan delas in i tre grupper:

● standardhanterare utformade för att utföra sådana grundläggande funktioner för utbyte med externa enheter som att organisera en kö av inkommande kommandon, hantera byte och blockera seriell utbyte och utbyte med direkt minnesåtkomst;

● nätverks- och kommunikationshanterare som säkerställer drift av OS –9 med olika nätverk och datautbyte via kommunikationskanaler med de vanligasterna;

● grafiskt gränssnitt och multimediaapplikationshanterare. Verktyg för programutveckling. OS-9 innehåller ett mjukvarupaket (BSP) för att stödja utvecklingskort, vilket gör att OS-9 kan arbeta tillsammans med ett antal SBC:er (Single Board Computer). Den kombinerade användningen av BSP och OS–9 låter dig konfigurera målsystemet för specifik tillämpning.

OS–9-systemet innehåller programmeringsstödsverktyg: Ultra C/C++-kompilatorer, EM ACS-textredigerare, tre typer (inklusive symboliska) felsökningsverktyg, en uppsättning verktyg för att organisera kontroll och montering av mjukvaruprodukter. Dessutom finns det en stor uppsättning (OS-9-kompatibla) programmeringsstödverktyg som utvecklats av andra företag. FastraTill. FasTrak-miljön levereras med OS-9 och ger användaren den mest kompletta uppsättningen av programmerings- och felsökningsverktyg. En del av FasTrak-mjukvaran är installerad på verktygsdatorn och en del är installerad på användarens målsystem. FasTrak-miljön integrerar alla verktyg som behövs för att stödja design/felsökning av målsystem. Versionen av FasTrak-miljön för att arbeta på en IBM PC innehåller:

● en textredigerare med, som möjliggör redigering i ett användarvänligt format;

● Ultra C/C++ kompilatorer;

● felsökningsverktyg som tillhandahåller två felsökningslägen: beställnings-- att skapa applikationsprogram, och systemisk- för serviceavbrott, systemsamtal och åtkomst kärna realtid;

● medel för gränssnitt med företagets logikanalysatorer.

FasTrak-miljön är rik på funktionalitet, vilket gör den effektiva medel skapa programvara för olika mikrokontrollersystem.

Microware Systems levererar en rad systempaket inriktad på olika applikationsområden:

● Wireless OS –9 - för utveckling av trådlösa kommunikationsenheter: mobiltelefoner, personsökare, bärbara digitala assistenter (PDA);

● Internet OS –9 - för utveckling av enheter med tillgång till Internet;

● Digital Audio / Video Interactive Decoder (DAVID) OS –9 - för utveckling av distribuerade digitala system interaktiv tv.

Hårt realtidssystem

Låt oss titta på funktionerna i denna typ av system med exemplet på VxWorks-systemet från WindRiver Systems, designat för att fungera med familjer av mikroprocessorer från många tillverkare. VxWorks-systemet installeras på målsystemet som felsöks och fungerar tillsammans med Tornados integrerade utvecklingsmiljö som körs på verktygsdatorn. IBM-datorer som körs i Windows eller SUN, HP, etc. arbetsstationer används som instrumentdator. Kort beskrivning av systemetVxWorks. Den lägre nivån av den hierarkiska organisationen av systemet är realtidsmikrokärnan, som utför de grundläggande funktionerna för att schemalägga uppgifter och hantera deras kommunikation och synkronisering. Minsta uppsättning kärnmoduler tar 20–40K byte minne. Alla andra funktioner - minneshantering, input/output, nätverksutbyte och andra - implementeras av ytterligare moduler. För att stödja grafiska applikationer tillhandahåller VxWorks ett VX-Windows grafiskt gränssnitt.

Om målsystemets minne är begränsat kan du använda RTGL-grafikbiblioteket, som innehåller grundläggande grafikprimitiver, uppsättningar teckensnitt och färger, drivrutiner för typiska indataenheter och grafikkontroller. VxWorks innehåller också olika verktyg för att stödja en mängd olika nätverksprotokoll. Spår given händelser och deras ackumulering i buffertminnet för efterföljande analys utförs i realtid av speciella felsökningsverktyg och spårning systemisk händelser - WindView dynamisk analysator. WindView-analysatorn fungerar på samma sätt som en logisk analysator, och visar tidsdiagram på skärmen av uppgiftsväxlar, meddelandeköposter och andra processer. Stethoscope Data Monitor låter dig analysera dynamiska förändringar i användar- och systemvariabler, inklusive en procedurprofilerare. VxWorks inkluderar:

● mjukvarupaket för att stödja utvecklingstavlor;

● VxSim-simulator, som låter dig simulera multitasking-VxWorks-miljön och gränssnittet med målsystemet på en instrumentell dator, samt utveckla och felsöka programvara utan att ansluta målsystemet.

För omfattande felsökning av målsystem tillhandahåller VxWorks ett gränssnitt med kretsemulatorer och ROM-emulatorer. Integrerad utvecklingsmiljöTornado . Tornado inkluderar VxWorks 5.3-systemet, som inkluderar en kärna i realtid och systembibliotek, programmeringsverktyg, en högnivåfelsökning och ett antal andra systemverktyg. Ytterligare verktyg i Tornado-miljön ger kontroll över felsökningsprocessen, visualisering av målsystemets tillstånd och andra servicefunktioner. Tomado-miljöns öppna arkitektur låter användaren ansluta sina egna specialiserade verktyg och utöka kapaciteten hos standardverktyg.

VxWorks realtidsoperativsystem, tillsammans med den integrerade Tornado-miljön, är ett kraftfullt verktyg för att implementera målsystem som arbetar under stränga restriktioner för mängden minne som används och svarstid på externa händelser.

Skicka ditt goda arbete i kunskapsbasen är enkelt. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara er mycket tacksamma.

Federal Agency for Education

Institutionen för automatiserade styrsystem

Realtidssystem

Introduktion

1. Operativsystem i realtid

1.1 Typer av RTOS

1.2 Struktur för en RTOS

1.3 Processer, trådar, uppgifter

1.4 Planering, prioriteringar

1.5 Minne

1.6 Avbrott

1.7 Klockor och timers

2. Standarder för realtidsoperativsystem

2.1 POSIX standard

2.2 DO-178B standard

2.3 ARINC-653 standard

2,4 OSEK standard

2.5 Säkerhetsnormer

3. Korta egenskaper hos vanliga realtidsoperativsystem

3.2 QNX Neutrino RTOS

3.5 RTX (Real Time Extension för Windows NT)

3.6 INtime (Windows NT Real Time Extension)

3.8 MicroWare OS-9

3.11 Nucleus RTOS

Slutsats

Bibliografi

Introduktion

Koncepten som ligger till grund för de flesta realtidsoperativsystem idag går tillbaka till slutet av 1970-talet och början av 1980-talet.

Realtidsoperativsystem och inbyggda system fungerar i "begränsade" miljöer där minne och processorkraft är begränsad. De måste tillhandahålla tjänster till användare och världen de interagerar med inom strikta tidsramar.

Realtidssystem kännetecknas av mycket blygsamma användargränssnittsmöjligheter, eftersom systemet som överförs till drift är en "svart låda". En mycket viktig del och huvuddraget i ett realtidsoperativsystem är att hantera datorns resurser på ett sådant sätt att en viss operation utförs under exakt samma tidsperiod varje gång den ska utföras och som inte kan utföras överskridits.

I en komplex maskin mer snabbresa delar än nödvändigt, bara för att systemresurser tillåter det, kan leda till katastrofala resultat, såväl som oförmåga att flytta denna del på grund av det upptagna systemet.

Vanligtvis, när man designar ett realtidssystem, är sammansättningen av programmen (uppgifterna) som det utför känd i förväg. Många av deras parametrar är också kända, vilket måste beaktas vid allokering av resurser (till exempel mängden minne, prioritet, genomsnittlig körningstid, öppnade filer, enheter som används, etc.). Därför skapas uppgiftsbeskrivningar för dem i förväg för att inte slösa dyrbar tid på att organisera deskriptorn och leta efter de nödvändiga resurserna för den.

För verklig realtidsimplementering krävs multiprogrammering. Multiprogrammering är huvudmedlet för att öka prestandan hos ett datorsystem, och för att lösa realtidsproblem blir prestanda den viktigaste faktorn.

De bästa prestandaegenskaperna för realtidssystem tillhandahålls av realtidsoperativsystem med en terminal.

1. Operativsystem i realtid

Ett realtidsoperativsystem är en typ av operativsystem.

Det finns många definitioner av begreppet. De vanligaste av dem:

*Ett operativsystem där framgången för ett program inte bara beror på dess logiska korrekthet, utan också på den tid det tog att få detta resultat. Om systemet inte kan uppfylla tidsbegränsningarna måste ett fel registreras;

*POSIX 1003.1-standarden definierar: "Realtid i operativsystem är operativsystemets förmåga att tillhandahålla den nödvändiga servicenivån under en viss tidsperiod";

*Ett operativsystem som reagerar vid förutsägbara tidpunkter på oförutsägbara externa händelser;

*Interaktiva system med konstant beredskap. De klassificeras i RTOS-kategorin baserat på marknadsföringsöverväganden, och om ett interaktivt program kallas "realtid" betyder detta bara att förfrågningar från användaren behandlas med en fördröjning som är omärklig för människor.

Realtidsoperativsystem (RTOS) är utformade för att ge ett gränssnitt till resurserna i tidskritiska realtidssystem. Huvuduppgiften i sådana system är databehandlingens aktualitet.

Huvudkravet för en RTOS är att säkerställa förutsägbarhet eller determinism av systembeteende under de värsta yttre förhållandena, vilket skiljer sig kraftigt från kraven på prestanda och hastighet för universella operativsystem. En bra RTOS har ett förutsägbart beteende under alla scenarier systemstart(samtidiga avbrott och trådutförande).

Det finns en viss skillnad mellan realtidssystem och inbyggda system. Ett inbäddat system är inte alltid nödvändigt att ha förutsägbart beteende, i vilket fall det inte är ett realtidssystem. Men även en snabb blick på möjliga inbyggda system tyder på att de flesta inbäddade system kräver förutsägbart beteende för åtminstone viss funktionalitet, och därför kan dessa system klassificeras som realtidssystem.

Martin Timmerman (direktör för Real-Time Consult och Real-Time User's Support International (RTUSI), som tillhandahåller hård- och mjukvarusupport och utvecklar realtidssystemprojekt) formulerade följande nödvändiga krav för en RTOS:

*operativsystemet måste vara multitasking och förvägsbart;

*operativsystemet måste ha konceptet prioritet för trådar;

*operativsystemet måste stödja förutsägbara synkroniseringsmekanismer;

*operativsystemet måste tillhandahålla en mekanism för att ärva prioriteringar;

*operativsystemets beteende måste vara känt och förutsägbart (avbrottsbehandlingsfördröjningar, uppgiftsbyteförseningar, drivrutinsförseningar, etc.).

Detta innebär att i alla scenarier för systembelastning måste den maximala svarstiden bestämmas.

1.1 Typer av RTOS

Det är brukligt att skilja mellan mjuka och hårda realtidssystem.

I hårda realtidssystem, oförmågan att ge ett svar på eventuella händelser i angiven tid leder till misslyckanden och oförmåga att slutföra uppgiften. I den mesta ryskspråkiga litteraturen kallas sådana system för system med deterministisk tid. I praktiska tillämpningar bör reaktionstiden vara minimal.

Mjuka realtidssystem är system som inte faller under definitionen av "hårt", eftersom Det finns ingen tydlig definition för dem i litteraturen ännu. Mjuka realtidssystem kanske inte har tid att lösa ett problem, men detta leder inte till fel på systemet som helhet.

I realtidssystem är det nödvändigt att införa en viss deadline (i engelsk litteratur - deadline), innan vars utgång uppgiften nödvändigtvis måste (för mjuka realtidssystem - helst) vara klar. Denna deadline används av uppgiftsschemaläggaren både för att tilldela en prioritet till en uppgift när den startas och för att välja en uppgift för exekvering.

1.2 Struktur för en RTOS

Under de senaste 25-30 åren har strukturen för operativsystem (OS) utvecklats från monolitisk till flerlagers OS-struktur till klient-server-arkitektur.

I en monolitisk struktur består operativsystemet av en uppsättning moduler, och ändringar i en modul påverkar andra moduler. Ju fler moduler, desto mer kaos blir det under driften av ett sådant system. Dessutom är det inte möjligt att distribuera operativsystemet på ett multiprocessorsystem.

I en flerskiktsstruktur påverkar ändringar i ett lager intilliggande lager, och dessutom är det inte möjligt att vända genom ett lager.

För realtidssystem måste direktåtkomst till varje lager i operativsystemet tillhandahållas, och ibland direkt till hårdvaran.

Huvudidén med klient-serverteknologi i ett OS är att reducera OS-basen till ett minimum (schemaläggare och synkroniseringsprimitiver). All annan funktionalitet flyttas till en annan nivå och implementeras genom trådar eller uppgifter. En uppsättning sådana serveruppgifter ansvarar för systemanrop. Applikationer är klienter som efterfrågar tjänster genom systemsamtal.

Klient-server-teknik möjliggör skapandet av skalbara operativsystem och förenklar distributionen i ett multiprocessorsystem. När du använder systemet orsakar inte en "snöboll"-effekt att byta ut en modul. Det finns nu möjlighet att dynamiskt ladda och lossa moduler. Huvudproblemet i denna modell är minnesskydd, eftersom serverprocesser måste skyddas. Varje gång en tjänsteförfrågan görs måste systemet växla från applikationskontexten till serverkontexten. Med stöd för minnesskydd ökar växlingstiden från en process till en annan.

I regel majoriteten moderna RTOS byggd på basis av en mikrokärna (kärna eller kärna), som ger schemaläggning och utskick av uppgifter, såväl som deras interaktion. Även om kärnan minimerar OS-abstraktioner, behöver mikrokärnan fortfarande ha en förståelse för processabstraktioner. Alla andra konceptuella abstraktioner av operativsystem flyttas utanför kärnan, anropas på begäran och exekveras som applikationer.

1.3 Processer, trådar, uppgifter

Konceptet med multitasking (pseudo-parallellism) är väsentligt för ett realtidssystem med en processor vars applikationer måste kunna hantera flera externa händelser som inträffar nästan samtidigt.

Konceptet med en process, som kommer från UNIX-världen, är dåligt implementerat i ett multitasking-system eftersom processen har ett tungt sammanhang. Begreppet en tråd uppstår, vilket förstås som en delprocess, eller en lättviktsprocess. Trådar finns i samma processsammanhang, så att byta mellan trådar går väldigt snabbt och säkerhetsproblem tas inte med i beräkningen. Strömmar är lätta eftersom deras registerkontext är mindre, d.v.s. deras styrenheter är mycket mer kompakta. Den overhead som orsakas av att spara och återställa kontrollblock av avbrutna gängor minskar. Storleken på kontrollblocken beror på minneskonfigurationen. Om trådar körs i olika adressutrymmen måste systemet stödja minnesmappning för varje uppsättning trådar.

Så i realtidssystem är processen uppdelad i uppgifter eller trådar. I båda fallen behandlas varje process som en ansökan. Det bör inte vara för mycket interaktion mellan dessa applikationer och i de flesta fall är de av olika karaktär - hård realtid, mjuk realtid, icke-realtid.

1.4 Planering, prioriteringar

Huvudproblemet i en RTOS är uppgiftsschemaläggning, vilket skulle säkerställa förutsägbart systembeteende under alla omständigheter. I samband med schemaläggningsproblem i RTOS studeras och utvecklas två tillvägagångssätt - statiska schemaläggningsalgoritmer (RMS - Rate Monotonic Scheduling) och dynamiska schemaläggningsalgoritmer (EDF - Earliest Deadline First).

RMS används för att formellt bevisa ett systems förutsägbarhetsförhållanden. För att implementera denna teori krävs förebyggande prioriteringsschemaläggning. I RMS-teorin ges prioritet i förväg till varje process. Processer måste uppfylla följande villkor:

*processen måste slutföras inom dess period;

*processer är inte beroende av varandra;

*varje process kräver samma CPU-tid vid varje intervall;

*icke-periodiska processer har inga strikta deadlines;

*processavbrott sker inom en begränsad tid.

Processer utförs enligt prioriteringar. Vid schemaläggning av RMS ges företräde åt uppgifter med de kortaste slutförandeperioderna.

I EDF tilldelas prioritet dynamiskt och högsta prioritet tilldelas den process som har kortast återstående körtid. Vid höga systembelastningar har EDF fördelar jämfört med RMS.

Alla realtidssystem kräver en deadlinedriven schemaläggningspolicy. Detta tillvägagångssätt är dock under utveckling.

RTOS använder vanligtvis tjänsteavbrottsprioritetsplanering, som är baserad på RMS. Prioritetsavbrott (preemption) är en integrerad komponent i en RTOS, eftersom I ett realtidssystem måste det finnas garantier för att en högprioriterad händelse kommer att behandlas före en lägre prioriterad händelse. Allt detta leder till det faktum att RTOS inte bara behöver en schemaläggningsmekanism baserad på avbrottsprioriteringar, utan också en lämplig mekanism för att hantera avbrott. Dessutom måste RTOS kunna inaktivera avbrott när kritisk kod behöver exekveras som inte kan avbrytas. Varaktigheten av avbrottsbehandlingen bör hållas till ett minimum.

RTOS måste ha ett utvecklat prioriteringssystem. För det första krävs detta eftersom systemet i sig kan betraktas som en samling serverapplikationer uppdelade i trådar, och flera höga prioritetsnivåer måste tilldelas systemprocesser och bäckar. För det andra, i komplexa applikationer Alla realtidstrådar bör placeras på olika prioritetsnivåer, och icke-realtidstrådar bör placeras på samma nivå (lägre än alla realtidstrådar). I det här fallet kan icke-realtidstrådar bearbetas i schemaläggningsläget round-robin (RRS), där varje process ges ett processortidssegment, och när segmentet slutar sparas processkontexten och den placeras i slutet av kön. Många RTOSer använder RRS för att schemalägga uppgifter på en nivå. Prioritetsnivå 0 används vanligtvis för viloläge.

När man planerar utifrån prioriteringar finns det två viktiga frågor att lösa:

*säkerställa genomförandet av processen med högsta prioritet,

*förhindra prioritetsinvertering, när uppgifter med hög prioritet väntar på resurser som fångas upp av uppgifter med lägre prioritet.

För att bekämpa prioritetsinversion använder RTOS ofta en prioritetsarvsmekanism, men detta eliminerar RMS-baserad schemaläggning eftersom prioriteter blir dynamiska.

1.5 Minne

Som nämnts ovan beror fördröjningen för trådkontextväxling direkt på minneskonfigurationen, dvs. från minnesskyddsmodellen. Det finns fyra vanligaste minnesskyddsmodeller i RTOS:

*Modell utan skydd - systemet och användarens adressutrymmen är inte skyddade från varandra, två minnessegment används: för kod och för data, medan systemet inte kräver någon minneshantering, kräver inte en MMU (minneshanteringsenhet - en speciell hårdvaruenhet för att stödja hanteringen virtuellt minne);

*System/användarsäkerhetsmodell - systemets adressutrymme är skyddat från användarens adressutrymme, system- och användarprocesser körs i ett gemensamt virtuellt adressutrymme och en MMU krävs. Skydd tillhandahålls av sidskyddsmekanismen. Det finns system- och användarsidor. Användarapplikationer är inte skyddade från varandra på något sätt. Processorn är i övervakningsläge om det aktuella segmentet är nivå 0, 1 eller 2. Om segmentnivån är 3, är processorn i användarläge. I den här modellen krävs fyra segment - två segment på nivå 0 (för kod och data) och två segment på nivå 3. Sidskyddsmekanismen lägger inte till overhead eftersom säkerheten kontrolleras samtidigt med adressöversättningen som utförs av MMU; i det här fallet behöver inte operativsystemet minneshantering.

*Användar/användarsäkerhetsmodell - lägger till säkerhet mellan användarprocesser till systemet/användarmodellen, kräver MMU. Liksom i den tidigare modellen används en sidskyddsmekanism. Alla sidor är markerade som privilegierade, förutom sidorna i den aktuella processen, som är markerade som användarsidor. Således kan den exekverande tråden inte komma åt gränserna för sitt adressutrymme. OS ansvarar för att uppdatera privilegieflaggan för specifik sida i sidtabellen vid byte av processer. Som i den tidigare modellen används fyra segment.

*Virtuellt minnesskyddsmodell - varje process körs i sitt eget virtuella minne, MMU krävs. Varje process har sina egna segment och därför sin egen deskriptortabell. OS ansvarar för att underhålla handtagstabeller. Det adresserbara utrymmet kan överstiga storleken på det fysiska minnet om sökt minne används i samband med personsökning. Emellertid använder realtidssystem i allmänhet inte personsökning på grund av dess oförutsägbarhet. För att lösa det här problemet tillgängligt minneär uppdelad i ett fast antal logiska adressutrymmen av samma storlek. Antalet processer som körs samtidigt i systemet blir begränsat.

Ett grundläggande krav för minne i ett realtidssystem är att åtkomsttiden måste vara begränsad (eller, med andra ord, förutsägbar). En direkt konsekvens är ett förbud mot användning av on-demand-tekniker för sidanrop (disksökning) för realtidsprocesser. Därför måste system som tillhandahåller en virtuell minnesmekanism kunna blockera processen random access minne, förhindrar byte. Så byte är inte tillåtet i en RTOS eftersom det är oförutsägbart.

Om personsökning stöds måste lämplig mappning av sidor till fysiska adresser vara en del av processkontexten. Annars uppstår oförutsägbarhet igen, vilket är oacceptabelt för en RTOS.

För processer som inte är det hårda processer realtid är det möjligt att använda en mekanism för dynamisk minnesallokering, dock måste RTOS stödja timeout-bearbetning för minnesbegäranden, dvs. begränsning av förutsägbara väntetider.

I konventionella operativsystem, när man använder en minnessegmenteringsmekanism, används komprimering efter sophämtning för att bekämpa fragmentering. Detta tillvägagångssätt är dock inte tillämpligt i en realtidsmiljö, eftersom Under komprimering kan flyttade uppgifter inte utföras, vilket leder till oförutsägbarhet i systemet. Detta är huvudproblemet med tillämpbarheten av den objektorienterade strategin för realtidssystem. Tills komprimeringsproblemet är löst kommer C++ och JAVA att finnas kvar bästa valet för hårda realtidssystem.

Hårda realtidssystem använder vanligtvis statisk minnesallokering. I mjuka realtidssystem är dynamisk minnesallokering möjlig, utan virtuellt minne och utan komprimering.

1.6 Avbryter

När man beskriver avbrottshantering särskiljs vanligtvis två procedurer, nämligen:

*Interrupt Servicing Rutin (ISR) - ett lågnivåprogram i kärnan med begränsade systemanrop,

*avbrottsservicetråd (IST - interrupt service thread) - applikationsnivåtråd som hanterar avbrottet, med tillgång till alla systemanrop.

Vanligtvis implementeras ISR:er av hårdvarutillverkaren, och enhetsdrivrutiner utför avbrottshantering med hjälp av IST:er. Avbrottstrådar fungerar som vilken annan tråd som helst och använder samma prioriteringssystem. Detta innebär att systemdesignern kan ge IST en lägre prioritet än applikationstråden.

1.7 Klockor och timers

RTOS använder olika tjänster tid. Operativsystemet håller reda på den aktuella tiden, startar uppgifter och trådar vid vissa tidpunkter och avbryter dem med vissa intervall. RTOS-tidstjänster använder realtidsklockor. Vanligtvis används hårdvaruklockor med hög precision. Timers skapas för att räkna tidsintervall baserat på realtidsklockan.

Varje process och tråd tilldelas en CPU-klocka. Dessa klockor används för att skapa timers som mäter om en process eller tråd körs över tid, vilket gör att den dynamiskt kan upptäcka programvarufel eller fel vid beräkning av maximalt möjliga exekveringstid.

I mycket tillförlitliga, tidskritiska system är det viktigt att identifiera situationer där en uppgift överskrider den maximala möjliga exekveringstiden, eftersom i detta fall kan systemdriften överskrida den acceptabla svarstiden. Runtime-klockor låter dig identifiera när tidsöverskridanden inträffar och initiera lämpliga felhanteringsåtgärder.

De flesta RTOS fungerar med relativ tid. Något händer "före" och "efter" någon annan händelse. I ett system som är helt händelsestyrt behövs en klockmekanism (ticker), eftersom det finns ingen tid att skiva. Men om du behöver tidsstämplar för vissa händelser eller om du behöver ett systemanrop som "vänta en sekund", behöver du en klockgenerator och/eller en timer.

Synkronisering i en RTOS utförs med hjälp av en blockerande (eller väntande) mekanism tills en viss händelse inträffar. Absolut tid används inte.

RTOS-implementationer av andra konceptuella abstraktioner liknar deras implementeringar i traditionella operativsystem.

2. Standarder för realtidsoperativsystem

2.1 POSIX standard

De stora skillnaderna i RTOS-specifikationer och det enorma antalet befintliga mikrokontroller aktualiserar problemet med standardisering inom området realtidssystem.

Den tidigaste och mest utbredda RTOS-standarden är POSIX-standarden (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Den ursprungliga versionen av POSIX-standarden dök upp 1990 och var avsedd för UNIX-system, vars första versioner dök upp på 70-talet av förra seklet. POSIX-specifikationerna definierar en standardmekanism för interaktion mellan ett applikationsprogram och operativsystemet och inkluderar för närvarande en uppsättning av mer än 30 standarder. För RTOS är sju av dem viktigast (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), men bara de tre första stöds allmänt i kommersiella operativsystem.

Trots de klart föråldrade bestämmelserna i POSIX-standarden och den stora efterfrågan på standardiseringsuppdateringar för RTOS har det inte skett några märkbara framsteg i denna riktning.

POSIX-standarden skapades som ett standardgränssnitt för operativsystemtjänster. Denna standard gör det möjligt att skapa bärbara applikationer. Denna standard utökades sedan till att omfatta realtidsfunktioner.

POSIX-specifikationerna definierar en standardmekanism för interaktion mellan en applikation och operativsystemet. Det bör noteras att POSIX-standarden är nära relaterad till Unix-operativsystemet, men utvecklarna av många RTOS försöker följa denna standard.

Överensstämmelse med POSIX-standarden för operativsystemet och hårdvaruplattformen måste certifieras genom att köra testfall på dem. Men om operativsystemet inte är Unix-liknande blir det en utmaning att uppfylla detta krav. Testsviter finns endast för POSIX 1003.1a. Eftersom POSIX-strukturen är en samling valfria funktioner kan OS-leverantörer implementera endast en del av standardgränssnittet och fortfarande hävda att deras system är POSIX-kompatibelt.

Även om POSIX-standarden växte ur Unix, adresserar den de grundläggande abstraktionerna av operativsystem, och realtidstilläggen gäller alla RTOS:er.

Vid det här laget ses POSIX-standarden som en familj av relaterade standarder: IEEE Std 1003.n (där n är ett tal).

2.2 DO-178B standard

DO-178B-standarden skapades av Radio Technical Commission for Aeronautics (RTCA) för utveckling av mjukvara för system ombord på flygplan.

Dess första version antogs 1982, den andra (DO-178A) - 1985, den nuvarande DO-178B - 1992. Antagandet av en ny version, DO-178C, förbereds. Standarden tillhandahåller fem nivåer av felallvarlighet, och för var och en av dem definieras en uppsättning programvarukrav som måste säkerställa funktionaliteten i hela systemet när fel uppstår. denna nivå allvar

Denna standard definierar följande certifieringsnivåer:

*A (katastrofisk),

*B (farligt),

*С (stor),

*D (inte signifikant)

*E (påverkar inte).

Innan alla de stränga kraven i denna standard är uppfyllda kommer säkerhetskänsliga datorsystem aldrig att ta fart.

2.3 ARINC-653 standard

ARINC-653-standarden (Avionics Application Software Standard Interface) utvecklades av ARINC 1997. Denna standard definierar en universell mjukvarugränssnitt APEX (Application/Executive) mellan flygplansdatorns OS och applikationsmjukvara.

Gränssnittskraven mellan applikationsprogramvara och operativsystemtjänster är definierade för att tillåta applikationsmjukvaran att kontrollera sändning, kommunikation och tillståndet för interna bearbetningselement. Under 2003 antogs en ny utgåva av denna standard. ARINC-653 introducerar arkitekturen för partitionerade virtuella maskiner som ett av huvudkraven för RTOS inom flyg.

2.4 OSEK standard.

OSEK/VDX-standarden är en kombination av standarder som ursprungligen utvecklades i två separata konsortier som senare slogs samman. OSEK har fått sitt namn från den tyska förkortningen för ett konsortium som inkluderade de ledande tyska biltillverkarna BMW, Bosch, Daimler Benz (numera Daimler Chrysler), Opel, Siemens och Volkswagen, samt universitetet i Karlsruhe (Tyskland). VDX-projektet (Vehicle Distributed eXecutive) utvecklades gemensamt av de franska företagen PSA och Renault. OSEK- och VDX-teamen slogs samman 1994.

OSEK/VDX-projektet var ursprungligen avsett att utveckla en öppen OS-arkitektur och API-standard för system som används inom fordonsindustrin. Den utvecklade standarden visade sig dock vara mer abstrakt och är inte begränsad till att endast användas inom bilindustrin.

OSEK/VDX-standarden består av tre delar - en standard för operativsystemet (OS), kommunikationsstandard(COM) och Network Manager (NM) standard. Utöver dessa standarder definieras ett implementeringsspråk (OIL). Den första komponenten i OSEK-standarden är OS-standarden, så OSEK-standarden uppfattas ofta av misstag som en RTOS-standard. Även om operativsystemet är en stor del av denna standard, ligger dess kraft i integrationen av alla dess komponenter.

2.5 Säkerhetsnormer

I samband med standarder för RTOS är det värt att notera den välkända standarden för kriterier för att bedöma lämpligheten av datorsystem (Trusted Computer System Evaluation Criteria - TCSEC). Denna standard har utvecklats av det amerikanska försvarsdepartementet och är även känd som Orange Book på grund av färgen på omslaget.

Ett antal andra länder har utvecklat liknande kriterier, utifrån vilka den internationella standarden "Common Criteria for IT Security Evaluation" (ISO/IEC 15408) skapades.

The Orange Book listar sju skyddsnivåer:

*A1 - verifierad utveckling. Denna nivå kräver att skyddet av sekretessbelagd och annan känslig information genom säkerhetskontroller garanteras genom formella verifieringsmetoder.

*B3 - säkerhetsdomäner. Denna nivå är utformad för att skydda system från erfarna programmerare.

*B2 - strukturerat skydd. Ett system med denna skyddsnivå kan inte penetreras av hackare.

*B1 - obligatorisk åtkomstkontroll. En erfaren hacker kanske kan övervinna denna skyddsnivå, men inte vanliga användare.

*C2 - diskretionär åtkomstkontroll. Nivå C2 ger säkerhet för inloggningsprocedurer, tillåter övervakning av säkerhetsrelaterade händelser och isolerar resurser.

*C1 - selektivt skydd. Denna nivå ger användarna möjlighet att skydda personliga data eller projektinformation genom att ställa in åtkomstkontroller.

*D - minimiskydd. Denna lägre skyddsnivå är reserverad för system som har testats men inte kunde uppfylla kraven för en högre klass.

3. Korta egenskaper hos de vanligaste realtidsoperativsystemen

3.1 VxWorks

Realtidsoperativsystem i VxWorks-familjen från WindRiver Systems Corporation är designade för utveckling av mjukvara för inbyggda datorer som arbetar i hårda realtidssystem.

Operativsystemet VxWorks har en klient-server-arkitektur och är byggt i enlighet med mikrokärnteknik, d.v.s. det lägsta icke-avbrottsbara kärnlagret (WIND Microkernel) hanterar endast uppgiftsschemaläggning och uppgiftskommunikation/synkroniseringshantering. All annan funktionalitet hos operativsystemkärnan - minneshantering, input/output, etc. - tillhandahålls på en högre nivå och implementeras genom processer. Detta säkerställer kärnans prestanda och determinism, såväl som systemets skalbarhet.

VxWorks kan konfigureras för små inbyggda system med snäva minnesbegränsningar till komplexa system med avancerad funktionalitet.

Även om VxWorks-systemet är konfigurerbart, d.v.s. Även om enskilda moduler kan laddas statiskt eller dynamiskt, kan det inte sägas använda ett komponentbaserat tillvägagångssätt. Alla moduler är byggda ovanpå baskärnan och är designade på ett sådant sätt att de inte kan användas i andra miljöer.

3.2 QNX Neutrino RTOS

QNX Neutrino Real-time Operating System (RTOS) från QNX Software Systems är ett mikrokärnoperativsystem som ger prioriterad multitasking.

QNX Neutrino RTOS har en klient-server-arkitektur. I QNX Neutrino-miljön körs alla drivrutiner, applikationer, protokoll och filsystem utanför kärnan, i ett skyddat adressutrymme. Om någon komponent misslyckas kan den automatiskt starta om utan att påverka andra komponenter eller kärnan. Även om QNX-systemet är konfigurerbart, d.v.s. Även om enskilda moduler kan laddas statiskt eller dynamiskt, kan det inte sägas använda ett komponentbaserat tillvägagångssätt. Alla moduler förlitar sig på baskärnan och är designade på ett sådant sätt att de inte kan användas i andra miljöer.

QNX Neutrino RTOS består av en kärna, en processhanterare och avancerade tjänster på användarnivå. Som ett riktigt mikrokärnoperativsystem implementerar QNX Neutrino RTOS endast de mest grundläggande tjänsterna i OS-kärnan, såsom meddelandeöverföring, signaler, timers, trådschemaläggning och synkroniseringsobjekt. Alla andra OS-tjänster, drivrutiner och applikationer körs som separata processer som kommunicerar genom synkron meddelandeöverföring.

QNX Neutrino RTOS har korta avbrottsbehandlingstider och snabb kontextväxling. Prioritetsinvertering övervinns med fördelat prioritetsarv. Förenklad modellering av realtidsaktiviteter utförs genom synkron meddelandeöverföring. Kapslade avbrott och en fast övre gräns för avbrottsbehandlingstid säkerställer att högprioriterade avbrott bearbetas snabbt med förutsägbar timing.

3.3 RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) är ett icke-kommersiellt realtidsoperativsystem för djupt inbäddade system.

Systemutvecklaren är OAR (On-Line Applications Research Corporation, USA). Systemet skapades på order av det amerikanska försvarsdepartementet för användning i kontrollsystem för missilsystem. Systemet utvecklas för multiprocessorsystem baserade på öppen källkod, till skillnad från liknande system med sluten källkod. Systemet är designat för MS-Windows och Unix-plattformar (GNU/Linux, FreeBSD, Solaris, MacOS X).

RTEMS-kärnan tillhandahåller den grundläggande funktionaliteten i realtidssystem. Dessa funktioner inkluderar

*multitasking bearbetning;

*arbete i homogena och heterogena system;

*händelsedriven planering baserad på prioriteringar;

*planering i monoton hastighet;

*uppgiftsinteraktion och synkronisering;

*prioriterat arv;

*responsavbrottskontroll;

*dynamisk minnesallokering;

*systemkonfiguration för auktoriserade användare;

*bärbar till många målplattformar.

RTOS är länkad till hårdvaran med hjälp av ett speciellt bibliotek av BSP (board support package) subrutiner och specialiserade subrutiner för olika arkitekturer.

RTEMS stöder inte dynamisk laddning av applikationer och moduler, så dess tillämpningsområde är inbyggda system där frekventa programvaruändringar inte förväntas.

RTEMS RTOS ger ganska svagt stöd för filsystem, vilket begränsar omfattningen av dess möjliga tillämpning inom området för centraliserad datainsamling och lagringssystem till standardverktyg på hög nivå.

3.4 ChorusOS

Operativsystemet ChorusOS är ett skalbart inbyggt operativsystem som används ofta inom telekommunikationsindustrin. För närvarande utvecklas och distribueras detta varumärke av Sun Microsystems Corporation.

För att bygga och distribuera ChorusOS på specifika telekommunikationsplattformar erbjuder Sun Microsystems användningen av utvecklingsmiljön Sun Embedded Workshop. Sun Microsystems introducerar ChorusOS som den inbäddade grunden för Suns tjänstedrivna nätverk. I kombination med ett brett utbud av tjänster, sömlös mjukvaru- och hårdvaruintegration, enkel administration och support för Java-teknik som är dedikerad till behoven inom telekommunikation, låter ChorusOS dig effektivt distribuera nya funktioner och applikationer, och bibehålla tillförlitligheten och funktionaliteten hos moderna nätverk.

ChorusOS stöder ett brett utbud av telekommunikationsprotokoll, äldre applikationer, realtidsapplikationer och Java-tekniker på en enda hårdvaruplattform.

ChorusOS modellerar tre typer av applikationer:

*POSIX-processer utgör majoriteten av ChorusOS-applikationer, dessa applikationer har tillgång till POSIX API, flera POSIX-liknande utökade API:er och ett litet antal begränsade mikrokärnsystemanrop;

*ChorusOS Actors - dessa applikationer körs ovanpå mikrokärnan och begränsas av mikrokärnans API, aktörer inkluderar drivrutiner, undersystemhändelser och protokollstackar;

*Äldre ChorusOS-appar stöds för kompatibilitet med appar utformade för mer avancerade tidigare versioner ChorusOS.

Arkitekturen för ChorusOS OS är komponentbaserad i flera lager. Mikrokärnan innehåller den minsta uppsättning komponenter som krävs för driften av operativsystemet. Storleken på den inhemska delen av kärnan är 10Kb.

Begreppet "aktör" i ChorusOS definieras som en laddningsenhet för en applikation. Den fungerar också som en inkapslingsenhet för att matcha allt systemresurser, som används av applikationen, och trådar som löper inuti skådespelaren. Exempel på sådana resurser är trådar, minnesregioner och kommunikationsslutpunkter.

ChorusOS 5.0 är kärnan operativ miljö Solaris och stöder följande målplattformar:

*UltraSPARC II (CP1500 och CP20x0);

*Intel x86, Pentium;

*Motorola PowerPC 750 och 74x0 processorfamiljen (mpc7xx);

*Motorola PowerQUICC I (mpc8xx) och PowerQUICC II (mpc8260) (mikrokontroller).

3.5 RTX (Real Time Extension för Windows NT)

Windows NT designades och används främst som ett allmänt operativsystem. På marknaden för realtidssystem finns det dock en tydlig trend att använda Windows NT och dess tillägg i specialiserade system. Det finns flera anledningar till detta:

*Windows NT designades enligt modern OS-teknik,

*applikationsprogrammeringsgränssnitt (API) för Win32 har blivit de facto-standarden för programmerare,

*grafiskt användargränssnitt (GUI) har blivit så populärt att andra operativsystem försöker tillhandahålla ett liknande gränssnitt,

*ett stort antal enhetsdrivrutiner är tillgängliga,

*Många kraftfulla integrerade utvecklingsmiljöer finns tillgängliga.

Windows NT i sig är inte lämpligt för användning i realtidssystem, eftersom det har för få prioritetsnivåer och det inte finns någon mekanism för att ärva prioriteringar. För att minimera interrupt service time (ISR) introducerade Windows NT konceptet med deferred procedure call (DPC), vars prioritet är högre än prioritet för användar- och systemtrådar, medan alla DPC:er har samma prioritet. Detta gör att alla DPC:er ställs i kö i en FIFO-kö, och en DPC med ett högnivåavbrott kommer endast att kunna exekvera efter att alla andra DPC:er står i kö innan den har slutförts. Sådana situationer leder till oförutsägbara svarstider, som är oförenliga med RTOS-kraven. Minneshantering i Windows NT är baserad på en virtuell minnesmekanism. Detta medför minnesskydd, adressöversättning och byte, vilket är oacceptabelt i en RTOS.

RTX (Real-Time Extension) för Windows NT (utvecklad av VenturCom Corporation) låter dig skapa hömed deterministiska svarstider på externa händelser.

RTX är djupt integrerad i Windows NT-kärnan och använder Windows-tjänst NT och API WIN32. Realtidskärnan (kärnan) är integrerad i NT-kärnan (kärnan). Varje RTX-process körs som en NT-kärnenhetsdrivrutin, och processerna är inte skyddade från varandra. Denna implementering resulterar i snabb kontextväxling, men är inte säker ur ett integritetsperspektiv.

3.6 INtime (Windows NT Real Time Extension)

INtime är ett Windows-realtidstillägg som utvecklats av Radisys Corporation och för närvarande underhålls av TenAsys Corporation.

INtime kombinerar funktionerna hos en hård realtids-RTOS med standard Windows-operativsystem, inklusive Windows XP, Windows XP Embedded, Windows 2000, Windows NT och Windows NT Embedded, utan att kräva ytterligare hårdvara. INtime är speciellt designad för x86-processorarkitektur.

INtime är, till skillnad från RTX, svagt relaterat till NT. INtime-arkitekturen är baserad på den hårdvaruuppgiftsmekanism som tillhandahålls av Intel-processorn. Det visar sig att två kärnor körs på samma hårdvara. Eftersom de delar samma hårdvara krävdes vissa modifieringar av NT HAL. Detta tillvägagångssätt låter dig skydda och separera runtime- och minnesområdet från Windows. Inom INtime har varje ansökningsprocess sitt eget adressutrymme. Dessutom körs kärnan och applikationerna på olika prioritetsnivåer, vilket hjälper till att skydda dem från varandra.

INtime uppvisar förutsägbart beteende, men dess komplexa arkitektur tillåter inte systemet att uppnå bra prestanda. På grund av segmenteringsbegränsningar är INtime inte lämpligt för alla realtidssystem.

3.7 LynxOS

LynxOS RTOS-operativsystemet (LynuxWorks, Inc.) är ett hårt realtidsoperativsystem som är designat för specialiserad utrustning och telekommunikationsutrustning. Detta operativsystem är helt deterministiskt och har POSIX, UNIX och Linux-kompatibilitet. Användningsområden för LynxOS är också komplexa säkerhetssystem.

Den senaste släppta versionen av detta varumärke, LynxOS-178 2.0, kännetecknas av tillverkaren som ett kommersiellt operativsystem som ger en hög nivå av tillförlitlighet och lyhördhet som krävs för inbäddade applikationer med speciella säkerhetskrav. LynxOS-178 2.0 implementerar stöd för APEX-gränssnittet (Application/EXEcutive - application/control program interface) i ARINC-653-specifikationen. Detta innebär att detta operativsystem uppfyller de strängaste kraven på säkerhet och tillförlitlighet hos elektroniska system för militär och civil luftfart. LynxOS-178 2.0 är helt kompatibel med nivå A i DO-178B-specifikationen.

RTOS LynxOS-178 2.0 uppfyller kraven i POSIX- och ARINC-653-standarderna, samt DO-178B, vilket innebär en garanti för portabilitet av applikationskod för inbyggda system, återanvändning av skapade program, samt överensstämmelse med de mest stränga operativsystemstandarder med ökade säkerhetskrav. Genom att använda LynxOS-178 2.0 kan du använda alla tidigare certifierade program och utvecklingar.

3.8 MicroWare OS-9

Microsoft Systems OS-9 realtidsoperativsystem är ett multitasking, fleranvändaroperativsystem för inbäddade realtidsapplikationer. Det här systemet är utformat för att fungera i system som mobila telekommunikationsenheter, inbyggda terminaler för internetåtkomst och interaktiva digital-tv set-top-boxar.

OS-9 körs på processorer som Motorola 68K, ARM/StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 eller Intel Pentium, Intel IXC1100 XScale.

OS-9-kärnan är skalbar, helt borttagbar, stöder upp till 65 535 processer, ger 65 535 prioritetsnivåer och stöder upp till 255 användare. OS-9-kärnan innehåller mer än 90 systemanrop som gör det möjligt att styra dynamisk schemaläggning, minnesallokering, interprocessorkommunikation, etc. - upp till att hantera energisparläget inbyggt i OS-kärnan.

Microware var en av de första att licensiera Java för inbäddade applikationer och är ledande när det gäller att erbjuda en mängd olika verktyg och applikationer inom OS-9 för olika klasser av enheter.

Som en integrerad korsapplikationsutvecklingsmiljö för OS-9 har Microware utvecklat Hawk-miljön, som körs på MS Windows NT-plattformen.

3.9 OSE RTOS

Realtidsoperativsystemet OSE RTOS, utvecklat av ENEA Corporation, har en prioriterad schemaläggningskärna. Denna kärna är mycket optimerad för hög prestanda och är tillräckligt kompakt för användning i inbyggda system. OSE har en meddelandestyrd arkitektur med enkla systemanrop. Meddelandeöverföring i OSE fungerar som en konceptuell gateway i distribuerade multiprocessor-inbäddade system. Uppgifter skickar meddelanden till varandra direkt via operativsystemet utan stöd för köer, brevlådor eller andra mellanliggande mekanismer. OSE RTOS stöder personsökning, duplicering, dynamisk koduppdatering och många kommunikationsprotokoll.

OSE RTOS-arkitekturen är baserad på en flerskiktsmodell.

Enheten för exekvering i OSE RTOS är processen. Processer kan grupperas i ett block, som kan ha sin egen minnespool. I OSE RTOS-kärnan hör ett adressutrymme till ett segment, som kan inkludera ett eller flera block. Mappning av block till segment och kartläggning av pooler till regioner gör det möjligt att uppnå fullt skydd minne och programisolering. Block och pooler kan placeras i en eller flera skärvor.

I OSE RTOS förstås processseparation som dynamisk och statisk: statiska processer skapas av kärnan när systemet startar och existerar under hela systemets livstid, dynamiska processer skapas och förstörs under exekvering.

3.10 Windows CE

Windows CE RTOS är modulärt med en liten kärna och valfria moduler som körs som oberoende processer. Schemaläggning i Windows CE baseras på prioriteringar. Skydd av kärnan och processer från varandra stöds. Dessutom är ett driftläge möjligt när det inte finns något skydd mellan processer och kärnan. Det bör noteras att avbrott behandlas som trådar och har trådprioritetsnivåer. Windows CE stöder även trådar, som är trådar som kärnan inte hanterar. Varje tråd körs i sammanhanget för tråden som skapade den; de kan användas för att skapa en schemaläggare i en tråd. Sådana trådar är användbara i exotiska eller äldre applikationer, men de är inte lämpliga för realtidssystem.

Windows CE har en fysisk minnesgräns på 512 MB. Microsoft introducerade denna begränsning så att Windows CE kunde köras på ett brett utbud av inbäddade processorer utan kompatibilitetsproblem, eftersom vissa av dessa processorer kan hantera 512 MB fysiskt minne. Windows CE implementerar virtuell minnessökning. Sidstorleken varierar beroende på plattform, men 4KB används när det är möjligt. Det är möjligt att förbjuda personsökning, vilket är viktigt för realtidssystem. I detta läge laddas modulen helt in i minnet innan den körs. Då kommer personsökning inte att påverka exekveringen av applikationen.

Till skillnad från andra RTOS stöder Windows CE generiska väntefunktioner för olika typer av objekt (mutexes, semaforer, händelser, processer och trådar). Fördelen med sådana funktioner är att många objekt kan förväntas på en gång tills ett av dem ger en signal. Kritiska avsnitt kan endast användas inom en enda process. Beräkningssemaforer och mutexer kan användas både inom en process och mellan processer. Windows CE använder prioritetsarv för att undvika problemet med prioritetsinversion.

3.11 Nucleus RTOS

Operativsystemet Nucleus, utvecklat av Accelerated Technology Corporation, är designat för inbyggda applikationer.

Nucleus är ett tvärsystem, dvs. en mjukvaruprodukt skapas på en mjukvaru- och hårdvaruplattform och exekveras på en annan.

Nucleus RTOS kommer med öppen källkod.

Kärnan i Nucleus RTOS, Nucleus PLUS, ger multitasking, portabilitet och skalbarhet. Kärnan är implementerad som ett bibliotek med funktioner i C.

Nucleus PLUS tillhandahåller funktioner som uppgiftsinteraktionshantering ( brevlådor, köer, pipelines, semaforer, händelser, signaler), samt minneshantering, timers, avbrott. Uppgiftsschemaläggning utförs baserat på prioriteringar, såväl som med hjälp av FIFO-algoritmen.

När ett systemanrop exekveras kan uppgiften pausas för obestämd tid, på specificerat intervall, eller pausa inte. Alla objekt i systemet kan skapas och raderas dynamiskt.

Slutsats

Under många år har realtidsoperativsystembaserade applikationer använts i inbyggda specialsystem, och på senare tid har de hittat in i allt från flygplanskontrollsystem ombord till hushållsapparater.

Den viktigaste egenskapen hos realtidssystem är förutsägbarheten av systemets tidsreaktioner på yttre händelser. Endast baserat på denna egenskap kan vi prata om konsistensen och giltigheten hos lösningarna inbäddade i ett specifikt realtidsoperativsystem.

Realtidssystem måste svara på externa parametrar lägga in och skapa nya resultat på en begränsad tid. Svarstiden bör vara begränsad. Mycket långa svarstider kan göra att realtidssystem misslyckas.

Det råder ingen tvekan om att de flesta traditionella realtidsoperativsystem designades med en enda CPU på ett enda kort i åtanke. Numera krävs allt mer stöd för multiprocessorsystem.

Det är uppenbart att operativsystem med en monolitisk arkitektur, på grund av deras fokus på specifika processorplattformar och karaktären av interaktion med kärnan, osannolikt kommer att användas som relativt universella realtidsoperativsystem för system med hög tillgänglighet.

Moderna realtidsoperativsystem är baserade på nya arkitektoniska tillvägagångssätt, kompletterade med verktyg för att utveckla applikationssystem som gör att de kan skapas inom en kortare tidsram med bästa egenskaper Dessutom har de som skapats på basis av en mikrokärna ett antal fördelar jämfört med en monolitisk arkitektur, och i kombination med ett objektorienterat tillvägagångssätt gör de att systemet blir hårdvaruoberoende och ger ett snabbt svar på externa händelser.

Det är i ljuset av tidsmässig förutsägbarhet som en RTOS måste utformas noggrant för att stödja realtidsapplikationer.

Bibliografi

1. Burdonov I.B., Kosachev A.S., Ponomarenko V.N. Operativsystem i realtid. Preprint: Institute of System Programming RAS. Irkutsk, 2006.

2. Olifer V.G., Olifer N.A. Nätverksoperativsystem: Lärobok för universitet. 2:a uppl. - St Petersburg: Peter, 2008. - 669 s.: ill.

3. www.ru.wikipedia.org

4. www.intuit.ru

Liknande dokument

Huvudegenskaper hos realtidssystem, typer av arkitekturer. Process (uppgift) prioriteringssystem och sändningsalgoritmer. Begreppet feltolerans, orsaker till misslyckanden. Feltolerans i befintliga realtidssystem (QNX Neutrino).

test, tillagt 2013-09-03


Klassificering av realtidssystem. Kärnor och realtidsoperativsystem. Uppgifter, processer, trådar. Fördelar och nackdelar med trådar. Egenskaper, schemaläggning, uppgiftssynkronisering. Relaterade uppgifter. Synkronisering med externa händelser.

abstrakt, tillagt 2007-12-28


Egenskaper, grunder för tillämpning, arkitektur för hårda och realtidsoperativsystem. Sekventiell programmering av realtidsuppgifter. Struktur och språk för parallell programmering, multiprogrammering och multitasking.

kursarbete, tillagd 2015-12-17


OS satsvis bearbetning, tidsdelning, realtid. Funktioner hos resurshanteringsalgoritmer. Stöd för fleranvändarläge. Förebyggande och icke-förebyggande multitasking. Operativsystem och globala nätverk.

abstrakt, tillagt 2011-11-12


Granskning av problemdomänkrav. Funktioner i uppgiftshantering. Exekveringssystem i realtid. Programmering på mikroprocessornivå. Domänmodeller och metoder. Implementering av en realtidssystemprototyp.

kursarbete, tillagt 2005-02-15


Schemalägga uppgifter i ett realtidsoperativsystem. Grundläggande typer av planering i förhållande till realtidsuppgifter. Att välja en acceptabel schemaläggningsalgoritm vid design av en RTS. Statisk prognos med hjälp av tabeller.

test, tillagt 2014-05-28


Övervägande av de grundläggande principerna och metoderna för att designa realtidssystem. Beskrivning av kontrollobjektets design och funktionella egenskaper, konstruktion av ett uppgiftsdiagram. Val av hårdvaruarkitektur, processtrådsmodell, gränssnitt.

kursarbete, tillagd 2015-01-19


Allmänna kännetecken för uppgifterna att spela in programkörningstid: utförande av realtidsprocesser, profilering. Programmerbar intervalltimer som ett mycket komplext system. Analys av huvudfunktionerna som returnerar Windows standardtid.

kursarbete, tillagd 2014-05-18


Operativsystemets koncept och funktioner. Huvudfunktionen i realtidsoperativsystem. Arbeta med kalkylblad. Filtrera poster i en MS Excel-tabell. Installation av ett anpassat autofilter i varurörelsens omsättningsblad.

test, tillagt 2013-11-21


Kärnan och principen för driften av operativsystemet, reglerna och fördelarna med dess användning. Möjligheterna hos olika operativsystem, deras styrkor och svagheter. Jämförande egenskaper hos Unix- och Windows NT-system, deras potential och utförda uppgifter.

Utmärkande egenskaper hos RTOS från OS generell mening

Operativsystem för allmänna ändamål, särskilt operativsystem för flera användare som UNIX, är fokuserade på att optimalt fördela datorresurser mellan användare och uppgifter. I realtidsoperativsystem försvinner en sådan uppgift i bakgrunden - allt försvinner innan huvuduppgift- ha tid att reagera på händelser som inträffar på anläggningen En annan skillnad är att användningen av ett realtidsoperativsystem alltid är kopplat till utrustningen, med objektet, med de händelser som inträffar på anläggningen. Ett realtidsoperativsystem är fokuserat på att bearbeta externa händelser. Ett realtidsoperativsystem kan ha ett användargränssnitt som liknar ett generellt operativsystem, men det är utformat helt annorlunda. Dessutom är tillämpningen av realtidsoperativsystem alltid specifik. Om ett operativsystem för allmänna ändamål vanligtvis uppfattas av användare (inte utvecklare) som en färdig uppsättning applikationer, fungerar ett realtidsoperativsystem endast som ett verktyg för att skapa ett specifikt maskin- och mjukvarukomplex i realtid. Och därför de flesta bred klass användare av realtidsoperativsystem - utvecklare av realtidskomplex, personer som designar kontroll- och datainsamlingssystem. Designa och utveckla specifikt system realtid, programmeraren vet alltid exakt vilka händelser som kan inträffa på anläggningen, känner till den kritiska tidsramen för att serva var och en av dessa händelser händelse. Värdet på den kritiska tiden för varje händelse bestäms av objektet och själva händelsen och kan vara olika, men systemets reaktionstid måste förutsägas (beräknas) när systemet skapas. Underlåtenhet att svara vid den förutsedda tiden anses vara ett fel för realtidssystem. Systemet måste kunna svara på samtidigt inträffade händelser. Även om två eller flera externa händelser inträffar samtidigt måste systemet ha tid att reagera på var och en av dem inom de tidsintervall som är kritiska för dessa händelser.

	OS i realtid	OS för allmänna ändamål
Huvuduppgiften	Ha tid att reagera på händelser som inträffar på utrustningen	Optimalt fördela datorresurser mellan användare och uppgifter
Vad är det fokuserat på?	Hantering av externa händelser	Bearbetar användaråtgärder
Hur den är placerad	Ett verktyg för att skapa ett specifikt maskin- och mjukvarukomplex i realtid	Användaren uppfattar det som en uppsättning applikationer redo att användas
Vem är den avsedd för?	Kvalificerad utvecklare	Mellanvändare

Hårda och mjuka realtidssystem

Det finns två typer av realtidssystem - hårda realtidssystem och mjuka realtidssystem.

Hårda realtidssystem tillåter inte någon fördröjning av systemsvar under några förhållanden eftersom:

• resultaten kan vara värdelösa om de är försenade
• katastrof kan inträffa om reaktionen försenas

• kostnaden för att komma för sent kan vara oändlig.

Exempel på hårda realtidssystem är styrsystem ombord, nödskyddssystem, nödhändelseregistratorer.

Mjuka realtidssystem kännetecknas av att svarsfördröjningen inte är kritisk, även om den kan leda till en ökning av resultatkostnaden och en minskning av systemets prestanda som helhet. Ett exempel är nätverksdrift. Om systemet inte hinner bearbeta nästa mottagna paket leder detta till timeout på sändningssidan och återsändning (beroende på protokollet förstås). Data går inte förlorade, men nätverkets prestanda minskar. Den huvudsakliga skillnaden mellan hårda och mjuka realtidssystem kan uttryckas på följande sätt: ett hårt realtidssystem ska aldrig vara sent med att svara på en händelse, ett mjukt realtidssystem. ska aldrig vara sen med att svara på en händelse

Operativsystems kärna

Kärnan är den centrala delen av operativsystemet (OS), vilket ger applikationer koordinerad åtkomst till datorresurser, minne, extern Hårdvara, en extern ingångs- och utmatningsenhet, som översätter applikationsspråkkommandon till binär kod som datorn förstår. Som det grundläggande elementet i operativsystemet är kärnan den mest låg nivå abstraktioner för applikationer för att få tillgång till de systemresurser som krävs för deras drift. Typiskt ger kärnan sådan åtkomst till exekveringsprocesserna för motsvarande applikationer genom användning av kommunikationsmekanismer mellan processer och applikationsanrop till OS-systemanrop.

Monolitisk kärna

Den monolitiska kärnan ger en rik uppsättning hårdvaruabstraktioner. Alla delar av en monolitisk kärna arbetar i samma adressutrymme. Detta är en operativsystemdesign där alla komponenter i dess kärna finns komponenter ett program, använd allmänna strukturer data och interagerar med varandra genom att direkt anropa procedurer. Monolitisk kärna - det äldsta sättet organisation av operativsystem. Ett exempel på system med en monolitisk kärna är de flesta UNIX-system.

Fördelar: Driftshastighet, förenklad utveckling av moduler.

Brister: Eftersom hela kärnan arbetar i samma adressutrymme kan ett fel i en av komponenterna störa hela systemet.

Vissa gamla monolitiska kärnor, särskilt UNIX/Linux-klasssystem, krävde omkompilering närhelst hårdvarusammansättningen ändrades. De flesta moderna kärnor låter dig ladda moduler under drift som utför delar av kärnfunktionerna. I det här fallet är operativsystemets komponenter inte oberoende moduler, utan komponenter i ett stort program som kallas en monolitisk kärna, vilket är en uppsättning procedurer, som var och en kan anropa var och en. Alla procedurer körs i privilegierat läge.

Mikrokärna

Mikrokärnan tillhandahåller bara elementära funktioner processhantering och ett minimum av abstraktioner för att arbeta med utrustning. Det mesta av arbetet sker genom speciella användarprocesser som kallas tjänster. Det avgörande kriteriet för "mikrokernelism" är placeringen av alla eller nästan alla drivrutiner och moduler i serviceprocesser.

Fördelar: Motstånd mot hårdvarufel, fel i systemkomponenter. Den största fördelen med mikrokärnarkitektur är hög grad modularitet för operativsystemets kärna. Detta gör det mycket lättare att lägga till nya komponenter till den. I ett mikrokärnoperativsystem kan du ladda och ladda ner nya drivrutiner, filsystem, etc. utan att avbryta dess funktion Processen att felsöka kärnkomponenter är avsevärt förenklad, eftersom en ny version drivrutiner kan laddas utan att starta om hela operativsystemet. Komponenterna i operativsystemets kärna skiljer sig inte i grunden från användarprogram, så du kan använda vanliga verktyg för att felsöka dem. Mikrokärnarkitektur förbättrar systemets tillförlitlighet eftersom ett fel på den oprivilegierade programnivån är mindre farligt än ett fel på kärnlägesnivån.

Brister: Att skicka data mellan processer kräver overhead.

Runtime miljö

Kraven för exekveringsmiljön för realtidssystem är följande:

• litet systemminne - för möjligheten att bädda in det;
• systemet måste vara helt minnesrelaterat för att undvika byte eller utbyte av minnessidor;
• systemet måste vara multitasking - för att säkerställa maximalt effektiv användning alla systemresurser;
• kärna med prioritet för serviceavbrott. Avbrottsprioritet innebär att en process som är redo att köras och har en viss prioritet med nödvändighet har prioritet i kön framför en process med lägre prioritet, snabbt ersätter den senare och går vidare till exekvering. Kärnan avslutar någon servicearbete, så snart en uppgift med högsta prioritet anländer. Detta säkerställer systemets förutsägbarhet;
• prioritetshanterare - låter applikationsutvecklaren tilldela varje startmodul en prioritet som inte är föremål för systemet. Prioritetstilldelning används för att bestämma i vilken ordning program som är redo att köras körs. Ett alternativ till denna typ av schemaläggning är karusellschemaläggning, där varje program som är redo att fortsätta ges lika stor chans att köras. Med denna metod finns det ingen kontroll över vilket program som ska köras och när. Detta är oacceptabelt i en realtidsmiljö. Prioritetsbaserad utskick och en kärna med avbrottsprioritet ger applikationsutvecklaren fullständig kontroll över systemet. Om en händelse med högre prioritet inträffar, slutar systemet att behandla den lägre prioritetsuppgiften och svarar på den nyligen mottagna begäran.

Kombinationen av egenskaperna som beskrivs ovan skapar en kraftfull och effektiv realtidsmiljö.

Förutom egenskaperna för runtime-miljön är det också nödvändigt att överväga tjänsten som tillhandahålls av realtids-OS-kärnan. Kärnan i alla realtidskörningsmiljöer är kärnan eller avsändaren. Kärnan styr måldatorns hårdvara: centralenhet, minne och inmatnings-/utgångsenheter; kontrollerar driften av alla andra system och applikationsprogramvara. I ett realtidssystem sitter avsändaren mellan måldatorns hårdvara och applikationsmjukvaran. Det ger särskild tjänst, nödvändigt för att köra realtidsapplikationer. Tjänsten som tillhandahålls av kärnan ger applikationsprogram tillgång till systemresurser som minne eller inmatnings-/utgångsenheter.

Kärnan kan tillhandahålla olika typer av tjänster:

• Intertask utbyte. Det är ofta nödvändigt att överföra data mellan program inom samma system. Dessutom behöver många applikationer kommunicera med andra system över ett nätverk. Intern kommunikation kan utföras genom ett meddelandesystem. Extern kommunikation kan organiseras antingen genom ett datagram (bästa leveranssätt) eller via kommunikationslinjer (garanterad leverans). Valet av en eller annan metod beror på kommunikationsprotokollet.
• Dataseparation. I realtidsapplikationer tar datainsamling längst tid. Data är ofta nödvändiga för driften av andra program eller behövs av systemet för att utföra vissa av dess funktioner. Många system ger åtkomst till delade minnessektioner. Dataköer är utbredda. Det finns många typer av köer som används, som var och en har sina egna fördelar.
• Bearbetar förfrågningar från externa enheter. Varje applikationsprogram ansluts i realtid till en extern enhet viss typ. Kärnan måste tillhandahålla I/O-tjänster som tillåter applikationsprogram att läsa från och skriva till dessa enheter. För realtidsapplikationer är det vanligt att ha en den här applikationen extern enhet. Kärnan måste tillhandahålla en tjänst som gör det enklare att arbeta med drivrutiner. Ge till exempel förmågan att skriva på högnivåspråk - som C eller Pascal.
• Hantera speciella situationer. Ett undantag är en händelse som inträffar under programkörning. Den kan vara synkron om dess förekomst är förutsägbar, till exempel division med noll. Och det kan också vara asynkront om det inträffar oförutsägbart, till exempel ett spänningsfall. Genom att tillhandahålla möjligheten att hantera dessa typer av händelser kan realtidsapplikationer reagera snabbt och förutsägbart på interna och externa händelser. Det finns två metoder för att hantera undantag - att använda tillståndsvärden för att upptäcka feltillstånd och att använda en undantagshanterare för att fånga feltillstånd och korrigera dem.

Översikt över RTOS-arkitekturer

Under sin historia har operativsystemets arkitektur genomgått en betydande utveckling. En av de första principerna för konstruktion, monolitisk OS (Figur 1) bestod av att presentera OS som en uppsättning moduler som interagerar med varandra på olika sätt inom systemkärnan och förser applikationsprogram med ingångsgränssnitt för åtkomst till hårdvara.

nivå OS (Figur 2) Ett exempel på ett sådant operativsystem är bra känt system MS-DOS. I system av denna klass kan applikationsapplikationer komma åt hårdvaran inte bara genom systemkärnan eller dess inhemska tjänster, utan också direkt. RTOS har byggts på denna princip i många år. Jämfört med monolitiska operativsystem ger den här arkitekturen en betydligt större grad av förutsägbarhet av systemreaktioner och tillåter även applikationsapplikationer att snabbt komma åt hårdvaran. Nackdel

Det som gör sådana system så dåliga är deras brist på multitasking. Inom denna arkitektur reducerades problemet med att bearbeta asynkrona händelser till att buffra meddelanden, och sedan sekventiellt polla buffertarna och bearbeta dem. Samtidigt säkerställdes efterlevnaden av kritiska servicedeadlines av datorkomplexets höga prestanda jämfört med hastigheten på externa processer.

Figur 2. Tier OS-arkitektur

En av de mest effektiva arkitekturerna för att bygga realtidsoperativsystem är klient-server-arkitekturen. Det allmänna diagrammet för ett operativsystem som använder denna teknik presenteras i figur 3. Huvudprincipen för denna arkitektur är överföringen av OS-tjänster i form av servrar till användarnivån, och mikrokärnan utför funktionerna för en meddelandehanterare mellan klienter användarprogram och servrar - systemtjänster. Denna arkitektur ger många fördelar när det gäller krav på RTOS och inbyggda system. Bland dessa fördelar är:

1. Tillförlitligheten hos OS ökar, eftersom Varje tjänst är i själva verket en oberoende applikation och är lättare att felsöka och spåra fel.

2. Ett sådant system skalar bättre, eftersom onödiga tjänster kan uteslutas från systemet utan att kompromissa med dess prestanda.

3. Feltoleransen hos systemet ökar pga En frusen tjänst kan startas om utan

starta om systemet.

Figur 3. Bygga ett OS med klient-server-arkitektur

Tyvärr finns det idag inte många operativsystem implementerade på klient-server-principen. Bland de välkända RTOS som implementerar mikrokärnarkitektur är OS9 och QNX.

Lista över använd 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/

En översikt över de jämförande egenskaperna hos RT OS som finns på den ryska marknaden presenteras i förhållande till användning i flygkontrollsystem.

Tack vare utvecklingen datateknik Nyligen har det blivit möjligt att tilldela en modul uppgifter som tidigare utförts av flera processormoduler samtidigt som vikt- och storleksegenskaperna hos styrsystemet förbättras och kostnaden reduceras. Denna trend inom flygteknik har lett till uppkomsten av konceptet integrerad modulär flygelektronik - IMA (Integrated Modular Avionics, IMA).

Problemet med att integrera styrfunktioner i en enda modul är att det är nödvändigt att dela upp de nu gemensamma resurserna (processortid, minne, kommunikationskanaler) mellan olika uppgifter, samtidigt som de ger samma nivå av tillförlitlighet och oberoende av funktioner som tidigare. Realtidsoperativsystemet spelar en nyckelroll för att lösa detta problem.

För närvarande finns det flera kommersiella RTOSer för kritiska applikationer på världsmarknaden (tabell 1). Den här artikeln ger en översikt över RTOS tillgängligt på den ryska marknaden, baserat på information från öppna källor och personlig erfarenhet författare.

Dokument som reglerar kraven för RTOS

• DO-178-standarden (Software Consideration in Airborne Systems and Equipment Certification) definierar kraven för mjukvaruutvecklingsprocessen och noggrannheten i dess verifiering beroende på dess kritiska nivå. Nivån på programvarans kritik bestäms utifrån en analys av hur allvarliga konsekvenserna av ett programvarufel är. Det finns fem nivåer av mjukvarukritikitet totalt (från A till E).
• MILS (Multiple Independent Levels of Security) är ett speciellt tillvägagångssätt för OS-design som förhindrar spridning av programvarufel under körning, och även förenklar programverifiering på grund av mjukvarumodularitet. Alla ansökningar placeras i så kallade sektioner (partitioner). Partitioner har allokerade resurser (minnesområde, processortid under varje systemcykel, åtkomst till kommunikationskanaler, etc.). Tillgång till tilldelade resurser garanteras av operativsystemet som körs i övervakarläge. Således kan applikationsprogramvara med olika kritiska nivåer köras på en processormodul som kör ett operativsystem - om ett fel inträffar i mindre kritisk (och följaktligen mindre testad) programvara kommer detta inte på något sätt att påverka funktionen för andra sektioner, eftersom försök att "usurpera" andra människors resurser kommer att blockeras av operativsystemet. MILS idéer återspeglar IMA och DO-178B.
• ARINC-653-standarden (Avionics Application Software Standard Interface) specificerar ett APEX-applikationsprogramvarugränssnitt som stöder ett partitionskoncept i MILS-stil. Detta gränssnitt innehåller funktioner för hantering av partitioner, processer, tidsdelning, kommunikation mellan och inom partitioner och övervakning av systemstatus. Det bör noteras att ARINC-653-standarden beskriver ett allmänt accepterat tillvägagångssätt för att implementera MILS-idéer för IMA, även om det kan finnas andra implementeringar. En RTOS för flyg som överensstämmer med ARINC-653 har fördelar eftersom denna standard är välkänd och förstådd av internationella certifieringsorgan, så det är lättare att få ett DO-178B överensstämmelsecertifikat för ett system byggt enligt denna standard.
• Återanvändbara programvarukomponenter standard. I enlighet med DO-178B genomgår programvaran för ett visst flygapplikationssystem hela certifieringsförfarandet, även om det använder moduler (komponenter) som redan har certifierats tidigare som en del av ett annat system. Ett av de senaste initiativen från FAA (Federal Aviation Certification Agency, USA) är att definiera kriterier för återanvändning av programvara utan omcertifiering. Komponenter som kanske inte är omcertifierade kallas RSC (Reusable Software Components). Det krävs mer ansträngning att få RSC-certifierad, men då ger RSC betydande besparingar.

Ryska dokument som definierar programvarukrav (inklusive RTOS):

• GOST R ISO/IEC 51904-2002 ("Inbäddade systemprogramvara. Allmänna krav för utveckling och dokumentation") - en analog till DO-178B för militär luftfart;
• KT-178A ("Kvalifikationskrav del 178A") - en analog till DO-178B för civil luftfart;
• GOST R ISO/IEC 12207-99 (" Informationsteknologi. Programvarans livscykelprocesser").

Jämförelsen av RT OS utfördes enligt 13 parametrar, som tar hänsyn till tekniska kriterier, enkel utveckling och ekonomiska parametrar.

OS timing parametrar

Ett av huvudkraven för RT OS är den minsta fördröjningstiden för bearbetning av en händelse. I praktiken betyder det att följande parametrar måste vara små:

• avbrottssvarstid - tiden mellan den faktiska förekomsten av avbrottet och början av behandlingen av den första instruktionen från avbrottshanteraren;
• styr trådbytestid - bytetid mellan två trådar i en process;
• processkontextväxlingstid (endast för operativsystem som stöder processmodellen) - tiden för växling mellan två styrtrådar som tillhör två olika processer.

Tyvärr är det inte lätt att objektivt jämföra dessa parametrar för olika RT OS, eftersom dessa parametrar inte bara beror på kvaliteten på operativsystemet, utan också på kapaciteten hos den använda hårdvaruplattformen. Helst bör alla operativsystem som jämförs installeras på samma hårdvaruplattform, varefter lämpliga mätningar bör göras. Men inte ens dessa mätningar kommer att ge ett objektivt resultat, eftersom olika operativsystem kan mer eller mindre anpassas till specifik hårdvara.

För att jämföra tidsparametrar använder den här artikeln fragmenterad data som finns på Internet, som ofta erhålls när man testar operativsystemet på olika utrustningar, medan testernas sammansättning och karaktär inte alltid är tydlig.

Ganska objektiva data kan betraktas som resultaten som erhållits av experter från tidningen Dedicated System, som genomförde tester och praktiska jämförelser av QNX RTOS 6.1, VxWorks AE 1.1 och Windows CE.NET på x86-plattformen. Även om dessa uppgifter för närvarande är föråldrade, kunde författarna till denna artikel inte hitta nyare material. I tabell Figur 2 visar valda prestandajämförelsedata mellan QNX Neutrino 6.1 och VxWorks AE 1.1. Dedicated Systems-rapporten gav företräde åt QNX när det gäller prestanda, med poängförhållandet satt till 9:5 (QNX:VxWorks), eftersom två fel upptäcktes i VxWorks under testning, för vilka det var nödvändigt att kontakta support för att rätta till dem.

I tabell 3 visar data om egenskaperna hos LynxOS. Sammansättningen av de använda testerna är inte specificerad. När det gäller data om egenskaperna hos LynxOS är den fjärde kolumnen (testning på x86-plattformen) intressant. Jämfört med VxWorks och QNX visar LynxOS RT OS en enorm fördröjning när det gäller att svara på avbrott (mer än 5 gånger). Kontextbytetiden (vilket betyder tiden för att växla mellan två trådar i samma process) är densamma som QNX och cirka 1,5 gånger mindre än VxWorks.

Stabilitet av tidsparametrar

Förutom timingegenskaper är stabiliteten hos dessa egenskaper också viktig för RT OS. Det är detta kriterium som till stor del avgör "styvheten" hos RT OS, d.v.s. förutsägbarhet av databehandlingstid, tidpunkt för utfärdande av resultat, etc.

Baserat på data från Dedicated System-journalen ligger QNX före VxWorks i detta kriterium både när det gäller spridningen av egenskaper i en serie liknande tester (förhållandet mellan maximal tid och medelvärde är betydligt mindre) och med ökande belastning (trådbytestid när antalet trådar ökar från 2 till 128 enheter. QNX växte bara 1,65 gånger, medan VxWorks växte 2,24 gånger).

Enligt data som erhållits från RTSoft är det känt att LynxOS har ungefär samma egenskaper som VxWorks.

Hantera åtkomst till resurser

Låt oss utvärdera kvaliteten på åtkomstkontroll som erbjuds av ett eller annat RT OS till kritiska resurser i datorsystemet, såsom minne och processortid.

Den första frågan som behöver besvaras är om operativsystemet stöder processmodellen. En process är en logisk enhet som äger en eller flera trådar, deras tillhörande resurser och sammanhang – innehållet i register och räknare vid varje given tidpunkt.

Processernas uppgift är:

• att avgränsa åtkomst till RAM mellan olika program under exekvering;
• i att avgränsa omfattningen av globala variabler vid tidpunkten för sammanställningen (viktigt om applikationsmjukvaran är skriven på C-språket, vilket inte stöder sådan avgränsning).

Segmentering ger också separation av adressutrymmen (i denna mening dupliceras kapaciteten för sönderdelning och processer). Dessutom ger sharding varje segment som innehåller en eller flera processer (eller trådar om operativsystemet inte stöder processmodellen) med en garanterad tidsbudget. På detta sätt, om en högprioriterad tråd går in i en loop och stör dess segment, kommer alla andra segment att få CPU-tid enligt designtidsinställningarna och fortsätta att fungera normalt.

LynxOS och QNX stöder både processmodellen och skärning. VxWorks OS har en skärningsmekanism, men stöder inte processmodellen. I allmänhet är detta acceptabelt eftersom sharding ger separation av adressutrymmen. Men bristen på processer medför vissa olägenheter. Vanligtvis görs indelning i segment baserat på programmets avsedda syfte och dess kritikalitet. Till exempel kan något segment innehålla kontrollmjukvara för ett flygnavigeringssystem som har en hög grad av kritik. Men denna programvara är också ett ganska komplext komplex, vilket vore logiskt att delas upp i oberoende (minnes)moduler. VxWorks OS tillhandahåller inte denna funktion, det vill säga segmentet kommer att bestå av trådar med delat minne, vilket komplicerar organisationen av parallell utveckling och i slutändan minskar programvarans tillförlitlighet.

Stöd för multiprocessor och distribuerade system

Kostnaden för multiprocessormoduler har nyligen minskat avsevärt, och därför har de blivit allt mer använda i inbyggda system. Naturligtvis måste RT OS ge stöd för sådana kort.

En annan lovande riktning för att bygga självgående vapen är distribuerade system, där modulerna är åtskilda i rymden, och kommunikation mellan dem sker genom någon nätverksmiljö. Återigen måste RT OS som används ha bekväma och pålitliga medel för att organisera interaktionen mellan moduler: stöd för olika nätverksprotokoll, medel för att säkerställa nätverkstransparens.

QNX RT OS erbjuder stöd för multiprocessorkort. För VxWorks har ett sådant stöd precis meddelats. Det finns ingen flygversion av LynxOS med stöd för multiprocessorkort ännu.

När det gäller stöd för nätverksprotokoll bör det noteras att RT OS LynxOS, VxWorks och QNX har ungefär lika (och breda) möjligheter. En ytterligare fördel med QNX RT OS är dess speciella nätverksundersystemsarkitektur, som säkerställer nätverkets "transparens" för applikationsprogram: vilken process som helst kan anropa en annan process på en fjärrmodul på samma sätt som en process på en lokal modul.

Stöd för filsystem

Möjligheten att lagra information i form av filer är bekväm och traditionell. Omvänt skapar avsaknaden av en sådan möjlighet svårigheter när man lagrar sällan ändrade data och skapar distribuerade system.

I tabell Figur 4 visar filsystemstödet för vart och ett av de aktuella operativsystemen.

QNX har det mest omfattande stödet för filsystem. Dessutom är dess flash-filsystem feltolerant.

Dokumentationskvalitet

Kvaliteten på dokumentationen för RT OS LynxOS, VxWorks, QNX är ganska hög. Men det finns också klagomål på dokumentationen:

• QNX är en utmärkt beskrivning av arkitekturen och designprinciperna, men en otillräcklig beskrivning av applikationsprogrammeringsgränssnittet (inte alla parametrar beskrivs, det finns inkonsekvenser);
• VxWorks - ingen förklaring av hur det fungerar och otillräcklig beskrivning av den komplexa processen att konfigurera operativsystemet.

Däremot arbetar företag med kvaliteten på materialet. Dokumentation för aktuell version QNX (6.3.2) har utökats avsevärt, vissa delar har omarbetats.

Kvaliteten på teknisk support

När det gäller kvaliteten på den officiella tekniska supporten är LynxOS den otvivelaktiga ledaren. LynuxWorks lovar att svara på alla tekniska frågor inom 4 timmar efter att förfrågan publicerats. LynxOS distribueras i Ryssland av RTSoft, som har en stor personalstyrka som kan ge kvalificerad hjälp. Nackdelen med LynxOS är att operativsystemet ännu inte är särskilt utbrett i Ryssland, därför finns det ingen etablerad användargemenskap, och det finns inte ens ett ryskspråkigt forum.

QSS (tillverkaren av QNX) erbjuder också bra teknisk support, men snabba svarstider kan inte garanteras. Till skillnad från LynxOS har QNX RT OS en välorganiserad användargemenskap både utomlands och i Ryssland. Svar på de flesta frågor kan hittas på dessa forum. QNX i vårt land distribueras av SVD Embedded Systems, vars anställda kan ge kompetent teknisk support och utföra arbete med att anpassa OS till specifika processorkort. Dessutom har företaget direkta kontakter med QSS och kan få råd i komplexa frågor från utvecklaren av QNX RT OS.

WindRiver, utvecklaren av VxWorks, har traditionellt haft en stängd teknisk policy, det vill säga information om operativsystemets driftsprinciper är ganska svår att få. Detta operativsystem har inte heller ett ryskspråkigt forum. VxWorks RV OS distribueras i vårt land av företaget AVD Systems, som huvudsakligen ägnar sig åt försäljning av färdiga mjukvaru- och hårdvarulösningar tillverkade utomlands.

Öppen källa

Ett öppet RT OS har minst tre fördelar:

• Programutvecklare kan förstå komplexa problem utan att involvera teknisk support;
• lättare att certifiera (inga bokmärken, etc.);
• mer dynamisk utveckling, eftersom RT OS-utvecklarföretaget ofta inte bara får förfrågningar om felkorrigeringar, utan också förslag för att eliminera fel och förbättra systemet. Gemenskaper av RTOS-utvecklare med öppen källkod växer som regel mycket snabbare och är bättre organiserade. Oberoende experter verkar hjälpa till att lösa problemen med den tekniska supporttjänsten och deltar i utveckling, felsökning och testning av systemet.

Sedan september 2007 har QSS QNX-kärnan med öppen källkod (inklusive Adaptive Partitioning-paketet, High Availability-paketet). Lite senare öppnades källkoderna för nätverksundersystemet. För närvarande finns betaversion 6.4.0 tillgänglig för nedladdning på den officiella webbplatsen.

Det bör noteras att idag inte alla QNX-moduler är öppen källkod (det finns till exempel inga koder för grafik och filsystem), och licensen medför en begränsning av användningen av "källan": endast för icke-kommersiellt bruk. QNX-användaren får dock ovanstående fördelar gratis.

LynxOS och VxWorks källkoder är kommersiellt tillgängliga. Priset för en sådan produkt är förhandlingsbart.

Verktyg

Tillgången på bra verktyg avgör till stor del kvaliteten och hastigheten på utvecklingen av applikationsprogram för ett visst operativsystem. Det bör noteras att LynxOS, VxWorks och QNX för närvarande tillhandahåller verktyg av god kvalitet som inkluderar en integrerad utvecklingsmiljö (IDE) och programvarufelsökning, programprofileringsverktyg (för att upptäcka " flaskhalsar" när det gäller prestanda, minne, etc.). Ergonomin hos ISD för dessa RT OS är i allmänhet inte sämre än utvecklade utvecklingsverktyg för konventionella OS (till exempel MS Windows).

Portabilitet av applikationsprogramvara

Bärbarheten av applikationsprogramvara gör det möjligt att använda den under andra operativsystem (inklusive icke-RT OS). Portabilitet ger apett visst oberoende från RT OS: vid behov kan du byta till ett annat OS till låg kostnad.

Möjligheten att skriva bärbar programvara definieras i det här ögonblicketöverensstämmelse med POSIX-standarden. Alla betraktade RT OS stöder POSIX 1003.1-standarden. LynxOS har en fördel - detta OS är binärt kompatibelt med Linux. Det vill säga att Linux-applikationer kan köras under LynxOS utan att kompilera om. Omvänt kan LynxOS-applikationer köras på Linux (version 2.4.x med glibs C-språkbibliotek version 2.2.2).

Resten av RT OS kräver omkompilering för att köra Linux-applikationer. I det här fallet kan processen att porta även POSIX-kompatibla applikationer ofta bli ganska arbetskrävande på grund av skillnader i implementeringen av bibliotek och kompilatorer.

Processorarkitekturstöd

Inhemska utvecklare av styrsystem för flyg i dagens övergångsperiod från interna operativsystem till kommersiella befinner sig ofta i en situation där de behöver välja och anpassa ett RTOS till ett befintligt processorkort. I det här fallet är ett av nyckelargumenten när du väljer ett OS stöd för processorarkitekturen som används på kortet.

Överensstämmelse med luftfartsstandarder

I utländsk praxis måste programvara för flygelektroniksystem ha ett certifikat för överensstämmelse med DO-178B-standarden. Om programvara olika nivåer kritikalitet exekveras på en processormodul, då måste RTOS som används stödja konceptet med partitioner. (Annars är det nästan omöjligt att bevisa att felet inte har spridits). Som redan nämnts är det bättre om RTOS-programmeringsgränssnittet överensstämmer med ARINC-653-standarden, eftersom standarden är välkänd för utländska certifieringsorgan.

LynxOS är ledande när det gäller efterlevnad av standarder. Den stöder ARINC-653, och det finns många exempel på DO-178B-certifierade system byggda på den. Nyckelpunkten är att LynuxWorks erbjuder en uppsättning RSC (även om författarna till artikeln inte vet något om priset).

VxWorks följer ARINC-653-standarden och system som byggs ovanpå den kan certifieras enligt DO-178B (det finns många exempel).

QNX följer inte ARINC-653, och det finns inga DO-178B-certifierade system baserade på dem ännu.

Det bör noteras att QNX-system i princip kan användas för att bygga en IMA, eftersom QNX stöder sin egen metod för att tillhandahålla partitionskonceptet, vilket är ett mycket bra alternativ till ARINC-653 och dessutom låter dig spara processortid .

När det gäller liknande ryska standarder för militär luftfart (GOST R ISO/IEC 51904-2002) finns det ännu inte ett enda exempel på ett certifierat system, även om ett sådant system i princip kan utvecklas baserat på vilket som helst av de aktuella operativsystemen. För QNX RT OS pågår för närvarande arbete med att förbereda de viktigaste OS-modulerna för certifiering.

Utveckling av specialistutbildningssystemet

Hastigheten och kvaliteten på utbildningen för personal som arbetar med RT OS och olika mjukvaruutvecklings- och felsökningsverktyg är direkt relaterad till hastigheten på mjukvaruutvecklingen och dess kvalitet. Ledande företag inom området inbäddad och systemmjukvara, såsom WindRiver, LynuxWorks, QSS, genomför ett storskaligt program med kurser och utbildningar för att studera användningen av företagets produkter, inklusive RT OS.

Jämförelseresultat

QNX Neutrino RTOS är det mest avancerade operativsystemet ur teknisk synvinkel, har en bra uppsättning verktyg och har ett relativt lågt pris. Mikrokärnarkitektur säkerställer hög tillförlitlighet och modularitet hos utvecklade system. En ytterligare fördel är den öppna källkoden. Men det finns också en "fluga i glädjen": för närvarande används QNX praktiskt taget inte någonstans inom flyget, och i detta avseende förlorar detta operativsystem till sina konkurrenter (LynxOS och VxWorks). Ytterligare nackdel med QNX: bristande överensstämmelse med ARINC-653-standarden.

Det bör noteras att QNX Neutrino i princip har alla nödvändiga mekanismer för att arbeta i flygelektroniksystem. Dessutom har tillförlitligheten och hög tillgänglighet hos QNX-baserade system bevisats i andra branscher där felkostnaden är till och med högre än inom flyget (kärnreaktorstyrning).

Arbete med att förbereda certifieringen av QNX Neutrino enligt kraven i inhemska flygstandarder utförs för närvarande av SWD Software.

RTOS LynxOS-178, tvärtom, har alla nödvändiga certifikat utomlands, även om det enligt många andra kriterier ser mindre föredraget ut än QNX Neutrino. Observera att för användning i den ryska flygindustrin måste LynxOS-178 RTOS också vara certifierad enligt inhemska GOSTs.

VxWorks OS har en lång historia av användning i verksamhetskritiska applikationer utomlands. Vår analys visar dock att det ser mindre att föredra framför de två första operativsystemen enligt många kriterier. Dessutom undergrävs VxWorks trovärdighet av dess slutna utvecklingsstrategi.

En översikt över de jämförande egenskaperna hos RT OS som finns på den ryska marknaden presenteras i förhållande till användning i flygkontrollsystem.

05/05/2008, mån, 23:56, Moskva-tid

Tack vare utvecklingen av datorteknik har det nyligen blivit möjligt att tilldela en modul uppgifter som tidigare utförts av flera processormoduler, samtidigt som man förbättrar vikt- och storleksegenskaperna hos styrsystemet och minskar dess kostnader. Denna trend inom flygteknik har lett till uppkomsten av konceptet integrerad modulär flygelektronik - IMA (Integrated Modular Avionics, IMA).

Problemet med att integrera styrfunktioner i en enda modul är att det är nödvändigt att dela de nu gemensamma resurserna (processortid, minne, kommunikationskanaler) mellan olika uppgifter, samtidigt som man säkerställer samma nivå av tillförlitlighet och oberoende av funktioner som tidigare. Realtidsoperativsystemet spelar en nyckelroll för att lösa detta problem.

För närvarande finns det flera kommersiella RTOSer för kritiska applikationer på världsmarknaden (tabell 1). Den här artikeln ger en översikt över RTOS tillgängligt på den ryska marknaden, baserat på information från öppna källor och författarnas personliga erfarenhet.

Dokument som reglerar kraven för RTOS

DO-178-standarden (Software Consideration in Airborne Systems and Equipment Certification) definierar kraven för mjukvaruutvecklingsprocessen och noggrannheten i dess verifiering beroende på dess kritiska nivå. Nivån på programvarans kritik bestäms utifrån en analys av hur allvarliga konsekvenserna av ett programvarufel är. Det finns fem nivåer av mjukvarukritikitet totalt (från A till E).

MILS (Multiple Independent Levels of Security) är ett speciellt tillvägagångssätt för OS-design som förhindrar spridning av programvarufel under körning, och även förenklar programverifiering på grund av mjukvarumodularitet. Alla ansökningar placeras i så kallade sektioner (partitioner). Partitioner har allokerade resurser (minnesområde, processortid under varje systemcykel, åtkomst till kommunikationskanaler, etc.). Tillgång till tilldelade resurser garanteras av operativsystemet som körs i övervakarläge. Således kan applikationsprogramvara med olika kritiska nivåer köras på en processormodul som kör ett operativsystem - om ett fel inträffar i mindre kritisk (och följaktligen mindre testad) programvara kommer detta inte på något sätt att påverka funktionen för andra sektioner, eftersom försök att "usurpera" andra människors resurser kommer att blockeras av operativsystemet. MILS idéer återspeglar IMA och DO-178B.

Fel 404: Sidan kan inte hittas.

Detta kan ha hänt av en av dessa anledningar:

– fel när du skriver in sidadress (URL)
– efter en "trasig" (inte-fungerande, felaktig) länk
– den begärda sidan fanns aldrig på webbplatsen eller så togs den bort

Du kan:

– gå tillbaka med webbläsarens bakåtknapp
– kontrollera korrekt stavning av sidadressen (URL)
– använd webbplatskartan eller gå till huvudsidan

ARINC-653-standarden (Avionics Application Software Standard Interface) specificerar ett APEX-applikationsprogramvarugränssnitt som stöder ett partitionskoncept i MILS-stil. Detta gränssnitt innehåller funktioner för hantering av partitioner, processer, tidsdelning, kommunikation mellan och inom partitioner och övervakning av systemstatus. Det bör noteras att ARINC-653-standarden beskriver ett allmänt accepterat tillvägagångssätt för att implementera MILS-idéer för IMA, även om det kan finnas andra implementeringar. En RTOS för flyg som överensstämmer med ARINC-653 har fördelar eftersom denna standard är välkänd och förstådd av internationella certifieringsorgan, så det är lättare att få ett DO-178B överensstämmelsecertifikat för ett system byggt enligt denna standard.

Återanvändbara programvarukomponenter standard. I enlighet med DO-178B genomgår programvaran för ett visst flygapplikationssystem hela certifieringsförfarandet, även om det använder moduler (komponenter) som redan har certifierats tidigare som en del av ett annat system. Ett av de senaste initiativen från FAA (Federal Aviation Certification Agency, USA) är att definiera kriterier för återanvändning av programvara utan omcertifiering. Komponenter som kanske inte är omcertifierade kallas RSC (Reusable Software Components). Det krävs mer ansträngning att få RSC-certifierad, men då ger RSC betydande besparingar.

Ryska dokument som definierar programvarukrav (inklusive RTOS):

• GOST R ISO/IEC 51904-2002 ("Inbäddade systemprogramvara. Allmänna krav för utveckling och dokumentation") - en analog till DO-178B för militär luftfart;
• KT-178A ("Kvalifikationskrav del 178A") - en analog till DO-178B för civil luftfart;
• GOST R ISO/IEC 12207-99 ("Informationsteknologi. Programvarulivscykelprocesser").

Jämförelsen av RT OS utfördes enligt 13 parametrar, som tar hänsyn till tekniska kriterier, enkel utveckling och ekonomiska parametrar.

OS timing parametrar

Ett av huvudkraven för RT OS är den minsta fördröjningstiden för bearbetning av en händelse. I praktiken betyder det att följande parametrar måste vara små:

• avbrottssvarstid - tiden mellan den faktiska förekomsten av avbrottet och början av behandlingen av den första instruktionen från avbrottshanteraren;
• styr trådbytestid - bytetid mellan två trådar i en process;
• process context switching time (endast för OS som stöder processmodellen) - switching time mellan två styrtrådar som tillhör två olika processer.

Tyvärr är det inte lätt att objektivt jämföra dessa parametrar för olika RT OS, eftersom dessa parametrar inte bara beror på kvaliteten på operativsystemet, utan också på kapaciteten hos den använda hårdvaruplattformen. Helst bör alla operativsystem som jämförs installeras på samma hårdvaruplattform, varefter lämpliga mätningar bör göras. Men inte ens dessa mätningar kommer att ge ett objektivt resultat, eftersom olika operativsystem kan mer eller mindre anpassas till specifik hårdvara.

För att jämföra tidsparametrar använder den här artikeln fragmenterad data som finns på Internet, som ofta erhålls när man testar operativsystemet på olika utrustningar, medan testernas sammansättning och karaktär inte alltid är tydlig.

Ganska objektiva data kan betraktas som resultaten som erhållits av experter från tidningen Dedicated System, som genomförde tester och praktiska jämförelser av QNX RTOS 6.1, VxWorks AE 1.1 och Windows CE.NET på x86-plattformen. Även om dessa uppgifter för närvarande är föråldrade, kunde författarna till denna artikel inte hitta nyare material. I tabell Figur 2 visar valda prestandajämförelsedata mellan QNX Neutrino 6.1 och VxWorks AE 1.1. Dedicated Systems-rapporten gav företräde åt QNX när det gäller prestanda, med poängförhållandet satt till 9:5 (QNX:VxWorks), eftersom två fel upptäcktes i VxWorks under testning, för vilka det var nödvändigt att kontakta support för att rätta till dem.

I tabell 3 visar data om egenskaperna hos LynxOS. Sammansättningen av de använda testerna är inte specificerad. När det gäller data om egenskaperna hos LynxOS är den fjärde kolumnen (testning på x86-plattformen) intressant. Jämfört med VxWorks och QNX visar LynxOS RT OS en enorm fördröjning när det gäller att svara på avbrott (mer än 5 gånger). Kontextbytetiden (vilket betyder tiden för att växla mellan två trådar i en process) är densamma som QNX och är cirka 1,5 gånger mindre än VxWorks.

Stabilitet av tidsparametrar

Förutom timingegenskaper är stabiliteten hos dessa egenskaper också viktig för RT OS. Det är detta kriterium som till stor del avgör "styvheten" hos RT OS, d.v.s. förutsägbarhet av databehandlingstid, tidpunkt för utfärdande av resultat, etc.

Baserat på data från Dedicated System-loggen ligger QNX före VxWorks i detta kriterium både när det gäller spridningen av egenskaper i en serie liknande tester (förhållandet mellan maximal tid och medelvärde är betydligt mindre) och med ökande belastning (trådbytestid när antalet trådar ökar från 2...128 enheter för QNX ökade endast 1,65 gånger, medan för VxWorks - 2,24 gånger).

Enligt data som erhållits från RTSoft är det känt att LynxOS har ungefär samma egenskaper som VxWorks.

Hantera åtkomst till resurser

Låt oss utvärdera kvaliteten på åtkomstkontroll som erbjuds av ett eller annat RT OS till kritiska resurser i datorsystemet, såsom minne och processortid.

Den första frågan som behöver besvaras är om operativsystemet stöder processmodellen. En process är en logisk enhet som äger en eller flera trådar, deras tillhörande resurser och sammanhang – innehållet i register och räknare vid varje given tidpunkt.

Processernas uppgift är:

• att avgränsa åtkomst till RAM mellan olika program under exekvering;
• i att avgränsa omfattningen av globala variabler vid tidpunkten för sammanställningen (viktigt om applikationsmjukvaran är skriven på C-språket, vilket inte stöder sådan avgränsning).

Segmentering ger också separation av adressutrymmen (i denna mening dupliceras kapaciteten för sönderdelning och processer). Dessutom ger sharding varje segment som innehåller en eller flera processer (eller trådar om operativsystemet inte stöder processmodellen) med en garanterad tidsbudget. På detta sätt, om en högprioriterad tråd går in i en loop och stör dess segment, kommer alla andra segment att få CPU-tid enligt designtidsinställningarna och fortsätta att fungera normalt.

LynxOS och QNX stöder både processmodellen och skärning. VxWorks OS har en skärningsmekanism, men stöder inte processmodellen. I allmänhet är detta acceptabelt eftersom sharding ger separation av adressutrymmen. Men bristen på processer medför vissa olägenheter. Vanligtvis görs indelning i segment baserat på programmets avsedda syfte och dess kritikalitet. Till exempel kan något segment innehålla kontrollmjukvara för ett flygnavigeringssystem som har en hög grad av kritik. Men denna programvara är också ett ganska komplext komplex, vilket vore logiskt att delas upp i oberoende (minnes)moduler. VxWorks OS tillhandahåller inte denna funktion, det vill säga segmentet kommer att bestå av trådar med delat minne, vilket komplicerar organisationen av parallell utveckling och i slutändan minskar programvarans tillförlitlighet.

Stöd för multiprocessor och distribuerade system

Kostnaden för multiprocessormoduler har nyligen minskat avsevärt, och därför har de blivit allt mer använda i inbyggda system. Naturligtvis måste RT OS ge stöd för sådana kort.

En annan lovande riktning i konstruktionen av automatiska styrsystem är distribuerade system, där moduler separeras i rymden och kommunikation mellan dem sker genom någon nätverksmiljö. Återigen måste RT OS som används ha bekväma och pålitliga medel för att organisera interaktionen mellan moduler: stöd för olika nätverksprotokoll, medel för att säkerställa nätverkstransparens.

QNX RT OS erbjuder stöd för multiprocessorkort. För VxWorks har ett sådant stöd precis meddelats. Det finns ingen flygversion av LynxOS med stöd för multiprocessorkort ännu.

När det gäller stöd för nätverksprotokoll bör det noteras att RT OS LynxOS, VxWorks och QNX har ungefär lika (och breda) möjligheter. En ytterligare fördel med QNX RT OS är dess speciella nätverksundersystemsarkitektur, som säkerställer nätverkets "transparens" för applikationsprogram: vilken process som helst kan anropa en annan process på en fjärrmodul på samma sätt som en process på en lokal modul.

Stöd för filsystem

Möjligheten att lagra information i form av filer är bekväm och traditionell. Omvänt skapar avsaknaden av en sådan möjlighet svårigheter när man lagrar sällan ändrade data och skapar distribuerade system.

I tabell Figur 4 visar filsystemstödet för vart och ett av de aktuella operativsystemen.

QNX har det mest omfattande stödet för filsystem. Dessutom är dess flash-filsystem feltolerant.

Dokumentationskvalitet

Kvaliteten på dokumentationen för RT OS LynxOS, VxWorks, QNX är ganska hög. Men det finns också klagomål på dokumentationen:

• QNX är en utmärkt beskrivning av arkitekturen och designprinciperna, men en otillräcklig beskrivning av applikationsprogrammeringsgränssnittet (inte alla parametrar beskrivs, det finns inkonsekvenser);
• VxWorks - ingen förklaring av driftsprinciper och otillräcklig beskrivning av den komplexa processen att konfigurera operativsystemet.

Däremot arbetar företag med kvaliteten på materialet. Dokumentationen för den aktuella versionen av QNX (6.3.2) har utökats avsevärt, och vissa delar har omarbetats.

Kvaliteten på teknisk support

När det gäller kvaliteten på den officiella tekniska supporten är LynxOS den otvivelaktiga ledaren. LynuxWorks lovar att svara på alla tekniska frågor inom 4 timmar efter att förfrågan publicerats. LynxOS distribueras i Ryssland av RTSoft, som har en stor personalstyrka som kan ge kvalificerad hjälp. Nackdelen med LynxOS är att operativsystemet ännu inte är särskilt utbrett i Ryssland, därför finns det ingen etablerad användargemenskap, och det finns inte ens ett ryskspråkigt forum.

QSS (tillverkaren av QNX) erbjuder också bra teknisk support, men snabba svarstider kan inte garanteras. Till skillnad från LynxOS har QNX RT OS en välorganiserad användargemenskap både utomlands och i Ryssland. Svar på de flesta frågor kan hittas på dessa forum. QNX i vårt land distribueras av SVD Embedded Systems, vars anställda kan ge kompetent teknisk support och utföra arbete med att anpassa OS till specifika processorkort. Dessutom har företaget direkta kontakter med QSS och kan få råd i komplexa frågor från utvecklaren av QNX RT OS.

WindRiver, utvecklaren av VxWorks, följer traditionellt en sluten teknisk policy, det vill säga information om operativsystemets driftsprinciper är ganska svår att få. Detta operativsystem har inte heller ett ryskspråkigt forum. VxWorks RV OS distribueras i vårt land av företaget AVD Systems, som huvudsakligen ägnar sig åt försäljning av färdiga mjukvaru- och hårdvarulösningar tillverkade utomlands.

Öppen källa

Ett öppet RT OS har minst tre fördelar:

• applikationsprogramutvecklare kan förstå komplexa problem utan att involvera teknisk support;
• lättare att certifiera (inga bokmärken, etc.);
• mer dynamisk utveckling, eftersom RT OS-utvecklarföretaget ofta inte bara får förfrågningar om felkorrigeringar, utan också förslag för att eliminera fel och förbättra systemet. Gemenskaper av RTOS-utvecklare med öppen källkod växer som regel mycket snabbare och är bättre organiserade. Oberoende experter verkar hjälpa till att lösa problemen med den tekniska supporttjänsten och deltar i utveckling, felsökning och testning av systemet.

Sedan september 2007 har QSS QNX-kärnan med öppen källkod (inklusive Adaptive Partitioning-paketet, High Availability-paketet). Lite senare öppnades källkoderna för nätverksundersystemet. För närvarande finns betaversion 6.4.0 tillgänglig för nedladdning på den officiella webbplatsen.

Det bör noteras att idag inte alla QNX-moduler är öppna (till exempel finns det inga koder för grafik och filsystem), och licensen innebär en begränsning av användningen av "källkod": endast för icke-kommersiellt bruk. QNX-användaren får dock ovanstående fördelar gratis.

LynxOS och VxWorks källkoder är kommersiellt tillgängliga. Priset för en sådan produkt är förhandlingsbart.

Verktyg

Tillgången på bra verktyg avgör till stor del kvaliteten och hastigheten på utvecklingen av applikationsprogram för ett visst operativsystem. Det bör noteras att LynxOS, VxWorks och QNX för närvarande tillhandahåller verktyg av god kvalitet som inkluderar en integrerad utvecklingsmiljö (IDE) och programvarufelsökning, programprofileringsverktyg (för att upptäcka flaskhalsar i prestanda, minne, etc.). Ergonomin hos ISD för dessa RT OS är i allmänhet inte sämre än utvecklade utvecklingsverktyg för konventionella OS (till exempel MS Windows).

Portabilitet av applikationsprogramvara

Bärbarheten av applikationsprogramvara gör det möjligt att använda den under andra operativsystem (inklusive icke-RT OS). Portabilitet ger apett visst oberoende från RT OS: vid behov kan du byta till ett annat OS till låg kostnad.

Möjligheten att skriva bärbar programvara bestäms för närvarande av överensstämmelse med POSIX-standarden. Alla betraktade RT OS stöder POSIX 1003.1-standarden. LynxOS har en fördel - detta OS är binärt kompatibelt med Linux. Det vill säga att Linux-applikationer kan köras under LynxOS utan omkompilering. Omvänt kan LynxOS-applikationer köras på Linux (version 2.4.x med glibs C-språkbibliotek version 2.2.2).

Resten av RT OS kräver omkompilering för att köra Linux-applikationer. I det här fallet kan processen att porta även POSIX-kompatibla applikationer ofta bli ganska arbetskrävande på grund av skillnader i implementeringen av bibliotek och kompilatorer.

Processorarkitekturstöd

Inhemska utvecklare av styrsystem för flyg i dagens övergångsperiod från interna operativsystem till kommersiella befinner sig ofta i en situation där de behöver välja och anpassa ett RTOS till ett befintligt processorkort. I det här fallet är ett av nyckelargumenten när du väljer ett OS stöd för processorarkitekturen som används på kortet.

Överensstämmelse med luftfartsstandarder

I utländsk praxis måste programvara för flygelektroniksystem ha ett certifikat för överensstämmelse med DO-178B-standarden. Om programvara med olika kritiska nivåer exekveras på samma processormodul, måste RTOS som används stödja konceptet med partitioner. (Annars är det nästan omöjligt att bevisa att felet inte har spridits). Som redan nämnts är det bättre om RTOS-programmeringsgränssnittet överensstämmer med ARINC-653-standarden, eftersom standarden är välkänd för utländska certifieringsorgan.

LynxOS är ledande när det gäller efterlevnad av standarder. Den stöder ARINC-653, och det finns många exempel på DO-178B-certifierade system byggda på den. Nyckelpunkten är att LynuxWorks erbjuder en uppsättning RSC (även om författarna till artikeln inte vet något om priset).

VxWorks följer ARINC-653-standarden, och system som byggs ovanpå den kan certifieras enligt DO-178B (det finns många exempel).

QNX följer inte ARINC-653, och det finns inga DO-178B-certifierade system baserade på det ännu.

Det bör noteras att QNX-system i princip kan användas för att bygga en IMA, eftersom QNX stöder sin egen metod för att tillhandahålla partitionskonceptet, vilket är ett mycket bra alternativ till ARINC-653 och dessutom låter dig spara processortid .

När det gäller liknande ryska standarder för militär luftfart (GOST R ISO/IEC 51904-2002) finns det ännu inte ett enda exempel på ett certifierat system, även om ett sådant system i princip kan utvecklas baserat på vilket som helst av de aktuella operativsystemen. För QNX RT OS pågår för närvarande arbete med att förbereda de viktigaste OS-modulerna för certifiering.

Utveckling av specialistutbildningssystemet

Hastigheten och kvaliteten på utbildningen för personal som arbetar med RT OS och olika mjukvaruutvecklings- och felsökningsverktyg är direkt relaterad till hastigheten på mjukvaruutvecklingen och dess kvalitet. Ledande företag inom området inbäddad och systemmjukvara, såsom WindRiver, LynuxWorks, QSS, genomför ett storskaligt program med kurser och utbildningar för att studera användningen av företagets produkter, inklusive RT OS.

Jämförelseresultat

QNX Neutrino RTOS är det mest avancerade operativsystemet ur teknisk synvinkel, har en bra uppsättning verktyg och har ett relativt lågt pris. Mikrokärnarkitektur säkerställer hög tillförlitlighet och modularitet hos utvecklade system. En ytterligare fördel är den öppna källkoden. Men det finns också en "fluga i glädjen": för närvarande används QNX praktiskt taget inte någonstans inom flyget, och i detta avseende förlorar detta operativsystem till sina konkurrenter (LynxOS och VxWorks). En ytterligare nackdel med QNX: bristande överensstämmelse med ARINC-653-standarden.

Det bör noteras att QNX Neutrino i princip har alla nödvändiga mekanismer för att arbeta i flygelektroniksystem. Dessutom har tillförlitligheten och hög tillgänglighet hos QNX-baserade system bevisats i andra branscher där felkostnaden är till och med högre än inom flyget (kärnreaktorstyrning).

Arbete med att förbereda certifieringen av QNX Neutrino enligt kraven i inhemska flygstandarder utförs för närvarande av SWD Software.

RTOS LynxOS-178, tvärtom, har alla nödvändiga certifikat utomlands, även om det enligt många andra kriterier ser mindre föredraget ut än QNX Neutrino. Observera att för användning i den ryska flygindustrin måste LynxOS-178 RTOS också vara certifierad enligt inhemska GOSTs.

VxWorks OS har en lång historia av användning i verksamhetskritiska applikationer utomlands. Vår analys visar dock att det ser mindre att föredra framför de två första operativsystemen enligt många kriterier. Dessutom undergrävs VxWorks trovärdighet av dess slutna utvecklingsstrategi.

Expertgrupp / R&D.CNews

Skriva ut