Sistemul de operare în timp real ( RTOS , sistem de operare în timp real în engleză , RTOS ) este un tip de sistem de operare specializat , al cărui scop principal este de a oferi setul necesar și suficient de funcții pentru proiectarea, dezvoltarea și funcționarea sisteme de timp pe echipamente hardware specifice.
Specificația UNIX, Revizia 2, definește:
Timpul real în sistemele de operare este capacitatea sistemului de operare de a furniza nivelul necesar de serviciu într-o anumită perioadă de timp. [unu]
Text original (engleză)[ arataascunde] Timp real în sistemele de operare: capacitatea sistemului de operare de a furniza un nivel necesar de serviciu într-un timp de răspuns limitat. [2]RTOS ideal are un comportament previzibil în toate scenariile de încărcare, inclusiv întreruperi concurente și execuție de fire [3] .
Sistemele de operare în timp real sunt uneori împărțite în două tipuri - sisteme hard în timp real și sisteme soft în timp real [4] .
Un sistem de operare care poate oferi timpul de execuție necesar pentru o sarcină în timp real chiar și în cele mai rele cazuri se numește sistem de operare dur în timp real . Un sistem care poate oferi timpul de execuție necesar pentru o sarcină în timp real în medie se numește sistem de operare soft în timp real .
Sistemele hard în timp real nu permit întârzieri în răspunsul sistemului, deoarece acest lucru poate duce la pierderea relevanței rezultatelor, pierderi financiare mari sau chiar accidente și dezastre. O situație în care procesarea evenimentelor are loc dincolo de timpul permis este considerată o eroare fatală într-un sistem dur în timp real. Când apare o astfel de situație, sistemul de operare întrerupe operațiunea și o blochează astfel încât, pe cât posibil, fiabilitatea și disponibilitatea restului sistemului să nu fie afectată. Exemple de sisteme hard în timp real pot fi sistemele de control la bord (pe un avion, nave spațiale, navă etc.), sistemele de protecție în caz de urgență, înregistratoarele de evenimente de urgență [5] .
Într-un sistem soft în timp real, întârzierea răspunsului este considerată o eroare recuperabilă care poate crește costul rezultatelor și poate reduce performanța, dar nu este fatală. Un exemplu este operarea unei rețele de calculatoare [6] . Dacă sistemul nu a avut timp să proceseze următorul pachet primit, acest lucru va duce la oprirea transmisiei și retrimiterea (în funcție de protocol ). Nu se pierd date, dar performanța rețelei este degradată.
Principala diferență dintre sistemele hard și soft în timp real poate fi descrisă după cum urmează: un sistem hard în timp real nu va întârzia niciodată cu o reacție la un eveniment, un sistem soft în timp real nu ar trebui să întârzie cu o reacție la un eveniment [6] .
Adesea, un sistem de operare în timp real este considerat doar un sistem care poate fi folosit pentru a rezolva probleme grele în timp real. Această definiție înseamnă că RTOS are instrumentele necesare, dar înseamnă și că aceste instrumente trebuie utilizate corect [5] .
Majoritatea programelor software sunt orientate spre soft real time. Astfel de sisteme se caracterizează prin:
Un exemplu clasic de sarcină în care este necesar un RTOS este controlul unui robot care ia o piesă de pe o bandă transportoare . Piesa se mișcă și robotul are doar o mică fereastră de timp când o poate ridica. Dacă este târziu, atunci piesa nu va mai fi în secțiunea corectă a transportorului și, prin urmare, munca nu va fi efectuată, în ciuda faptului că robotul este în locul corect. Dacă se pregătește mai devreme, atunci partea nu va avea încă timp să urce și îi va bloca calea.
De asemenea, pentru sistemele de operare, se folosește uneori conceptul de „ timpul real interactiv ”, care definește pragul minim de răspuns la evenimentele interfeței grafice, timp în care operatorul - o persoană - este capabil să aștepte calm, fără nervozitate, sistemul să reacţioneze la instrucţiunile care le-au fost date.
Tabel care compară RTOS și sistemele de operare convenționale [5] :
| OS în timp real | OS de uz general | |
|---|---|---|
| Sarcina principală | Reușiți să răspundeți la evenimentele care au loc pe echipament | Distribuția optimă a resurselor computerului între utilizatori și sarcini |
| Pe ce se concentrează | Gestionarea evenimentelor externe | Gestionarea acțiunilor utilizatorului |
| Cum este pozitionat | Un instrument pentru crearea unui complex hardware-software specific în timp real | Percepută de utilizator ca un set de aplicații gata de utilizare |
| Cine este destinat | Dezvoltator calificat | Utilizator intermediar |
În dezvoltarea lor, RTOS au fost construite pe baza următoarelor arhitecturi :
| Arhitectură monolitică | Arhitectură în etaje (stratificate). | Arhitectura client-server |
Nucleul RTOS asigură funcționarea nivelului de SO abstract intermediar, care ascunde de aplicația software specificul dispozitivului tehnic al procesorului (mai multe procesoare) și hardware asociat [7] .
Acest strat abstract oferă cinci categorii principale de servicii pentru aplicații software [7] [8] :
Pe lângă serviciile de bază, multe RTOS oferă linii de componente suplimentare pentru a organiza concepte la nivel înalt precum sistemul de fișiere , rețea, managementul rețelei, managementul bazelor de date , interfața grafică cu utilizatorul etc. Deși multe dintre aceste componente sunt mult mai mari și mai mari complexe, decât nucleul RTOS în sine, ele se bazează totuși pe serviciile sale. Fiecare dintre aceste componente este inclusă în sistemul încorporat numai dacă serviciile sale sunt necesare pentru a rula aplicația încorporată și numai pentru a menține consumul de memorie la minimum [7] .
Multe sisteme de operare de uz general acceptă și serviciile de mai sus. Cu toate acestea, diferența cheie dintre serviciile de bază RTOS este natura deterministă , bazată pe un control strict al timpului, a activității lor. În acest caz, determinismul este înțeles ca fiind faptul că execuția unui serviciu al sistemului de operare necesită un interval de timp de o durată cunoscută. Teoretic, acest timp poate fi calculat prin formule matematice , care ar trebui să fie strict algebrice și nu ar trebui să includă nici un parametru de timp de natură aleatorie. Orice variabilă aleatorie care determină timpul de execuție a unei sarcini în RTOS poate provoca o întârziere nedorită în aplicație, atunci sarcina următoare nu se va încadra în cuantumul său de timp, ceea ce va provoca o eroare [7] .
În acest sens, sistemele de operare de uz general nu sunt deterministe. Serviciile lor pot permite întârzieri aleatorii în activitatea lor, ceea ce poate duce la o încetinire a răspunsului aplicației la acțiunile utilizatorului într-un moment necunoscut cunoscut. Atunci când proiectează sisteme de operare convenționale, dezvoltatorii nu se concentrează pe aparatul matematic pentru calcularea timpului de execuție pentru o anumită sarcină și serviciu. Acest lucru nu este critic pentru acest tip de sisteme [7] .
Majoritatea RTOS efectuează planificarea sarcinilor conform următoarei scheme [7] . Fiecărei sarcini din aplicație i se atribuie o anumită prioritate. Cu cât prioritatea este mai mare, cu atât reactivitatea sarcinii ar trebui să fie mai mare. Reactivitatea ridicată este atinsă prin implementarea unei abordări de planificare a priorităților preventive , a cărei esență este că planificatorului i se permite să oprească execuția oricărei sarcini la un moment arbitrar în timp dacă se stabilește că o altă sarcină ar trebui începută imediat.
Schema descrisă funcționează conform următoarei reguli: dacă două sarcini sunt gata să ruleze în același timp, dar prima are o prioritate ridicată, iar a doua are una scăzută, atunci planificatorul va acorda preferință primei. . A doua sarcină va fi lansată numai după ce prima își va finaliza activitatea.
Este posibil ca o sarcină cu prioritate scăzută să ruleze deja și planificatorul să primească un mesaj că o altă sarcină cu prioritate mai mare este gata de rulare. Acest lucru poate fi cauzat de o influență externă (întrerupere hardware), cum ar fi o schimbare a stării comutatorului pe un dispozitiv controlat de RTOS. Într-o astfel de situație, planificatorul de sarcini se va comporta conform abordării de planificare preventivă prioritară, după cum urmează. O sarcină cu o prioritate scăzută va fi permisă să finalizeze instrucțiunea curentă a mașinii (dar nu instrucțiunea descrisă în sursa programului în limbaj de nivel înalt ), după care execuția sarcinii este suspendată [7] . În continuare, este lansată o sarcină cu o prioritate ridicată. După ce se termină, planificatorul începe prima sarcină întreruptă, cu instrucțiunea mașinii urmând ultimei executate.
De fiecare dată când planificatorul de sarcini primește un semnal despre apariția unui eveniment extern (declanșator), a cărui cauză poate fi atât hardware cât și software, acesta acționează conform următorului algoritm [7] :
Acești cinci pași ai algoritmului sunt denumiți și schimbarea sarcinilor.
În RTOS convențional, o sarcină poate fi în trei stări posibile:
De cele mai multe ori, majoritatea sarcinilor sunt blocate. Numai o sarcină poate rula pe CPU la un moment dat. În RTOS primitiv, lista sarcinilor pregătite pentru execuție este de obicei foarte scurtă, poate consta din cel mult două sau trei elemente.
Funcția principală a administratorului RTOS este de a compila un astfel de planificator de sarcini.
Dacă nu există mai mult de două sau trei sarcini în lista ultimelor sarcini gata de execuție, atunci se presupune că toate sarcinile sunt situate în ordinea optimă. Dacă există situații în care numărul de sarcini din listă depășește limita permisă, atunci sarcinile sunt sortate în ordinea priorității.
În prezent, pentru a rezolva problema planificării eficiente în RTOS, sunt dezvoltate cel mai intens două abordări [9] :
Pentru sarcini mari ale sistemului, EDF este mai eficient decât RMS.
Sistemele multitasking trebuie să distribuie accesul la resurse. Accesul simultan a două sau mai multe procese la orice zonă de memorie sau alte resurse reprezintă o anumită amenințare. Există trei moduri de a rezolva această problemă: blocarea temporară a întreruperilor , semaforele binare , trimiterea de semnale. RTOS de obicei nu utilizează prima modalitate, deoarece aplicația utilizator nu poate controla procesorul atât de mult pe cât dorește. Cu toate acestea, multe sisteme încorporate și RTOS permit aplicațiilor să ruleze în modul kernel pentru a accesa apelurile de sistem și a controla mediul de execuție fără intervenția sistemului de operare.
Pe sistemele cu uniprocesor, cea mai bună soluție este o aplicație care rulează în modul kernel și care are voie să blocheze întreruperile. În timp ce întreruperea este dezactivată, aplicația folosește singur resursele procesului și nicio altă sarcină sau întrerupere nu poate rula. Astfel, toate resursele critice sunt protejate. După ce aplicația a finalizat activitățile critice, trebuie să activeze întreruperi, dacă există. Blocarea întreruperilor este permisă numai atunci când cel mai lung timp de execuție a secțiunii critice este mai mic decât timpul de răspuns la întrerupere permis. De obicei, această metodă de protecție este utilizată numai atunci când lungimea codului critic nu depășește câteva linii și nu conține bucle . Această metodă este ideală pentru protejarea registrelor .
Atunci când lungimea secțiunii critice este mai mare decât lungimea maximă sau conține cicluri, programatorul trebuie să utilizeze mecanisme care sunt identice sau imită comportamentul sistemelor de uz general, cum ar fi semaforele și semnalizarea.
Următoarele probleme de alocare a memoriei sunt acordate mai multă atenție în RTOS decât în sistemele de operare de uz general.
În primul rând, viteza de alocare a memoriei. Schema standard de alocare a memoriei implică scanarea unei liste de lungime nedeterminată pentru a găsi o zonă de memorie liberă de o dimensiune dată, iar acest lucru este inacceptabil, deoarece într-un RTOS alocarea memoriei trebuie să aibă loc într-un timp fix.
În al doilea rând, memoria poate deveni fragmentată dacă zonele sale libere sunt împărțite de procese care rulează deja. Acest lucru poate determina oprirea programului din cauza incapacității sale de a utiliza noua locație de memorie. Un algoritm de alocare a memoriei care crește treptat fragmentarea memoriei poate funcționa bine pe sistemele desktop dacă repornesc cel puțin o dată pe lună, dar este inacceptabil pentru sistemele încorporate care rulează ani de zile fără repornire.
Un algoritm simplu cu o lungime fixă a blocurilor de memorie funcționează foarte bine în sistemele încorporate simple.
De asemenea, acest algoritm funcționează bine pe sistemele desktop, mai ales când, în timpul procesării unui bloc de memorie de către un nucleu, următorul bloc de memorie este procesat de un alt nucleu. RTOS optimizat pentru desktop, cum ar fi Unison Operating System sau DSPnano RTOS oferă această capacitate.
| Sisteme de operare în timp real | |
|---|---|
| |
| deschis | |
| Proprietate |
|
| istoric |
|
| |
| Aspecte ale sistemelor de operare | |||||
|---|---|---|---|---|---|
| |||||
| Tipuri |
| ||||
| Nucleu |
| ||||
| Managementul proceselor |
| ||||
| Gestionarea și adresarea memoriei |
| ||||
| Instrumente de încărcare și inițializare | |||||
| coajă | |||||
| Alte | |||||
| Categorie Wikimedia Commons Wikibooks Wiktionar | |||||