Programarea aplicațiilor

de timp real
CURS 05
Gestionarea proceselor într-un
sistem de operare în timp real

Titular curs: Conf. dr. ing. Florin Dragomir
 Sistemul  de  Operare  face  parte  din  Software­ul  de  bază 
(programe și  date  de  sistem),  care  coordonează funcționarea 
de  ansamblu  a  sistemului;  asigură  prelucrearea  de  date 
desfășurate de calculator. Acesta asigură exploatarea eficace a 
resurselor  Hardware  și  Software  ale  mașinii  de  calcul, 
furnizând  suportul  necesar  pentru  dezvoltarea  și  execuția 
programelor de aplicație. 
 Modelul abstract al unui sistem de calcul

În Figura se poate observa modelul  abstract al  unui  sistem de calcul,  ce 

poziționează  Sistemul  de  Operare  între  stratul  Hardware  și  stratul  de 
Aplicații, putând fi considerat un veritabil middle­ware, un liant între cele 
două straturi.
Sistemul de Operare execută sarcini de bază, cum ar fi:

Controlul și alocarea memoriei
Exemplu: când este lansat un joc video în execuție pe un sistem de calcul este alocată 
memorie pentru variabilele acestuia
Prioritizarea cererilor sistemului
Exemplu: butonul ,,eject” într­un avion militar de vânătoare are prioritate mai mare 
decât sistemul de control al luminilor
Facilitează conexiunea la rețea
Exemplu: Network Interface Card (NIC) conectează calculatorul la rețea
Managerizează fișierele
Exemplu: My Computer oferă acces la hard disk drive (HDD) sau solid state drive 
(SSD), și perifericele externe, cum ar fi memoriile externe: stick USB extern, HDD 
     extern, unități optice externe și/sau interne. 
          Altfel spus, un Sistem de Operare reprezintă o platformă pentru alte      
aplicații. 
DEFINIREA UNUI SISTEM DE OPERARE
ÎN TIMP REAL
Un sistem de operare în timp real (RTOS – Real Time Operating System) este o 
clasă de Sistem de Operare special dedicată aplicațiilor în timp real. Astfel de aplicații sunt 
sistemele îmbarcate (embedded), roboții industriali, navele spațiale, și așa mai departe. 

Exemple de Sisteme de Operare în Timp Real:
 
Green Hills Software INTEGRITY
 Wind River VxWorks
 QNX Neutrino
 FreeRTOS
 Micrium µC/OS­II, III
 Windows CE
 TI­RTOS Kernel (previously called DSP/BIOS)
 RTEMS open source RTOS designed for embedded systems, mainly 
used for missile and space probes control
 RT­Preempted Linux

* Conform unui studiu realizat în anul 2014 [7], aceste 10 sisteme de operare în timp real sunt primele 
utilizate pe piața sistemelor integrate. 
 HARD VS. SOFT RTOS
Hard  Real  Time  înseamnă  că  toate  deadline­urile  sunt  respectate.  Orice 
eveniment  va  fi  procesat  și  răspunsul  emis  într­un  interval  predefinit,  indiferent  de 
încărcarea  sistemului.  În  următoarea  figură  poate  fi  observată  descrierea  unui  astfel  de 
sistem Hard Real Time OS. 

Figura 2 Hard Real Time
 HARD VS. SOFT RTOS
Pentru a obține orice tip de date analitice despre comportamentul unui program 
într­un mediu hard­real­time, anumite aserțiuni trebuie făcute despre acest tip de mediu. 
Nu toate aceste aserțiuni sunt absolut necesare. [9]
 
 
[A1]  –  Cererile  pentru  toate  task­urile  pentru  care  deadline­urile  hard  există  sunt 
periodice, cu intervale constante între cereri.
[A2]  –  Deadline­urile  conțin  doar  abilități  de  rulare cu  constrângeri –  așadar, orice task 
trebuie să fie executat înainte ca următoarea cerere să apară.
[A3]  –  Taskurile  sunt  independente,  cererile  pentru  un  anumit  task  nu  depind  de 
inițializarea sau de executarea cu success a cererii pentru alte task­uri.
[A4] – Timpul de rulare pentru fiecare task este constant pentru acel task și nu variază cu 
timpul.  Timpul  de  rulare face referință la  timpul  în  care procesorul îl  asigură executării 
unui task fără întreruperi.
[A5]  –  Toate  task­urile  aperiodice  din  sistem  sunt  speciale;  ele  sunt 
inițializate sau rutini de recuperare a eșecurilor; ele înlocuiesc task­urile 
periodice cât timp acestea se execută, și nu au deadline­uri hard, critice. 
 HARD VS. SOFT RTOS

Aserțiunea A1 complementează idea lui Martin [8], dar pare 
să fie validă pentru controlul proceselor pur. 
Aserțiunea  A2  elimină  problema  listei  de  așteptare  pentru 
taskuri  individuale.  Ca  aserțiunea  A2  să  fie  ținută  în  picioare,  o 
cantitate  minusculă,  dar  posibil  signifiantă  de  zonă  tampon 
hardware (buffer) trebuie să existe pentru fiecare funcție periferică. 
Orice buclă  de  control  închisă  în  sistemul  de  calcul  trebuie  să  fie 
proiectată să permit cel puțin o unitate de eșantionare cu întârziere. 
 
 
 HARD VS. SOFT RTOS

De  menționat  este  faptul  cu  aserțiunea  A3  nu  exclude 

situația  în  care apariția unui  task  Tj  poate urma numai  un  număr 
anume  (fix),  să  spunem  N,  de  apariții  a  taskului  Ti.  O  situație  de 
acest fel poate fi modelată prin alegerea perioadelor taskului Ti și Tj 
astfel încât perioada de Tj este N de înmulțit cu a N­a cerere pentru 
Ti și va coincide cu prima cerere pentru Tj și așa mai departe.
 HARD VS. SOFT RTOS
Timpul  de rulare în  aserțiunea  A4  poate fi  interpretat ca  timpul 
maxim  de  procesare pentru  un  task.  În  acest  fel  timpul  necesar 
contabilizării  (bookkeeping)  necesare  pentru  cererea  unui 
succesor și  costurile  preempțiunilor poate fi  luat  în  considerare. 
Deoarece  existența  unor  memorii  mari  principale  din  care 
programele  sunt  executate  și  suprapunerea  transferurilor  dintre 
spațiile de stocare principale și  auxiliare și  execuția programelor 
în  sisteme  de  calcul  modern,  aserțiunea  A4  ar  trebui  să  fie  o 
aproximație  bună,  chiar  dacă  nu  este  exactă.  Aceste  aserțiuni 
permit  caracterizarea/descrierea completă a unui  task  prin  două 
numere: perioada de cerere și timpul de rulare. 
Rata de  cerere a unui task este definită a fi 
reciprocă perioadei de cerere a task­ului 
respectiv.
 HARD VS. SOFT RTOS

Un  algoritm  de  scheduling  este  un  set  de  reguli  care 
determină  taskul  care  urmează  să  fie  executat la  un  moment  dat. 
Algoritmii  de  scheduling  specificați  în  această  lucrare  sunt  cei 
preemptivi  și  cei  determinați  de  priorități  (priority­driven).  Acest 
lucru înseamnă că ori de câte ori există o cerere pentru un task care 
are o prioritate mai mare decât cel executat în mod curect, procesul 
ce  rulează  este  întrerupt  imediat  și  task­ul  cu  cererea  nou  creată 
este pornit. 
 HARD VS. SOFT RTOS

Așadar  specificațiile  acestor  algoritmi  se  rezumă  la 

specificarea unei metode de asignare a priorității pentru taskuri. Un 
algoritm de scheduling se presupune a fi static dacă prioritățile sunt 
asignate  taskurilor  o  dată  pentru  toate.  Un  algoritm  static  de 
scheduling  este  de  asemenea  definit  ca  fiind  un  algoritm  de 
scheduling  fix.  Un  algoritm  de  scheduling  se  spune  că  este  mixt 
dacă  prioritățile  unora  dintre  taskuri  sunt  fixate,  dar  prioritățile 
taskurilor ce rămân variază de la cerere la cerere. [9]
 HARD VS. SOFT RTOS

Figura 3 Executarea lui Ti între cererile lui Tm
 HARD VS. SOFT RTOS

Se va deriva o regulă asignarea de priorități care dorește a fi 
un algoritm de scheduling  optim,  static.  Un concept important în 
determinarea  acestei  reguli  este  acela  ca  un  task  de  a  fi  instant 
critic. Deadline­ul (timpul limită) pentru o cerere a unui task este 
definit  a  fi  timpul  pentru  următoarea  cerere  pentru  același  task. 
Pentru un set de taskuri programate cu un algoritm de scheduling, 
se poate spune că un overflow se întâmplă la timpul  t,  dacă t este 
deadline­ul unei cereri neîmplinite.
 HARD VS. SOFT RTOS

Pentru un set de taskuri date, un algoritm de scheduling este 
fezabil  dacă  taskurile  sunt  programate  în  așa  fel  încât  nu  se 
întâmplă niciun eveniment de tipul overflow. Se definește răspunsul 
de timp la o cerere pentru un anumit task a fi durata de timp dintre 
cerere  și  sfârșitul  răspunsului  la  cererea  respectivă.  Un  critical 
instant  pentru  un  task  este definit a  fi  un  instant  în  care o  cerere 
pentru  acel  task  va  avea  cel  mai  mare  timp  de  răspuns.  O  zonă 
critică temporală (critical time zone) pentru un task este intervalul 
de timp dintre un critical instant și sfârșitul răspunsului la cererea 
ce corespunde  pentru task.
 HARD VS. SOFT RTOS

Teoremă. Un critical instant pentru orice task are loc ori de câte ori 
taskul are o cerere simultană cu alte cerere pentru taskuri de 
priorități mai mari. 
 HARD VS. SOFT RTOS
Demonstrație. Fie T1, T2, ...Tm un set de taskuri ordonate pe prioritate cu 
Tm  –  taskul  cu cea mai  mică prioritate. Se consideră o cerere particulară 
pentru Tm  care se întâmplă la timpul  t1.  Presupunem că între t1  și  t1+Tm, 
timpul  când  cererea    Tm  apare,  cererea  pentru  taskul  Ti,  cu  i<m,  se 
întâmplă la t2,  t2+Ti,  t2+2Ti,...,t2+kTi,  așa cum este ilustrat în Figura 3.  În 
mod evident, preempțiunea lui Tm prin Ti, dacă nu este cerut pentru Tm 
este finalizat înainte de t2. Mai mult, din Figura 3 se poate realiza faptul că 
avansarea timpului  cererii  t2  nu  va  repezi  finalizarea  lui  Tm.  Timpul  de 
finalizare  pentru  Tm  este  ori  neschimbat,  ori  încetinit  de  un  asemenea 
avans. Întârzierea în finalizarea task­ului  Tm este cea mai mare atunci 
când t2 coincide cu t1. 
Repetând  argumentul  de  mai  sus  pentru  toate  valorile 
Ti din interval, i=2, ... , m­1, se poate dovedi teorema 
(inducție matematică). 
HARD VS. SOFT RTOS

Figura 4 Scheduling-ul pentru două taskuri 
 HARD VS. SOFT RTOS
Una din valorile acestui rezultat este că o calculare simplă și directă poate 
determina dacă sau dacă nu o prioritate dată,  asignată,  va rezulta cu  un 
algoritm de scheduling fezabil. Dacă cererile pentru toate taskurile sunt la 
instantele lor critice și sunt împlinite înainte de deadline­urile lor, atunci 
algoritmul de scheduling este fezabil. Spre exemplu, considerăm un set de 
două  taskuri  T­1    =  2  și  T2  =  5,  și  timpii  de  rulare aferente taskurilor T1  , 
respectiv T2,  C1  =  1  și  C2  =  1.  Dacă T1  este taskul  cu  prioritate mai  mare, 
atunci  din  Figura  4  (a)  se  poate  observa  că  o  asignare  de  prioritate  de 
acest fel este fezabilă. Mai  mult,  valoarea lui  C2  poate fi  crescută maxim 
până la valoarea 2, dar nu mai mult, așa cum reiese din Figura 4 (b). Pe de 
cealaltă parte, dacă T2 este taskul cu prioritate mai mare, atunci niciunul 
din  valorile C1  și  C2  poate fi  crescută peste valoarea 1, 
așa cum  este prezentat în Figura4(c).
 HARD VS. SOFT RTOS
Soft Real Time înseamnă că toate evenimentele tolerează întârzieri
și răspunsul poate să nu fie cel mai bun calitativ. De exemplu, un
player video poate pierde cadre în timp ce rulează un fișier. În Figura 3
poate fi observată descrierea unui astfel de sistem Soft Real Time OS.

Figura 5 Soft Real Time
 HARD VS. SOFT RTOS

Exemplu:
Soft Real Time este pentru utilizatorii care sunt mulțumiți 
că  sistemul  răspunde  optim,  dar  care  nu  consider  că  a  apărut  o 
eroare catastrofală dacă sistemul nu îndeplinește cerințele lor de 
fiecare dată. Un Soft Real Time oferă răspunsul dorit de cele mai 
multe ori. 
 
 SO Monolitic vs. SO Micro-Kernel
Kernel  Monolitic:  modulele  Sistemului  de  Operare, 
aplicațiile, driverele și protocoalele sunt conectate împreună printr­
un singur modul.

Figura 6 Kernel Monolitic – Fără erori

 SO Monolitic vs. SO Micro-Kernel
  Orice  eroare  într­unul  din  module  va  conduce  la 
compromiterea întregului sistem.

Figura 7 Kernel Monolitic – Eroare => Compromiterea întregului sistem

 SO Monolitic vs. SO Micro-Kernel
Micro­Kernel:  OS,  aplicațiile,  driverele și  protocoalele sunt 
module diferite.

Figura 8 Micro-Kernel – Fără erori
 SO Monolitic vs. SO Micro-Kernel
Defectarea unui modul nu va corupe întregul sistem, ci doar 
acel modul.

Figura 9 Micro-Kernel – Eroare => Nu este compromis întregul sistem
 SO Monolitic vs. SO Micro-Kernel
Comparație între SO ce utilizează Kernel Monolitic și cele ce 
utilizează Micro – Kernel:
Micro Kernel — Avantaje

Micro-
Caracteristici Kernel Monolitic
Kernel

Memorie protejată pentru procesele sistemului Nu Da

Protecție la erori pentru procesele kernelului Nu Da

Protecție la erori pentru driverele de dispozitive Nu Da

Protecție la erori pentru fișierele de sistem Nu Da

Upgrade Software pentru infrastructură, procese, drivere Nu Da

DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Proces: un program în execuție
•  Instanțe  ale  programelor  care  sunt 
executate
•  Zone de memorie virtuală
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Task: subprogram care rulează în contextul unui proces
•  Mai multe threaduri pot să ruleze în zona de memorie 
a unui singur proces
•  Taskurile impart o zonă de memorie comună
•  În POSIX (Linux și Windows OS) task  thread
•  În Știința Calculatoarelor, un fir de execuție (thread of 
execution) este cea mai mică secvență de instrucțiune 
programată care poate fi administrat independent de un 
scheduler, care este o parte a unui Sistem de Operare. 
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Multitasking: execuția mai multor task­uri care 
împart resursele comune ale CPU – Unitatea 
Centrală de Prelucrare
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Procesul poate fi considerat o casă
•Casa utilizează teren (spațiu de memorie)
•Are multe facilități
•Când nu este locuită, este ,,idle”
 
Taskul poate fi considerat un locuitor din acea casă
•Persoana locuiește în interiorul casei
•Folosește facilitățile casei Figura 10 Sistem embedded Real Time – procese
•Mai multe persoane pot locui simultan acolo și taskuri

•Aceste persoane impart și au acces la aceleași resurse
•Când mai multe persoane vor să acceseze grupul sanitar, se impune o politică de 
,,share”.
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING
Structura unui task
 
Informațiile despre fiecare task sunt salvate în ,,Task Control 
Blocks” (TCB), care este o mică bază de date din memorie. Fiecare 
Task are propriul TCB. Acesta salvează informațiile taskului precum 
și  informații  externe,  cum  ar  fi  regiștrii  CPU.  Taskurile pot  trece 
dintr­o stare în alta, deoarece în TCB există un snapshot al taskului 
care poate fi accesat imediat. 
Fiecare task are asignată o prioritate.
Taskul este creat de o acțiune care se numește 
,,Spawn”.
DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Figura 11 Structura unui Task

 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING
Un task poate fi în una din următoarele stări, dependente de SO, așa cum reiese din Figura 12: 

Figura 12 Stările unui Task
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

Comutarea contextuală (Context Switching)
 
Este procesul de salvare/reîncărcare (store/restore) al unei stări. Task 
Context Switching este procesul tranzitoriu de la o stare la alta. 
Exemplu:
•  Taskul A este Pended și gata de a fi lansat în execuție(Figura 13)

Figura 13 Starea taskului A
 DEFINIREA PROCESELOR, TASK-URILOR.
MULTITASKING

•  Comutarea contextuală va salva starea taskului current și va 
restaura CPU la starea de dinainte ca taskul A să fie Pended
•  Taskul A este ready și este executat de CPU
•  Task Context Switch finalizat cu succes => Figura 14

Figura 14 Comutarea contextuală
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Tehnicile de planificare în timp real pot fi împărțite în mare 
măsură după două categorii: statice și dinamice. 
Algoritmii statici  atribuie priorități  la timpul  de proiectare 
(înainte  ca  procesele  să  fie  lansate  în  execuție).  Toate prioritățile 
atribuite rămân constant pe toată durata de viață a unui process. 
Algoritmii dinamici  atribuie priorități  în  timpul  rulării,  pe 
baza unor parametric de execuție a proceselor. 
ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Figura 15 Clasificarea algoritmilor de planificare a proceselor în timp 
real
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Planificarea dinamică  poate fi,  fie cu  prioritate static  fie cu 

prioritate dinamică. Rate Monolithic, Deadline Monolithic și Fixed 
Priority sunt exemple de planificare dinamică,  cu  prioritate static. 
Earliest Deadline First, Feedback EDF, Maximum Urgency și Least 
Slack Time First sunt exemple de planificare dinamică, cu prioritate 
dinamică.  Algoritmii  EDF  și  LST  sunt  optimi  în  condițiile  în  care 
task­urile  sunt  preemptive,  există  doar  un  singur  processor,  iar 
acesta nu este supraîncărcat, dar performanța lor scade exponențial 
în cazul în care sistemul devine puțin mai încărcat.
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

 Rate Monotonic 
 
Planificatorul Rate Monotonic acordă o mai mare prioritate 
proceselor cu perioade mai mici. Prin urmare, ori de câte ori un set 
de procese sunt programate cu programatorul Rate Monotonic, 
procesele sunt întotdeauna prioritizate în aceeași ordine. Din acest 
motiv, Rate Monotonic este considerat un algoritm de planificare 
dinamic cu prioritate statică. Rate Monotonic este un algoritm 
stabil, simplu de înțeles și ușor de implementat. Dezavantajele 
acestui algoritm sunt utilizarea scăzută a CPU­
ului și  faptul că se ocupă doar de procese independente. 
ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Figura 16 Exemplu de planificare cu algoritmul Rate Monotonic 
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS
Earliest Deadline First
 
Algoritmul  EDF  acordă  prioritate  proceselor  cu  cel  mai 
apropiat deadline. În timp ce sistemul execută, deadline­ul fiecărui 
process  se  va  schimba  în  raport  cu  timpul  current  al  sistemului. 
Deși  fiecare  dintre  deadline­uri  se  va  schimba  cu  o  cantitate 
identică  de  timp în  raport unul  cu  altul,  EDF  este un  algoritm de 
planificare  dinamică  cu  prioritate  dinamică.  El  este  simplu  și 
lucrează  bine  în  teorie.  Este  un  algoritm  optimal  ce  are  cea  mai 
bună utilizare a CPU­ului, însă este greu de implementat și instabil 
(dacă un process nu  își  atinge deadline­ul,  sistemul  devine 
instabil și orice  process ulterior poate să eșueze). 
ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Figura 17 Exemplu de planificare cu algoritmul EDF
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS
Least Slack Time First
  Algoritmul  LSTF  acordă  prioritate  procesului  cu  cea  mai 
mică cantitate de „slack”. „Slack”  este definit ca deadline­ul  minus 
munca rămasă.  Un proces cu  un  număr mare de „slack”  va avea o 
prioritate  mai  mică  în  raport  cu  un  proces  cu  un  număr  mic  de 
„slack”. Procesul cu un număr mic pentru un deadline și un număr 
mare  pentru  cantitatea  rămasă  de  muncă  va  avea  cea  mai  mare
prioritate.  Acest  algoritm  poate  fi  implementat  cu  un  minim  al 
timpului de angajament al unui proces pentru a preveni o oscilație 
rapidă  între  procese  atunci  când  preemțiunea  este  inclusă.  Când
toate  procesele  din  volumul  de  lucru  au  „slack­ul” 
diferit doar prin minimul timpului de angajament  al 
unui  proces  atunci  planificatorul  LSTF  este  esenţial 
identic cu cel RR.[6]
ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Figura 18 Exemplu de planificare cu algoritmul LSTF
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS
Round Robin
 
Algoritmul RR alocă un interval de timp specificat pentru 
fiecare proces al cărui lungime este cunoscută sub numele de 
cuantă de timp. Ordinea proceselor este aceeaşi ca ordinea în care 
au
ajuns ele în sistem. Din acest punct de vedere, algoritmul RR se 
aseamană cu FIFO. În cazul în care un task este gata de a fi executat 
dar nu mai are nimic de facut atunci următoarul task, în aceeași
ordine, este verificat.  
 ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Acest ciclu continuă până când se găseşte un proces 
care are ceva de făcut în ciclul curent sau până când sunt 
verificate toate procesele. În cazul în care nu există niciun 
proces cu ceva de executat, atunci sistemul nu face nimic 
util în acest ciclu. Dacă există un proces cu ceva de făcut 
în ciclul curent atunci procesul este lansat și executat 
pentru un timp egal cu cuanta de timp. [5]
ALGORITMI DE GESTIONARE A PROCESELOR ȘI ALE
TASKURILOR ÎN RTOS

Figura 19 Exemplu de planificare cu algoritmul RR
 DEFINIREA PROCESELOR ÎN TIMP REAL

Procesele  în  timp  real  pot  fi 

clasificate  în  funcție  de  periodicitate, 
anticipare, priorități sau dependența de 
alte procese. 
 DEFINIREA PROCESELOR ÎN TIMP REAL
Procesele  periodice  sunt  procese  în  timp  real,  care  sunt 
activate  (lansate)  în  mod  regulat  la  rate  fixe  (perioade).  În  mod 
normal,  procesele  periodice  au  constrângeri  de  timp  care  indică 
faptul că instanțele din ele trebuie să se execute o dată pe perioada 
P.
Procesele  aperiodice  sunt  procese  în  timp  real,  care  sunt 
activate  neregulat  la  un  anumit  grad  de  limitare  necunoscut. 
Constrângerea de timp este, de obicei, un termen limită (deadline).
Procesele  sporadice  sunt  procese  în  timp  real,  care  sunt 
activate neregulat, cu un grad de limitare cunoscut. Gradul de 
limitare  se  caracterizează  printr­o  perioadă  minimă 
de  între­sosire,  adică  un  interval  minim  de  timp  între 
două  lansări  successive. Constrângerea de  timp este, 
de obicei, un timp limită (deadline).
 DEFINIREA PROCESELOR ÎN TIMP REAL

În unii algoritmi de planificare în timp real, un proces poate 
fi preemptiv dacă un alt process de prioritate mai mare devine gata 
de execuție.  În schimb, executarea unui process de bază non-
preemptiv ar trebui să fie finalizată fără întrerupere, odată ce 
acesta este pornit. 
În planificarea de prioritate determinată, o prioritate este 
alocată fiecărui proces. Atribuirea de priorități se poate face static 
sau dinamic în timp ce sistemul este pornit. 
DEFINIREA PROCESELOR ÎN TIMP REAL

Figura 20 Proprietățile de timp ale unui proces în timp real

Legendă:
•Timpul de lansare: momentul în care procesul este gata pentru prelucrare.
•Termenul limită (deadline): timpul până când executarea procesului ar trebui să fie finalizată, după ce procesul este
lansat.
•Întârzierea minimă: valoarea minimă de timp care trebuie să treacă înainte de executarea procesului, după ce
procesul a fost lansat.
•Întârziere maximă: valoarea maximă de timp permisă, care trece înainte de executarea procesului, după ce procesul a
fost lansat.
•Timpul de execuție în cel mai rău caz: timpul maxim necesar pentru a finalize procesul, după ce procesul a fost
lansat. Timpul de execuție în cel mai rău caz este cunoscut, de asemenea, ca și timpul de răspuns în cel mai rău caz.
•Timpul de execuție: timpul necesar fără întreruperi, pentru a finalize procesul, după ce procesul a fost lansat.
•Prioritatea: urgența relativă a procesului.