Realtime besturingssysteem

Een besturingssysteem dat zelfs voor een realtime taak de vereiste uitvoeringstijd kan bieden in de ergste gevallen, genaamd harde real-time besturingssysteem.

Een besturingssysteem dat de vereiste uitvoeringstijd voor een realtime taak kan bieden gemiddeld, genaamd zacht real-time besturingssysteem.

Harde real-time systemen staan ​​geen vertragingen in de systeemreactie toe, omdat dit kan leiden tot:

• verlies van relevantie van de resultaten
• grote financiële verliezen
• ongelukken en rampen

Als kritische verwerking niet of niet snel genoeg plaatsvindt, breekt het harde real-time systeem de bewerking af en blokkeert deze zodat de betrouwbaarheid en beschikbaarheid van de rest van het systeem niet wordt aangetast. Voorbeelden van harde real-time systemen kunnen zijn: systemen aan boord controle (in een vliegtuig, ruimtevaartuig, schip, enz.), noodbeschermingssystemen, recorders voor noodgebeurtenissen.

Zachte real-time systemen worden gekenmerkt door de mogelijkheid van vertraagde respons, wat kan leiden tot hogere resultaatkosten en verminderde prestaties van het systeem als geheel. Een voorbeeld is de exploitatie van een computernetwerk. Als het systeem geen tijd had om de volgende te verwerken geaccepteerd pakket, zal dit ervoor zorgen dat de verzendende kant stopt en opnieuw verzendt (afhankelijk van het protocol). Er gaan geen gegevens verloren, maar de netwerkprestaties worden verminderd.

Het belangrijkste verschil tussen harde en zachte real-time systemen kan als volgt worden gekarakteriseerd: een hard real-time systeem zal nooit te laat reageren op een gebeurtenis, terwijl een zacht real-time systeem niet te laat zou moeten reageren op een gebeurtenis.

Laten we met een real-time besturingssysteem een ​​systeem aanduiden dat gebruikt kan worden om harde real-time systemen te bouwen. Deze definitie drukt de houding uit ten opzichte van een RTOS als een object bevattend noodzakelijke hulpmiddelen, maar betekent ook dat deze tools nog steeds correct moeten worden gebruikt.

De meeste software is gericht op "zachte" realtime. Dergelijke systemen worden gekenmerkt door:

• gegarandeerde responstijd op externe gebeurtenissen (onderbrekingen van apparatuur);
• een rigide subsysteem voor procesplanning (taken met een hoge prioriteit mogen niet worden vervangen door taken met een lage prioriteit, op enkele uitzonderingen na);
• verhoogde vereisten voor responstijd op externe gebeurtenissen of reactiviteit (vertraging bij het aanroepen van een interrupthandler is niet meer dan tientallen microseconden, vertraging bij het schakelen tussen taken is niet meer dan honderden microseconden)

Een klassiek voorbeeld van een taak waarbij een RTOS vereist is, is de besturing van een robot die een onderdeel oppakt van een transportband. Het onderdeel beweegt en de robot heeft slechts een klein tijdsbestek waarin hij het kan oppakken. Als hij te laat is, zal het onderdeel niet meer op het gewenste gedeelte van de transportband staan ​​en zal het werk dus niet worden voltooid, ondanks het feit dat de robot in bedrijf is. juiste plaats. Als hij zich eerder voorbereidt, heeft het onderdeel geen tijd om aan te komen en blokkeert hij zijn pad.

Onderscheidende kenmerken van RTOS

Vergelijkingstabel tussen RTOS en conventionele besturingssystemen:

RTOS-architecturen

Bij hun ontwikkeling werden RTOS's gebouwd op basis van de volgende architecturen.

• . Een besturingssysteem wordt gedefinieerd als een reeks modules die met elkaar communiceren binnen de systeemkernel en applicatiesoftware leveren invoerinterfaces voor oproepen naar apparatuur. Het belangrijkste nadeel van dit principe van het bouwen van een besturingssysteem is de slechte voorspelbaarheid van het gedrag ervan, veroorzaakt door de complexe interactie van modules met elkaar.
• . Applicatiesoftware heeft niet alleen toegang tot hardware via de systeemkernel en zijn services, maar ook rechtstreeks. Vergeleken met een monolithische architectuur biedt een dergelijke architectuur een aanzienlijk grotere mate van voorspelbaarheid van systeemreacties, en maakt het ook snelle toegang toepassing toepassingen naar de apparatuur. Het grootste nadeel van dergelijke systemen is het gebrek aan multitasking.
• Client-server-architectuur. Het belangrijkste principe is om OS-services in de vorm van servers naar het gebruikersniveau te brengen en de microkernelfuncties van een berichtenbeheerder tussen clientcomputers uit te voeren. gebruikersprogramma's en servers - systeem diensten. De voordelen van deze architectuur:

1. Grotere betrouwbaarheid, omdat elke service in feite een onafhankelijke applicatie is en gemakkelijker fouten kan opsporen en opsporen;
2. Verbeterde schaalbaarheid, omdat onnodige services van het systeem kunnen worden uitgesloten zonder de prestaties in gevaar te brengen;
3. Verhoogde fouttolerantie, omdat een bevroren service opnieuw kan worden gestart zonder het systeem opnieuw op te starten.

Kernel-functies

De RTOS-kernel zorgt voor het functioneren van een tussenliggend abstract OS-niveau, dat de details voor de applicatiesoftware verbergt technisch apparaat processor (meerdere processors) en bijbehorende hardware.

Basisdiensten

Deze abstracte laag biedt vijf hoofdcategorieën van diensten voor applicatiesoftware.

• Taakbeheer. Het meest hoofdgroep diensten. Hiermee kunnen applicatieontwikkelaars softwareproducten ontwerpen als sets van afzonderlijke programmafragmenten, die elk betrekking kunnen hebben op hun eigen onderwerpgebied, een afzonderlijke functie kunnen vervullen en waaraan een eigen tijdsdeel voor werk kan worden toegewezen. Elk dergelijk fragment wordt genoemd taak. Diensten in deze groep hebben de mogelijkheid om taken te starten en daaraan prioriteiten toe te wijzen. De belangrijkste service hier is taakplanner. Het bewaakt de uitvoering van huidige taken, lanceert nieuwe taken binnen de juiste periode en bewaakt hun werkingsmodus.
• Dynamische geheugentoewijzing. Veel (maar niet alle) RTOS-kernels ondersteunen deze groep services. Hiermee kunnen taken RAM-gebieden lenen voor tijdelijk gebruik in actieve applicaties. Vaak verplaatsen deze gebieden zich vervolgens van taak naar taak, en daardoor ook snelle overdracht veel gegevens tussen hen. Sommige zeer kleine RTOS-kernels die bedoeld zijn voor gebruik in hardwareomgevingen met strikte geheugenlimieten ondersteunen geen dynamische geheugentoewijzingsservices.
• Timerbeheer. Omdat embedded systemen strenge eisen stellen aan het tijdsbestek voor taakuitvoering, omvat de RTOS-kern een groep services die timerbeheer bieden om de tijdslimiet te bewaken waarin een taak moet worden uitgevoerd. Deze services meten en stellen verschillende tijdsintervallen in (vanaf 1 μs en meer), genereren interrupts wanneer tijdsintervallen verstrijken en creëren eenmalige en cyclische alarmen.
• Communicatie en synchronisatie tussen taken. Met diensten in deze groep kunnen taken informatie uitwisselen en de veiligheid ervan garanderen. Ze zorgen er ook voor dat softwarefragmenten hun werk op elkaar kunnen afstemmen om de efficiëntie te vergroten. Als deze services worden uitgesloten van de RTOS-kern, zullen taken vervormde informatie gaan uitwisselen en het werk van aangrenzende taken kunnen verstoren.
• Bewaking van I/O-apparaten. Services in deze groep bieden één enkele software-interface die communiceert met de vele apparaatstuurprogramma's die kenmerkend zijn voor de meeste ingebedde systemen.

Naast kernelservices bieden veel RTOS-lijnen lijnen extra componenten om concepten op hoog niveau te organiseren, zoals het bestandssysteem, netwerken, netwerkbeheer, databasebeheer, grafische gebruikersinterface, enz. Hoewel veel van deze componenten veel groter en complexer zijn dan de RTOS-kern zelf, zijn ze niettemin afhankelijk van de diensten ervan. Elk van deze componenten is alleen in het ingebedde systeem opgenomen als de diensten ervan nodig zijn om de ingebedde applicatie uit te voeren en alleen om het geheugengebruik tot een minimum te beperken.

Verschillen met besturingssystemen voor algemene doeleinden

Veel besturingssystemen voor algemene doeleinden ondersteunen ook de bovengenoemde services. Het belangrijkste verschil tussen de RTOS-kernservices is echter deterministisch, gebaseerd op strikte tijdscontrole, de aard van hun werk. IN in dit geval Met determinisme bedoelen we dat de uitvoering van één besturingssysteemservice een tijdsinterval van een bekende duur vereist. Theoretisch kan deze tijd worden berekend met behulp van wiskundige formules, die strikt algebraïsch moeten zijn en geen tijdsparameters van willekeurige aard mogen bevatten. Elke willekeurige variabele die de uitvoeringstijd van een taak in een RTOS bepaalt, kan een ongewenste vertraging in de applicatie veroorzaken, waarna de volgende taak zijn tijdsdeel niet zal halen, wat een fout zal veroorzaken.

In die zin zijn besturingssystemen voor algemene doeleinden niet deterministisch. Hun services kunnen af ​​en toe vertragingen in hun werking veroorzaken, wat kan leiden tot een vertraging in de reactie van de applicatie op gebruikersacties op een onbekend tijdstip. Bij het ontwerpen van conventionele besturingssystemen richten ontwikkelaars hun aandacht niet op het wiskundige apparaat voor het berekenen van de uitvoeringstijd specifieke taak en dienst. Dit is niet kritisch voor dit type systeem.

Taken plannen

Planner taak

De meeste RTOS voeren taakplanning uit met behulp van het volgende schema. Elke taak in de applicatie krijgt een bepaalde prioriteit toegewezen. Hoe hoger de prioriteit, hoe hoger de reactiviteit van de taak zou moeten zijn. Door de aanpak te implementeren wordt een hoge reactiviteit bereikt preventieve planning met prioriteit(preventieve planning), waarvan de essentie is dat de planner de uitvoering van een taak op een willekeurig tijdstip mag stoppen als wordt vastgesteld dat onmiddellijk een andere taak moet worden gestart.

Het beschreven schema werkt volgens de volgende regel: als twee taken tegelijkertijd klaar zijn om te worden uitgevoerd, maar de eerste een hoge prioriteit heeft en de tweede een lage prioriteit, dan zal de planner de voorkeur geven aan de eerste. De tweede taak wordt pas gestart nadat de eerste zijn werk heeft voltooid.

Het is mogelijk dat er al een taak met lage prioriteit wordt uitgevoerd en dat de planner een bericht ontvangt dat een andere taak met hogere prioriteit klaar is om te worden uitgevoerd. De reden hiervoor kan een externe invloed zijn (onderbreking van de apparatuur), zoals een verandering in de status van de schakelaar van een apparaat dat wordt bestuurd door een RTOS. In een dergelijke situatie zal de taakplanner zich als volgt gedragen volgens de prioritaire preventieve planningsbenadering. Een taak met een lage prioriteit mag het huidige assemblagecommando voltooien (maar niet het commando dat wordt beschreven in de broncode van het programma in een taal op hoog niveau), waarna de uitvoering van de taak stopt. Vervolgens wordt een taak met hoge prioriteit gelanceerd. Nadat deze is verwerkt, start de planner de onderbroken eerste taak met de montage-instructie die volgt op de laatst uitgevoerde taak.

Elke keer dat de taakplanner een signaal ontvangt over het optreden van een externe gebeurtenis (trigger), waarvan de oorzaak hardware of software kan zijn, handelt deze volgens het volgende algoritme.

1. Bepaalt of de momenteel actieve taak moet blijven worden uitgevoerd.
2. Stelt in welke taak als volgende moet worden uitgevoerd.
3. Slaat de context van een gestopte taak op (zodat deze later het werk kan hervatten vanaf het punt waarop deze was gestopt)
4. Stelt de context in voor de volgende taak.
5. Voert deze taak uit.

Deze vijf stappen van het algoritme worden ook wel genoemd taken wisselen.

Uitvoering van een taak

In conventionele RTOS's kan een taak zich in 3 mogelijke toestanden bevinden:

1. De taak wordt voltooid;
2. De taak is klaar om te worden uitgevoerd;
3. De taak is geblokkeerd.

Meestal wordt het grootste deel van de taken geblokkeerd. Er kan slechts één taak per CPU worden uitgevoerd huidige moment tijd. Bij primitieve RTOS's is de lijst met taken die klaar zijn voor uitvoering meestal erg kort; deze kan uit niet meer dan twee of drie items bestaan.

De belangrijkste functie van de RTOS-beheerder is het maken van een dergelijke taakplanner.

Als de lijst met taken die gereed zijn voor uitvoering niet meer dan twee of drie bevat, wordt ervan uitgegaan dat alle taken zich in de optimale volgorde bevinden. Als er zich situaties voordoen waarbij het aantal taken in de lijst de toegestane limiet overschrijdt, worden de taken gesorteerd op prioriteit.

Algoritmen voor planning

Momenteel worden twee benaderingen het meest intensief ontwikkeld om het probleem van effectieve planning in RTOS op te lossen.

• Statische planningsalgoritmen(RMS, monotone tariefplanning). Gebruik preventieve prioriteitsplanning. Aan elke taak wordt een prioriteit toegewezen voordat deze wordt uitgevoerd. De voorkeur gaat uit naar taken met de kortste doorlooptijd.
• Dynamische planningsalgoritmen(EDF, Vroegste deadline eerste planning). Prioriteit wordt dynamisch toegewezen aan taken, waarbij de voorkeur wordt gegeven aan taken met de vroegste start (voltooiing) uitvoeringstijd.

Interactie tussen taken en het delen van bronnen

• Tijdelijk uitschakelen van interrupts
• Binaire semaforen
• Signalen verzenden

RTOS'en gebruiken de eerste methode meestal niet omdat de gebruikersapplicatie de processor niet zoveel kan besturen als hij wil. Bij veel embedded systemen en RTOS's kunnen applicaties echter in de kernelmodus draaien om toegang te krijgen tot systeemaanroepen en controle te geven over de uitvoeringsomgeving zonder tussenkomst van het besturingssysteem.

Op systemen met één processor is de beste oplossing om de applicatie in de kernelmodus uit te voeren, die is ingeschakeld om interrupts te blokkeren. Terwijl de interrupt is uitgeschakeld, heeft de applicatie uitsluitend gebruik van de bronnen van het proces en kan geen enkele andere taak of interrupt worden uitgevoerd. Op deze manier worden alle kritieke hulpbronnen beschermd. Nadat de applicatie kritieke activiteiten heeft voltooid, moet deze eventuele interrupts deblokkeren. Het tijdelijk uitschakelen van een interrupt is alleen toegestaan ​​als de langste uitvoeringsperiode van een kritieke sectie korter is dan de toegestane interruptresponstijd. Normaal gesproken wordt deze beveiligingsmethode alleen gebruikt als de lengte van de kritieke code niet langer is dan meerdere regels en geen lussen bevat. Deze methode is ideaal voor registerbeveiliging.

Wanneer de kritische sectielengte groter is dan het maximum of lussen bevat, moet de programmeur mechanismen gebruiken die identiek zijn aan of het gedrag van systemen voor algemene doeleinden simuleren, zoals semaforen en signalering.

Geheugentoewijzing

De volgende problemen met geheugentoewijzing krijgen meer aandacht in RTOS's dan in besturingssystemen voor algemene doeleinden.

Ten eerste de geheugentoewijzingssnelheden. Het standaardschema voor geheugentoewijzing omvat het scannen van een lijst van onbepaalde lengte om een ​​vrij geheugengebied te vinden gegeven maat, en dit is onaanvaardbaar, aangezien in een RTOS de geheugentoewijzing binnen een vaste tijd moet plaatsvinden.

Ten tweede kan het geheugen gefragmenteerd raken als vrije delen ervan al verdeeld zijn lopende processen. Dit kan ertoe leiden dat het programma stopt omdat het geen nieuwe geheugenlocatie kan gebruiken. Een algoritme voor geheugentoewijzing dat geleidelijk de geheugenfragmentatie vergroot, kan goed werken op desktopsystemen als deze minstens één keer per maand opnieuw worden opgestart, maar is onaanvaardbaar voor ingebedde systemen die jarenlang draaien zonder opnieuw op te starten.

Een eenvoudig algoritme met een vaste lengte werkt heel goed in eenvoudige ingebedde systemen.

Dit algoritme werkt ook goed op desktopsystemen, vooral wanneer, terwijl de ene kern een stukje geheugen verwerkt, het volgende stukje geheugen door een andere kern wordt verwerkt. Desktop-geoptimaliseerde RTOS's zoals Unison Besturingssysteem of DSPnano RTOS bieden deze mogelijkheid.

Real-time besturingssystemen (lijst)

Opgemerkt moet worden dat de lijst geen systemen omvat die in de USSR zijn ontwikkeld voor militaire en ruimtevaartdoeleinden - om voor de hand liggende redenen die verband houden met het geheimhoudingsregime. Hun bestaan ​​en gebruik gedurende tientallen jaren is echter een onbetwistbaar feit waarmee rekening moet worden gehouden.

Opmerkingen

Literatuur

• Zyl S. QNX real-time besturingssysteem: van theorie naar praktijk. - 2e druk. - Sint-Petersburg. : BHV-Petersburg, 2004. - 192 p. - ISBN 5-94157-486-Х
• Zyl S. QNX-momenten. Basisprincipes van toepassingen. - Sint-Petersburg. : BHV-Petersburg, 2004. - 256 p. - ISBN 5-94157-430-4
• Kurten R. Inleiding tot QNX/Neutrino 2. - Sint-Petersburg. : Petropolis, 2001. - 512 p. - ISBN 5-94656-025-9
• Auslander DM, Ridgley JR, Ringenberg JD Besturingsprogramma's voor mechanische systemen: Objectgeoriënteerd ontwerp van real-time systemen. - M.: Binom. Kennislaboratorium, 2004. - 416 p. - ISBN 5-94774-097-4

Koppelingen

• Overzicht van realtime besturingssystemen

De basis van elk hardware- en softwarecomplex, inclusief die welke in realtime werken, is het besturingssysteem (OS). Een besturingssysteem is een reeks programma's die zorgen voor het beheer van de bronnen van een hardware-softwarecomplex (computersysteem) en processen die deze bronnen gebruiken bij berekeningen. Een hulpbron is in deze context elke logische of fysieke (en in zijn totaliteit) component van een computersysteem of hardware- en softwarecomplex en de mogelijkheden die het biedt.

De belangrijkste bronnen zijn de processor (processortijd), RAM en randapparatuur.

Resourcemanagement komt neer op het uitvoeren van de volgende taken: het vereenvoudigen van de toegang tot resources, het verdelen ervan over processen.

Met de oplossing voor het eerste probleem kunt u de hardwarefuncties van het computersysteem “verbergen” en deze daardoor beschikbaar maken voor de gebruiker of programmeur virtuele machine met aanzienlijk eenvoudiger controle. Het besturingssysteem ondersteunt dus de volgende interfaces: gebruiker (opdrachttaal voor het besturen van de werking van het systeem en een set van diensten); software (een reeks services die de programmeur bevrijdt van routinematige codeerbewerkingen). De functie voor het distribueren van bronnen is een van de belangrijkste taken die door het besturingssysteem wordt opgelost, maar is niet inherent aan alle besturingssystemen, maar alleen aan de systemen die de besturingssystemen garanderen. gelijktijdige uitvoering van meerdere programma's (processen).

Een proces is een reeks acties die worden voorgeschreven door een programma of het logisch complete onderdeel ervan, evenals gegevens die bij berekeningen worden gebruikt. Het proces is minimale eenheid werk waarvoor middelen worden toegewezen.

Momenteel is er een grote verscheidenheid aan besturingssystemen, die zijn geclassificeerd volgens de volgende criteria:

o het aantal gebruikers dat tegelijkertijd door het systeem wordt bediend;

o het aantal processen dat gelijktijdig onder OS-controle kan draaien;

o type gebruikerstoegang tot het systeem;

o type hardware- en softwarecomplex.

In overeenstemming met het eerste teken worden besturingssystemen voor één en meerdere gebruikers onderscheiden.

De tweede functie verdeelt het besturingssysteem in single- en multi-tasking.

In overeenstemming met het derde kenmerk zijn besturingssystemen onderverdeeld in:

o systemen met batchverwerking. In dit geval wordt een pakket gevormd uit de uit te voeren programma's en ter verwerking aan het systeem aangeboden. In dit geval hebben gebruikers geen directe interactie met het besturingssysteem;

o timesharingsystemen die gelijktijdige interactieve toegang bieden tot computersysteem meerdere gebruikers via terminals. In dit geval worden systeembronnen “op zijn beurt” aan elke gebruiker toegewezen, in overeenstemming met een of andere servicediscipline;

o real-time systemen, die een gegarandeerde responstijd op externe gebeurtenissen moeten bieden (zie hieronder voor meer details).

De vierde functie verdeelt het besturingssysteem in single- en multiprocessor, netwerk en gedistribueerd. Voor besturingssystemen voor meerdere gebruikers en meerdere taken is onderhoudsdiscipline een belangrijke indicator. In overeenstemming hiermee wordt onderscheid gemaakt tussen preventieve en coördinerende vormen van multitasking. In een preventieve organisatie is alleen het besturingssysteem verantwoordelijk voor het toewijzen van processortijd aan taken (voor elke taak wordt bijvoorbeeld beurtelings een processor toegewezen, en voor een strikt vaste tijdsperiode, maar prioritair onderhoud is ook mogelijk). In het geval van een matchingorganisatie bepaalt elke taak, nadat deze de controle heeft gekregen, zelf wanneer de processor aan een andere taak moet worden "gegeven". Over het algemeen is coördinatie effectiever en betrouwbaarder dan preventie, maar de bepalende factor bij de implementatie van programma's is het feit dat dit programma mag de CPU-tijd niet monopoliseren.

Realtimesysteem (RTS)- dit is een systeem waarvan de juiste werking niet alleen afhangt van de logische juistheid van de berekeningen, maar ook van het tijdstip waarop deze berekeningen worden gemaakt.

Voor gebeurtenissen die in een dergelijk systeem plaatsvinden, zijn het tijdstip waarop deze gebeurtenissen plaatsvinden en hun logische juistheid belangrijk. Een systeem werkt in realtime als de prestatie ervan toereikend is voor de snelheid van fysieke processen bij het bewaken of besturen van objecten (dat wil zeggen processen die rechtstreeks verband houden met de functies die worden uitgevoerd door een specifiek realtime systeem). Het besturingssysteem moet gegevens verzamelen, deze verwerken volgens gespecificeerde algoritmen en een controleactie uitvoeren binnen een periode die de succesvolle voltooiing van de toegewezen taken garandeert.

1.1 Wat is een realtime systeem

IN de laatste tijd We worden steeds vaker geconfronteerd met taken waarbij het beheer van complexe processen of apparatuur met behulp van een computer vereist is. Bovendien vinden alle gebeurtenissen in deze processen plaats wanneer ze plaatsvinden. Een computer kan slechts een eindig aantal bewerkingen in een eindige tijd uitvoeren, dus rijst de vraag: heeft de computer tijd om de vereiste snelheid de situatie berekenen en specifieke controleacties uitvaardigen die specifiek in dat geval adequaat zouden zijn bepaald moment tijd. Naar mijn mening ontstonden dit soort problemen door het gebruik van very hoge snelheden V moderne productie. Het is duidelijk dat signalen in de natuur zich met een eindige snelheid voortplanten, de werkingssnelheid is ook eindig, daarom is het fundamenteel onmogelijk om onmiddellijke acties (veroorzaakt door een bepaalde gebeurtenis) van een computer te verwachten. Hoe modern een computer ook is (lees krachtig in prestaties, d.w.z. hoge snelheid bij het verwerken van opdrachten en bewerkingen), hij heeft fysiek minstens een fractie van een seconde nodig om een ​​kleine taak uit te voeren. eenvoudige groep commando's, en soms is deze tijd te veel. De reactietijd van het systeem op een bepaalde gebeurtenis is dus strikt groter dan nul. Echte taken zorgen voor enige vertraging in acties, en als het systeem een ​​reactietijd heeft die korter is dan deze acceptabele vertraging, dan is het eerlijk om het een realtime systeem te noemen. Sinds in de natuur verschillende processen Omdat ze met verschillende snelheden te werk gaan, kan een en hetzelfde systeem binnen het gegeven raamwerk voor het ene proces passen en niet voor het andere. Het is dus logisch om te praten over een realtime systeem in relatie tot een specifieke taak. Om bijvoorbeeld de afhankelijkheid van de gemiddelde luchttemperatuur voor een dag op een dag van de week in kaart te brengen, zal vrijwel elke computer met vrijwel alle software als een realtime systeem werken. Als we de landing van een vliegtuig controleren, waarbij milliseconden een belangrijke rol spelen, zou het passender zijn om zorgvuldig hardware en software te kiezen.

Naast de weloverwogen taak om op een bepaalde gebeurtenis te reageren, zijn er nog andere klassen van realtime taken. Een van de vaak voorkomende taken is de taak van het voortdurend monitoren of controleren van een dynamisch proces, d.w.z. wanneer je continu signalen moet uitwisselen met de buitenwereld. Een computer is een discreet systeem, dus het is noodzakelijk om bepaalde acties binnen een bepaalde eindige tijdsperiode uit te voeren, ervan uitgaande dat de buitenwereld gedurende deze korte tijdsperioden onveranderd blijft. Als ons systeem in staat is informatie te verwerken en besturingssignalen op de vereiste frequentie te produceren, kan het een real-time systeem worden genoemd. Het is niet moeilijk te begrijpen dat deze taak gemakkelijk kan worden teruggebracht tot de vorige, waarbij het begin van het volgende tijdsinterval als gebeurtenis wordt gebruikt. De reactietijd moet korter zijn dan de bemonsteringstijd van het proces. De eerder beschreven taak is dus het belangrijkst wanneer waar we het over hebben over realtime systemen. Opgemerkt moet worden dat een onbevredigende werking van het systeem in termen van latentie bij sommige taken tot fatale gevolgen kan leiden, terwijl bij andere taken zich geen abnormale of ongewenste situaties zullen voordoen. Bijvoorbeeld: als het temperatuurmeetsysteem uit het hierboven beschreven voorbeeld per ongeluk onaanvaardbaar veel tijd te laat arriveert, betekent dit dat we eenvoudigweg de selectie van temperatuurmeetpunten hebben gewijzigd en dat we nog steeds het juiste resultaat krijgen, maar als de automatische Wanneer de nadering van een passagiersvliegtuig per ongeluk een seconde wordt uitgesteld door een plotselinge windvlaag, bereikt het vliegtuig mogelijk de landingsbaan niet en zullen tientallen mensen om het leven komen. Systemen moeten dus worden onderverdeeld in harde en zachte real-time systemen.

Real Time OS (RTOS) is een besturingssysteem dat een bepaalde capaciteit voor een bepaalde periode garandeert. Het zou bijvoorbeeld ontworpen kunnen zijn om aan te geven dat een object toegankelijk is geworden voor een robot op een lopende band. Dergelijke schelpen worden geclassificeerd in "hard" en "zacht".

Harde real-time besturingssystemen gaan ervan uit dat de berekening niet kan worden uitgevoerd als het object niet binnen de aangegeven periode beschikbaar is (een dergelijke bewerking zal mislukken).

In een zacht real-time besturingssysteem zal de assemblagelijn onder deze omstandigheden blijven functioneren, maar de productie kan lager zijn omdat objecten niet op het geplande tijdstip beschikbaar zijn, waardoor de robot tijdelijk niet productief is.

Voordat we voorbeelden geven van realtime besturingssystemen, is het noodzakelijk om de kenmerken van hun gebruik te begrijpen. Sommige van dergelijke besturingssystemen zijn gemaakt voor speciale toepassingen, andere voor meer algemene toepassingen. Bovendien worden sommige shells voor algemene doeleinden soms ook gebruikt voor realtime werk. Het bekende Windows 2000 of IBM Microsoft/390 kan dit type uitvoeren. Dat wil zeggen: zelfs als het besturingssysteem niet aan bepaalde vereisten voldoet, kan het kenmerken hebben waardoor het in realtime kan worden beschouwd als een oplossing voor een specifiek toepassingsprobleem.

Voorbeelden van besturingssystemen en hun kenmerken

Over het algemeen heeft realtime de volgende karakteristieke kenmerken:

• Multitasking.
• Technologische stromen die prioriteit kunnen krijgen.
• Voldoende aantal interruptniveaus.

Realtime besturingssystemen worden vaak gebruikt als onderdeel van kleine ingebedde shells die in microdevice-formaat worden gebruikt. Sommige kernels kunnen dus in realtime worden beschouwd als besturingssystemen met één taak (bijvoorbeeld: kernels die zijn opgenomen in IOS, Android, enz.). Ze hebben echter andere apparaatcomponenten nodig, zoals stuurprogramma's, om de beoogde taken uit te voeren. Dat is de reden waarom een ​​volwaardige in de regel meer is dan alleen een kern.

Een typisch voorbeeld van een RTOS-toepassing is een HDTV-ontvanger en -display. Hij moet lezen digitaal signaal, decodeer het en geef het weer als binnenkomende gegevens. Elke vertraging zal merkbaar zijn als gepixelde video en/of vervormde audio.

Tegelijkertijd betekent het verzoek om ‘voorbeelden te geven van besturingssystemen van dit type’ dat de meest voorkomende worden vermeld. bekende namen. Wat zit er in deze groep?

VxWorks van WindRiver

VxWorks is een real-time besturingssysteem ontwikkeld als eigen software door WindRiver. VxWorks werd voor het eerst uitgebracht in 1987 en was oorspronkelijk bedoeld voor gebruik in embedded systemen die realtime en deterministische prestaties vereisten. Voorbeelden van dit soort besturingssystemen worden dus gebruikt op het gebied van beveiliging en veiligheid, verschillende industrieën (vooral lucht- en ruimtevaart en defensie), productie medische apparaten, industriële uitrusting, robotica, energie, transportmanagement, netwerk infrastructuur, verbetering van de auto- en consumentenelektronica.

VxWorks ondersteunt Intel (x86, inclusief de nieuwe IntelQuarkSoC en x86-64), MIPS, PowerPC, SH-4 en ARM-architecturen. Deze RTOS wordt meegeleverd krachtige kern, tussenliggend software, betaalde ondersteuning extra pakketten en hardwaretechnologieën externe fabrikanten. In de nieuwste release - VxWorks 7 - is het systeem opnieuw ontworpen met het oog op modulariteit en upgrademogelijkheden, zodat de OS-kernel gescheiden wordt gehouden van middleware, applicaties en andere pakketten.

QNX-neutrino

Klassieke voorbeelden van besturingssystemen van dit type zijn ook enkele Unix-achtige shells. Dit is QNX Neutrino, oorspronkelijk ontwikkeld begin jaren tachtig door het Canadese bedrijf Quantum Software Systems. Uiteindelijk werd de ontwikkeling in 2010 overgenomen door BlackBerry. QNX is een van de eerste commercieel succesvolle microkernelbesturingssystemen die wordt gebruikt in verschillende apparaten, inclusief auto's en mobiele telefoons.

GratisRTOS

FreeRTOS is een populair realtime kernel-besturingssysteem voor ingebedde apparaten dat is geladen met 35 microcontrollers. Het verspreidt zich onder GPL-licentie Met extra beperking en optionele uitzonderingen. De beperking verbiedt benchmarking, terwijl de uitzondering dit wel toestaat eigen code gebruikers samen met gesloten broncode, terwijl de kernel zelf behouden blijft. Dit maakt het eenvoudiger om FreeRTOS in uw eigen applicaties te gebruiken.

Windows CE

Windows Embedded Compact is een subfamilie van besturingssystemen ontwikkeld door Microsoft Corporation als onderdeel van de Windows-producten Ingebed. In tegenstelling tot Windows Embedded Standard, dat is gebaseerd op Windows NT, gebruiken deze voorbeeldbesturingssystemen een exclusieve hybride kernel. Microsoft biedt Windows-licenties CE voor OEM's die hun eigen aangepaste interfaces kunnen aanpassen en creëren technische basis hiervoor.

Real-time besturingssystemen (RTOS) zijn ontworpen om een ​​interface te bieden voor de bronnen van tijdkritische realtime systemen. De belangrijkste taak in dergelijke systemen is de tijdigheid van gegevensverwerking.

De belangrijkste vereiste voor een RTOS is het garanderen van voorspelbaarheid of determinisme van systeemgedrag onder de slechtste externe omstandigheden, wat sterk verschilt van de vereisten voor prestaties en snelheid van universele besturingssystemen. Een goede RTOS gedraagt ​​zich voorspelbaar onder alle systeembelastingscenario's (gelijktijdige onderbrekingen en threaduitvoering).

Er is een verschil tussen realtime systemen en embedded systemen. Een embedded systeem hoeft niet altijd voorspelbaar gedrag te vertonen; in dat geval is het geen real-time systeem. Maar zelfs een vluchtige blik op mogelijke embedded systemen suggereert dat de meeste embedded systemen voorspelbaar gedrag nodig hebben ten minste, voor bepaalde functionaliteit, en dus kunnen deze systemen worden geclassificeerd als realtime systemen.

Het is gebruikelijk om onderscheid te maken tussen zachte en harde real-time systemen. Bij systemen moeilijk echt tijd onvermogen om een ​​reactie te geven op gebeurtenissen in opgegeven tijd leidt tot mislukkingen en het onvermogen om de taak te voltooien. In de meeste Russischtalige literatuur worden dergelijke systemen systemen met deterministische tijd genoemd. Bij praktische toepassing reactietijd moet minimaal zijn. Zachte real-time systemen zijn systemen die niet onder de definitie van “hard” vallen, omdat In de literatuur bestaat er nog geen duidelijke definitie voor. Zachte real-time systemen hebben misschien geen tijd om een ​​probleem op te lossen, maar dit leidt niet tot falen van het systeem als geheel. In real-time systemen is het noodzakelijk om een ​​bepaalde deadline in te voeren (in de Engelse literatuur - deadline), vóór het verstrijken daarvan moet de taak noodzakelijkerwijs (voor zachte real-time systemen - bij voorkeur) zijn voltooid. Deze deadline wordt door de taakplanner gebruikt om zowel een prioriteit toe te kennen aan een taak wanneer deze wordt gestart als bij het selecteren van een taak voor uitvoering.

Martin Timmerman formuleerde de volgende noodzakelijke eisen voor een RTOS:

• Het besturingssysteem moet multitasken en verwijderbaar zijn,
• Het besturingssysteem moet een concept van prioriteit voor threads hebben,
• Het besturingssysteem moet voorspelbare synchronisatiemechanismen ondersteunen,
• Het besturingssysteem moet een mechanisme bieden voor het overnemen van prioriteiten,
• Het gedrag van het besturingssysteem moet bekend en voorspelbaar zijn (vertragingen bij het verwerken van onderbrekingen, vertragingen bij het wisselen van taken, vertragingen van stuurprogramma's, enz.); dit betekent dat in alle systeembelastingscenario's de maximale responstijd moet worden bepaald.

De afgelopen 25 tot 30 jaar is de structuur van besturingssystemen geëvolueerd van een monolithische naar een meerlaagse OS-structuur en vervolgens naar een client-server-architectuur. In een monolithische structuur bestaat het besturingssysteem uit een reeks modules, en wijzigingen in één module hebben invloed op andere modules. Hoe meer modules, hoe meer chaos er is tijdens de werking van zo’n systeem. Bovendien is het niet mogelijk om het besturingssysteem te distribueren op een systeem met meerdere processors. In een meerlaagse structuur hebben veranderingen in één laag invloed op aangrenzende lagen; bovendien is inversie door de laag niet mogelijk. Voor real-time systemen moet directe toegang tot elke laag van het besturingssysteem worden geboden, en soms rechtstreeks tot de hardware.

Het belangrijkste idee van client-servertechnologie in een besturingssysteem is om de besturingssysteembasis tot een minimum te beperken (planner- en synchronisatieprimitieven). Alle andere functionaliteit wordt naar een ander niveau verplaatst en geïmplementeerd via threads of taken. Een reeks van dergelijke servertaken is verantwoordelijk voor systeemaanroepen. Applicaties zijn clients die diensten aanvragen via systeemaanroepen.

Client-servertechnologie maakt de creatie van schaalbare besturingssystemen mogelijk en vereenvoudigt de distributie in een systeem met meerdere processors. Bij het bedienen van het systeem veroorzaakt het vervangen van één module geen “sneeuwbaleffect”; Bovendien leidt een modulestoring niet altijd tot een storing van het systeem als geheel. Er is nu de mogelijkheid om modules dynamisch te laden en te ontladen. Het grootste probleem in dit model is geheugenbescherming aanwezig, aangezien serverprocessen moeten worden beschermd. Elke keer dat er een serviceverzoek wordt gedaan, moet het systeem overschakelen van de applicatiecontext naar de servercontext. Met ondersteuning voor geheugenbescherming neemt de schakeltijd van het ene proces naar het andere toe.

In de regel zijn de meeste moderne RTOS gebouwd op basis van een microkernel (kernel of kern), die zorgt voor de planning en verzending van taken, evenals hun interactie. Hoewel de kernel de abstracties van het besturingssysteem minimaliseert, moet de microkernel nog steeds inzicht hebben in de procesabstractie. Alle andere conceptuele abstracties van besturingssystemen worden buiten de kernel verplaatst, op verzoek opgeroepen en als applicaties uitgevoerd.

Onderscheidende kenmerken RTOS van een algemeen besturingssysteem

Besturingssystemen voor algemene doeleinden, vooral besturingssystemen voor meerdere gebruikers, zoals UNIX, zijn bedoeld optimale verdeling computerbronnen tussen gebruikers en taken. In realtime besturingssystemen verdwijnt een dergelijke taak naar de achtergrond - alles verdwijnt eerder hoofdtaak- tijd hebben om te reageren op gebeurtenissen die zich in de faciliteit voordoen. Een ander verschil is dat het gebruik van een real-time besturingssysteem altijd verband houdt met de apparatuur, met het object, met de gebeurtenissen die zich in de faciliteit voordoen. Een real-time besturingssysteem is gericht op het verwerken van externe gebeurtenissen. Een real-time besturingssysteem kan vergelijkbaar zijn in gebruikersinterface op een algemeen besturingssysteem, maar het is totaal anders gestructureerd. Bovendien is het gebruik van realtime besturingssystemen altijd specifiek. Als een algemeen besturingssysteem door gebruikers (niet door ontwikkelaars) doorgaans wordt gezien als een kant-en-klare set applicaties, dan dient een real-time besturingssysteem alleen als hulpmiddel voor het creëren van een specifiek real-time hardware- en softwarecomplex. En daarom bestaat de grootste groep gebruikers van real-time besturingssystemen uit ontwikkelaars van real-time systemen, mensen die besturings- en data-acquisitiesystemen ontwerpen. Bij het ontwerpen en ontwikkelen van een specifiek real-time systeem weet de programmeur altijd precies welke gebeurtenissen zich in de faciliteit kunnen voordoen, en weet hij dat het kritieke tijdsbestek voor het onderhouden van elk van deze gebeurtenissen de tijd moet hebben om te reageren op een gebeurtenis die heeft plaatsgevonden in de faciliteit binnen de tijd die cruciaal is voor deze gebeurtenis. De waarde van de kritische tijd voor elke gebeurtenis wordt bepaald door het object en de gebeurtenis zelf, en kan verschillend zijn, maar de reactietijd van het systeem moet worden voorspeld (berekend) bij het maken van het systeem. Het niet reageren op het voorspelde tijdstip wordt als een fout beschouwd voor realtimesystemen. Het systeem moet kunnen reageren op gelijktijdig optredende gebeurtenissen. Zelfs als zich twee of meer externe gebeurtenissen tegelijkertijd voordoen, moet het systeem de tijd hebben om op elk van deze gebeurtenissen te reageren binnen de tijdsintervallen die cruciaal zijn voor deze gebeurtenissen.

Harde en zachte real-time systemen

Er zijn twee soorten real-time systemen: harde real-time systemen en zachte real-time systemen.

Harde real-time systemen laten onder geen enkele omstandigheid enige vertraging in de systeemreactie toe omdat:

• resultaten kunnen nutteloos zijn als ze te laat komen
• Er kan zich een ramp voordoen als de reactie wordt uitgesteld

• de kosten van te laat komen kunnen oneindig zijn.

Voorbeelden van harde real-time systemen zijn controlesystemen aan boord, noodbeschermingssystemen en recorders voor noodsituaties.

Zachte real-time systemen worden gekenmerkt door het feit dat de responsvertraging niet kritisch is, hoewel dit kan leiden tot een stijging van de resultaatkosten en een afname van de prestaties van het systeem als geheel. Een voorbeeld hiervan is de netwerkwerking. Als het systeem geen tijd heeft om het volgende ontvangen pakket te verwerken, zal dit leiden tot een time-out aan de verzendende kant en het opnieuw verzenden (uiteraard afhankelijk van het protocol). Er gaan geen gegevens verloren, maar de netwerkprestaties worden verminderd. Het belangrijkste verschil tussen harde en zachte real-time systemen kan als volgt worden uitgedrukt: moeilijk systeem real-time zal nooit te laat zijn met reageren op een gebeurtenis, een zacht real-time systeem zou niet te laat moeten zijn met reageren op een gebeurtenis

Besturingssysteem-kernel

De kernel is het centrale onderdeel van het besturingssysteem (OS) en biedt applicaties gecoördineerde toegang tot computerbronnen, geheugen, externe hardware, externe invoer- en uitvoerapparaten, en vertaalt applicatietaalopdrachten in binaire codetaal die de computer als fundamenteel begrijpt element van het besturingssysteem, vertegenwoordigt de kernel het meeste laag niveau abstracties voor toepassingen om toegang te krijgen tot de systeembronnen die nodig zijn voor hun werking. Normaal gesproken biedt de kernel dergelijke toegang tot de uitvoerende processen van de overeenkomstige applicaties door het gebruik van mechanismen communicatie tussen processen en applicatieoproepen naar systeemoproepen Besturingssysteem.

Monolithische kern

De monolithische kernel biedt een rijke reeks hardware-abstracties. Alle delen van een monolithische kernel werken in dezelfde adresruimte. Dit is een besturingssysteemontwerp waarin alle componenten van de kernel zijn opgenomen componentenéén programma, gebruik algemene structuren gegevens en communiceer met elkaar door rechtstreeks procedures aan te roepen. Monolithische kern - de oudste manier organisatie van besturingssystemen. Een voorbeeld van systemen met een monolithische kernel zijn de meeste UNIX-systemen.

Voordelen: Snelheid van werken, vereenvoudigde ontwikkeling van modules.

Gebreken: Omdat de hele kernel in dezelfde adresruimte werkt, kan een storing in een van de componenten het hele systeem ontwrichten.

Sommige oude monolithische kernels, vooral systemen van de UNIX/Linux-klasse, vereisten hercompilatie telkens wanneer de hardwaresamenstelling veranderde. Meerderheid moderne korrels kunt u tijdens de werking modules laden die een deel van de kernelfuncties uitvoeren. In dit geval zijn de componenten van het besturingssysteem dat niet onafhankelijke modules, en de componenten van één groot programma een monolithische kernel genoemd, een reeks procedures die elk elkaar kunnen aanroepen. Alle procedures worden uitgevoerd in de bevoorrechte modus.

Microkernel

De microkernel biedt alleen basisprocescontrolefuncties en een minimale set abstracties voor het werken met hardware. Het meeste werk wordt gedaan via speciale gebruikersprocessen die services worden genoemd. Het doorslaggevende criterium voor ‘microkernelisme’ is de plaatsing van alle of bijna alle drivers en modules in serviceprocessen.

Voordelen: Weerstand tegen hardwarefouten en fouten in systeemcomponenten. Het belangrijkste voordeel van microkernelarchitectuur is hoge graad modulariteit van de kernel van het besturingssysteem. Dit maakt het veel gemakkelijker om er nieuwe componenten aan toe te voegen. In een microkernelbesturingssysteem kunt u nieuwe stuurprogramma's, bestandssystemen, enz. laden en verwijderen zonder de werking ervan te onderbreken nieuwe versie stuurprogramma's kunnen worden geladen zonder het hele besturingssysteem opnieuw op te starten. De componenten van de kernel van het besturingssysteem verschillen niet fundamenteel van gebruikersprogramma's, dus u kunt gewone tools gebruiken om ze te debuggen. De microkernelarchitectuur verbetert de betrouwbaarheid van het systeem, omdat een fout op programmaniveau zonder privileges minder gevaarlijk is dan een fout op het niveau van de kernelmodus.

Gebreken: Het doorgeven van gegevens tussen processen vereist overhead.

Runtime-omgeving

De vereisten voor de uitvoeringsomgeving van realtime systemen zijn als volgt:

• klein systeemgeheugen - vanwege de mogelijkheid van inbedding;
• het systeem moet volledig geheugenresident zijn om geheugenwisselen of -wisselen te voorkomen;
• het systeem moet multitasken - om maximaal te garanderen effectief gebruik alle systeembronnen;
• kern met prioriteit voor het onderhouden van interrupts. Interruptprioriteit betekent dat een proces dat klaar is om te worden uitgevoerd en een bepaalde prioriteit heeft, noodzakelijkerwijs voorrang in de wachtrij heeft boven een proces met een lagere prioriteit, dit laatste snel vervangt en overgaat tot uitvoering. De kern maakt alles af dienstwerk, zodra er een taak binnenkomt topprioriteit. Dit waarborgt de voorspelbaarheid van het systeem;
• Prioriteitsmanager - hiermee kan de applicatieontwikkelaar aan elke opstartmodule een prioriteit toewijzen die niet aan het systeem onderworpen is. Prioriteitstoewijzing wordt gebruikt om de volgorde te bepalen waarin programma's die gereed zijn om te worden uitgevoerd, worden uitgevoerd. Een alternatief voor dit type planning is carrouselplanning, waarbij elk programma dat klaar is om door te gaan een gelijke kans krijgt om te worden uitgevoerd. Met deze methode is er geen controle over welk programma wanneer wordt uitgevoerd. Dit is onaanvaardbaar in een real-time omgeving. Op prioriteit gebaseerde verzending en een kernel met interruptprioriteit geven de applicatie-ontwikkelaar volledige controle over het systeem. Als er zich een gebeurtenis met een hogere prioriteit voordoet, stopt het systeem met het verwerken van de taak met een lagere prioriteit en reageert het op het nieuw ontvangen verzoek.

De combinatie van de hierboven beschreven eigenschappen creëert een krachtige en efficiënte real-time uitvoeringsomgeving.

Naast de eigenschappen van de runtime-omgeving is het ook noodzakelijk om rekening te houden met de service die wordt geboden door de real-time OS-kernel. De kern van elke real-time uitvoeringsomgeving is de kernel of dispatcher. De kernel bestuurt de hardware van de doelcomputer: centrale verwerker, geheugen en invoer-/uitvoerapparaten; controleert de werking van alle andere systemen en software van toegepaste aard. In een real-time systeem zit de coördinator tussen de hardware van de doelcomputer en de applicatiesoftware. Het biedt speciale dienst, noodzakelijk voor het uitvoeren van realtime applicaties. De service die door de kernel wordt geleverd, geeft applicatieprogramma's toegang tot systeembronnen zoals geheugen of invoer-/uitvoerapparaten.

De kernel kan verschillende soorten services bieden:

• Intertask-uitwisseling. Het is vaak nodig om gegevens over te dragen tussen programma's binnen hetzelfde systeem. Bovendien moeten veel applicaties via een netwerk met andere systemen communiceren. Intercom kan worden gedaan via een berichtensysteem. Externe communicatie kan worden georganiseerd via een datagram ( beste manier levering), of via communicatielijnen (gegarandeerde levering). De keuze voor de ene of de andere methode hangt af van het communicatieprotocol.
• Gegevensscheiding. Bij real-time toepassingen duurt het verzamelen van gegevens het langst. Gegevens zijn vaak nodig voor de werking van andere programma's of zijn nodig voor het systeem om bepaalde functies uit te voeren. Veel systemen bieden toegang tot algemene secties geheugen. Dataqueuing is wijdverbreid. Er zijn veel soorten wachtrijen in gebruik, die elk hun eigen voordelen hebben.
• Verwerken van verzoeken van externe apparaten. Elk applicatieprogramma is in realtime verbonden met een extern apparaat bepaald type. De kernel moet I/O-services bieden waarmee applicatieprogramma's van deze apparaten kunnen lezen en ernaar kunnen schrijven. Voor real-time toepassingen is het gebruikelijk om een deze applicatie extern apparaat. De kernel moet een dienst bieden die het werken met apparaatstuurprogramma's eenvoudiger maakt. Maak het bijvoorbeeld mogelijk om in talen op te nemen hoog niveau- zoals C of Pascal.
• Omgaan met bijzondere situaties. Een uitzondering is een gebeurtenis die optreedt tijdens de uitvoering van een programma. Het kan synchroon zijn als het voorkomen ervan voorspelbaar is, zoals delen door nul. En het kan ook asynchroon zijn als het zich op onvoorspelbare wijze voordoet, zoals een spanningsval. Door de mogelijkheid te bieden dit soort gebeurtenissen af ​​te handelen, kunnen realtime applicaties snel en voorspelbaar reageren op interne en externe gebeurtenissen. Er zijn twee methoden voor het afhandelen van uitzonderingen: het gebruik van statuswaarden om foutcondities te detecteren en het gebruik van een uitzonderingshandler om foutcondities op te sporen en te corrigeren.

Overzicht van RTOS-architecturen

In de loop van de geschiedenis heeft de architectuur van het besturingssysteem een ​​aanzienlijke ontwikkeling doorgemaakt. Een van de eerste bouwprincipes, monolithisch Het besturingssysteem (Figuur 1) bestond uit het presenteren van het besturingssysteem als een reeks modules die op verschillende manieren met elkaar communiceren binnen de systeemkern en die applicatieprogramma's voorzien van invoerinterfaces voor toegang tot hardware.

niveau besturingssysteem (Figuur 2). MS-DOS-systeem. In systemen van deze klasse konden applicatieapplicaties niet alleen toegang krijgen tot de hardware via de systeemkernel of de aanwezige services, maar ook rechtstreeks. RTOS's zijn al vele jaren op dit principe gebouwd. Vergeleken met monolithische besturingssystemen biedt deze architectuur een aanzienlijk grotere mate van voorspelbaarheid van systeemreacties, en maakt het ook mogelijk dat applicatietoepassingen snel toegang krijgen tot de hardware. Nadeel

Wat dergelijke systemen zo slecht maakt, is hun gebrek aan multitasking. Binnen deze architectuur werd het probleem van het verwerken van asynchrone gebeurtenissen beperkt tot het bufferen van berichten, het vervolgens opeenvolgend pollen van de buffers en het verwerken ervan. Tegelijkertijd werd de naleving van kritieke servicedeadlines verzekerd door de hoge prestaties van het computercomplex in vergelijking met de snelheid van externe processen.

Figuur 2. Gelaagde OS-architectuur

Een van de meest effectieve architecturen voor het bouwen van real-time besturingssystemen is de client-server-architectuur. Algemeen schema Een besturingssysteem dat deze technologie gebruikt, wordt weergegeven in figuur 3. Het belangrijkste principe van deze architectuur is de overdracht van besturingssysteemservices in de vorm van servers naar het gebruikersniveau, en de microkernel fungeert als berichtenbeheerder tussen clientgebruikersprogramma's en servers - systeem diensten. Deze architectuur biedt veel voordelen op het gebied van vereisten voor RTOS en embedded systemen. Tot deze voordelen behoren:

1. De betrouwbaarheid van het besturingssysteem neemt toe, omdat Elke service is in feite een onafhankelijke applicatie en het is gemakkelijker om fouten te debuggen en op te sporen.

2. Een dergelijk systeem schaalt beter, omdat onnodige services van het systeem kunnen worden uitgesloten zonder dat de prestaties ervan in gevaar komen.

3. De fouttolerantie van het systeem neemt toe, omdat Een bevroren service kan opnieuw worden gestart zonder

start het systeem opnieuw op.

Figuur 3. Een besturingssysteem bouwen met behulp van client-serverarchitectuur

Helaas zijn er tegenwoordig niet veel besturingssystemen geïmplementeerd volgens het client-server-principe. Tot de bekende RTOS'en die microkernelarchitectuur implementeren behoren OS9 en QNX.

Lijst met gebruikte literatuur:

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

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

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

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

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