Realtids operativsystem för avionik: granskning. Utvecklingsfunktioner med OSRV

Alla råd

Urval för service i luftfart är extremt strikt och bekymmer inte bara flygkomposition utan även operativsystem i realtid (OS RV). Tänk på vilka krav som åläggs kommersiella system för luftfart från organisationer som ansvarar för säkerhetsflyg. Utan tvekan kommer det att bidra till att förstå kraven, betydande för många andra branscher, - varhelst ett snabbt svar på händelser behövs, hög tillförlitlighet, vitalitet och säkerhet för de tillämpade fonderna, inklusive programvaruverktyg.

Federal Aviation Administration är en av de auktoritativa organisationerna som ansvarar för säkerhetsflygningar - gör strikta krav på kommersiella realtidssystem, som antagits för drift (detta är särskilt sant för civil luftfart, där hundratals passagerare är beroende av sitt arbete). Bland dem:

krav på "hård" realtid Deterministiskt beteende vid olika belastningar på det system som krävs i ansvarsfullt applikationer och hög tillgänglighetssystem;
hög "vitalitet", så att om du vägrar någon del av programvaran fortsatte den andra delen att fungera normalt;
stränga kvalitetskrav, vilket innebär överensstämmelse med olika sektoriella, nationella och internationella standarder.
tillförlitlighetskrav; Sannolikheten för ett misslyckande i programmet bör vara mycket litet;
säkerhets- och sekretessbehov Systemet bör tillhandahålla medel för att skydda den viktigaste informationen.

Regulatoriska systemkrav

Vi listar de grundläggande dokumenten som reglerar kraven för operativsystem i realtid inom luftfartsområdet.

Standard DO-178 - Programvaruhänsyn i luftburna system och utrustning certifiering. Utvecklad och stödd av den tekniska tekniska kommissionen för Aeronautics Association (RTCA, www.rtca.org.). Standarden definierade fem nivåer av fel, för var och en indikerar en uppsättning programvarukrav som är utformade för att garantera hela systemets prestanda som helhet i händelse av fel på denna nivå:

nivå A. - Skydd mot misslyckanden som leder till katastrofala konsekvenser

nivå B. - Skydd mot misslyckanden som leder till farliga konsekvenser

nivå C. - Skydd mot misslyckanden som leder till stora konsekvenser

nivå D. - Skydd mot misslyckanden som leder till minimala konsekvenser

e nivå E. - Skydd mot misslyckanden som inte leder till några konsekvenser.

Standard ED-12B. Europeisk ekvivalent DO-178B. Den europeiska organisationen för civil luftfartsutrustning (Eurocae, www.eurocae.org) bestäms av föreningen.

RTCA DO-248B - Slutlig årsredovisning för förtydligande av DO-178B. Förklarande dokument till-178b. Huvudämnena inkluderar sektioner som tidigare utvecklad programvara, kommersiella mjukvaruprodukter, verifieringsprocesser, historiska referenser, automatiserade verktyg etc.

Standard DO-254 - Design Assurance Guidance för luftburna elektroniska hårdvara. Designad och stödd av RTCA-föreningen. Dokumentet skapades för att hjälpa tillverkare av flygplan och leverantörer av luftfarts elektronisk utrustning, se till att deras elektroniska utrustning säkert utför de nödvändiga funktionerna. Dokumentet reglerar processerna för maskinens livscykel och beskriver sätt att säkerställa de nödvändiga egenskaperna hos produkter för att intyga dem i enlighet med kraven i kraven.

ARINC 653 - Avionics Application Software Standard Interface. ARINC har utvecklats 1997 och bestämmer APEX Universal-programgränssnittet (Application / Executive) mellan operativsystemet i datorns dator och tillämpad programvara. Gränssnittskraven definieras på ett sådant sätt att applikationer kan kontrollera sändningen, anslutningen och tillståndet för de interna bearbetade elementen. Som en av de grundläggande kraven för realtidssystem i luftfart kommer ARINC 653 in i arkitekturen hos den isolerade (partitionering) av virtuella maskiner.

Allmänna kriterier för bedömning av sekretessen för informationsteknik (gemensamma kriterier för informationsteknikens säkerhetsutvärdering). Sats av krav och villkor för sekretess ( www.commoncriteria.org.), godkänd av Förenta staternas nationella säkerhetsbyrå och Förenta staternas nationella institut och teknik, samt relevanta organ i andra länder (för närvarande 13 fler länder, utom USA). År 1999 mottog de "allmänna kriterierna" statusen för den internationella standarden ISO 15408.

Mils - flera oberoende säkerhetsnivåer / säkerhet. Utvecklas av intresserade organisationer, som US Air Force Research Laboratory, Lockheed Martin, USA: s nationella säkerhetsbyrå etc. MILS-projektet gör det möjligt att matematisk verifiering av systemkärnsystemet genom att minska funktionaliteten på grund av presentationen av De fyra erforderliga kraven i kraven (informationsflöde, datalisolering, periodbehandling, skada begränsning). MILS-arkitektur är ett system med isolerade sektioner, vilka var och en innefattar kärnan, mjukvaran hos det mellanliggande skiktet och applikationen (fig 1).

Fikon. 1. mils-arkitektur

POSIX - Bärbart operativsystemgränssnitt för UNIX. Bestämmer operativsystemets bärbara gränssnitt vid nivån av källtext. Huvudspecifikationen är utvecklad som IEEE 1003.1 och godkänd som en internationell standard ISO / IEC 9945-1: 1990. Ur sikt av realtidsoperativsystem är tre standarder av största intresse: 1003.1a (OS-definition), 1003,1B (Realtime Extensions) och 1003,1C (trådar).

Begreppet isolerade partitioner

I många aspekter skär regleringsdokumenten, kompletterar varandra. Som ett resultat av många studier antogs begreppet isolerade sektioner som huvud. Tillfredsställelse med kraven på styv isolering bör vara "beprövade" programlösningsleverantörer i enlighet med certifieringsmetoden som anges i DO-178B. Det finns olika tillvägagångssätt för genomförandet av isolerade partitioner, men idag antas arkitekturen som motsvarar ARINC 653, vilket bestämmer isolatstödet för realtidsoperativsystemet och beskrivningen av beskrivningen använder också C och ADA-95.

Från användarens synvinkel är ARINC 653 APEX-gränssnittsspecifikationen (ansökan / verkställande) och bestämmer inte dess genomförande. Således genomför vissa mjukvaruleverantörer sändning med en monoloral avsändare, andra med en två-nivå, när de första nivån hanterar sektioner och andra processer inom varje sektion. Denna situation med stöd för ARINC 653 medför svårigheter att certifiera mjukvaruprodukter som endast motsvarar ARINC 653 - samma API kan visas på olika sätt att implementeringar. Som ett resultat framkom många mycket olika realtidssystem, vilket emellertid motsvarar ARINC 653-specifikationen.

I fig. 2 visar systemarkitekturen med flera isolerade sektioner, var och en är en oberoende applikation. All data- och programkod i varje sektion samlas ihop och exekveras i användarläge. Komponenter "Modulärt operativsystem" och "Board Support Package" (Board Support Package, BSP) utförs i ett handledarläge. Dessutom kan det finnas en speciell sektion med några speciella funktioner, till exempel I / O-verktyg och lägesbrytning.

ARINC 653 anger bara ett gränssnitt för att dela information mellan sektioner, som var och en representerar en viss applikation plus partitionsoperativsystem (POS). Detta gränssnitt måste säkerställa isoleringen av de nedanstående elementen.

BAGGE. Varje partition kännetecknas av ett kontinuerligt linjärt fysiskt adressutrymme, vars gränser inte kan förändras under systemoperationen. För varje sektion utförs valet och frisättningen av minnet och MOS övervakas. I realtidsoperativsystemet bör säkerställa isolering av information i adressutrymmet i det linjära "stycket som är allokerat till varje sektion. Detta gäller för programkoden, konstanter, statiska data, stack och "heap" (område där minne tas från förfrågan).

Tiden för att använda processorn. Processer i ett avsnitt kan antingen inte påverka processernas beteende i en annan sektion, eller påverka dem i förväg med en viss och kontrollerad metod (till exempel genom att ställa in vissa flaggor eller betingelser). ARINC 653 kräver att processorns tid tilldelas varje sektion strikt cykliskt, och äganderätten till processorn för varje partition bör ställas in i förväg i konfigurationstabellen. Inuti varje sektion kan processerna konkurrera med varandra för processorns tid baserad på prioriteringar ("förskjuta" med avsändning med prioritetsförskjutning.

Programkod. För vissa MOS-minnesområden sätter ut i handledsläge) exekveringsattributet. Det betyder att applikationer i användarläge inte kan förstöra kodområdet.

Avbrott. Avbrott är asynkrona händelser som kräver särskild vård ur synvinkel för att säkerställa partitioner. Det är viktigt att de inte "uttråkas" vid tiden och minnet i ett annat avsnitt. En av de möjliga avbrottskällorna är timers som styr sändningen av händelser både inuti POS och inuti MOS.

För att säkerställa isolering av avbrott, antagna ett antal avtal. Timeravbrott uppstår endast i handledsläge; Direkt tillgång till klockan i användarläge är inte möjligt. Om POS och MOS är på olika skyddsnivåer, måste mekanismen förses med spridningen av tillfälliga händelser information i applikationskivor som arbetar i användarläge. I de stunderna när sektionen är aktiv (äger processortid) bör alla tillfälliga händelser som rör den överföras. När sektionen är inaktiv måste alla tillfälliga händelser som är relaterade till den sparas och sedan när den är aktiverad överförs till den.

En annan avbrytningskälla är externa ingångs- / utgångsenheter. I enlighet med kraven i ARINC 653, för anordningar med synkron dataöverföring, rekommenderas det att använda enhetsundersökningsalgoritmen. Men vissa enheter kräver avbrottshantering. Dessa avbrott måste behandlas av MOS och sedan överföras till POS vid tidpunkten för aktivering av sektionen. Självklart kan det finnas tillfälliga förseningar och till och med förlust av information, och därför bör utvecklaren ta hänsyn till detta.

ARINC 653 definierar inte bara urvalskrav, utan även interaktionsmekanismerna mellan dem. Följande interaktionsfunktioner matas in mellan sektionerna:

meddelandeutbyte Genom att etablera en kommunikationskanal, som måste beskrivas i förväg i systemkonfigurationstabellen;

utbyte genom buffertVid vilken endast en partition kan skriva till en specifik buffert, och alla andra - läs inte; Detta ger möjlighet att sända information mellan sektioner.

DO-178B standard

DO-178B-standarden beskriver tekniken och metoderna som garanterar integriteten och tillförlitligheten hos programvara, som täcker alla stadier av sin livscykel - planering, utveckling, design, kodning, integration och testning.

Planering enligt DO-178B bör innehålla följande planer: Plan för certifieringsprogramvaror. Projektplan för programvara; Programvaruverifieringsplan; Programvarukonfigurationshanteringsplan; Programvarukvalitetssäkringsplan. Under hela livscykeln måste DO-178-standarden säkerställas vid formulering av krav, design, kodning, verifiering och dokumentation. Programvarukrav (krav på hög nivå), Programvaruprojekt (krav och arkitektur), programkod i käll- och objektformulär bör utvecklas. Var och en av de konstruerade komponenterna måste verifieras med olika kriterier. Verifiering av krav på hög nivå på programvara innefattar verifiering av följande villkor: Krav som överensstämmer med systemkrav och är tillgängliga för analys tillsammans med systemkraven. Krav är korrekta och samordnade Kraven är kompatibla med hårdvara och måste därför bekräftas av resultaten.

Verifiering av mjukvaruprojektet innefattar verifiering av projektkraven uppfyller kraven på hög nivå och kan analyseras, är korrekta och samordnade och måste därför bekräftas av resultaten. På samma sätt måste programvaran och koden för programvara verifieras, som dessutom måste uppfylla de krav som anges i DO-178B. Denna standard definierar processen att verifiera programvaruintegrationsfasen, kontrollera fullständigheten av verifieringsprocessen själv, vilket säkerställer konfigurationshantering (inklusive versionskontroll), kvalifikationerna för automatiserade medel.

Standarden definierar tre nivåer av blocktestning av koden:

omfattande uttalanden innebär att varje uttalande i programmet orsakas minst en gång.
lösningstäckningen innebär att varje ingångs- och utgång i programmet utfördes minst en gång och att varje lösning i programmet fick alla möjliga (booleska) utgångsvärden åtminstone en gång;
lösningarna på det modifierade tillståndet innebär att varje ingångspunkt och utgång i programmet utfördes minst en gång att varje lösning i programmet tog alla möjliga (booleska) utgångsvärden åtminstone en gång och att varje tillstånd i lösningen ledde till en oberoende förändring i utgångsvärdena.

Certifieringsnivåer som definieras i DO-178B skiljer sig åt i antalet krav (verifieringsdjup), vilket måste vara nöjda med programvaran. Teoretiska aspekter av verifieringen av koden framgår av olika grundläggande monografier, i synnerhet i drift.

DO-178B-certifieringen måste utföras av de så kallade "utsedda teknikrepresentanterna", som utses av Federal Aviation Administration för amerikansk luftfart för att verifiera de data som används i certifiering. Utvecklaren syftar till att certifiera sin programvara i enlighet med DO-178B för att få tillstånd att använda sin programvara (inklusive realtidssystemet) i luftfart. Upplösningen gäller inte bara programvara, utan också till hela produkten (projekt) som helhet. För att starta certifieringsprocessen måste utvecklaren först "öppna" projektet och ta emot FAA det officiella projektnumret eller att ansluta sig till det befintliga projektet med det redan utfärdade numret. För projektets "öppning" måste du få ett typcertifikat eller ett extra typcertifikat. Som regel är typcertifikatet tilldelat flygplanet, och all utrustning som finns med det här certifikatet. Ett ytterligare typcertifikat ges till extra utrustning på flygplanet, inklusive programvara.

"Allmänna kriterier" för att bedöma sekretessen

"Allmänna kriterier" definierar nivåerna av sekretessgaranti-utvärderingssäkringsnivå (EAL) och utvärderar inte bara produkternas säkerhet och tillförlitlighet utan även processerna för deras utveckling och stöd som garanterar den snabba lösningen på problem. I förhållande till operativsystemen anges kraven i "allmänna kriterier" i detalj. Sju nivåer av sekretessgaranti är markerade:

Eaal1 (funktionellt testad) - Tillämplig där minsta sekretess krävs, men säkerställer sekretess betraktas inte som ett viktigt krav.

Eaal2 (strukturellt testad) - Gäller med de omständigheter där utvecklare eller användare kräver den genomsnittliga nivån på garanterad sekretess i avsaknad av fullständig information om alla utvecklingsförfaranden.

EAL3 (metodiskt testad och kontrollerad) - Tillämpa där utvecklare eller användare kräver en genomsnittlig garanterad sekretess och kräver en uttömmande studie av operativsystemet och dess utvecklingsstadier, men utan att tillgripa en väsentlig bearbetning av operativsystemet.

Eaal4 (metodiskt utformad, testad och granskad) - Gäller med de omständigheter där utvecklare eller användare kräver en hög grad av garanterad sekretess för operativsystemet och kräver en särskild revidering av ett befintligt operativsystem för att säkerställa dessa krav.

EAL5 (semi formellt utformad och testad) - Gäller att utvecklare eller användare kräver en hög grad av garanterad sekretess för operativsystemet och ett strikt sätt att designa, så att dessa fastigheter läggs på designfasen med hjälp av särskild sekretessbeställning.

Alla6 (semi formellt verifierad, designad och testad) - Tillämpa om det finns en hög nivå av farliga situationer och där höga kostnader för skydd mot obehörig åtkomst är motiverade.

EAL7 (formellt verifierad, utformad och testad) - Det bör tillämpas i ansökningar med ett mycket högt pris vid obehörig åtkomst.

EAL-nivå bekräftas av ett särskilt laboratorium av gemensamma kriterier testlaboratorium.

Tabellen visar en lista över de maximala kraven för sekretessgaranti för att systemet ska uppfylla Nivån på EAL7.

Lynxos-178-systemet

Basen av Lynxos-178 är realtidsoperativsystemet Lynxos V.3, som utförs i en isolerad sektion. Lynxos V.3 är certifierad för överensstämmelse med standard POSIX 1003.1-1996 på Intel och PowerPC-plattformen.

Lynxos-178-nyckelegenskapen stöds av flera tidsavskiljda, minnes- och skiljevägar i enlighet med kraven i ARINC 653. Lynxos-178 (version 2.0) Stödjer: Upp till 16 sektioner (virtuella maskiner), inklusive rotdel; upp till 64 processer; upp till 51 trådar inuti varje process; sändning av strömmar i realtidssektionen; Funktionerna för interprocessing interaktion inom sektionen.

Varje sektion är helt isolerad, vilket gör det omöjligt att sprida misslyckanden mellan sektioner.

Med hjälp av lynxos-178 serveras fasta sektioner som lynxos virtuella maskiner. Varje applikationsprocess är verksam inom sin egen operativsystemmiljö, som om han arbetade på sin egen processor. Detta är tillämpligt på alla processorresurser och namngivna utrymmen. Denna abstraktion skyddar utvecklaren av det tillämpade systemet från ytterligare ansträngningar vid programmering av ett komplext system. Avsnittshantering övervakas med hjälp av det virtuella maskinkonfigurationstabellen (Vctual-Machine Configuration Tabell, VCT) och är obligatorisk i Lynxos-178-miljön, så att applikationsutvecklaren kan koncentrera sig på utvecklingen av applikationer och inte på organisationen av separationen av separationen av systemet. Dessutom stöder Lynxos-178 separation av system som är kompatibla med RTCA DO-255, vilket tillåter att utföra programvara med olika säkerhetsnivåer genom DO-178B i olika sektioner (virtuella maskiner). Det innebär att operativsystemet kan utföra en applikation med en nivå A (av DO-178B) på en virtuell maskin och en applikation med en nivå C till en annan, och båda applikationerna arbetar på samma processor inom samma system.

Lynxos-178-versionen som en del av olika produkter (till exempel Bombardier Challenger 300 Aircraft Company Rockwell Collins är certifierat enligt DO-178B-standarden och själva arbetssystemets arkitektur ( fikon. 3.) Uppfyller kraven i ARINC 653.

Lynxos-178 innehåller följande grupp av systemtjänster i enlighet med ARINC 653: Partitionshantering - Hantera partitioner, Processhantering - Processhantering, Time Management - Time Management, Interpartition Kommunikation - Samverkan av processer i olika sektioner (Samla porttjänster och köport Tjänster), IntraMartition Kommunikation - Processer Interaktion inom ett avsnitt (Buffertjänster, Blackboard Tjänster, Semaphore-tjänster, Evenemangstjänster), Hälsoövervakning - Kontroll av operativsystem eller utrustning.

Under 2006 måste prototyps operativsystem som motsvarar EAL7 släppas. Den nya Lynxsecure-kärnan utvecklas, kompatibel med MILS-krav, som bara innehåller 8 tusen rader av källkoden och kommer att uppfylla EAL7-kraven.

Oavsett tvivel är kraven för operativsystem i realtid mycket betydelsefulla för många andra branscher, såsom havsflottan, militär- och rymdsystem, kommunikationssystem, försörjningssystem, system avsedda för användning i nödsituationer - varhelst behöver snabb reaktion på händelser , hög tillförlitlighet, hållbarhet och säkerhet för tillämpade medel, inklusive programvara.

Litteratur

Kommersiell Off-the-Self realtids operativsystem och arkitektonisk övervägning. Slutrapport, U.S. Federal Aviation Administration, Dot / FAA / AR-03/77, februari 2004.
Partitionering i avionik. Arkitektur: Krav, mekanik och försäkran. Slutrapport, National Aeronautics and Space Administration, DOT / FAA / AR-99/58, NASA / CR-1999-209347, mars 2000.
Studie av kommersiella Off-the-Self (COTS) realtidsoperativsystem (RTO) i luftfartsansökan. Slutrapport, U.S. Federal Aviation Administration, Dot / FAA / AR-02/118, december 2002.
Utvärdering av operativsystem i realtid - standardernas roll. Avionic Systems Standardization Committee (ASSC), dok nr: ASSC / 330/2/141, mars 1997.
G. Mayers, konsten av mjukvarutestning. John Wiley & Sons, 1979.
COTS Säkerhetsskyddsprofil - Operativsystem (CSPP-OS), NISTIR 6985, april 2003.
Vanliga kriterier för säkerhetsutvärdering av informationsteknik. Del 3: Behov av säkerhetssäkring. Augusti 1999, version 2.1, CCIMB-99-033.

Sergey Zolotarev ( [E-post skyddad]) - Anställd av företaget "RTSoft" (Moskva).

FAR ALAR Stratotanker Strategisk Bomber Dispenser har beslutats att uppgradera för att säkerställa att International Global Air Traffic Management och DO-178B standarder. Integrerat bearbetningscenter, som utvecklats av Rockwell Collins, tillhandahåller databehandling och nätverksfunktioner som kan användas för att utföra flera olika uppgifter (uppdrag, flygkontroll, visar support). Grundläggande funktionalitet expanderar, vilket gör att du kan genomföra ytterligare applikationer. Datautbyte med annan utrustning utförs på "Aviation" -versionen av Ethernet-nätverket. Integrerat bearbetningscenter, det finns flera utbytbara linjer utbytbara modul linjära moduler. Ett certifierat realtidsoperativsystem LYNXOS-178 körs på den vanliga datamodulens datormodul och på ingångs- / utgångskoncentratormodulen I / O-navet.

KC-767 Tanker-flygplanet, som också fungerar Lynxo-178-operativsystemet, är klart att härleda luftfyllning i US Air Force till en ny nivå och skicka de gamla KC-135E-tankarna i mer än fyra decennier. Ett nytt fartyg är inte bara bra, men också mer tillförlitlig, vilket gör det lämpligt för ett bredare utbud av verksamheter. Faktum är att KC-767 är fyra olika flygplan i en. En nivå där besättningen är lätt att utrusta för att transportera passagerare eller varor utan att det påverkar tankens funktionalitet. Dessutom kan det göras så att skeppet, beroende på situationen, var passagerare, sedan en blandad typbärare.

I engelskspråkig litteratur används två termer - säkerhet och säkerhet, som helt enkelt kan översättas till ryska. Men de betecknar olika begrepp, och i den här artikeln kommer vi att använda säkerhet som en synonym för säkerhet och säkerhet - sekretess. - Cirka. Bil

Särskiljande egenskaper hos OSR från det allmänna ändamålet

Allmänna ändamål, särskilt multiplayer, som UNIX, är inriktade på den optimala fördelningen av datorresurser mellan användare och uppgifter. I realtidsoperativsystem flyttar en sådan uppgift till bakgrunden - allt som återkommer före huvuduppgiften - har tid att reagera på händelser som uppstår vid objektet. Den andra skillnaden - användningen av realtidsoperativsystemet är alltid associerat med utrustning, med ett objekt, med händelser som uppstår vid anläggningen. Realtidsoperativsystemet är inriktat på att bearbeta externa händelser. Realtidsoperativsystemet kan likna användargränssnittet på ett allmänt ändamål, men det fungerar helt annorlunda. Dessutom är användningen av realtidsoperativsystem alltid specifikt. Om det allmänna ändamålet vanligtvis uppfattas av användarna (inte utvecklare) som en färdigställd applikation, tjänar realtidsoperativsystemet bara ett verktyg för att skapa ett visst hårdvaru- och mjukvarukomplex av realtid. Och därför är den bredaste klassen av användarnas operativsystem utvecklare av realtidskomplex, personer som utformar förvaltnings- och datainsamlingssystem. Utforma och utveckla ett specifikt realtidssystem, vet programmeraren alltid exakt vilka händelser som kan uppstå på anläggningen, känner till den kritiska servicetiden för var och en av dessa händelser. RV-systemet måste ha tid att svara på en händelse som inträffade på objektet under den tid som är kritisk för denna händelse. Storleken på den kritiska tiden för varje händelse bestäms av objektet och händelsen själv, och kan vara annorlunda, men systemreaktionstiden måste förutsägas (beräknas) när man skapar ett system. Bristen på reaktion i förutsagt tid anses vara ett fel för realtidssystem. Systemet måste ha tid att svara på samtidigt händelser. Även om två eller flera externa händelser inträffar samtidigt, bör systemet ha tid att reagera på var och en av dem under de tidsintervall som är kritiska för dessa händelser.

	Realtids OS	Generell mening
Huvuduppgiften	Ha tid att reagera på händelser som uppstår på utrustningen	Distribuera optimalt datorresurser mellan användare och uppgifter
Vad är orienterat	Bearbetar externa händelser	Bearbetar användaråtgärder
Som placerad	Verktyg för att skapa ett specifikt hårdvara och mjukvarupaket av realtid	Uppfattas av användaren som en uppsättning applikationer som är färdiga för användning
Vem är avsedd	Kvalificerad utvecklare	Användarekonomiska kvalifikationer

Hårda och mjuka realtidssystem

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

Hårda realtidssystem tillåter inte några systemreaktionsfördröjningar under inga omständigheter som:

resultat kan vara värdelösa om sena
en katastrof kan inträffa i händelse av en reaktionsfördröjning

kostnaden för att försenas kan vara oändligt stor.

Exempel på hårda realtidssystem är ombordkontrollsystem, akutskyddssystem, nöddekoratorer.

Mjuka realtidssystem kännetecknas av det faktum att reaktionsfördröjningen inte är kritisk, även om den kan leda till en ökning av kostnaden för resultaten och en minskning av systemets prestanda som helhet. Till exempel - nätverksoperationen . Om systemet inte hade tid att bearbeta nästa mottagna paket, leder detta till en timeout på den sändande sidan och skickas (beroende på protokollet, förstås). Uppgifterna är inte förlorade, men nätverksprestandan minskar. Källan mellan hårda och mjuka realtidssystem kan uttryckas så här: det hårda realtidssystemet är aldrig sent med svaret på en händelse, systemet med mjuk realtid - bör inte vara sen med reaktionen på evenemanget

Kärna av operativsystemet

Kärnan är den centrala delen av operativsystemet (OS), vilket ger applikationer samordnad åtkomst till datorresurser, minne, extern hårdvara, extern ingång och utmatningsenhet, som översätter programmets språkkod till språket i binära koder, vilket förstår datorn. Hur det grundläggande elementet i operativsystemet, kärnan är den lägsta abstraktionsnivån för att få tillgång till applikationer till de systemresurser som krävs för sitt arbete. Kärnan tillhandahåller som regel sådan tillgång till de exekverbara processerna för relevanta applikationer genom att använda interaktionsmekanismer i samband med interaktionsmekanismer och överklagar systemets utmaningar.

Monolitisk kärna

Den monolitiska kärnan ger en rik uppsättning utrustningstraktioner. Alla delar av den monolitiska kärnan fungerar i ett adressutrymme. Detta är ett sådant system för operativsystemet där alla komponenter i kärnan är kompositdelar av ett program, använder allmänna datastrukturer och interagerar med varandra genom att direkt anropa procedurer. Den monolitiska kärnan är det äldsta sättet att organisera operativsystem. Ett exempel på system med en monolitisk kärna är majoriteten av UNIX-systemen.

Värdighet: Arbetshastighet, förenklad modulutveckling.

nackdel: Eftersom kärnan arbetar i ett adressutrymme kan ett fel i en av komponenterna störa hela systemets prestanda.

Några gamla monolitiska kärnor, speciellt UNIX / Linux-klasssystem, erforderlig omkompilering om den är utrustad med utrustningskomposition. De flesta moderna kärnor låter dig ladda moduler under drift som utför en del av kärnfunktionerna. I det här fallet är komponenterna i operativsystemet inte oberoende moduler, och komponenterna i ett stort program kallas den monolitiska kärnan (monolithisk kärna), som är en uppsättning procedurer, som var och en kan orsaka var och en. Alla procedurer fungerar i privilegierad läge.

Microofer

Micronier ger endast elementära processhanteringsfunktioner och en minsta uppsättning abstraktioner för att arbeta med utrustning. Det mesta av arbetet utförs med hjälp av speciella användarprocesser som heter tjänster. Det avgörande kriteriet för "mikroordid" är placeringen av alla eller nästan alla förare och moduler i serviceprocesserna.

Värdighet: Motstånd mot utrustningsfel, fel i systemkomponenter. Den största fördelen med den mikronukleära arkitekturen är en hög grad av modularitet hos operativsystemkärnan. Detta förenklar avsevärt tillägget av nya komponenter i den. I det mikronukleotala operativsystemet, utan att avbryta det, ladda ner och lossa nya drivrutiner, filsystem etc. är processen att felsöka kärnkomponenterna väsentligt förenklad, eftersom den nya versionen av föraren kan laddas utan att starta hela operativsystemet. Komponenterna i operativsystemkärnan är inte fundamentalt annorlunda än användarprogram, därför kan vanliga medel användas för att felsöka dem. Den mikronukleära arkitekturen ökar systemets tillförlitlighet, eftersom felet på nivån på det obevekliga programmet är mindre farligt än kärnläge.

nackdel: Datatransmission mellan processer kräver överliggande.

Onsdagsexekvering

Krav på realtidssystem Exekveringsmiljö:

ett litet minne av systemet - för möjligheten att bädda in det;
systemet ska vara helt bosatt i minnet för att undvika ersättning av minnessidor eller swappar;
systemet måste vara multitasking - för att säkerställa en effektiv användning av alla systemresurser.
kärna med prioritet för avbrottstjänst. Prioriteten för avbrott innebär att en process som är klar för en lansering som har viss prioritet, nödvändigtvis en fördel i kön med en lägre prioritetsprocess, ersätter snabbt den senare och anländer. Kärnan avslutar något servicearbete så snart uppgiften med högsta prioritet är mottagen. Detta säkerställer systemets förutsägbarhet;
en prioriterad sändare - gör det möjligt att utveckla ett applikationsprogram för att prioritera varje startmodul utan misslyckande. Prioriterade uppdrag används för att bestämma ordningen för lanseringsprogram som är klar för utförande. Alternativ till en sådan sändningstyp är typkontrollen "Carousel", där varje redo att fortsätta programmet ges lika möjlighet att lansera. När du använder den här metoden finns det ingen kontroll över vilket program och när kommer att utföras. I realtidsmediet är det oacceptabelt. Skickning, som bygger på prioriteringsprincipen, och närvaron av en kärna med en avbrottsprioritering tillåter utvecklaren av ett applikationsprogram för att fullt ut övervaka systemet. Om en händelse inträffar med högsta prioritet, slutar systemet bearbeta uppgiften med den lägre prioriteten och svarar på den nyligen mottagna förfrågan.

Kombinationen av de ovan beskrivna egenskaperna skapar en kraftfull och effektiv realtidsexekveringsmiljö.

Förutom exekveringsmiljön är det också nödvändigt att överväga den tjänst som tillhandahålls av realtidskärnan. Grunden för en realtidsexekveringsmiljö är en kärna eller avsändare. Kärnan hanterar måldatorns hårdvara: en central processor, minne och I / O-enheter; Kontrollerar arbetet med alla andra system och programvara som tillämpas. I realtidssystemet sker avsändaren mellan hårdvaran på måldatorn och applikationsprogrammet. Det ger en speciell tjänst som krävs för driften av realtidsapplikationer. Den tjänst som tillhandahålls av kärnan ger ansökningar till tillgång till sådana resurser i systemet, t.ex. minnes- eller ingångs- / utgångsenheter.

Kärnan kan ge en tjänst av olika typer:

Interfreferbyte. Det är ofta nödvändigt att säkerställa överföring av data mellan program inom samma system Dessutom är det i många tillämpningar ett behov av att interagera med andra system via nätverket. Intern kommunikation kan utföras via meddelandeöverföringssystemet. Extern kommunikation kan organiseras antingen via ett datagram (det bästa sättet att leverera) eller av länklinjer (garanterad leverans). Urvalet av detta eller den metoden beror på kommunikationsprotokollet.
Dataseparation. I de tillämpade programmen som arbetar i realtid är den längsta datainsamlingen. Data behövs ofta för att arbeta andra program eller behöver ett system för att utföra någon av dess funktioner. Många system ger tillgång till delade minnesavsnitt. Organisationen av datakön är utbredd. Många köer används, som alla har sina egna fördelar.
Bearbetningsförfrågningar för externa enheter. Varje realtidsansökan är associerad med en extern anordning av en specifik typ. Kärnan ska tillhandahålla I / O-tjänster som tillåter applikationer att läsa från dessa enheter och spela in på dem. För realtidsapplikationer är närvaron av en extern enhet som är specifik för denna ansökan vanlig. Kärnan måste ge en tjänst som gör det lättare att arbeta med drivrutiner. Till exempel, för att ge möjlighet att spela in på hög nivå språk - som SI eller Pascal.
Bearbetar speciella situationer. En speciell situation är en händelse som uppstår under programmet. Det kan synkroniseras om dess förekomst är förutsägbar, som till exempel delning till noll. Och kanske asynkron, om det förekommer oförutsägbart, som till exempel en spänningsfall. Att tillhandahålla möjligheten att hantera händelser av denna typ tillåter realtidsprogram snabbt och förutsägbart att svara på interna och externa händelser. Det finns två metoder för bearbetning av speciella situationer - användningen av statliga värden för att detektera felaktiga förhållanden och användningen av speciella situationshanterare för att avbryta felaktiga förhållanden och justera dem.

Översikt över arkitekturer Orvv

För sin historia har arbetssystemens arkitektur genomgått betydande utveckling. En av de första principerna för konstruktion, monolitiskOS (Figur 1) inkluderades i OS-vyn som en uppsättning moduler som interagerar med varandra på olika sätt inuti systemkärnan och använde applikationsinmatningsgränssnitt för tillgång till utrustning.

nivå OS (Figur 2). Till exempel är ett sådant os ett välkänt MS-DOS-system. I dessa klasssystem kan applicerade applikationer komma åt utrustningen inte bara via systemkärnan eller dess bosatta tjänster, men också direkt. Enligt denna princip byggdes OrRV i många år. Jämfört med monolitiskt operativt ger en sådan arkitektur en betydligt större grad av förutsägbarhet för systemreaktionerna, och gör det också möjligt att snabbt komma åt applicerade applikationer till utrustningen. Nackdel

sådana system är frånvaro av multitasking i dem. Som en del av en sådan arkitektur reducerades problemet med att bearbeta asynkrona händelser till buffring av meddelanden och sedan seriell intervju av buffertarna och bearbetningen. Samtidigt säkerställdes överensstämmelse med den kritiska livslängden genom hög hastighet av beräkningskomplexet jämfört med hastigheten på externa processer.

Figur 2. Arkitekturnivå OS

En av de mest effektiva arkitekturerna för att bygga realtidsoperativsystem är klient-serverarkitekturen. Det övergripande systemet för operativprogrammet på denna teknik presenteras i Figur 3. Grundprincipen för en sådan arkitektur är att göra OS-tjänster i form av servrar till användarnivån, och microkernel utför meddelandets funktioner mellan klienten Användarprogram och servrar - Systemtjänster. En sådan arkitektur ger många fördelar med hänsyn till kraven för OSR och Embedded Systems. Bland dessa fördelar kan noteras:

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

2. Ett sådant system är bättre skalat, eftersom onödiga tjänster kan uteslutas från systemet utan att det påverkar dess prestanda.

3. Systemfelsoleransen ökar, för "Walked" -tjänsten kan startas om utan

omstart-system.

Figur 3. Bygg ett operativsystem med hjälp av klient-serverarkitekturen

Tyvärr, idag, inte så många operativsystem, implementeras i principen om klient-servern. Bland de välkända OSRS som genomför mikrokitekturen kan OS9 och QNX noteras.

Referenslista:

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

2) http://www.asutp.ru/?p\u003d600591

3) http://www.mka.ru/?p\u003d40774

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

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

Realtids operativsystem - RTO) Se programvara och är utformade för att upprätthålla digitala system i fall där:

● Systemet bör inte bara ge resultatet av behandlingen mottagen information, men också varaktigheten av resultattiden. Från OSR krävs det tillsammans med att erhålla det önskade resultatet för att genomföra de angivna tidsparametrarna: tidsintervall mellan händelser och svar eller den angivna frekvensen för att ta emot externa data och utfärdande resultat.

● Systemet kan utföra flera uppgifter samtidigt. Typisk multisasciaoperativsystemet allokerar varje uppgift (program) med samma tidsintervall, vilket skapar användaren med användaren att alla program utförs samtidigt. Realtidsoperativsystemet är ett speciellt fall av ett multisascaid operativsystem optimerat för att genomföra kontrollprocesserna. Det svarar snabbt på externa händelser och låter dig imitera flera processorer, var och en kontrollerar en enhet. För att hantera ett komplext system med en enda processor är det därför lämpligt att använda OSR, som kan samordna genomförandet av olika uppgifter. Ett exempel på OSR kan fungera som ett hissstyrsystem.

OSRV-principen

När frågan är mottagen, kontrollerar du inmatningsdata för att lösa problemet. Om du har tillgång är uppgiften att utföras. Om det inte finns några nödvändiga inmatningsdata går OSR till nästa uppgift (om du har en begäran om utförande). För att ta emot inmatning och starta motsvarande uppgift används avbrott. Att köra uppgiften görs vanligtvis genom att skicka den från köen av väntande uppgifter till kön av uppgifter som är avsedda för utförande.

Varje uppgift har en ingångskö av meddelanden som den endast kan behandlas inom det tilldelade tidsintervallet eller när det begärs att avbryta. Om svaret tar för mycket tid, läggs uppgiften tillbaka till kön av kommandon som utförts, och kontrollen överförs av nästa uppgift.

Systemresurser (hårddiskar, timers, I / O-enheter, etc.) är vanligtvis endast tillgängliga för specifika uppgifter. Detta gör att du kan organisera frågeköer på ett sådant sätt att du förhindrar samtidig tillgång till en resurs till flera uppgifter.

Krav på Orvd.

Modern PB OS bör uppfylla följande krav:

● liten svarstid (vilket resulterar i resultatet);

● Genomförande av multitasking-läge med en flexibel prioriteringsmekanism;

● litet minne (tillräckligt för att rymma i ansökningssystemets bostad);

● Förekomsten av servicefunktioner och supportverktyg för att utveckla applikationsprogram och ett antal andra.

För närvarande används utvecklingen av mikrokontrollersystem för att utveckla olika egenskaper och testas i sådana tillämpningar som, kontroll- och mätsystem, telekommunikationsutrustning, rymd- och militär utrustning, transport, säkerhetssystem etc.

Typer av osRV

Du kan välja två typer av OSRV:

● hårda realtidssystemsom upptar en liten mängd minne och har minsta svarstid, men har mycket begränsade serviceverktyg. De implementeras enligt den modulära principen, vilket gör att du bara kan använda de verktyg som behövs i den här applikationen. Som ett resultat uppnås en signifikant minskning av mängden minne och svarstid;

● Mjuka realtidssystem som kräver ett större minne, har en längre svarstid, men den är nöjd med ett brett utbud av användarkrav för serviceunderhållsläge, den tjänst som tillhandahålls. Mjuka realtidssystemgränssnittsverktyg gör att du kan använda mycket effektiva debuggers eller integrerade utvecklingsmiljöer.

System med mjuk realtid.

Denna typ av system kommer att övervägas vid exemplet på OS-9-systemet med mikrovågssystem. Som en OS -9-verktygsdator använder IBM-PC i Windows onsdag eller Sun, HP-arbetsstationer, IBM RS / 6000 med UNIX Operationssystem. Egenskaper OS -9:

● Modularitet som ger möjlighet att konfigurera mål OSR i enlighet med klassen av löst uppgifter. Exklusive oanvända moduler kan du minska mängden minne och minska kostnaden för systemet.

● Flexibiliteten hos strukturen som ger systemets omkonfiguration och expandera sin funktionalitet. Funktionella komponenter OS-9:

● Realtidskärnan (OS-9 kärna);

● Allmänt I / O-verktyg (I / O-man);

● Filhanterare;

● Programutvecklingsverktyg.

OS -9 Funktionskomponenter är gjorda i form av autonoma moduler som kan raderas eller läggas till med hjälp av enkla kommandon som inte kräver att en återkoppling eller återanslut. Kombinera moduler kan du skapa måloperativsystem med olika funktionalitet.

Tänk på de ovanstående funktionella komponenterna.

Kärna av realtid

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

● Atomkärnan som implementerar det minsta antalet servicefunktioner (fjärrkontroll, en länk med ett lokalt nätverk, drivna mikrokontroller). Kärnan används i system inbäddade i olika utrustning, har en liten volym (24 kb) och ger en minsta svarstid (3 μs med en klockfrekvens på 25 MHz);

● Standardkärna, som säkerställer ett brett utbud av service- och applikationsprogramvaror, för genomförandet av vilket kräver ett större minne (upp till 512K ROM Byte och 38K Byte RAM). Genom att ändra kärnfunktionsmodulerna kan du implementera system med varierande komplexitet och destination: från kontrollerna inbäddade i utrustningen med bosatt programvara och de enklaste I / O-verktygen till komplexa armed utvecklat nätverksstöd och tillhandahållande av en sortiment av servicefunktioner, inklusive multimedia.

OS -9-systemet ger användaren möjlighet att välja kärnan beroende på systemets funktionella ändamål. Allmänt I / O-verktyg. OS -9 fysiska gränssnittet med en mängd olika externa enheter tillhandahålls av en uppsättning drivrutiner,skapat av både mikrovågssystem och många utrustningsutvecklare med det här operativsystemet för specifika applikationer. Filhanterare. Dessa inkluderar moduler som styr logiska dataflöden. Var och en av modulerna har ett specifikt funktionellt syfte och specifikation. Filhanterare kan delas upp i tre grupper:

● Standardledare som syftar till att utföra sådana grundläggande utbytesfunktioner med externa enheter som en organisation av en order av inkommande kommandon, byte och blockera sekventiell utbyte och utbyte med direkt tillgång till minnet.

● Nätverks- och kommunikationschefer som tillhandahåller OS -9 med olika nätverk och datautbyte över kommunikationskanaler med de vanligaste börsnoterna.

● Chefer av grafiskt gränssnitt och arbetar med multimediaapplikationer. Programutvecklingsverktyg. OS -9 har ett mjukvarupaket (BSP) för att stödja utvecklingsbrädor, vilket ger SBC-samarbete med en enda SBC (enstaka datorer - en enstaka dator). Med hjälp av BSP och OS-9 kan du konfigurera målsystemet för en viss applikation.

OS-9-systemet omfattar programmeringsstöd: Ultra C / C ++ -kompilatörer, ACS-textredigerare, tre typer (inklusive symboliska) debuggers, en uppsättning verktyg för att organisera kontroll och montering av mjukvaruprodukter. Dessutom finns det en stor uppsättning (kompatibel med OS -9) Programmeringsverktyg som utvecklas av andra företag. Fastra. till. Fastrak onsdag kommer i samband med OS-9 och ger användaren den mest kompletta uppsättningen programmerings- och felsökningsverktyg. En del av Fastrak-programvaran är installerad på den instrumentella datorn, och delen är på användarmålsystemet. Fastrak-miljön integrerar alla medel som är nödvändiga för att stödja design / debugging av målsystem. Fastrak-miljön är att arbeta på IBM-PC-verktygsdatorn består av:

● Textredigerare med tangentbord som återkallar verktyg, vilket möjliggör redigering i ett användarvänligt format;

● Ultra C / C ++ -kompilatorer;

● Debuggers som tillhandahåller två debug-lägen: beställnings- Att skapa programprogram, och systemisk- För att upprätthålla avbrott, samtal och överklagande till kärnarealtid;

● Gränssnittsverktyg med logiska analysatorer av företaget.

Fastrak-miljön har en bred funktionalitet, vilket gör det till ett effektivt sätt att skapa programvara för olika mikrokontrollersystem.

Microware Systems levererar ett antal systempaket som är inriktade på olika tillämpningar:

● Trådlöst OS -9 - för att utveckla trådlösa enheter: mobiltelefoner, personsökare, bärbara digitala assistenter (PDA);

● Internet OS -9 - Att utveckla enhetens åtkomst till Internet;

● Digital Audio / Video Interactive Decoder (DAVID) OS -9 - För att utveckla distribuerade digitala interaktiva TV-system.

Hårt realtidssystem

Funktioner av denna typ av system överväger exemplet på VXWorks-systemet för Windriver Systems, som är utformat för att fungera med mikroprocessorfamiljer av många tillverkare. VXWorks-systemet är installerat på det definierade målsystemet och fungerar i samband med det integrerade Tornado-utvecklingsmediet som fungerar på den instrumentella datorn. IBM - PC arbetar i Windows, eller Sun, HP, etc., etc. används som en instrumental dator. KORT BESKRIVNING AV SYSTEMET VXWorks. Den lägre nivån på den hierarkiska organisationen av systemet tjänar som en mikrokonditionering av realtid, som utför grundläggande funktioner för planeringsuppgifter och hantering av deras band och synkronisering. Den minsta uppsättningen av kärnmoduler upptar en 20-40k minnesbyte. Alla andra funktioner - minneshantering, ingång / utgång, nätverksutbyte och andra implementeras av ytterligare moduler. För att stödja grafiska applikationer har VXWorks ett VX-Windows-grafiskt gränssnitt.

Med ett begränsat minne av målsystemet kan du använda RTGL-grafikbiblioteket, som innehåller grundläggande grafiska primitiva, teckensnittsuppsättningar och färger, drivrutiner av typiska inmatningsenheter och grafiska styrenheter. VXWorks innehåller också olika supportverktyg för olika nätverksprotokoll. Spårning specificeradhändelser och deras ackumulering i buffertminne för efterföljande analys Utför realtids speciella felsökningsprodukter och spårning systemiskhändelser - Dynamisk Windview Analyzer. Windview Analyzer fungerar som en logisk analysator, som visar uppgiftskopplingsdiagram på skärmen, registrerar meddelanden och andra processer på skärmen. Stetoskopdataövervakningen gör att du kan analysera den dynamiska förändringen i användar- och systemvariabler, inklusive procedurprofilen. VXWorks innehåller:

● Programvarupaket för att stödja utvecklingsbrädor;

● VXSIM Simulator som låter dig simulera på Verktygslådan Multitasking VXWorks och ett gränssnitt med målsystemet, samt utveckla och felsöka programvaran utan att ansluta målsystemet.

För den integrerade felsökningen av mål VXWorks-system, ger ett gränssnitt med kretsemulatorer och ROM-emulatorer. Integrerad utvecklingsmiljö Tornado. . Tornado innehåller VXWorks 5.3-systemet, som inkluderar realtidskärnan och systembibliotek, programmeringsverktyg, en högnivå debugger och ett antal andra system i systemet. Ytterligare medel för Tornado-miljön säkerställer ledningen av felsökningsprocessen, visualisera målsystemets tillstånd, andra servicefunktioner. Den öppna arkitekturen i Tomado-miljön gör att användaren kan ansluta sina egna specialverktyg och expandera möjligheterna till standardverktyg.

Realtidsoperativsystemet VXWorks tillsammans med Tornado-integrerat medium är ett kraftfullt sätt att implementera riktade system som arbetar i hårda begränsningar på mängden minne som används och svarstid till externa händelser.

Ryska federationens ministerium och vetenskap

Volga State Technological University

Sammanfattning på disciplin

"Realtids operativsystem: Funktioner och applikation"

Utförs: Student EF (grupp PI-12)

Mikushov Yu. V.

[E-post skyddad]

Föreläsare: Borodin A. V.

Yoshkar-Ola.

● Introduktion

● Definition

● Utveckling av moderna operativsystem

● Modernt tillstånd av ämnesområdet

● Skillnader från allmänna operativsystem

● arkitektur osrv

● Typer av uppgifter OS

● Fem viktigaste osynliga uppgifter

● Funktioner

● Ansökan

● Operativsystemmarknaden

● Framtida Orvv

● Slutsats

● Lista över använda källor

Introduktion

Operativsystem (OSR) är avsedda att ge ett gränssnitt till resurserna av realtidskritiska resurser. Huvuduppgiften i sådana system är aktualitet (aktualitet) av databehandling.

Som huvudkravet för OSRV, kravet att säkerställa förutsägbarhet eller deterministiskt Systemets beteende i de värsta externa förhållandena, vilket skämtsamt skiljer sig från kraven på prestanda och hastighet av Universal OS. En bra delning har förutsägbart beteende med alla scenarier av systemstart (samtidiga avbrott och streaming).

Det finns en slags skillnad mellan realtidssystem och inbyggda system. Det inbäddade systemet kräver inte alltid att det har förutsägbart beteende, och i det här fallet är det inte ett realtidssystem. Men även en snabb titt på eventuella inbyggda system tyder dock på att de flesta inbäddade system behöver förutsägbart beteende, åtminstone för viss funktionalitet, och således kan dessa system hänföras till realtidssystem.

Det är vanligt att skilja systemen för mjuk (mjuk) och hård (hård) realtid. I hårda realtidssystem leder oförmågan att säkerställa reaktionen på eventuella händelser vid en viss tid till misslyckanden och omöjligheten att utföra uppgiften. I de flesta ryska språklitteraturen kallas sådana system system med deterministisk tid. I praktisk tillämpning måste reaktionstiden vara minimal. System av mild realtid kallas system som inte faller under definitionen "HARD", för Det finns ingen tydlig definition för dem i litteraturen. Mjuka realtidssystem kanske inte har tid att lösa uppgiften, men det leder inte till att systemet misslyckas som helhet. I realtidssystem är det nödvändigt att införa en viss politisk term (i engelskspråkig litteratur - deadline) före utgången av vilken uppgiften nödvändigtvis (för mjuka realtidssystem - det är önskvärt) att utföras. Denna gränsperiod används av uppgiftschemalagaren för att tilldela uppgiftsprioriteten när den startas och när man väljer en uppgift för utförande.

Definitioner

Realtidssystemet är typen av operativsystem, vars huvudsyfte är att tillhandahålla den nödvändiga och tillräckliga uppsättningen funktioner som säkerställer utvecklingen av programvaran i realtid på specifik maskinvaruutrustning.

Systemet kallas realtidssystemet, om korrektheten av sin operation beror inte bara på den logiska korrektheten av beräkningar, men också på den tidpunkt för vilka dessa beräkningar görs. Det vill säga för händelser som uppstår i ett sådant system, när dessa händelser inträffar, lika viktigt som händelsens logiska korrekthet.

Realtidskomponenter.

Programvara		Avsändande
		Inter-streaming
Realtids operativsystem		Bearbetningsavbrott
	Skydda från inversionsprioriteringar	Flödeshantering
		Minneshantering
Hårdvara			Anordningar

Avkodning av Mac OS X:

"Mac" betyder namnet Macintosh.

"OS" - operativsystem, det vill säga operativsystemet.

"X" - Det romerska antalet tio, betyder antalet versionen av operativsystemet.

Utveckling av moderna operativsystem

I utvecklingen av moderna operativsystem är det en tendens till vidare överföring av koden till de övre nivåerna och avlägsnande av allt som är möjligt från kärnläget och lämnar minsta microkernel. Det utförs vanligtvis genom att skifta utförandet av de flesta operativsystemuppgifter till användarprocesserna.

Ta emot en begäran om vilken operation som helst, till exempel att läsa filblocket, användarprocessen (nu kallad den serverade processen eller klientprocessen) skickar en förfrågan till servern (servering) processen som behandlar det och skickar tillbaka svaret.

Tack vare separationen av operativsystemet på den del, som bara hanterar ett element i systemet (filsystem, processer, terminal eller minne) blir alla delar små och hanterbara.

Dessutom, eftersom alla servrar fungerar som processer i användarläge, och inte i kärnläge, har de inte direkt tillgång till utrustning. Om ett fel uppstår på filservern kan därför filen förfrågningsbehandling kollapsas, men det brukar inte stoppa hela maskinen helt.

En annan fördel med klient-servermodellen är dess enkla anpassning att använda i distribuerade system. Om klienten kommunicerar med servern, skickar du meddelanden till honom, inte klienten behöver inte veta om det bearbetas lokalt på egen maskin, eller det skickades över nätverket till servern på en fjärrmaskin. Från kundens synvinkel händer samma sak i båda fallen: begäran skickades och svaret mottogs.

Trendated ovanför kärnans berättelse, hantering av överföringen av meddelanden från kunder till servrar och tillbaka, är inte helt realistisk. Vissa operativsystemfunktioner, till exempel nedladdningskommandon till register med fysiska I / O-enheter, är svårt om det är mycket möjligt att utföra från program i användarutrymmet. Det finns två sätt att lösa detta problem.

Det första är att vissa kritiska serverprocesser (till exempel I / O-enheter) verkligen startas i kärnläge, med full tillgång till utrustningen, men de kommunicerar med andra processer med hjälp av en konventionell meddelandeöverföringskrets.

Den andra metoden är att bädda in en minsta informationsbehandlingsmekanism i kärnan, utan att lämna godkännandet av politiska lösningar för servrar i användarutrymmet. Kärnan kan till exempel identifiera meddelanden som skickas på vissa adresser. För kärnan betyder det att du måste ta innehållet i meddelandet och ladda det, säg till I / O-registren på en skiva för att starta skivläsaren.

I det här exemplet kan kärnan till och med inte undersöka byte av meddelandet om de visade sig vara tillåtna eller meningslösa. Det kan blint kopiera dem till diskregistren. (Självklart bör vissa system som begränsar processens cirkel med rätten att skicka sådana meddelanden) användas.

Det aktuella läget för ämnesområdet

Föreningar, företag och produkter

Microsoft och Apple Inc. är de mest populära tillverkarna av operativsystem och programvara till dem i den moderna världen.

Moderna operativsystem från Microsoft:

Windows XP (Windows NT 5.1)

Windows Vista (Windows NT 6.0)

Windows 7 (Windows NT 6.1)

Windows 8 (Windows NT 6.2)

Windows 10 (Windows NT 10)

Moderna operativsystem från Apple Inc:

Moderna mobila operativsystem:

Linux-system (Android)

Skillnader från operativsystem för allmänt bruk

Den viktigaste skillnaden mellan OSR-kärntjänsterna är deterministisk, baserat på strikt kontroll av tiden, arten av sitt arbete. I det här fallet är det determinismen underförstått att för att utföra en operativsystemstjänst krävs ett temporärt intervall med en välkänd varaktighet. Teoretiskt kan denna tid beräknas med matematiska formler, som bör vara strängt algebraisk och bör inte inkludera några tidsparametrar för en slumpmässig karaktär. Eventuellt slumpmässigt värde som definierar tiden för att utföra uppgiften i OSR kan orsaka en oönskad försening i ansökan, då kommer nästa uppgift inte att läggas i sin kvant, vilket kommer att orsaka ett fel.

I detta avseende är det allmänna operativsystemen inte deterministiska. Deras tjänster kan tillåta slumpmässiga förseningar i sitt arbete, vilket kan leda till en avmattning i ansökans svar på användarens handlingar i en avsiktligt okänd tidpunkt. Vid konstruktion av konventionella operativsystem fokuserar inte utvecklarna deras uppmärksamhet på den matematiska apparaten att beräkna tiden för den specifika uppgiften och tjänsten. Det är inte kritiskt för sådana system

Arkitektur Orvv

För sin historia har arbetssystemens arkitektur genomgått betydande utveckling. En av de första principerna för konstruktion, så kallad Det monolitiska OS (Figur 1) inkluderades i OS-vyn som en uppsättning moduler som interagerar på olika sätt inuti systemkärnan och använde applikationsinmatningsgränssnitt för applicering på utrustning. Den största nackdelen med sådan arkitektur är den dåliga förutsägbarheten för sitt beteende som orsakas av systemmodulernas komplexa interaktion.

De flesta av de moderna operativsystemen, både realtid och allmänt syfte, bygger emellertid på denna princip.

I Automatiseringsuppgifterna var nivåerna (Figur 2) utbredd som OSR. Ett exempel på ett sådant os är ett välkänt MS-DOS-system. I dessa klasssystem kan applicerade applikationer komma åt utrustningen inte bara via systemkärnan eller dess bosatta tjänster, men också direkt. Enligt denna princip byggdes OrRV i många år. Jämfört med monolitiskt operativt ger en sådan arkitektur en betydligt större grad av förutsägbarhet för systemreaktionerna, och gör det också möjligt att snabbt komma åt applicerade applikationer till utrustningen. Nackdelen med sådana system är frånvaron av multitasking i dem. Som en del av en sådan arkitektur reducerades problemet med att bearbeta asynkrona händelser till buffring av meddelanden och sedan seriell intervju av buffertarna och bearbetningen. Samtidigt säkerställdes överensstämmelse med den kritiska livslängden genom hög hastighet av beräkningskomplexet jämfört med hastigheten på externa processer.

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

2. Ett sådant system är bättre skalat, eftersom onödiga tjänster kan uteslutas från systemet utan att det påverkar dess prestanda.

3. Systemfelsoleransen ökar, för Den "beroende" tjänsten kan startas om utan att starta om systemet.

Tyvärr implementeras idag inte så många operativsystem på principen om klient-server. Bland de välkända OSRS som genomför mikrokitekturen kan OS9 och QNX noteras.

Typer av uppgifter

Alla processer innehåller en eller flera uppgifter. Operativsystemet tillåter uppgift att generera nya uppgifter. Uppgifter på deras sätt kan agera på 3 kategorier.

1. Cykliska uppgifter. Karaktäristiskt för hantering och interaktiva processer.

2. Periodiska uppgifter. Karaktäristiskt för många tekniska processer och synkroniseringsuppgifter.

3. Pulsuppgifter. Karaktäristiskt för uppgifterna för signalering och asynkrona tekniska processer.

Fem arbetssystemets viktigaste osynliga uppgifter

1. Ger hårdvara och programvara "koppling"

Operativsystemet är en slags "översättare" mellan hårdvarudelen av datorn och dess programvara. Om du öppnar ett datorväska kan du se olika brädor, chips, kablar och andra komponenter. Detta är den fysiska basen som gör det möjligt att utföra programmet. Men programmet kan inte bara ta och använda datorhårdvaror. Hon gör det genom operativsystemet.

Nyligen har operativsystem blivit alltmer kallade "plattformar". Och det här namnet återspeglar verkligen essensen. OS är plattformen på vilka program som finns. Eller som nu är det vanligt att tala, applikationer till operativsystemet. Det är operativsystemet som gör det möjligt för programvaran att "kommunicera" med hårdvara. Detta gäller även för inmatnings- och utmatningsenheter. Det enklaste exemplet på ingångsenheten är tangentbordet, och utgången är monitorn.

Detta är ett mycket viktigt jobb. Teoretiskt kan hundratals olika ingångs- och utgångsenheter anslutas till en dator. Ta den vanliga musen. Men konceptet "mus" är generellt. Det finns dussintals olika modeller av denna manipulator. Det skulle vara en outhärdlig uppgift att tillhandahålla separat mjukvarustöd för varje typ av mus så att den direkt "kommunicerar" med datorresurserna. Men utgången är drivrutinerna i operativsystemet. För användaren ser det ut som om han bara anslutit någon mus till sin dator, och hon tog omedelbart och tjänat.

2. Orsakar att samma ansökan fungerar på olika "hårdvara"

Det är operativsystemet som tillåter programvara att arbeta på olika datorer, och inte bara på en specifik konfiguration. När programmen har skrivit för en viss datormodell. Programmeringsspråket fungerade faktiskt som operativsystemet för föregångarna till moderna datorer, mikrodatorerna i slutet av sjuttiotalet av det senaste århundradet.

Men i dessa dagar försäkrade OS rollen som en slags "adapter" mellan program och dator "hårdvara". Om du tar några två modeller av datorer, kommer de uppsättningar av komponenter som de samlas in skilja. Detta gäller även känd för varandra "Macintoshi", för att inte nämna hela vägen ett stort utbud som finns på den moderna PC-marknaden.

Driftsmiljön skapar en så kallad abstrakt miljö för programmet. Detta kan representeras som en dialog mellan OS och programmet. Under denna oförståeliga person, berättar programmen "konversationer" "plattformen om hans behov, och operativsystemet måste" tänka "över hur de är rationella för att tillfredsställa. Faktum är att det är nödvändigt att tänka mycket snabbt. Modern gamer är inte redo att vänta en timme, medan hans favoritspel kommer att laddas.

Så, programmet "berättar" operativsystemet exakt vad det är nödvändigt för att kunna fungera korrekt. När allt kommer omkring, med datorresurserna, är ansökan direkt obekant. Och OS distribuerar i sin tur det uppgiftsåtdelade programmet mellan den digitala enhetens resurser. Och hårdvarustypen har inte värdet för programmet. Plattformen tar hand om allt! Operativsystemet kan "prata" om inte med alla, då med mycket många enheter och hårdvarumoduler.

Om det inte var för denna värdefulla färdighet i operativsystemet, skulle programmerare behöva skriva om sina program för varje specifik datorkonfiguration, för varje komponentuppsättning. Och om det inte var för operativsystemet kunde programmet inte fungera alls på datorn, vars egenskaper skiljer sig från programmeraren som tillhandahålls av programmet.

Idag skapar utvecklarna sina egna applikationer för plattformar, och inte för någon känd pre-hårdvarukonfiguration. Enkelt uttryckt, inte för en viss dator, men för ett specifikt operativsystem. Så självklart mycket lättare. Miljoner enheter kan fungera under kontroll av samma operativsystem. Därför har dussintals och till och med hundratusentals applikationer tillgängliga för den moderna användaren av var och en av de populära plattformarna blivit möjliga.

3. Hitta den önskade filansökan

Endast de fysiska resurserna i datorprogrammet skulle inte ha tillräckligt med att korrekt klara av sina uppgifter. All information lagras i filer och dessa filer ska lydas av vissa regler. Dessa regler handlar om hur man ringer och lagrar filer. Vi kallar den gemensamma uppsättningen regler "Filhanteringssystem" eller helt enkelt "Filhanteraren" ("Filhanteraren").

I olika operativsystem implementeras olika tillvägagångssätt för filhantering. Dessutom kan användaren ställa in ytterligare programvara som gör det möjligt att effektivt hantera filer. Det är operativsystemet "minns" de filer som lagras på datorn. När programmet vill hänvisa till en viss fil, kommer OS att visa vägen till den.

Utan filhanteringssystem är digital information på en dator helt enkelt en meningslös uppsättning data. Chaos, där inget är omöjligt att hitta. Dessutom hittades för den kortaste kragen av en sekund.

Operativsystemet är osynligt för oss att vara deras regler, så du behöver inte manuellt komma åt de celler där filen du behöver är fysiskt lagrad. Men viktigast av allt, användaren av det moderna operativsystemet vet inte nödvändigtvis dessa regler för att arbeta på datorn.

4. Effektiv distribution av tillgänglig RAM

Eftersom vi pratar om minne, är det meningsfullt att komma ihåg minnet av operativ (RAM, RAM). Om själva förvaringen, som alltid är "till hands" på processorn.

Det är nödvändigt att betona att förvaltningen av den viktigaste resursen på datorn också utför operativsystemet. RAM är en resurs som är starkt undervärderad av många användare. Hur gör du datorn snabbare? Många tror att en mer kraftfull processor är brådskande. Men i praktiken händer det ofta helt enkelt att öka mängden RAM för att känna en betydande ökning av datorns prestanda.

I RAM placerar datorn den information som kan krävas för att beräkna processorn. Tänk på denna typ av minne helt enkelt som en tillfällig körning av den information som ska vara "närmare processorn".

När vi arbetar med en dator startade vi ibland flera program samtidigt. Operativsystemet allokerar varje uppgift en viss mängd minne. Om processorn behöver sådan information som den inte hittar i RAM, måste han leta efter det på andra ställen. I synnerhet på datorns hårddisk. Det tar längre tid än utvinning av data från RAM. För användaren kommer den här situationen att se ut som temporära "hängande" -applikationer. I sådana fall är det vanligt att säga att "datorn tänker".

En av de uppgifter som operativsystemet är osynligt för användaren är att minimera fördröjningstiden, det vill säga den mest obehagliga tiden under vilken datorn är upptagen med dess angelägenheter och inte svarar på din överklagande till det. Problemet är att vid varje gång operativsystemet

den har en viss mängd RAM, som alltid är begränsad. Denna volym beror på hur många program du samtidigt lanserade. Operativsystemet ska varje ögonblick "veta", hur mycket RAM det kvarstår i lager för att fördela sin process i tid, vilket behöver denna viktiga resurs.

Operativsystemet "uppskattar" kraven i varje arbetsprocess och bestämmer hur klokt uppfyller dem. Helst måste det göras så att användaren inte känner några förseningar alls. Men i praktiken försöker OS helt enkelt minska sådana förseningar till ett minimum, med rationellt fördela de resurser som den faktiskt har.

På jorden finns inga datorer med obegränsad mängd RAM. Därför måste systemet alltid välja vilken process som är för närvarande prioritet, och som är sekundär. Vem allokeralt allokerar minne, och vem kommer att misslyckas förrän tiden. Användaren kanske inte alltid håller med de regler som styrs av operativsystemet när minnesfördelning. Men självständigt fördela lediga operativa minnesprocesser skulle vara mycket mer komplicerade och längre än att anförtrotts denna mjukvaruplattform.

5. Europaparlamentet betonar processorns uppmärksamhet på en viss uppgift

Den centrala processorn (CPU) är den fysiska modulen som löser de uppgifter som användaren poserar framför datorn. En annan sak är att den sällsynta användaren äger det språk som processorn förstår. Vad är det, inte ens alla programmerare är nära bekant med maskinkoden. En person får inte ens tänka på det faktum att något program är en komplex uppsättning av matematiska problem.

Den centrala processorn utövar bara dator, det vill säga, finner lösningen på dessa problem, och du kommer att ge dig redan färdiga resultat, vilket även liknar formlerna från Textbook Algebra. Den vanliga användaren, all denna matematik helt enkelt oavsett. Han vill ha sitt spelkaraktär för att överbelasta hindret för en bråkdel av en sekund, eller vill kontrollera stavningen justerad text. Bakom dessa verkar det vara avlägset från tråkiga siffror, uppgifterna är den mest komplexa matematiken.

Varje arbetsprogram kräver en del av processorns beräkningskraft. Ju fler program du kör samtidigt desto närmare processorns belastning till det maximala. Operativsystemets uppgift att samordna leveransen av information om behandling till processorn så att allt går smidigt och obemärkt för användaren. OS kan byta processorns uppmärksamhet från en uppgift till en annan.

En av de viktigaste rollerna i operativsystemet är resurschefens roll. Om hon klarar sig bra med den här uppgiften, vet vi inte ens hur mycket processorn skjutit upp en uppgift åt sidan och drog sin uppmärksamhet åt en annan.

Omärkbar och oumbärlig assistent

Det mest komplicerade av operativsystemets uppgifter är att du inte uppmärksammar det och fokuserar på dina bilagor intressanta för dig. Och medan allt går bra, tänker användaren inte på plattformen alls. Och endast när programvarufel börjar, är användaren medveten om hur viktigt uppdraget för operativsystemet är.

Dessa "skillnader" mellan operativsystem, som är märkbara för de flesta användare rent kosmetiska. En sällsynt användare förstår programmeringen så att inneslutningen av det grafiska gränssnittet är att se vad som faktiskt skiljer ett operativsystem från en annan. Varken utseendet på skrivbordet eller designen av applikationsikoner har inget att göra med operativsystemets inre essens.

De uppgifter som skrivs ovan är ett eller annat sätt. modernt operativsystemHantera vilken dator som helst. Oavsett hur operativsystemet ser ut och på vilket enhet det är installerat: På en dator, mobilenhet eller spelkonsol.

Funktioner

Positiva funktioner

Bred prevalens av produkten

I den överväldigande majoriteten är OC-fönstren installerad på datorer. Därför, kom till att besöka en vän eller på jobbet, kan du enkelt överföra paret av bilder, textfiler eller klipp från flash-enheten. Lätt att använda och stödja OC-fönster av någon utrustning och eventuella program som bidrar till den globala distributionen är OC.

Trevligt gränssnitt

Modern OC har ett ganska trevligt och förståeligt gränssnitt. Detta bidrar till den snabba uppfattningen av information, användarvänlighet av datorn, snabbt lärande att arbeta med operativsystemet.

Stabilitet OS.

I allmänhet kan stabiliteten i det moderna OC: s arbete kallas acceptabelt. Ordet "acceptabelt" här måste dock åtföljas av en massa av reservationer:

1. En acceptabel stabilitet i operativsystemet blir först efter sin högkvalitativa och kompetenta konfiguration - om det obestämda systemet (men som en onödig gitarr) är det inte värt att prata här alls.

2. Stabiliteten i det moderna operativsystemet är också i stor utsträckning beroende av den version av produkten och tillgängligheten av installerade servicepaket och tillägg - tyvärr, men utan deras närvaro i operativsystemet uppträder ofta frekventa fel.

3. Stabiliteten hos OS beror också på de applikationer som de är installerade på användaren: vad de är stabila i drift och ju mer kompatibel med själva Windows-programvaran, de mindre misslyckandena vi kan observera huvudo.

4. På stabiliteten i det moderna operativsystemet har järnet i sig ett stort inflytande, vilket används i samband med operatören.

5. Också på den stabila driften av moderna OCS, gör Devices-drivrutiner. Dessa mini-program ansvarar för att kartlägga en viss programvara med en viss "hårdvara".

God kompatibilitet med produkter från olika utvecklare (omOC. Fönster)

Modern OC kan korrekt förstå alla typer av filer som uppträdde i sina tidiga reinkarnationer. Om du kommer ihåg samma filtillägg, blir det klart att deras höjd är i själva verket är det mest primitiva och arkaiska operativsystemet, en gång överköpt från en tredjepartsutvecklare och kommuniceras med att tänka Microsoft - MS-DOS. Denna kontinuitet i filformat sträcker sig genom tråden genom alla versioner av Windows, som i sig är helt enkelt underbart.

Skicka ditt bra arbete i kunskapsbasen är enkel. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete är mycket tacksamma för dig.

Federal byrå för utbildning

Institutionen för automatiserade styrsystem

Realtidssystem

Introduktion

1. Operativsystem i realtid

1.1 Typer OSRV

1.2 Struktur av OSRV

1.3 Processer, flöden, uppgifter

1.4 Planering, prioriteringar

1,5 minne

1,6 avbryts

1,7 timmar och timers

2. Operativsystem i realtid

2.1 Standard Posix

2.2 Standard DO-178B

2.3 Standard ARINC-653

2.4 Standard OSEK.

2.5 Säkerhetsstandarder

3. Kortfattade egenskaper hos vanliga operativsystem i realtid

3.2 QNX NeutRino RTOS

3.5 RTX (Realtidsförlängning för Windows NT)

3.6 Intime (förlängning av realtid för Windows NT)

3.8 Microware OS-9

3.11 Nucleus RTOS.

Slutsats

Bibliografisk lista

Introduktion

Begreppen som ligger bakom de mest realtidssystem som finns i våra dagar lämnar sina rötter i slutet av 70-talets början på 80-talets 80-tal.

Realtids operativsystem och inbäddade system arbetar i "trånga" förhållanden när minneskapaciteten och processorns ström är begränsad. De måste säkerställa utförandet av tjänster för användare och omvärlden, med vilken de interagerar, i strikt tillfällig ram.

Realtidssystem utmärks av mycket blygsamma användargränssnittsmöjligheter, eftersom det överförda systemet är en svart låda. En mycket viktig del och huvudfunktionen i realtidsoperativsystemet är att hantera datorresurser så att en viss operation utförs under en absolut identisk tidsperiod varje gång den ska utföras och som inte kan överskridas.

I en komplex maskin kan en snabbare rörelse av detaljerna än vad som är nödvändig, endast av anledningen till att detta tillåts av systemresurserna, kan leda till katastrofala resultat, liksom omöjligheten att flytta denna del på grund av systemets anställning .

Vanligtvis, vid utformningen av realtidssystemet, är sammansättningen av de program som utförs av den (uppgifter) känd i förväg. Många av sina parametrar som måste beaktas vid distribuering av resurser (till exempel minne, prioritet, den genomsnittliga körtiden, de filer som öppnas, enheter som används etc.) är också kända. Därför, för dem, ges uppgifterna på förhand i förväg så att den därefter inte spenderar dyrbar tid för att organisera en deskriptor och söka efter det nödvändiga resurser.

För äkta implementering i realtid behövs multiprogrammering. Multiprogrammering är det viktigaste sättet att förbättra beräkningssystemets prestanda och för att lösa realtidsuppgifter blir prestanda en viktig faktor.

De bästa prestationsegenskaperna för realtidssystem tillhandahålls av enstaka operativsystem i realtid.

1. Operativsystem i realtid

Realtidsoperativsystemet är typen av operativsystem.

Det finns många definitioner av termen. Den vanligaste av dem:

* Det operativa systemet där framgången med något program beror inte bara på sin logiska korrekthet, utan också på den tid det fick detta resultat. Om systemet inte kan uppfylla tillfälliga begränsningar måste den fastställas i sin verksamhet.

* POSIX 1003.1 Standard ger en definition: "Realtid i operativsystem är operativsystemets förmåga att säkerställa den önskade servicenivån vid en viss tidsperiod".

* Operativsystem som reagerar i förutsägbar tid för oförutsägbart utseende av externa händelser.

* Interaktivt system med konstant beredskap. I kategorin hänvisas OSR, baserat på marknadsföringsöverväganden, och om det interaktiva programmet kallas "arbetar i realtid" betyder det bara att förfrågningar från användaren bearbetas med en försening omärkbar för människor.

Operativsystem (OSR) är avsedda att ge ett gränssnitt till resurserna av realtidskritiska resurser. Huvuduppgiften i sådana system är aktualiteten av databehandling.

Som huvudbehovet för OSR läggs kravet på att säkerställa förutsägbarheten eller bestämningen av systemets beteende i de värsta externa förhållandena, vilket skiktigt skiljer sig från prestandakraven och universalens hastighet. En bra delning har förutsägbart beteende med alla scenarier av systemstart (samtidiga avbrott och streaming).

Martin Timmerman (direktör för realtidskonsult och realtidsanvändare "s support International (RTUSI)", som tillhandahåller hårdvara och mjukvarustöd och utvecklar realtidsprojekt) formulerade följande krav på Orvd:

* Operativsystemet måste vara multitasking och tillåta förskjutning;

* Operativsystemet måste ha begreppet prioritet för strömmar.

* Operativsystemet måste stödja förutsägbara synkroniseringsmekanismer.

* Operativsystemet måste säkerställa prioriteringens mekanism.

* Operativsystemets beteende måste vara känt och förutsägbart (avbryta hanteringsförseningar, uppgiftsbrytningsfördröjningar, drivfördröjningar etc.).

Det betyder att i alla scenarier av systemets arbetsbelastning måste den maximala svarstiden bestämmas.

1.1 Typer av osRV

Det är vanligt att skilja systemen för mjuk (mjuk) och hård (hård) realtid.

I hårda realtidssystem leder oförmågan att säkerställa reaktionen på eventuella händelser vid en viss tid till misslyckanden och omöjligheten att utföra uppgiften. I de flesta ryska språklitteraturen kallas sådana system system med deterministisk tid. I praktisk tillämpning måste reaktionstiden vara minimal.

System av mild realtid kallas system som inte faller under definitionen "HARD", för Det finns ingen tydlig definition för dem i litteraturen. Mjuka realtidssystem kanske inte har tid att lösa uppgiften, men det leder inte till att systemet misslyckas som helhet.

I realtidssystem är det nödvändigt att införa en viss politisk term (i engelskspråkig litteratur - deadline) före utgången av vilken uppgiften nödvändigtvis (för mjuka realtidssystem - det är önskvärt) att utföras. Denna gränsperiod används av uppgiftschemalagaren för att tilldela uppgiftsprioriteten när den startas och när man väljer en uppgift för utförande.

1.2 Struktur av OSRV

Under de senaste 25-30 åren har strukturen av operativsystem (OS) utvecklats från monolitisk till en flerskiktsstruktur av operativsystemet och vidare till klient-serverarkitekturen.

Med den monolitiska strukturen i operativsystemet består av en uppsättning moduler, och ändringarna av en modul påverkar andra moduler. Ju fler moduler, desto mer kaos under operationen av ett sådant system. Dessutom är det omöjligt att distribuera OS i ett multiprocessorsystem.

I flerskiktsstrukturen hos förändringen av ett skikt påverkar de intilliggande skikten, dessutom är överklagandet genom skiktet omöjligt.

För realtidssystem bör en direkt överklagande till varje lager av operativsystem tillhandahållas, och ibland direkt till utrustningen.

Huvudideen för klient-server-teknik i OS är att minska basen av OS till ett minimum (schemaläggare och synkroniserings primitiv). All annan funktionalitet görs till en annan nivå och implementeras genom strömmar eller uppgifter. Kombinationen av sådana serveruppgifter är ansvarig för systemsamtal. Ansökningar är kunder som begär tjänster via systemsamtal.

Client-Server-teknik gör att du kan skapa skalbar OS och förenklar fördelningen i ett multiprocessorsystem. Vid drift av systemet orsakar inte utbytet av en modul inte effekten av "snowball", dessutom, innebär modulfelet inte alltid misslyckandet av systemet som helhet. Möjligheten till dynamisk belastning och försändelse av moduler har dykt upp. Det största problemet i den här modellen är att skydda minnet, eftersom serverprocesser måste skyddas. Varje gång serviceförfrågan måste systemet byta från applikationskontexten till serverns sammanhang. Med stöd av minnesskydd ökar omkopplingstiden från en process till en annan.

Som regel är de flesta av de moderna OSRS byggda på grundval av Microker (kärna eller kärna), som tillhandahåller planering och avsändning av uppgifter och implementerar dem också. Trots minimering i kärnan i Abstraktionerna av operativsystemet bör microkernel fortfarande ha en uppfattning om processens abstraktion. All annan konceptuell abstraktion av operativsystem deponeras utöver kärnan, kallas på begäran och exekveras som applikationer.

1.3 Processer, flöden, uppgifter

Begreppet multitasking (pseudoparallism) är viktigt för ett realtidssystem med en processor, som ska kunna hantera många externa händelser som förekommer nästan samtidigt.

Begreppet process som kom från Unix-världen är dåligt implementerat i ett multi-tasking system, eftersom processen har ett tungt sammanhang. Begreppet ström uppstår (tråd), vilket förstås som en delprocess, eller en lättbehandling (lätt process). Trådar finns i ett sammanhang av processen, så att byte mellan trådar uppträder mycket snabbt, och säkerhetsproblem beaktas inte. Trådar är lätta, eftersom deras registreringskontext är mindre, d.v.s. Deras kontrollblock är mycket mer kompakta. Övergående kostnader som orsakas av att spara och återställa kontrollblock av avbrutna flöden minskas. Volymen av kontrollblock beror på minneskonfigurationen. Om strömmarna utförs i olika adressutrymmen måste systemet stödja minnesbilden för varje uppsättning strömmar.

Så, i realtidssystem, uppstår processen på uppgifter eller strömmar. I vilket fall som helst anses varje process som en ansökan. Det bör finnas för många interaktioner mellan dessa applikationer, och i de flesta fall har de olika natur - hård realtid, mjuk realtid, inte realtid.

1.4 Planering, prioriteringar

Huvudproblemet i OSR är uppgiftsplanering (schemaläggning), vilket skulle säkerställa systemets förutsägbara beteende under alla omständigheter. I samband med problemen med planering i OSRV studeras två tillvägagångssätt - statiska planeringsalgoritmer (RMS-takt monotoniska schemaläggning) och dynamiska planeringsalgoritmer (EDF - tidigast deadline först).

RMS används för att formella bevis för systemets förutsägbarhet. Att genomföra denna teori, planering baserad på prioriteringar, avbryta underhållet (Preemptive prioriterade schema). I RMS-teorin är prioritet tilldelad i förväg till varje process. Processer måste uppfylla följande villkor:

* Processen måste slutföras under sin tid

* Processer beror inte på varandra;

* Varje process kräver samma processor tid vid varje intervall;

* Icke-periodiska processer har ingen svår tid

* Processavbrott sker för begränsad tid.

Processer utförs i enlighet med prioriteringar. När du planerar RMS, ges preferens till uppgifter med de mest korta perioderna av utförande.

I EUF är prioritet dynamiskt tilldelad, och den största prioriteten är inställd på den process som har den minsta exekveringstiden. Med stora lastningssystem har EDF fördelar över RMS.

Alla realtidssystem kräver en planeringspolicy som förvaltas av deadline (deadline-driven schemaläggning). Men detta tillvägagångssätt är under utveckling.

OSR används vanligtvis för att planera med prioriteringar som avbryter underhållet, som bygger på RMS. Prioritetsavbrottet i tjänsten (princip) är en integrerad del av OSR, eftersom I realtidssystemet måste det finnas en garanti för att en händelse med hög prioritet behandlas före den tidigare prioriterade händelsen. Allt detta leder till det faktum att OSRV inte bara behöver i planeringsmekanismen baserat på prioriteringar, avbrottstjänsten, men också i motsvarande avbrottshanteringsmekanism. Dessutom måste OSR kunna förbjuda avbrott när det är nödvändigt att utföra en kritisk kod som inte kan avbrytas. Varaktigheten av behandling av avbrott måste minimeras.

OSRV måste ha ett utvecklat system av prioriteringar. För det första krävs det eftersom systemet i sig kan betraktas som en uppsättning serverprogram som är uppdelade i strömmar, och flera höga nivåer av prioriteringar bör markeras av systemiska processer och strömmar. För det andra, i komplexa tillämpningar, är alla realtidsströmmar nödvändiga för att sätta på olika prioriterade nivåer, och inga realtidsströmmar placeras en nivå (lägre än alla realtidsströmmar). I det här fallet kan inga realtidsströmmar bearbetas i cykliskt planeringsläge (RRS-Round-Robin-schemaläggning), i vilken varje process tillhandahålls av en processortidskvantum och när kvantändarna är bevaras, och Det sätts i slutet av kön. I många OSRS används RRS för att planera uppgifter på en nivå. Prioritetsnivå 0 används vanligtvis för tomgång.

Vid planering på grundval av prioriteringar måste två obligatoriska problem lösas:

* Se till att processen genomförs med högsta prioritet,

* Tillåt inte inversion av prioriteringar när uppgifter med höga prioriteringar förväntar sig resurser som tagits av uppgifter med lägre prioriteringar.

För att bekämpa inversion av prioriteringar i OSRV används ofta arvsmekanismen ofta, men det är nödvändigt att överge RMS-baserad planering, eftersom prioriteringarna blir dynamiska.

1,5 minne

Som nämnts ovan beror förseningen med att byta strömkontexten direkt på minneskonfigurationen, d.v.s. Från minnesskyddsmodellen. Fyra minnesskyddsmodeller är vanligast i OSRV:

* Modell utan skydd - System och användaradresser är inte skyddade från varandra, två minnesegment används: för kod och för data, medan ingen minneshantering krävs, krävs ingen MMU (minneshanteringsenhet en särskild maskinvaruanordning för stöd virtuell minneshantering);

* Skyddsmodellsystem / användarsystemadressutrymme skyddat från användaradressutrymmet, system och användarprocesser utförs i ett gemensamt virtuellt adressutrymme, det tar MMU. Skyddet tillhandahålls av skyddsplåstret. System och användarsidor skiljer sig åt. Anpassade applikationer är inte skyddade mot varandra. Processorn är i ett handledsläge om det aktuella segmentet har en nivå av 0, 1 eller 2. Om segmentnivån är 3 är processorn i användarläge. I denna modell behövs fyra segment - två segment på nivå 0 (för kod och data) och två segment på nivå 3. Sidskyddsmekanismen lägger inte över huvudet, eftersom Skydd kontrolleras samtidigt med adressomvandlingen som MMU utför; Samtidigt behöver operativsystemet inte minneshantering.

* Skyddsmodell Användare / Användare - För att modellera system / användare, skyddas skydd mellan användarprocesser, MMU krävs. Som i föregående modell används mekanismen för sidskydd. Alla sidor är markerade som privilegierade, med undantag för sidorna i den aktuella processen som är markerade som anpassade. Således kan löpströmmen inte kontakta gränserna för sitt adressutrymme. OS ansvarar för att uppdatera Privilege-flaggan för en viss sida i sidtabellen när du byter processen. Som i föregående modell används fyra segment.

* Virtuell minnesskyddsmodell - varje process utförs i sitt eget virtuella minne, mmu krävs. Varje process har sina egna segment och därmed dess egen deskriptortabell. OS ansvarar för att stödja beskrivningsborden. Det adresserbara utrymmet kan överstiga storleken på det fysiska minnet om sidoorganisationen av minnet används i samband med podachka. Men i realtidssystem är podachka vanligtvis inte tillämpad på grund av dess oförutsägbarhet. För att lösa detta problem är det tillgängliga minnet uppdelat i ett fast antal logiska adressutrymmen av samma storlek. Antalet samtidigt löpande processer i systemet blir begränsat.

Det grundläggande minneskravet i realtidssystemet är att åtkomsttiden till den ska vara begränsad (eller med andra ord förutsägbara). En direkt följd blir ett förbud mot användningen av sidor för realtidsprocesser på begäran (personsökning från disken). Därför måste system som tillhandahåller en virtuell minnesmekanism kunna blockera processen i RAM, inte tillåta personsökning. Så är podachka oacceptabelt i OSRV eftersom det är oförutsägbart.

Om sidans organisation av minne stöds, ska motsvarande visning av sidor till fysiska adresser vara en del av processens sammanhang. Annars uppträder oförutsägbarhet igen, oacceptabelt för OSRV.

För icke-realtidsprocessprocesser är det möjligt att använda en dynamisk minnesdistributionsmekanism, men OSR måste stödja timeoutbehandlingen till minnesförfrågan, d.v.s. Begränsning av förutsägbar väntetid.

I det vanliga OS, vid användning av minnessegmenteringsmekanismen används tätningsförfarandet för att bekämpa fragmentering efter montering av sopor. Emellertid är detta tillvägagångssätt inte tillämpligt i realtidsmiljö, för Under tätningen kan de flyttade uppgifterna inte utföras, vilket leder till systemets oförutsägbarhet. Detta är det främsta problemet med tillämpligheten av ett objektorienterat tillvägagångssätt för realtidssystem. Så länge komprimeringsproblemet är löst, kommer C ++ och Java inte det bästa valet för hårda realtidssystem.

I hårda realtidssystem appliceras vanligtvis en statisk minnesfördelning. I mjuka realtidssystem är en dynamisk minnesfördelning möjlig, utan virtuellt minne och utan tätning.

1.6 Avbrytande

När du beskriver avbrottshanteringen, är två procedurer vanligtvis särskiljande, nämligen:

* Avbryt bearbetningsprogram (ISR-avbrottservice rutin) - Lågnivåprogram i en kärna med begränsade systemutmaningar,

* Avbryt bearbetning (IST-avbrottservice) - ett applikationsnivåflöde som styr avbrottet, med tillgång till alla systemutmaningar.

Vanligtvis implementeras ISR av tillverkaren av utrustningen, och drivrutinerna utför avbrottskontroll med hjälp av IST. Avbryt hanteringsströmmar fungerar som alla andra strömmar och använder samma prioriterade system. Det betyder att systemdesignern kan ge IST lägre prioritet än prioriteringen av applikationsströmmen.

1,7 timmar och timers

I OSRV används olika tidstjänster. Operativsystemet spårar den aktuella tiden, startar vid en viss tid och strömmar och upphäver dem till vissa intervaller. I OSRVs tid används i realtidsklockan. Brukar använda hög precision hårdvaruklocka. Timers skapas baserat på tidsintervall baserat på realtidsklocka.

För varje process och ström bestäms timmarna av processorns tid. På grundval av dessa timmar skapas timers att mätningstiden överskrider processen eller strömmen, så att du kan dynamisera programfel eller fel för att beräkna den maximala möjliga exekveringstiden.

I mycket tillförlitliga, kritiska system är det viktigt att identifiera situationer där uppgiften överstiger den maximala möjliga tiden för utförandet, eftersom Samtidigt kan systemets funktion gå bortom den tillåtna svarstiden. Exekveringstiden tillåter dig att identifiera förekomsten av tidsberäkning och aktivera motsvarande felbehandlingsåtgärder.

De flesta OSRV arbetar med relativ tid. Någonting händer "till" och "efter" någon annan händelse. I ett system krävs helt hanterade händelser, en klockmekanism (ticker), eftersom Det finns ingen tidskvantisering (tidsskivning). Men om du behöver tillfälliga etiketter för vissa händelser eller ett systemsamtal behövs för att "vänta på en sekund", behöver du en klockgenerator och / eller timer.

Synkronisering i OSR utförs med en blockeringsmekanism (eller väntar) före en viss händelse. Absolut tid används inte.

Genomförandet av andra konceptuella abstraktioner i trb liknar deras implementeringar i det traditionella OS.

2. Operativsystem i realtid

2.1 Standard Posix

Stora skillnader i OSR-specifikationerna och ett stort antal befintliga mikrokontroller frambordade ett problem med standardisering inom realtidssystem.

OSR: s mest tidiga och utbredda standard är POSIX-standarden (IEEE-bärbart operativsystemgränssnitt för datormiljö, IEEE 1003.1). Den ursprungliga versionen av POSIX-standarden uppträdde 1990 och var avsedd för UNIX-system, vilka de första versionerna uppträdde på 70-talet av förra seklet. POSIX-specifikationer Definiera standardmekanismen för interaktion mellan applikationsprogrammet och operativsystemet och inkluderar för närvarande en uppsättning av mer än 30 standarder. Sju av dem (1003,1a, 1003,1b, 1003,1c, 1003,1d, 1003,1j, 1003,21, 1003,2, 1003,1j, 1003,21, 1003,2, 1003,1J, 1003,21, 1003,2h) är viktigast (1003,1 A, 1003,2h), men det finns bara tre första stöd i kommersiellt OS.

Trots de tydligt föråldrade positionerna i POSIX-standarden och den större efterfrågan på standardiseringsuppdateringar för OSR, observeras inte märkbar framsteg i denna riktning.

POSIX-standarden skapades som ett vanligt operativsystemgränssnitt. Denna standard gör det möjligt att skapa bärbara applikationer. Därefter har denna standard utökats av särdrag i realtidsläge.

POSIX-specifikationen Ställ in standardinspelningsmekanismen och OS. Det bör noteras att POSIX-standarden är nära förknippad med UNIX, ändå försöker utvecklarna av många OSR för att klara överensstämmelse med denna standard.

Överensstämmelse med POSIX-standarden för OS och hårdvaruplattformen måste certifieras av körningen på dem testuppsättningar. Men om OS inte är unix-liknande, för att motstå detta krav blir en svår uppgift. Testuppsättningar finns endast för POSIX 1003.1A. Eftersom POSIX-strukturen är en uppsättning valfria funktioner kan OS-leverantörer endast implementera en del av standardgränssnittet och samtidigt prata om Systemets posix-komplimang.

Trots det faktum att POSIX-standarden har vuxit ut ur UNIX "A, påverkar den den grundläggande abstraktionen av operativsystem, och expansionen av realtid är tillämplig på alla OSRV.

Hittills anses POSIX-standarden som en familj av relaterade standarder: IEEE STD 1003.N (där n är ett nummer).

2.2 Standard DO-178B

DO-178B-standarden skapades av Radio Technical Commission på Aeronautics (RTCA, Radio Technical Commission for Aeronautics) för att utveckla programvara (programvara) för ombord luftfartssystem.

Den första versionen antogs 1982, den andra (DO-178A) - 1985, den nuvarande DO-178B - 1992, är antagandet av den nya versionen att förbereda, göra-178c. Standarden ger fem nivåer av svårighetsgraden av misslyckandet, och för var och en av dem en uppsättning programvarukrav, som bör garantera hela systemets prestanda som helhet, i händelse av misslyckanden av denna svårighetsgrad

Denna standard definierar följande nivåer av certifiering:

* A (katastrofalt),

* I (farligt),

* C (essential),

* D (obetydlig)

* E (inte påverkar).

Så länge som alla strikta krav i denna standard inte är uppfyllda, kommer beräkningssystem som påverkar säkerheten aldrig att stiga in i luften.

2.3 Standard ARINC-653

ARINC-653 Standard (Avionics Application Software Standard Interface) utvecklades av ARINC 1997. Denna standard definierar det universella APEX-programgränssnittet (Application / Executive) mellan luftfartsdator och tillämpad programvara.

Gränssnittskraven mellan applikationsprogrammet och operativsystemtjänsterna bestäms på ett sådant sätt att applikationen kan styra sändningen, anslutningen och tillståndet för de interna bearbetade elementen. År 2003 antogs en ny upplaga av denna standard. ARINC-653 Som en av de grundläggande kraven för OSR i luftfart kommer den isolerade arkitekturen (partitionering) av virtuella maskiner.

2.4 Standard OSEK.

OSEK / VDX-standarden är en kombination av standarder som ursprungligen utvecklades i två separata konsortier, som därefter spilldes. OSEK tar sitt namn från den tyska akronymen av konsortiet, som omfattade ledande tyska biltillverkare - BMW, Bosch, Daimler Benz (nu Daimler Chrysler), Opel, Siemens och Volkswagen, samt universitetet i Karlsruhe (Tyskland). VDX-projektet (Fordonsfördelad Executive) som utvecklats av de franska företagens gemensamma insatser. PSA och RENAULT. OSEK och VDX-lag fusionerades 1994.

Inledningsvis var OSEK / VDX-projektet avsett att utveckla en öppen arkitekturstandard OS och API-standard för system som används inom bilindustrin. Den utvecklade standarden visade emellertid vara mer abstrakt och är inte begränsad till endast användning inom bilindustrin.

OSEK / VDX-standarden består av tre delar - standard för operativsystemet (OS), kommunikationsstandard (COM) och standard för en nätverkshanterare (NM). Utöver dessa standarder bestäms ett visst implementeringsspråk (olja). Den första delen av OSEK-standarden är standarden för OS, så ofta är OSEK-standarden felaktigt uppfattad som en standard OSR. Även om OS är en stor del av denna standard består dess makt i integrationen av all sin komponent.

2.5 Säkerhetsstandarder

I samband med standarderna för OSR är det värt att notera den välkända standarden för kriterierna för bedömning av datorsystemets lämplighet (betrodda datasystemets utvärderingskriterier - TCSEC). Denna standard utvecklades av den amerikanska försvarsdepartementet och är också känd som den orange boken (orange bok - på grund av omslaget på locket).

I ett antal andra länder har liknande kriterier utvecklats, på grundval av vilka den internationella standarden "Allmänna kriterier för informationsteknologi bedömning" skapades (nedan kallad allmänhetens kriterier) (gemensamma kriterier för IT-säkerhetsutvärdering, ISO / IEC 15408 ).

Den "orange boken" listar sju nivåer av skydd:

* A1 - Verifierad utveckling. Denna nivå kräver skydd av hemlighet och annan kritisk information till säkerhetshanteringsverktyg garanterade formella verifieringsmetoder.

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

* B2 - Strukturerat skydd. En hackerpenetration kan inte tillåtas i systemet med denna nivå.

* B1 - mandatåtkomstkontroll. Skyddet av denna nivå kan kunna övervinna den experimentella hackaren, men inte för vanliga användare.

* C2 - Diskretionär åtkomstkontroll. C2-nivån säkerställer skyddet av inträdesprocedurer, låter dig övervaka händelser relaterade till säkerhet, liksom isolera resurser.

* C1 - Selektivt skydd. Den här nivån ger användarna möjlighet att skydda personuppgifter eller projektinformation genom att ställa in åtkomstkontroller.

* D - Minimal skydd. Denna lägre skyddsnivå är kvar för system som har testats, men kunde inte uppfylla kraven i en högre klass.

3. Kortfattade specifikationer för de vanligaste operativsystemen i realtid

3.1 VXWorks.

Operativsystem i realtidsfamiljen VXWorks Corporation "Windriver Systems" är utformade för att utveckla programvara (programvara) av inbäddade datorer som arbetar i hårda realtidssystem.

VXWorks operativsystem har en klient-serverarkitektur och inbyggd i enlighet med Microke-tekniken, d.v.s. På den lägsta kontinuerliga nivån på kärnan (vindmikrokernel) bearbetas endast uppgiftsplanering och deras interaktion / synkronisering. Resten av funktionskärnans funktionalitet är minneshantering, ingång / utgång, etc. - finns på en högre nivå och implementeras genom processer. Detta säkerställer kärnans hastighet och bestämning, såväl som systemets skalbarhet.

VXWorks kan ordnas både för små inbäddade system med hårda begränsningar för minnet och för komplexa system med avancerad funktionalitet.

Även om VXWorks-systemet är konfigurerbart, dvs. Separata moduler kan laddas ned statiskt eller dynamiskt, det kan inte sägas att det använder ett tillvägagångssätt baserat på komponenter. Alla moduler är konstruerade över baskärnan och är utformade 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 Operativsystem Operativsystem (RTO) Corporation "QNX Software Systems" är ett mikronukleärt operativsystem som ger multitasking prioritetsläge.

QNX Neutrino RTOS har en klient-serverarkitektur. I QNX-neutrino-miljön utförs varje förare, applikation, protokoll och filsystem utanför kärnan i ett skyddat adressutrymme. Vid fel på någon komponent kan den automatiskt startas om utan att påverka andra komponenter eller kärna. Även om QNX-systemet är konfigurerbart, d.v.s. Separata moduler kan laddas ned statiskt eller dynamiskt, det kan inte sägas att det använder ett tillvägagångssätt baserat på komponenter. Alla moduler är beroende av baskärnan och är utformade 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, processplanerare (Process Manager) och utökade användarnivå. Som ett riktigt mikroder operativsystem implementerar QNX Neutrino RTOS endast de mest grundläggande tjänsterna i kärnan, såsom överföring av meddelanden, signaler, timers, flödesplanering, synkroniseringsobjekt. Alla andra operativsystem, drivrutiner och applikationer utförs som separata processer som interagerar genom synkronmeddelanden.

QNX Neutrino RTOS har låga avbryta behandlingstider, snabb kontextkoppling. Inversion av prioriteringar övervinnas med ett distribuerat prioriterat arv. Förenklad modellering av realtidsaktivitet utförs genom synkron överföring av meddelanden. Investerade avbrott och fasta övre avbrottsbehandlingstidsgränsen säkerställer att högprioriterade avbrott behandlas snabbt med förutsägbar tid.

3,3 rtems.

RTEMS (realtids verkställande för multiprocessorsystem) är ett ideellt realtidsoperativsystem för djupt inbäddade system.

Systemutvecklarbolaget "OAR" (On-Line Applications Research Corporation, USA). Systemet skapades av Order av US Department of Defense för användning i Missile Systems Management Systems. Systemet är utvecklat för multiprocessorsystem baserat på öppen källkod i motviktiga liknande system med sluten kod. Systemet är utformat för MS-Windows och Unix-plattformen (GNU / Linux, FreeBSD, Solaris, MacOS X).

RTEMS-kärnan ger den grundläggande funktionaliteten hos realtidssystem. Dessa möjligheter inkluderar

* Multitasking bearbetning;

* Arbeta i homogena och heterogena system;

* Planering som förvaltas av händelser baserade på prioriteringar.

* Planering med monotont hastighet;

* Interaktion av uppgifter och synkronisering

* Prioriterad arv

* Hantering av svaravbrott

* Fördelning av dynamiskt minne;

* Konfigurera systemet för behöriga användare;

* Portability till många målplattformar.

OSR-bindningen till utrustningen görs med ett speciellt bibliotek med BSP (styrelsestödpaket) och specialiserade delprogram för olika arkitekturer.

RTEMS stöder inte den dynamiska applikationen och modulerna, så det använda området är inbäddade system som inte antar en frekvent mjukvaruändring.

RTEMS DRI ger tillräckligt svagt stöd för filsystem, vilket begränsar sitt område med möjlig tillämpning inom området för centraliserade insamlings- och lagringssystem med standard på hög nivå.

3.4 Chorusos.

Korusos operativsystem är ett skalbart inbäddat OS, som används i stor utsträckning inom telekommunikationsindustrin. För närvarande utvecklas och distribueras detta varumärke av Sun Microsystems Corporation.

För layout och utplacering av Chorusos OS på specifika telekommunikationsplattformar, föreslår Sun Microsystems att använda den soldaterade verkstadsutvecklingsmiljön. Sun Microsystems Corporation representerar Chorusos OS som en inbäddad basis för Sun "Service Network Administreras av Tjänster (Sun Service-Driven Network). I kombination med ett brett utbud av tjänster, komplett integrering av programvara och utrustning, bekväm administration och support av Java-teknik, som ägnas åt behoven av telekommunikation, gör Chorusos OS det möjligt att effektivt använda nya funktioner och applikationer, stödja tillförlitligheten och Funktionalitet av moderna nätverk.

Chorusos OS stöder ett brett utbud av telekommunikationsprotokoll, ärftliga applikationer, realtids- och Java-teknikprogram på en maskinvaruplattform.

Chorusos OS-modeller Tre typer av applikationer:

* POSIX-processer utgör de flesta Chorusos-applikationer, dessa applikationer har tillgång till POSIX API, flera posix-liknande utökade API och ett litet antal begränsade Microkes systemsamtal.

* Chorusos aktörer - Dessa applikationer utförs via microkernel och är begränsade till Microkes API, aktörerna inkluderar drivrutiner, evenemangs delsystem och protokollstackar;

* Inherited Chorusos-applikationer stöds för kompatibilitet med applikationer som är utformade för tidigare versioner av Chorusos.

Chorusos OS-arkitektur är en flerskiktad komponentbaserad (compoly-base). Mikroideriskt innehåller en minsta uppsättning komponenter som krävs för operationen av operativsystemet. Storleken på veliddelen av kärnan är 10kb.

Begreppet "skådespelare" i Chorusos definieras som en hämtningsenhet för applikationen. Det fungerar också som en inkapslingsenhet för att jämföra alla systemresurser som används av applikationen och strömmarna som utförs inuti skådespelaren. Exempel på sådana resurser är strömmar, minnesområden och slutpunkter för interaktion.

Chorusos 5.0 bygger på Solaris-operativmiljön och stöder följande målplattformar:

* UltraSPARC II (CP1500 och CP20x0);

* Intel X86, Pentium;

* Motorola PowerPC 750 och 74x0 processorfamilj (MPC7XX);

* Motorola PowerQuicc I (MPC8XX) och PowerQuicc II (MPC8260) (mikrokontroller).

3.5 RTX (Realtidsförlängning för Windows NT)

Windows NT konstruerades och används huvudsakligen som ett universellt OS. Marknaden för realtidssystem är dock tydligt spårad att använda Windows NT och dess expansion i specialiserade system. Det finns flera anledningar till det:

* Windows NT designades enligt modern OS Construction Technologies,

* Ansökningsgränssnitt (API) för Win32 har blivit en de facto-standard för programmerare,

* Det grafiska användargränssnittet (GUI) har blivit så populärt att andra operativsystem försöker ge ett liknande gränssnitt,

* Tillgängligt ett stort antal enheter drivrutiner,

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

Windows NT själv är inte lämplig för användning i realtidssystem, eftersom det är för få prioriterade nivåer, det finns ingen mekanism för prioriteringar. För att minimera avbrottsbehandling (ISR) i Windows NT är begreppet ett uppskjutet procedursamtal inmatat (DPC-uppskjuten procedur), vars prioritet är högre än användarens och systemets prioritering, medan alla DPC har samma prioritet . Detta leder till det faktum att alla DPC är i FIFO-köen, och DPC med ett avbrott på hög nivå kommer att kunna exekvera först efter att alla andra DPCs vetter mot det kommer att slutföras. Sådana situationer leder till oförutsägbara svarstider, vilket är oförenligt med kraven för OSR. Minneshantering i Windows NT är baserat på en virtuell minnesmekanism. Detta drar minnesskyddet, översättningen av adresser och en podmaskin som är oacceptabelt för OSR.

Realtidsförlängning RTX (realtidsförlängning) för Windows NT (utvecklad av Ventursom Corporation) kan du skapa höghmed en deterministisk reaktionstid till externa händelser.

RTX integreras djupt i Windows NT-kärnan och för att säkerställa att de nödvändiga funktionerna använder Windows NT-tjänsten och Win32 API. Realtidskärnan (kärnan) integrerad i NT (kärnan) kärna. Varje RTX-process utförs som NT-kärndrivrutinen, och processerna är inte skyddade mot varandra. Sådan implementering leder till en snabb byte av sammanhang, men osäker när det gäller sekretess.

3.6 Intime (förlängning av realtid för Windows NT)

Intimesystemet är en realtids Windows-förlängning, som utvecklades av Radisys Corporation, och stöds för närvarande av Tenasys Corporation.

Intime kombinerar hårda realtids triviala funktioner med standard Windows OS, inklusive Windows XP, Windows XP Embedded, Windows 2000, Windows NT och Windows NT inbäddad, utan att behöva extra utrustning. Intime är speciellt utformad för X86-processorns arkitektur.

Intime, i motsats till RTX, är dåligt ansluten till NT. Intime Architecture är baserad på hårdvaruhandtaget (hårdvaruuppgift), som tillhandahålls av Intel-processorn. Det visar sig att två kärnor utförs på en hårdvara. Eftersom de delar en utrustning krävs några modifieringar av NT Hal. Med detta tillvägagångssätt kan du skydda och separera körtid och minnesområde från Windows. Inom intime har varje applikationsprocess ett eget adressutrymme. Dessutom utförs kärnorna och applikationerna på olika prioriterade nivåer, vilket gör det möjligt för dem att skydda dem från varandra.

Intime visar förutsägbart beteende, men dess komplexa arkitektur tillåter inte att uppnå ett bra prestationsystem. På grund av segmenteringsrestriktioner är intim inte lämplig för alla realtidssystem.

3,7 lynxos.

Lynxos RTOS operativsystem (Lynuxworks, Inc.) är ett hårt realtidssystem som är avsett för specialiserad och telekommunikationsutrustning. Detta operativsystem är helt deterministisk och har posix-, UNIX- och Linux-kompatibilitet. Lynxos OS-applikationer är också komplexa säkerhetssystem.

Den senaste versionen av detta märke av Lynxos-178 2.0 kännetecknas av en tillverkare som ett kommersiellt operativsystem som ger en hög grad av tillförlitlighet och effektivitet som är nödvändig för inbäddade applikationer med speciella säkerhetskrav. I Lynxos-178 2.0 implementeras APEX-gränssnittsstöd (Ansöknings / Executive - Application / Managing Program Interface) ARINC-653 Specifikationer. Det innebär att detta operativsystem uppfyller de strängaste kraven för säkerhet och tillförlitlighet hos elektroniska system för militär och civil luftfart. Lynxos-178 2.0-systemet uppfyller helt nivån en bestämmelser och DO-178B-specifikationen.

OSRV Lynxos-178 2.0 uppfyller kraven i POSIX och ARINC-653-standarder, liksom DO-178B, vilket innebär en garantisolering av applikationskoden för inbäddade system, upprepad användning av de skapade programmen, liksom överensstämmelse med De strängaste standarderna för operativsystem med ökade säkerhetskrav. Med Lynxos-178 2.0 kan du tillämpa eventuella tidigare certifierade program och utveckling.

3.8 Microware OS-9

Operativsystemet i realtid OS-9 Corporation "Microware System" är ett multi-tasking, multiplayer operativsystem för inbäddade applikationer som arbetar i realtid. Detta system är utformat för att fungera i system som mobila telekommunikationsenheter, inbäddade internetåtkomstterminaler, interaktiva digitala tv-konsoler.

OS-9 arbetar på processorer som Motorola 68k, Arm / Strongarm, Intel IXP1200 Nätverksprocessor, MIPS, PowerPC, Hitachi Superh, X86 eller Intel Pentium, Intel IXC1100 Xscale.

OS-9-kärnan är skalbar, helt förskjuten, stöder upp till 65535 processer, ger 65535 prioriterade nivåer och ger upp till 255 användare. OS-9-kärnan innehåller mer än 90 systemsamtal som gör det möjligt att styra det dynamiska avsändningsläget, minnesdistribution, interprocessorkommunikation etc. - Vid kontrollen av det ekonomiska strömförbrukningsläget som är inbyggt i kärnan.

Microware Corporation är en av de första som licensierade Java för inbäddade applikationer och är ledande med förslag på olika medel och applikationer inom OS-9 för olika klasser av enheter.

Som en integrerad korsmiljö för att utveckla applikationer för OS-9 har Microware utvecklat en Hawk-miljö som fungerar på MS Windows NT-plattformen.

3.9 OSE RTOS.

Realtids operativsystem OSE RTOS, som utvecklats i Enea Corporation, har en kärna med prioriterad planering. Denna kärna är starkt optimerad för att ge hög prestanda och kompakt kompakt för användning i inbäddade system. OSE har arkitektur som hanteras av meddelanden, med enkla systemutmaningar. Överföring av meddelanden till OSE fungerar som en konceptuell gateway i distribuerade multiprocessorinbäddade system. Uppgifter skickar meddelanden till varandra direkt via operativsystemet utan att stödja köer, brevlådor eller andra mellanliggande mekanismer. OSE RTOS stöder podaching, duplicering, dynamisk koduppdatering och många kommunikationsprotokoll.

OSE RTOS-arkitekturen är baserad på en flerskiktad modell.

Exekveringsenheten i OSE RTOS är processen. Processer kan grupperas i ett block som kan ha sin egen minnespool. I OSE RTOS-kärnan hör adressutrymmet till ett segment som kan innehålla ett eller flera block. Visar block till segment och visning av pooler till regionerna gör det möjligt att uppnå fullt minnesskydd och programisolering. Block och pooler kan placeras i ett eller flera segment.

I OSE RTOS är separation av processer förstådda som dynamiska och statiska: statiska processer skapas av kärnan när systemet börjar och existerar under hela systemets existens, dynamiska processer skapas och förstörs under utförandet.

3.10 Windows CE

Windows CE är modulär med en liten kärna och valfria moduler som exekveras som oberoende processer. Planering i Windows CE är baserad på prioriteringar. Skyddet av kärnan och processerna från varandra stöds. Dessutom är det möjligt att arbeta när det inte finns något skydd mellan processerna och kärnan. Det bör noteras att avbrott behandlas som flöden och har prioriterade nivåer. Windows CE stöder också trådar (fiber), som är trådar som kärnan inte kontrollerar. Varje tråd utförs i samband med flödet, vilket skapade det; De kan användas för att skapa en schemaläggare inuti strömmen. Sådana trådar används i exotiska eller ärftliga applikationer, men de är olämpliga i realtidssystem.

Windows CE har en begränsning av fysiskt minne - 512 MB. Microsoft gick in i denna begränsning så att Windows CE kan utföras på ett stort utbud av inbäddade processorer utan kompatibilitetsproblem, eftersom några av dessa processorer kan hantera det fysiska minnet i 512 MB. Windows CE implementerar den virtuella minnessidan. Sidstorleken beror på plattformen, men om möjligt används storleken på 4KB. Det finns ett tillfälle att förbjuda tallorganisationen, vilket är viktigt för realtidssystem. I det här läget laddas modulen före körning helt i minnet. Då påverkar sidsökningen (personsökning) inte utförandet av programmet.

Till skillnad från andra fönster stöder Windows CE generaliserade vänteläge för olika typer av objekt (mutexer, semaforer, händelser, processer och flöden). Fördelen med sådana funktioner är att det är möjligt att förvänta sig många föremål på en gång tills en av dem tjänar en signal. Kritiska sektioner kan endast användas inom en enda process. Beräkningsmapor och mutexer kan användas både inom en enda process och mellan processer. I Windows CE används prioriteringen för att undvika problemet med prioriterad inversion.

3.11 Nucleus RTO.

Kärnans operativsystem som utvecklats av accelererad teknik är konstruerad för inbäddade applikationer.

Kärnan är ett tvärsystem, d.v.s. Programvaruprodukten är skapad på en enda programvara och hårdvaruplattform och utförs på en annan.

OSRV-kärnan kommer med öppen källa.

Kärnan av kärnan, kärnan plus, ger multitasking-bearbetning, tolereras och skalbar. Kärnan implementeras som ett bibliotek med funktioner i C.

Nucleus Plus ger möjligheter som uppgiftsinteraktionshantering (brevlådor, köer, transportörer, semaforer, händelser, signaler), såväl som minneshantering, timers, avbrott. Uppgiftsplanering utförs på grundval av prioriteringar, liksom på FIFO-algoritmen.

Vid utförande av ett systemsamtal kan uppgiftsexekveringen avbrytas för en obestämd tid, till ett givet intervall eller inte avbrytas. Alla objekt i systemet kan skapas och raderas dynamiskt.

Slutsats

I många år användes applikationer baserade på operativsystemet i realtid i inbäddade specialsystem, och nyligen började de tillämpa överallt, från ombordkontrollsystem för flygplan, hushållsapparater.

Den viktigaste egenskapen hos realtidssystem är förutsägbarheten för systemets tidsreaktioner på externa händelser. Endast på grundval av den här egenskapen kan vi prata om lönsamheten och giltigheten av de lösningar som fastställs i ett specifikt operativsystem av realtid.

Realtidssystem måste svara på externa ingångsparametrar och skapa nya resultatresultat för begränsad tid. Svarstiden måste vara begränsad. En mycket lång svarstid kan leda till ett realtidsfel.

Det är ingen tvekan om att de flesta av de traditionella realtidssystemen har utvecklats med en syn på den enda centrala processorn som är installerad på den enda brädet. Numera behövs multiprocessorsystem alltmer.

Det är uppenbart att operativsystem med en monolitisk arkitektur, på grund av deras fokus på specifika processorplattformar och naturen av interaktion med kärnan, knappast kan användas som relativt universella realtidssystem för hög tillgänglighetssystem.

Moderna operativsystem i realtid är baserade på nya arkitektoniska tillvägagångssätt, kompletterade med hjälp av att utveckla applikationssystem som gör det möjligt för dem att skapa dem i förkortade perioder med de bästa egenskaperna, dessutom, har den mikroferbaserade ett antal fördelar jämfört med den monolitiska arkitekturen , och i kombination med objektet ett orienterat tillvägagångssätt, tillåta systemet att bli hårdvaruoberoende och säkerställa ett snabbt svar på externa händelser.

Och det är i ljuset av en tillfällig förutsägbarhet för OSR bör försiktigt utformas för att stödja realtidsapplikationer.

Bibliografisk lista

1. Burdonov I.B., Kosachev A.S., Ponomarenko v.n. Realtids operativsystem. Preprint: Institutet för systemprogrammering RAS. Irkutsk, 2006.

2. OLIFER V.G., OLIFER N.A. Nätverksoperativsystem: lärobok för universitet. 2: a ed. - SPB: Peter, 2008. - 669 C.: IL.

3. www.ru.wikipedia.org.

4. www.intuit.ru.

Liknande dokument

De viktigaste egenskaperna hos realtidssystem, typer av arkitekturer. Processprioriteringssystem (uppgifter) och sändningsalgoritmer. Begreppet feltolerans, orsaker till misslyckanden. Fel tolerans i befintliga realtidssystem (QNX NeutRino).

examination, tillagt 03/03/2013

Klassificering av realtidssystem. Kärnor och realtidsoperativsystem. Uppgifter, processer, strömmar. Fördelar och nackdelar med strömmar. Egenskaper, planering, uppgiftssynkronisering. Relaterade uppgifter. Synkronisering med externa händelser.

abstrakt, tillagt 12/28/2007

Egenskaper, grunderna för applicering, arkitektur av styva och operativsystem i realtid. Seriell programmering av realtidsuppgifter. Struktur och språk av parallell programmering, multiprogrammering och multitasking.

coursework, tillagt 12/17/2015

Paketbehandling av operativsystem, tidseparation, realtid. Funktioner av resurshanteringsalgoritmer. Stöd multiplayer-läge. Obesting och avlindning av multitasking. Operativsystem och globala nätverk.

abstrakt, tillagt 11.12.2011

Översikt över kraven i problemområdet. Funktioner i ledningsuppgifter. Executive realtidssystem. Programmering på mikroprocessornivån. Modeller och metoder för ämnesområdet. Förverkligande av prototypen av realtidssystemet.

kurs, tillagt 15.02.2005

Planeringsuppgifter i realtidssystemet. De viktigaste typerna av planering i förhållande till realtidsuppgifter. Välj en acceptabel planeringsalgoritm vid utformning av RTS. Statisk förutsägelse med hjälp av tabeller.

examination, tillagt 05/28/2014

Övervägande av de grundläggande principerna och metoderna för att utforma realtidssystem. Beskrivning av de konstruktiva och funktionella egenskaperna hos kontrollobjektet, konstruktion av uppgiftsdiagram. Välja maskinvaruarkitektur, flödesprocessmodeller, gränssnitt.

kursarbete, tillagt 01/19/2015

Övergripande egenskaper hos programkörningstidfixering: Utför realtidsprocesser, profilering. Programmerbar intervalltimer som ett mycket komplext system. Analys av de viktigaste funktionerna som returnerar standardfönstren.

kursarbete, tillagt 05/18/2014

Operativsystemets koncept och funktion. Huvudfunktionen i realtidsoperativsystem. Arbeta med kalkylblad. Filtreringsposter i MS Excel-tabellen. Installera en anpassad autofilter i ett roterande uttalande av varuförflyttning.

examination, tillagt 11/21/2013

Essens och princip för operativsystemet, reglerna och fördelarna med användningen. Möjligheterna för olika operativsystem, deras styrkor och svagheter. Jämförande egenskaper hos UNIX och Windows NT-system, deras potentiella och uppgifter utförda.