Curs 4 Sistemele De Operare In Timp Real

4.1. Introducere

Un sistem de operare in timp real (Real Time Operating System) este nucleul multor
sisteme dedicate din prezent, ce ofera o platforma software pe care se pot construi aplicatii
complexe.Totusi, nu toate sistemele dedicate sunt concepute sa functioneze cu un RTOS.
Este posibil ca unele sisteme dedicate cu hardware relativ simplu sau cu o dimensiune mica a
aplicatiilor software sa nu necesite un RTOS. Cu toate acestea, multe sisteme dedicate cu
aplicatii software medii spre mari au nevoie de o anumita forma de planificare a exectutie
(adica au nevoie de un RTOS).
Standardul POSIX 1003.1 defineste caracteristica de timp real a unui sistem de
operare ca fiind abilitatea sistemului de operare de a oferi nivelul necesar de servicii intr-un
timp de raspuns predefinit , relativ scurt.
Sistemele de operare in timp real sunt folosite, in principal, pentru capacitatea lor de
raspuns rapid si nu atat pentru volumul total de munca (calcule) pe care il pot efectua. Un
sistem de operare in timp real nu e nevoie sa dispuna de o viteza (putere) mare de calcul —
viteza lui de calcul este influentata nu numai de viteza de calcul a procesorului pe care
ruleaza, dar si de algoritmul specializat de scheduling, precum si de frecventa ridicata a
intreruperii de ceas.

Acest capitol descrie conceptele cheie pe care se bazeaza cele mai multe sisteme de
operare in timp real.
Concret, acest capitol ofera:
 o scurta istorie a sistemelor de operare
 o definitie a unui RTOS
 o descriere a planificatorului
 o discutie despre obiecte
 o discutie despre servicii
 caracteristicile cheie ale unui RTOS

4.2. O scurta istorie a sistemelor de operare

La inceput, dezvoltatorii au creat aplicatii software care includeau cod masina de

nivel scazut pentru a initializa si interactiona cu hardwareul sistemului decicat in mod direct.
Aceasta legatura stransa dintre software si hardware a dus la aplicatii non-portabile. O mica
schimbare in hardware ar putea duce la rescrierea unei parti semnificative din aplicatia
software. In mod evident,aceste sisteme au fost dificile si costisitor de intretinut.
Cum industria software a progresat, sistemele de operare, care asigurau software-ul
de baza pentru sistemele de calcul, au evoluat si au facilitat abstractizarea hardware-ului
pentru care este creat codul aplicatiei. In plus, evolutia sistemelor de operare a ajutat la
schimbarea designului aplicatiilor software de la cele de dimeniuni mari, monolitice la cele
modulare, interconectate, care pot rula deasupra sistemului de operare.
De-a lungul anilor, multe versiuni ale sistemelor de operare au evoluat. Acestea au
variat de la sistemele de operare de uz general (GPOS), cum ar fi UNIX si Microsoft
Windows, la sisteme in timp real mai mici si mai compacte, ca VxWorks.
 Unele asemanari functionale de baza intre un RTOS tipic si GPOS includ:
 un anumit nivel de multitasking asemanator
 gestionarea resurselor software si hardware
 furnizarea de serviciilor necesare aplicatiilor
 abstractizarea hardware necesara aplicatiei software

Pe de alta parte, unele diferente cheie care ne fac sa alegem RTOS si nu GPOS includ:
 o mai buna fiabilitate in aplicatiile dedicate
 capacitatea de a scala resursele in concordanta cu cerintele aplicatiilor
 performante mai bune
 cerinte reduse de memorie
 reguli de planificare a executiei aplicatiilor potrivite pentru sistemele dedicate in timp
real
 suport pentru sistemele dedicate fara disk, permitand executabilelor sa booteze si sa
ruleze din memorie ROM sau RAM
 portabilitate mai buna pentru diferite platforme hardware

Astazi, GPOS-urile tintesc calculul de uz general si rularea predominanta in sisteme

ca PC- uri, statii de lucru si mainframe-uri. In unele cazuri, GPOS-urile ruleaza pe dispozitive
dedicate care au o memorie extinsa si cerinte reduse de timp real. Un GPOS tipic necesita
mai multa memorie decat un RTOS. GPOS-urile nu sunt potrivite pentru dispozitivele
dedicate in timp real cu memorie limitata si cerinte de inalta performanta.
Pe de alta parte, RTOS-urile pot satisface aceste cerinte. Ele sunt fiabile, compacte si
scalabile. In plus, pot fi usor adaptate pentru utilizarea doar a acelor componente necesare
pentru o anumita aplicatie.
Este de retinut ca astazi multe dispozitive dedicate mici sunt inca construite fara un
RTOS. Aceste dispozitive simple, de obicei contin o cantitate mica pana la moderata a
codului de aplicatie.

4.3. Definitia unui RTOS

Un sistem de operare in timp real (RTOS) este un program care planifica executarea
aplicatiei intr-un timp util, gestioneaza resursele sistemului si ofera o fundatie coerenta pentru
dezvoltarea codului aplicatiei. Codul proiectat pe un RTOS poate fi diferit ca si complexitate,
variind de la o aplicatie simpla pentru un cronometru digital la o aplicatie complexa pentru
controlul navigatiei aeronavelor. Prin urmare, RTOS-urile bune sunt scalabile pentru a
satisface diferitele seturi de cerinte pentru aplicatii diferite.

RTOS-urile se impart in doua categorii:

1. sisteme "hard real time", unde lipsa raspunsurilor la diferitele deadline-uri este
critica
2. sisteme "soft real time" , unde atingerea unei deadline nu este critica si poate fi
acceptabila in anumite situatii

Conceptul RTOS a fost implementat pentru controlul sistemelor dedicate si pentru a

da raspunsuri in timp real. Aplicatiile ruleaza sub controlul RTOS, dar cu planificari
("schedules") bine definite de catre CPU. In sistemele moderne, un RTOS consta nu doar
intr-un nucleu real-time, ci in diferite functii de nivel inalt ale diferitelor componente (USB,
UART, Etharnet, LCD), fisiere de sistem (file system), magistrale (CAN, STAR,
MICROBUS, SEGBUS) si interfete grafice (GUI).
 In unele aplicatii, un RTOS contine doar un nucleu (kernel), care supervizeaza
software-ul ce realizeaza procesarile, planifica executia si face managementul de resurse a
algoritmului. Fiecare RTOS are un nucleu (kernel).
In alte aplicatii, un RTOS poate fi o combinatie de module diferite, inclusiv nucleul,
un sistem de fisiere, stive de protocol de retea, precum si alte componente necesar pentru o
anumita aplicatie, dupa cum este ilustrat la un nivel ridicat in figura 4.1.

Figura 4.1. Vedere de nivel inalt a unui RTOS: kernelul sau , precum si alte componente
gasite in sistemele dedicate.

Deoarece multe RTOS-uri pot scala in sus sau in jos pentru a indeplini cerintele
aplicatiei, ne vom concentra pe elementul comun al acestora si anume nucleul (Kernelului).
Cele mai multe nuclee de RTOS contin urmatoarele componente:
 un planificator (scheduler) care este continut in fiecare nucleu si urmeaza un set de
algoritmi ce determina care task este executat si cand. Cateva exemple comune ale
algoritmilor de planificare sunt: round robin si preemptive scheduling.
 obiecte - sunt constructii speciale ale Kernelului, care ajuta dezvoltatorii sa creeze
aplicatii pentru sistemele dedicate in timp real. Obiectele comune ale kernelului sunt:
task-uri, semafoare si cozi de mesaje.
 servicii - sunt operatiuni pe care nucleul le efectueaza pe un obiect sau, in general,
operatiuni cum ar fi timing-ul, tratarea intreruperii si gestionarea resurselor.
 Figura 4.2 ilustreaza aceste componente.

Figura 4.2. Componentele comune ale unui Kernel RTOS (obiectele, planificatorul si
unele servicii)

4.4. Planificatorul (Scheduler)

Planificatorul este inima fiecarui nucleu. Acesta ofera algoritmii necesari pentru a
determina care task este executat si cand. In continuarea vor fi prezentate urmatoarele
componente ale unui planificator:
 entitati de planificare
 multitasking
 comutarea de context
 dispetcher
 algoritmi de planificare

4.4.1. Entitati de planificare

O entitate de planificare este un obiect al nucleului care poate concura pentru timpul
de executie al unui sistem, bazandu-se pe un algoritm de planificare predefinit. Task-uril si
procesele sunt cele mai comune entitati gasite in cele mai multe nuclee.
O task este un fir de executie independent care contine o secventa de instructiuni
planificabile independent. Unele nuclee ofera un alt tip de obiect de planificare numit proces.
Procesele sunt similare cu task-urile, in sensul ca acestea pot concura independent pentru
timpul de executie al unui CPU. Procesele difera de task-uri prin aceea ca ofera caracteristici
de protectie a memoriei mai bune, in detrimetul performantei si al spatiului de memorie
ocupat.
Cozile de mesaje si semafoarele nu sunt entitati de programare. Aceste elemente sunt
folosite pentru sincronizare si comunicare.
4.4.2 Multitasking

Multitaskingul reprezinta capacitatea sistemului de operare de a gestiona multiple

activitati in termenii stabiliti. Un nucleu in timp real poate avea mai multe task-uri pe care le
poate planifica sa ruleze. Un astfel de scenariu este ilustrat in figura 4.3

Figura 4.3. Multitasking folosind un comutator de context.

In acest caz, nucleul opereaza in asa fel incat mai multe fire de executie par a rula in
acelasi timp, insa, nucleul se bazeaza de fapt pe intercalarea executiei secventiale, pe un
algoritm de planificare prestabilit. Planificatorul trebuie sa se asigura ca sarcina
corespunzatoare ruleaza la momentul potrivit.
Un punct important il reprezinta faptul ca task-urile urmeaza algoritmul de planificare
a executie, in timp de rutinele de intrerupere a serviciilor (ISR) sunt declansate sa ruleze pe
baza intreruperilor hardware si a prioritatilor deja stabilite.
Cresterea numarului de task-uri ce trebuie planificate duce la crestrea cerintelor de
performanta a procesorului. Aceasta duce si la cresterea comutatiilor intre contextele diferelor
fire de executie.

4.4.3. Comutarea de context

Fiecare task are propriul context, constând în starea regiştrilor utilizati de procesor, de
fiecare dată când acesta este programat să ruleze. Un schimb de context are loc atunci când
planificatorul (scheduler-ul) comută executia de la un task la altul. Pentru o mai bună
înţelegere a acestui proces de comutare a contextului, vom examina în detaliu ceea ce face un
Kernel în acest situaţie.
De fiecare dată când o un nou task este creat, kernelul creează şi menţine un bloc de
control al task-urilor asociate (TCB - Task Control Block). TCB-urile reprezintă structuri de
date ale sistemului pe care kernelul le foloseşte pentru a menţine informaţii despre task-urile
respective. TCB-urile conţin toate informaţiile de care kernelul are nevoie pentru a cunoaşte
un anumit task. Când un task rulează, context-ul acestuia este dinamic; acest context dinamic
este memorat în TCB-uri. Atunci când task-ul nu rulează, conţinutul acestuia este salvat în
TCB pentru ca task-ul sa poate fi reluat de unde a ramas, in momentul in care acesta va rula
din nou. În Figura 4.3 este ilustrată situaţia unui comunitatii obisnuite de context.

Aşa cum este prezentat în Figura 4.3, în momentul în care scheduler-ul kernel-ului
decide că trebuie să oprească rularea Task-ului 1 şi începe să ruleze Task-ul 2, sunt necesari
următorii paşi:
1. Kernelul salvează informaţiile contextului Task-ului 1 în TCB.
2. Kernelul începe să încarce din TCB informaţiile contextului Task-ului 2,
care devine principalul fir de execuţie.
3. Contextul Task-ului 1 este reţinut în TCB-uri atât timp cât Task-ul 2
rulează. Dacă planificatorul are nevoie să ruleze din nou Task-ul 1,
aceasta va rula continuând de unde a rămas, înainte ca respectiva
comuntare de context să se producă.

Timpul de care scheduler-ul are nevoie pentru a comuta de la un task la altul poartă
denumirea de timpul comutatiei de context. Acesta este relativ nesemnificativ, comparativ
cu majoritatea operaţiilor pe care un task le efectuează. Dacă executia unei aplicaţii include
comunitatii frecvente de context, aceasta poate duce la pierderi de performanta. Prin urmare,
aplicaţiile ar trebui proiectate în aşa manieră încât să nu conţină schimbări de context în
exces.
De fiecare dată când o aplicaţie face un "request" catre sistemul de operare,
scheduler-ul poate stabili dacă trebuie sau nu să schimbe contextul. Atunci când schedulerul
determină că o schimbare a contextului este necesară, el se bazează pe un modul asociat
pentru a realiza schimbul. Acest modul se numeste DISPATCHER.

4.4.4. Dispatcher-ul

Dispatcher-ul reprezintă acea partea a planificatorului (scheduler-ului) care efectuează

schimbul de context şi schimbă fluxul de execuţie. De fiecare dată când RTOS-ul (Sistemul
de Operare în Timp Real) rulează, fluxul de execuţie, cunoscut şi ca fluxul de control, trece
prin una dintre următoarele trei etape: printr-un task al aplicatie, printr-un ISR (serviciu de
întrerupere) sau prin Kernel. Atunci când un task sau un ISR (serviciul de întrerupere)
apelează sistemul de operare, fluxul de control este transferat kernelului pentru a executa una
dintre rutinele furnizate de kernel. Cand fluxul de control ajunge la momentul in care trebuie
sa paraseasca kernelul, dispatcherul devine responsabil de trimiterea controlului la unul din
task-urile aplicatiei definite de programator. Aceste nu trebuie sa fie neaparat acelasi task cu
cel care a apelat iniţial sistemul de operare.
Algoritmii de planificare (analizaţi în partea care va urma) ai scheduler-ului sunt cei
ce determină ce sarcină urmează a fi executată, dispatcherul fiind de fapt, cel care execută
schimbarea contextului şi transfera controlului executiei.

4.4.5. Algoritmii de planificare a executiei

După cum a fost menţionat mai sus, scheduler-ul determina ce task va rula, după un
anumit algoritm de planificare (cunoscut şi sub numele de politică de planificare/
programare). Majoritatea kernel-urilor din ziua de astăzi suporta două tipuri de algoritmi de
planificare:
 Preemptive Scheduling
 Round Robin
 Producătorul RTOS-ului (Sistemelor de Operare în Timp Real) predefineşte, de
obicei, aceşti algoritmi; totuşi, în unele cazuri, dezvoltatorii pot crea şi defini proprii lor
algoritmi de planificare. Fiecare algoritm este descris după cum urmează:

 Preemptive Scheduling (planificare bazată pe prioritate)

Dintre cei doi algoritmi de planificare prezentaţi aici, cele mai multe kernel-uri
folosesc planificarea preventivă bazată pe prioritate în mod implicit. După cum este descris în
Figura 4.4, cu acest tip de planificare, task-ul care poate rula în orice moment, este acel task
care are cea mai mare prioritate în faţa celorlalte taks-uri - gata de a fi rulate oricând de către
sistem.

Figure 4.4: Preemptive priority-based scheduling.

Kernelul de tip “timp real” suportă în general 256 de nivele de prioritate, dintre care
nivelul 0 are cea mai mare prioritate, iar nivelul 255 cea mai mică prioritate. Unele kernel-uri
îşi stabilesc priorităţile în ordine inversă, unde nivelul 255 este cel mai înalt nivel (prioritate
cea mai mare), iar nivelul 0 cel mai scăzut (prioritatea cea mai mică). Oricum ar fi, conceptul
este practic acelaşi. Cu o planificare preventivă bazată pe prioritate, fiecare task are o anumită
prioritate, iar task-ul cu cea mai prioritate rulează primul. Dacă un task cu o prioritate mai
mare decât altuk devine aptde a rula, kernelul salvează imediat contextul task-ului curent în
TCB (blocul de control al task-urilor asociate) şi comută la task-ul cu prioritatea mai mare.
După cum este descris în Figura 4.4 , Taskul 1 este precedat de Taskul 2 care are o prioritate
mai mare, iar aceasta la rândul lui este precedat de Taskul 3. Când Taskul 3 este finalizat,
Taskul 2 este reluat şi, de asemenea, când Taskul 2 este finalizat, Taskul 1 este reluat.
Rularea task-urilor are loc în functie de nivelul de prioritate si de timp.
Deşi fiecărui task îi este asignat o prioritate în momentul în care este creat, această
prioritate a task-ului poate fi schimbată dinamic folosind rutinele din kernel. Capacitatea de a
schimba dinamic priorităţile task-urilor, ofera unei aplicaţii dedicate flexibilitatea de a se
adapta la evenimente externe imediat cum acestea apar, creând un sistem cu răspuns în timp
real. Trebuie reţinut, totuşi, că folosireea in exces a acestei capacitati poate duce la inversarea
prioritatilor, deadlock sau la aparitia unor erori.

 Round Robin (planificare aleatorie)

Planificarea Round Robin, oferă fiecărui task, o parte egală din timpul de execuţie al
unităţii de procesare. Planificările strict aleatorii nu pot satisface cerinţele unui sistem de tip
”Real Time” deoarece în cazul acestora, task-urile executate au diferite grade de importanţă.
În schimb, planificarea preventivă bazată pe prioritate, poate fi imbunatatita cu planificarea
Round Robin, folosind astfel divizarea timpului de executie pentru a alocarea egala a unitatii
de procesare in cazul task-urilor cu prioritati egale.
 Figure 4.5: Round-robin and preemptive scheduling.

Prin divizarea timpului, fiecare task rulează pentru un interval definit sau pentru o
bucată de timp, într-un ciclu continuu, definit de modelul Round Robin. Un contor urmăreşte
bucata de timp alocată fiecărui task si se auto-incrementeaza la fiecare tact. Atunci când se
termină bucata de timp acordată unei task, contorul este resetat, tassk-ul fiind plasat la
sfârşitul ciclului. Noile task-uri adăugate, ce au aceeaşi prioritate, sunt plasate la sfârşitul
ciclului, având contoarele ce înregistrează timpul iniţializate la 0.
Dacă un task dintr-un ciclu de tip ”round-robin”, este precedat de un task cu o
prioritatea mai mare, contorul acestuia este salvat şi reluat, atunci când task-ul întrerupt este
din nou gata de execuţie. Acest concept este ilustrat în Figura 4.5, în care Task-ul 1 este
precedat de Task-ul 4, ce are o prioritate mai mare. Task-ul 1 va fi reluat de unde a rămas, în
momentul în care Task-ul 4 este finalizat.

4.5. Obiecte

Obiectele kernelului sunt construcţii speciale ce fundatia dezvoltarii aplicaţiilor pe

sisteme dedicate de timp real. Cele mai comune obiecte ale kernelurilor RTOS sunt:
 Task-urile – sunt fire concurente şi independente de executie, care pot concura la
timpul de execuţie ale unităţii de procesare.
 Semafoarele – sunt obiecte de tip "token" care pot fi incrementate sau decrementate
de task-uri si sunt folosite pentru sincronizare sau excludere mutuala.
 Cozile de mesaje – sunt structuri de date de tipul "buffer" care pot fi utilizate pentru
sincronizare si excludere mutuala, precum şi pentru schimb de date prin transmiterea
unor mesaje între task-uri.

Dezvoltatorii care proiecteaza aplicatii pentru sisteme dedicate in timp real pot
combina aceste tipuri standard de obiecte ale kernelului (dar şi altele care nu sunt menţionate
aici) pentru a soluţiona în timp real, probleme comune de design, precum executia
concurentă, activităţiile sincronizate sau transferul de date.

4.6. Servicii

Împreună cu obiectele, majoritatea kernelurilor furnizează şi servicii ce pot ajuta

dezvoltatorii să creeze aplicaţii pentru sisteme dedicate în timp real. Aceste servicii cuprind
seturi API (Aplication Programming Interface ) care pot fi folosite pentru a efectua operaţii
cu obiectele kernelului, sau pot fi utilizate în general pentru a facilita gestionarea timpului, a
memoriei, dar şi pentru a facilita folosirea dispozitivelor de tip I/O (intrare/ieşire). Pot fi
furnizate şi alte tipuri servicii, dar acestea sunt cel mai des întâlnite în kernelurile RTOS.
4.7. Caracteristicile principale ale RTOS-ului

Cerinţele unei aplicaţii definesc cerinţele RTOS-ului ei de bază. Unele dintre cele mai
comune cerinţe sunt:
 Fiabilitate
 Predictibilitate
 Performanţă
 Compact
 Scalabilitate

4.7.1 Fiabilitate

Una dintre cerinţele importante ale sistemele dedicate este aceea că acestea trebuie să
fie fiabile. În funcţie de aplicaţie, sistemul trebuie să fie capabil să poată opera pentru
perioade lungi de timp, fără a fi necesară intervenţia umană.
Diferite grade de fiabilitate pot fi necesare. De exemplu, un calculator digital cu
energie solară s-ar putea reseta singur, în cazul în care nu primeste suficientă lumină, acest
lucru fiind acceptabil. Pe de altă parte, un switch de telecomunicaţii, nu se poate reseta în
timpul funcţionării, fără a suporta costurile ridicate asociate “timpului mort”. RTOS-urilor
acestor aplicatii necesită, deasemenea, diferite grade de fiabilitate.
Deşi sunt acceptate diferite grade de fiabilitate, în general, un sistem fiabil este
considerat acel sistem care este disponibil continuu. Un mod comun în care dezvoltatorii
clasifică sistemele de înaltă fiabilitate, constă în cuantificarea nefuncţionării sistemelor pe o
perioadă de un an, aşa cum este redat în Table 4.1. Procentele prezentate în prima coloană
denumită “Number of 9s” , indică procentele din timpul total în care un sistem trebuie să fie
disponibil.
Fiabilitatea unui sistem este dată de combinarea tuturor elementelor sistemelui. Ca şi
elemente, putem include componentele hardware, BSP, RTOS, şi aplicaţii.

Table 4.1: Categorizing highly available systems by allowable downtime.1

Number of 9s Downtime per year Typical application
3 Nines (99.9%) ~9 hours Desktop
4 Nines (99.99%) ~1 hour Enterprise Server
5 Nines (99.999%) ~5 minutes Carrier-Class Server
6 Nines (99.9999%) ~31 seconds Carrier Switch Equipment
1 Source: 'Providing Open Architecture High Availability Solutions,' Revision 1.0,
Published by HA Forum, February 2001.

4.7.2 Predictabilitate

Deoarece multe sisteme dedicate sunt sisteme în timp real, satisfacerea cerinţelor în
timp sunt esenţiale pentru funcţionarea corespunzătoare. RTOS- folosit în acest caz, trebuie
să fie previzibil la un anumit grad. Termenul determinist, descrie comportamentul predictabil
al unui RTOS, în care finalizarea apelurilor la sistemul de operare are loc în termeni
cunoscuţi.
Dezvoltatorii pot scrie programe simple de referinţă pentru a valida determinismul
unui RTOS. Rezultatul se bazează pe timpul de răspuns. Într-un Sistem de Operare în Timp
Real determinist, variaţia timpilor de răspuns pentru fiecare tip de apel la sistem este foarte
mic.

4.7.3 Performanţa

Această cerinţă impune ca un sistem dedicat să opereze suficient de rapid pentru a

îndeplini cerinţele de sincronizare. De obicei, cu cât mai multe termene de deadline sunt
respectate şi perioada de timp dintre ele este mai scurtă, cu atât procesorul sistemului trebuie
să fie mai rapid. Deşi componente hardware adiacentă, poate dicta puterea de procesare într-
un sistem, componenta software poate contribui, de asemenea, la performanţele sistemului.
De obicei, performanţa procesorului este exprimată în milioane de instructiuni pe secundă
(MIPS).
"Throughput-ul" măsoară, de asemenea, performanța generală a unui sistem,
combinând hardware-ul şi software-ul. O definiţie a "throughput-ului", este dată de rata la
care un sistem poate genera date de ieşire pe baza datelor de intrare. "Throughput-ul" este dat
de cantitatea de date transferate, divizata de timpul necesar pentru a le transfera.
"Throughput-ul" transferului de date, este de obicei măsurat în multiplii de biţi pe secundă
(bps).

4.7.4 Compact

Constrângeri de proiectare a aplicatiilor şi constrângerile de cost determină cât de

compact poate fi un sistem integrat. De exemplu, un telefon mobil în mod clar trebuie să aibă
o dimensiune mică, redusă, costurile să fie mici, şi bineînţeles să fie portabil. Aceste cerinţe
de proiectare, limitează memoria sistemului, care la rândul său limitează dimensiunea
aplicaţiilor şi funcţionalitatea sistemului.
În astfel de sisteme dedicate, în care hardware-ul este limitat din cauza dimensiunilor
și costurilor, RTOS-ul, în mod clar, trebuie să ocupe putina memorie şi sa fie eficient. În
astfel de cazuri, amprenta de memorie a RTOS-urilor poate reprezenta un factor important.
Pentru a îndeplini cerinţele totale ale sistemului, proiectanţii trebuie să aibă în vedere
consumul de memorie statică şi dinamică atat al RTOS-ului cât şi al aplicaţia care va rula pe
el.

4.7.5 Scalabilitate

Deoarece RTOS-urile pot fi folosite într-o varietate de sisteme dedicate, acestea

trebuie să fie în măsură să scaleze pentru a satisface cerinţele specifice aplicaţiei. În funcţie
de aplicabilitatea necesară, un RTOS ar trebui să fie capabil să adauge sau să elimine
componente modulare, incluzând sistemele de fişiere şi stive de protocol.
Dacă un RTOS nu scalează bine, echipele de dezvoltare ar fi nevoite să cumpere sau
dezvolte modulele lipsa.
Să presupunem că o echipă de dezvoltare doreşte să utilizeze un RTOS pentru a
dezvolta un brat robotic şi o camera video de securitate. Dacă un RTOS scalează bine,
acelaşi RTOS poate fi folosit în ambele proiecte, în locul utilizării a două RTOS-uri diferite,
economisind astfel timp şi bani.
4.8 De retinut

Ideile principale de care ar trebui să ne amintim sunt:

 RTOS-urile sunt potrivite pentru sistemele dedicate in timp real specifice

aplciatiilor; GPOS-urile (Sistemele de Operare de uz General) sunt folosite pentru
sisteme de uz general.
 RTOS-urile sunt programe care planifica executie in timp a task-urilor,
gestioneaza resursele sistemului si ofera o baza solida pentru dezvoltarea codului
aplicatiei
 Kernelul este modulul central al oricarui RTOS si contine: obiectele kernelului,
servicii si scheduler-ul (panificatorul executiei)
 Kernelul poate contine algoritmi diferiti pentru planificarea executiei task-urilor.
Cei mai comuni doi algoritmi sunt: Preenptive Priority Based Scheduling si
Round Robin Sccheduling
 RTOS-urile pentru sisteme dedicate trebuie sa fie fiabile, predictibile din punct de
vedere al timpului de executie, cu performante ridicate, compacte din punct de
vedere al resurselor ocupate si scalabile.