(Echte tijd Besturingssysteem s - RTOS) zijn softwaretools en zijn bedoeld om digitale systemen in gevallen waarin:

● het systeem moet niet alleen het resultaat van de verwerking van de ontvangen informatie garanderen, maar ook de tijdsduur voor het verkrijgen van het resultaat. Van de RTOS is het, naast het verkrijgen van het vereiste resultaat, vereist om de gespecificeerde tijdparameters te implementeren: de tijdsintervallen tussen gebeurtenissen en reacties of de gespecificeerde frequentie van het ontvangen van externe gegevens en het uitgeven van resultaten;

● het systeem is in staat om meerdere taken tegelijk uit te voeren. Typisch multitasking het besturingssysteem kent aan elke taak (programma) dezelfde hoeveelheid tijd toe, waardoor de gebruiker de indruk krijgt dat alle programma's tegelijkertijd worden uitgevoerd. Een realtime besturingssysteem is een speciaal geval van een multitaskingbesturingssysteem dat is geoptimaliseerd voor de implementatie van beheerprocessen. Het reageert snel op externe gebeurtenissen en stelt u in staat om de werking van verschillende processors te simuleren, die elk één apparaat aansturen. Om een ​​complex systeem te besturen met een enkele processor, is het daarom raadzaam om een ​​RTOS te gebruiken, die in staat is om de uitvoering van verschillende taken te coördineren. Een voorbeeld van een RTOS is een liftbesturingssysteem.

Hoe een RTOS werkt

Bij binnenkomst van een aanvraag wordt gecontroleerd op de invoergegevens om het probleem op te lossen. Als ze aanwezig zijn, wordt de taak uitgevoerd. ALS de vereiste invoer niet beschikbaar is, gaat de RTOS verder met de volgende taak (indien gevraagd om deze te voltooien). Interrupts worden gebruikt om input te ontvangen en de bijbehorende taak te starten. Een taak wordt meestal gestart door deze over te brengen van de wachtende taakwachtrij naar de uit te voeren taakwachtrij.

Elke taak heeft een wachtrij voor invoerberichten die alleen kan worden verwerkt tijdens het toegewezen tijdsinterval of na een onderbrekingsverzoek. Als de respons te lang duurt, wordt de taak teruggeplaatst in de uitvoerbare wachtrij en wordt de controle overgedragen aan de volgende taak.

Systeembronnen ( schijfstations, timers, I / O-apparaten, enz.) zijn meestal alleen beschikbaar voor specifieke taken. Hiermee kunt u de wachtrij met verzoeken om resources zo ordenen dat wordt voorkomen dat meerdere taken tegelijkertijd toegang krijgen tot dezelfde resource.

Vereisten voor RTOS.

Modern PB OS moet aan de volgende eisen voldoen:

● korte responstijd (het verkrijgen van het resultaat);

● implementatie van een multitasking-modus met een flexibel prioriteitsmechanisme;

● weinig geheugen (voldoende voor plaatsing in het residente geheugen van het applicatiesysteem);

● beschikbaarheid van servicefuncties en ondersteuningstools voor het ontwikkelen van applicatieprogramma's en een aantal andere.

Momenteel wordt RTOS gebruikt voor de ontwikkeling van microcontrollersystemen. verschillende kenmerken en zijn getest in toepassingsgebieden zoals industriële automatiseringssystemen, controle- en meetsystemen, telecommunicatieapparatuur, ruimtevaart- en militaire uitrusting, transport, beveiligingssystemen, enz.

RTOS-typen

Er zijn twee soorten RTOS te onderscheiden:

● harde real-time systemen, die een kleine hoeveelheid geheugen in beslag nemen en minimale responstijden hebben, maar zeer beperkte servicefaciliteiten hebben. Ze zijn modulair geïmplementeerd, waardoor u alleen die tools kunt gebruiken die nodig zijn in een bepaalde toepassing. Als resultaat wordt voor een bepaalde toepassing een significante vermindering van de benodigde hoeveelheid geheugen en responstijd bereikt;

● Zachte realtime-systemen, die meer geheugen nodig hebben, hebben een langere responstijd, maar voldoen aan een breed scala aan gebruikerseisen wat betreft de taakservicemodus en het geleverde serviceniveau. Zachte real-time systeeminterfacetools maken het gebruik van zeer efficiënte debuggers of IDE's mogelijk.

Zacht realtime systeem.

Laten we eens kijken naar dit type systeem met het OS – 9-systeem van Microwave Systems als voorbeeld. Als instrumentele computer gebruikt OS –9 IBM - pc's die worden uitgevoerd in Windows-omgeving, of werkstations Sun, HP, IBM RS / 6000 met besturingssystemen zoals UNIX. Kenmerken besturingssysteem –9:

● modulariteit, die de mogelijkheid biedt om de doel-RTOS te configureren in overeenstemming met de klasse van op te lossen taken. Door ongebruikte modules te elimineren, kunt u geheugen besparen en systeemkosten verlagen;

● flexibiliteit van de structuur, waardoor het systeem opnieuw kan worden geconfigureerd en de functionaliteit ervan kan worden uitgebreid. Functionele componenten Besturingssysteem – 9:

● realtime-kernel (OS –9-kernel);

● algemene input/output faciliteiten (I/O man);

● bestandsbeheerders;

● softwareontwikkelingstools.

De functionele componenten van OS-9 zijn ontworpen als zelfstandige modules die kunnen worden verwijderd of toegevoegd met behulp van eenvoudige opdrachten die niet opnieuw gecompileerd of opnieuw opgebouwd hoeven te worden. Door modules te combineren, kunt u doelbesturingssystemen maken met verschillende functionaliteiten.

Overweeg het bovenstaande: functionele componenten.

Realtime-kernel

Het systeem bevat twee soorten kernels:

● Atoomkern, die het minimum aantal servicefuncties implementeert (laden op afstand, communicatie met) lokaal netwerk, besturing van slave-microcontrollers). De core wordt gebruikt in systemen die zijn ingebed in verschillende apparatuur, heeft een klein volume (24 Kbytes) en biedt een minimale responstijd (3 s bij een klokfrequentie van 25 MHz);

● Standaardkern, die een breed scala aan service- en ontwikkelingsfuncties biedt toepassingsprogramma's, voor de uitvoering waarvan meer geheugen nodig is (tot 512K bytes ROM en 38K bytes RAM). Door te veranderen functionele modules cores kunnen worden gebruikt om systemen van verschillende complexiteit en doel te implementeren: van embedded controllers met resident software en de eenvoudigste I/O tot complexe functionele systemen klasse werkstations met geavanceerde netwerkondersteuning en een verscheidenheid aan servicefuncties, waaronder multimedia.

OS –9 biedt de gebruiker de keuze voor een kernel, afhankelijk van de functionaliteit van het systeem. Algemene middelen van invoer / uitvoer. De fysieke interface van OS-9 met een verscheidenheid aan externe apparaten wordt geleverd door een groot een stel chauffeurs, gemaakt door zowel Microwave Systems als tal van hardwareontwikkelaars die dit besturingssysteem gebruiken voor specifieke toepassingen. Bestandsbeheerders. Dit zijn onder andere modules die logische datastromen aansturen. Elk van de modules heeft een specifieke functioneel doel en specificatie. Bestandsbeheerders kunnen worden onderverdeeld in drie groepen:

● standaardmanagers die zijn ontworpen om dergelijke basisfuncties van uitwisseling met externe apparaten uit te voeren, zoals het in de wachtrij plaatsen van inkomende opdrachten, controle van sequentiële uitwisseling van bytes en blokken en uitwisseling met directe geheugentoegang;

● netwerk- en communicatiemanagers die zorgen voor de werking van OS-9 met verschillende netwerken en de uitwisseling van gegevens via communicatiekanalen met de meest gangbare standaarden van uitwisselingsprotocollen;

● beheerders van de grafische interface en werken met multimediatoepassingen. Hulpprogramma's voor softwareontwikkeling. OS-9 bevat een softwarepakket (BSP) om ontwikkelborden te ondersteunen, waardoor OS-9 kan samenwerken met een aantal SBC's (Single Board Computer). Door BSP en OS-9 samen te gebruiken, kunt u het doelsysteem configureren voor: specifieke toepassing:.

OS – 9-systeem bevat programmeerondersteuningstools: Ultra C / C ++ -compilers, EM ACS-teksteditor, drie typen (inclusief symbolische) debuggers, een set hulpprogramma's voor het organiseren van controle en assemblage van softwareproducten. Daarnaast is er een grote set (compatibel met OS –9) programmeerondersteuningstools die door andere bedrijven zijn ontwikkeld. FasTraTot. FasTrak is gebundeld met OS – 9 en biedt de meest complete set programmeer- en foutopsporingstools voor de gebruiker. Een deel van de FasTrak-software is geïnstalleerd op de ontwikkelcomputer en een deel op het doelsysteem van de gebruiker. De FasTrak-omgeving integreert alle tools die nodig zijn om het ontwerp/debuggen van doelsystemen te ondersteunen. De versie van de FasTrak-omgeving voor werken op de ontwikkelcomputer IBM - PC bevat:

● een teksteditor met conversietools voor het toetsenbord, die bewerking in een gebruiksvriendelijk formaat mogelijk maakt;

● Ultra C/C++-compilers;

● debuggers die twee manieren van debuggen bieden: Op maat- om applicatieprogramma's te maken, en systemisch- voor serviceonderbrekingen, systeemoproepen en toegang de kern echte tijd;

● middel van interface met logische analysatoren van het bedrijf.

De FasTrak-omgeving is rijk aan functionaliteit waardoor het effectieve remedie creatie van software voor verschillende microcontrollersystemen.

Microware Systems levert een reeks van: systeempakketten gericht op verschillende toepassingsgebieden:

● Wireless OS –9 - voor de ontwikkeling van draadloze communicatieapparatuur: mobiele telefoons, semafoons, draagbare digitale assistenten (PDA);

● Internet OS –9 - voor het ontwikkelen van apparaten met toegang tot internet;

● Digital Audio / Video Interactive Decoder (DAVID) OS –9 - voor de ontwikkeling van gedistribueerde digitale systemen interactieve televisie.

Hard real-time systeem

We zullen de kenmerken van dit type systemen bekijken aan de hand van het voorbeeld van het VxWorks-systeem van WindRiver Systems, ontworpen om te werken met families van microprocessors van vele fabrikanten. Het VxWorks-systeem wordt geïnstalleerd op het doelsysteem dat wordt opgespoord en werkt samen met de Tornado IDE die op de ontwikkelcomputer draait. Als instrumentele computer worden IBM - pc's die in de Windows-omgeving werken, of werkstations SUN, HP, enz. Gebruikt. Korte beschrijving van het systeemVxWorks. Het lagere niveau van de hiërarchische organisatie van het systeem is een realtime microkernel, die de basisfuncties uitvoert van het plannen van taken en het beheren van hun communicatie en synchronisatie. De minimale set kernelmodules neemt 20-40K bytes geheugen in beslag. Alle andere functies - geheugenbeheer, I / O, netwerkuitwisseling en andere, worden geïmplementeerd door extra modules. Om grafische toepassingen te ondersteunen, heeft VxWorks een VX – Windows grafische interface.

Met beperkt geheugen op het doelsysteem kunt u de RTGL grafische bibliotheek gebruiken, die elementaire grafische primitieven, lettertypen en kleurensets, generieke stuurprogramma's voor invoerapparaten en grafische controllers bevat. VxWorks bevat ook een verscheidenheid aan tools om een ​​verscheidenheid aan netwerkprotocollen te ondersteunen. traceren gegeven gebeurtenissen en hun accumulatie in het buffergeheugen voor daaropvolgende analyse worden in realtime uitgevoerd door speciale foutopsporingstools en tracering systemisch gebeurtenissen - dynamische analysator WindView. De WindView-analysator werkt op dezelfde manier als een logische analysator en geeft timingdiagrammen op het scherm weer voor het wisselen van taken, het in de wachtrij plaatsen van berichten en andere processen. Met de stethoscoop-gegevensmonitor kunt u de dynamische verandering van gebruikers- en systeemvariabelen analyseren, inclusief een procedureprofiler. VxWorks omvat:

● softwarepakket ter ondersteuning van ontwikkelborden;

● VxSim-simulator, waarmee een multitasking VxWorks-omgeving en interface met een doelsysteem op een ontwikkelcomputer kunnen worden gesimuleerd, evenals het ontwikkelen en debuggen van software zonder het doelsysteem aan te sluiten.

Voor complexe debugging van doelsystemen biedt VxWorks een interface voor circuit- en ROM-emulators. Geïntegreerde ontwikkelomgevingTornado . Tornado bevat het VxWorks 5.3-systeem, dat een realtime kernel en systeembibliotheken, programmeertools, een debugger op hoog niveau en een aantal andere systeemtools omvat. Extra tools van de Tornado-omgeving bieden controle over het foutopsporingsproces, visualisatie van de status van het doelsysteem en andere servicefuncties. De open architectuur van de Tomado-omgeving stelt de gebruiker in staat om zijn eigen gespecialiseerde tools in te pluggen en de mogelijkheden van de standaardtools uit te breiden.

Het realtime besturingssysteem van VxWorks, samen met het Tornado-framework, is een krachtig hulpmiddel voor het targeten van systemen die werken met ernstige geheugen- en responstijdbeperkingen.

Stuur uw goede werk in de kennisbank is eenvoudig. Gebruik het onderstaande formulier

Studenten, afstudeerders, jonge wetenschappers die de kennisbasis gebruiken in hun studie en werk zullen je zeer dankbaar zijn.

Federaal Agentschap voor Onderwijs

Afdeling Geautomatiseerde Besturingssystemen

Realtime systemen

Invoering

1. Realtime besturingssystemen

1.1 Soorten RTOS

1.2 RTOS-structuur

1.3 Processen, threads, taken

1.4 Planning, prioriteiten

1.5 Geheugen

1.6 Onderbrekingen

1.7 Klokken en timers

2. Normen van realtime besturingssystemen

2.1 POSIX-standaard

2.2 DO-178B Standaard

2.3 ARINC-653 standaard

2.4 OSEK-standaard

2.5 Veiligheidsnormen

3. Korte kenmerken van gangbare realtime besturingssystemen

3.2 QNX Neutrino RTOS

3.5 RTX (realtime-extensie voor Windows NT)

3.6 INtime (Windows NT Realtime-extensie)

3.8 MicroWare OS-9

3.11 Kern RTOS

Conclusie

Bibliografische lijst

Invoering

De concepten achter de meeste real-time besturingssystemen die tegenwoordig bestaan, vinden hun oorsprong in de late jaren 70 en vroege jaren 80.

Real-time besturingssystemen en embedded systemen werken in "kleine" omgevingen waar geheugen en processorkracht beperkt zijn. Ze moeten ervoor zorgen dat services binnen een strikt tijdsbestek operationeel zijn voor gebruikers en de wereld waarmee ze communiceren.

Real-time systemen onderscheiden zich door zeer bescheiden mogelijkheden van de gebruikersinterface, aangezien het systeem dat in gebruik wordt genomen een "black box" is. Een zeer belangrijk onderdeel en het belangrijkste kenmerk van het real-time besturingssysteem is het beheer van computerbronnen op een zodanige manier dat een bepaalde bewerking wordt uitgevoerd voor exact dezelfde tijdsduur telkens wanneer deze moet worden uitgevoerd en die niet kan worden overschreden.

In een complexe auto, meer snel reizen onderdelen dan nodig zijn, alleen omdat de bronnen van het systeem het toelaten, kan leiden tot rampzalige resultaten, evenals het onvermogen om dit onderdeel te verplaatsen omdat het systeem bezet is.

Meestal is bij het ontwerpen van een realtime systeem de samenstelling van de programma's (taken) die het uitvoert vooraf bekend. Veel van hun parameters zijn ook bekend, waarmee rekening moet worden gehouden bij het toewijzen van bronnen (bijvoorbeeld geheugengrootte, prioriteit, gemiddelde uitvoeringstijd, geopende bestanden, gebruikte apparaten, enz.). Daarom worden vooraf taakbeschrijvingen voor hen opgesteld om geen kostbare tijd te verspillen aan het organiseren van de descriptor en het later zoeken naar de benodigde bronnen.

Voor de echte implementatie van de realtime-modus is de organisatie van multiprogrammering noodzakelijk. Multiprogrammering is het belangrijkste middel om de prestaties van een computersysteem te verbeteren, en voor het oplossen van realtime problemen worden prestaties de belangrijkste factor.

De beste prestatiekenmerken voor real-time systemen worden geleverd door real-time besturingssystemen met één terminal.

1. Realtime besturingssystemen

Een realtime besturingssysteem is een type besturingssysteem.

Er zijn veel definities van de term. De meest voorkomende zijn:

* Een besturingssysteem waarin het succes van een programma niet alleen afhangt van de logische juistheid ervan, maar ook van de tijd waarin het dit resultaat heeft ontvangen. Als het systeem niet aan de tijdsdruk kan voldoen, moet een storing in de werking worden geregistreerd;

* De POSIX 1003.1-standaard definieert: "Real-time in besturingssystemen is het vermogen van het besturingssysteem om het vereiste serviceniveau in een bepaalde periode te bieden";

* Een besturingssysteem dat op een voorspelbaar tijdstip reageert op het onvoorspelbare optreden van externe gebeurtenissen;

* Interactieve systemen van constante paraatheid. Ze zijn ingedeeld in de RTOS-categorie op basis van marketingoverwegingen, en als een interactief programma "in realtime werken" wordt genoemd, betekent dit alleen dat verzoeken van de gebruiker worden verwerkt met een vertraging die voor mensen niet waarneembaar is.

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

De belangrijkste vereiste voor een RTOS is de vereiste om voorspelbaarheid of determinisme van het systeemgedrag in de slechtste externe omstandigheden te garanderen, wat sterk verschilt van de vereisten voor prestaties en snelheid van universele besturingssystemen. Een goede RTOS vertoont voorspelbaar gedrag in alle scenario's systeem opstarten(gelijktijdige interrupts en thread-uitvoering).

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 realtime systeem. Zelfs een vluchtige blik op mogelijke embedded systemen suggereert echter dat de meeste embedded systemen voorspelbaar gedrag nodig hebben, althans voor bepaalde functionaliteit, en dus kunnen worden geclassificeerd als real-time systemen.

Martin Timmerman (directeur van Real-Time Consult en Real-Time User "s Support International (RTUSI)", dat hardware- en softwareondersteuning levert en projecten voor realtime systemen ontwikkelt) formuleerde de volgende noodzakelijke eisen voor een RTOS:

* het besturingssysteem moet preventief en multitasking zijn;

* het besturingssysteem moet het concept van prioriteit voor threads hebben;

* het besturingssysteem moet voorspelbare synchronisatiemechanismen ondersteunen;

* het besturingssysteem moet voorzien in een mechanisme voor het erven van prioriteiten;

* het gedrag van het besturingssysteem moet bekend en voorspelbaar zijn (vertragingen bij de verwerking van onderbrekingen, vertragingen bij het wisselen van taken, vertragingen van de bestuurder, enz.).

Dit betekent dat in alle scenario's voor systeembelasting een maximale responstijd moet worden opgegeven.

1.1 RTOS-typen

Het is gebruikelijk om onderscheid te maken tussen zachte en harde realtime systemen.

In harde real-time systemen kan het onvermogen om te reageren op gebeurtenissen in tijd instellen leidt tot weigeringen en de onmogelijkheid om de toegewezen taak te voltooien. In de meeste Russischtalige literatuur worden dergelijke systemen systemen met deterministische tijd genoemd. In praktische toepassingen moeten reactietijden tot een minimum worden beperkt.

Systemen die niet onder de definitie van "hard" vallen, worden zachte realtime-systemen genoemd. er is nog steeds geen duidelijke definitie voor in de literatuur. Zachte real-time systemen hebben misschien geen tijd om het probleem op te lossen, maar dit leidt niet tot systeemstoringen als geheel.

In real-time systemen is het noodzakelijk om een ​​bepaalde regieperiode in te voeren (in de Engelstalige literatuur - deadline), vóór het verstrijken waarvan de taak noodzakelijkerwijs (voor zachte real-time systemen - bij voorkeur) voltooid moet zijn. Deze deadline wordt door de taakplanner gebruikt om zowel een prioriteit toe te kennen aan een taak wanneer deze begint als bij het kiezen van een uit te voeren taak.

1.2 RTOS-structuur

In de afgelopen 25-30 jaar is de structuur van besturingssystemen (OS) geëvolueerd van een monolithische naar een meerlagige OS-structuur en verder naar een client-server-architectuur.

Met een monolithische structuur bestaat het besturingssysteem uit een set modules, en veranderingen in de ene module hebben invloed op andere modules. Hoe meer modules, hoe meer chaos tijdens de werking van zo'n systeem. Het is ook 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, en bovendien is het niet mogelijk om door de laag te circuleren.

Voor realtime systemen moet directe toegang tot elke OS-laag worden geboden, en soms ook rechtstreeks tot de hardware.

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

Client-servertechnologie maakt schaalbare besturingssystemen mogelijk en vereenvoudigt de distributie op een systeem met meerdere processors. Tijdens de werking van het systeem veroorzaakt het vervangen van één module geen “sneeuwbaleffect” en bovendien betekent een storing van een module niet altijd een storing van het systeem als geheel. Nu kunt u modules dynamisch laden en lossen. Het grootste probleem in dit model is geheugenbescherming, aangezien de serverprocessen moeten worden beschermd. Elke keer dat een serviceverzoek wordt gedaan, moet het systeem overschakelen van de applicatiecontext naar de servercontext. Met de ondersteuning van 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 planning en planning van taken, en ook hun interactie implementeert. Ondanks het minimaliseren van OS-abstracties in de kernel, moet de microkernel zich nog steeds bewust zijn van de procesabstractie. Alle andere conceptuele abstracties van besturingssystemen worden buiten de kernel verplaatst, op aanvraag aangeroepen en uitgevoerd als toepassingen.

1.3 Processen, threads, taken

Het concept van multitasking (pseudo-parallelisme) is essentieel voor een real-time systeem met een enkele processor, waarvan de applicaties in staat moeten zijn om tal van externe gebeurtenissen aan te kunnen die bijna gelijktijdig plaatsvinden.

Het concept van een proces, afkomstig uit de UNIX-wereld, werkt niet goed in een multitaskingsysteem omdat het proces een zware context heeft. Het concept van een draad ontstaat, die wordt opgevat als een subproces of een lichtgewicht proces. Threads bestaan ​​in dezelfde procescontext, dus schakelen tussen threads gaat erg snel en er wordt geen rekening gehouden met beveiligingsproblemen. Streams zijn lichtgewicht omdat hun registercontext kleiner is, d.w.z. hun bedieningsblokken zijn veel compacter. Vermindert de overhead die gepaard gaat met het opslaan en herstellen van besturingsblokken van onderbroken threads. Het aantal besturingsblokken is afhankelijk van de geheugenconfiguratie. Als de threads in verschillende adresruimten worden uitgevoerd, moet het systeem voor elke set threads geheugentoewijzingen bijhouden.

In realtime systemen wordt een proces dus opgesplitst in taken of threads. In elk geval wordt elk proces beschouwd als een aanvraag. Er mogen niet te veel interacties zijn tussen deze applicaties, en in de meeste gevallen zijn ze van een andere aard - harde realtime, zachte realtime, niet realtime.

1.4 Planning, prioriteiten

De grootste uitdaging in een RTOS is de planning, die zorgt voor voorspelbaar systeemgedrag onder alle omstandigheden. In verband met planningsproblemen in RTOS worden twee benaderingen bestudeerd en ontwikkeld: statische planningsalgoritmen (RMS - Rate Monotonic Scheduling) en dynamische planningsalgoritmen (EDF - Earliest Deadline First).

RMS wordt gebruikt om de voorspelbaarheid van een systeem formeel te bewijzen. Deze theorie vereist preventieve prioriteitsplanning. In de RMS-theorie wordt aan elk proces vooraf een prioriteit toegewezen. Processen moeten aan de volgende voorwaarden voldoen:

* het proces moet tijdens zijn periode worden voltooid;

* processen zijn niet van elkaar afhankelijk;

* elk proces vereist bij elk interval dezelfde processortijd;

* niet-periodieke processen kennen geen strikte deadlines;

* procesonderbreking treedt op binnen een beperkte tijd.

Processen worden uitgevoerd volgens prioriteiten. RMS-planning geeft prioriteit aan taken met de kortste doorlooptijden.

In EDF wordt de prioriteit dynamisch toegewezen en wordt de hoogste prioriteit gegeven aan het proces met de minste uitvoeringstijd. Bij hoge systeembelastingen heeft EDF voordelen ten opzichte van RMS.

Alle realtime systemen vereisen een deadline-gedreven planningsbeleid. Deze aanpak is echter in ontwikkeling.

Meestal gebruikt een RTOS planning met prioriteiten die de service onderbreken, die is gebaseerd op RMS. Voorkoop is een integraal onderdeel van een RTOS omdat: in een realtime systeem moeten er garanties zijn dat een gebeurtenis met een hoge prioriteit eerder wordt verwerkt dan een gebeurtenis met een lagere prioriteit. Dit alles leidt ertoe dat de RTOS niet alleen een planningsmechanisme nodig heeft op basis van prioriteiten die de service onderbreken, maar ook een geschikt mechanisme voor het beheren van onderbrekingen. Bovendien moet de RTOS interrupts kunnen uitschakelen wanneer kritieke code moet worden uitgevoerd die niet kan worden onderbroken. Interrupt verwerkingstijden moeten tot een minimum worden beperkt.

De RTOS moet een goed ontwikkeld stelsel van prioriteiten hebben. Ten eerste is dit vereist omdat het systeem zelf kan worden gezien als een set servertoepassingen die is onderverdeeld in threads, en er moeten verschillende niveaus met hoge prioriteit worden toegewezen. systeemprocessen en stromen. Ten tweede, in complexe toepassingen het is noodzakelijk om alle realtime streams op verschillende prioriteitsniveaus te plaatsen, en niet-realtime streams op één niveau (lager dan alle realtime streams). In dit geval kunnen niet-realtime stromen worden verwerkt in de round-robin scheduling (RRS) -modus, waarbij elk proces wordt voorzien van een processortijdplak, en wanneer het kwantum eindigt, wordt de procescontext opgeslagen en wordt het aan het einde van de rij geplaatst. Veel RTOS's gebruiken de RRS voor het plannen van taken op één niveau. Prioriteitsniveau 0 wordt meestal gebruikt voor inactieve modus.

Er zijn twee dwingende problemen die moeten worden aangepakt met op prioriteiten gebaseerde planning:

* zorgdragen voor de uitvoering van het proces met de hoogste prioriteit,

* Voorkom omkering van prioriteiten wanneer taken met hoge prioriteiten wachten op middelen die zijn vastgelegd door taken met lagere prioriteiten.

Om prioriteitinversie in een RTOS tegen te gaan, wordt vaak een gebruikt, maar dit moet worden gedaan met op RMS gebaseerde planning, aangezien de prioriteiten dynamisch worden.

1.5 Geheugen

Zoals hierboven vermeld, hangt de vertraging voor het omschakelen van de threadcontext rechtstreeks af van de geheugenconfiguratie, d.w.z. van het geheugenbeschermingsmodel. Er zijn vier meest voorkomende geheugenbeschermingsmodellen in RTOS:

* Model zonder bescherming - de adresruimten van het systeem en de gebruiker zijn niet van elkaar beveiligd, er worden twee geheugensegmenten gebruikt: voor code en voor gegevens, terwijl er geen geheugenbeheer nodig is van het systeem, geen MMU-beheer (geheugenbeheereenheid vereist) virtueel geheugen);

* Systeem-/gebruikersbeveiligingsmodel - de systeemadresruimte is beschermd tegen de gebruikersadresruimte, het systeem en de gebruikersprocessen worden uitgevoerd in een gedeelde virtuele adresruimte en een MMU is vereist. Bescherming wordt geboden door een paginabeveiligingsmechanisme. Er wordt onderscheid gemaakt tussen systeem- en gebruikerspagina's. Gebruikersapplicaties zijn op geen enkele manier tegen elkaar beschermd. De processor staat in de supervisormodus als het huidige segment zich op niveau 0, 1 of 2 bevindt. Als het segmentniveau 3 is, staat de processor in de gebruikersmodus. Dit model vereist vier segmenten: twee segmenten op niveau 0 (voor code en gegevens) en twee segmenten op niveau 3. Het pagingmechanisme voegt geen overhead toe omdat het geen overhead heeft. de beveiliging wordt gelijktijdig gecontroleerd met de adresvertaling die door de MMU wordt uitgevoerd; het besturingssysteem heeft geen geheugenbeheer nodig.

* Gebruikers-/gebruikersbeveiligingsmodel - voegt beveiliging tussen gebruikersprocessen toe aan het systeem-/gebruikersmodel, vereist een MMU. Net als in het vorige model wordt een paginabeveiligingsmechanisme gebruikt. Alle pagina's zijn gemarkeerd als bevoorrecht, met uitzondering van pagina's in het huidige proces, die zijn gemarkeerd als gebruikerspagina's. Een actieve thread heeft dus geen toegang buiten zijn adresruimte. Het besturingssysteem is verantwoordelijk voor het bijwerken van de privilegevlag voor: specifieke pagina in de paginatabel bij het omschakelen van het proces. Net als in het vorige model worden vier segmenten gebruikt.

* Virtueel geheugenbeschermingsmodel - elk proces draait in zijn eigen virtueel geheugen, een MMU is vereist. Elk proces heeft zijn eigen segmenten en dus zijn eigen descriptortabel. Het besturingssysteem is verantwoordelijk voor het onderhouden van descriptortabellen. De adresseerbare ruimte kan groter zijn dan het fysieke geheugen als geheugenoproep wordt gebruikt in combinatie met oproepen. In realtime-systemen wordt paging echter meestal niet gebruikt vanwege de onvoorspelbaarheid ervan. Om dit probleem op te lossen beschikbaar geheugen is opgedeeld in een vast aantal logische adresruimten van gelijke grootte. Het aantal gelijktijdig lopende processen op het systeem wordt beperkt.

Een fundamentele vereiste voor geheugen in een real-time systeem is dat de toegangstijd tot het geheugen beperkt (of, met andere woorden, voorspelbaar) moet zijn. Een direct gevolg is het verbod op het gebruik van de on-demand page-calling techniek (swapping van schijf) voor realtime processen. Daarom moeten systemen die een virtueel geheugenmechanisme bieden, het proces kunnen blokkeren in werkgeheugen zonder ruilen toe te staan. Paging is dus niet toegestaan ​​in een RTOS omdat het onvoorspelbaar is.

Als paging wordt ondersteund, moet de bijbehorende toewijzing van pagina's aan fysieke adressen deel uitmaken van de procescontext. Anders treedt er opnieuw onvoorspelbaarheid op, onaanvaardbaar voor RTOS.

Voor processen die dat niet zijn processen van harde real-time is, is het mogelijk om het mechanisme van dynamische geheugentoewijzing te gebruiken, maar in dit geval moet de RTOS de verwerking van een time-out voor een geheugenverzoek ondersteunen, d.w.z. beperking van voorspelbare latentie.

In conventionele besturingssystemen, wanneer het geheugensegmentatiemechanisme wordt gebruikt om fragmentatie tegen te gaan, is de verdichtingsprocedure post-vuilnisophaling. Deze benadering is echter niet van toepassing in een realtime omgeving, aangezien tijdens het verdichten kunnen de verplaatste taken niet worden uitgevoerd, wat leidt tot onvoorspelbaarheid van het systeem. Dit is het belangrijkste probleem van de toepasbaarheid van de objectgeoriënteerde benadering op real-time systemen. Totdat het verdichtingsprobleem is opgelost, zullen C++ en JAVA niet de beste zijn de beste keuze voor harde real-time systemen.

Harde realtime-systemen gebruiken doorgaans statische geheugentoewijzing. In zachte real-time systemen is dynamische geheugentoewijzing mogelijk, zonder virtueel geheugen en zonder verdichting.

1.6 Onderbrekingen

Bij het beschrijven van interruptcontrole worden doorgaans twee procedures onderscheiden, namelijk:

* interruptserviceroutine (ISR) - een programma op laag niveau in de kernel met beperkte systeemaanroepen,

* interruptservicethread (IST) - een thread op toepassingsniveau die de interrupt beheert, met toegang tot alle systeemaanroepen.

Doorgaans worden ISR's geïmplementeerd door de hardwarefabrikant en voeren apparaatstuurprogramma's de interruptcontrole uit met behulp van de IST. Interrupt-verwerkingsthreads werken als elke andere thread en gebruiken hetzelfde prioriteitssysteem. Dit betekent dat de systeemontwerper de IST een lagere prioriteit kan geven dan de prioriteit van de toepassingsthread.

1.7 Klokken en timers

RTOS gebruikt verschillende diensten tijd. Het besturingssysteem houdt de huidige tijd bij, start taken en threads op een bepaald tijdstip en pauzeert ze met bepaalde tussenpozen. RTOS tijddiensten gebruiken een realtime klok. Zeer nauwkeurige hardwareklokken worden vaak gebruikt. Timers worden gemaakt om tijdsintervallen te tellen op basis van de realtime klok.

CPU-uren worden bepaald voor elk proces en elke thread. Op basis van deze klok worden timers gemaakt die de tijd meten die wordt overschreden door een proces of thread, zodat u softwarefouten of fouten dynamisch kunt detecteren bij het berekenen van de maximaal mogelijke uitvoeringstijd.

In zeer betrouwbare, tijdkritische systemen is het belangrijk om situaties te identificeren waarin een taak de maximaal mogelijke uitvoeringstijd overschrijdt. in dit geval kan de werking van het systeem de aanvaardbare responstijd overschrijden. Met de runtime-klok kunt u het optreden van overschrijdingen identificeren en de juiste foutafhandeling activeren.

De meeste RTOS werken met relatieve tijd. Er gebeurt iets "voor" en "na" een andere gebeurtenis. Een volledig gebeurtenisgestuurd systeem vereist een ticker omdat: er is geen tijd om te snijden. Als je echter tijdstempels nodig hebt voor sommige evenementen of een systeemoproep nodig hebt zoals "wacht een seconde", dan heb je een klokgenerator en / of timer nodig.

Synchronisatie in RTOS wordt uitgevoerd met behulp van het mechanisme van blokkeren (of wachten) totdat een bepaalde gebeurtenis plaatsvindt. Absolute tijd wordt niet gebruikt.

Realisaties in RTOS van andere conceptuele abstracties zijn vergelijkbaar met hun implementaties in traditionele OS.

2. Normen van realtime besturingssystemen

2.1 POSIX-standaard

Grote verschillen in RTOS-specificaties en het enorme aantal bestaande microcontrollers benadrukken het probleem van standaardisatie in real-time systemen.

De vroegste en meest wijdverbreide RTOS-standaard is POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). De originele versie van de POSIX-standaard verscheen in 1990 en was bedoeld voor UNIX-systemen, waarvan de eerste versies in de jaren 70 van de vorige eeuw verschenen. De POSIX-specificatie definieert een standaardmechanisme voor interactie tussen een applicatie en een besturingssysteem en omvat momenteel een set van meer dan 30 standaarden. Voor RTOS zijn er zeven het belangrijkst (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), maar alleen de eerste drie hebben brede ondersteuning gekregen in commerciële besturingssystemen.

Ondanks de duidelijk verouderde bepalingen van de POSIX-standaard en de grote vraag naar standaardisatie-updates voor RTOS, is er geen merkbare vooruitgang in deze richting.

De POSIX-standaard is gemaakt als een standaard service-interface voor het besturingssysteem. Deze standaard maakt het mogelijk om draagbare applicaties te maken. Vervolgens is deze standaard uitgebreid met features van de realtime mode.

De POSIX-specificatie definieert een standaardmechanisme voor communicatie tussen een applicatie en een besturingssysteem. Opgemerkt moet worden dat de POSIX-standaard nauw verwant is aan het Unix-besturingssysteem; desalniettemin proberen de ontwikkelaars van veel RTOS deze standaard na te leven.

Naleving van de POSIX-standaard voor het besturingssysteem en het hardwareplatform moet worden gecertificeerd door er testsuites op uit te voeren. Als het besturingssysteem echter niet Unix-achtig is, wordt het een ontmoedigende taak om aan deze vereiste te voldoen. Testsuites bestaan ​​alleen voor POSIX 1003.1a. Omdat de POSIX-structuur een verzameling optionele functies is, kunnen OS-leveranciers slechts een subset van de standaardinterface implementeren en nog steeds praten over POSIX-compatibele systemen.

Hoewel de POSIX-standaard voortkwam uit Unix, raakt het de onderliggende abstracties van besturingssystemen en zijn realtime-extensies van toepassing op alle RTOS.

De POSIX-standaard wordt nu beschouwd als een familie van verwante standaarden: IEEE Std 1003.n (waarbij n een getal is).

2.2 DO-178B Standaard

De DO-178B-standaard is gemaakt door de Radio Technical Commission for Aeronautics (RTCA) voor de ontwikkeling van software (SW) voor vliegtuigsystemen in de lucht.

De eerste versie werd in 1982 aangenomen, de tweede (DO-178A) - in 1985, de huidige DO-178B - in 1992. De goedkeuring van een nieuwe versie, DO-178C, wordt voorbereid. De standaard voorziet in vijf niveaus van storingsernst, en voor elk daarvan is een set van softwarevereisten gedefinieerd, die de werking van het gehele systeem als geheel in het geval van storingen moeten garanderen. dit niveau ernst

Deze norm definieert de volgende certificeringsniveaus:

* A (catastrofaal),

* B (gevaarlijk),

* C (essentieel),

* D (niet essentieel)

* E (niet beïnvloedend).

Totdat aan alle strenge eisen van deze norm is voldaan, zullen beveiligingsgerelateerde computersystemen nooit de lucht in gaan.

2.3 ARINC-653 standaard

ARINC-653 (Avionics Application Software Standard Interface) is in 1997 door ARINC ontwikkeld. Deze norm definieert een universele software-interface: APEX (Application / Executive) tussen het besturingssysteem van de vliegtuigcomputer en de applicatiesoftware.

Vereisten voor de interface tussen de applicatiesoftware en de besturingssysteemservices zijn zodanig gedefinieerd dat de applicatiesoftware de verzending, communicatie en status van interne verwerkingselementen kan regelen. In 2003 werd een nieuwe editie van deze standaard aangenomen. ARINC-653 introduceert partitionering van virtuele machine-architectuur als een van de basisvereisten voor een RTOS in de luchtvaart.

2.4 OSEK-standaard.

De OSEK/VDX-standaard is een combinatie van standaarden die oorspronkelijk zijn ontwikkeld in twee afzonderlijke consortia, die later zijn samengevoegd. OSEK ontleent zijn naam aan het Duitse acroniem voor een consortium dat de toonaangevende Duitse autofabrikanten BMW, Bosch, Daimler Benz (nu Daimler Chrysler), Opel, Siemens en Volkswagen omvatte, evenals de Universiteit van Karlsruhe, Duitsland. Het VDX-project (Vehicle Distributed eXecutive) werd gezamenlijk ontwikkeld door de Franse bedrijven PSA en Renault. De OSEK- en VDX-teams fuseerden in 1994.

Het OSEK / VDX-project was oorspronkelijk bedoeld om een ​​open OS-architectuurstandaard en een API-standaard te ontwikkelen voor systemen die worden gebruikt in de auto-industrie. De ontwikkelde standaard bleek echter abstracter en beperkt zich niet alleen tot gebruik in de auto-industrie.

De OSEK / VDX-standaard bestaat uit drie delen - de standaard voor het besturingssysteem (OS), communicatie standaard(COM) en standaard voor netbeheerder (NM). Naast deze standaarden is er een implementatietaal (OIL) gedefinieerd. Het eerste onderdeel van de OSEK-standaard is de OS-standaard, dus de OSEK-standaard wordt vaak aangezien voor een RTOS-standaard. Hoewel het besturingssysteem een ​​groot deel van deze standaard uitmaakt, ligt de kracht ervan in de integratie van al zijn componenten.

2.5 Veiligheidsnormen

In verband met de standaarden voor RTOS is het vermeldenswaard de bekende Trusted Computer System Evaluation Criteria (TCSEC) standaard. Deze standaard is ontwikkeld door het Amerikaanse Ministerie van Defensie en staat ook wel bekend als het Orange Book (vanwege de kleur van de omslag).

In een aantal andere landen zijn vergelijkbare criteria ontwikkeld, op basis waarvan de internationale standaard "Common Criteria for IT Security Evaluation" (hierna simpelweg de Common Criteria genoemd) (Common Criteria for IT Security Evaluation, ISO/IEC 15408) is gemaakt.

Het Oranje Boek somt zeven beschermingsniveaus op:

* A1 - geverifieerde ontwikkeling. Dit niveau vereist formele verificatiemethoden om ervoor te zorgen dat beveiligingsmaatregelen gevoelige en andere gevoelige informatie beschermen.

* B3 - beveiligingsdomeinen. Dit niveau is ontworpen om systemen te beschermen tegen ervaren programmeurs.

* B2 - gestructureerde verdediging. Hackers mogen geen toegang krijgen tot een systeem met dit beschermingsniveau.

* B1 - verplichte toegangscontrole. De bescherming van dit niveau kan misschien worden overwonnen door een ervaren hacker, maar niet door gewone gebruikers.

* C2 - discretionaire toegangscontrole. Niveau C2 beschermt inlogprocedures, stelt u in staat beveiligingsgebeurtenissen te bewaken en bronnen te isoleren.

* C1 - selectieve verdediging. Deze laag geeft gebruikers de mogelijkheid om persoonlijke of projectinformatie te beschermen door toegangscontroles te installeren.

* D - minimale bescherming. Deze lagere beschermingslaag is gereserveerd voor systemen die zijn getest maar niet kunnen voldoen aan de hogere eisen.

3. Korte kenmerken van de meest voorkomende realtime besturingssystemen

3.1 VxWorks

De real-time besturingssystemen van de VxWorks-familie van WindRiver Systems Corporation zijn bedoeld voor de ontwikkeling van software (software) voor embedded computers die werken in harde real-time systemen.

Het VxWorks-besturingssysteem heeft een client-server-architectuur en is gebouwd in overeenstemming met microkernel-technologie, d.w.z. het laagste uninterruptible kernel-niveau (WIND Microkernel) zorgt alleen voor taakplanning en communicatie- / synchronisatiebeheer. Alle andere functionaliteit van de werkende kernel - geheugenbeheer, I / O, enzovoort - wordt op een hoger niveau geboden en via processen geïmplementeerd. Dit zorgt voor de snelheid en determinisme van de kernel, evenals de schaalbaarheid van het systeem.

VxWorks kan worden gekoppeld voor kleine embedded systemen met ernstige geheugenbeperkingen, maar ook voor complexe systemen met geavanceerde functionaliteit.

Hoewel het VxWorks-systeem configureerbaar is, d.w.z. individuele modules kunnen statisch of dynamisch worden geladen, er kan niet worden gezegd dat het een componentgebaseerde benadering gebruikt. Alle modules zijn gebouwd op een basiskernel en zijn zo ontworpen dat ze niet in andere omgevingen kunnen worden gebruikt.

3.2 QNX Neutrino RTOS

Het QNX Neutrino Real-time Operating System (RTOS) van QNX Software Systems is een microkernel-besturingssysteem dat multitasking met prioriteit biedt.

QNX Neutrino RTOS heeft een client-server-architectuur. In de QNX Neutrino-omgeving draait elk stuurprogramma, elke toepassing, elk protocol en elk bestandssysteem buiten de kernel, in een beschermde adresruimte. Als een onderdeel faalt, kan het automatisch opnieuw opstarten zonder andere onderdelen of de kernel te beïnvloeden. Hoewel het QNX-systeem configureerbaar is, d.w.z. individuele modules kunnen statisch of dynamisch worden geladen, er kan niet worden gezegd dat het een componentgebaseerde benadering gebruikt. Alle modules vertrouwen op de onderliggende kernel en zijn zo ontworpen dat ze niet in andere omgevingen kunnen worden gebruikt.

QNX Neutrino RTOS bestaat uit een kernel, een procesmanager en geavanceerde services op gebruikersniveau. Als een echt microkernel-besturingssysteem implementeert QNX Neutrino RTOS alleen de meest fundamentele services in de OS-kernel, zoals berichten, signalen, timers, threadplanning, synchronisatieobjecten. Alle andere OS-services, stuurprogramma's en toepassingen worden uitgevoerd als afzonderlijke processen die communiceren via synchrone berichtenuitwisseling.

QNX Neutrino RTOS heeft snelle interrupt-verwerkingstijden, snelle contextwisseling. Prioriteitsinversie wordt overwonnen met gedistribueerde prioriteitsovererving. Vereenvoudigde modellering van real-time activiteiten wordt gedaan door middel van synchrone berichten. Geneste interrupts en een vaste bovengrens voor de afhandelingstijden van interrupts zorgen ervoor dat interrupts met hoge prioriteit snel en op een voorspelbaar tijdstip worden verwerkt.

3.3 RTEMS

RTEMS (Real-Time Executive for Multiprocessor Systems) is een niet-commercieel realtime besturingssysteem voor diepe embedded systemen.

De systeemontwikkelaar is het bedrijf OAR (On-Line Applications Research Corporation, VS). Het systeem is gemaakt in opdracht van het Amerikaanse ministerie van Defensie voor gebruik in raketcontrolesystemen. Het systeem wordt ontwikkeld voor open source multiprocessor-systemen in tegenstelling tot vergelijkbare closed source-systemen. Het systeem is ontworpen voor MS-Windows- en Unix-platforms (GNU / Linux, FreeBSD, Solaris, MacOS X).

De kern van RTEMS biedt de basisfunctionaliteit van realtime systemen. Deze kansen omvatten:

* multitasking-verwerking;

* werken in homogene en heterogene systemen;

* evenementgestuurde planning op basis van prioriteiten;

* plannen in een monotone snelheid;

* taakinteractie en synchronisatie;

* prioriteit overerving;

* controle van de responsonderbreking;

* toewijzing van dynamisch geheugen;

* configureren van het systeem voor geautoriseerde gebruikers;

* overdraagbaarheid naar veel doelplatforms.

De RTOS is gebonden aan de hardware met behulp van een speciale bibliotheek van BSP (board support package) subroutines en gespecialiseerde subroutines voor verschillende architecturen.

RTEMS ondersteunt geen dynamisch laden van applicaties en modules, dus wordt het gebruikt in embedded systemen waar frequente softwareaanpassingen niet worden verwacht.

RTEMS RTOS biedt nogal zwakke ondersteuning voor bestandssystemen, wat de reikwijdte van de mogelijke toepassing ervan op het gebied van gecentraliseerde gegevensverzameling en opslagsystemen met standaard middelen op hoog niveau beperkt.

3.4 ChorusOS

Het ChorusOS-besturingssysteem is een schaalbaar ingebed besturingssysteem dat veel wordt gebruikt in de telecommunicatie-industrie. Dit merk wordt momenteel ontwikkeld en gedistribueerd door Sun Microsystems Corporation.

Sun Microsystems biedt de Sun Embedded Workshop-ontwikkelomgeving om ChorusOS te bouwen en te implementeren op specifieke telecomplatforms. Sun Microsystems Corp. introduceert ChorusOS als een embedded framework voor Sun's Service-Driven Network. Gecombineerd met een breed scala aan diensten, volledige software- en hardware-integratie, eenvoudig beheer en ondersteuning voor Java-technologie die is gericht op telecommunicatiebehoeften, stelt ChorusOS u in staat om efficiënt nieuwe mogelijkheden en toepassingen in te zetten met behoud van de betrouwbaarheid en functionaliteit van de hedendaagse netwerken.

ChorusOS ondersteunt een breed scala aan telecommunicatieprotocollen, legacy-applicaties, realtime-applicaties en Java-technologie op een enkel hardwareplatform.

ChorusOS simuleert drie soorten toepassingen:

* POSIX-processen vormen de meerderheid van ChorusOS-applicaties, deze applicaties hebben toegang tot de POSIX API, verschillende POSIX-achtige uitgebreide API's en een klein aantal beperkte microkernel-systeemaanroepen;

* ChorusOS-acteurs - Deze applicaties draaien bovenop de microkernel en zijn beperkt tot de microkernel-API, actoren omvatten stuurprogramma's, subsysteemgebeurtenissen en protocolstacks;

* Legacy ChorusOS-apps worden ondersteund voor compatibiliteit met apps die zijn ontwikkeld voor meer vroege versies KoorOS.

ChorusOS-architectuur is meerlagig, op componenten gebaseerd. De microkernel bevat de minimale set componenten die nodig zijn voor het functioneren van het besturingssysteem. De grootte van het residente deel van de kernel is 10Kb.

ChorusOS definieert een actor als de download-eenheid voor een applicatie. Het dient ook als de eenheid van inkapseling voor het matchen van alle systeembronnen gebruikt door de toepassing en threads die in de actor worden uitgevoerd. Voorbeelden van dergelijke bronnen zijn threads, geheugenregio's en interactie-eindpunten.

ChorusOS 5.0 vormt de kern van werkomgeving Solaris en ondersteunt de volgende doelplatforms:

* UltraSPARC II (CP1500 en CP20x0);

* Intel x86, Pentium;

* Motorola PowerPC 750 en 74x0 processorfamilie (mpc7xx);

* Motorola PowerQUICC I (mpc8xx) en PowerQUICC II (mpc8260) (microcontrollers).

3.5 RTX (realtime-extensie voor Windows NT)

Windows NT is ontworpen en voornamelijk gebruikt als een algemeen besturingssysteem. Er is echter een duidelijke tendens in de real-time markt om Windows NT en zijn extensies in gespecialiseerde systemen te gebruiken. Hier zijn verschillende redenen voor:

* Windows NT is ontworpen volgens moderne technologieën voor het bouwen van besturingssystemen,

* de Application Programming Interface (API) voor Win32 is de de facto standaard geworden voor programmeurs,

* de grafische gebruikersinterface (GUI) is zo populair geworden dat andere besturingssystemen proberen een vergelijkbare interface te bieden,

* een groot aantal apparaatstuurprogramma's beschikbaar,

* veel krachtige geïntegreerde ontwikkelomgevingen beschikbaar.

Op zichzelf is Windows NT niet geschikt voor gebruik in real-time systemen, omdat het te weinig prioriteitsniveaus heeft en er geen mechanisme is om prioriteiten over te nemen. Om de onderbrekingsverwerkingstijd (ISR) te minimaliseren, heeft Windows NT het concept van uitgestelde procedureaanroep (DPC) geïntroduceerd, welke prioriteit hoger is dan de prioriteit van gebruikers- en systeemthreads, terwijl alle DPC's dezelfde prioriteit hebben. Dit zorgt ervoor dat alle DPC's in de wachtrij worden geplaatst bij de FIFO, en een interrupt-DPC op hoog niveau kan alleen worden uitgevoerd nadat alle andere DPC's ervoor zijn uitgevoerd. Deze situaties leiden tot onvoorspelbare responstijden die niet compatibel zijn met de RTOS-vereisten. Geheugenbeheer in Windows NT is gebaseerd op het virtuele geheugenmechanisme. Dit omvat geheugenbescherming, adresvertaling en paging, wat niet acceptabel is in een RTOS.

Uitbreiding van realtime RTX (Real-Time Extension) voor Windows NT (ontwikkeld door VenturCom Corporation) stelt u in staat applicaties te maken voor snelle controle met een deterministische responstijd op externe gebeurtenissen.

RTX is diep geïntegreerd in de Windows NT-kernel en gebruikt windows-service NT en API WIN32. De real-time kernel (nucleus) is geïntegreerd in de NT-kernel (kernel). Elk RTX-proces wordt uitgevoerd als een NT-kernelstuurprogramma en de processen zijn niet tegen elkaar beschermd. Deze implementatie leidt tot snelle contextwisselingen, maar is vanuit privacyoogpunt onveilig.

3.6 INtime (Windows NT Realtime-extensie)

INtime is een realtime Windows-extensie die is ontwikkeld door Radisys Corporation en momenteel wordt onderhouden door TenAsys.

INtime combineert de mogelijkheden van een harde realtime RTOS met standaard Windows-besturingssystemen, waaronder Windows XP, Windows XP Embedded, Windows 2000, Windows NT en Windows NT Embedded, zonder dat er extra hardware nodig is. INtime is speciaal ontworpen voor de x86-processorarchitectuur.

INtime is, in tegenstelling tot RTX, losjes gerelateerd aan NT. De INtime-architectuur is gebaseerd op het hardwaretaakmechanisme van de Intel-processor. Het blijkt dat twee cores op dezelfde hardware draaien. Omdat ze dezelfde hardware delen, waren enkele aanpassingen aan de NT HAL vereist. Deze aanpak helpt de runtime- en geheugenruimte te beschermen en los te koppelen van Windows. Binnen INtime heeft elk aanvraagproces zijn eigen adresruimte. Bovendien draaien de kernel en applicaties op verschillende prioriteitsniveaus om ze tegen elkaar te beschermen.

INtime vertoont voorspelbaar gedrag, maar door de complexe architectuur kan het systeem geen goede prestaties leveren. Vanwege segmentatiebeperkingen is INtime niet geschikt voor alle realtime systemen.

3.7 LynxOS

Het LynxOS RTOS-besturingssysteem (LynuxWorks, Inc.) is een hard realtime besturingssysteem dat is ontworpen voor gespecialiseerde en telecommunicatieapparatuur. Dit besturingssysteem is volledig deterministisch en compatibel met POSIX, UNIX en Linux. LynxOS wordt ook gebruikt in complexe beveiligingssystemen.

De nieuwste versie van dit merk OS, LynxOS-178 2.0, wordt door de fabrikant gekenmerkt als een commercieel besturingssysteem dat het hoge niveau van betrouwbaarheid en reactievermogen biedt dat vereist is voor embedded applicaties met speciale beveiligingseisen. LynxOS-178 2.0 implementeert ondersteuning voor de APEX (Application / EXecutive) interface van de ARINC-653-specificatie. Hiermee voldoet dit besturingssysteem aan de strengste eisen voor de beveiliging en betrouwbaarheid van elektronische systemen voor de militaire en burgerluchtvaart. Het LynxOS-178 2.0-systeem voldoet volledig aan de Level A-bepalingen van de DO-178B-specificatie.

De LynxOS-178 2.0 RTOS voldoet aan POSIX en ARINC-653, evenals DO-178B, wat betekent dat het de draagbaarheid van de applicatiecode van embedded systemen, herbruikbaarheid van gemaakte programma's en naleving van de strengste besturingssysteemregelgeving met verhoogde beveiligingsvereisten garandeert . Door LynxOS-178 2.0 te gebruiken, kunt u alle eerder gecertificeerde programma's en ontwikkelingen gebruiken.

3.8 MicroWare OS-9

Het real-time besturingssysteem van Microware System OS-9 is een multitasking, multi-user besturingssysteem voor real-time embedded toepassingen. Dit systeem is ontworpen om te werken in systemen zoals mobiele telecommunicatieapparatuur, ingebouwde internettoegangsterminals, interactieve digitale settopboxen.

OS-9 draait op processors als Motorola 68K, ARM / StrongARM, Intel IXP1200 Network Processor, MIPS, PowerPC, Hitachi SuperH, x86 of Intel Pentium, Intel IXC1100 XScale.

De OS-9-kernel is schaalbaar, volledig preventief, ondersteunt tot 65535 processen, biedt 65535 prioriteitsniveaus en ondersteunt tot 255 gebruikers. De OS-9-kernel bevat meer dan 90 systeemaanroepen die het mogelijk maken om de dynamische verzendingsmodus, geheugentoewijzing, interprocessorcommunicatie, enz. - tot het beheer van de modus van zuinig stroomverbruik die in de OS-kernel is ingebouwd.

Microware Corporation was een van de eersten die Java licentiëerde voor embedded toepassingen en is een leider in het aanbieden van een verscheidenheid aan OS-9-tools en -toepassingen voor een verscheidenheid aan apparaatklassen.

Als geïntegreerde ontwikkelomgeving voor meerdere toepassingen voor OS-9 heeft Microware Corporation de Hawk-omgeving ontwikkeld, die op het MS Windows NT-platform draait.

3.9 OSE RTOS

Het real-time besturingssysteem OSE RTOS, ontwikkeld door ENEA Corporation, heeft een prioriteitsplanningskernel. Deze kernel is sterk geoptimaliseerd voor hoge prestaties en is compact genoeg voor gebruik in embedded systemen. OSE heeft een berichtgestuurde architectuur met eenvoudige systeemaanroepen. OSE-berichten dienen als conceptuele gateway in gedistribueerde embedded systemen met meerdere processors. Taken sturen berichten rechtstreeks naar elkaar via het besturingssysteem zonder de ondersteuning van wachtrijen, mailboxen of andere tussenliggende mechanismen. OSE RTOS ondersteunt swapping, duplicatie, dynamische code-updates en vele communicatieprotocollen.

De OSE RTOS-architectuur is gebaseerd op een gelaagd model.

De uitvoeringseenheid in OSE RTOS is een proces. Processen kunnen worden gegroepeerd in een blok, dat hun eigen geheugenpool kan hebben. In de OSE RTOS-kernel hoort de adresruimte bij een segment dat een of meer blokken kan bevatten. Het toewijzen van blokken aan segmenten en het toewijzen van pools aan regio's maakt het mogelijk om te bereiken volledige bescherming geheugen en programma-isolatie. Blokken en zwembaden kunnen in een of meer segmenten worden geplaatst.

In OSE RTOS wordt processcheiding opgevat als dynamisch en statisch: statische processen worden gecreëerd door de kernel wanneer het systeem opstart en bestaan ​​gedurende de hele levensduur van het systeem, dynamische processen worden gecreëerd en vernietigd tijdens de uitvoering.

3.10 Windows CE

De Windows CE RTOS is modulair met een kleine kern en optionele modules die als onafhankelijke processen draaien. Planning in Windows CE heeft prioriteit. Het beschermen van de kernel en processen tegen elkaar wordt ondersteund. Bovendien is een werkingsmodus mogelijk wanneer er geen bescherming is tussen processen en de kernel. Opgemerkt moet worden dat interrupts worden behandeld als threads en prioriteitsniveaus voor threads hebben. Windows CE ondersteunt ook vezels, dit zijn threads die niet door de kernel worden beheerd. Elke thread wordt uitgevoerd in de context van de thread die deze heeft gemaakt; ze kunnen worden gebruikt om een ​​planner in een thread te maken. Dergelijke threads worden gebruikt in exotische of legacy-applicaties, maar zijn onbruikbaar in realtime-systemen.

Windows CE heeft een fysieke geheugenlimiet van 512 MB. Microsoft heeft deze beperking ingevoerd zodat Windows CE op een groot aantal ingebouwde processors kan draaien zonder compatibiliteitsproblemen, aangezien sommige van deze processors 512 MB fysiek geheugen aankunnen. Windows CE implementeert paging van virtueel geheugen. Het paginaformaat is platformafhankelijk, maar waar mogelijk wordt 4KB gebruikt. Het is mogelijk om paging uit te schakelen, wat belangrijk is voor realtime systemen. In deze modus wordt de module volledig in het geheugen geladen voordat deze wordt uitgevoerd. Dan heeft paging geen invloed op de uitvoering van de applicatie.

In tegenstelling tot andere RTOS'en ondersteunt Windows CE generieke wachtfuncties voor verschillende typen objecten (mutexen, semaforen, gebeurtenissen, processen en threads). Het voordeel van dergelijke functies is dat je veel objecten tegelijk kunt verwachten totdat een van hen een signaal geeft. Kritische secties kunnen slechts binnen één proces worden gebruikt. Computationele semaforen en mutexen kunnen zowel binnen één proces als tussen processen worden gebruikt. Windows CE gebruikt prioriteitsovererving om het probleem van prioriteitinversie te voorkomen.

3.11 Nucleus RTOS

Het Nucleus-besturingssysteem, ontwikkeld door Accelerated Technology Corporation, is ontworpen voor embedded toepassingen.

Nucleus is systeemoverschrijdend, d.w.z. een softwareproduct wordt gemaakt op het ene software- en hardwareplatform en uitgevoerd op een ander.

De Nucleus RTOS wordt geleverd met open source software.

De kern van de Nucleus RTOS, Nucleus PLUS, is multitasking, draagbaar en schaalbaar. De kernel is geïmplementeerd als een bibliotheek met functies in de C-taal.

Nucleus PLUS biedt mogelijkheden zoals taakinteractiebeheer ( brievenbussen, wachtrijen, pijplijnen, semaforen, gebeurtenissen, signalen), evenals geheugenbeheer, timers, interrupts. De planning van taken wordt uitgevoerd op basis van prioriteiten, evenals volgens het FIFO-algoritme.

Bij het uitvoeren van een systeemaanroep kan de uitvoering van de taak worden onderbroken voor onbepaalde tijd, Aan interval instellen, of niet te pauzeren. Alle objecten in het systeem kunnen dynamisch worden aangemaakt en verwijderd.

Conclusie

Gedurende vele jaren worden toepassingen op basis van het realtime besturingssysteem gebruikt in embedded systemen voor speciale doeleinden, en meer recentelijk zijn ze gebruikt in alles, van besturingssystemen aan boord van vliegtuigen tot huishoudelijke apparaten.

De belangrijkste eigenschap van real-time systemen is de voorspelbaarheid van de temporele reacties van het systeem op externe gebeurtenissen. Alleen op basis van deze eigenschap kunnen we praten over de consistentie en validiteit van beslissingen die zijn ingebed in een specifiek realtime besturingssysteem.

Realtime systemen moeten reageren op: externe parameters input en creëer nieuwe outputresultaten in een beperkte tijd. De responstijd moet worden beperkt. Zeer lange reactietijden kunnen ervoor zorgen dat realtime systemen uitvallen.

Het lijdt geen twijfel dat de meeste traditionele realtime besturingssystemen zijn ontworpen met één centrale verwerkingseenheid op één bord in gedachten. Ondersteuning voor multiprocessorsystemen is tegenwoordig steeds meer vereist.

Het is duidelijk dat besturingssystemen met een monolithische architectuur, vanwege hun focus op specifieke processorplatforms en de aard van interactie met de kernel, nauwelijks kunnen worden gebruikt als relatief universele real-time besturingssystemen voor systemen met hoge beschikbaarheid.

Moderne realtime besturingssystemen zijn gebaseerd op nieuwe architecturale benaderingen, aangevuld met tools voor het ontwikkelen van applicatiesystemen waarmee ze in korte tijd kunnen worden gecreëerd met beste optreden Bovendien hebben degenen die zijn gemaakt op basis van een microkernel een aantal voordelen ten opzichte van een monolithische architectuur, en in combinatie met een objectgeoriënteerde benadering zorgen ze ervoor dat het systeem hardware-onafhankelijk wordt en snel reageert op externe gebeurtenissen.

En het is in het licht van de voorspelbaarheid in de tijd dat een RTOS zorgvuldig moet worden ontworpen om realtime-applicaties te ondersteunen.

Bibliografische lijst

1. Burdonov I.B., Kosachev A.S., Ponomarenko V.N. Realtime besturingssystemen. Preprint: Instituut voor Systeemprogrammering, Russische Academie van Wetenschappen. Irkoetsk, 2006.

2. Olifer V.G., Oliver N.A. Netwerkbesturingssystemen: een leerboek voor universiteiten. 2e druk - St. Petersburg: Peter, 2008. - 669 p.: ill.

3.www.ru.wikipedia.org

4.www.intuit.ru

Vergelijkbare documenten

De belangrijkste kenmerken van real-time systemen, soorten architecturen. Het systeem van prioriteiten van processen (taken) en planningsalgoritmen. Fouttolerantieconcept, oorzaken van storingen. Fouttolerantie in bestaande realtime systemen (QNX Neutrino).

test, toegevoegd 03/09/2013


Classificatie van real-time systemen. Kernels en realtime besturingssystemen. Taken, processen, threads. Voor- en nadelen van streams. Eigenschappen, planning, taaksynchronisatie. Gerelateerde taken. Synchronisatie met externe gebeurtenissen.

samenvatting toegevoegd op 28-12-2007


Kenmerken, toepassingsprincipes, architectuur van harde en realtime besturingssystemen. Sequentiële programmering van real-time taken. Structuur en talen van parallel programmeren, multiprogrammeren en multitasken.

scriptie, toegevoegd 17-12-2015


besturingssysteem batchverwerking, tijddeling, realtime. Kenmerken van algoritmen voor resourcebeheer. Ondersteuning voor multiplayer-modus. Preventief en niet-preventief multitasken. Besturingssystemen en wereldwijde netwerken.

samenvatting, toegevoegd op 12/11/2011


Bekijk de vereisten van het probleemgebied. Kenmerken van taakbeheer. Realtime uitvoerende systemen. Programmeren op microprocessorniveau. Domeinmodellen en methoden. Realtime implementatie van systeemprototype.

scriptie toegevoegd 15-02-2005


Taken plannen in een realtime besturingssysteem. De belangrijkste soorten planning met betrekking tot realtime taken. Een acceptabel planningsalgoritme kiezen bij het ontwerpen van een RTS. Statische prognoses met behulp van tabellen.

test, toegevoegd op 28-05-2014


Overweging van de basisprincipes en methoden voor het ontwerpen van real-time systemen. Beschrijving van het ontwerp en de functionele kenmerken van het besturingsobject, constructie van een taakdiagram. Het kiezen van een hardware-architectuur, een model van proces-threads, een interface.

scriptie toegevoegd 19/01/2015


Algemene kenmerken van de taken voor het vastleggen van de uitvoeringstijd van programma's: uitvoering van realtime-processen, profilering. Programmeerbare intervaltimer als zeer complex systeem. Analyse van de belangrijkste functies die de standaard Windows-tijd teruggeven.

scriptie, toegevoegd 18-05-2014


Het concept en de functies van het besturingssysteem. Het belangrijkste kenmerk van real-time besturingssystemen. Werk met spreadsheets... Records filteren in MS Excel-tabel. Een aangepast autofilter installeren in de omzetlijst van goederenbewegingen.

test, toegevoegd 21-11-2013


De essentie en het principe van het besturingssysteem, de regels en voordelen van het gebruik ervan. De mogelijkheden van verschillende besturingssystemen, hun sterke en zwakke punten. Vergelijkende kenmerken van Unix- en Windows NT-systemen, hun potentieel en uitgevoerde taken.

Onderscheidende kenmerken van RTOS van OS algemeen doel

Besturingssystemen voor algemene doeleinden, met name besturingssystemen voor meerdere gebruikers zoals UNIX, zijn gericht op de optimale verdeling van computerbronnen tussen gebruikers en taken. In realtime besturingssystemen verdwijnt zo'n 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 realtime besturingssysteem altijd verband houdt met de apparatuur, met de faciliteit, met gebeurtenissen die plaatsvinden in de faciliteit. Het realtime besturingssysteem is gericht op het afhandelen van externe gebeurtenissen. Een realtime besturingssysteem kan qua gebruikersinterface vergelijkbaar zijn met een algemeen besturingssysteem, maar het is op een heel andere manier ontworpen en de toepassing van realtime besturingssystemen is altijd specifiek. Als een algemeen besturingssysteem door gebruikers (niet ontwikkelaars) doorgaans wordt gezien als een kant-en-klare set applicaties, dan dient een realtime besturingssysteem alleen als een hulpmiddel voor het creëren van een specifiek realtime hardware- en softwarecomplex. En daarom het meest brede klasse gebruikers van real-time besturingssystemen - ontwikkelaars van real-time systemen, mensen die controle- en gegevensverzamelingssystemen ontwerpen. Ontwerpen en ontwikkelen specifiek systeem realtime, de programmeur weet altijd precies welke gebeurtenissen zich in de faciliteit kunnen voordoen, kent de kritieke tijdframes voor het onderhoud van elk van deze gebeurtenissen. Het RT-systeem moet tijd hebben om te reageren op een gebeurtenis die zich in de faciliteit heeft voorgedaan binnen een tijd die kritiek is voor deze gebeurtenis. De kritieke tijd voor elke gebeurtenis wordt bepaald door het object en de gebeurtenis zelf en kan verschillen, maar de reactietijd van het systeem moet worden voorspeld (berekend) wanneer het systeem wordt gemaakt. Gebrek aan reactie op het voorspelde tijdstip wordt voor realtime systemen als een fout beschouwd. Het systeem moet kunnen reageren op gelijktijdig optredende gebeurtenissen. Zelfs als twee of meer externe gebeurtenissen tegelijkertijd plaatsvinden, moet het systeem erin slagen om op elk van hen te reageren gedurende de tijdsintervallen die cruciaal zijn voor deze gebeurtenissen.

	Realtime besturingssysteem	Besturingssysteem voor algemeen gebruik
De belangrijkste taak	Tijd om te reageren op gebeurtenissen op de apparatuur	Wijs computerbronnen optimaal toe aan gebruikers en taken
Waar is het op gericht?	Externe gebeurtenissen afhandelen	Gebruikersacties afhandelen
Hoe is het gepositioneerd?	Een tool voor het creëren van een specifiek realtime hardware- en softwarecomplex	Door de gebruiker gezien als een verzameling kant-en-klare applicaties
Voor wie is het	Gekwalificeerde ontwikkelaar	Gemiddelde gebruiker

Harde en zachte realtime systemen

Er zijn twee soorten realtimesystemen: harde realtimesystemen en zachte realtimesystemen.

Harde real-time systemen staan ​​onder geen enkele voorwaarde vertragingen toe in de reactie van het systeem, aangezien:

• resultaten kunnen nutteloos zijn als u te laat bent
• een catastrofe kan optreden als de reactie wordt vertraagd

• de kosten van te laat komen kunnen oneindig hoog zijn.

Voorbeelden van harde real-time systemen zijn controlesystemen aan boord, noodbeveiligingssystemen, noodgebeurtenisrecorders.

Zachte realtime-systemen worden gekenmerkt door het feit dat de responsvertraging niet kritisch is, hoewel dit kan leiden tot een verhoging van de kosten van resultaten en een afname van de prestaties van het systeem als geheel, bijvoorbeeld de netwerkwerking. Als het systeem geen tijd had om het volgende ontvangen pakket te verwerken, zal dit leiden tot een time-out aan de verzendende kant en opnieuw verzenden (afhankelijk van het protocol natuurlijk). Tegelijkertijd gaan er geen data verloren, maar nemen de netwerkprestaties af. Het belangrijkste verschil tussen harde en zachte real-time systemen kan als volgt worden uitgedrukt: een hard real-time systeem zal nooit te laat reageren op een gebeurtenis, een soft real-time systeem mag niet te laat reageren op een gebeurtenis.

Besturingssysteemkernel

Kernel - het centrale deel van het besturingssysteem (OS), dat applicaties gecoördineerde toegang biedt tot computerbronnen, geheugen, externe Hardware, een extern apparaat voor het invoeren en uitvoeren van informatie, dat de commando's van de toepassingstaal vertaalt in de taal van binaire codes die de computer begrijpt. Als fundamenteel element van het besturingssysteem is de kernel de meest laag niveau abstracties voor applicatietoegang tot systeembronnen die nodig zijn voor hun werking. In de regel biedt de kernel dergelijke toegang tot de uitvoerbare processen van de corresponderende applicaties door het gebruik van communicatiemechanismen tussen processen en applicatie-aanroepen naar OS-systeemaanroepen.

Monolithische kern

De monolithische kernel biedt een rijke set hardware-abstracties. Alle delen van de monolithische kernel werken in dezelfde adresruimte. Dit is een schema van een besturingssysteem waarin alle componenten van de kernel zijn samenstellende delenéén programma, gebruik algemene structuren gegevens en communiceren met elkaar via directe procedureaanroepen. Monolithische kern - oudste manier organisatie van besturingssystemen. De meeste UNIX-systemen zijn voorbeelden van systemen met een monolithische kernel.

Waardigheid: Snelheid van werken, vereenvoudigde ontwikkeling van modules.

nadelen: Aangezien de hele kernel in dezelfde adresruimte werkt, kan een storing in een van de componenten de prestaties van het hele systeem verstoren.

Sommige oudere monolithische kernels, vooral UNIX/Linux-systemen, moesten opnieuw worden gecompileerd wanneer de hardware veranderde. De meeste moderne kernels laten toe om tijdens het draaien modules te laden die een deel van de kernelfuncties uitvoeren. In dit geval zijn de componenten van het besturingssysteem geen onafhankelijke modules, maar samenstellende delen van één groot programma dat een monolithische kernel wordt genoemd, wat een reeks procedures is, die elk elk kunnen aanroepen. Alle procedures werken in de bevoorrechte modus.

Microkernel

De microkernel biedt alleen: elementaire functies procesbeheersing en een minimale set abstracties voor het werken met apparatuur. Het meeste werk wordt gedaan via speciale aangepaste processen die services worden genoemd. Het doorslaggevende criterium voor "microkernel" is de plaatsing van alle of bijna alle drivers en modules in serviceprocessen.

Waardigheid: Bestand tegen hardwarestoringen, fouten in systeemcomponenten. Het belangrijkste voordeel van microkernel-architectuur 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 microkernel-besturingssysteem is het mogelijk om, zonder de werking ervan te onderbreken, nieuwe stuurprogramma's, bestandssystemen, enz. te laden en te verwijderen. Het proces van het debuggen van kernelcomponenten is aanzienlijk vereenvoudigd, aangezien een nieuwe versie stuurprogramma's kunnen worden geladen zonder het hele besturingssysteem opnieuw te starten. De kernelcomponenten van het besturingssysteem verschillen niet fundamenteel van gebruikersprogramma's, dus u kunt conventionele tools gebruiken om ze te debuggen. Microkernel-architectuur verbetert de systeembetrouwbaarheid omdat een bug op het niet-geprivilegieerde programmaniveau minder gevaarlijk is dan een crash op het niveau van de kernelmodus.

nadelen: Het overbrengen van gegevens tussen processen vereist overhead.

Runtime-omgeving

Vereisten voor de uitvoeringsomgeving van realtime systemen zijn als volgt:

• klein systeemgeheugen - voor de mogelijkheid van inbedding;
• het systeem moet volledig geheugenresident zijn om swapping of paging te voorkomen;
• het systeem moet multitasken - om maximaal te garanderen effectief gebruik alle systeembronnen;
• kernel met prioriteit voor service-interrupts. Interrupt-prioriteit betekent dat een kant-en-klaar proces met een bepaalde prioriteit noodzakelijkerwijs voorrang krijgt in de wachtrij boven een proces met een lagere prioriteit, dit snel vervangt en overgaat tot uitvoering. De kernel beëindigt elke service werk zodra de taak met de hoogste prioriteit arriveert. Dit zorgt voor de voorspelbaarheid van het systeem;
• Prioriteitsdispatcher - Hiermee kan de applicatieontwikkelaar elke opstartmodule een prioriteit toewijzen die buiten de controle van het systeem ligt. Prioritering wordt gebruikt om de volgorde te bepalen waarin programma's gereed voor uitvoering worden uitgevoerd. Een alternatief voor dit type planning is carrousel scheduling, waarbij elk kant-en-klaar programma een gelijke kans krijgt om te draaien. Met deze methode is er geen controle over welk programma wanneer wordt uitgevoerd. Dit is onaanvaardbaar in een realtime omgeving. Planning met prioriteit en een kernel met interruptprioriteit geven de applicatieontwikkelaar volledige controle over het systeem. Als zich een gebeurtenis met de hoogste prioriteit voordoet, stopt het systeem met het verwerken van de taak met de laagste prioriteit en reageert het op het nieuw ontvangen verzoek.

De combinatie van bovenstaande eigenschappen zorgt voor een krachtige en efficiënte realtime uitvoeringsomgeving.

Naast de eigenschappen van de runtime-omgeving, moet ook rekening worden gehouden met de service die wordt geboden door de realtime OS-kernel. De kern van elke realtime runtime is de kernel of dispatcher. De kernel beheert de hardware van de doelcomputer: de centrale verwerkingseenheid, het geheugen en I/O-apparaten; regelt de werking van alle andere systemen en software van toegepaste aard. In een realtime systeem neemt een dispatcher ruimte in tussen de hardware van de doelcomputer en de toepassingssoftware. Het zorgt voor speciale service nodig om realtime applicaties te draaien. Een service die door de kernel wordt geleverd, geeft applicatieprogramma's toegang tot systeembronnen zoals geheugen of invoer-/uitvoerapparaten.

De kernel kan verschillende soorten diensten leveren:

• Uitwisseling van taken. Het is vaak nodig om de overdracht van gegevens tussen programma's binnen hetzelfde systeem te waarborgen.Bovendien wordt het in veel toepassingen noodzakelijk om via een netwerk met andere systemen te communiceren. Interne communicatie kan via een berichtensysteem. Externe communicatie kan worden georganiseerd via een datagram (de beste leveringsmethode) of via communicatielijnen (gegarandeerde levering). De keuze voor deze of gene methode hangt af van het communicatieprotocol.
• Gegevens scheiding. In realtime toepassingen is het verzamelen van gegevens het meest tijdrovend. Gegevens zijn vaak nodig om andere programma's te laten werken of het systeem moet enkele van zijn functies uitvoeren. Veel systemen bieden toegang tot gedeelde geheugengedeelten. Datawachtrijen zijn wijdverbreid. Er zijn veel soorten wachtrijen, elk met zijn eigen voordelen.
• Verwerken van verzoeken van externe apparaten. Elke applicatie is in realtime verbonden met een extern apparaat van een bepaald type... De kernel moet I / O-services bieden waarmee applicaties kunnen lezen en schrijven naar deze apparaten. Het is gebruikelijk dat real-time toepassingen een specifieke van deze applicatie extern apparaat... De kernel zou een service moeten bieden die het werken met apparaatstuurprogramma's gemakkelijker maakt. Bied bijvoorbeeld de mogelijkheid om te schrijven in talen op hoog niveau, zoals C of Pascal.
• Omgaan met bijzondere situaties. Een uitzondering is een gebeurtenis die optreedt tijdens de uitvoering van het programma. Het kan synchroon zijn als het voorkomen ervan voorspelbaar is, zoals delen door nul. Of het kan asynchroon zijn als het onvoorspelbaar is, zoals een spanningsval. Door de mogelijkheid te bieden om dit soort gebeurtenissen af ​​te handelen, kunnen realtime toepassingen snel en voorspelbaar reageren op interne en externe gebeurtenissen. Er zijn twee methoden voor het afhandelen van uitzonderingen: statuswaarden gebruiken om foutcondities te detecteren en een uitzonderingshandler gebruiken om foutcondities te onderbreken en te corrigeren.

Overzicht van RTOS-architecturen

Tijdens zijn geschiedenis heeft de architectuur van besturingssystemen een aanzienlijke ontwikkeling doorgemaakt. Een van de eerste bouwprincipes, monolithisch OS (Figuur 1), was om het OS weer te geven als een set modules die op verschillende manieren met elkaar interageren binnen de systeemkernel en applicatieprogramma's voorzien van invoerinterfaces voor toegang tot hardware.

gelaagd besturingssysteem (Figuur 2) Een voorbeeld van zo'n besturingssysteem is goed bekend systeem MS-DOS. In systemen van deze klasse konden applicatietoepassingen niet alleen toegang krijgen tot hardware via de systeemkernel of zijn residente services, maar ook rechtstreeks. RTOS is jarenlang op dit principe gebouwd. Vergeleken met monolithische besturingssystemen biedt deze architectuur een veel grotere mate van voorspelbaarheid van systeemreacties en stelt applicatietoepassingen ook in staat snel toegang te krijgen tot hardware. Nadeel

dergelijke systemen zijn het gebrek aan multitasking erin. In deze architectuur werd het probleem van het verwerken van asynchrone gebeurtenissen teruggebracht tot het bufferen van berichten en het vervolgens opeenvolgend pollen van de buffers en verwerking. Tegelijkertijd werd de naleving van de kritische servicevoorwaarden verzekerd door de hoge snelheid van het rekencomplex in vergelijking met de snelheid van externe processen.

Afbeelding 2. Gelaagde OS-architectuur

Een van de meest effectieve architecturen voor het bouwen van realtime besturingssystemen is de client-server-architectuur. Het algemene schema van het besturingssysteem dat op deze technologie werkt, wordt getoond in figuur 3. Het belangrijkste principe van deze architectuur is om OS-services in de vorm van servers naar het gebruikersniveau te brengen, en de microkernel vervult de functies van een berichtverzender tussen clientgebruiker programma's en servers - systeemdiensten. Deze architectuur biedt veel voordelen op het gebied van vereisten voor RTOS en embedded systemen. Deze voordelen omvatten:

1. De betrouwbaarheid van het besturingssysteem neemt toe, aangezien elke service is in feite een op zichzelf staande applicatie en het is gemakkelijker om fouten te debuggen en op te sporen.

2. Zo'n systeem schaalt beter, omdat onnodige services uit het systeem kunnen worden uitgesloten zonder dat dit ten koste gaat van de prestaties.

3. Verhoogt de fouttolerantie van het systeem, omdat: Een bevroren service kan opnieuw worden gestart zonder

herstart het systeem.

Afbeelding 3. Een besturingssysteem bouwen met een client-server-architectuur

Helaas worden tegenwoordig niet veel besturingssystemen op client-serverbasis geïmplementeerd. Tot de bekende RTOS-implementerende microkernel-architectuur behoren OS9 en QNX.

Lijst met gebruikte literatuur:

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

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

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

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

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

Er wordt een overzicht gegeven van de vergelijkende kenmerken van RC-besturingssystemen die op de Russische markt aanwezig zijn, zoals toegepast op hun gebruik in luchtvaartcontrolesystemen.

Dankzij de ontwikkeling computertechnologie sinds kort is het mogelijk om taken toe te wijzen aan één module die voorheen door meerdere werden uitgevoerd processormodules, terwijl de kenmerken van het gewicht en de afmetingen van het besturingssysteem worden verbeterd en de kosten worden verlaagd. Deze trend in luchtvaarttechnologie heeft geleid tot de opkomst van het concept van geïntegreerde modulaire avionica - IMA (Integrated Modular Avionics, IMA).

Het probleem van het integreren van besturingsfuncties in een enkele module is dat het nodig is om de nu gemeenschappelijke bronnen (processortijd, geheugen, uitwisselingskanalen) tussen verschillende taken terwijl het hetzelfde niveau van betrouwbaarheid en onafhankelijkheid van functies biedt als voorheen. Het realtime besturingssysteem speelt een sleutelrol bij het oplossen van dit probleem.

Momenteel zijn er verschillende commerciële RTOS voor kritische toepassingen op de wereldmarkt (tabel 1). Dit artikel geeft een overzicht van RTOS beschikbaar op de Russische markt, gebaseerd op informatie uit open bronnen en persoonlijke ervaring auteurs.

Documenten die de vereisten voor RTOS regelen

• DO-178 (Software Consideration in Airborne Systems and Equipment Certification) specificeert de vereisten voor het softwareontwikkelingsproces en de grondigheid van de verificatie ervan, afhankelijk van de ernst ervan. Het niveau van softwarekritiek wordt bepaald op basis van een analyse van de ernst van de gevolgen van een softwarefout. Er zijn vijf niveaus van softwarekritiek (van A tot E).
• MILS (Multiple Independent Levels of Secutiry) is een speciale benadering van het ontwerp van besturingssystemen die de verspreiding van fouten in toepassingssoftware tijdens runtime voorkomt en programmaverificatie vereenvoudigt dankzij de modulaire opbouw van de software. Alle applicaties worden in zogenaamde partities geplaatst. Secties hebben specifieke bronnen (geheugengebied, processortijd tijdens elke systeemcyclus, toegang tot uitwisselingskanalen, enz.). Toegang tot de toegewezen middelen wordt gegarandeerd door het besturingssysteem dat in de supervisormodus draait. Zo kan op één processormodule onder controle van één besturingssysteem toepassingssoftware met verschillende kritieke niveaus draaien - als er een storing optreedt in minder kritieke (en dus minder geteste) software, heeft dit geen invloed op de werking van andere partities in hoe dan ook, aangezien pogingen om de bronnen van andere mensen te "usurteren" door het besturingssysteem worden geblokkeerd. MILS-ideeën sluiten aan bij die van IMA en DO-178B.
• De Avionics Application Software Standard Interface (ARINC-653) specificeert een APEX-toepassingssoftware-interface die het MILS-achtige clausuleconcept ondersteunt. Deze interface bevat functies voor het beheren van secties, processen, time-sharing, communicatie tussen secties en binnen een sectie, het bewaken van de toestand van het systeem. Opgemerkt moet worden dat de ARINC-653-standaard een algemeen aanvaarde benadering beschrijft voor de implementatie van MILS-ideeën voor IMA, hoewel er mogelijk andere implementaties zijn. Een RTOS-vliegtuig dat voldoet aan ARINC-653 heeft voordelen, aangezien deze standaard goed bekend is en begrepen wordt door internationale certificeringsinstanties, en daarom is het gemakkelijker om een ​​DO-178B-certificaat te verkrijgen voor een systeem dat volgens deze standaard is gebouwd.
• Herbruikbare softwarecomponenten standaard. Conform DO-178B is de software van een of ander luchtvaarttoepassingssysteem volledig gecertificeerd, ook als deze modules (componenten) gebruikt die al eerder zijn gecertificeerd als onderdeel van een ander systeem. Een van de nieuwste initiatieven van de FAA (Federal Aviation Certification Agency, VS) is het definiëren van criteria voor herbruikbaarheid van software zonder hercertificering. Componenten die mogelijk niet opnieuw worden gecertificeerd, worden RSC (Reusable Software Components) genoemd. Het kost meer moeite om gecertificeerd te worden voor het RSC, maar dan biedt het RSC een aanzienlijke besparing.

Russische documenten die softwarevereisten definiëren (inclusief RTOS):

• GOST R ISO / IEC 51904-2002 ("Software voor embedded systemen. Algemene vereisten voor ontwikkeling en documentatie") - analoog van DO-178B voor militaire luchtvaart;
• KT-178A ("Kwalificatie-eisen deel 178A") - analoog van DO-178B voor burgerluchtvaart;
• GOST R ISO / IEC 12207-99 (" Informatie Technologie... Softwarelevenscyclusprocessen ").

Vergelijking van RT OS werd uitgevoerd volgens 13 parameters, die rekening houden met technische criteria, gemakkelijke ontwikkeling en economische parameters.

Tijdparameters van het besturingssysteem

Een van de belangrijkste vereisten voor het RT OS is de minimale vertragingstijd voor het verwerken van een gebeurtenis. In de praktijk betekent dit dat de volgende parameters klein moeten zijn:

• responstijd voor onderbrekingen - de tijd tussen het daadwerkelijke optreden van een onderbreking en het begin van de verwerking van de eerste instructie van de onderbrekingsafhandelaar;
• controle stroomschakeltijd - tijd van schakelen tussen twee stromen in één proces;
• procescontext schakeltijd (alleen voor besturingssystemen die het procesmodel ondersteunen) - de tijd om te schakelen tussen twee besturingsthreads die bij twee verschillende processen horen.

Helaas is het niet eenvoudig om de gespecificeerde parameters van verschillende RT-besturingssystemen objectief te vergelijken, omdat deze parameters niet alleen afhankelijk zijn van de kwaliteit van het besturingssysteem, maar ook van de mogelijkheden van het gebruikte hardwareplatform. Idealiter moeten alle vergeleken besturingssystemen op hetzelfde hardwareplatform worden geïnstalleerd, waarna de bijbehorende metingen worden gedaan. Maar zelfs deze metingen zullen geen objectief resultaat geven, omdat verschillende besturingssystemen min of meer aangepast kunnen worden aan specifieke hardware.

Om de tijdparameters te vergelijken, maakt dit artikel gebruik van gefragmenteerde gegevens op het web, die vaak worden verkregen bij het testen van het besturingssysteem op verschillende apparatuur, terwijl de samenstelling en aard van de tests niet altijd duidelijk is.

Vrij objectieve gegevens kunnen worden beschouwd als de resultaten die zijn verkregen door de experts van het tijdschrift Dedicated System, die tests en praktische vergelijkingen hebben uitgevoerd van QNX RTOS 6.1, VxWorks AE 1.1 en Windows CE.NET op het x86-platform. Hoewel deze gegevens inmiddels achterhaald zijn, konden de auteurs van dit artikel geen recenter materiaal vinden. Tafel 2 toont een voorbeeldvergelijking van de prestaties van QNX Neutrino 6.1, VxWorks AE 1.1. Het Dedicated Systems-rapport gaf de voorkeur aan QNX wat betreft prestaties, met een scoreverhouding van 9: 5 (QNX: VxWorks), omdat VxWorks tijdens het testen twee bugs tegenkwam en contact moest opnemen met de ondersteuning om ze te repareren.

Tafel 3 geeft gegevens over de kenmerken van LynxOS. De samenstelling van de gebruikte testen is niet gespecificeerd. Wat betreft de gegevens over de kenmerken van LynxOS, is de vierde kolom interessant (testen op het x86-platform). Vergeleken met VxWorks en QNX vertoont LynxOS RT OS een enorme latentie in reactie op onderbrekingen (meer dan 5 keer). De context-schakeltijd (d.w.z. de schakeltijd tussen twee threads in hetzelfde proces) is hetzelfde met QNX en is ongeveer 1,5 keer minder dan die van VxWorks.

Stabiliteit van timingparameters

Naast de tijdkenmerken voor de RT OS is ook de stabiliteit van deze kenmerken van belang. Het is dit criterium dat grotendeels de "rigiditeit" van het RT OS bepaalt, d.w.z. voorspelbaarheid van de verwerkingstijd van gegevens, het moment van afgifte van resultaten, etc.

Op basis van de gegevens van het tijdschrift Dedicated System loopt QNX voor op VxWorks in dit criterium, zowel wat betreft de spreiding van kenmerken in een reeks tests van hetzelfde type (de verhouding van de maximale tijd tot de gemiddelde waarde is veel minder) , en met een toename van de belasting (de tijd van het wisselen van een stream met een toename van het aantal threads 2 ... 128 eenheden. voor QNX groeide het slechts 1,65 keer, terwijl het voor VxWorks 2,24 keer groeide).

Volgens de gegevens die zijn verkregen in het bedrijf RTSoft, is het bekend dat LynxOS ongeveer dezelfde kenmerken heeft als VxWorks.

Toegangscontrole tot bronnen

Laten we eens kijken naar de kwaliteit van toegangscontrole die door dit of dat RT OS wordt geboden aan kritieke bronnen van het computersysteem, zoals geheugen en processortijd.

De eerste vraag die beantwoord moet worden is of het besturingssysteem het procesmodel ondersteunt. Een proces is een logisch object dat eigenaar is van een of meer threads, de bijbehorende bronnen en de context - de inhoud van registers en tellers op een bepaald moment.

De taak van de processen is:

• in de afbakening van toegang tot RAM tussen verschillende programma's tijdens uitvoering;
• bij het afbakenen van de reikwijdte van globale variabelen tijdens het compileren (het is van cruciaal belang als de toepassingssoftware is geschreven in C, dat een dergelijke afbakening niet ondersteunt).

Segmentatie biedt ook scheiding van adresruimten (in die zin dupliceren sharding- en procesmogelijkheden elkaar). Bovendien biedt sharding elk segment met een of meer processen (of threads als het besturingssysteem het procesmodel niet ondersteunt) een gegarandeerd tijdsbudget. Dus als een thread met hoge prioriteit een lus vormt en zijn segment verstoort, zullen alle andere segmenten CPU-tijd ontvangen in overeenstemming met de instellingen die in de ontwerpfase zijn bepaald en normaal blijven functioneren.

LynxOS en QNX ondersteunen zowel procesmodel als sharding. VxWorks OS heeft een sharding-mechanisme, maar ondersteunt het procesmodel niet. Over het algemeen is dit acceptabel omdat sharding scheiding van adresruimten mogelijk maakt. Maar het ontbreken van processen brengt wat ongemak met zich mee. Doorgaans wordt segmentatie uitgevoerd op basis van het beoogde doel van de software en het belang ervan. Een bepaald segment kan bijvoorbeeld software bevatten voor het besturen van het vlucht- en navigatiecomplex, dat een hoge mate van kritiek heeft. Maar deze software is ook een nogal complex complex dat het logisch zou zijn om het op te splitsen in onafhankelijke (qua geheugen) modules. VxWorks OS biedt zo'n mogelijkheid niet, dat wil zeggen dat het segment zal bestaan ​​uit threads met gedeeld geheugen, wat de organisatie van parallelle ontwikkeling bemoeilijkt en uiteindelijk de betrouwbaarheid van de software vermindert.

Ondersteuning voor multiprocessor- en gedistribueerde systemen

De kosten van multiprocessormodules zijn de laatste tijd aanzienlijk gedaald en daarom worden ze steeds vaker gebruikt in embedded systemen. Natuurlijk moet het RT OS ondersteuning bieden voor dergelijke kaarten.

Een andere veelbelovende richting in de constructie van ACS is: gedistribueerde systemen, waarbij de modules op afstand van elkaar staan ​​en communicatie tussen de modules plaatsvindt via een netwerkomgeving. Nogmaals, het toegepaste RT OS moet handige en betrouwbare middelen hebben om de interactie van modules te organiseren: ondersteuning voor verschillende netwerkprotocollen, middelen om netwerktransparantie te waarborgen.

PB OS QNX biedt ondersteuning voor multiprocessor-kaarten. Voor VxWorks is deze ondersteuning zojuist aangekondigd. Een luchtvaartversie van LynxOS met ondersteuning voor multiprocessorborden bestaat ook nog niet.

Met betrekking tot ondersteuning voor netwerkprotocollen moet worden opgemerkt dat RT OS LynxOS, VxWorks en QNX ongeveer gelijke (en brede) mogelijkheden hebben. Een bijkomend voordeel van RT OS QNX is de speciale architectuur van het netwerksubsysteem, dat netwerk "transparantie" van applicatieprogramma's biedt: elk proces kan een ander proces op een externe module aanroepen, net als een proces op een lokale module.

Ondersteuning voor bestandssysteem

De mogelijkheid om informatie in de vorm van bestanden op te slaan is handig en traditioneel. Omgekeerd zorgt het ontbreken van een dergelijke mogelijkheid voor problemen bij het opslaan van zelden gewijzigde gegevens en het creëren van gedistribueerde systemen.

Tafel 4 toont de bestandssysteemondersteuning voor elk van de beschouwde besturingssystemen.

QNX heeft de breedste ondersteuning voor bestandssystemen. Bovendien is het flash-bestandssysteem fouttolerant.

Kwaliteit van documentatie

De kwaliteit van RV OS-documentatie LynxOS, VxWorks, QNX is vrij hoog. Er zijn echter enkele klachten over de documentatie:

• QNX - uitstekende beschrijving van architectuur en ontwerpprincipes, maar onvoldoende beschrijving van de API (niet alle parameters zijn beschreven, er zijn inconsistenties);
• VxWorks - er is geen uitleg van de werkingsprincipes en een onvoldoende beschrijving van het complexe proces van het configureren van het besturingssysteem.

Bedrijven werken echter aan de kwaliteit van het materiaal. Documentatie over huidige versie QNX (6.3.2) is flink uitgebreid, sommige onderdelen zijn herwerkt.

Kwaliteit van technische ondersteuning

Wat de kwaliteit van officiële technische ondersteuning betreft, is LynxOS de onbetwiste leider. LynuxWorks belooft elke technische vraag binnen 4 uur na het plaatsen van het verzoek te beantwoorden. LynxOS wordt in Rusland gedistribueerd door RTSoft, dat een grote staf heeft die gekwalificeerde hulp kan bieden. Het nadeel van LynxOS is dat het besturingssysteem nog niet erg gangbaar is in Rusland, daarom is er geen gevestigde gebruikersgemeenschap en is er zelfs geen Russischtalig forum.

QSS (fabrikant van QNX) biedt ook technische ondersteuning van goede kwaliteit, maar een snelle reactie is niet gegarandeerd. In tegenstelling tot LynxOS heeft RT OS QNX een goed georganiseerde gebruikersgemeenschap, zowel in het buitenland als in Rusland. De meeste vragen kunnen op deze forums worden beantwoord. QNX in ons land wordt gedistribueerd door SVD Embedded Systems, wiens medewerkers competente technische ondersteuning kunnen bieden en werkzaamheden kunnen uitvoeren om het besturingssysteem aan te passen aan specifieke processorkaarten. Daarnaast heeft het bedrijf directe contacten met QSS en kan het advies krijgen over complexe vraagstukken bij de ontwikkelaar van het RT OS QNX.

WindRiver, de ontwikkelaar van VxWorks, houdt traditioneel vast aan een gesloten technisch beleid, dat wil zeggen, het is nogal moeilijk om informatie te verkrijgen over de werkingsprincipes van het besturingssysteem. Dit besturingssysteem heeft ook geen Russischtalig forum. RV OS VxWorks in ons land wordt gedistribueerd door AVD Systems, dat zich voornamelijk bezighoudt met de verkoop van kant-en-klare software- en hardwareoplossingen van buitenlandse productie.

Open source

Een open RT OS heeft minstens drie voordelen:

• ontwikkelaars van applicatiesoftware kunnen begrijpen: moeilijke problemen zonder tussenkomst van technische ondersteuning;
• gemakkelijker te certificeren (bij afwezigheid van bladwijzers, enz.);
• meer dynamische ontwikkeling, aangezien de ontwikkelaar van het RT OS vaak niet alleen verzoeken ontvangt om fouten te corrigeren, maar ook suggesties voor het elimineren van fouten, waardoor het systeem wordt verbeterd. Open source RTOS-ontwikkelgemeenschappen groeien over het algemeen veel sneller en zijn beter georganiseerd. Onafhankelijke experts lijken te helpen bij het oplossen van de problemen van de technische ondersteuningsdienst en deelnemen aan de ontwikkeling, debuggen en testen van het systeem.

Sinds september 2007 heeft QSS de QNX-kernel uitgebracht (inclusief Adaptive Partitioning, High Availability). Even later werden de broncodes van het netwerksubsysteem geopend. De bètaversie van 6.4.0 is momenteel beschikbaar om te downloaden op de officiële website.

Opgemerkt moet worden dat vandaag niet alle QNX-modules open zijn (er zijn bijvoorbeeld geen codes voor grafische en bestandssysteem), en de licentie legt een beperking op aan het gebruik van "bronnen": alleen voor niet-commercieel gebruik. Een QNX-gebruiker ontvangt bovenstaande voordelen echter gratis.

De broncodes voor LynxOS en VxWorks zijn in de handel verkrijgbaar. De prijs voor een dergelijk product is bespreekbaar.

Gereedschapsgereedschappen

De beschikbaarheid van goede tools bepaalt in hoge mate de kwaliteit en snelheid van ontwikkeling van applicatieprogramma's voor een bepaald OS. Opgemerkt moet worden dat LynxOS, VxWorks en QNX momenteel tools van goede kwaliteit bieden, waaronder een geïntegreerde ontwikkelomgeving (IDE) en debugging van applicatiesoftware, programmaprofileringstools (voor het detecteren van " knelpunten"Door prestaties, geheugen, enz.). De ergonomie van de IDS voor deze RT-besturingssystemen doet over het algemeen niet onder voor de ontwikkelde ontwikkeltools voor conventionele besturingssystemen (bijvoorbeeld MS Windows).

Draagbaarheid van applicatiesoftware

De draagbaarheid van de applicatiesoftware biedt de mogelijkheid om deze te gebruiken voor andere besturingssystemen (inclusief niet-RT-besturingssystemen). Overdraagbaarheid geeft een zekere onafhankelijkheid aan de ontwikkelaar van applicatiesoftware vanuit het RT OS: indien nodig kun je tegen lage kosten overstappen naar een ander OS.

De mogelijkheid om draagbare software te schrijven is gedefinieerd in dit moment overeenstemming met de POSIX-standaard. Alle beschouwde RV-besturingssystemen ondersteunen de POSIX 1003.1-standaard. LynxOS heeft een voordeel - dit besturingssysteem is binaire compatibiliteit met Linux OS. Dat wil zeggen, Linux-applicaties kunnen worden uitgevoerd onder LynxOS zonder opnieuw te compileren. Omgekeerd kunnen LynxOS-applicaties op Linux draaien (versie 2.4.x met de glibs-versie 2.2.2 C-bibliotheek).

De rest van de RT-besturingssystemen moeten opnieuw worden gecompileerd om Linux-applicaties uit te voeren. In dit geval kan het proces van het overzetten van zelfs POSIX-compatibele applicaties vaak behoorlijk arbeidsintensief worden vanwege het verschil in de implementatie van bibliotheken en compilers.

Ondersteuning voor processorarchitecturen

Binnenlandse ontwikkelaars van besturingssystemen voor de luchtvaart bevinden zich in de huidige overgangsperiode van interne besturingssystemen naar commerciële besturingssystemen vaak in een situatie waarin het noodzakelijk is om een ​​RTOS te selecteren en aan te passen aan een reeds bestaand processorbord. In dit geval is een van de belangrijkste overwegingen bij het kiezen van een besturingssysteem ondersteuning voor de processorarchitectuur die op het bord wordt gebruikt.

Naleving van luchtvaartnormen

In buitenlandse praktijk moet software voor elektronische systemen een certificaat hebben van overeenstemming met de DO-178B-norm. Als de software verschillende niveaus kritiek wordt uitgevoerd op één processormodule, dan moet de gebruikte RTOS het concept van partities ondersteunen. (Anders is het bijna onmogelijk om te bewijzen dat de fout niet wordt verspreid). Zoals eerder vermeld, is het beter als de RTOS-programmeerinterface voldoet aan de ARINC-653-standaard, aangezien de standaard goed bekend is bij buitenlandse certificeringsinstanties.

LynxOS is de marktleider op het gebied van compliance. Het ondersteunt ARINC-653, er zijn veel voorbeelden van DO-178B gecertificeerde systemen die op zijn basis zijn gebouwd. Het belangrijkste punt is dat LynuxWorks een set RSC's aanbiedt (hoewel de auteurs van het artikel niet op de hoogte zijn van de prijs).

VxWorks is ARINC-653-compatibel en systemen die erop zijn gebouwd, kunnen DO-178B-gecertificeerd zijn (er zijn veel voorbeelden).

QNX is niet ARINC-653-compatibel en tot nu toe zijn er geen DO-178B-gecertificeerde systemen op gebaseerd.

Opgemerkt moet worden dat QNX-systemen in principe kunnen worden gebruikt om IMA te bouwen, omdat QNX zijn eigen methode ondersteunt om het concept van partities te bieden, wat een zeer goed alternatief is voor ARINC-653 en bovendien processortijd bespaart.

Wat betreft vergelijkbare Russische normen voor militaire luchtvaart (GOST R ISO / IEC 51904-2002), is er nog geen enkel voorbeeld van een gecertificeerd systeem, hoewel een dergelijk systeem in principe kan worden ontwikkeld op basis van een van de besturingssystemen onder overweging. Voor de RT OS QNX wordt momenteel gewerkt aan de voorbereiding van de belangrijkste OS-modules voor certificering.

Ontwikkeling van het systeem voor het opleiden van specialisten

De snelheid en kwaliteit van de training voor personeel dat werkt met het RT OS en verschillende tools voor het ontwikkelen en debuggen van software is direct gerelateerd aan de snelheid van softwareontwikkeling en de kwaliteit ervan. Toonaangevende bedrijven op het gebied van embedded en systeemsoftware, zoals WindRiver, LynuxWorks, QSS, voeren een grootschalig programma van cursussen en trainingen uit om het gebruik van de producten van het bedrijf, waaronder het RT OS, te bestuderen.

Vergelijkingsresultaten

RTOS QNX Neutrino is technisch het meest geavanceerde besturingssysteem, heeft een goede set tools, heeft een relatief lage prijs. De microkernel-architectuur zorgt voor een hoge betrouwbaarheid en modulariteit van de ontwikkelde systemen. Een bijkomend pluspunt is de open source code. Maar er is ook een vlieg in de zalf: momenteel wordt QNX praktisch nergens in de luchtvaart gebruikt en in deze parameter verliest dit besturingssysteem van concurrenten (LynxOS en VxWorks). Een bijkomend nadeel van QNX: niet-naleving van de ARINC-653-standaard.

Opgemerkt moet worden dat QNX Neutrino in principe alle noodzakelijke mechanismen heeft om in elektronische systemen te werken. Bovendien is de betrouwbaarheid en hoge beschikbaarheid van op QNX gebaseerde systemen bewezen in andere industrieën waar de kosten van fouten zelfs hoger zijn dan in de luchtvaart (besturing van kernreactoren).

Momenteel wordt door SWD Software gewerkt aan de voorbereiding van de certificering van QNX Neutrino volgens de vereisten van de binnenlandse luchtvaartnormen.

RTOS LynxOS-178 heeft daarentegen alle benodigde certificaten in het buitenland, hoewel het volgens veel andere criteria minder de voorkeur lijkt te hebben dan QNX Neutrino. Merk op dat voor gebruik in de Russische luchtvaartindustrie de LynxOS-178 RTOS ook gecertificeerd moet zijn volgens de Russische GOST.

VxWorks OS heeft een lange geschiedenis van missiekritieke applicaties in het buitenland. Uit onze analyse blijkt echter dat het in veel opzichten minder de voorkeur heeft voor de eerste twee besturingssystemen. Bovendien wordt de geloofwaardigheid van VxWorks ondermijnd door een gesloten ontwikkelingsstrategie.

Er wordt een overzicht gegeven van de vergelijkende kenmerken van RC-besturingssystemen die op de Russische markt aanwezig zijn, zoals toegepast op hun gebruik in luchtvaartcontrolesystemen.

05.05.2008, ma, 23:56, Moskouse tijd

Dankzij de ontwikkeling van computertechnologie is het recentelijk mogelijk geworden om taken die voorheen door meerdere processormodules werden uitgevoerd, toe te wijzen aan één module, terwijl de gewichts- en groottekenmerken van het besturingssysteem worden verbeterd en de kosten worden verlaagd. Deze trend in luchtvaarttechnologie heeft geleid tot de opkomst van het concept van geïntegreerde modulaire avionica - IMA (Integrated Modular Avionics, IMA).

Het probleem van het integreren van besturingsfuncties in een enkele module is dat het nodig is om de nu gemeenschappelijke bronnen (processortijd, geheugen, uitwisselingskanalen) tussen verschillende taken te delen, terwijl hetzelfde niveau van betrouwbaarheid en onafhankelijkheid van functies als voorheen wordt gegarandeerd. Het realtime besturingssysteem speelt een sleutelrol bij het oplossen van dit probleem.

Momenteel zijn er verschillende commerciële RTOS voor kritische toepassingen op de wereldmarkt (tabel 1). Dit artikel geeft een overzicht van RTOS's die beschikbaar zijn op de Russische markt, gebaseerd op informatie uit open bronnen en de persoonlijke ervaring van de auteurs.

Documenten die de vereisten voor RTOS regelen

DO-178 (Software Consideration in Airborne Systems and Equipment Certification) specificeert de vereisten voor het softwareontwikkelingsproces en de grondigheid van de verificatie ervan, afhankelijk van de ernst ervan. Het niveau van softwarekritiek wordt bepaald op basis van een analyse van de ernst van de gevolgen van een softwarefout. Er zijn vijf niveaus van softwarekritiek (van A tot E).

MILS (Multiple Independent Levels of Secutiry) is een speciale benadering van het ontwerp van besturingssystemen die de verspreiding van fouten in toepassingssoftware tijdens runtime voorkomt en programmaverificatie vereenvoudigt dankzij de modulaire opbouw van de software. Alle applicaties worden in zogenaamde partities geplaatst. Secties hebben specifieke bronnen (geheugengebied, processortijd tijdens elke systeemcyclus, toegang tot uitwisselingskanalen, enz.). Toegang tot de toegewezen middelen wordt gegarandeerd door het besturingssysteem dat in de supervisormodus draait. Zo kan op één processormodule onder controle van één besturingssysteem toepassingssoftware met verschillende kritieke niveaus draaien - als er een storing optreedt in minder kritieke (en dus minder geteste) software, heeft dit geen invloed op de werking van andere partities in hoe dan ook, aangezien pogingen om de bronnen van andere mensen te "usurteren" door het besturingssysteem worden geblokkeerd. MILS-ideeën sluiten aan bij die van IMA en DO-178B.

Fout 404. De pagina kan niet worden gevonden.

Misschien is dit om een ​​van de volgende redenen gebeurd:

- fout bij het typen van het pagina-adres (URL)
- het volgen van een "gebroken" (niet-werkende, onjuiste) link
- de opgevraagde pagina is nog nooit op de site geweest of is verwijderd

Jij kan:

- ga terug met de knop Terug van de browser
- controleer de spelling van het pagina-adres (URL)
- gebruik de sitemap of ga naar de hoofdpagina

De Avionics Application Software Standard Interface (ARINC-653) specificeert een APEX-toepassingssoftware-interface die het MILS-achtige clausuleconcept ondersteunt. Deze interface bevat functies voor het beheren van secties, processen, time-sharing, communicatie tussen secties en binnen een sectie, het bewaken van de toestand van het systeem. Opgemerkt moet worden dat de ARINC-653-standaard een algemeen aanvaarde benadering beschrijft voor de implementatie van MILS-ideeën voor IMA, hoewel er mogelijk andere implementaties zijn. Een RTOS-vliegtuig dat voldoet aan ARINC-653 heeft voordelen, aangezien deze standaard goed bekend is en begrepen wordt door internationale certificeringsinstanties, en daarom is het gemakkelijker om een ​​DO-178B-certificaat te verkrijgen voor een systeem dat volgens deze standaard is gebouwd.

Herbruikbare softwarecomponenten standaard. Conform DO-178B is de software van een of ander luchtvaarttoepassingssysteem volledig gecertificeerd, ook als deze modules (componenten) gebruikt die al eerder zijn gecertificeerd als onderdeel van een ander systeem. Een van de nieuwste initiatieven van de FAA (Federal Aviation Certification Agency, VS) is het definiëren van criteria voor herbruikbaarheid van software zonder hercertificering. Componenten die mogelijk niet opnieuw worden gecertificeerd, worden RSC (Reusable Software Components) genoemd. Het kost meer moeite om gecertificeerd te worden voor het RSC, maar dan biedt het RSC een aanzienlijke besparing.

Russische documenten die softwarevereisten definiëren (inclusief RTOS):

• GOST R ISO / IEC 51904-2002 ("Software voor embedded systemen. Algemene vereisten voor ontwikkeling en documentatie") - analoog van DO-178B voor militaire luchtvaart;
• KT-178A ("Kwalificatie-eisen deel 178A") - analoog van DO-178B voor burgerluchtvaart;
• GOST R ISO / IEC 12207-99 ("Informatietechnologie. Softwarelevenscyclusprocessen").

Vergelijking van RT OS werd uitgevoerd volgens 13 parameters, die rekening houden met technische criteria, gemakkelijke ontwikkeling en economische parameters.

Tijdparameters van het besturingssysteem

Een van de belangrijkste vereisten voor het RT OS is de minimale vertragingstijd voor het verwerken van een gebeurtenis. In de praktijk betekent dit dat de volgende parameters klein moeten zijn:

• responstijd voor onderbrekingen - de tijd tussen het daadwerkelijke optreden van een onderbreking en het begin van de verwerking van de eerste instructie van de onderbrekingsafhandelaar;
• controle stroomschakeltijd - tijd van schakelen tussen twee stromen in één proces;
• procescontext schakeltijd (alleen voor besturingssystemen die het procesmodel ondersteunen) - de tijd om te schakelen tussen twee besturingsthreads die bij twee verschillende processen horen.

Helaas is het niet eenvoudig om de gespecificeerde parameters van verschillende RT-besturingssystemen objectief te vergelijken, omdat deze parameters niet alleen afhankelijk zijn van de kwaliteit van het besturingssysteem, maar ook van de mogelijkheden van het gebruikte hardwareplatform. Idealiter moeten alle vergeleken besturingssystemen op hetzelfde hardwareplatform worden geïnstalleerd, waarna de bijbehorende metingen worden gedaan. Maar zelfs deze metingen zullen geen objectief resultaat geven, omdat verschillende besturingssystemen min of meer aangepast kunnen worden aan specifieke hardware.

Om de tijdparameters te vergelijken, maakt dit artikel gebruik van gefragmenteerde gegevens op het web, die vaak worden verkregen bij het testen van het besturingssysteem op verschillende apparatuur, terwijl de samenstelling en aard van de tests niet altijd duidelijk is.

Vrij objectieve gegevens kunnen worden beschouwd als de resultaten die zijn verkregen door de experts van het tijdschrift Dedicated System, die tests en praktische vergelijkingen hebben uitgevoerd van QNX RTOS 6.1, VxWorks AE 1.1 en Windows CE.NET op het x86-platform. Hoewel deze gegevens inmiddels achterhaald zijn, konden de auteurs van dit artikel geen recenter materiaal vinden. Tafel 2 toont een voorbeeldvergelijking van de prestaties van QNX Neutrino 6.1, VxWorks AE 1.1. Het Dedicated Systems-rapport gaf de voorkeur aan QNX wat betreft prestaties, met een scoreverhouding van 9: 5 (QNX: VxWorks), omdat VxWorks tijdens het testen twee bugs tegenkwam en contact moest opnemen met de ondersteuning om ze te repareren.

Tafel 3 geeft gegevens over de kenmerken van LynxOS. De samenstelling van de gebruikte testen is niet gespecificeerd. Wat betreft de gegevens over de kenmerken van LynxOS, is de vierde kolom interessant (testen op het x86-platform). Vergeleken met VxWorks en QNX vertoont LynxOS RT OS een enorme latentie in reactie op onderbrekingen (meer dan 5 keer). De context-schakeltijd (d.w.z. de schakeltijd tussen twee threads in hetzelfde proces) is hetzelfde met QNX en is ongeveer 1,5 keer minder dan die van VxWorks.

Stabiliteit van timingparameters

Naast de tijdkenmerken voor de RT OS is ook de stabiliteit van deze kenmerken van belang. Het is dit criterium dat grotendeels de "rigiditeit" van het RT OS bepaalt, d.w.z. voorspelbaarheid van de verwerkingstijd van gegevens, het moment van afgifte van resultaten, etc.

Op basis van de gegevens van het tijdschrift Dedicated System loopt QNX voor op VxWorks in dit criterium, zowel wat betreft de spreiding van kenmerken in een reeks tests van hetzelfde type (de verhouding van de maximale tijd tot de gemiddelde waarde is veel minder) , en met een toename van de belasting (de tijd van het wisselen van een stream met een toename van het aantal threads 2 ... 128 eenheden voor QNX groeide slechts 1,65 keer, terwijl voor VxWorks - 2,24 keer).

Volgens de gegevens die zijn verkregen in het bedrijf RTSoft, is het bekend dat LynxOS ongeveer dezelfde kenmerken heeft als VxWorks.

Toegangscontrole tot bronnen

Laten we eens kijken naar de kwaliteit van toegangscontrole die door dit of dat RT OS wordt geboden aan kritieke bronnen van het computersysteem, zoals geheugen en processortijd.

De eerste vraag die beantwoord moet worden is of het besturingssysteem het procesmodel ondersteunt. Een proces is een logisch object dat eigenaar is van een of meer threads, de bijbehorende bronnen en de context - de inhoud van registers en tellers op een bepaald moment.

De taak van de processen is:

• in de afbakening van toegang tot RAM tussen verschillende programma's tijdens uitvoering;
• bij het afbakenen van de reikwijdte van globale variabelen tijdens het compileren (het is van cruciaal belang als de toepassingssoftware is geschreven in C, dat een dergelijke afbakening niet ondersteunt).

Segmentatie biedt ook scheiding van adresruimten (in die zin dupliceren sharding- en procesmogelijkheden elkaar). Bovendien biedt sharding elk segment met een of meer processen (of threads als het besturingssysteem het procesmodel niet ondersteunt) een gegarandeerd tijdsbudget. Dus als een thread met hoge prioriteit een lus vormt en zijn segment verstoort, zullen alle andere segmenten CPU-tijd ontvangen in overeenstemming met de instellingen die in de ontwerpfase zijn bepaald en normaal blijven functioneren.

LynxOS en QNX ondersteunen zowel procesmodel als sharding. VxWorks OS heeft een sharding-mechanisme, maar ondersteunt het procesmodel niet. Over het algemeen is dit acceptabel omdat sharding scheiding van adresruimten mogelijk maakt. Maar het ontbreken van processen brengt wat ongemak met zich mee. Doorgaans wordt segmentatie uitgevoerd op basis van het beoogde doel van de software en het belang ervan. Een bepaald segment kan bijvoorbeeld software bevatten voor het besturen van het vlucht- en navigatiecomplex, dat een hoge mate van kritiek heeft. Maar deze software is ook een nogal complex complex dat het logisch zou zijn om het op te splitsen in onafhankelijke (qua geheugen) modules. VxWorks OS biedt zo'n mogelijkheid niet, dat wil zeggen dat het segment zal bestaan ​​uit threads met gedeeld geheugen, wat de organisatie van parallelle ontwikkeling bemoeilijkt en uiteindelijk de betrouwbaarheid van de software vermindert.

Ondersteuning voor multiprocessor- en gedistribueerde systemen

De kosten van multiprocessormodules zijn de laatste tijd aanzienlijk gedaald en daarom worden ze steeds vaker gebruikt in embedded systemen. Natuurlijk moet het RT OS ondersteuning bieden voor dergelijke kaarten.

Een andere veelbelovende richting in de constructie van ACS zijn gedistribueerde systemen, waarbij modules op afstand van elkaar zijn geplaatst en communicatie tussen hen plaatsvindt via een bepaalde netwerkomgeving. Nogmaals, het toegepaste RT OS moet handige en betrouwbare middelen hebben om de interactie van modules te organiseren: ondersteuning voor verschillende netwerkprotocollen, middelen om netwerktransparantie te waarborgen.

PB OS QNX biedt ondersteuning voor multiprocessor-kaarten. Voor VxWorks is deze ondersteuning zojuist aangekondigd. Een luchtvaartversie van LynxOS met ondersteuning voor multiprocessorborden bestaat ook nog niet.

Met betrekking tot ondersteuning voor netwerkprotocollen moet worden opgemerkt dat RT OS LynxOS, VxWorks en QNX ongeveer gelijke (en brede) mogelijkheden hebben. Een bijkomend voordeel van RT OS QNX is de speciale architectuur van het netwerksubsysteem, dat netwerk "transparantie" van applicatieprogramma's biedt: elk proces kan een ander proces op een externe module aanroepen, net als een proces op een lokale module.

Ondersteuning voor bestandssysteem

De mogelijkheid om informatie in de vorm van bestanden op te slaan is handig en traditioneel. Omgekeerd zorgt het ontbreken van een dergelijke mogelijkheid voor problemen bij het opslaan van zelden gewijzigde gegevens en het creëren van gedistribueerde systemen.

Tafel 4 toont de bestandssysteemondersteuning voor elk van de beschouwde besturingssystemen.

QNX heeft de breedste ondersteuning voor bestandssystemen. Bovendien is het flash-bestandssysteem fouttolerant.

Kwaliteit van documentatie

De kwaliteit van RV OS-documentatie LynxOS, VxWorks, QNX is vrij hoog. Er zijn echter enkele klachten over de documentatie:

• QNX - uitstekende beschrijving van architectuur en ontwerpprincipes, maar onvoldoende beschrijving van de API (niet alle parameters zijn beschreven, er zijn inconsistenties);
• VxWorks - er is geen uitleg van de werkingsprincipes en een onvoldoende beschrijving van het complexe proces van het configureren van het besturingssysteem.

Bedrijven werken echter aan de kwaliteit van het materiaal. De documentatie voor de huidige versie van QNX (6.3.2) is aanzienlijk uitgebreid, sommige delen zijn herwerkt.

Kwaliteit van technische ondersteuning

Wat de kwaliteit van officiële technische ondersteuning betreft, is LynxOS de onbetwiste leider. LynuxWorks belooft elke technische vraag binnen 4 uur na het plaatsen van het verzoek te beantwoorden. LynxOS wordt in Rusland gedistribueerd door RTSoft, dat een grote staf heeft die gekwalificeerde hulp kan bieden. Het nadeel van LynxOS is dat het besturingssysteem nog niet erg gangbaar is in Rusland, daarom is er geen gevestigde gebruikersgemeenschap en is er zelfs geen Russischtalig forum.

QSS (fabrikant van QNX) biedt ook technische ondersteuning van goede kwaliteit, maar een snelle reactie is niet gegarandeerd. In tegenstelling tot LynxOS heeft RT OS QNX een goed georganiseerde gebruikersgemeenschap, zowel in het buitenland als in Rusland. De meeste vragen kunnen op deze forums worden beantwoord. QNX in ons land wordt gedistribueerd door SVD Embedded Systems, wiens medewerkers competente technische ondersteuning kunnen bieden en werkzaamheden kunnen uitvoeren om het besturingssysteem aan te passen aan specifieke processorkaarten. Daarnaast heeft het bedrijf directe contacten met QSS en kan het advies krijgen over complexe vraagstukken bij de ontwikkelaar van het RT OS QNX.

WindRiver, de ontwikkelaar van VxWorks, houdt zich traditioneel aan een gesloten technisch beleid, dat wil zeggen dat het nogal moeilijk is om informatie te verkrijgen over de werkingsprincipes van het besturingssysteem. Dit besturingssysteem heeft ook geen Russischtalig forum. RV OS VxWorks in ons land wordt gedistribueerd door AVD Systems, dat zich voornamelijk bezighoudt met de verkoop van kant-en-klare software- en hardwareoplossingen van buitenlandse productie.

Open source

Een open RT OS heeft minstens drie voordelen:

• ontwikkelaars van applicatiesoftware kunnen complexe problemen oplossen zonder technische ondersteuning;
• gemakkelijker te certificeren (bij afwezigheid van bladwijzers, enz.);
• meer dynamische ontwikkeling, aangezien de ontwikkelaar van het RT OS vaak niet alleen verzoeken ontvangt om fouten te corrigeren, maar ook suggesties voor het elimineren van fouten, waardoor het systeem wordt verbeterd. Open source RTOS-ontwikkelgemeenschappen groeien over het algemeen veel sneller en zijn beter georganiseerd. Onafhankelijke experts lijken te helpen bij het oplossen van de problemen van de technische ondersteuningsdienst en deelnemen aan de ontwikkeling, debuggen en testen van het systeem.

Sinds september 2007 heeft QSS de QNX-kernel uitgebracht (inclusief Adaptive Partitioning, High Availability). Even later werden de broncodes van het netwerksubsysteem geopend. De bètaversie van 6.4.0 is momenteel beschikbaar om te downloaden op de officiële website.

Opgemerkt moet worden dat tegenwoordig niet alle QNX-modules open source zijn (er zijn bijvoorbeeld geen codes voor de grafische afbeeldingen en bestandssystemen), en de licentie legt een beperking op aan het gebruik van "bron": alleen voor niet-commercieel gebruik. Een QNX-gebruiker ontvangt bovenstaande voordelen echter gratis.

De broncodes voor LynxOS en VxWorks zijn in de handel verkrijgbaar. De prijs voor een dergelijk product is bespreekbaar.

Gereedschapsgereedschappen

De beschikbaarheid van goede tools bepaalt in hoge mate de kwaliteit en snelheid van ontwikkeling van applicatieprogramma's voor een bepaald OS. Opgemerkt moet worden dat LynxOS, VxWorks en QNX momenteel tools van goede kwaliteit bieden, waaronder een geïntegreerde ontwikkelomgeving (IDE) en foutopsporing in applicatiesoftware, programmaprofileringstools (voor het detecteren van prestatieknelpunten, geheugen, enz.). De ergonomie van de IDS voor deze RT-besturingssystemen doet over het algemeen niet onder voor de ontwikkelde ontwikkeltools voor conventionele besturingssystemen (bijvoorbeeld MS Windows).

Draagbaarheid van applicatiesoftware

De draagbaarheid van de applicatiesoftware biedt de mogelijkheid om deze te gebruiken voor andere besturingssystemen (inclusief niet-RT-besturingssystemen). Overdraagbaarheid geeft een zekere onafhankelijkheid aan de ontwikkelaar van applicatiesoftware vanuit het RT OS: indien nodig kun je tegen lage kosten overstappen naar een ander OS.

De mogelijkheid om draagbare software te schrijven wordt momenteel bepaald door POSIX-compliance. Alle beschouwde RV-besturingssystemen ondersteunen de POSIX 1003.1-standaard. LynxOS heeft een voordeel - dit besturingssysteem is binaire compatibiliteit met Linux OS. Dat wil zeggen, Linux-applicaties kunnen worden uitgevoerd onder LynxOS zonder opnieuw te compileren. Omgekeerd kunnen LynxOS-applicaties op Linux draaien (versie 2.4.x met de glibs-versie 2.2.2 C-bibliotheek).

De rest van de RT-besturingssystemen moeten opnieuw worden gecompileerd om Linux-applicaties uit te voeren. In dit geval kan het proces van het overzetten van zelfs POSIX-compatibele applicaties vaak behoorlijk arbeidsintensief worden vanwege het verschil in de implementatie van bibliotheken en compilers.

Ondersteuning voor processorarchitecturen

Binnenlandse ontwikkelaars van besturingssystemen voor de luchtvaart bevinden zich in de huidige overgangsperiode van interne besturingssystemen naar commerciële besturingssystemen vaak in een situatie waarin het noodzakelijk is om een ​​RTOS te selecteren en aan te passen aan een reeds bestaand processorbord. In dit geval is een van de belangrijkste overwegingen bij het kiezen van een besturingssysteem ondersteuning voor de processorarchitectuur die op het bord wordt gebruikt.

Naleving van luchtvaartnormen

In buitenlandse praktijk moet software voor elektronische systemen een certificaat hebben van overeenstemming met de DO-178B-norm. Als software van verschillende ernstniveaus op één processoreenheid wordt uitgevoerd, moet de gebruikte RTOS het concept van partities ondersteunen. (Anders is het bijna onmogelijk om te bewijzen dat de fout niet wordt verspreid). Zoals eerder vermeld, is het beter als de RTOS-programmeerinterface voldoet aan de ARINC-653-standaard, aangezien de standaard goed bekend is bij buitenlandse certificeringsinstanties.

LynxOS is de marktleider op het gebied van compliance. Het ondersteunt ARINC-653 en er zijn voldoende voorbeelden van DO-178B-gecertificeerde systemen die erop zijn gebouwd. Het belangrijkste punt is dat LynuxWorks een set RSC's aanbiedt (hoewel de auteurs van het artikel niet op de hoogte zijn van de prijs).

VxWorks is ARINC-653-compatibel en systemen die erop zijn gebouwd, kunnen DO-178B-gecertificeerd zijn (er zijn veel voorbeelden).

QNX is niet ARINC-653-compatibel en tot nu toe zijn er geen DO-178B-gecertificeerde systemen op gebaseerd.

Opgemerkt moet worden dat QNX-systemen in principe kunnen worden gebruikt om IMA te bouwen, omdat QNX zijn eigen methode ondersteunt om het concept van partities te bieden, wat een zeer goed alternatief is voor ARINC-653 en bovendien processortijd bespaart.

In termen van vergelijkbare Russische normen voor militaire luchtvaart (GOST R ISO / IEC 51904-2002), is er nog geen enkel voorbeeld van een gecertificeerd systeem, hoewel een dergelijk systeem in principe kan worden ontwikkeld op basis van elk van de besturingssystemen in overweging. Voor de RT OS QNX wordt momenteel gewerkt aan het voorbereiden van de belangrijkste OS-modules voor certificering.

Ontwikkeling van het systeem voor het opleiden van specialisten

De snelheid en kwaliteit van de training voor personeel dat werkt met het RT OS en verschillende tools voor het ontwikkelen en debuggen van software is direct gerelateerd aan de snelheid van softwareontwikkeling en de kwaliteit ervan. Toonaangevende bedrijven op het gebied van embedded en systeemsoftware, zoals WindRiver, LynuxWorks, QSS, voeren een grootschalig programma van cursussen en trainingen uit om het gebruik van de producten van het bedrijf, waaronder het RT OS, te bestuderen.

Vergelijkingsresultaten

RTOS QNX Neutrino is technisch het meest geavanceerde besturingssysteem, heeft een goede set tools, heeft een relatief lage prijs. De microkernel-architectuur zorgt voor een hoge betrouwbaarheid en modulariteit van de ontwikkelde systemen. Een bijkomend pluspunt is de open source code. Maar er is ook een vlieg in de zalf: momenteel wordt QNX praktisch nergens in de luchtvaart gebruikt en in deze parameter verliest dit besturingssysteem van concurrenten (LynxOS en VxWorks). Een bijkomend nadeel van QNX: het niet voldoen aan de ARINC-653 standaard.

Opgemerkt moet worden dat QNX Neutrino in principe alle noodzakelijke mechanismen heeft om in elektronische systemen te werken. Bovendien is de betrouwbaarheid en hoge beschikbaarheid van op QNX gebaseerde systemen bewezen in andere industrieën waar de kosten van fouten zelfs hoger zijn dan in de luchtvaart (besturing van kernreactoren).

Momenteel wordt door SWD Software gewerkt aan de voorbereiding van de certificering van QNX Neutrino volgens de vereisten van de binnenlandse luchtvaartnormen.

RTOS LynxOS-178 heeft daarentegen alle benodigde certificaten in het buitenland, hoewel het volgens veel andere criteria minder de voorkeur heeft dan QNX Neutrino. Houd er rekening mee dat voor gebruik in de Russische luchtvaartindustrie de LynxOS-178 RTOS ook moet zijn gecertificeerd volgens de Russische GOST.

VxWorks OS heeft een lange geschiedenis van missiekritieke applicaties in het buitenland. Uit onze analyse blijkt echter dat het in veel opzichten minder de voorkeur heeft voor de eerste twee besturingssystemen. Bovendien wordt de geloofwaardigheid van VxWorks ondermijnd door een gesloten ontwikkelingsstrategie.

Expertgroep / R & D.CNieuws

Afdrukken