Operativni sustav u stvarnom vremenu

Operativni sustav koji može osigurati potrebno vrijeme izvršenja čak i za zadatak u stvarnom vremenu u najgorim slučajevima, nazvao tvrdi operativni sustav u stvarnom vremenu.

Operativni sustav koji može osigurati potrebno vrijeme izvršenja za zadatak u stvarnom vremenu prosjek, nazvao meki operativni sustav u stvarnom vremenu.

Tvrdi sustavi u stvarnom vremenu ne dopuštaju kašnjenja u odgovoru sustava jer to može dovesti do:

• gubitak relevantnosti rezultata
• velike financijske gubitke
• nesreće i katastrofe

Ako se kritična obrada ne dogodi ili se ne dogodi dovoljno brzo, tvrdi sustav u stvarnom vremenu prekida operaciju i blokira je tako da se ne utječe na pouzdanost i dostupnost ostatka sustava. Primjeri tvrdih sustava u stvarnom vremenu mogu biti - ugrađeni sustavi upravljanje (u zrakoplovu, svemirskoj letjelici, brodu itd.), sustavi zaštite u hitnim slučajevima, snimači hitnih događaja.

Meke sustave u realnom vremenu karakterizira mogućnost odgođenog odgovora, što može dovesti do povećanja cijene rezultata i smanjene performanse sustava u cjelini. Primjer je rad računalne mreže. Ako sustav nije imao vremena obraditi sljedeći prihvaćen paket, to će uzrokovati zaustavljanje i ponovno slanje strane pošiljatelja (ovisno o protokolu). Podaci se ne gube, ali performanse mreže su smanjene.

Glavna razlika između tvrdih i mekih sustava u stvarnom vremenu može se okarakterizirati na sljedeći način: tvrdi sustav u stvarnom vremenu nikada neće kasniti u odgovoru na događaj, dok meki sustav u stvarnom vremenu ne bi trebao kasniti u odgovoru na događaj.

Označimo operativnim sustavom u stvarnom vremenu sustav koji se može koristiti za izgradnju tvrdih sustava u stvarnom vremenu. Ova definicija izražava stav prema RTOS-u kao objektu koji sadrži potrebni alati, ali također znači da se ti alati i dalje moraju pravilno koristiti.

Većina softvera je orijentirana na "soft" stvarno vrijeme. Takve sustave karakterizira:

• zajamčeno vrijeme odziva na vanjske događaje (prekidi opreme);
• podsustav strogog planiranja procesa (visoki prioritetni zadaci ne bi trebali biti zamijenjeni onima niskog prioriteta, uz neke iznimke);
• povećani zahtjevi za vrijeme reakcije na vanjske događaje ili reaktivnost (kašnjenje u pozivanju rukovatelja prekidima nije veće od desetaka mikrosekundi, kašnjenje pri prebacivanju zadataka nije veće od stotina mikrosekundi)

Klasičan primjer zadatka gdje je potreban RTOS je upravljanje robotom koji podiže dio s pokretne trake. Dio se kreće, a robot ima samo malo vremena kada ga može podići. Ako zakasni, tada dio više neće biti na željenom dijelu transportne trake, pa stoga posao neće biti dovršen, unatoč činjenici da je robot u pravo mjesto. Ako se pripremi ranije, dio neće imati vremena stići, a on će mu blokirati put.

Posebnosti RTOS-a

Tablica usporedbe između RTOS-a i konvencionalnih operativnih sustava:

RTOS arhitekture

U svom razvoju, RTOS-ovi su izgrađeni na temelju sljedećih arhitektura.

• . OS se definira kao skup modula koji međusobno djeluju unutar jezgre sustava i pružaju aplikacijski softver ulazna sučelja za pozive na opremu. Glavni nedostatak ovog principa konstruiranja OS-a je slaba predvidljivost njegovog ponašanja uzrokovana složenom interakcijom modula međusobno.
• . Aplikacijski softver ima mogućnost pristupa hardveru ne samo putem jezgre sustava i njegovih usluga, već i izravno. U usporedbi s monolitnom arhitekturom, takva arhitektura pruža značajno veći stupanj predvidljivosti reakcija sustava, a također omogućuje brz pristup aplikacija aplikacija na opremu. Glavni nedostatak takvih sustava je nedostatak multitaskinga.
• Arhitektura klijent-poslužitelj. Njegovo glavno načelo je dovesti usluge OS-a u obliku poslužitelja na korisničku razinu i obavljati funkcije mikrojezgre upravitelja poruka između klijenta korisničkih programa i poslužitelji - usluge sustava. Prednosti ove arhitekture:

1. Povećana pouzdanost, budući da je svaka usluga, zapravo, neovisna aplikacija i lakše je ispravljati pogreške i pratiti pogreške;
2. Poboljšana skalabilnost, budući da se nepotrebne usluge mogu isključiti iz sustava bez ugrožavanja njegove izvedbe;
3. Povećana tolerancija grešaka, budući da se zamrznuta usluga može ponovno pokrenuti bez ponovnog pokretanja sustava.

Značajke jezgre

RTOS kernel osigurava funkcioniranje srednje apstraktne OS razine, koja skriva specifičnosti od aplikacijskog softvera tehnički uređaj procesor (nekoliko procesora) i pripadajući hardver.

Osnovne usluge

Ovaj apstraktni sloj pruža pet glavnih kategorija usluga za aplikacijski softver.

• Upravljanje zadacima. Najviše glavna grupa usluge. Omogućuje razvojnim programerima aplikacija da dizajniraju softverske proizvode kao skupove zasebnih programskih fragmenata, od kojih se svaki može odnositi na vlastito tematsko područje, obavljati zasebnu funkciju i imati vlastiti vremenski odsječak koji mu je dodijeljen za rad. Svaki takav fragment naziva se zadatak. Servisi u ovoj grupi imaju mogućnost pokretanja zadataka i dodjeljivanja prioriteta za njih. Glavna usluga ovdje je upravitelj zadataka. Prati izvršavanje tekućih zadataka, pokreće nove u odgovarajućem vremenskom razdoblju i prati njihov način rada.
• Dinamička dodjela memorije. Mnogi (ali ne svi) RTOS kerneli podržavaju ovu grupu usluga. Zadacima omogućuje posuđivanje područja RAM-a za privremenu upotrebu u pokrenutim aplikacijama. Često se ta područja naknadno pomiču sa zadatka na zadatak, a kroz ovo brz prijenos mnogo podataka između njih. Neki vrlo mali RTOS kerneli namijenjeni za korištenje u hardverskim okruženjima sa strogim ograničenjima memorije ne podržavaju usluge dinamičke dodjele memorije.
• Upravljanje timerom. Budući da ugrađeni sustavi imaju stroge zahtjeve za vremenski okvir za izvršenje zadatka, RTOS jezgra uključuje grupu usluga koje pružaju upravljanje timerom za praćenje vremenskog ograničenja tijekom kojeg se zadatak mora izvršiti. Ovi servisi mjere i postavljaju različite vremenske intervale (od 1 μs i više), generiraju prekide po isteku vremenskih intervala te kreiraju jednokratne i cikličke alarme.
• Komunikacija i sinkronizacija između zadataka. Usluge u ovoj grupi omogućuju zadacima razmjenu informacija i osiguravaju njihovu sigurnost. Oni također omogućuju fragmentima softvera da koordiniraju svoj rad jedan s drugim kako bi se povećala učinkovitost. Ako su te usluge isključene iz RTOS jezgre, tada će zadaci početi razmjenjivati ​​iskrivljene informacije i mogu ometati rad susjednih zadataka.
• Nadzor I/O uređaja. Usluge u ovoj grupi pružaju jedinstveno softversko sučelje koje se povezuje s mnogim upravljačkim programima uređaja koji su tipični za većinu ugrađenih sustava.

Uz usluge kernela, mnogi RTOS-ovi nude linije dodatne komponente organizirati koncepte visoke razine kao što je sustav datoteka, umrežavanje, upravljanje mrežom, upravljanje bazom podataka, grafičko korisničko sučelje, itd. Iako su mnoge od ovih komponenti puno veće i složenije od same jezgre RTOS-a, one se ipak oslanjaju na njezine usluge. Svaka od ovih komponenti uključena je u ugrađeni sustav samo ako su njegove usluge potrebne za izvođenje ugrađene aplikacije i samo kako bi se potrošnja memorije svela na minimum.

Razlike od operativnih sustava opće namjene

Mnogi operativni sustavi opće namjene također podržavaju gore navedene usluge. Međutim, ključna razlika između RTOS osnovnih usluga je deterministički, na temelju stroge kontrole vremena, prirode njihovog posla. U u ovom slučaju Pod determinizmom podrazumijevamo da izvođenje jedne usluge operacijskog sustava zahtijeva vremenski interval poznatog trajanja. Teoretski, to se vrijeme može izračunati pomoću matematičkih formula koje moraju biti striktno algebarske i ne smiju uključivati ​​nikakve vremenske parametre slučajne prirode. Bilo koja slučajna varijabla koja određuje vrijeme izvršenja zadatka u RTOS-u može uzrokovati neželjeno kašnjenje u aplikaciji, tada sljedeći zadatak neće ispuniti svoj vremenski odsječak, što će uzrokovati pogrešku.

U tom smislu operativni sustavi opće namjene nisu deterministički. Njihove usluge mogu dopustiti povremena kašnjenja u radu, što može dovesti do usporavanja odgovora aplikacije na radnje korisnika u nepoznatom trenutku. Prilikom dizajniranja konvencionalnih operativnih sustava, programeri ne usmjeravaju svoju pozornost na matematički aparat za izračunavanje vremena izvršenja konkretan zadatak i usluga. Ovo nije kritično za ovu vrstu sustava.

Planiranje zadataka

Posao planera

Većina RTOS-a izvršava raspoređivanje zadataka na temelju sljedeće sheme. Svakom zadatku u aplikaciji dodijeljen je određeni prioritet. Što je veći prioritet, to bi trebala biti veća reaktivnost zadatka. Primjenom pristupa postiže se visoka reaktivnost priority preventivno raspoređivanje(preemptive scheduling), čija je suština da je planeru dopušteno zaustaviti izvršenje bilo kojeg zadatka u proizvoljnom trenutku ako se utvrdi da drugi zadatak treba odmah pokrenuti.

Opisana shema funkcionira prema sljedećem pravilu: ako su dva zadatka spremna za pokretanje u isto vrijeme, ali prvi ima visoki prioritet, a drugi nizak, tada će planer dati prednost prvom. Drugi zadatak će se pokrenuti tek nakon što prvi završi svoj posao.

Moguće je da se zadatak niskog prioriteta već izvodi, a planer primi poruku da je drugi zadatak višeg prioriteta spreman za izvođenje. Razlog tome može biti neki vanjski utjecaj (prekid od strane opreme), kao što je promjena stanja sklopke uređaja kojim upravlja RTOS. U takvoj situaciji, planer zadataka će se ponašati prema pristupu prioritetnog preventivnog planiranja kako slijedi. Zadatku s niskim prioritetom bit će dopušteno dovršiti trenutnu naredbu asemblera (ali ne i naredbu opisanu u izvornom kodu programa na jeziku visoke razine), nakon čega se izvršavanje zadatka zaustavlja. Zatim se pokreće zadatak visokog prioriteta. Nakon što se obradi, planer pokreće prekinuti prvi zadatak s asemblerskom instrukcijom koja slijedi nakon zadnje izvršene.

Svaki put kada planer zadataka primi signal o pojavi nekog vanjskog događaja (okidača), čiji uzrok može biti ili hardverski ili softverski, on postupa prema sljedećem algoritmu.

1. Određuje treba li se zadatak koji se trenutno izvodi nastaviti izvoditi.
2. Postavlja koji zadatak treba pokrenuti sljedeći.
3. Sprema kontekst zaustavljenog zadatka (tako da kasnije može nastaviti s radom od mjesta gdje je zaustavljen)
4. Postavlja kontekst za sljedeći zadatak.
5. Pokreće ovaj zadatak.

Ovih pet koraka algoritma također se nazivaju prebacivanje zadataka.

Izvršenje zadatka

U konvencionalnim RTOS-ovima, zadatak može biti u 3 moguća stanja:

1. Zadatak se izvršava;
2. Zadatak je spreman za izvršenje;
3. Zadatak je blokiran.

Većinu vremena većina zadataka je blokirana. Samo jedan zadatak može se izvršiti na CPU-u po ovaj trenutak vrijeme. U primitivnim RTOS-ovima, popis zadataka spremnih za izvršenje obično je vrlo kratak; ne može se sastojati od više od dvije ili tri stavke.

Glavna funkcija RTOS administratora je stvoriti takav planer zadataka.

Ako popis zadataka spremnih za izvršenje ne sadrži više od dva ili tri, tada se pretpostavlja da su svi zadaci smješteni u optimalnom redoslijedu. Ako se dogode takve situacije da broj zadataka na popisu premašuje dopuštenu granicu, tada se zadaci poredaju po prioritetu.

Algoritmi planiranja

Trenutno se najintenzivnije razvijaju dva pristupa za rješavanje problema učinkovitog planiranja u RTOS-u.

• Statički algoritmi raspoređivanja(RMS, Rate Monotonic Scheduling). Koristite prioritetno preventivno zakazivanje. Prioritet se dodjeljuje svakom zadatku prije nego što se počne izvršavati. Prednost imaju zadaci s najkraćim rokom izvršenja.
• Algoritmi dinamičkog raspoređivanja(EDF, prvo planiranje najranijeg roka). Prioritet se zadacima dodjeljuje dinamički, a prednost imaju zadaci s najranijim vremenom početka (završetka) izvršenja.

Interakcija između zadataka i dijeljenja resursa

• Privremeno onemogućavanje prekida
• Binarni semafori
• Slanje signala

RTOS obično ne koriste prvu metodu jer korisnička aplikacija ne može kontrolirati procesor onoliko koliko želi. Međutim, mnogi ugrađeni sustavi i RTOS-ovi dopuštaju aplikacijama da se izvode u načinu rada jezgre radi pristupa sistemskim pozivima i daju kontrolu nad okruženjem izvršavanja bez intervencije OS-a.

Na jednoprocesorskim sustavima, najbolje rješenje je pokrenuti aplikaciju u kernel modu, koji ima omogućenu blokadu prekida. Dok je prekid onemogućen, aplikacija isključivo koristi resurse procesa i nijedan drugi zadatak ili prekid ne može se izvršiti. Na taj su način svi kritični resursi zaštićeni. Nakon što aplikacija završi kritične aktivnosti, mora deblokirati prekide, ako postoje. Privremeno onemogućavanje prekida dopušteno je samo kada je najduži period izvođenja kritične sekcije manji od dopuštenog vremena odziva prekida. Obično se ova metoda zaštite koristi samo kada duljina kritičnog koda ne prelazi nekoliko redaka i ne sadrži petlje. Ova metoda je idealna za zaštitu registra.

Kada je duljina kritične sekcije veća od maksimalne ili sadrži petlje, programer mora koristiti mehanizme identične ili simuliraju ponašanje sustava opće namjene, kao što su semafori i signalizacija.

Dodjela memorije

Sljedećim problemima dodjele memorije pridaje se više pažnje u RTOS-ovima nego u operativnim sustavima opće namjene.

Prvo, brzine raspodjele memorije. Standardna shema dodjele memorije uključuje skeniranje popisa neodređene duljine kako bi se pronašlo slobodno područje memorije zadana veličina, a to je neprihvatljivo, budući da se u RTOS-u dodjela memorije mora dogoditi u fiksnom vremenu.

Drugo, memorija može postati fragmentirana ako su njezini slobodni dijelovi već podijeljeni pokrenuti procesi. To može uzrokovati zaustavljanje programa zbog nemogućnosti korištenja nove memorijske lokacije. Algoritam raspodjele memorije koji postupno povećava fragmentaciju memorije može dobro funkcionirati na desktop sustavima ako se ponovno pokreću barem jednom mjesečno, ali je neprihvatljiv za ugrađene sustave koji rade godinama bez ponovnog pokretanja.

Jednostavan algoritam fiksne duljine vrlo dobro funkcionira u jednostavnim ugrađenim sustavima.

Ovaj algoritam također dobro radi na desktop sustavima, posebno kada, dok jedna jezgra obrađuje komad memorije, sljedeći komad memorije obrađuje druga jezgra. RTOS-ovi optimizirani za stolna računala kao što je Unison Operacijski sustav ili DSPnano RTOS pružaju ovu mogućnost.

Operativni sustavi u stvarnom vremenu (popis)

Treba napomenuti da popis ne uključuje sustave razvijene u SSSR-u za vojne i svemirske sustave - iz očitih razloga povezanih s režimom tajnosti. Međutim, njihovo postojanje i korištenje desetljećima neosporna je činjenica o kojoj treba voditi računa.

Bilješke

Književnost

• Zyl S. QNX operativni sustav u stvarnom vremenu: od teorije do prakse. - 2. izd. - St. Petersburg. : BHV-Petersburg, 2004. - 192 str. - ISBN 5-94157-486-H
• Zyl S. QNX Momentics. Osnove primjene. - St. Petersburg. : BHV-Petersburg, 2004. - 256 str. - ISBN 5-94157-430-4
• Curten R. Uvod u QNX/Neutrino 2. - St. Petersburg. : Petropolis, 2001. - 512 str. - ISBN 5-94656-025-9
• Auslander D.M., Ridgley J.R., Ringenberg J.D. Kontrolni programi za mehanički sustavi: Objektno orijentirano projektiranje sustava u stvarnom vremenu. - M.: Binom. Laboratorij znanja, 2004. - 416 str. - ISBN 5-94774-097-4

Linkovi

• Pregled operativnih sustava u stvarnom vremenu (engleski)

Osnova svakog sklopa hardvera i softvera, uključujući i one koji rade u stvarnom vremenu, je operativni sustav (OS). Operacijski sustav je skup programa koji osigurava upravljanje resursima hardversko-softverskog kompleksa (računalnog sustava) i procesa koji koriste te resurse u izračunima. Resurs je u ovom kontekstu bilo koja logička ili fizička (i u cjelini) komponenta računalnog sustava ili sklopa hardvera i softvera i mogućnosti koje on pruža.

Glavni resursi su procesor (procesorsko vrijeme), radna memorija i perifernih uređaja.

Upravljanje resursima svodi se na izvršavanje sljedećih zadataka: pojednostavljenje pristupa resursima, njihova raspodjela između procesa.

Rješenje prvog problema omogućuje vam da "sakrijete" hardverske značajke računalnog sustava i time ih učinite dostupnima korisniku ili programeru virtualni stroj uz znatno lakšu kontrolu. Dakle, OS podržava sljedeća sučelja: korisničko (komandni jezik za upravljanje radom sustava i skup usluge); softver (skup usluga koji oslobađa programera od rutinskih operacija kodiranja) jedan je od najvažnijih zadataka koje OS rješava, ali nije svojstven svim OS-ima, već samo onima koji osiguravaju istovremeni rad. izvršavanje više programa (procesa).

Proces je slijed radnji propisanih programom ili njegovim logički dovršenim dijelom, kao i podaci koji se koriste u izračunima. Proces je minimalna jedinica posao za koji su sredstva dodijeljena.

Trenutno postoji veliki izbor operativnih sustava koji su klasificirani prema sljedećim kriterijima:

o broj korisnika koje sustav istovremeno opslužuje;

o broj procesa koji se mogu istovremeno izvoditi pod kontrolom OS-a;

o vrsta korisničkog pristupa sustavu;

o vrsta sklopa hardvera i softvera.

Prema prvom znaku razlikuju se jednokorisnički i višekorisnički operativni sustavi.

Druga značajka dijeli OS na one s jednom i više zadataka.

Prema trećem obilježju operativni sustavi se dijele na:

o sustavi sa skupna obrada. U ovom slučaju, paket se formira od programa koje treba izvršiti i predstaviti sustavu na obradu. U ovom slučaju korisnici nemaju izravnu interakciju s OS-om;

o sustavi dijeljenja vremena koji omogućuju istovremeni interaktivni pristup računalni sustav više korisnika putem terminala. U ovom slučaju, resursi sustava se dodjeljuju svakom korisniku "zauzvrat", u skladu s jednom ili drugom disciplinom usluge;

o sustavi u stvarnom vremenu, koji moraju osigurati zajamčeno vrijeme odgovora na vanjske događaje (pogledajte dolje za više detalja).

Četvrta značajka dijeli OS na jednoprocesorske i višeprocesorske, mrežne i distribuirane. Za višekorisničke i multitasking operativne sustave, disciplina održavanja važan je pokazatelj. U skladu s tim, razlikuju se preventivni i koordinirajući načini multitaskinga. U preventivnoj organizaciji samo je OS odgovoran za raspodjelu procesorskog vremena zadacima (na primjer, za svaki zadatak, procesor se dodjeljuje naizmjence, i to za strogo fiksno vremensko razdoblje, ali je moguće i prioritetno servisiranje). U slučaju organizacije koja se podudara, svaki zadatak, nakon što je dobio kontrolu, sam određuje kada će procesor "dati" drugom zadatku. Općenito, koordinacija je učinkovitija i pouzdanija od prevencije, ali odlučujući faktor u provedbi programa je činjenica da ovaj program ne bi trebao monopolizirati CPU vrijeme.

Sustav u stvarnom vremenu (RTS)- ovo je sustav čije ispravno funkcioniranje ne ovisi samo o logičkoj ispravnosti izračuna, već i o vremenu tijekom kojeg se ti izračuni rade.

Za događaje koji se događaju u takvom sustavu važno je vrijeme u kojem se događaji događaju i njihova logička ispravnost. Sustav radi u stvarnom vremenu ako je njegova izvedba primjerena brzini fizičkih procesa na objektima nadzora ili upravljanja (što znači procesi koji su izravno povezani s funkcijama koje obavlja određeni sustav u stvarnom vremenu). Kontrolni sustav mora prikupiti podatke, obraditi ih prema zadanim algoritmima i izdati kontrolnu akciju u vremenskom razdoblju koje osigurava uspješno izvršenje dodijeljenih zadataka.

1.1 Što je sustav stvarnog vremena

U U zadnje vrijeme Sve češće se susrećemo sa zadacima koji zahtijevaju upravljanje složenim procesima ili opremom pomoću računala. Štoviše, svi događaji u tim procesima događaju se kad se dogode. Računalo može izvršiti samo konačan broj operacija u konačnom vremenu, pa se postavlja pitanje hoće li računalo imati vremena potrebna brzina izračunati situaciju i izdati konkretne kontrolne radnje koje bi bile primjerene konkretno u određeni trenutak vrijeme. Po mom mišljenju, problemi ove vrste nastali su zbog korištenja vrlo velike brzine V moderna proizvodnja. Jasno je da se signali u prirodi šire konačnom brzinom, brzina rada je također konačna, stoga je načelno nemoguće očekivati ​​trenutne akcije (uzrokovane određenim događajem) od računala. Uostalom, koliko god računalo bilo moderno (čitaj – moćno u performansama, tj. velikoj brzini obrade naredbi i operacija), fizički mu treba barem djelić sekunde da izvrši mali jednostavna grupa zapovijedi, a ponekad je i ovo vrijeme previše. Dakle, vrijeme reakcije sustava na neki događaj je striktno veće od nule. Stvarni zadaci dopuštaju određeno kašnjenje u radnjama, a ako sustav ima vrijeme reakcije manje od ovog prihvatljivog kašnjenja, tada je pošteno nazvati ga sustavom u stvarnom vremenu. Pošto u prirodi različite procese odvijati se različitim brzinama; jedan te isti sustav može stati unutar zadanog okvira za jedan proces, a ne stati za drugi. Stoga ima smisla govoriti o sustavu u stvarnom vremenu u odnosu na konkretan zadatak. Na primjer, za iscrtavanje ovisnosti prosječne temperature zraka za jedan dan o danu u tjednu, gotovo svako računalo s gotovo bilo kojim softverom radit će kao sustav u stvarnom vremenu. Ako kontroliramo slijetanje zrakoplova, gdje milisekunde igraju značajnu ulogu, prikladnije bi bilo pažljivo odabrati hardver i softver.

Osim razmatranog zadatka odgovora na određeni događaj, postoje i druge klase zadataka u stvarnom vremenu. Jedna od čestih je zadaća stalnog praćenja ili kontrole dinamičkog procesa, tj. kada trebate kontinuirano razmjenjivati ​​signale s vanjskim svijetom. Računalo je diskretan sustav, pa je potrebno izvršavati neke radnje s određenim konačnim vremenskim razdobljima, pod pretpostavkom da tijekom tih kratkih vremenskih razdoblja vanjski svijet ostaje nepromijenjen. Ako je naš sustav sposoban obraditi informacije i proizvesti upravljačke signale na potrebnoj frekvenciji, tada se može nazvati sustavom u stvarnom vremenu. Nije teško razumjeti da se ovaj problem može lako svesti na prethodni, koristeći početak sljedećeg vremenskog intervala kao događaj. Vrijeme reakcije mora biti kraće od vremena uzorkovanja procesa. Stoga je prethodno opisani zadatak najvažniji kada govorimo o o sustavima u stvarnom vremenu. Treba napomenuti da nezadovoljavajući rad sustava u smislu latencije kod nekih zadataka može dovesti do fatalnih posljedica, a kod drugih neće doći do abnormalnih ili neželjenih situacija. Na primjer: ako sustav za mjerenje temperature iz gore opisanog primjera slučajno zakasni nedopustivo dugo, to znači da smo jednostavno promijenili izbor točaka očitanja temperature, i dalje ćemo dobiti točan rezultat, ali ako automatski prilaz putničkog zrakoplova slučajno kasni na sekundu zbog iznenadnog naleta vjetra, zrakoplov možda neće stići do piste i deseci ljudi će poginuti. Stoga sustave treba podijeliti na tvrde i meke sustave stvarnog vremena.

Real Time OS (RTOS) je OS koji jamči određenu sposobnost za određeno vremensko razdoblje. Na primjer, mogao bi biti dizajniran da pokaže da je objekt postao dostupan robotu na pokretnoj traci. Takve školjke se dijele na "tvrde" i "meke".

Čvrsti operativni sustavi u stvarnom vremenu pretpostavljaju da se izračun ne može izvesti ako objekt nije dostupan unutar određenog razdoblja (takva operacija neće uspjeti).

U mekom operativnom sustavu u stvarnom vremenu, pokretna traka će nastaviti funkcionirati pod ovim uvjetima, ali proizvodnja može biti manja jer objekti ne mogu biti dostupni u zakazano vrijeme, što uzrokuje da robot bude privremeno neproduktivan.

Prije davanja primjera operativnih sustava u stvarnom vremenu, potrebno je razumjeti značajke njihove upotrebe. Neki takvi operativni sustavi stvoreni su za posebne aplikacije, drugi za općenitije. Osim toga, neke ljuske opće namjene također se ponekad koriste za rad u stvarnom vremenu. Dobro poznati Windows 2000 ili IBM Microsoft/390 mogu izvesti ovu vrstu. To jest, čak i ako OS ne ispunjava neke zahtjeve, može imati karakteristike koje mu omogućuju da se smatra rješenjem za određeni problem aplikacije u stvarnom vremenu.

Primjeri operativnih sustava i njihove karakteristike

Općenito, stvarno vrijeme ima sljedeće karakteristike:

• Multitasking.
• Tehnološki tokovi kojima se može dati prioritet.
• Dovoljan broj razina prekida.

Operativni sustavi u stvarnom vremenu često se koriste kao dio malih ugrađenih ljuski koje se koriste u formatu mikrouređaja. Stoga se neke jezgre mogu smatrati operativnim sustavima s jednim zadatkom (primjeri: jezgre u iOS-u, Androidu itd.) u stvarnom vremenu. Međutim, one zahtijevaju druge komponente uređaja, kao što su upravljački programi, za obavljanje predviđenih zadataka. Zato je punopravni, u pravilu, više od jezgre.

Tipičan primjer RTOS aplikacije je HDTV prijemnik i zaslon. Mora čitati digitalni signal, dekodirati ga i prikazati kao dolazni podatak. Svako kašnjenje bit će vidljivo kao pikselizirani video i/ili izobličeni zvuk.

U isto vrijeme, kada se postavi zahtjev "navedite primjere operativnih sustava ove vrste", to znači spominjanje najviše poznata imena. Što je uključeno u ovu grupu?

VxWorks tvrtke WindRiver

VxWorks je operativni sustav u stvarnom vremenu razvijen kao vlasnički softver tvrtke WindRiver. Prvi put objavljen 1987., VxWorks je izvorno bio namijenjen za korištenje u ugrađenim sustavima koji zahtijevaju determinističke performanse u stvarnom vremenu. Tako se primjeri operativnih sustava ove vrste koriste u područjima sigurnosti i sigurnosti, raznim industrijama (osobito zrakoplovnoj i obrambenoj), proizvodnji medicinski uređaji, industrijska oprema, robotika, energija, upravljanje transportom, mrežna infrastruktura, poboljšanje automobilske i potrošačke elektronike.

VxWorks podržava Intel (x86, uključujući novi IntelQuarkSoC i x86-64), MIPS, PowerPC, SH-4 i ARM arhitekture. Uz ovaj RTOS dolazi moćna jezgra, srednje softver, plaćena podrška dodatni paketi i hardverske tehnologije trećih proizvođača. U svom najnovijem izdanju - VxWorks 7 - sustav je redizajniran za modularnost i mogućnost nadogradnje tako da je OS kernel odvojen od međuprograma, aplikacija i drugih paketa.

QNX Neutrino

Također klasični primjeri operativnih sustava ove vrste su neke ljuske slične Unixu. Ovo je QNX Neutrino, izvorno razvijen u ranim 1980-ima od strane kanadske tvrtke Quantum Software Systems. Naposljetku, razvoj je kupio BlackBerry 2010. QNX je jedan od prvih komercijalno uspješnih mikrokernel operativnih sustava koji se koristi u razne uređaje, uključujući automobile i mobilne telefone.

FreeRTOS

FreeRTOS je popularan kernel OS u stvarnom vremenu za ugrađene uređaje koji ima 35 mikrokontrolera. Širi se pod GPL licenca S dodatno ograničenje i neobvezne iznimke. Ograničenje zabranjuje benchmarking, dok iznimka dopušta vlastiti kod korisnicima zajedno sa zatvorenim izvornim kodom, uz očuvanje same jezgre. To olakšava korištenje FreeRTOS-a u vašim aplikacijama.

Windows CE

Windows Embedded Compact je podfamilija operativnih sustava koju je razvila Microsoft Corporation kao dio Windows proizvodi Ugrađen. Za razliku od Windows Embedded Standarda, koji se temelji na Windows NT, ovi ogledni operativni sustavi koriste ekskluzivnu hibridnu jezgru. Microsoft pruža Windows licence CE za OEM proizvođače koji mogu mijenjati i stvarati vlastita prilagođena sučelja, pružajući tehnička osnova za ovo.

Operativni sustavi u stvarnom vremenu (RTOS) dizajnirani su za pružanje sučelja za resurse vremenski kritičnih sustava u stvarnom vremenu. Glavna zadaća u takvim sustavima je pravodobnost obrade podataka.

Glavni zahtjev za RTOS je osigurati predvidljivost ili determinizam ponašanja sustava u najgorim vanjskim uvjetima, što se oštro razlikuje od zahtjeva za performansama i brzinom univerzalnih operacijskih sustava. Dobar RTOS ima predvidljivo ponašanje u svim scenarijima opterećenja sustava (istovremeni prekidi i izvršavanje niti).

Postoji određena razlika između sustava u stvarnom vremenu i ugrađenih sustava. Ugrađeni sustav ne mora uvijek imati predvidljivo ponašanje, u kojem slučaju to nije sustav u stvarnom vremenu. Međutim, čak i letimičan pogled na moguće ugrađene sustave sugerira da većina ugrađenih sustava treba predvidljivo ponašanje, prema barem, za neke funkcionalnosti, pa se ovi sustavi mogu klasificirati kao sustavi u stvarnom vremenu.

Uobičajeno je razlikovati meke i tvrde sustave stvarnog vremena. U sustavima teško stvarno vremenska nemogućnost davanja odgovora na bilo kakve događaje u navedeno vrijeme dovodi do neuspjeha i nemogućnosti izvršenja zadatka. U većini literature na ruskom jeziku takvi se sustavi nazivaju sustavima s determinističkim vremenom. Na praktična aplikacija vrijeme reakcije mora biti minimalno. Meki sustavi u stvarnom vremenu su sustavi koji ne potpadaju pod definiciju “tvrdih”, jer Za njih još nema jasne definicije u literaturi. Meki sustavi u stvarnom vremenu možda neće imati vremena riješiti problem, ali to ne dovodi do kvara sustava u cjelini. U sustavima stvarnog vremena potrebno je uvesti određeni rok (u engleskoj literaturi - deadline), prije čijeg isteka zadatak mora nužno (za sustave mekog stvarnog vremena - poželjno) biti dovršen. Ovaj rok planer zadataka koristi i za dodjelu prioriteta zadatku kada se pokrene i za odabir zadatka za izvršenje.

Martin Timmerman formulirao je sljedeće potrebne zahtjeve za RTOS:

• OS mora biti multitasking i imati prednost,
• OS mora imati koncept prioriteta za niti,
• OS mora podržavati predvidljive mehanizme sinkronizacije,
• OS mora osigurati mehanizam za nasljeđivanje prioriteta,
• Ponašanje OS-a mora biti poznato i predvidljivo (kašnjenja obrade prekida, kašnjenja prebacivanja zadataka, kašnjenja upravljačkog programa, itd.); to znači da se u svim scenarijima opterećenja sustava mora odrediti maksimalno vrijeme odziva.

Tijekom proteklih 25-30 godina, struktura operativnih sustava razvila se od monolitne do višeslojne OS strukture do arhitekture klijent-poslužitelj. U monolitnoj strukturi OS se sastoji od skupa modula, a promjene jednog modula utječu na druge module. Što je više modula, to je veći kaos tijekom rada takvog sustava. Osim toga, nije moguće distribuirati OS na višeprocesorskom sustavu. U višeslojnoj strukturi promjene u jednom sloju utječu na susjedne slojeve; osim toga, inverzija kroz sloj nije moguća. Za sustave u stvarnom vremenu mora se osigurati izravan pristup svakom sloju OS-a, a ponekad i izravno hardveru.

Glavna ideja tehnologije klijent-poslužitelj u OS-u je smanjiti bazu OS-a na minimum (raspoređivač i primitive sinkronizacije). Sve druge funkcionalnosti premještene su na drugu razinu i implementirane kroz niti ili zadatke. Skup takvih poslužiteljskih zadataka odgovoran je za sistemske pozive. Aplikacije su klijenti koji traže usluge putem sistemskih poziva.

Tehnologija klijent-poslužitelj omogućuje stvaranje skalabilnih operativnih sustava i pojednostavljuje distribuciju u višeprocesorskom sustavu. Prilikom rada sustava, zamjena jednog modula ne uzrokuje efekt "grude snijega"; Osim toga, kvar modula ne povlači uvijek kvar sustava u cjelini. Sada postoji mogućnost dinamičkog učitavanja i učitavanja modula. Glavni problem u ovom modelu je zaštita memorije, jer procesi poslužitelja moraju biti zaštićeni. Svaki put kada se napravi zahtjev za uslugu, sustav se mora prebaciti iz konteksta aplikacije u kontekst poslužitelja. Uz podršku za zaštitu memorije, vrijeme prebacivanja s jednog procesa na drugi se povećava.

U pravilu, većina modernih RTOS-ova izgrađena je na temelju mikrokernela (kernel ili nucleus), koji omogućuje raspoređivanje i otpremu zadataka, kao i njihovu interakciju. Iako jezgra minimizira apstrakcije OS-a, mikrojezgra još uvijek mora imati razumijevanje apstrakcija procesa. Sve ostale konceptualne apstrakcije operativnih sustava premještaju se izvan jezgre, pozivaju se na zahtjev i izvršavaju kao aplikacije.

Izrazite značajke RTOS iz OS-a opće namjene

Namijenjeni su operacijskim sustavima opće namjene, posebno višekorisničkim poput UNIX-a optimalna raspodjela računalnih resursa između korisnika i zadataka. U operativnim sustavima u stvarnom vremenu, takav zadatak blijedi u pozadinu - sve se povlači prije glavni zadatak- imati vremena reagirati na događaje koji se događaju u objektu Druga je razlika u tome što je korištenje operativnog sustava u stvarnom vremenu uvijek povezano s opremom, s objektom, s događajima koji se događaju u objektu. Operativni sustav u stvarnom vremenu fokusiran je na obradu vanjskih događaja. Operativni sustav u stvarnom vremenu može biti sličan korisničko sučelje na OS-u opće namjene, ali je strukturiran potpuno drugačije. Osim toga, korištenje operativnih sustava u stvarnom vremenu uvijek je specifično. Ako OS opće namjene korisnici (ne programeri) obično percipiraju kao gotov skup aplikacija, tada operativni sustav u stvarnom vremenu služi samo kao alat za stvaranje određenog hardverskog i softverskog kompleksa u stvarnom vremenu. Stoga najširu klasu korisnika operativnih sustava u stvarnom vremenu čine programeri sustava u stvarnom vremenu, ljudi koji projektiraju sustave upravljanja i prikupljanja podataka. Prilikom projektiranja i razvoja određenog sustava u stvarnom vremenu, programer uvijek zna koji se događaji mogu dogoditi u objektu i zna kritični vremenski okvir za servisiranje svakog od tih događaja koji mora imati vremena da odgovori na događaj koji se dogodio u objektu u vremenu kritičnom za ovaj događaj. Vrijednost kritičnog vremena za svaki događaj određena je objektom i samim događajem, a može biti različita, ali se vrijeme reakcije sustava mora predvidjeti (izračunati) prilikom izrade sustava. Neuspjeh u odgovoru u predviđeno vrijeme smatra se pogreškom za sustave koji rade u stvarnom vremenu. Čak i ako se dva ili više vanjskih događaja dogode istovremeno, sustav mora imati vremena reagirati na svaki od njih unutar vremenskih intervala kritičnih za te događaje.

Tvrdi i meki sustavi realnog vremena

Postoje dvije vrste sustava u stvarnom vremenu - sustavi u stvarnom vremenu i sustavi u stvarnom vremenu.

Sustavi tvrdog stvarnog vremena ne dopuštaju kašnjenje u odgovoru sustava ni pod kojim okolnostima jer:

• rezultati mogu biti beskorisni ako kasne
• može doći do katastrofe ako se reakcija odgodi

• cijena kašnjenja može biti beskonačna.

Primjeri tvrdih sustava u stvarnom vremenu su upravljački sustavi na vozilu, sustavi zaštite u hitnim slučajevima, snimači hitnih događaja.

Meke sustave u stvarnom vremenu karakterizira činjenica da kašnjenje odgovora nije kritično, iako može dovesti do povećanja cijene rezultata i smanjenja performansi sustava u cjelini. Primjer je rad mreže. Ako sustav nema vremena za obradu sljedećeg primljenog paketa, to će dovesti do isteka vremena na strani pošiljatelja i ponovnog slanja (ovisno o protokolu, naravno). Podaci se ne gube, ali se performanse mreže smanjuju. Glavna razlika između tvrdih i mekih sustava u stvarnom vremenu može se izraziti na sljedeći način: tvrdi sustav stvarno vrijeme nikada neće kasniti u reagiranju na događaj, meki sustav stvarnog vremena ne bi trebao kasniti u reagiranju na događaj

Jezgra operativnog sustava

Jezgra je središnji dio operacijskog sustava (OS), koji aplikacijama omogućuje koordinirani pristup resursima računala, memoriji, vanjskom hardveru, vanjskim ulaznim i izlaznim uređajima, prevodeći naredbe jezika aplikacije u jezik binarnog koda koji računalo razumije kao temelj element OS-a, kernel predstavlja najviše niska razina apstrakcije za pristup aplikacija resursima sustava potrebnim za njihov rad. Tipično, kernel omogućuje takav pristup izvršnim procesima odgovarajućih aplikacija korištenjem mehanizama međuprocesna komunikacija i aplikacija poziva na sistemske pozive OS.

Monolitna jezgra

Monolitna jezgra pruža bogat skup hardverskih apstrakcija. Svi dijelovi monolitnog kernela rade u istom adresnom prostoru. Ovo je dizajn operativnog sustava u kojem su sve komponente njegove jezgre komponente jedan program, koristite opće strukture podatke i međusobno komuniciraju izravnim pozivanjem procedura. Monolitna jezgra - najstariji način organizacija operativnih sustava. Primjer sustava s monolitnom jezgrom je većina UNIX sustava.

Prednosti: Brzina rada, pojednostavljen razvoj modula.

Mane: Budući da cijeli kernel radi u istom adresnom prostoru, kvar u jednoj od komponenti može poremetiti cijeli sustav.

Neki stari monolitni kerneli, posebno sustavi klase UNIX/Linux, zahtijevali su ponovno kompajliranje kad god bi se sastav hardvera promijenio. Većina moderne jezgre omogućuju učitavanje modula tijekom rada koji obavljaju dio funkcija jezgre. U ovom slučaju komponente operativnog sustava nisu nezavisni moduli, i komponente jednog veliki program zove se monolitna jezgra, koja je skup procedura od kojih svaka može pozvati svaku. Sve procedure izvode se u povlaštenom načinu rada.

Mikrojezgra

Mikrojezgra pruža samo osnovne funkcije kontrole procesa i minimalan skup apstrakcija za rad s hardverom. Većina posla obavlja se kroz posebne korisničke procese zvane usluge. Odlučujući kriterij za "mikrokernelizam" je smještaj svih ili gotovo svih pokretača i modula u uslužnim procesima.

Prednosti: Otpornost na kvarove hardvera i greške u komponentama sustava. Glavna prednost mikrojezgrene arhitekture je visoki stupanj modularnost jezgre operacijskog sustava. To znatno olakšava dodavanje novih komponenti. U operacijskom sustavu s mikrojezgrom možete učitavati i uklanjati nove upravljačke programe, datotečne sustave itd. bez prekidanja njegovog rada. Proces otklanjanja pogrešaka u komponentama jezgre znatno je pojednostavljen nova verzija upravljački programi se mogu učitati bez ponovnog pokretanja cijelog operativnog sustava. Komponente jezgre operacijskog sustava ne razlikuju se bitno od korisničkih programa, tako da možete koristiti obične alate za njihovo otklanjanje pogrešaka. Arhitektura mikrokernela poboljšava pouzdanost sustava jer je kvar na neprivilegiranoj programskoj razini manje opasan od kvara na razini kernel moda.

Mane: Prijenos podataka između procesa zahtijeva dodatne troškove.

Runtime okruženje

Zahtjevi za okruženje izvršavanja sustava u stvarnom vremenu su sljedeći:

• mala sistemska memorija - za mogućnost ugradnje;
• sustav mora biti potpuno rezidentan u memoriji kako bi se izbjeglo mijenjanje memorijske stranice ili zamjena;
• sustav mora biti multitasking – kako bi se osigurala maksimalna učinkovito korištenje svi resursi sustava;
• jezgra s prioritetom za servisiranje prekida. Prioritet prekida znači da proces koji je spreman za izvođenje i ima određeni prioritet nužno ima prioritet u redu čekanja nad procesom nižeg prioriteta, brzo zamjenjuje potonji i nastavlja s izvršenjem. Jezgra završava bilo uslužni rad, čim stigne zadatak sa glavni prioritet. Time se osigurava predvidljivost sustava;
• upravitelj prioriteta - omogućuje programeru aplikacije da svakom modulu za pokretanje dodijeli prioritet koji nije podložan sustavu. Dodjela prioriteta koristi se za određivanje redoslijeda kojim se izvršavaju programi koji su spremni za izvođenje. Alternativa ovoj vrsti rasporeda je vrtuljak raspored, u kojem svaki program koji je spreman za nastavak ima jednake šanse za pokretanje. Kod ove metode nema kontrole nad time koji će se program i kada izvršiti. Ovo je neprihvatljivo u okruženju u stvarnom vremenu. Slanje temeljeno na prioritetu i kernel s prioritetom prekida daju programeru aplikacija potpunu kontrolu nad sustavom. Ako se dogodi događaj višeg prioriteta, sustav prestaje obrađivati ​​zadatak nižeg prioriteta i odgovara na novoprimljeni zahtjev.

Kombinacija gore opisanih svojstava stvara snažno i učinkovito okruženje za izvršavanje u stvarnom vremenu.

Osim svojstava runtime okruženja, također je potrebno uzeti u obzir uslugu koju pruža OS kernel u stvarnom vremenu. Srž svakog okruženja za izvršavanje u stvarnom vremenu je kernel ili dispečer. Kernel kontrolira hardver ciljnog računala: središnji procesor, memorija i ulazno/izlazni uređaji; kontrolira rad svih ostalih sustava i softver primijenjene prirode. U sustavu u stvarnom vremenu, dispečer se nalazi između hardvera ciljnog računala i aplikacijskog softvera. Pruža posebna služba, potrebno za pokretanje aplikacija u stvarnom vremenu. Usluga koju pruža kernel daje aplikacijski programi pristup resursima sustava poput memorije ili ulazno/izlaznih uređaja.

Kernel može pružiti različite vrste usluga:

• Razmjena između zadataka. Često je potrebno prenositi podatke između programa unutar istog sustava. Osim toga, mnoge aplikacije moraju komunicirati s drugim sustavima putem mreže. Interfon može se obaviti putem sustava za razmjenu poruka. Vanjske komunikacije može se organizirati putem datagrama ( najbolji način dostava), ili putem komunikacijskih linija (zajamčena dostava). Odabir jedne ili druge metode ovisi o komunikacijskom protokolu.
• Razdvajanje podataka. U aplikacijama u stvarnom vremenu prikupljanje podataka traje najdulje. Podaci su često nužni za rad drugih programa ili su potrebni sustavu za obavljanje neke od njegovih funkcija. Mnogi sustavi omogućuju pristup opći odjeljci memorija. Čekanje podataka u redu je široko rasprostranjeno. U upotrebi je mnogo vrsta redova čekanja, od kojih svaki ima svoje prednosti.
• Obrada zahtjeva s vanjskih uređaja. Svaki aplikacijski program povezan je u stvarnom vremenu s vanjskim uređajem određena vrsta. Kernel mora osigurati I/O usluge koje omogućuju aplikacijskim programima čitanje i pisanje na ovim uređajima. Za aplikacije u stvarnom vremenu uobičajeno je imati a ovu aplikaciju vanjski uređaj. Kernel mora pružiti uslugu koja olakšava rad s upravljačkim programima uređaja. Na primjer, omogućite snimanje na jezicima visoka razina- kao što su C ili Pascal.
• Rješavanje posebnih situacija. Izuzetak je događaj koji se dogodi tijekom izvođenja programa. Može biti sinkrono ako je njegovo pojavljivanje predvidljivo, kao što je dijeljenje s nulom. A može biti i asinkrono ako se dogodi nepredvidivo, kao što je pad napona. Pružanje mogućnosti rukovanja ovim vrstama događaja omogućuje aplikacijama u stvarnom vremenu da brzo i predvidljivo reagiraju na unutarnje i vanjske događaje. Postoje dvije metode za rukovanje iznimkama - korištenje vrijednosti stanja za otkrivanje stanja pogreške i korištenje rukovatelja iznimkom za hvatanje stanja pogreške i njihovo ispravljanje.

Pregled RTOS arhitektura

Tijekom svoje povijesti, arhitektura operacijskog sustava doživjela je značajan razvoj. Jedan od prvih principa gradnje, monolitna OS (Slika 1) se sastojao od predstavljanja OS-a kao skupa modula koji međusobno djeluju na različite načine unutar jezgre sustava i daju aplikacijskim programima ulazna sučelja za pristup hardveru.

razina OS (slika 2) Primjer takvog OS-a je dobro poznati MS-DOS sustav. U sustavima ove klase, aplikacijske aplikacije mogu pristupiti hardveru ne samo preko jezgre sustava ili njegovih rezidentnih usluga, već i izravno. RTOS-ovi su godinama građeni na ovom principu. U usporedbi s monolitnim operativnim sustavima, ova arhitektura pruža značajno veći stupanj predvidljivosti reakcija sustava, a također omogućuje aplikativnim aplikacijama brz pristup hardveru. Hendikep

Ono što takve sustave čini tako lošima je nedostatak multitaskinga. Unutar ove arhitekture, problem obrade asinkronih događaja sveden je na spremanje poruka u međuspremnik, a zatim sekvencijalno ispitivanje međuspremnika i njihovu obradu. Istodobno, poštivanje kritičnih servisnih rokova osigurano je visokim performansama računalnog kompleksa u usporedbi s brzinom vanjskih procesa.

Slika 2. Tier OS arhitektura

Jedna od najučinkovitijih arhitektura za izgradnju operativnih sustava u stvarnom vremenu je arhitektura klijent-poslužitelj. Opća shema OS koji radi pomoću ove tehnologije prikazan je na slici 3. Glavni princip ove arhitekture je prijenos OS usluga u obliku poslužitelja na korisničku razinu, a mikrojezgra djeluje kao upravitelj poruka između klijentskih korisničkih programa i poslužitelja - sustava usluge. Ova arhitektura pruža puno prednosti u smislu zahtjeva za RTOS i ugrađene sustave. Među tim prednostima su:

1. Povećava se pouzdanost OS-a, jer Svaka je usluga zapravo neovisna aplikacija i lakše je ispravljati pogreške i pratiti pogreške.

2. Takav sustav se bolje skalira, budući da se nepotrebne usluge mogu isključiti iz sustava bez ugrožavanja njegove izvedbe.

3. Povećava se otpornost sustava na pogreške jer Zamrznuta usluga može se ponovno pokrenuti bez

ponovno pokrenite sustav.

Slika 3. Izrada OS-a korištenjem klijent-poslužiteljske arhitekture

Nažalost, danas nema mnogo operativnih sustava implementiranih na principu klijent-poslužitelj. Među poznatim RTOS-ovima koji implementiraju mikrokernel arhitekturu su OS9 i QNX.

Popis korištene literature:

1) http://ru.wikipedia.org/wiki/Real_time_operating system

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/