Curs Apd PDF

NICOLAE PARASCHIV
ACHIZIŢIA ŞI
PRELUCRAREA
DATELOR
UNIVERSITATEA PETROL – GAZE DIN PLOIEŞTI

2008
Achiziția și prelucrarea datelor
CAPITOLUL Problematica sistemelor
1 de achiziție și prelucrare
a datelor
1.1. Funcţiile automatizării proceselor

După cum se cunoaşte, prin proces se înţelege o succesiune de
transformări ce caracterizează diverse obiecte sau fenomene în evoluţia lor
spaţio - temporală. O importanţă aparte prezintă procesele tehnologice
caracterizate pe lângă transferuri masice şi energetice şi de transferuri
informaţionale.
Unui proces îi sunt de regulă asociate trei categorii de obiective şi
anume
- obiective de calitate;
- obiective de eficienţă;
- obiective de securitate.
Aceste obiective sunt de regulă formulate prin specificaţii asociate
produselor sau serviciilor rezultate, mărimea beneficiilor rezultate ca urmare a
valorificării acestora, norme protecţie a factorului uman, mediului şi
infrastructurii procesului.
Conducerea încadrează activitate de dirijare a evoluţiei procesului în
vederea realizării obiectivelor impuse. După cum factorul uman este implicat
sau nu conducerea poate fi manuală sau automată.
Conducerea presupune existenţa unui mijloc de conducere (MC), care să
aplice comenzi obiectului condus (OC) respectiv procesului. Ansamblul celor
două entităţi încadrează un sistem de conducere (SC).
Dacă procesul se află numai sub influenţa comenzilor, este suficientă
determinarea comenzilor ţinând cont numai de obiective. După cum se observă
din figura 1.1 sistemul de conducere este deschis , mijlocul de conducere nefiind
informat în legătură cu rezultatul acţiunilor sale.
Capitolul 1 1
Obiective Comenzi Rezultate

MC OC
Fig. 1.1. Sistem de conducere deschis: MC – mijloc de

conducere; OC – obiect condus (proces).
Existenţa unor perturbaţii care acţionează asupra OC independent de

comenzi determină îndepărtarea rezultatelor de la obiective, situaţie care nu
poate fi rezolvată prin intermediul structurii din figura 1.1.
În consecinţă se impune luarea în consideraţie la elaborarea comenzilor şi
a altor elemente în afara obiectivelor.
Dacă la determinarea comenzilor pe lângă obiective sunt avute în vedere
şi rezultatele se obţine structura ilustrată în figura 1.2, în care conducerea este
corectivă.
Perturbaţii

MC OC
Feedback
Fig. 1.2. Sistem de conducere cu acţiune după efect.
Caracterul corectiv este dat de faptul că prin acţiunea comenzilor

rezultatele sunt corectate în sensul că sunt readuse la nivelul obiectivelor. În
acest sens se stabileşte o legătură informaţională de la rezultate la MC, legătură
care s-a impus sub denumirea de feedback. Existenţa acestei legături
informaţionale face ca SC cu acţiune corectivă să fie cu structură închisă în
raport cu rezultatele.
Este important de subliniat faptul că rezultatele sunt restabilite indiferent
de cauza care a determinat alterarea lor. Există însă şi un incovenient al acţiunii
preventive determinat de faptul că există intervale de timp în care rezultatele nu
sunt în concordanţă cu obiectivele
Incovenientul identificat la SC cu acţiune corectivă este eliminat dacă la
elaborarea comenzilor, pe lângă obiective sunt avute în vedere şi o parte din
perturbaţii. Se obţine structura din figura 1.3, în care se constată existenţa unei
legături informaţionale de la perturbaţii la MC, legătură cunoscută sub
denumirea de feedforward.
Capitolul 1 2
Feedforward Perturbaţii

MC OC
Fig. 1.3. Sistem de conducere cu acţiune după cauză.
La un asemenea sistem comenzile sunt astfel determinate încât la

modificarea acelor perturbaţii care sunt luate în considerare, rezultatele nu se
abat de la obiective. Acţiunea preventivă are în vedere faptul că se previne
apariţia unui efect reprezentat de îndepărtarea rezultatelor de la obiective.
Dacă însă se modifică o perturbaţie care nu este considerată de MC
rezultatele nu mai sunt conforme cu obiectivele, iar acest efect nu mai poate fi
îndepărtat, întrucât SC este cu structură deschisă în raport cu rezultatele.
Dezavantajele celor două tipuri de acţiune sunt parţiale eliminate, dacă se
utilizează un SC cu acţiune mixtă după efect şi după cauză.
Feedforward Perturbaţii

MC OC
Feedback
Fig. 1.4. Sistem de conducere cu acţiune după efect şi după cauză.
Sistemul acţionează după cauză (respectiv preventiv) la modificarea

perturbaţiilor accesibile SC. La modificarea altor perturbaţii acţiunea este după
efect (respectiv corectivă).
În contextul conducerii automate pot fi identificate patru categorii de
sisteme automate care permit realizarea următoarelor funcţii:
- monitorizarea automată;
- reglarea automată;
- protecţia automată;
- optimizarea automată.
Capitolul 1 3
Este de menţionat faptul că pentru primele trei fucţii apar constrîngeri

severe de natură temporală. În continuare vor fi expuse consideraţii succinte
privind fiecare categorie de sistem automat
1.1.1. Monitorizarea automată
Conceptul de monitorizare este legat nemijlocit de cunoaşterea stării
momentane şi a evoluţiei parametrilor aferenţi unui proces.
Date privind valorile parametrilor se pot obţine prin măsurare şi/sau prin
calcul. Este important de subliniat faptul că numărul minim de sisteme de
măsurat este egal cu numărul gradelor de libertate ale procesului, respectiv
F  LM , (1.1)
unde: L este numărul total de variabile specifice procesului;
M – numărul de relaţii independente dintre cele L variabile;
F – numărul gradelor de libertate.
Pentru cele F variabile care trebuie măsurate se impune existenţa câte
unui sistem de măsurat la distanţă în structura căruia intră următoarele elemente:
- traductor;
- mediu (linie) de transmisie;
- instrument de vizualizare.
Traductoarele pot avea ieşiri sub forma unui cod numeric, caz în care
practic adaptoarele aferente acestora conţine un microcontrollere cu convertoare
analog-numerice (CAN) încorporate. Sunt încă răspândite traductoarele cu
semnal de ieşire analogic în domeniu unificat (uzual 4…20 mA).
Liniile te transmisie pentru semnale analogice sunt realizate în
exclusivitate din conductoare metalice. În cazul traductoarelor numerice (smart
transducers), acestea sunt conectate în reţele în care transmisia poate fi cu sau
fără fir (wireless).
În ceea ce priveşte instrumentele de vizualizare (IV) acestea pot fi reale
sau virtuale. Instrumentele reale se prezintă sub forma indicatoarelor şi
înregistratoarelor digitale. Instrumentele virtuale prezintă practic utilizatorului o
interfaţă grafică pe monitorul unui calculator, unde valorile parametrilor sunt
prezentate pe diferite tipuri de indicatoare programate.
După relaţia care există între numărul de parametri care se măsoară şi
numărul de instrumente de vizualizare s-au impus următoarele structuri de
monitorizare:
- structura total distribuită, în care există câte un IV pentru fiecare
parametru;
- structura total concentrată, în care există un IV pentru toţi parametrii;
Capitolul 1 4
- structura parţial distribuită, în care există câte un IV pentru fiecare

grup de parametri (se consideră că un grup de parametri este asociat
unui subproces).
1.1.2. Reglarea automată

Reglarea automată presupune atingerea şi menţinerea unei stări de
referinţă pentru proces fără intervenţia nemijlocită a factorului uman. Din
punctul de vedere al complexităţii există două tipuri de sisteme de reglare
automată (SRA) şi anume:
- SRA cu structură convenţională;
- SRA cu structură evoluată.
SRA cu structură convenţională au, de regulă, ca obiectiv menţinerea
stării de referinţă pentru un singur parametru. În această categorie pot fi incluse
SRA cu acţiune după abatere (efect) şi SRA cu acţiune după perturbaţie (cauză),
considerate tipuri fundamentale de SRA specifice nivelului automatizării
convenţionale.
Pentru asigurarea funcţionalităţii un asemenea SRA conţine pe lângă
proces un dispozitiv de automatizare (DA) căruia îi sunt specifice trei funcţii şi
anume:
- funcţia de măsurare;
- funcţia de comandă;
- funcţia de execuţie.
Pentru realizarea celor trei funcţii în structura DA sunt incluse în ordinea
funcţiilor traductoare, regulatoare elemente de execuţie. Este important de
subliniat faptul că regulatorul elaborează şi transmite comanda deci îndeplineşte
rolul mijlocului de conducere din structura unui sistem de conducere. În figura
1.5 sunt reprezentate scheme bloc ale SRA abatere şi perturbaţie în care este
evidenţiat dispozitivul de automatizare.
p1 pk pn
… a b
……
P r1 rk
i y ..
DA Pr P
I y
m m
DA Pr
Fig. 1.5. Schema bloc simplificată de structură a unui SRA:

a – abatere; b – perturbaţie; DA - dispozitiv de automatizare; Pr - proces.
Capitolul 1 5
O altă structurare identifică la nivelul unui SRA o parte fixată şi una

variabilă. Partea fixată potrivit reprezentării din figura 1.6 este constituită din
proces, traductor(oare) şi element de execuţie, în timp ce partea variabilă este
reprezentată de regulator.
Parametri de
acordare Perturbaţii
i
u r
EE Proces T
C
Parte variabilă Parte fixată

a
r
Perturbaţii
T b
I
u y
C EE Proces
Parte variabilă Parte fixată
Fig. 1.6. SRA cu evidenţierea părţilor fixată şi variabilă:

SRA abatere; SRA perturbaţie.
Este important de subliniat că din punctul de vedere al echipamentelor

numerice de conducere traductoarele şi elementele de execuţie sunt considerate
echipamente periferice de proces. Această încadrare are în vedere faptul că prin
intermediul traductoarelor procesul îşi face cunoscută starea, în timp ce
elementele de execuţie implementează în proces comenzile elaborate de
echipamentul numeric.
SRA cu structură evoluată (reglare avansată) au asociate obiective
specifice întregului proces (instalaţii). În cazul reglării avansate, mărimile
reglate sunt adesea reprezentate de parametri sintetici ale căror valori se
determină prin calcul. Prezenţa reglării avansate nu exclude reglarea
convenţională, cele două categorii coexistând în cadrul sistemelor ierarhice de
conducere.
Capitolul 1 6
În figura 1.7 se prezintă structura unui sistem ierarhic organizat pe două

niveluri, în care la nivelul inferior se realizează reglarea convenţională iar la cel
superior, reglarea avansată. Comenzile elaborate la nivelul inferior se bazează
atât pe mărimile preluate din proces, cât şi pe mărimile de coordonare primite de
la nivelul superior. Aceste mărimi sunt generate avându-se pe de o parte în
vedere obiectivele proprii ale nivelului coordonator, iar pe de alta reacţiile
informaţionale de la primul nivel.
Γ 
SCS vn
z1
z2
v1 v2 zn
SCI1 SCI2 SCIn
p1 p2 pn
r1 m1 r2 m2 rn mn
SP1 SP2 SPn
Fig. 1.7. Structura unui sistem de conducere ierarhizată:

SCS - sistem de conducere superior; SCI - sistem de conducere inferior; SP -
subprocese; r - reacţii de la subprocese; p - perturbaţii; m – mărimi de execuţie; z -
reacţii informaţionale; v-mărimi de coordonare;  - vector al obiectivelor pentru
nivelul superior; Γ- vector al mărimilor de informare de la nivelul superior.
Sistemul cu structura reprezentată în figura 1.7 este un sistem ierarhizat
pe verticală şi distribuit pe orizontală. Acest tip de structurare creează premisele
realizării sistemelor informatice integrate cu posibilităţi de prelucrare unitară
atât a informaţiei de natură tehnică cât şi a celei de natură economică.
1.1.3. Protecţia automată

Sistemele de protecţie automată (SPA) asigură realizarea obiectivelor
legate de securitate. Se au în vedere considerente legate de protecţia factorului
uman, a mediului ambiant şi a utilajelor implicate în desfăşurarea procesului.
În mod uzual funcţiile unui SPA pot fi divizate în două categorii
importante şi anume:
- funcţii de informare;
- funcţii de intervenţie.
Funcţiile de informare sunt asigurate de către sistemele automate de
avertizare iar cele de intervenţie de către sistemele automate de blocare şi
comandă.
Capitolul 1 7
Sistemele automate de avertizare (SAA) informează personalul de

operare în legătură cu starea momentană a unui utilaj sau cu producerea unui
eveniment. Aceste sisteme sunt cu structură deschisă, după cum se observă din
figura 1.8.
Limite de avertizare
P1lim Pklim Pnlim

… …
u m AO
BLC EAA
AA
… …
T1 Tk Tn
P1 Pk Pn
Parametri din proces

Fig. 1.8. Structura unui sistem de avertizare (SAA) : BLC - bloc logic de
comandă; EAA – element acţionare avertizoare; AO - avertizor optic; AA -
avertizor acustic.
Funcţie de situaţia semnalată avertizarea poate fi: de poziţie, de

prevenire sau de avarie. Avertizarea de poziţie nu determină o anume acţiune
din partea operatorului întrucât informează în legătură cu starea de funcţionare
sau nu a unui utilaj. Avertizarea de prevenire va trebui să provoace o
intervenţie, pentru a se preîntâmpina producerea unei avarii. Al treilea tip de
avertizare este legat de producerea unui eveniment care a cauzat o avarie.
Sistemele automate de blocare (SAB) sunt cu structură închisă şi
determină scoaterea din funcţiune a unui utilaj sau secţiune din instalaţie,
întrucât nu s-a intervenit după avertizarea de prevenire. Este de remarcat faptul
că SAB acţionează numai la scoaterea din funcţiune, nu şi la repornire.
Sistemele automate de comandă (SAC) sunt componente ale SPA care
asigură pornirea condiţionată a unor utilaje. Condiţionarea pornirii constă în
testarea îndeplinirii unor condiţii într-o succesiune temporală impusă, care
preced de exemplu cuplarea alimentării cu energie a utilajului respectiv. Tot la
nivelul SAC se asigură oprirea normală a unui utilaj (nu în condiţii de avarie).
1.1.4. Optimizarea automată
Conducerea optimală reprezintă implică, de regulă, aplicarea către proces
a acelor comenzi care extremizează o funcţie de performanţă. Este important de
subliniat că nivelul de optimizare se situează de regulă la un nivel superior
Capitolul 1 8
reglării convenţionale. plicarea către un caz particular al conducerii prin fixarea

mărimilor de referinţă, elaborarea referinţelor făcându-se în acest caz în urma
extremizării unei funcţii de performanţă. În capitolul 5 al prezentei lucrări va fi
prezentat implementarea unui sistem de conducere optimală.
1.2. Tipuri de aplicaţii în timp real

Timpul real (TR) reprezintă o noţiune utilizată pentru caracterizarea
operaţiilor dintr-un sistem de conducere care se desfăşoară în sincronism cu
evenimentele lumii exterioare. Un sistem de conducere prezintă comportare în
timp real dacă deciziile elaborate de acesta sunt emise la momentul oportun,
respectiv sunt aplicate procesului înainte ca datele pe baza cărora au fost
determinate aceste comenzi să-şi piardă valabilitatea.
În aceste condiţii timpul reprezintă o resursă esenţială şi în acelaşi timp
critică pentru echipamentele numerice implicate în conducerea proceselor. Este
o resursă deoarece toate mărimile aferente unui proces sunt dependente de timp.
Resursa timp este critică deoarece trebuie să existe o strânsă corelaţie între
timpul procesului şi cel al sistemului de conducere.
Timpul real este concretizat în timpul de reacţie sau de răspuns al
sistemului la anumite modificări din proces sau la comenzi ale operatorului. Se
poate aşadar stabili o legătură directă între inerţia procesului şi comportarea în
timp real. În ultimă instanţă comportarea în TR este determinată de frecvenţa cu
care sunt preluate datele din proces şi cu care sunt transmise comenzile către
acesta. În acest sens este cunoscută teorema lui Schanon care stabileşte că
pentru a nu se pierde informaţie, frecvenţa de eşantionare trebuie să fie cel puţin
dublul frecvenţei semnalului care se achiziţionează.
Având în vedere corelaţia TR – inerţie se poate spune că timpul real nu
are o valoare universală ci este specific fiecărui proces. Din acest motiv o
denumire alternativă pentru noţiunea de timp real este cea de timp util.
În continuare vor fi prezentate două tipuri de aplicaţii în timp real şi
anume aplicaţii de conducere şi aplicaţii tranzacţionale.
 Aplicaţiile de conducere se referă la elaborarea şi transmiterea de
comenzi către un proces.
Pentru exemplificare în figura 1.9 se prezintă structura unei astfel de
aplicaţii, care permite realizarea următoarelor funcţii:
- achiziţii de date;
- procesarea datelor achiziţionate;
- actualizarea bazei de date de proces;
- elaborarea comenzilor;
Capitolul 1 9
- procesarea comenzilor în vederea transmiterii către elementele de

execuţie;
- generarea de rapoarte.
COP
MEC
BGR
CTR
BDP ABDP
Procesare Date Procesare

Comenzi
SEN SIA SEA
TA EEA
EEN PROCES
Fig. 1.9. Structura unui sistem de conducere în timp real: BDP-baza de date de proces;
BGR-bloc generare rapoarte; ABDP-modul actualizare BDP; MEC – modul elaborare
copmenzi ;COP-consola operator; CTR – ceas de timp real; SIA – subsistem intrări
analogice; SEA – subsistem ieşiri analogice; TA- traductoare analogice; EEA - Elemente
de execuţie analogice; EEN – Elemente de execuţie numerice.
Din analiza figurii 1.9 se observă că sistemul de interfaţă se situează la

limita sistemului de conducere în timp real, în timp ce traductoarele şi
elementele de execuţie se află la limita procesului.
 Aplicaţiile tranzacţionale presupun rezolvarea unor solicitări pe
care utilizatorii le adresează sistemului de timp real. Aceste solicitări sunt
cunoscute sub denumirea de tranzacţii. Rezolvarea tranzacţiilor implică
existenţa unor aplicaţii de tratare, care pot face apel la diverse categorii de
resurse. În cadrul acestor tipuri de aplicaţii pot fi enumerate cele din domeniul
bancar, comerţul on-line, rezervarea de locuri, servicii în cadrul bibliotecilor etc.
Capitolul 1 10
Pentru exemplificare în figura 1.10, se prezintă structura unui sistem

tranzacţional, unde tranzacţiile sunt introduse de la un terminal.
MAT1
T1
MACU
T2
MGT MMT MATk SGBD
MATn BDST
Tn
Fig. 1.10. Structura unui sistem de tranzacţionare în timp real: BDST-baza

de date a sistemului tranzacţional ; T1…Tn – terminale; MGT – modul
gestiune terminale; MMT- modul monitorizare tranzacţii; MACU – modul
analiză comenzi utilizatori; MAT1…MATn ; SGBD – sistem de gestiune a
bazei de date; BDST – bază de date a sistemului tranzacţional.
După cum se observă din figura 1.10 sistemul tranzacţional implică

utilizarea unui număr de n terminale de la care diverşi utilizatori pot introduce
diferite mesaje predefinite ca funcţii şi semnificaţii denumite tranzacţii.
Tranzacţiile determină prelucrări al căror rezultat trebuie pus la dispoziţia
utilizatorilor în timp real.
1.3. Trăsături specifice ale sistemelor de operare în timp

real
La realizarea şi execuţia unei aplicaţii de timp real sunt implicate trei
categorii de resurse software (sisteme de programe) şi anume:
- programe de sistem;
- programe aplicative;
- programe utilitare sau de serviciu.
 Programele de sistem cunoscute ca software de bază asigură
următoarele funcţii importante:
Capitolul 1 11
- servicii comune pentru programe aplicative;

- planificare şi coordonarea programelor aplicative.
În categoria serviciilor comune sunt de regulă incluse următoarele
categorii de servicii:
- alocarea unităţii centrale de procesare;
- alocarea memoriei;
- alocarea echipamentelor de intrare-ieşire;
- tratarea întreruperilor.
După cum se va arăta întru-n sistem de timp real aplicaţiile (taskurile)
sunt într-o permanentă competiţie pentru deţinerea resurselor sistemului.
Componente ale software-ului de bază trebuie să asigure alocarea pe baza unor
criterii stabilite a resurselor importante ale echipamentului numeric respectiv:
timpul unităţii centrale de prelucrare şi spaţiile memoriei şi de intrare-ieşire.
În ceea ce priveşte tratarea întreruperilor, acest mecanism are o
importanţă deosebită pentru sistemele de timp real întrucât sistemul de
întreruperi constituie alături de ceasul de timp real un suport puternic al
prelucrării în timp real.
 Programele aplicative realizează prelucrările dorite de utilizator.
Aceste programe aplicative trebuie să se încadreze în clasa aplicaţiilor de timp
real, în sensul celor prezentate anterior (adică să fie de conducere în timp real
sau tranzacţionale în timp real).
 Programele utilitare sunt cele care asistă programatorul la
dezvoltarea şi implementarea programelor aplicative. În această categorie intră
printre altele: mediile de dezvoltare, diagnosticare şi depanare, generatoarele
de cod şi de rapoarte etc.
Cea mai importantă componentă a resurselor software de bază este
reprezentată de (SO). În mod obişnuit u SO are două funcţii importante şi
anume:
- gestionarea resurselor sistemului de calcul;
- realizarea unei interfeţe de dialog cu utilizatorul.
Specificul Sistemelor de Operare în Timp Real (SOTR) rezultă din faptul
că există programe care să fie executate condiţionat de unul dintre factorii timp
şi/sau evenimente externe.
Având în vedere aceste condiţionări posibile, rezultă că la un moment
dat în memoria sistemului pot exista mai multe aplicaţii aflate în diverse stadii
sau stări.
Capitolul 1 12
În contextul prelucrării în timp real unitatea funcţională elementară de

program, independentă din punct de vedere logic se numeşte task.
Principala componentă a unui SOTR este planificatorul1 care asigură
secvenţierea corectă a evoluţiei taskurilor. În mod obişnuit la nivelul unui SOTR
există două niveluri de planificare a execuţiei taskurilor şi anume:
- planificarea pe condiţii de timp2;
- planificarea pe condiţii de evenimente3.
Satisfacerea cerinţelor de prelucrare în timp real la achiziţia datelor din
proces şi la transmiterea comenzilor către acesta, impune o prelucrare paralelă
sau cel puţin pseudoparalelă a taskurilor. Este cunoscut faptul că o prelucrare
pur paralelă implică execuţia simultană a mai multor instrucţiuni, execuţie
posibilă în sistemele cu mai multe unităţi centrale de prelucrare (UCP). La
sistemele cu o singură UCP prelucrarea este pseudoparalelă, fiecare task
deţinând controlul UCP un anumit interval de timp.
Un SOTR capabil să asigure o execuţie paralelă su cel puţin
pseudoparalelă a taskurilor se numeşte Sistem de Operare în Timp Real
Multitasking – SOTRM..
Pe parcursul execuţiei lor taskurile pot activa proceduri sau rutine care
pot fi de trei categorii şi anume: dedicate, comune, reentrante.
 Rutinele dedicate pot fi utilizate de către un singur task.
 Rutinele comune pot fi activate din mai multe taskuri, însă succesiv.
Cu alte cuvinte, rutina poate apelată de un nou task, numai după ce execuţi sa în
precedentul task a fost încheiată.
 Rutinele reentrante pot fi activate simultan din mai multe taskuri,
cu alte cuvinte se pot autoîntrerupe.
Când se vorbeşte de funcţia de gestiune a SOTRM se au în vedere
următoarele tipuri de gestiune:
- gestionarea timpului UCP,
- gestionarea alocării spaţiului de memorie internă;
- gestionare echipamentrlor periferice aferente spaţiului de intrare-
ieşire.
 Gestionarea timpului UCP. După cum se cunoaşte UCP asigură în
totalitate disponibilităţile de calcul şi de comandă ale unui sistem de calcul.
Taskurile existente la un moment dat în memoria internă îşi dispută dreptul de
utiliza UCP. Taskurile apte de a prelua controlul UCP sunt dispuse de către
1
Engl. -scheduler
2
Engl. – time driven
3
Engl. – event driven
Capitolul 1 13
planificator într-o coadă de aşteptare, care poate fi organizată funcţie de

priorităţi4, sau în ordinea sosirii.
În mod curent SOTRM preia controlul UCP în următoarele situaţii:
- apariţia unui eveniment extern (de exemplu întreruperi din partea
procesului sau a operatorului);
- apariţia unui eveniment intern ( cum ar fi o întrerupere asociată unei
operaţii de intrare-ieşire);
- o întrerupere de la ceasul de timp real;
- apelarea de către taskul aflat în execuţie a unei funcţii realizate de
către SOTRM;
- trecerea unui anumit interval de timp.
La preluarea controlului UCP, SOTRM va întrerupe taskul aflat în
execuţie la acel moment şi va adopta una dintre următoarele decizii:
- va relua execuţia taskului întrerupt;
- va aduce în execuţie taskul cu prioritatea cea mai ridicată din coada de
aşteptare;
- va aduce în execuţie taskul cu timpul de aşteptare cel mai ridicat din
coada de aşteptare.
În cazul în care mai multe taskuri pot avea aceeaşi prioritate, alocarea
UCP se poate realiza potrivit următoarelor strategii:
- primul intrat primul ieşit5 , conform căreia taskurile cu prioritate egală
intră în execuţie în ordinea sosirii;
- timp divizat6, conform căreia fiecărui task i se alocă o cuantă de timp
în care deţine controlul UCP.
Unele SOTRM au facilitatea execuţiei în criză de timp, care presupune
creşterea automată a priorităţii, în condiţiile în care respectivul task nu a fost
executat un interval de timp superior unuia specificat.
 Gestionarea memoriei interne. Existenţa unei zone în care să fie
organizată stiva proprie este o condiţie absolut necesară pentru ca un task să
poată prelua controlul UCP. Pentru un SOTRM pot fi identificate patru strategii
de alocare a memoriei care vor fi succint analizate în continuare.
Strategia încărcării în zone fixe ale memoriei presupune că la un
moment dat în memoria internă a calculatorului se găseşte la un moment dat un
4
Fiecărui task i se atribuie contextul timpului real un indicator de urgenţă sau importanţă în execuţie care se
numeşte prioritate. Aceste poate fi un atribut fix, care să rămână nemodificat pe durata existenţei taskului, sau
variabil (care se poate schimba pe parcurs – vezi funcţia RTK SetTaskPriority)
5
FIFO – First Input First Output
6
Engl – time sharing
Capitolul 1 14
singur task. Pentru a se putea realiza execuţia funcţie de priorităţi taskurile

trebuie să fie întreruptibile şi transferabile. Aceste atribute presupun că toate
taskurile care nu sunt în execuţie nu sunt rezidente în memoria internă.
Avantajul acestei strategii constă în faptul că taskul aflat în execuţie are
la dispoziţie întregul spaţiu al memoriei interne. Preţul plătit pentru acest
avantaj este reprezentat de timpul consumat cu transferurile, astfel încât timul
consumat cu tranziţiile între stări creşte.
O variantă îmbunătăţită a acestei metode constă în asigurarea rezidenţei
permanente în memoria internă a taskurilor critice, respectiv a taskurilor
neîntreruptibile şi a celor care impun timpi de tranziţie foarte scurţi.
Strategia overlay (suprapunere şi înlănţuire) presupune ca un task
rezident la un moment dat în memoria internă să dirijeze încărcarea în memorie
a altor taskuri.
Strategia planificatorului presupune transferul gestionării memoriei
interne către taskul aflat în execuţie, respectiv către taskul care deţine controlul
UCP.
Strategia coexistenţei care presupune rezidenţa la un moment dat în
memoria internă a mai multor taskuri, comutarea făcându-se în regim de
multiprogramare7.
 Gestionarea operaţiilor de intrare – ieşire. Alături de UCP şi
memoria internă, spaţiul de intrare – ieşire constituie o altă ţintă pentru
concurenţa dintre taskuri. Din acest motiv accesul la periferice este controlat,
reglementarea acestui acces aparţinând SOTRM. Pentru gestionarea operaţiilor
de intrare – ieşire sistemele de operare pot pune la dispoziţie drivere şi rutine de
intrare- ieşire.
Driverele sunt module componente ale SOTRM care dirijează
dispozitivele periferice fizice, reacţionând la întreruperi pentru transferul datelor
şi semnalând rutinelor de intrare-ieşire încheierea operaţiei de transfer.
Rutinele de intrare-ieşire interfaţează dispozitivele implicate cu
programele de aplicaţie (taskuri), realizând principial următoarele funcţii
importante:
- semnalarea stării perifericului (liber sau ocupat);
- transmiterea cererilor de intrare-ieşire către driverele echipamentelor
care vor fi implicate.
La gestionarea operaţiilor de intrare-ieşire, trebuie avut în vedere faptul
că acestea se pot efectua cu sau fără implicarea unui tampon de memorie. Dacă
7
Multiprogramarea presupune o execuţie întreţesută conform căreia la un moment dat un singur task este
executat, dar mai multe sunt în execuţie (respectiv au instrucţiuni care au fost executate şi aşteaptă continuarea
execuţiei).
Capitolul 1 15
se utilizează un asemenea tampon cererea de intrare-ieşire este plasată într-un şir

de aşteptare, după care controlul UCP este dat taskului apelant. În al doilea caz
(respectiv la absenţa unui tampon de memorie) controlul UCP este redat taskului
apelant numai după realizarea operaţiei specificate.
1.4. Obiectivele şi principiile ingineriei programării în

timp real
Ingineria Programării în Timp Real (IPTR) încadrează o mulţime de
concepte, principii, metode şi instrumente de dezvoltare a programelor
destinate aplicaţiilor de timp real.
Abordarea în stil ingineresc a activităţii de programare este impusă atât
de complexitatea aplicaţiilor, cât şi de exigenţe care privesc creşterea
productivităţii acestei activităţi.
Principala misiune a IPTR constă în asigurarea premiselor pentru
trecerea de la arta programării la industria programării. Pentru realizarea
acestei misiuni IPTR urmăreşte rezolvarea a trei categorii importante de
probleme şi anume:
- stabilirea etapelor şi în cadrul acestora a fazelor prin care trece produs
informatic pe durata existenţei sale;
- elaborarea unor metode şi instrumente asociate (incluse în tehnologii)
pentru asistarea elaboratorului în fiecare etapă de dezvoltare;
- elaborarea pe baze ştiinţifice a unor metodologii pentru organizarea şi
coordonarea activităţilor specifice dezvoltării în stil industrial a
produselor informatice.
Pentru rezolvarea acestor tipuri de probleme, IPTR îşi propune
următoarele categorii de obiective pentru produsele informatice dezvoltate :
- obiective de adaptabilitate;
- obiective de eficienţă;
- obiective de fiabilitate;
- obiective de perceptibilitare.
 Adaptabilitatea presupune dezvoltarea de facilităţi pentru
efectuarea de modificări într-o manieră strict controlată. Modificările pot fi
determinate de:
- adăugarea de noi funcţii;
- ameliorarea performanţelor sistemului;
- corectarea unor erori de programare.
Pentru sistemele de conducere în timp real (SCTR) adaptabilitatea este
impusă, printre altele de caracterul evolutiv al procesului, evoluţie care poate
Capitolul 1 16
marca modificări ale obiectivelor, a strategiei de conducere şi implicit a

programelor asociate.
 Eficienţa este impusă de argumente care de regulă au în vedere:
- minimizarea necesarului de resurse pentru execuţia programelor;
- minimizarea efortului pentru dezvoltarea programelor;
- minimizarea timpului necesar pentru dezvoltarea programelor.
 Fiabilitatea programelor se referă, ca şi în cadrul echipamentelor
de conducere, la dezvoltarea de aptitudini pentru acestea de îndeplinire a
sarcinilor, un interval de timp prestabilit în condiţii de lucru specificate. Este
important de subliniat că în cadrul programelor dimensiunile fiabilităţii constau
în:
- evitarea, depistarea şi înlăturarea defectelor, pe cât posibil, în fazele
de proiectare, dezvoltare şi implementare a programelor;
- existenţă de instrumente şi resurse pentru înlăturarea defectelor, dacă
acestea se manifestă pe parcursul funcţionării programelor.
Ca şi în cazul echipamentelor fiabilitatea nu constituie un adaos ci se
dezvoltă odată cu sistemul de programe.
 Perceptibilitatea se referă la aptitudinea care trebuie conferită
programelor de a fi uşor înţelese şi urmărite de către un alt programator sau
chiar de către autor, la un anumit interval după finalizare8.
Pentru realizarea acestor obiective trebuie respectate o serie de principii,
între care o importanţă aparte prezintă următoarele:
- principiul modularizării;
- principiul abstractizării;
- principiul localizării;
- principiul uniformităţii;
- principiul completitudinii;
- principiul confirmabilităţii;
- principiul acoperirii.
 Principiul modularizării. Modularizarea reprezintă maniera în care
trebuie structurat un program pentru a atinge mai uşor un anumit scop.
Modularizarea constituie un factor determinant pentru satisfacerea obiectivelor
adaptabilităţii şi fiabilităţii.
 Principiul abstractizării impune identificarea proprietăţilor comune
unor entităţi aparent diferite şi omiterea unor detalii specifice neesenţiale. De
8
Această obiectiv mai este cunoscut şi sub denumirea de claritate.
Capitolul 1 17
regulă într-o structură ierarhic , fiecare nivel reprezintă o abstractizare a

nivelelor inferioare, detaliile fiind păstrate pe acestea.
 Principiul localizării se referă dispunerea în vecinătate fizică a
elementelor cu legături între ele cum ar fi: subrutine, înregistrări fizice şi logice,
pagini de memorie, etc.
 Principiul uniformităţii presupune asigurarea consistenţei, un
exemplu în acest sens fiind respectarea notaţiilor.
 Principiul completitudinii are în vedere includerea în conceptele
abstracte a tuturor elementelor semnificative.
 Principiul confirmabilităţii afirmă necesitatea formulării explicite a
tuturor informaţiilor legate de posibilitatea verificării corectitudinii programelor.
 Principiul acoperirii, promovează afirmarea aspectelor esenţiale în
favoarea celor neesenţiale, care pot fi transparente pentru utilizator.
Un alt aspect specific IPTR legat de fazele din existenţa unui program
respectiv:
- analiza cerinţelor;
- elaborarea specificaţiilor;
- proiectarea sistemului de programe;
- codificarea în program;
- instalarea şi testarea programelor;
- întreţinerea programelor.
 Analiza cerinţelor este o etapă în care beneficiarul colaborează
strâns cu echipa de analişti din partea elaboratorului produsului informatic, în
vederea identificării particularităţilor problemei care urmează a se rezolva.
Această etapă se finalizează cu tema de proiectare în care sunt formulate
cerinţele şi restricţiile aplicaţiei.
 Elaborarea specificaţiilor presupune formularea unui set de
specificaţii care includ resursele funcţionale şi restricţiile de operare.
 Proiectarea sistemului de programe reprezintă o etapă în care se
stabilesc:
- structura pe module funcţionale a programelor;
- relaţiile între modulele componente şi modalităţile de comunicare;
- datele de intrare şi rezultatele pentru fiecare modul;
- algoritmii care vor fi utilizaţi pentru implementarea cerinţelor din tema
de proiectare.
Capitolul 1 18
 Codificarea presupune generarea programelor pentru modulele

definite în etapa de proiectare şi rularea lor pe un calculator gazdă.
 Instalarea şi testarea programelor are în vedere transferul
programelor pe maşina unde aplicaţia urmează a fi executată. Respectiv pe
calculatorul ţintă. În această etapă mai pot fi corectate eventuale erori de
programare care nu au putut fi depistate în fazele anterioare.
 Întreţinerea programelor presupune eventuale corecţii impuse fie de
neconcordanţe în raport cu tema de proiectare, fie de reveniri ale beneficiarului.
Fiecare dintre etapele anterioare conţine câte o secvenţă de validare,
promovarea la etapa următoare fiind condiţionată de validarea celei precedente.
După cum se observă din figura 1.11, în care sunt evidenţiate aceste etape, etapa
de întreţinere conţine o validare care are în vedere o anume activitate specifică
acestei etape.
Start dezvoltare aplicaţie
Analiză
Codificare
Nu Da
Validare Nu Da
Validare
Specificaţii
Da
Nu Da
Validare Instalare -
testare
Proiectare Nu Da
Validare
Nu Da
Validare
Întreţinere
Nu
Nu
Da
Expirare contract Validare
intreţinere
Da
Încheiere dezvoltare aplicaţie
Fig. 1.11. Procesul iterativ asociat etapelor din existenţa unui produs
informatic.
Capitolul 1 19
Pe parcursul derulării etapelor de mai sus repartiţia aproximativă a

costurilor este următoarea:
- analiză, elaborare specificaţii, proiectare - 40 % din costuri;
- codificare - 20 % din costuri;
- instalare şi testare - 40 % din costuri.
Costurile operaţiilor de întreţinere le pot depăşi pe cele de elaborare.

Evident acestea sunt suportate de elaborator (dacă se constată erori ale acestuia)
sau de către beneficiar (în cazul unor reveniri).
Pe parcursul diverselor etape, sunt implicaţi, în ordine; următoarele

categorii specialişti în tehnologia informaţiei:
- analişti;
- proiectanţi;
- programatori;
- implementatori.
Coordonarea dezvoltării şi implementării produsului informatic este
asigurată de către un manager de proiect.
Capitolul 1 20
CAPITOLUL Elemente componente ale
2 sistemelor de achiziție
După cum s-a arătat în capitolul precedent un echipament numeric (EN)

de calcul procesează datele într-o formă specifică acestuia şi oferă rezultatele
într-o formă accesibilă utilizatorului. Acest mod de funcţionare presupune
existenţa în structura EN a unei diviziuni capabile să rezolve comunicarea cu
mediul exterior reprezentat de utilizatori.
Obiectul prezentului capitol îl constituie prezentarea funcţională a
dispozitivelor destinate schimbului de informaţii cu procesul tehnologic
reprezentat de traductoare şi elemente de execuţie.
2.1. Transferuri de date în echipamente numerice

Din punct de vedere structural frontiera dintre diviziunile de calcul,
comandă si memorare şi cea de comunicare este reprezentată de porturile de
intrare/ieşire. În acest sens un port este un punct prin care se face schimb de
informaţie cu mediul exterior. În continuare vor fi prezentate elemente privind
modalităţile de transfer a datelor şi mediile prin care acesta se realizează.
2.1.1. Transferul paralel al informaţiei
După cum se observă din figura 2.1, un echipament periferic nu este
conectat direct la magistralele sistemului de calcul, ci prin intermediul unei
interfeţe.
Funcţionarea nemijlocită a EP este coordonată de către CP, care se
conectează la microsistem prin intermediul ITF. Această delimitare netă între
ITF şi CP nu este întotdeauna evidentă. Dacă ITF şi CP sunt incluse în acelaşi
circuit integrat poartă denumirea globală de controller , acesta putând depăşi în
complexitate structura unui P.
21
În ceea ce priveşte interfeţele, acestea pot fi nestandard sau standard,

ambele tipuri făcând posibilă comunicaţia cu porturile. Comunicaţia cu un port
necesită selectarea acestuia, urmată de înscriere sau de citire. Informaţia citită
sau înscrisă este vehiculată pe magistrala de date a sistemului. Pentru sistem,
portul în care se înscrie este port de ieşire, cel din care se citeşte este port de
intrare, iar cel din care se citeşte si se înscrie este port de intrare / ieşire.
ITF
CP EP
MS
Fig. 2.1. Structură principială pentru conectarea unui periferic la

sistem: MS – magistrală sistem; ITF - interfaţă; CP - unitate de
comandă a perifericului; EP - echipament periferic.
O interfaţă de comunicaţie are structura de principiu din figura 2.2 şi
necesită mai multe porturi concretizate în următoarele adrese :
- una sau două adrese pentru portul de intrare/ieşire date, după cum
acesta este bidirecţional sau constituit din două porturi unidirecţionale ;
- o adresă pentru un port de intrare, care conţine starea perifericului ;
- o adresă pentru un port de ieşire care va conţine un cuvânt de comandă
către periferic.
MD
BSF
RTI RTE
MA
Periferic
MC
Fig. 2.2. Structurăde principiu pentru o interfaţă:

MA, MD, MC - magistrale de adrese, date, comenzi; BSE - bloc selecţie funcţie; RTI,
RTE - registre tampon de intrare, ieşire.
22
De regulă informaţia se transmite în exterior de pe magistrala de date a

sistemului. Dacă toţi biţii acesteia se transmit simultan, atunci transmisia este
paralelă, iar dacă se transmit succesiv transmisia este serială.
Figura 2.3 prezintă diagramele de timp pentru transferul paralel al
următoarei secvenţe de cuvinte cu lungimea de un byte : 11110001, 00011110,
11000101. După cum se observă, pe liniile magistralei vor fi simultan, la
momentul de tact, biţii corespunzători cuvintelor care se transmit ( se consideră
că cei trei octeţi se transmit la momentele t1, t2, şi t3).
D7
MSb 1
t
D6
1
t
D5
1
t
D4
1
t
D3
1
t
D2
1
t
D1
1
t
D0
1
LSb
t
Imp.
1
t
t1 t2 t3
Fig. 2.3 Diagramă de timp pentru transmisia paralelă:
D7…D0 - biţii care se transmit; MSb - bitul cel mai
semnificativ; LSb - bitul cel mai puţin semnificativ.
Între secţiunile unui P precum şi între acesta si memorie, transmisia

este aproape în exclusivitate în format paralel. Vitezei ridicate de transmisie i se
opune o sensibilitate ridicată la perturbaţii, motiv pentru care în exteriorul
sistemului transmisia se poate face la maximum 2-3 m, iar cu amplificatoare de
magistrală la 50-60 m.
Pentru transferul paralel există interfeţe standard programabile (funcţiile
sunt fixate prin program) între care remarcabile sunt : PIO (Parallel Input
23
Output) , PIA (Programmable Interface Adapter), PPF (Programmable

Peripheral Interface).
2.1.2. Transferul serial al informaţiei

Transmisia serială, care este mai lentă decât cea paralelă, se foloseşte
pentru transferul informaţiei între calculatoare sau între calculatoare şi unele
categorii de periferice. Comunicaţia se poate desfăşura intr-un singur sens
(simplex), in ambele sensuri, dar nu simultan (semiduplex), sau simultan în
ambele sensuri (duplex).
Indiferent de consistenţa fizică a semnalelor informaţia poate fi transmisă
asincron sau sincron.
În modul asincron momentele transmisiei sunt aleatoare, dar orice cuvânt
consumă acelaşi interval de timp.
În figura 2.4 este evidenţiată transmisia serială asincronă a octetului
11010100. În repaus linia este în starea 1 logic, iar transmisia fiecărui cuvânt
începe cu bitul de start care este 0 logic. La recepţie se detectează la inceput
tranziţia 10 a bitului de start. În situaţia recepţiei corecte a bitului de start se
preiau ceilalţi biti, începând cu LSb şi terminând cu MSb. Transmisia cuvântului
se încheie cu unul sau doi biţi 1 de stop, după care linia rămâne în repaus (starea
1), sau se începe cu un nou bit de start (starea 0). Transmisia este denumită
funcţie de lungimea totală a cuvântului pentru a transmite un octet (8/10- pentru
un bit de stop, 8/11 pentru doi biţi de stop). Viteza de transmisie a informaţiei pe
o linie de comunicaţie se măsoară în bps (biţi pe secundă), iar viteza semnalului
se măsoară în baud. Baud-ul este definit ca măsura inversă, a duratei exprimate
în secunde, a celui mai scurt element din codul semnalului. Este evident faptul
că în cazul informaţiei codificate binar, cele două viteze coincid. La frecvenţe
ridicate modul asincron devine ineficient, deoarece 2 sau 3 biţi dintr-un cuvânt
nu sunt purtători de informaţie.
Start Stop
U b0 b1 b2 b3 b4 b5 b6 b7 Aşteptare
1
t
Impulsuri de
U la generatorul
1 local
t
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10
Fig. 2.4. Transmisie serială asincronă 8/10.
24
În modul de transmisie serială sincronă, cuvintele sunt transmise într-o

succesiune continuă, sub formă de bloc de date, fără biţi de start şi de stop.
Pentru a exista corespondenţă în timp (sincronizare), la emisie şi la recepţie se
transmite câte un bit de sincronizare pentru fiecare bloc de date. Pentru
transmisia la mari distanţe pe linie telefonică, semnalul digital este convertit
într-o frecvenţă. În aceste condiţii la emiţător este necesară prezenţa unui
modulator, iar la receptor a unui demodulator, ansamblul celor două elemente
fiind cunoscut sub denumirea de MODEM ( MODulator DEModulator).
În ceea ce priveşte interfeţele standardizate destinate transmisiei seriale
sunt de menţionat : UART (Universal Asynchronous Receiver Transmiter),
ACIA (Asynchronous Comunications Interface Adapter), USART (Universal
Synchronous and Asynchronous Receiver Transmiter).
Realizarea unei interfeţe seriale presupune în primul rând realizarea unui
convertor paralel-serie (pentru emisie) şi a unuia serie-paralel (la recepţie) .
Ambele tipuri de convertoare pot fi realizate cu registre de deplasare. Conversia
paralel-serie presupune încărcarea unui cuvânt intr-un registru, urmată de
deplasarea acestuia cu câte un rang la fiecare impuls de tact. Astfel, la ieşirea
registrului se obţin succesiv (serial) biţii cuvântului de la intrare începând cu
LSb. La conversia serie-paralel registrul este încărcat serie cu câte un bit
(începând cu LSb) la fiecare impuls de tact. După introducerea MSb cuvântul
este extras la ieşirea în paralel a registrului .
2.1.3. Magistrale de comunicaţie

În transferul de date sunt implicate echipamente şi unităţi funcţionale
interconectate prin intermediul magistralelor de comunicaţie.
În sens restrâns magistrala (M) reprezintă un grup de trasee prin care sunt
transmise semnale în interiorul unui sistem de calcul, între acesta şi
echipamentele periferice, sau între mai multe sisteme de calcul.
În sens mai larg noţiunea de M include:
─ mediul de transmitere (conductor metalic, eterul, fibră optică, etc.) ;
─ forma sub care sunt vehiculate semnalele (niveluri de tensiune,
durata impulsurilor, frecvenţa impulsurilor etc.) ;
─ dispozitivele de conectare de la fiecare capăt.
În afara consistenţei fizice prezentate, noţiunii de M i se mai atribuie şi un
conţinut logic concretizat în modul de vehiculare a semnalelor, secvenţierea lor
în timp, semnificaţiile acestora.
Principial magistrala realizează următoarele funcţii:
- transferul de informaţie;
25
- sincronizarea, care permite cuplarea de echipamente cu caracteristici

dinamice diferite;
- comutarea, care facilitează utilizarea în comun a M.
Cu toate că din punct de vedere fizic circuitele de sincronizare şi/sau
comutare se găsesc incluse în modulele deservite, conceptual acestea se
consideră ca făcând parte din M. Concretizarea realizării acestor funcţii impune
alegerea mediului fizic de transmitere, a protocolului logic de transmisie şi a
manierei de alocare a M la utilizatori.
Uzual M se consideră secţionată în trei diviziuni şi anume:
- magistrala de date asociată transmiterii datelor între memorie şi P;
- magistrala de adrese prin care circulă semnalele de identificare a
locaţiei de memorare referite;
- magistrala de comenzi care vehiculează semnalele de comandă şi
control ale sistemului.
Caracteristicile importante ale unei M sunt lungimea şi lăţimea (prin
lăţime înţelegându-se numărul de linii în paralel). Între acestea două
caracteristici există o strânsă corelaţie determinată de structura fizică a mediului
de transmitere şi de cost.
Deoarece actualele echipamente de conducere sunt sisteme
multiprocesor, în continuare vor fi prezentate câteva elemente specifice
comunicaţiei în cadrul acestor sisteme.
Din punct de vedere topologic subsistemele pot fi puternic sau slab
cuplate. Termenul de puternic cuplat este folosit pentru definirea unui transfer
de informaţie între procesoare şi resurse comune (în primul rând memoria) care
se consideră concentrate. Termenul de slab cuplat se referă la comunicaţia în
cadrul sistemelor în care atât procesoarele cât şi resursele sunt distribuite.
Sistemelor puternic cuplate le sunt specifice M paralele, iar cele slab cuplate
sunt caracterizate de existenţa M seriale.
O primă structură de sistem puternic cuplat este cea din figura 2.5, în care
procesoarele P1 şi P2 utilizează în comun memoriile M1 şi M2. Fiecare procesor
dispune de propria M, ceea ce impune ca fiecare memorie să deţină un număr de
porturi de acces egal cu numărul procesoarelor. În cazul sistemelor cu un număr
ridicat de procesoare, structura M şi mecanismul de acces multiport la memorie
devin deosebit de complexe, ceea ce limitează răspândirea acestui tip de
comunicaţie.
P1 P2
Fig. 2.5. Sistem puternic cuplat cu mai multe
magistrale:
M1 M2
26
Structura din figura 2.6 utilizează o singură M, indiferent de numărul

procesoarelor şi al blocurilor de memorie pe care le interconectează. Utilizarea
M se face prin divizarea timpului, fiecărui proces fiindu-i alocat, ciclic, un
interval de timp în care are acces la totalitatea resurselor (în speţă la întregul
spaţiu de memorie). O asemenea soluţie este atractivă datorită simplităţii ei, dar
prezintă dezavantajul unor performanţe în ceea ce priveşte viteza de transmisie.
P1 P2
Fig. 2.6. Sistem puternic cuplat cu o singură
magistrală.
M1 M2
O a treia metodă de interconectare în cadrul sistemelor puternic cuplate o

reprezintă utilizarea M încrucişate (cross-bar). După cum se observă din figura
2.7, în care este evidenţiat principiul metodei , prezenţa comutatoarelor pe
magistrale Kij permite comunicarea oricărui procesor, cu orice modul de
memorie, fiind posibile şi transferurile simultane. De exemplu, în figura 2.6, în
timp ce procesorul P1 citeşte date din memoria M2, procesorul P2 poate să
înscrie date în memoria M1. Soluţia cross-bar măreşte viteza de lucru a
sistemului, simplifică realizarea blocurilor de memorie, dar necesită un număr
mare de magistrale şi un mecanism complex de comutaţie.
P1 P2
K11 K12
M1
K21 K22
M2
Fig. 2.7. Sistem cu magistrale încrucişate.
Industria echipamentelor de conducere a proceselor a cunoscut o

abundenţă de tipuri de magistrale, marii producători încercând să impună ca
standard propriile structuri de M. Magistralele specifice sistemelor de conducere
sunt de regulă ierarhizate şi distribuite, corespunzător caracterului acestor
sisteme. În continuare vor fi prezentate elementele importante a două standarde
27
de organizare a magistralelor pentru echipamentele de proces şi anume AMS şi

VME.
Magistrala AMS a fost elaborată în Europa, de către firma Siemens şi este
organizată pe 4 niveluri de comunicaţie (figura 2.8).
AMS_8
AMS_32
P1 S1 P2
AMS_16 AMS_16
P3 P4 S2 P5 S8 S9
AMS_8 AMS_8
S5 S6 S7 S10 S11
Fig. 2.8. Comunicaţia prin magistrala AMS :

P - procesoare (module MASTER); S - module subordonate (SLAVE).
Procesoarele asociate primului nivel sunt interconectate prin magistrale

pe 32 de biţi, AMS32. Procesoarele P1 şi P2 coordonează prin intermediul
magistralelor pe 16 biţi AMS16 susbsistemele situate la nivelul inferior.
Diviziunea AMS8 a M este asociată nivelului de bază al sistemului ierarhic şi
poate reprezenta, de exemplu, comunicaţiile asociate unui C. În afara
comunicaţiei de tip paralel între procesoare, standardul AMS oferăşi
posibilitatea comunicaţiei de tip serial între acestea.
Magistrala VME, cu toate că s-a dorit să fie independentă de fabricant,
este puternic orientată către familia de P Motorola. Din punct de vedere
structural, standardul VME impune 3 secţiuni, evidenţiate în figura 4.9 şi anume:
-VMX destinată conectării unui procesor cu module pasive în structuri
monoprocesor;
-VME care permite cuplarea în configuraţie multiprocesor a modulelor
active şi pasive.
-VMS care oferă posibilitatea comunicaţiei seriale între modulele active şi
cele pasive.
28
VMS
VME
P M I/E M P
VMX
Fig. 2.9. Magistrala VME:

P - procesoare; M - memorie; I/E - unităţi de intrare/ieşire;
VMS, VME, VMX - secţiuni ale magistralei.
Distribuţia pe arii extinse a echipamentelor de conducere şi supraveghere

impune conectarea acestora în reţele de comunicaţie, în care comunicaţia este
serială iar schimbul de informaţie se poate realiza între doi sau mai mulţi
parteneri. Principalele configuraţii de reţele sunt (figura 4.10):
- configuraţie stea, în care un nod central este legat la toate celelalte
noduri ale reţelei;
- configuraţie multipunct, în care toate nodurile sunt conectate printr-o
legătură unică;
- configuraţie în buclă, asemănătoare celei multipunct, în care însă
legătura formează o buclă;
- configuraţia de tip plasă, în care fiecare partener din reţea posedă cel
puţin două legături cu alţi parteneri.
Comunicaţia în cadrul reţelelor se poate realiza într-un sens sau în
ambele sensuri (simultan sau nu). Canalele care oferă suportul comunicaţiei pot
fi multiplexate în timp sau în frecvenţă. În primul caz fiecărui utilizator i se
alocă o cuantă de timp, pe durata căreia poate folosi canalul. Multiplexarea în
frecvenţă presupune alocarea de frecvenţe separate (în cadrul benzii de trecere a
canalului) pentru diverşi parteneri sau grupe de parteneri.
Pentru ca transferul de informaţie în cadrul reţelelor să poată avea loc, se
impune stabilirea unui set de reguli asociat acestui proces, care constituie
protocolul de comunicaţie.
2.3. Interfeţe de proces

Necesitatea interconectării subsistemelor cu caracteristici complet diferite
impune utilizarea unor dispozitive care să le compatibilizeze. Această
compatibilizare trebuie să asigure transferul informaţional între sistemele
conectate, care devine posibil în condiţiile în care dispozitivele de interconectare
prezintă caracteristici comune ambelor subsisteme.
29
a) b)
c) d)
Fig. 2.10. Tipuri de reţele de comunicaţie:
a - stea; b - multipunct; c - în buclă; d - de tip plasă cu conectare completă.
În cadrul sistemelor numerice de conducere a proceselor,

compatibilizarea este asigurată de către sistemul de interfaţă proces-calculator
(SIPC) ale cărui caracteristici vor fi prezentate în cele ce urmează.
2.3.1. Structura şi funcţiile sistemului de interfaţă cu procesul

Necesitatea existenţei SIPC apare evidentă datorită incompatibilităţii
totale între mărimile aferente procesului şi cele cu care operează echipamentul
numeric de conducere. Practic SIPC asigură posibilitatea conectării
calculatorului la echipamentele periferice de proces reprezentate de traductoare
şi elemente de execuţie.
La nivelul SIPC se consideră că are loc o transmisie bilaterală de
informaţie, între proces şi calculator, care funcţie de sensul transmisiei se pot
constitui alternativ în emiţătoare respectiv receptoare de informaţie. Transmisia
semnalelor se poate face prin cablu, radio, fibră optică, etc. În cazul transmisiei
prin cablu, aceasta se poate face serie sau paralel, durata fiind determinată,
printre altele, de: timpii de trecere, de identificare a receptorului şi de acceptare
a transmisiei. Viteza de transmisie a datelor este influenţată şi de tipul
semnalelor de sincronizare.
Din acest punct de vedere transmisia se poate face prin două metode şi
anume:
- transferul ciclic, care presupune efectuarea transmisiei între două
impulsuri de tact;
30
- transferul la cerere, care presupune informarea asincronă a unităţii

receptoare în legătură cu posibilitatea efectuării unei transmisii urmată de
identificarea emiţătorului şi de acceptarea transmisiei.
CALCULATOR
SADA SADN SDCA SDCN
SAD SDC
P R O C E S
Fig. 2.11. Structura generalăa unui SIPC.
Structura generală a unui SIPC este de forma celei prezentate în figura

2.11, în care se remarcă prezenţa a două subsisteme şi anume:
- subsistemul de achiziţie a datelor (SAD);
- subsistemul de distribuţie a comenzilor (SDC).
 SAD, care cuprinde subsistemele de achiziţie a datelor analogice
(SADA) şi numerice (SADN), asigură preluarea semnalelor din proces,
adaptarea lor în vederea prelucrării numerice şi transmisia la calculator.
 SDC, care cuprinde subsistemele de distribuţie a comenzilor în forma
analogică (SDCA) şi numerică (SDCN), asigură transformarea informaţiei
furnizate de calculator în semnale specifice elementelor de execuţie (analogice
sau numerice) şi transmisia către acestea.
Gestionarea transferului de informaţie între perifericele de proces şi
echipamentul numeric de conducere este realizată de către o bloc de comandă
aferent SIPC.
În momentul actual se constată tendinţa de migrare a tehnicii numerice
către perifericele de proces aspect materializat de apariţia aşa numitelor
traductoare şi elemente de execuţie inteligente. Această deplasare nu schimbă
însă fondul atribuţiilor SIPC deoarece subsistemele aferente acestuia se regăsesc
în structurile traductoarelor şi elementelor de execuţie. Soluţia, tentantă la prima
vedere, prezintă inconvenientul costurilor, încă destul de ridicate pentru aceste
tipuri de traductoare şi de elemente de execuţie.
31
O situaţie frecvent întâlnită este aceea în care se menţin traductoare şi

elemente de execuţie analogice dar se utilizează regulatoare numerice. În acest
caz regulatoarele conţin interfeţe de proces cu structuri apropiate de cele ce se
vor prezentata în continuare.
2.3.2. Subsistemul de achiziţie a datelor analogice (SADA)

Un volum important din informaţia privind starea proceselor tehnologice
este transmis sub formă analogică de către traductoare corespunzătoare. Aceste
semnale pot fi atât în curent cât şi în tensiune, de nivel coborât sau ridicat.
Între funcţiile specifice SADA pot fi enumerate:
- selectarea canalului fizic de acces conform unei adrese primite de la
UCP;
- eventuale prelucrări primare ale informaţiei preluate (liniarizări,
corecţii, filtrări, etc);
- transformarea semnalelor în vederea compatibilizării cu domeniul
dispozitivului (dispozitivelor) de conversie analog-numerică;
- conversia din formă analogică în formă numerică;
- transferul informaţiei numerice rezultate, în memoria echipamentului
numeric prin intermediul magistralei de date.
Corespunzător funcţiilor enumerate, în structura SADA pot intra, în
totalitate sau nu, următoarele componente:
- elemente de joncţiune (EJ), care conectează SADA la liniile prin care se
transmit semnale de la perifericele de proces;
- multiplexoare (MUX), care creează posibilitatea utilizării în comun a
resurselor unice;
- elemente de prelucrare primară(EPP), care asigură prelucrări de tipul
celor enumerate mai sus;
- amplificatoare, care permit aducerea semnalului în domeniul
convertorului analog-numeric şi adaptarea de impedanţă;
- dispozitive de eşantionare şi reţinere (DER), care reprezintă memorii
analogice destinate păstrării semnalului eşantionat pe durata conversiei analog -
numerice;
- convertoare analog - numerice (CAN), destinate conversiei semnalelor
preluate din formă analogică în formă numerică;
- registre tampon ale mărimii convertite (RT) , care memorează valorile
numerice ale mărimilor achiziţionate, până când acestea sunt preluate pe
magistrala de date;
- blocul de comandă(BC) destinat secvenţierii operaţiilor aferente
achiziţiei şi conversiei, ţinând cont de caracterul asincron al acestora în raport cu
funcţionarea UCP.
32
În figura 2.12 sunt prezentate structuri posibile de SADA diferenţiate

după numărul de CAN utilizate.
I1 EPP AFAP DER CAN RT

M
I2 EPP
U
MD
X
A
In EPP BC
a)
I1 EPP A1 DER1 CAN1 RT

M
U
X
MD
N
In EPP An DERn CANn
BC
b)
Fig. 2.12. Structuri de SADA:
a - cu un singur CAN şi multiplexare analogică; b - cu mai multe CAN şi
multiplexare numerică.
Varianta din figura 2.12 a este caracterizată de prezenţa unui

amplificator cu factor de amplificare programabil (AFAP), căruia îi succede un
lanţ unic DER-CAN. Rolul AFAP este acela de a aduce semnalele preluate de la
traductoare în domeniul de lucru al CAN.
Operaţia de achiziţie a datelor de pe un anumit canal, în cazul acestei
variantei, se derulează etapizat după cum urmează:
- se transmite multiplexorului analogic MUXA adresa canalului selectat;
- se transmite către AFAP factorul de amplificare aferent;
- se transmite către DER comanda de eşantionare;
- se transmite către CAN comanda Start conversie;
- după recepţionarea semnalului Sfârşit conversie se transmite comanda de
înscriere a informaţiei numerice furnizate de CAN în registrul tampon RT.
33
Variantei din figura 2.12 b îi este specific câte un lanţ A-DER-CAN

pentru fiecare canal care se conectează la SADA. Spre deosebire de varianta
anterioară, fiecare din coeficienţii de amplificare ai amplificatoarelor A1,…, An
este fix, iar multiplexarea este numerică, resursa comună fiind reprezentată de
RT iar utilizatorii de ansamblurile EP-A-DER-CAN, aferente fiecărui canal.
Achiziţia de pe un canal, în cazul variantei b se realizează prin
parcurgerea următoarei secvenţe de operaţii:
- se poziţionează multiplexorul numeric MUXN pe canalul de pe care
urmează a se face achiziţia;
- se transmite comanda de eşantionare către DER de pe canalul respectiv;
- se transmite comanda Start conversie către CAN de pe canalul selectat;
- după recepţionarea semnalului Sfârşit conversie se dă comanda de
înscriere a codului numeric rezultat în RT.
În cazul ambelor variante după înscrierea în registrul tampon RT, datele în
formă numerică pot fi preluate în memorie prin intermediul magistralei de date
MD.
Cu toate că în soluţiile prezentate în figura 2.12 SADA se conectează
numai la MD, nu este exclusă conectarea în anumite situaţii şi la magistralele de
adrese şi de comenzi ale sistemului respectiv. În continuare se vor face referiri la
elementele care intră în structura SADA.
 Elementele de joncţiune. Acestea asigură conectarea nemijlocită,
fizică a SADA la traductoarele din proces. Uzual conectarea se poate face prin
cleme, cuple sau lipire. Deosebit de importantă pentru precizia SADA este
valoarea rezistenţelor de contact din cadrul EJ şi stabilitatea lor în timp. Din
acest punct de vedere cea mai sigură este conectarea prin lipire, la polul opus
situându-se EJ realizate cu cleme.
O altă cerinţă impusă EJ o reprezintă posibilitatea de modificare a
configuraţiei canalelor de intrare, conexiunile realizate cu cleme oferind
facilităţi maxime în acest sens.
În legătură cu opţiunea pentru un tip de EJ trebuie realizat un compromis
între versatilitatea şi fermitatea joncţiunilor realizate.
 Elemente de prelucrare primară. Acestea realizează printre altele
următoarele operaţii: converise curent - tensiune, filtrare, atenuare.
Conversia curent tensiune. Se realizează prin conectarea unui rezistor în
circuitul de ieşire (în curent) al traductorului . Rezistenţa acestuia se
calculeazăcu relaţia:
ΔU max
R (2.1)
ΔI max
în care: - R este rezistenţa rezistorului;
34
- ΔUmax - domeniul tensiunii la intrarea CAN;

- ΔImax - domeniul curentului de la traductor.
Exemplul 2.1
Să se calculeze rezistenţa R pentru un traductor cu i  [4...20 mA] care se
conectează la un CAN care admite la intrare u  [...1V ] , domeniul util fiind
u  [0,2...1V ] .
Rezolvare
În figura 4.16 se prezintă conectarea traductorului la CAN şi caracteristica
statică a convertorului curent - tensiune realizat cu rezistorul R.
u [V ]
i
1
Traductor R u CAN
0.2
i [mA ]
4 20
a) b)
Fig. 2.13. Conversia curent - tensiune:
a - schema de conectare; b - caracteristica statică.
Aplicând relaţia (2.1) rezultăpentru R valoarea :

1  0,2
R  500 
(20  4 )10  3
Filtrarea are drept principal, scop rejecţia tensiunilor parazite induse în

cablurile de conectare. Uzual se folosesc filtre simple trece jos iar în situaţii
deosebite chiar filtre active.
Atenuarea se realizează prin utilizarea divizoarelor rezistive.
Performanţele atenuatoarelor sunt dictate atât de precizia cât şi de stabilitatea
termicăşi în timp a rezistoarelor.
 Multiplexoarele. MUX sunt dispozitive care permit conectarea unei
resurse la mai mulţi utilizatori, situaţi din punct de vedere topologic înaintea
acesteia. Multiplexarea poate fi analogică sau numerică. Soluţiei de SADA
prezentate în figura 4.15 a îi este specifică multiplexarea analogică în care
utilizatorii sunt reprezentaţi de canalele analogice de intrare iar resursa de
ansamblul AFAP-DER-CAN. Pentru varianta de SADA din figura 4.15 b, în care
multiplexarea este numerică, utilizatorii sunt constituiţi din CAN asociate
fiecărui canal iar resursa de RT şi implicit de magistrala de date a sistemului.
35
MUXA este constituit dintr-o reţea de comutatoare comandate, care pe

baza unei adrese de selecţie dirijează o anumită intrare către ieşirea unică. În
figura 2.14 se prezintă schematic un MUXA cu 8 intrări şi tabelul de adevăr al
selecţiei canalelor.
EN A2 A1 A0 Y
I0
1 0 0 0 I0
I1 1 0 0 1 I1
Y 1 0 1 0 I2
1 0 1 1 I3
1 1 0 0 I4
I7 1 1 0 1 I5
1 1 1 0 I6
1 1 1 1 I7
EN A2 A1 A0 0 * * * -
a) b)
Fig. 2.14. MUXA cu opt intrări:
a - schema principială; b - selecţia intrărilor.
După cum se observă din figura 2.14.b, cuvântul de adresă este format din
4 biţi, din care 3 sunt pentru selecţia canalului (A2,A1,A0) iar bitul EN (enable)
este utilizat pentru selecţia MUX. Orice combinaţie A2A1A0 va conduce la
selecţia unui canal, numai dacă MUX este activat, respectiv dacă EN=1.
În general pentru un MUXA cu n canale de intrare cuvântul de selecţie a
unui canal va fi format din log2n+1 biţi, unde n este o putere întreagă a lui 2.
Elementul principal al MUXA îl constituie reţeaua de comutatoare care
poate fi realizată în următoarele variante constructive:
- cu relee obişnuite;
- cu relee cu mercur;
- cu relee reed;
- cu elemente semiconductoare.
Primele trei variante, care utilizează elemente electromecanice sunt
caracterizate de investiţii iniţiale reduse, compensate însă de un efort
considerabil în timpul exploatării, datorită fiabilităţii şi duratei de viaţă reduse.
Dintre variantele cu elemente electromecanice s-au impus atenţiei,
datorită unui raport performanţă/cost acceptabil, MUX realizate cu relee reed
Un releu reed a cărui structură este prezentată în figura 2.15, poate oferi
următoarele performanţe:
- rezistenţa contactului închis mai mică de 50 mΩ ;
36
- viteza de comutaţie ridicată chiar în cazul unor frecvenţe de ordinul 250

parametri / secundă;
- durata de viaţă ridicatăsituată între 106 şi 109 cicluri.
Este de menţionat faptul că durata de viaţă a unui releu reed este
condiţionată de respectarea specificaţiilor referitoare la încărcarea acestuia
(rezistenţă de sarcină).
4 3
2
1
U
Fig. 2.15. Schema principialăa unui releu reed:
1 - lamelăfixă; 2 - capsulădin sticlă; 3 - bobină;
4 - lamelămobilă.
Reţelele de comutatoare statice sunt realizate cu dispozitive

semiconductoare care lucrează în regim de comutaţie. Comutatoarele pot fi
realizate cu tranzistoare bipolare sau speciale, în figura 2.16 fiind prezentat un
comutator realizat cu tranzistoare cu efect de câmp (FET).
D S
RC
G
UC U0 RS
Ui
Fig. 2.16. Comutator electronic realizat cu FET:

RS - rezistenţăde sarcină; RC - rezistenţăaferentăcanalului de intrare;
Ui - tensiune de intrare; U0 - tensiune de ieşire; UC - tensiune de
comandă; D - drenă; S - sursă; G - grilă.
Cu notaţiile din figura 2.16 expresia tensiunii la ieşire este:
Rs
U0  Ui (2.2)
Rs  Rc  rDS (ON )
37
în care rDS(ON) reprezintă rezistenţa tranzistorului drenă-sursă în conducţie (de

ordinul ohmilor).
MUXA se realizează de regulă pentru un număr relativ redus de canale, 8
sau 16. Creşterea capacităţii de multiplexare se realizează prin conectarea mai
multor MUXA. În figura 2.17 se prezintă o asemenea soluţie , prin conectarea
MUXA paralel, în varianta a, respectiv serie în varianta b.
Prin conectarea în paralel a m MUXA cu n intrări se obţine un MUXA cu
m  n intrări. Conectarea în serie presupune utilizarea a m+1 MUXA,
capacitatea rezultată fiind de m  n  (n  m) canale.
Pe lângă avantajul creşterii numărului de canale multiplexate, cele două
soluţii prezintă şi dezavantaje cum ar fi:
- micşorarea impedanţei de intrare a amplificatorului care succede
MUXA (varianta a);
- creşterea rezistenţei comutatoarelor în conducţie care poate
influenţa precizia achiziţiei (varianta b).
1 1
2 MUX 2 MUX
1 1
n n
1 1 1
2 MUX 2 MUX 2
2 Y 2 Y
n n MUX
m 0
n
1 1
2 MUX 2 MUX
m m
n n
a) b)
Fig. 2.17. Configuraţii de multiplexoare: a - paralel; b - serie.
În cazul MUXN resursa comună poate fi reprezentată de un canal de

comunicaţie, iar utilizatorii de surse de semnal cum ar fi: traductoare numerice
sau quasinumerice, stări contacte etc.
În figura 2.18 este prezentată structura unui MUXN pe un bit 4:1, realizat
cu porţi ŞI-SAU-NU şi care are următoarea funcţie de selecţie:
38
Y  EN  ( A0  A1  D0  A0  A1  D1  A0  A1  D2  A0  A1  D3 ) (4.3)
A1 A0 D0 D1 D2 D3 EN
Y W
Fig. 2.18. MUXN pe un bit cu patru intrări:
A1, A0 - biţi selecţie canal; EN - bit selecţie MUXN;
D0…D3 - intrări numerice; Y - ieşire directă; W - ieşire negată.
In sistemele industriale achiziţia mărimilor numerice nu se realizează la

nivel de bit ci la nivel de cuvânt binar cu o lungime egală, de regulă, cu cea a
magistralei de date. Ca şi în cazul MUXA creşterea capacităţii de multiplexare se
poate realiza prin gruparea convenabilă a MUXN elementare.
 Amplificatoare cu factor de amplificare programabil Într-un SIPC
amplificatoarele pot realiza una sau mai multe din următoarele funcţii:
- amplificarea semnalului;
- adaptarea de impedanţă între surse şi DER;
- conversia curent tensiune;
- rejecţia zgomotului de mod comun dintr-un semnal diferenţial.
În cele ce urmează se vor face referiri la principala funcţie a
amplificatoarelor şi anume aducerea semnalelor preluate de la traductoare în
domeniul de lucru al ansamblului DER-CAN.
Dacă sursele se semnal nu oferă semnale în aceeaşi gamă se utilizează
AFAP. În figura 4.22 se prezintă structura unui AFAP, care conţine un
amplificator operaţional AO a cărui rezistenţă de intrare poate fi modificată prin
comanda de la calculator a comutatoarelor Ci.
39
C1
R/8 R2
C2
R1 R/4
C3
R/2
C4
-
U1 R
+ U2
Circuit de comandă
De la
calculator
Fig. 2.19. AFAP cu rezistenţă variabilă pe intrare.
Amplificarea structurii prezentate în figura 2.19 este

R
A 2 (3.4)
R1
în care rezistenţa de intrare R1 se determină cu relaţia

R1  R  (23  c1  2 2  c2  21  c3  20  c4 ) 1 , (3.5)
unde ci are valori logice 0 sau 1 funcţie de starea deschis sau închis a
comutatoarelor Ci. În tabelul 4.1 se prezintă valorile |A|1 pentru toate
combinaţiile posibile ale comutatoarelor, în situaţia R=R2.
Tabelul 2.1
Valori posibile pentru A
C1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
C2 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
C3 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
C4 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
A 0 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1
Eroarea tipică a structurii din figura 2.19 este datorată faptului că

rezistenţele comutatoarelor introduse de comutatoarele Ci (realizate cu
tranzistoare cu efect de câmp, bipolare, relee REED etc.) se înseriază cu
rezistenţele reţelei de comutatoare din MUX .
1
Din combinaţiile prezentate se eclude combinaţia 0000 care ar corespunde tuturor comutatoarelor deschise.
40
Structura prezentată în figura 2.20, în care rezistenţa variabilă este

conectată pe reacţia amplificatorului operaţional elimină acest neajuns.
Când este necesar un domeniu larg de amplificare şi în acelaşi timp se
solicită o rezoluţie fină între două trepte, se poate introduce în cascadă un al
doilea etaj cu amplificare programabilă.
Circuit de
comandă
De la C1 C2 C3 C4
calculator
R 2R 4R 8R
R
-
U1 +
U2
Fig. 2.20. AFAP cu rezistenţe variabile pe reacţie.
 Dispozitive de eşantionare şi reţinere. Utilizate împreună cu CAN,

DER asigură memorarea analogică a semnalului pe durata conversiei analog
numerice. Principial, un DER conţine o secţiune de eşantionare şi una de
memorare ilustrate în figura 2.21.
De la BC
calculator



 K U2
U1
CM
Fig. 2.21. Structura principială a unui DER
Funcţioanrea DER are loc în douăetape şi anume:

 obţinerea informaţiei, caracterizatăde timpul de obţinere T0;
 memorarea informaţiei, caracterizatăde timpul de memorare TM.
41
 Convertoare analog-numerice. CAN realizează conversia unui

semnal din formă analogică în formă numerică în vederea prelucrării ulterioare
prin metode numerice.
Procesul prin care are loc această transformare constituie o clasificare a
mărimii de intrare (uzual semnal în tensiune) într-un număr de clase sau canale
distincte. Rezultatul conversiei este practic reprezentat de numărul canalului
căruia îi este repartizată valoarea respectivă.
Mărimea de intrare Ui este repartizatăcanalului k dacăea satisface relaţia
de apartenenţăla acest canal:
Lk  U i  Lk 1 (2.6)
în care Lk şi Lk-1 sunt limitele superioare ale canalelor k, respectiv k-1. Diferenţa
celor două limite
U  Lk  Lk 1 (2.7)
constituie lăţimea canalului.
Din cele prezentate, rezultă că oricărei valori Ui care satisface relaţia (2.6)
i se ataşează acelaşi număr de canal. Apare de aici ideea existenţei unei erori
inerente de cuantificare egală cu lăţimea unui canal.
Determinarea numărului canalului N se face în baza relaţiei:
Ui
N , (2.8)
UR
în care UR reprezintă o tensiune de referinţă. Uzual N se exprimă în număr de
cuante sau număr de unităţi CAN (uCAN).
Indiferent de tipul CAN rezultatul conversiei este un cuvânt binar în
structura căruia se evidenţiază:
 BSMin - bitul de semnificaţie minimă amplasat în extrema dreaptă a
cuvântului binar;
 BSMax - bitul de semnificaţie maximă amplasat în extrema stângă a
numărului binar.
Ca ponderi lui BSMax îi corespunde 1/2 din domeniul de variaţie
(diapazonul) al mărimii Ui iar lui BSMin i se asociază reprezintă 1/2n din acelaşi
diapazon.
Dacă n reprezintă lungimea în biţi a cuvântului convertit (rezoluţia),
atunci numărul maxim de cuante (canale) va fi
N max  2 n  1 , (2.9)
iar valoarea unui canal se va obţine:
42
n 1
N  ai 2i , ai {0,1} , (2.10)
i 0
Cunoscând valoarea tensiunii de referinţă UR şi lungimea cuvântului

convertit n se poate determina limita maximă a domeniului tensiunii de intrare
U i max  (2 n  1)  U R (2.11)
Considerând un canal identificat prin valoarea sa medie, rezultă eroarea
inerentă de cuantificare ca fiind  U / 2 , respectiv  1/ 2 BSMin .
N
111
110
½ Bsmin
101
100
011
010
001
000 Ui
0.5 1.5 2.5 3.5 4.5 5.5 6.5 7.0 * UR
C
 ½ Bsmin
- ½ Bsmin Ui
0.5 1.5 2.5 3.5 4.5 5.5 6.5 7.0 * UR
Fig. 2.22. Caracteristica de transfer idealăa unui CAN cu rezoluţia de 3 biţi:

N - număr de cuante; Ui - tensiunea de intrare; UR - tensiunea de referinţă;
c - eroarea de cuantificare.
Pe baza precizărilor anterioare, în figura 2.22 se prezintă caracteristica

ideală a unui CAN cu rezoluţia de 3 biţi şi variaţia a erorii inerente de
cuantificare. În afara erorii inerente de cuantificare, procesul de conversie mai
poate fi însoţit de următoarele tipuri de erori :
- eroarea de decalaj a nulului (offset);
- eroarea de amplificare;
- eroarea de neliniaritate.
43
Determinarea biţilor cuvântului convertit se poate face simultan sau

succesiv. Pentru prima metodă sunt semnificative CAN de tip paralel iar pentru
a doua metodă CAN cu reacţie.
 CAN de tip paralel determină toţi biţii reprezentării numerice ca
urmare a comparării tensiunii de intrare cu niveluri prestabilite de tensiune. În
figura 4.26 se prezintă structura unui CAN paralel cu n = 2 biţi.
3Uref /4 Uin
Codificator
R
- Y3
Uref 
R
2Uref /4 - Y2

R
Uref /4 - Y1

R
Bit2 (BSMax) Bit1 (BSMin)
Fig. 2.23. CAN paralel pe doi biţi.
După cum se observă nivelurile prestabilite de tensiune sunt echidistante,

diferenţa dintre acestea fiind egală cu lăţimea canalului de conversie, respectiv
BSMin. În tabelul 4.2 sunt evidenţiate ieşirile comparatoarelor C1, C2, C3 funcţie
de valorile tensiunii Uin.
Tabelul 2.2
Valori logice asociate CAN pe doi biţi
Uin Y3 Y2 Y1 Bit2 Bit1

0  Uref /4 0 0 0 0 0
Uref /42 Uref /4 0 0 1 0 1
2Uref /43 Uref /4 0 1 1 1 0
3Uref /4 Uref 1 1 1 1 1
44
Din tabelul 2.2 rezultă următoarele funcţii logice pentru codificator:

Bit 2  Y3Y2Y1  Y3Y2Y1  (Y 3  Y3 )Y2Y1  Y2Y1 (2.12)
Bit 1  Y 3 Y 2Y1  Y3Y2Y1  (Y 3 Y 2  Y3Y2 )Y1 . (2.13)
În cazul general, pentru o rezoluţie a CAN de n biţi sunt necesare 2n-1
comparatoare. CAN paralel prezintă avantajul rapidităţii conversiei, dar odată cu
creşterea rezoluţiei creşte exponenţial numărul de codificatoare şi se complică
logica de codificare.
CAN cu reacţie asigură un compromis între viteza de conversie şi
simplitatea constructivă. La aceste CAN determinarea structurii cuvântului
convertit se face prin comparaţii succesive. Din această categorie se va prezenta
succint în cele ce urmează unul din cele mai răspândite CAN şi anume cel cu
aproximaţii succesive, a cărui schemă bloc se află în figura 2.24.
Aşa cum reiese din figură CAN funcţionează în buclăînchisă, pe calea de
reacţie găsindu-se un convertor numeric analog (CNA). Acesta este comandat de
un registru special numit registru cu aproximaţii succesive (RAS). În momentul
începerii conversiei toţi biţii RAS sunt în starea 0 cu excepţia BSMax care este
prestabilit în starea 1. Cu această structurăa biţilor, RAS comandă CNA a cărui
tensiune UCNA este aplicată comparatorului C.
Configuraţia biţilor din RAS face ca prima comparaţie a lui Uin să se
efectueze cu Umax/2, cât reprezintă în tensiune BSMax. Dacă Uin > Umax/2,
BSMax rămâne 1, altfel este trecut în 0. La ciclul următor tensiunea generată de
CNA va fi în primul caz 3Umax/4 iar în al doilea Umax/4. Procesul continuă prin
comparaţii succesive ale tensiunii Uin cu aproximaţii tot mai bune ale sale, până
când se determină BSMin.
RAS
Start Registru deplasare Sfârşit
conversie
Tact
Uin 1 2 n
+ Intrar Ieşire
serie
- date
..
… .
Ieşire
BSMax BSMin paralel
UCNA
Umax
CNA
Fig. 2.24. Schema de principiu a unui CAN cu aproximaţii succesive.
45
Uin
Da 4U max Nu
u in 
8
100 000
Da 6U max Nu Da 6U max Nu
u in  u in 
8 8
110 100 110 100
7U max 5U max 3U max U max

u in  u in  u in  u in 
8 8 8 8
Da Nu Da Nu Da Nu Da Nu
111 110 101 100 011 010 001 000
Fig. 2.25. Selectarea codului pentru un CAN cu aproximaţii succesive cu n = 3 biţi.
Astfel pentru conversia completă a unui semnal analogic într-un număr

de n biţi sunt necesare n comparări ale semnalului de intrare cu semnalul de
reacţie. Aceste n comparări împreună cu ajustarea semnalului de reacţie necesită
n perioade de tact. Ajustarea semnalului de reacţie presupune admiterea bitului
k, dacă semnalul de reacţie până la bitul k este mai mare decât semnalul de
intrare şi respingerea lui în caz contrar. În afara celor n perioade de tact
menţionate mai este necesară încă una pentru iniţializarea RAS la începutul
conversiei.
La sfârşitul conversiei tensiunea de reacţiei Ur care reprezintă cea mai
bună aproximaţie a semnalului de intrare realizată cu n biţi este :
n ai
U r  U max  i
ai {0,1} . (2.14)
i 1 2
Tehnica de selecţie a biţilor reiese din figura 2.25, unde s-a considerat un
CAN cu rezoluţia de 3 biţi. După cum reiese din figura 2.25 stabilirea unei
combinaţii la ieşire se realizează prin 3 treceri, alocarea canalelor fiind
prezentată în figura 2.26.
000 001 010 011 100 101 110 111
0 1 2 3 4 5 6 7 8 * Umax/8
Fig. 2.26. Alocarea canalelor pentru un CAN cu n = 3 biţi.
46
Având în vedere rolul deosebit al CAN în realizarea performanţelor

globale ale SADA, la alegerea CAN trebuie avute în vedere:
- domeniul semnalului de intrare;
- natura semnalului de intrare;
- durata admisibilă a conversiei;
- rezoluţia necesară;
- erorile admisibile maxime;
- tipul transmisiei semnalelor convertite (serie sau paralel).
O cerinţă importantă care se impune CAN este rezoluţia. Referitor la acest
parametru trebuie avută în vedere implicarea CAN într-un sistem de măsurat a
cărui clasă de precizie este dictată de elementul cu precizia cea mai scăzută.
Pornind de la aceste considerente se poate aprecia că o rezoluţie de 12 biţi este
pe deplin satisfăcătoare pentru sistemele de achiziţie industriale.
2.3.3. Subsistemul de achiziţie a datelor numerice

Acest subsistem (SADN) asigură accesul pe magistrala de date a
sistemului a informaţiei numerice referitoare în mod deosebit la starea
procesului sau a unor diviziuni ale acestuia. Dacă se utilizează traductoare cu
ieşirea numerică, SADN asigură preluarea informaţiei numerice furnizate de
acestea.
Un canal multiplu de achiziţie a datelor numerice îndeplineşte următoarele
funcţii: - colectarea şi centralizarea informaţiei din proces;
- selectarea liniilor de intrare şi adaptarea la caracteristicile
receptorului;
- transferul în memoria sistemului prin intermediul magistralei de date.
I11 EPP1
M RT
I1m EPP1
U
MD
X
In1 EPPn
BC
N
Inm EPPn
Fig. 2.27 Structura principialăa unui SADN.
Datele pot fi preluate individual sau pe grupe de 8 sau 16 semnale funcţie

de lungimea cuvântului de date a sistemului de calcul. Semnalele pot fi pur
47
numerice (niveluri de tensiune, curent sau stări contacte) sau quasinumerice

(durata sau frecvenţa unor impulsuri). Intrările numerice pot fi statice, când sunt
sesizate nivelurile sau dinamice, atunci când sunt sesizate tranziţiile. Funcţiile
prezentate ale SADN pot fi realizate de către structura din figura 4.30.
Ui U
Ui Ue
Formator
t t
Ue
Uimin Uimax Ui
Fig. 2.28. Formarea impulsurilor în cadrul EPP.
Această structură permite achiziţia a n grupe fiecare formatădin câte m

parametri numerici. Elementele de joncţiune asigură cuplarea fizică a liniilor
numerice la SADN. Elementele de prelucrare primară EPP asigură adaptarea
semnalelor numerice la cerinţele multiplexorului numeric MUXN.
În vederea preîntâmpinării aspectelor negative datorate fluctuaţiilor
nivelurilor semnalelor de intrare, în cadrul EPP se pot utiliza formatoare cu
hysterezis (figura 2.28).
Dacă informaţia preluată din proces reprezintă starea unor contacte, în
structura EPP intră circuite pentru filtrarea oscilaţiilor produse datorită
imperfecţiunii acestora (figura 4.32).
R
Vcc
Ue
Ue
t
Ue
Vcc t
R
Fig. 2.29. Schemă pentru filtrarea oscilaţiilor mecanice.
O alternativă la filtrarea hardware o reprezintă filtrarea software, prin

introducerea unor bucle de întârziere în rutinele care prelucrează informaţia
furnizată de contacte.
48
În urma prelucrării primare semnalele numerice sunt aplicate MUXN, care

pe baza unei adrese primite de la blocul de comandă BC va selecta canalul al
cărui conţinut urmează a se înscrie în registrul tampon RT comandat tot de către
blocul de comandă BC.
La realizarea SADN, o problemă importantă o reprezintă izolarea
atât faţă de mediul extern cât şi faţă de calculator, o soluţie larg utilizată fiind
cuplarea optică.
2.3.4. Probleme ce privesc conectarea interfeţelor la proces
Performanţele unui SADA sunt nemijlocit legate de maniera în care acesta este
conectat la proces. Dupăcum s-a văzut, în structura SADA intrăelementele de
joncţiune care trebuie săprezinte o rezistenţăde contact cât mai mică.
Legat de conectarea sistemului de interfaţăla proces se pun următoarele
probleme:
- rejecţia erorilor de mod comun;
- reducerea zgomotului indus în circuitele de intrare;
- realizarea unei împământări corespunzătoare .
 Erorile de mod comun apar datorită faptului că potenţialul masei
traductorului diferă de potenţialul masei SADA, în situaţia în care traductorul
este conectat printr-un singur fir (figura 2.30)
Traductor Vs Vin SADA
GndT Vg GndS
Fig. 2.30 Eroarea de mod comun în cazul conectării

monofilare:
Din figura 2.30 se observăcă Vin=Vs+Vg, Vg fiind

neglijabilădacătraductorul şi SADA au punctele de masăapropiate.
Intrucât în condiţii industriale Vg poate fi de ordinul zecilor sau chiar
sutelor de V, o conectare de tipul celei din fig. 5.49 nu este posibilădecât în
condiţii de laborator. În industrie se utilizează în exclusivitate conectarea
diferenţială, prezentată în figura 2.31.
La modul ideal, conectarea diferenţială este caracterizată de egalitatea
tensiunilor Vg şi Vin. În realitate, datorită distribuţiilor neuniforme ale
49
impedanţei şi izolaţiei liniilor de transmisie, între cele două tensiuni apar

diferenţe cunoscute sub numele de erori de mod comun.
Traductor Vs Vin SADA
GndT GndS
Fig. 5.50 Conectarea diferenţialăa unui traductor
Pentru determinarea acestora, din motive legate de simplificarea

calculelor se utilizeazăîn locul unei scheme cu parametrii distribuiţi, schema
echivalentăcu parametrii concentraţi din fig. 5.51. Prin aplicarea teoremei
superpoziţiei, în condiţiile pasivizării sursei Vs se obţine:
(R 1  R g 2  R 2  R g1 ) R S
Vin  Vcm . (2.15)
R S (R 2  R g 2 )(R 1  R g1 )  R 2 R g 2 (R 1  R g1 )  R 1 R g1 (R 2  R g 2 )
Ordinele de mărime pentru rezistenţele care intervin în relaţia (2.25) sunt:

pânăla 1 kΩ pentru R1 şi R2 , zeci de MΩ pentru Rs şi sute de MΩ pentru Rg1
şi Rg2, astfel încât se poate aprecia căR2Rg2<<Rs şi R1Rg1<<Rs.
Cu aceste precizări relaţia 2.25 devine:
R 1  R g 2  R 2  R g1
Vin  Vcm . (2.36)
( R 2  R g 2 )( R 1  R g1 )
R2
VS Rg2 RS Vin
R1
SADA
Vcm Rg1
Fig. 2.31 Schema echivalentăa conectării diferenţiale:

VS , Vcm - tensiunile surselor de semnal şi de mod comun;
R1 , R2 - impedanţele liniilor de transmisie;
Rg1 , Rg2 - rezistenţele de izolaţie ale liniilor de transmisie;
RS - rezistenţa de sarcină; Vin - tensiunea achiziţionată.
50
Se defineşte raportul de rejecţie de mod comun (CMMR- Common Mode

Rejection Ratio) ca fiind raportul dintre tensiunea de mod comun şi tensiunea
produsăde aceasta la intrarea SADA:
Vcm ( R 2  R g 2 )( R 1  R g1 )
CMMR   . (2.37)
Vin R 1  R g 2  R 2  R g1
Dacărezistenţele de izolaţie au valori apropiate Rg1  Rg2  Rg atunci:
Rg
CMMR  (2.38)
R1  R 2
sau exprimat în decibeli:

CMMR(db)=20lg(CMMR). (2.39)
Valori uzuale ale CMMR se situeazăîn intervalul 100-120 db în condiţiile
unei asimetrii a liniilor de transmisie de pânăla regul1 kΩ.
 De regulă semnalul util achiziţionat este însoţit de zgomote provocate
de fenomenul de inducţie electromagnetică, regimurile tranzitorii în circuitele
electrice, procesul de eşantionare etc.
Zgomotul produs de primele douăsurse poate fi diminuat printr-o separare
a traseelor conductoarelor de semnal de cele ale cablurilor de alimentare cu
energie. Alături de separarea traseelor, pentru rejectarea zgomotelor se
recomandă:
- filtrarea hardware, cu filtre pasive sau/şi active;
- torsadarea cablurilor de transmisie;
- ecranarea cablurilor cu împământarea ecranului într-un singur punct.
În figura 2.32 sunt prezentate toate cele 3 soluţii pentru un semnal de
nivel mic de la un termocuplu.
Conductoare torsadate
Filtru
Ecran
Fig. 2.32 Soluţie pentru rejectarea zgomotelor în circuitele de

i l
 In ceea ce priveşte împământarea, aceasta trebuie realizatăîntr-un

singur punct cu repsectarea prescripţiilor în ceea ce priveşte rezistenţa electricăa
prizei centrale.
51
La realizarea împământării echipamentele aferente sistemului de

conducere se grupează în 4 diviziuni după cum urmează:
- subsistemul analogic;
- subsistemul numeric;
- subsistemul de alimentare cu energie;
- construcţia metalică aferentă.
Pentru fiecare subsistem se defineşte câte un punct de masă, iar toate
punctele locale de masăse leagăla priza unicăde împământare (figura 2.32).
Toate conexiunile atât la punctele locale de masăcât şi la priza unicăde
împământare se vor efectua cu conductoare multifilare scurte şi groase.
Subsistem Subsistem
analogic numeric
Masăanalogică
Masănumerică
Masăsursă Masă
alimentare construcţie
metalică
Masa generală
a sistemului
Fig. 2.33 Împământarea sistemului de conducere cu o singură priză.
După cum s-a văzut SIPC conectează două entităţi cu caracteristici

energetice complet diferite: calculatorul şi procesul. Necesitatea protecţiei
echipamentului de conducere şi chiar a personalului de exploatare la tensiunile
periculoase conduce la ideea separării galvanice între sursele de semnal
(traductoare) şi echipamentul numeric.
Soluţia o reprezintăutilizarea amplificatoarelor cu izolare pentru SADA şi
a simplei cuplări optice pentru SADN. Problema decuplării galvanice se pune şi
la transmiterea comenzilor, soluţiile fiind aceleaşi ca la subsistemul de achiziţie.
În figura 2.33 este prezentată schema principială a unui amplificator cu
decuplare, în care izolarea galvanică între intrare, ieşire şi sursa de alimentare
este evidenţiatăprin utilizarea de simboluri diferite de conectare la masă pentru
cele 3 componente.
52
În scopul izolării galvanice, transferul semnalului de la amplificatorul de

intrare la cel de ieşire se poate realiza prin cuplaj inductiv, optic sau chiar
capacitiv. Pentru cuplajul inductiv se realizează transformatoare cu bandă de
trecere 102-106 Hz şi tensiuni de străpungere mai mari de 5 kV. Pentru cuplajul
optic se utilizează ansambluri LED - fototranzistori cu tensiuni de străpungere
mai mari de 2,5 kV.
Prin intercalarea unui cablu optic între cele două elemente ale cuplorului
se poate obţine izolare până la tensiuni de 102-103 kV.
Izolarea galvanică între sursa de alimentare şi intrarea respectiv ieşirea
amplificatorului cu izolare se realizează prin intermediul unui convertor curent
continuu-curent continuu. Cuplajul optic prezintăo bandă de trecere mai largă în
timp ce liniaritatea este mai bunăîn cadrul cuplajului inductiv.
Pentru transferul semnalului de la AI la AO se utilizează:
- modulaţia în duratăpentru cuplajul inductiv sau optic;
- modulaţia în amplitudine a unei purtătoare sinusoidale în cazul
cuplajului inductiv;
- modulaţia în intensitate luminoasăîn cadrul cuplajului optic.
Intrare A AO
Ieşire
Convertor
CC / CC
SA
Fig. 2.34 Schema de principiu a unui amplificator cu

izolare: AI - amplificator de intrare; AO - amplificator de
ieşire; SA - sursăde alimentare.
53
E1 E2
R3
R2 R4
--
AI --
 I2 AO
 Ue
R1
I1 OC2
Ui
OC1
Fig. 2. 35 Structura principialăa unui amplificator de

izolare cu cuplaj
În figura 2.35 se prezintă schema principială a unui amplificator cu

cuplaj optic. Structura acestuia cuprinde 2 circuite optocuploare OC1 şi OC2,
fiecare constituit dintr-un ansamblu LED-fototranzistor. Optocuplorul OC2
realizează separarea galvanică între intrarea şi ieşirea amplificatorului iar OC1
este inclus în bucla de reacţie negativă a amplificatorului de intrare. Cu notaţiile
din figura 2.34 rezultă:
U i E1
I1   , (2.40)
R1 R 2
Ue E 2
I2   . (2.41)
R4 R3
Deoarece diodele celor două optocuploare sunt conectate în serie, rezultă

egalitatea curenţilor din cele două fototranzistoare, respectiv I1şI2. Pe baza
acestei precizări şi a relaţiilor (2.40) şi (2.41) se deduce ecuaţia caracteristicii
statice a amplificatorului cu izolare:
R4  E1 E 2 
ue  ui  R 4   . (2.42)
R1  R 2 R1 
Se constată liniaritatea caracteristicii şi independenţa acesteia faţă de

caracteristicile optocuploarelor (în condiţiile în care I1=I2)
54
Tehnici de implementare
CAPITOLUL
a operațiilor multitasking
3 de achiziție și prelucrare
a datelor
Execuţia aplicaţiilor de timp real impune ca acestea să fie dezvoltate prin

tehnici care să permită rezolvarea problemelor specifice fără a se declanşa
conflicte în utilizarea resurselor maşinii şi cu respectarea constrângerilor de
natură temporală.
În prezentul capitol se va realiza o prezentare a principalelor mecanisme
specifice programării în timp real. Acestei prezentări i se va adăuga o abordare
succintă a problemei formalizării sistemelor de taskuri.
3.1. Stările şi evoluţia taskurilor

Aplicaţiile de timp real se dezvoltă apelând la programarea paralelă sau
concurentă. Două taskuri se numesc paralele sau concurente1 dacă prima
instrucţiune a unuia trebuie executată înainte de încheierea ultimei instrucţiuni a
celuilalt. O execuţie pur paralelă este posibilă în situaţia în care maşina pe care
se execută aplicaţia conţine mai mult de o Unitate Centrală de Procesare
(UCP). În cazul sistemelor cu o singură UCP execuţia este pseudoparalelă ,
timpul acesteia fiind partajat între mai multe taskuri.
Avantajul procesării pseudoparalele este evidenţiat de următorul
exemplu în care se evaluează gradul de utilizare a UCP pentru două situaţii şi
anume:
- procesare secvenţială;
- procesare pseudoparalelă.
Exemplul 3.1
Fie trei unităţi de program A, B, C caracterizate de distribuţia temporală
a operaţiilor specifice UCP (notate cu majuscule) şi de intrare – ieşire I/E
(notate cu minuscule) din figura 3.1.
1
Atributul de paralel are în vedere execuţia paralelă sau pseudoparalelă a mai multor acţiuni.
Atributul concurent se referă la faptul că taskurile se află în competiţie pentru deţinerea de resurse.
Capitolul 3 55
A: A1 a1 A2 a2 A3 t [ut]
0 30 50 80 120 130
B: B1 b1 B2 t [ut]
0 20 40 60
C: C1 c1 C2 c2 C3 c3 C4 c4 C5 t[ut]
0 10 20 60 80 100 110 120 140 150
Fig. 3.1. Secvenţe aferente execuţiei a trei aplicaţii A, B, C: ut – unităţi de timp.
Pentru execuţia secvenţială diagrama de timp este ilustrată în figura 3.2,
UCP: A1 A2 A3 B1 B2 C1 C2 C3 C4 C5 t[ut]
0 30 50 80 120 130 150 170 190 200 210 250 270 290 300 310 330 340
I/E: a1 a2 b1 c1 c2 c3 c4 t[ut]
0 30 50 80 120 150 170 200 210 250 270 290 300 310 330
Fig. 3.2. Execuţia pur secvenţială a aplicaţiilor A, B, C: ut – unităţi de timp.
iar pentru prelucrarea pseudoparalelă în figura 3.3.

În varianta secvenţială, din figura 3.2 se stabilesc următoarele valori
pentru tuc-s – timpul efectiv al UCP şi tex-s – timpul total de execuţie:
tex-s = 340 ut
tuc-s = 210 ut
valori cu care se calculează Gradul de utilizare a UCP secvenţial – GrutUCP-s
tUCP S 210
GrutUCP S    61,7% . (3.1)
t ExS 340
UCP: A1 B1 C1 A2 B2 C2 A3 C3 C4 C5 t[ut]
0 30 50 60 90 110 150 160 170 190 200 210 230 240
I/E: a1 b1 c1 a2 c2 c3 c4 t[ut]
0 30 50 70 80 90 130 150 170 190 200 210 230
Fig. 3.3. Execuţia pseudoparalelă a aplicaţiilor A, B, C: ut – unităţi de timp.
Capitolul 3 56
În varianta pseudoparalelă2, din figura 3.3 se stabilesc următoarele

valori pentru tuc-p – timpul efectiv al UCP şi tex-p – timpul total de execuţie:
tex-p = 240 ut
tuc-p = 200 ut
valori cu care se calculează Gradul de utilizare a UCP pseudoparalelă –
GrutUCP-P
tUCP  P 200
GrutUCP  P    83 ,3% . (3.2)
t Ex P 240
Execuţia intercalată a taskurilor presupune lucrul în întreruperi, taskurile
executându-se intercalat cu rutina te tratare a întreruperilor, aspect evidenţiat în
figura 3.4.
operaţii
….. …..
a A A A B A C t
Cerere de
întrerupere
Execuţie task
Cerere întrerupere
Execuţie
rutină tratare
b Execuţie task
Fig. 3.4. Execuţia intercalată a taskurilor.
În exemplul din figura 3.4 a se consideră următoarea semnificaţie a

taskurilor:
- A – task de achiziţie date de la CAN (iniţiat de un semnal de
întrerupere de la CAN la încheierea conbersiei);
- B – task de calcul comenzi (se executa la anumite intervale de
timp);
- C – task de avertizare (se execută la neîncadrarea între limite a
mărimii achiziţionate din proces).
2
Se consideră procesare pseudoparalelă în regim de timp divizat – time sharing.
Capitolul 3 57
În figura 3.4 b este reprezentată execuţia rutinei de tratare a unei

întreruperi. Se remarcă faptul că execuţia acestei rutine presupune întreruperea şi
apoi reluarea unui task.
În afara lucrului în întreruperi , execuţia intercalată a taskurilor mai
presupune existenţa în cadrul sistemului de operare a mecanismelor pentru:
- salvarea şi restaurarea stării unui task înainte, respectiv după
întrerupere;
- utilizarea neconflictuală a resurselor critice (excludere mutuală);
- coordonarea execuţiei taskurilor interactive (sincronizare);
- transferul de informaţie între taskuri (comunicare);
- activarea şi dezactivarea taskurilor.
Cele cinci mecanisme sunt implementate în nucleul SOTRM (executiv),
care se află în vecinătarea imediată secţiunii hardware şi care se consideră că
face parte din aplicaţia de timp real. După cum se observă din figura 3.5, o
asemenea aplicaţie mai conţine taskuri sistem şi taskuri utilizator.
Taskuri utilizator
Taskuri sistem
Nucleu SOTRM
Hardware
Fig. 3.5. Structura stratificată a unei aplicaţii de timp real.
O asemenea execuţie implică existenţa în cadrul SOTRM a

mecanismelor pentru:
- salvarea şi restaurarea stării taskurilor;
- utilizarea neconflictuală a resurselor critice (excluderea mutuală);
- coordonarea taskurilor interactive (sincronizarea);
- reglementarea schimbului de date între taskuri (comunicarea);
- activarea şi dezactivarea taskurilor.
În mod obişnuit un task are asociate în memoria internă trei secţiuni şi
anume:
Capitolul 3 58
- secţiunea de date – conţine operanzi şi rezultate ;

- secţiunea de cod – conţine codul care implementează algoritmul
aferent aplicaţiei realizate de task;
- secţiunea de stivă – în care sunt salvate informaţii care să permită
refacerea contextului la reluarea execuţiei taskului după o întrerupere.
În structura unei aplicaţii de timp real sunt incluse în mod obişnuit
taskuri interactive şi taskuri disjuncte.
 Taskurile interactive sunt taskurile care pe parcursul evoluţiei lor
utilizează resurse în comun şi fac schimb de informaţie .
 Taskurile disjuncte sunt taskuri care nu interacţionează, respectiv
care nu utilizează resurse în comun şi nu fac schimb de informaţie.
Evoluţia unei aplicaţii care conţine numai taskuri disjuncte este unică
indiferent de viteza şi ordinea de execuţie a taskurilor.
În ceea ce priveşte evoluţia unui sistem de taskuri interactive , aceasta
este influenţată de doi factori şi anume:
- modul de planificare a execuţiei taskurilor;
- modul de efectuare a tranziţie între stări şi/sau substări.
Execuţia unei aplicaţii de timp real presupune evoluţia taskurilor într-un
spaţiu al stărilor, în care tranziţiile sunt provocate de directive care pot fi emise
de către planificator sau de către taskul aflat în execuţie. În continuare vor fi
prezentate două abordări echivalente care privesc stările şi tranziţiile taskurilor.
3.1.1. Stările şi tranziţiile taskurilor – prima abordare
Conform acestei abordări un task se poate găsi într-una dintre
următoarele stări:
- necreat;
- creat;
- gata de execuţie;
- execuţie;
- blocat.
Aceste stări împreună tranziţiile posibile sunt ilustrate în figura 3.63.
3
Această reprezentare în care stările sunt considerate noduri iar directivele arce, mai este cunoscută şi
ca graf al tranziţiilor.
Capitolul 3 59
Dispecerizare
Deblocare EXECUŢIE LOGICĂ
BLOCAT Blocare
EXECUŢIE
FIZICĂ
Dezactivare
Dezactivare Dispecerizare
Dispecerizare
Dezactivare
CREAT GATA DE
Activare EXECUŢIE
Suprimare Suprimare Suprimare Suprimare
NECREAT
Creare
Fig. 3.6. Evoluţia taskurilor în spaţiul stărilor - abordarea 1.
 Un task necreat este un task necunoscut de executivul de timp real.

Acestea sunt de regulă rezidente în memoria externă şi prin urmare nu au
rezervate în memoria internă zone pentru cod, date şi stivă. Dacă sistemul pe
care se execută aplicaţia nu dispune de memorie externă, taskul necreat este
rezident în memoria internă, însă nu are alocate zone pentru date şi stivă.
După cum se observă din figura 3.7 din starea necreat se poate ajunge
numai în starea creat prin directiva de creare. Din oricare stare, execuţia
directivei suprimare determină tranziţia în starea necreat.
 Un task este în starea creat dacă este cunoscut de executiv, situaţie
în care are atribuit un identificator şi are alocate zone de memorie pentru date,
cod şi stivă.
Capitolul 3 60
EXECUŢIE
LOGICĂ
BLOCAT Suprimare Creare

NECREAT CREAT
CREAT
GATA DE
EXECUŢIE
Fig. 3.7. Tranziţiile asociate stării necreat.
După cum apare evidenţiat în figura 3.8, în starea creat se poate ajunge
prin directivele de creare (din starea necreat ) şi dezactivare din celelalte stări.
Din starea creat, se poate ajunge în starea gata de execuţie, prin directiva
activare sau necreat prin directiva de suprimare.
NECREAT
Creare
Suprimare NECREAT
EXECUŢIE
LOGICĂ
CREAT
BLOCAT
Dezactivare GATA DE
Activare
EXECUŢIE
GATA DE
EXECUŢIE
Fig. 3.8. Tranziţiile asociate stării creat.
 Un task este în starea gata de execuţie dacă îndeplineşte toate

condiţiile pentru preluarea controlului UCP, respectiv dacă este un task rulabil.
Când un task gata de execuţie satisface condiţia de prioritate sau de timp, prin
directiva de dispecerizare are loc tranziţia în starea execuţie logică. Alte tranziţii
posibile din starea gata de execuţie sunt în starea creat (directiva dezactivare) şi
necreat (directiva suprimare). După cum se observă din figura 3.8, în starea
gata de execuţie se poate ajunge numai din starea creat prin directiva de
activare.
 Un task este în starea execuţie dacă rularea sa a început şi dacă este
încă apt pentru rulare , indiferent că deţine sau nu controlul UCP. Dacă taskul
deţine controlul UCP este în execuţie fizică, altfel este în execuţie logică. Când
taskul pierde controlul UCP poate trece în execuţie logică, contextul fiind salvat
în stivă. Contextul mai salvat şi la tranziţia în starea blocat.
Capitolul 3 61
EXECUŢIE
LOGICĂ
Dispecerizare
Activare
CREAT GATA DE Dezactivare
EXECUŢIE CREAT
Suprimare
NECREAT
Fig. 3.9. Tranziţiile asociate stării gata de execuţie.
După cum reiese din figura 3.9, în care se prezintă tranziţiile stării
execuţie, în această stare se poate ajunge din starea gata de execuţie prin
directiva de dispecerizare sau blocat prin directiva de deblocare. Se observă de
asemenea că tot prin directiva dispecerizare se au loc tranziţiile execuţie fizică –
execuţie logică şi invers.
Dispecerizare
Blocare BLOCAT
Deblocare
BLOCAT EXECUŢIE LOGICĂ
Dezactivare
CREAT
Dispecerizare Suprimare
EXECUŢIE
GATA DE FIZICĂ NECREAT
EXECUŢIE
Dispecerizare
Fig. 3.10. Tranziţiile asociate stării execuţie.
 Un task este în starea blocat dacă a fost în execuţie fizică şi a

devenit inapt pentru rulare, datorită apariţiei unor condiţii de blocare cum ar fi:
- aşteptarea unui mesaj;
- aşteptarea unui eveniment;
- aşteptarea expirării unui timp;
- aşteptarea disponibilităţii unei resurse critice, etc.
Tranziţia în starea blocat este precedată de salvarea contextului, pentru
ca reluarea execuţiei sale, la dispariţia condiţiei de blocare, să se facă din
punctul unde a fost întrerupt.
Capitolul 3 62
După cum reiese din figura 3.11, în starea blocat se poate ajunge numai
din starea execuţie prin directiva blocare. În ceea ce priveşte tranziţiile din
starea blocat, acestea pot fi în una din stările execuţie (directiva deblocare),
creat (directiva dezactivare) sau necreat (directiva suprimare).
EXECUŢIE
Deblocare
Blocare
EXECUŢIE Dezactivare
BLOCAT CREAT
Suprimare
NECREAT
Fig. 3.11. Tranziţiile asociate stării blocat.
Aşa după cum s-a mai spus se poate considera că stările analizate mai sus
formează un spaţiu de evoluţie taskurilor. Tranziţiile între stări sunt determinate
de directive sau primitive care pot fi lansate de către taskul aflat în execuţie sau
de către executivul de timp real. În cele ce urmează vor fi prezentate unele
elemente aferente directivelor (primitivelor) aferente stărilor primei abordări.
 Directiva Creare asigură tranziţia NECREAT – CREAT care
presupune:
- atribuirea unui indicator;
- alocarea de memorie pentru cod şi stivă (dacă taskul era rezident
înainte de creare zona de cod ar putea fi deja alocată).
Stiva este în mod curent utilizată pentru:
- stocarea variabilelor locale ale taskurilor;
- transmiterea parametrilor şi memorarea adresei de retur la apelarea
unei funcţii;
- salvarea contextelor la ieşirea taskului din execuţie fizică.
Crearea unui task se poate face din alt task în timpul rulării sau în faza
de compilare. Pentru a lansa un task în execuţie executivul trebuie să cunoască
adresa de start, mărimea sivei şi prioritatea, elemente care se comunică la creare.
 Directiva Activare presupune tranziţia CREAT – GATA DE
EXECUŢIE. Această directivă realizează activarea unui task şi presupune
alocarea de memorie pentru date. Prin activare, care este interpretată ca o cerere
Capitolul 3 63
de rulare, un task trece de la condiţia de spectator la cea de competitor pentru

obţinerea controlului UCP şi implicit pentru rulare.
 Directiva Blocare presupune tranziţia EXECUŢIE – BLOCAT ceea
ce face ca respectivul task să iasă din rândul taskurilor rulabile, ca urmare a
apariţiei unei condiţii de blocare a execuţiei sale.
Dacă taskul era în EXECUŢIE FIZICĂ , condiţia de blocare se produce
în momentul rulării (directiva de autoblocare este conţinută în task). Este de
menţionat faptul că ieşirea din EXECUŢIE FIZICĂ presupune salvarea
contextului.
Dacă taskul era în EXECUŢIE LOGICĂ blocarea sa este este solicitată
printr-o directivă introdusă în taskul aflat în EXECUŢIE FIZICĂ.
 Directiva Dispecerizare este asociată următoarelor tranziţii în
spaţiul stărilor:
- GATA DE EXECUŢIE – EXECUŢIE FIZICĂ;
- EXECUŢIE FIZICĂ – EXECUŢIE LOGICĂ;
- EXECUŢIE LOGICĂ – EXECUŢIE FIZICĂ.
Prima tranziţie este iniţiată şi realizată de către dispecer (planificator)
atunci când cel mai prioritar dintre taskurile rulabile este un task în starea GATA
DE EXECUŢIE, căruia i se conferă controlul UCP. Intrarea în rulare a acestui
task este evident precedată de restaurarea contextului.
Al doilea tip de tranziţie are loc atunci când taskul aflat în EXECUŢIE
FIZICĂ cedează controlul UCP prin execuţia unei directive prin care solicită să-
şi întrerupă execuţia. O altă cauză o poate reprezenta existenţa unei întreruperi
fizice a cărei rutină de tratare apelează dispecerul de taskuri. În ambele situaţii
se impune salvarea întregului context al taskului care iese din EXECUŢIE –
FIZICĂ.
Ultimul tip de tranziţie este iniţiată şi realizată de către dispecer
(planificator) atunci când cel mai prioritar dintre taskurile rulabile este un task
în substarea EXECUŢIE LOGICĂ, căruia i se conferă controlul UCP. Ca şi în
cazul primului tip de tranziţie intrarea în rulare este precedată de restaurarea
contextului.
 Directiva Deblocare presupune tranziţia BLOCARE – EXECUŢIE
LOGICĂ atunci când condiţia care a determinat blocarea a dispărut şi taskul a
devenit din nou rulabil.
 Directiva Dezactivare poate determina una dintre următoarele
tranziţii:
- GATA DE EXECUŢIE – CREAT;
- BLOCAT – CREAT;
- EXECUŢIE – CREAT.
Capitolul 3 64
Prin toate aceste tranziţii taskurile revin în starea CREAT păstrând

alocată memorie pentru cod şi stivă şi indicatorii asociaţi la creare.
 Directiva Suprimare presupune realizarea uneia dintre următoarele
tranziţii:
- CREAT - NECREAT
- GATA DE EXECUŢIE – NECREAT;
- BLOCAT – NECREAT;
- EXECUŢIE – NECREAT.
Prin toate aceste tranziţii taskurile revin în starea NECREAT când li se
memoria pentru date şi stivă. Memoria de cod ar putea rămâne alocată pentru o
posibilă nouă tranziţie în starea CREAT. De asemenea oricare dintre aceste
tranziţii determină anularea indicatorilor asociaţi la creare.
3.1.2. Stările şi tranziţiile taskurilor – a doua abordare

În această abordare un task se poate găsi într-una dintre următoarele
stări:
- neinstalat;
- inactiv;
- activ,
stării activ fiindu-i asociate una dintre substările:
- execuţie;
- gata de execuţie
- blocat.
Aceste stări împreună tranziţiile posibile sunt ilustrate în graful din
figura 3.12.
 Un task neinstalat este un task rezident în memoria internă sau
externă, necunoscut de executivul de timp real.
 Un task inactiv este un task instalat, pentru care fie nu s-a făcut un
apel de rulare fie şi-a încheiat rularea (prin stop natural sau forţat).
 Un task activ este un task rulabil care se poate găsi într-una din
substările execuţie, gata de execuţie, blocat.
 Substarea execuţie corespunde situaţiei în care taskul deţine controlul
UCP. La sistemele cu o singură unitate centrală, un singur task se
poate găsi în această substare.
 Substarea gata de execuţie este specifică taskurilor care aşteaptă să
preia controlul UCP. Indicatorii asociaţi acestora se înscriu într-o
coadă, execuţia putându-se efectua în două moduri:
Capitolul 3 65
- ciclic (ROUND – ROBIN) , taskurile fiind executate succesiv în

interiorul unei cuante de timp sau până la terminarea normală;
- după priorităţi, controlul UCP fiind preluat de taskul cu prioritatea
cea mai ridicată.
 Substarea blocat este asociată taskurilor care se pot găsi într-una din
situaţiile:
- aşteaptă să i se aloce memorie;
- aşteaptă producerea unui eveniment;
- aşteaptă realizarea unei condiţii de timp;
- aşteaptă realizarea unei operaţii de intrare / ieşre.
ACTIV
Aşteptare
Aşteptare Preluare
GATA DE EXECUŢIE
BLOCAT
EXECUŢIE
Continuare Eliberare
Stop forţat Start Stop forţat Stop normal

din alt task din alt task
INACTIV
Instalare Ştergere
NEINSTALAT
Fig. 3.12. Evoluţia taskurilor în spaţiul stărilor - abordarea 2.
Tranziţiile între stări şi substări se poate realiza în două moduri şi

anume:
- prin întreruperi hardware sau software, contextul comutării fiind
determinat de nivelul întreruperii;
- prin apeluri către EXECUTIV din taskul aflat în EXECUŢIE.
Acestea sunt apeluri de subrutine neîntreruptibile numite PRIMITIVE sau
Capitolul 3 66
DIRECTIVE, contextul comutării fiind determinat de numele şi parametrii

directivei.
Există două categorii de directive şi anume:
- directive care nu declară un eveniment semnificativ , după a căror
execuţie controlul UCP este returnat taskului întrerupt;
- directive care declară un eveniment semnificativ , după a căror
execuţie controlul UCP este returnat taskului aflat pe prima poziţie în coada
taskurilor GATA DE EXECUŢIE.
În cele ce urmează se prezintă tranziţiile ilustrate în graful din figura
3.12 şi directivele asociate.
 Tranziţia NEINSTALAT – INACTIV se realizează prin directiva
Instalare care face cunoscut executivului taskul realizând în acelaşi timp
crearea şi alocarea blocului descriptor al taskului (BDT) care poate conţine
următoarele elemente:
- parametrii ai taskului (adresă de început, prioritate, identificator,
nume, etc.);
- mărimea stivei;
- indicatori către alte taskuri.
 Tranziţia INACTIV –NEINSTALAT se realizează prin directiva
Ştergere care elimină taskul din lista taskurilor cunoscute de către executiv şi
dezactivează BDT.
 Tranziţia INACTIV – ACTIV care presupune trecerea taskului în
substarea GATA DE EXECUŢIE se realizează prin directiva Start. Această
directivă semnifică practic un apel de rulare pentru respectivul task.
 Tranziţia GATA DE EXECUŢIE – EXECUŢIE se realizează printr-
o directivă de Preluare. După execuţia acestei directive controlul este cedat
taskului din prima poziţie a listei de aşteptare la procesor. După cum se va arăta
ulterior această listă poate fi organizată după priorităţi sau respectând principiul
rotaţiei.
 Tranziţia GATA DE EXECUŢIE – BLOCAT se realizează printr-o
directivă de Aşteptare, în situaţia în care taskului nu i se mai poate aloca
memorie pentru stivă dacă ar prelua controlul UCP.
 Tranziţia GATA DE EXECUŢIE – INACTIV se realizează printr-o
directivă de terminare forţată (Stop forţat) directivă lansată de către taskul aflat
în execuţie. Această tranziţie presupune menţinerea BDT pentru respectivul task.
 Tranziţia EXECUŢIE – GATA DE EXECUŢIE se realizează printr-
o directivă de Eliberare. Controlul UCP este cedat ca urmare a declarării unui
eveniment ca fiind semnificativ (cum ar fi expirarea cuantei de timp alocate, sau
trecerea în starea GATA DE EXECUŢIE , a unui task cu prioritate superioară.
Capitolul 3 67
 Tranziţia EXECUŢIE – BLOCAT se realizează printr-o directivă

de Aşteptare, în situaţia în care continuarea execuţiei taskului este condiţionată
de: producerea unui eveniment extern, realizarea unei condiţii de timp,
realizarea unei operaţii de intrare-ieşire, etc.
 Tranziţia EXECUŢIE – INACTIV care presupune păstrarea BDT
se realizează la o terminare normală a taskului (Stop normal).
 Tranziţia BLOCAT – GATA DE EXECUŢIE se realizează printr-
o directivă de Continuare , lansată de către executiv dacă situaţia care a
determinat blocarea a dispărut.
 Tranziţia BLOCAT – INACTIV se realizează printr-o directivă de
terminare forţată (Stop forţat) directivă lansată de către taskul aflat în execuţie.
Ca şi în cadrul altor tranziţii în starea INACTIV şi aceasta presupune menţinerea
BDT pentru respectivul task.
Este de menţionat faptul că tranziţiile taskurilor în spaţiul stărilor
trebuie tratate în strânsă corelaţie cu operaţiile multitasking aferente rezolvării
problemei interacţiunii dintre taskuri, operaţii care vor fi tratate pe parcursul
acestui capitol.
3.2. Dispecerizarea taskurilor

După cum s-a arătat într-un sistem multitasking în timp real mai multe
taskuri se pot găsi la un moment dat în competiţie pentru a deţine controlul UCP
în scopul rulării lor.
Procesul de dispecerizare reprezintă ansamblul de acţiuni prin care în
cadrul unei sesiuni de comutare este ales taskul care urmează a fi rulat. La baza
acestui proces – realizat de dispecer – stă un algoritm adoptat din faza de
proiectare a executivului de timp real.
Variantele uzuale de dispecerizare sunt:
- dispecerizarea prin rotaţie;
- dispecerizarea prin prioritizare;
- dispecerizarea prin prioritizare şi rotaţie.
În continuare vor fi prezentate aceste maniere de dispecerizare, cu
referire la prima abordare a stărilor şi tranziţiilor taskurilor.
3.2.1. Dispecerizarea prin rotaţie
Această variantă presupune existenţa unei Liste de Aşteptare la Procesor
– LAP în care se înscriu elementele de identificare (indexurile) ale tuturor
taskurilor rulabile4.
4
Taskurile aflate într-una dintre stările Gata de execuţie şi Execuţie.
Capitolul 3 68
Dispecerul va alege întotdeauna pentru rulare taskul aflat în prima poziţie

din LAP. Taskul aflat în rulare se consideră că ocupă ultima poziţie din LAP , iar
takurile devenite rulabile se inserează înaintea primei poziţii din listă, aspect
relevat de reprezentarea din figura 3.13 a dispecerizării prin rotaţie.
Ieşire taskuri Traseu circularizare taskuri
suprimate
Punct inserare noi taskuri

UCP
Ieşire taskuri
05
07 01 06 02 04 09
blocate
Ultima Prima poziţie, Penultima

poziţie, (cap de listă) LAP poziţie
Ieşire taskuri (coadă de
Intrare taskuri devenite rulabile
listă)
dezactivate 03
Fig. 3.13. Modelul dispecerizării prin rotaţie..
Când un task aflat în rulare este supus unui proces de comutare fără ca
acest lucru să fie provocat de dezactivare sau suprimare în faţa sa stau două
alternative:
- dacă îndeplineşte în continuare condiţiile de rulare, i se asigură
rămânerea normală în LAP şi înscrierea indexului său în penultima poziţie din
listă;
- dacă nu mai îndeplineşte condiţiile de rulare , acesta se blochează şi
este eliminat din LAP şi înscris într-o listă a taskurilor blocate.
Este de menţionat faptul că trecerea în ultima poziţie a taskului aflat în
rulare va determina avansul celorlalte taskuri în LAP.
Dacă taskul aflat în rulare este supus unui proces de comutare datorat
dezactivării sau suprimării, atunci taskul este scos din LAP şi trecut după caz În
starea creat, respectiv necreat.
În modelul din figura 3.13 este surprinsă următoarea situaţie:
- taskul 07 este în rulare şi ocupă ultima poziţie din LAP;
- taskul 01 ocupă prima poziţie din LAP şi este la iminenţa rulării;
- taskurile 06, 02, 04, 09 aşteaptă în această ordine intrarea în rulare
după taskul 01;
- taskul 05, după ce s-a aflat pentru un timp în rulare a fost exclus din
LAP blocându-se;
Capitolul 3 69
- taskul 03 , devenit rulabil urmează să fie inserat în LAP.
Figura 3.14 prezintă situaţia în care taskul 07 se mai află în rulare, iar
taskul 03 a fost înscris în prima poziţie din LAP.

suprimate

UCP
Ieşire taskuri
07 03 01 06 02 04 09
blocate

listă) Intrare taskuri devenite rulabile
dezactivate
Fig. 3.14. Modelul dispecerizării prin rotaţie după inserarea în LAP a taskului 03.
Presupunând că se produce un proces de comutare, iar taskul 07 rămâne

în continuare rulabil, situaţia se va prezenta ca în figura 3.15.
suprimate

UCP
Ieşire taskuri
03 01 06 02 04 09 07
blocate

listă) Intrare taskuri devenite rulabile
dezactivate
Fig. 3.15. Modelul dispecerizării prin rotaţie după un proces de comutare în care taskul 07
a rămas rulabil.
Realizarea dispecerizării prin rotaţie necesită gestionarea unei liste

circulare de întregi scurţi care sunt asociaţi indexurilor taskurilor din listă.
Fiecare nod din listă va conţine pe lângă index şi un pointer la următorul nod,
aspect evidenţiat în figura 3.16.
Capitolul 3 70
Ultima poziţie o
(coadă de listă)
p
Prima poziţie
(cap de listă)
Punct inserare
nod nou
Fig. 3.16. Componenţa listei circulare de aşteptare la procesor.
În reprezentarea din figura 3.16 semnificaţia notaţiilor este următoarea:

- m, n, o, p reprezintă indexurile taskurilor din LAP;
- m – indexul taskului aflat în rulare;
- p – indexul taskului care urmează să intre în rulare.
Gestionarea unei asemenea liste presupune implementarea a patru tipuri
de funcţii şi anume:
- funcţia de inserare în LAP a unui task;
- funcţia de eliminare din LAP a unui task;
- funcţia de determinare a indexului taskului aflat în prima poziţie
din LAP;
- funcţia de iniţializare a LAP.
3.2.2. Dispecerizarea prin prioritizare

Această manieră de dispecerizare presupune alocarea pentru fiecare task
la crearea sa a unei priorităţi. Toate taskurile rulabile sunt incluse într-o LAP
organizată însă pe bază de priorităţi. Fiecare task ocupă un loc conform
priorităţii sale, în fruntea listei aflându-se evident taskul cu cea mai mare
prioritate, iar în coada listei taskul cu prioritatea cea mai mică.
În cadrul unei sesiuni de comunicare dispecerul introduce în rulare
taskul cu cea mai puternică prioritate din LAP. Dacă în intervalul de timp care
provoacă procesul de comutare, nu este introdus în LAP un task cu prioritate
superioară celui aflat în rulare, atunci UCP va fi alocată pentru încă o sesiune de
rulare acestuia.
Introducerea în LAP a unui task poate fi consecinţa unei întreruperi
fizice (care ar putea fi chiar cea care provoacă procesul de comutare) sau a unei
acţiuni de autoblocare a taskului aflat în rulare.
Capitolul 3 71
În figura 3.17 este reprezentat modelul dispecerizării cu prioritizare, cu

şase nivele de prioritate, în care un task identificat printr-un anumit index este
înscris în LAP potrivit priorităţii sale.
Fig. 2.43. Intrare taskuri devenite rulabile
Soluţia lui
UCP Intrare task
prioritate 0
03
Sens
Intrare task
prioritate 1 scădere
Ieşire taskuri 07 prioritate
blocate
03 Intrare task
prioritate 2
Task
în Intrare task
rulare prioritate 3
04
Intrare task
Ieşire taskuri prioritate 4
02
dezactivate Intrare task
LAP
prioritate 5
Fig. 3.17. Modelul dispecerizării prin prioritizare.
În situaţia evidenţiată în modelul din figura 3.17 sunt de subliniat

următoarele:
- taskul 03 de prioritate 1 este în rulare;
- poziţiile corespunzătoare priorităţilor 0 şi 3 nu sunt ocupate;
- taskul cu cea mai ridicată prioritate aflat în LAP este 03, aflat în
acelaşi timp şi în rulare;
- un proces de comutare va asigura încă un interval de rulare pentru
taskul 03;
- dacă dintr-un motiv oarecare taskul 03 este scos din LAP, taskul 07 de
prioritate 2 va fi trecut în rulare;
- dacă la un moment dat taskul 05 ar fi inserat în LAP pe nivelul de
prioritate 0, atunci la proximul proces de comutare taskul 03 va trece
în execuţie logică iar taskul 05 va fi adus în rulare.
Ca şi în cazul precedent şi realizarea dispecerizării prin prioritizare
necesită gestionarea unei liste circulare de întregi scurţi. Un nod al unei
asemenea liste va conţine pe lângă indexul taskului şi pointerul la următorul nod
şi prioritatea, potrivit reprezentării din figura 3.18.
În reprezentarea din figura 3.18 semnificaţia notaţiilor este următoarea:
- m, n, o, p reprezintă indexurile taskurilor din LAP;
- a, b, c, d – priorităţile taskurilor cu indexurile m, n, o, p.
Capitolul 3 72
m
a
m
Prima poziţie
(cap de listă) a
m
a
m
a b c d a
Sensul de scădere a priorităţii
Ultima poziţie
(coadă de listă)
Fig. 3.18. Lista de aşteptare la procesor în cazul dispecerizării prin prioritizare.

Gestionarea unei asemenea liste presupune şi în acest caz implementarea
celor patru tipuri de funcţii specifice gestionării listelor şi anume:
- funcţia de inserare în LAP a unui task ţinînd de această dată cont
atât de index cât şi de prioritate;
- funcţia de eliminare din LAP a unui task;
- funcţia de determinare a indexului taskului aflat în prima poziţie
din LAP;
- funcţia de iniţializare a LAP.
3.2.3. Dispecerizarea prin prioritizare şi rotaţie

Acest tip de dispecerizare (pentru care se va utiliza abrevierea DPR)
reprezintă o combinaţie între cele două tipuri de dispecerizare analizate anterior.
DPR se caracterizează prin faptul că admite posibilitatea ca mai multe taskuri să
deţină aceiaşi prioritate.
În consecinţă LAP este constituită practic dintr-o înlănţuire de liste
circulare, fiecare astfel de listă conţinând taskuri de aceiaşi prioritate. În figura
3.19 se prezintă, pentru o situaţie concretă, un model de DPR.
În situaţia ilustrată în figura 3.19 sunt de menţionat următoarele aspecte:
- LAP cuprinde cinci liste circulare corespunzătoare celor cinci
priorităţi acceptate pentru taskurile rulabile, dintre care lista de
prioritate 1 este vidă;
- taskul cu indexul 07 aparţinând listei circulare de prioritate 0 este în
execuţie fizică, şi ocupă prin urmare ultima poziţie în această listă;
Capitolul 3 73
- în ipoteza conservării conţinutului LAP, prin sesiuni succesive de

comutare vor intra în execuţie fizică taskurile 01, 06, 02, 04, 09, apoi
din nou 07 ş.a.m.d. ;
- rularea taskurilor din lista de prioritate 2, (în ordinea 08, 03, 08, etc.),
va începe numai după vidarea listei de prioritate 0;
- în general taskurile de pe o listă circulară asociată unei anumite
priorităţi vor intra în rulare numai daca toate listele cu priorităţi
superioare sunt vide (de exemplu taskurile din lista de prioritate 3 vor
fi rulate numai dacă listele 0, 1, 2 sunt vide).
Traseu circularizare taskuri .
Listă circulară - prioritate 0

UCP
01 06 02 04 09
Intrare taskuri de prioritate 0

Ieşire taskuri
suprimate
Ieşire taskuri
blocate
07 08 03
Task
în Intrare taskuri de prioritate 2
rulare
Ieşire taskuri
14 10 05
dezactivate

12
Intrare taskuri devenite rulabile.
Fig. 3.19. Modelul dispecerizării prin prioritizare şi rotaţie.
Capitolul 3 74
DPR se poate reduce la cele două tipuri de dispecerizare prezentate

anterior în următoarele condiţii:
- dacă toate taskurile rulabile au aceiaşi prioritate DPR se reduce la
dispecerizarea prin rotaţie;
- dacă fiecare listă conţine câte un singur task rulabil DPR se reduce
la dispecerizarea prin prioritizare.
Realizarea DPR necesită gestionarea unei înlănţuiri de liste circulare,
care se succed în sensul scăderii priorităţilor asociate. O asemenea înlănţuire
presupune existenţa a două tablouri corelate: un tablou al taskurilor şi un tablou
al priorităţilor.
Tabloul taskurilor implementează listele circulare conform regulilor
specifice dispecerizării prin rotaţie. Un element al tabloului, împreună cu
indicele său reprezintă un nod al unei liste. Indicele va avea semnificaţia unui
index al taskului aferent nodului , elementul va avea ca valoare indexul asociat
succesorului acestui task.
Gestionarea LAP, pentru DPR comportă aceleaşi funcţii de la
precedentele tipuri de dispecerizări cu excepţia funcţiei de eliminare, unde
trebuie precizată şi prioritatea taskului eliminat.
3.3. Conflicte potenţiale în sistemele multitasking

După cum s-a arătat concurenţa pentru deţinerea resurselor poate genera
situaţii conflictuale. Pentru evitarea acestora şi pentru ca taskurile să-şi realizeze
obiectivele au fost formalizate aşa numitele operaţii multitasking între care o
importanţă aparte prezintă: excluderea mutuală, sincronizarea şi comunicarea 5
Pentru implementarea acestor operaţii sistemele de operare sau
executivele de timp real pun la dispoziţie instrumente cum ar fi: semafoare, cutii
poştale, mesaje de trecere, variabile de tip eveniment, fanioane de excluziune,
monitoare, etc.
3.3.1. Resurse şi secţiuni critice
În general termenul de resursă desemnează orice element necesar unui
task pentru a putea fi rulat. Resursele pot fi de două categorii şi anume materiale
şi logice.
În rândul resurselor materiale pot fi considerate:
- procesorul;
- memoria internă;
- memoriile externe;
- dispozitivele de intrare / ieşire;
5
În mod obişnuit acestea sunt cunoscute ca Operaţii Fundamentale Multitasking.
Capitolul 3 75
- ceasul de timp real;

- dispozitivele speciale.
În resursele logice pot fi incluse:
- subrutinele (procedurile);
- masivele de date;
- fişierele;
- variabilele.
O altă clasificare împarte resursele în: resurse locale şi resurse comune.
 Resursele locale sunt resursele care pot fi accesate de către un singur
task. Acestea pot fi în primul rând de natură logică (subrutine, fişiere, variabile),
dar pot fi şi de natură fizică, cum ar fi anumite dispozitive de intrare / ieşire.
 Resursele comune sunt acele resurse care pot fi accesate de mai
multe taskuri. Acestea pot fi atât de natură logică (subrutine, tampoane de date,
variabile, etc. ) cât şi fizică (procesor, memorie, dispozitive de intrare/ieşire
etc.).
La rândul lor resursele comune pot fi critice, partajabile, reentrante.
 O resursă comună asupra căreia la un moment dat se poate
desfăşura o singură sesiune de lucru respectiv care poate fi accesată la un
moment dat de către un singur task se numeşte resursă critică. În această
categorie pot fi incluse procesorul, locaţiile de memorie, echipamente de
intrare, subrutinele care îşi modifică pe parcurs unele date proprii, etc.
 O resursă comună care admite ca n sesiuni de lucru să fie în
derulare asupraei la un moment dat (respectiv să poată fi accesată de către n
taskuri) se numeşte resursă partajabilă cu n puncte de intrare.
 O resursă comună care admite să fie oricâte sesiuni de lucru să fie
în derulare la un moment dat se numeşte resursă reentrantă6.
În continuare vor fi tratate unele aspecte referitoare la utilizarea
neconflictuală a resurselor critice. Secţiunea dintr-un task în care este accesată o
resursă critică se numeşte secţiune critică. În sistemele multitasking trebuie să
existe reglementări pentru accesarea secţiunilor critice. În acest sens se impune
existenţa unor modalităţi de implementare a excluderii mutuale.
Excluderea de către un task aflat într-o secţiune critică referitoare la o
resursă a accesului altor taskuri de a accesa propriile secţiuni critice referitoare
la aceiaşi resursă se constituie în excludere mutuală.
Referitor la implementarea excluderii mutuale sunt de menţionat
recomandările făcute de prof. Andrew Tanenbaum de la Universitatea Vrijie
Amsterdam, Olanda în anul 1987.
6
Resursele reentrante pot fi considerate resurse partajabile cu n tinzând către infinit.
Capitolul 3 76
Sintetic aceste recomandări au în vedere următoarele aspecte:

1 – orice secţiune critică poate fi executată la un moment dat de către un
singur task (aceasta este practic esenţa excluderii mutuale care afirmă că un
singur task se poate afla la un moment dat în propria secţiune critică referitoare
la o resursă);
2 – nu se poate face nici o ipoteză în ceea ce priveşte viteza relativă şi
frecvenţa de execuţie a taskurilor (cu alte cuvinte la implementarea excluderii
mutuale nu pot fi avute în vedere considerente legate de frecvenţa sau viteza de
execuţie a taskurilor);
3 – orice task are dreptul să acceseze propria secţiune critică referitoare
ala o anumită resursă după un interval finit de timp;
4 – orice task trebuie să evacueze o secţiune critică proprie după un
interval finit de timp;
5 – taskurile nu se pot bloca în interiorul propriilor secţiuni critice.
În continuare vor fi prezentate câteva modalităţi de implementare a
excluderii mutuale.
3.3.2. Excluderea mutuală realizată cu semafoare

Un semafor reprezintă, conform introdus în anul 1965 de către
matematicianul olandez Edsger Wybe Dijkstra, un dublet format dintr-o
variabilă de tip întreg I şi o coadă de aşteptare C, respectiv
S  ( I ,C ). (3.1)
La iniţializare variabilei I i se atribuie o valoare I 0  0 , iar coada C este vidă.
Dacă variabila I ia numai valorile 0 şi 1 semaforul se numeşte binar iar dacă ia
şi alte valori întregi, semaforul se numeşte general.
Asupra semafoarelor pot fi efectuate două operaţii denumite P (de la
cuvântul olandez Passeren – a trece) şi V (de la cuvântul olandez Vrigeven – a
elibera). Aceste funcţii sunt indivizibile7 şi se numesc primitive. În ceea ce
priveşte coada de aşteptare , aceasta poate gestionată conform principiului
FIFO8, sau după priorităţi (univoce sau neunuivoce).
Primitiva P(S) presupune realizarea următoarelor operaţii (ilustrate în
organigrama din figura 3.20):
1 - I←I-1;
2 – dacă I  0 , funcţia se încheie şi taskul în care aceasta se execută îşi
continuă execuţia;
7
Indivizibilitatea are în vedere faptul că cele două funcţii nu pot fi întrerupte.
8
First Input First Output
Capitolul 3 77
3 – dacă I < 0, taskul în care se execută primitiva, iese din rândul

taskurilor rulabile, se blochează iar indexul său este înscris în coada de aşteptare
C. În aceste împrejurări se provoacă un proces de comutare care determină
trecerea în rulare (execuţie fizică) a altui task.
I←I-1
NU DA
I<0
Continuă execuţia Se scoate taskul apelant din rândul

taskului apelant taskurilor rulabile, se blochează şi se
înregistrează în coada C
Se apelează dispecerul
Se aduce în execuţie alt task
Fig. 3.20. Execuţia primitivei P(S).
Primitiva V(S) presupune realizarea următoarelor operaţii (ilustrate în

organigrama din figura 3.21):
1 - I←I+1;
2 – dacă I  0 , se deblochează taskul aflat pe prima poziţie în coada de
aşteptare la semafor şi se înscrie în rândul taskurilor rulabile, după care se face
apel la dispecer, după care continuă execuţia taskului apelant ;
3 – dacă I > 0, taskul în care se execută primitiva, îşi continuă execuţia.
În timpul execuţiei primitivei V(S), dacă în urma incrementării rezultă
I≤0, după deblocarea taskului aflat pe prima poziţie în coada C se dă controlul
dispecerului. Acesta decide funcţie de prioritate dacă aduce sau nu în execuţie
taskul deblocat9.
Din definirea primitivelor P(S) şi V(S) rezultă următoarele precizări
referitoare la valorile variabilei I aferente semaforului (S):
- dacă I > 0 , atunci aceasta reprezintă numărul de taskuri care pot
executa primitiva P(S) fără a se bloca, presupunând că între timp nu se execută
nici o primitivă V(S);
9
În figura 3.21 este surprinsă situaţia în care continuă execuţia taskului apelant, deci taskul deblocat
este adus în execuţie logică.
Capitolul 3 78
- dacă I ≤ 0 , atunci |I| reprezintă numărul de taskuri blocate la

semaforul S şi înregistrate în coada C.
I←I+1
NU DA
I ≤0
Se deblochează taskul aflat pe prima

poziţie în coada C, se elimină din ea
şi se înscrie între taskurile rulabile
Continuă execuţia Se apelează dispecerul

taskului apelant
Fig. 3.21. Execuţia primitivei P(S).
Excluderea mutuală cu semafoare presupune utilizarea unui singur

semafor binar, pe care îl vom nota SEMEX, care se iniţializează cu valoarea 1.
În fiecare task care trebuie să se excludă mutual, înainte de intrarea în secţiunea
critică se execută o directivă P(SEMEX), iar după ieşirea din secţiune o directivă
V(SEMEX).
Este clar că în intervalul de timp în care un task se află în propria
secţiune critică referitoare la o anumită resursă SEMEX=0. În aceste condiţii
orice alt task ce va dori să acceadă în propria secţiune critică referitoare la
aceiaşi resursă, va executa directiva P(SEMEX), ceea ce va determina blocarea
sa întrucât după decrementare SEMEX =-1.
La ieşirea din secţiunea critică execuţia directivei V(SEMEX) va
determina SEMEX=0 şi conform celor precizate anterior , taskul aflat în prima
poziţie în coada C aferentă semaforului S , va fi deblocat10 şi va putea pătrunde
la rândul său în propria secţiune critică.
Ca exemplu în figura 3.22 se prezintă schemele logice aferente excluderii
mutuale cu semafoare a două taskuri T1, T2.. Se observă că cele două taskuri se
execută la intervale prestabilite Δt_ex_T1, Δt_ex_T1.
10
Pentru ca soluţia să fie funcţională, semaforul SEMEX nu trebuie aservit altor scopuri în afara
excluderii mutuale.
Capitolul 3 79
Task T1 Task T2
Iniţializare T1 Iniţializare T2
…SEMEX=1… …SEMEX=1…
NU NU
Δt_ex_T2 ?
Δt
DA DA
P1_T1 P1_T2
P(SEMEX) P(SEMEX)
SCr T1 SCr T2
V(SEMEX) V(SEMEX)
P2_T1 P2_T2
Fig. 3.22. Excluderea mutuală cu semafoare:

P1_T1, …,P2_T2 proceduri ale taskurilor T1 şi T2.
Având în vedere că SEMEX este iniţializat cu valoarea 1, dacă de

exemplu pentru T1se impune accesul în secţiunea sa critică, acest lucru va fi
posibil întrucât directiva P(SEMEX) nu va bloca Taskul T1. Dacă în timp ce T1
se află în secţiunea sa critică T2 va ajunge la iminenţa intrării în secţiunea sa
critică, acest deziderat nu se va putea realiza întrucât directiva P(SEMEX) va
determina blocarea Taskului T2 la semaforul SEMEX. Deblocarea se va produce
când T1 va termina de executat secţiunea sa critică după care va executa
directiva V(SEMEX). Ca urmare a acestei directive SEMEX va căpăta valoarea 0
(zero) şi T2 va deveni rulabil urmând a fi planificat de dispecer pentru execuţia
secţiunii sale critice.
Din cele prezentate rezultă că se realizează excluderea mutuală, respectiv
un singur task se poate găsi la un moment dat în propria sa secţiune critică.
3.3.3. Excluderea mutuală realizată cu variabile de tip
eveniment
O variabilă de tip eveniment este o variabilă logică de tip speciala asupra
căreia pot acţiona trei tipuri de primitive şi anume ÎNSCRIE, ŞTERGE şi
AŞTEAPTĂ.
Capitolul 3 80
Considerând E o variabilă de tip eveniment şi

E  ADEVARAT , FALS ,
semnificaţiile celor trei primitive sunt următoarele:
INSCRIE( E )  E  ADEVARAT ;
STERGE( E )  E  FALS ;
ASTEAPTA( E )  Blocheaza taskul daca E  FALS,
Continua executia daca E  ADEVARAT .
Este de menţionat faptul că primitiva ASTEAPTA se poate aplica şi unei
funcţii de o variabilă eveniment F(E) respectiv
F( E )  ADEVARAT , FALS,
ASTEAPTA( E )  Blocheaza taskul daca F(E)  FALS,
Continua executia daca F(E)  ADEVARAT .
Excluderea mutuală cu variabile eveniment se bazează pe utilizarea unei
singure astfel de variabile, notate generic EVEX şi care se iniţialializează cu
valoarea ADEVĂRAT. În fiecare task care trebuie să se excludă mutual, înainte
de intrarea în secţiunea critică se va executa o secvenţă de directive ASTEAPTĂ
(EVEX), ŞTERGE(EVEX), iar după ieşirea din secţiune o directivă
ÎNSCRIE(EVEX).
Rezultă că în intervalul de timp în care un task se află în secţiunea sa
critică referitoare la o anumită resursă EVEX=FALS. În aceste condiţii orice alt
task ce va dori să acceadă în propria secţiune critică referitoare la aceiaşi
resursă, se va bloca la execuţia directivei AŞTEAPTĂ(EVEX).
La ieşirea din secţiunea critică execuţia directivei ÎNSCRIE(EVEX) va
conduce la EVEX = ADEVĂRAT şi conform celor precizate referitor la directiva
AŞTEAPTĂ primul task blocat la variabila EVEX , va fi deblocat11 şi va putea
pătrunde la rândul său în propria secţiune critică.
Ca exemplu în figura 3.23 se prezintă schemele logice aferente excluderii
mutuale cu semafoare a două taskuri T1, T2. Se observă că cele două taskuri se
execută la intervale prestabilite Δt_ex_T1, Δt_ex_T1.
Având în vedere că variabila EVEX este iniţializată cu valoarea
ADEVĂRAT, dacă de exemplu pentru T1se impune accesul în secţiunea sa
critică, acest lucru va fi posibil întrucât directiva AŞTEAPTĂ (EVEX) nu va
bloca Taskul T1. Dacă în timp ce T1 se află în secţiunea sa critică T2 va ajunge
la iminenţa intrării în secţiunea sa critică, acest deziderat nu se va putea realiza
întrucât directiva AŞTEAPTĂ(EVEX) va determina blocarea Taskului T2 la
11
Ca şi în cazul semafoarelor, variabila de tip eveniment EVEX va trebui utilizată numai la
implementarea excluderii mutuale.
Capitolul 3 81
variabila eveniment EVEX. Deblocarea se va produce când T1 va termina de

executat secţiunea sa critică după care va executa directiva ÎNSCRIE(EVEX). Ca
urmare a acestei directive EVEX va căpăta valoarea ADEVĂRAT şi T2 va
deveni rulabil urmând a fi planificat de dispecer pentru execuţia secţiunii sale
critice.
Task T1 Task T2
…EVEX=ADEV… …EVEX=ADEV…
NU NU
Δt_ex_T1 ? Δt_ex_T2 ?
DA DA
P1_T1 P1_T2
NU ? NU ?
EVEX=ADEV EVEX=ADEV
ASTEAPTA (EVEX) DA ASTEAPTA (EVEX) DA
ŞTERGE(EVEX) ŞTERGE(EVEX)
SCr T1 SCr T2
ÎNSCRIE(EVEX) ÎNSCRIE(EVEX)
P2_T1 P2_T2
Fig. 3.23. Excluderea mutuală cu variabile de tip eveniment: P1_T1, …,P2_T2

proceduri ale taskurilor T1 şi T2.
Din cele prezentate rezultă că prin utilizarea variabilelor de tip

eveniment se realizează excluderea mutuală, respectiv un singur task se poate
găsi la un moment dat în propria sa secţiune critică.
3.3.4. Excluderea mutuală realizată cu mesaje şi cutii poştale
O cutie poştală (CP) reprezintă o structură al cărui element central este
un tampon circular gestionat conform principiului FIFO. Într-o CP taskurile pot
depune mesaje, accesibile oricărui task. În mod normal o CP se specifică prin
Capitolul 3 82
numărul de poziţii ale tamponului circular şi prin lungimea admisă pentru un

mesaj.
Mesajele reprezintă volume de date transferate între taskuri pe parcursul
evoluţiei lor. Mesajele pot fi transmise direct între taskuri (caz în care se numesc
mesaje de trecere) su prin intermediul cutiilor poştale. Din punct de vedere al
conţinutului mesajele pot fi cu conţinut fix sau variabil. Cele cu conţinut fix se
numesc mesaje simbolice iar celelalte mesaje informaţionale. În ceea ce priveşte
formatul şi acesta poate fi fix sau variabil. În mod normal mesajele simbolice
sunt mesaje cu format fix.
O funcţie de depunere (PUT) a unui mesaj într-o anume CP trebuie să
conţină un pointer la variabila al cărui conţinut se depune, în timp ce o funcţie
de extragere (GET) a unui mesaj dintr-o anume CP va trebui să conţină un
pointer la variabila în care se depune mesajul extras.
Cutiile poştale trebuie astfel gestionate încât să se producă blocarea
taskurilor pe operaţii de depunere , atunci când CP este plină sau pe operaţii de
extragere atunci când CP este vidă.
Excluderea mutuală cu cutii poştale presupune utilizarea unei singure
CP pe care o vom nota CPEX în care primul task ce se iniţializează depune un
mesaj simbolic, notat MESEX. Înainte de intrarea în secţiunea critică fiecare
task care trebuie să se excludă mutual va extrage MESEX din CPEX, iar după
ieşirea din secţiunea critică îl va redepune.
Rezultă că în intervalul de timp în care un task se află în secţiunea sa
critică referitoare la o anumită resursă cutia poştală CPEX este vidă. În aceste
condiţii orice alt task ce va dori să acceadă în propria secţiune critică referitoare
la aceiaşi resursă, se va bloca la execuţia funcţiei de preluare a mesajului
simbolic. Deblocarea12 se va produce în momentul în care CPEX va conţine din
nou mesajul simbolic MESEX
În figura 3.24 se prezintă schemele logice aferente excluderii mutuale cu
semafoare a două taskuri, T1şi T2. Ca şi în cazurile precedente cele două taskuri
sunt sincronizate cu timpul, intervalele de execuţie fiind Δt_ex_T1, Δt_ex_T1.
Având în vedere că la iniţializare cutia poştală CPEX va conţine mesajul
simbolic MESEX, dacă de exemplu pentru T1se impune accesul în secţiunea sa
critică, acest lucru va fi posibil întrucât prin funcţia de extragere GET va putea fi
preluat mesajul MESEX. Dacă în timp ce T1 se află în secţiunea sa critică T2 va
ajunge la iminenţa intrării în secţiunea sa critică, acest deziderat nu se va putea
realiza întrucât funcţia GET va determina Taskului T2 la cutia poştală CPEX.
Deblocarea se va produce când T1 va termina de executat secţiunea sa critică
după care va executa funcţia PUT de depunere a MESEX în CPEX.
12
Utilizarea căsuţei poştală CPEX şi a mesajului MESEX trebuie să fie numai în excludere mutuală.
utilizată numai la implementarea excluderii mutuale.
Capitolul 3 83
În urma acestei depuneri T2 va deveni rulabil urmând a fi planificat de

dispecer pentru execuţia secţiunii sale critice.
Task T1 Task T2
PUT MESEX PUT MESEX

NU NU
SAU
DA DA
P1_T1 P1_T2
NU ? ? NU
MESEX în CPEX MESEX în CPEX
DA DA
PREIA MESEX din CPEX PREIA MESEX din CPEX
GET GET
SCr T1 CPEX SCr T2
PUT PUT
DEPUNE MESEX în CPEX DEPUNE MESEX în CPEX
P2_T1 P2_T2
Fig. 3.24. Excluderea mutuală cu cutii poştale şi mesaje:

P1_T1, …,P2 _T2 proceduri ale taskurilor T1 şi T2.
Din cele prezentate rezultă că şi prin utilizarea cutiilor poştale şi a mesajelor se
poate realiza excluderea mutuală, respectiv se poate asigura prezenţa unui singur
task la un moment dat în propria sa secţiune critică.
3.3.5. Alte modalităţi de realizare a excluderii mutuale
În afara modalităţilor prezentate de realizarea a excluderii mutuale (EM)
prezentate, o importanţă practică şi altele, între care în cele ce urmează vor fi
abordate următoarele :
- EM prin dezactivarea întreruperilor;
- EM prin fanioane de excluziune;
- EM prin blocuri resursă;
Capitolul 3 84
- EM prin monitoare.
A. Realizarea EM prin dezactivarea întreruperilor. Această metodă

presupune inhibarea sistemului de întreruperi înainte de intrarea în
secţiunea critică şi reactivarea acestuia după ieşirea din secţiunea critică.
Prin dezactivarea sistemului de întreruperi este împiedicată preluarea
UCP de la taskul care îşi execută propria secţiune critică.
B. Realizarea EM cu ajutorul fanioanelor de excluziune. Un fanion de
excluziune (FE) reprezintă o variabilă logică iniţializată cu valoarea 0 (zero)
asupra căreia se pot efectua două operaţii şi anume:
- testarea şi forţarea la 1 , numită operaţie TAS - Test And Set;
- forţarea la 0, numită operaţie RES – RESet.
După cum tratarea unui fanion implică sau nu apelarea dispecerului
fanioanele de excluziune pot fi active (FE-A) sau pasive (FE-P).
Implementarea EM, referitoare la o anumită resursă, cu ajutorul FE-P
presupune respectarea următoarelor reguli:
a – FE-P este asociat numai EM pentru resursa în cauză;
b – dacă FE-P = 0 atunci că nici o secţiune critică referitoare la
respectiva resursă nu este în rulare;
c – dacă FE-P = 1, rezultă că un task execută propria secţiune critică
referitoare la resursa în cauză;
d – înainte de pătrunderea în secţiunea critică se realizează în condiţii de
indivizibilitate operaţia TAS(FE-P);
d1 – dacă operaţia TAS a găsit FE-P=1se reia începând cu punctul d;
d2 – dacă operaţia TAS a găsit FE-P=0 se face FE-P=1 după care
se intră în secţiunea critică;
e – la părăsirea secţiunii critice se va efectua RAS(FE-P) care va
determina FE-P=0.
Un fanion de excluziune activ reprezintă un ansamblu (dublet) format
dintr-un fanion de excluziune pasiv F şi o coadă de aşteptare C. FE-P are rolul
de a indica printr-o operaţie TAS existenţa sau nu a posibilităţii accesului unui
task în secţiunea sa critică referitoare la o resursă pusă în corespondenţă cu
respectivul fanion. Coada de aşteptare C înregistrează taskurile care nu au putut
accesa propriile resurse critice referitoare la o resursă pusă în corespondenţă cu
fanionul de excluziune pasiv F.
Utilizarea FE-A în cadrul implementării EM, referitoare la o anumită
resursă, presupune respectarea următoarelor reguli:
Capitolul 3 85
a – FE-A este asociat numai EM pentru resursa în cauză;

b – în situaţia în care F = 0 rezultă că nici un task nu se află în secţiunea
sa critică;
c – dacă F = 1, atunci se află în derulare o secţiune critică;
d – înainte de pătrunderea în secţiunea critică se realizează în condiţii de
indivizibilitate operaţia TAS(F);
d1 – dacă operaţia TAS a găsit F=1se realizează următoarele:
d11 – autoînscrierea taskului în coada C a FE-A;
d12 – autoeliminarea sa din rândul taskurilor rulabile;
d13 – autoblocarea şi autoînscrierea în lista taskurilor blocate;
d14 – apelarea dispecerului;
d15 – reluarea după deblocare începând cu punctul d;
d2 – dacă operaţia TAS a găsit F=0 se face FE=1 după care se intră
în secţiunea critică;
e – la părăsirea secţiunii critice se va efectua următoarea secvenţă
indivizibilă:
e1 – efectuarea operaţiei RES(F);
e2 – deblocarea tuturor taskurilor înscrise în coada C şi reînscrierea
lor în rândul taskurilor rulabile.
C. Realizarea EM cu ajutorul blocurilor resursă. Un bloc resursă este
reprezentat de un triplet BR cu structura
BR  ( I ,C , In),
unde: I şi C păstrează semnificaţiile stabilite la descrierea semafoarelor;
In – variabilă în care se păstrează indexul taskului în care s-a efectuat
ultima operaţie de tip P.
În contextul EM taskul al cărui index este înregistrat în In este
proprietarul resursei critice în cauză. Un semafor care asigură înregistrarea
proprietarului curent al resursei critice căruia îi corespunde se numeşte bloc
resursă. Perechea de primitive P, V asociată unui bloc resursă se numeşte
gestionar de resursă.
Este important de subliniat faptul că la execuţia primitivei V pentru un
BR are loc o comparaţie a indexului taskului înscris în In cu cel al taskului în
care se execută primitiva. La necoincidenţă se semnalează o eroare, întrucât unei
primitive P executată într-un task trebuie să îi corespundă o primitivă V
executată în acelaşi task.
Capitolul 3 86
D. Realizarea EM cu ajutorul monitoarelor.

Conceptul de monitor a fost introdus Richard Hoare în 1974 ca
ansamblu de proceduri şi variabile la care accesul este indivizibil. Referitor la
EM toate secţiunile critice ale taskurilor care trebuie să se excludă se introduc în
monitor, devenind funcţii sau proceduri ale acestuia.
De fiecare dată când un task intenţionează să îşi execute propria secţiune
critică va face apel la procedura corespunzătoare a monitorului. Întrucât un
singur task poate beneficia la un moment dat de serviciile monitorului, toate
celelalte taskuri care solicită servicii se vor bloca aşteptând eliberarea acestia.
În acest fel programatorul nu trebuie să fie preocupat de realizarea EM ci
de asigurarea prezenţei la un moment dat în monitor a unui singur task
3.4. Sincronizarea taskurilor

De regulă, în evoluţia lor, taskurile unei aplicaţii trebuie să se supună
unor relaţii de ordine care să le asigure o anumită succesiune temporală.
De exemplu într-o aplicaţie de conducere în timp real un task efectuează
achiziţia datelor din proces şi le depune într-un buffer de unde vor fi preluate de
taskurile utilizator (reglare, supraveghere, monitorizare etc. ). În această situaţie
taskurile beneficiare trebuie să aştepte încărcarea buffer-ului, după care în cadrul
unei secţiuni critice vor prelua datele.
Sincronizarea taskurilor reprezintă procesul de punerea a unui task în
relaţie cu alt task, cu timpul sau cu un eveniment extern. Două taskuri se
consideră sincronizate dacă se pot stabili relaţii predictibile între anumite
momente ale desfăşurării lor. Sensul general al sincronizării este acela de
coordonare în timp, decorelare.
În mod obişnuit sincronizarea se poate face:
- funcţie de producerea unui eveniment extern taskului;
- funcţie de realizarea unei condiţii de timp.
Sincronizarea cu timpul poate fi tratată ca o sincronizare cu evenimente
externe dacă se consideră impulsurile ceasului de timp real ca fiind astfel de
evenimente. Pentru realizarea sincronizării sunt necesare funcţii specifice de
tratare şi anume:
- wait – aşteptare până la producerea evenimentului;
- signal – anunţare că evenimentul s-a produs.
Metodele şi mecanismele utilizate pentru realizarea sincronizării se
deosebesc sub mai multe aspecte şi anume:
- natura sincronizării (cu evenimente externe sau cu timpul);
Capitolul 3 87
- momentul sincronizării (cu începutul, zona mediană sau sfârşitul unui

task):
- implementarea sincronizării (prin facilităţi ale limbajelor de
programare, ale limbajelor de comandă sau ale monitoarelor).
Din punctul de vedere al sincronizării cu timpul pot exista două situaţii,
ilustrate în figura 3.25, şi anume:
- taskul aşteaptă expirarea unui interval de timp Δt după care se
execută (figura 3.25 a);
- taskul se execută în interiorul cuantei de timp Δt.
Δt Δt Δt Δt Δt
t t
τ τ τ τ τ
a b
Fig. 3.25. Sincronizarea cu timpul:
a – intervalul de execuţie τ în afara intervalului de sincronizare Δt;
b – intervalul de execuţie τ în interiorul intervalului de sincronizare Δt.
În continuare vor fi prezentate câteva modalităţi de implementare a

sincronizării.
3.4.1. Sincronizarea realizată cu semafoare
Se va exemplifica pentru un sistem de două taskuri T1 şi T2 care trebuie
să se sincronizeze reciproc, în fiecare task fiind definit câte un punct de
sincronizare PS1 pentru T1, respectiv PS2 pentru T2. Sincronizarea trebuie astfel
realizată încât taskul Ti să nu poată trece de punctul său de sincronizare PSi până
când celălalt task Tj nu a ajuns în punctul său de sincronizare PSj ( i , j  { 0 ,1} ).
Din analiza figurii 2.26, în care se prezintă sincronizarea cu semafoare,
rezultă că punctele de sincronizare se află între procedurile P1 şi P2 ale fiecărui
task. Cu alte cuvinte un task nu poate executa propria procedură P2 până când
celălalt task nu şi-a executat procedura P1.
Sincronizarea se realizează cu ajutorul a doua semafoare binare notate în
figura 3.26 cu SEMSYNC1 şi SEMSYNC2 care în taskurile T1 şi T2 se
iniţializează cu valorile 1 respectiv 0. În punctul de sincronizare PSi al taskului
Ti se execută secvenţa P(SEMSYNCi), V(SEMSYNCj) cu i , j  { 0 ,1} .
Dacă de exemplu T2 ajunge în PS2 înainte ca T1 să îşi execute
procedura P1, se va bloca întrucât SEMSYNC2=0. Taskul se va debloca după ce
T1 depăşeşte PS1 deoarece va executa directiva V(SEMSYNC2).
Capitolul 3 88
Task T1 Task T2
…SEMSYNC1=1 …SEMSYNC2=0
NU NU
DA DA
P1_T1 P1_T2
P(SEMSYNC1) P(SEMSYNC2)
PS1 PS2
V(SEMSYNC2) V(SEMSYNC1)
P2_T1 P2_T2
Fig. 3.26. Utilizarea semafoarelor pentru sincronizarea a două taskuri:

P1_T1, …,P2_T2 proceduri ale taskurilor T1 şi T2.
În figura 3.27 este ilustrată utilizarea sincronizării cu un eveniment

extern. Taskul T1 trebuie să îşi execute procedura P2 numai după producerea
evenimentului extern EVEXT. În acest scop se utilizează semaforul de
sincronizare SYMSYNC care se iniţializează cu valoarea 0. Asupra acestui
semafor se execută o directivă de tip V în taskul T0 care supraveghează
producerea evenimentului.
Task T0 Task T1
…SEMSYNC=0… …SEMSYNC=0…
NU
P1_T1
EVEXT?
DA
P(SEMSYNC)
V(SEMSYNC)
P2_T1
Fig. 3.27. Utilizarea semafoarelor în pentru sincronizarea cu un eveniment

extern: P1_T1, …,P2_T1 proceduri ale taskului T1.
Capitolul 3 89
Semafoarele pot fi utilizate şi în sincronizarea cu timpul, în figura 3.28

fiind prezentat un exemplu în acest sens. Taskul T1 trebuie să se execute la
intervale de timp Δt_ex_T1 . În acest scop se construieşte taskul T0 cu rol de
planificator. Acesta execută o aşteptare temporizată la semaforul de
sincronizare SYMSYNC iniţializat cu valoarea 0. Aşteptarea temporizată
presupune execuţia directivei V(SEMSYNC) la expirarea intervalului Δt_ex_T1.
Această directivă va debloca taskul T1, care între momentele de execuţie
aşteaptă pe o funcţie P la acelaşi semafor, rezultatul fiind acela că taskul T1 se va
executa cu periodicitatea Δt_ex_T113 .
Task T0 Task T1
…SEMSYNC=0… …SEMSYNC=0…
NU
Δt_ex_T1 ? P(SEMSYNC)
DA
P_T1
V(SEMSYNC)
Fig. 3.28. Utilizarea semafoarelor în pentru sincronizarea cu timpul:

P_T1 procedură a taskului T1.
3.4.2. Sincronizarea realizată cu variabile de tip eveniment

Variabilele de tip eveniment (VTE) sunt adecvate sincronizării cu
evenimente externe. În acest caz punctele de sincronizare sunt asociate unor
evenimente externe, la a căror producere se înscriu VTE.
Sincronizarea cu VTE va fi exemplificată pentru un sistem de trei taskuri
T1, T2, T3 cu următoarea funcţionalitate:
- T1 se sincronizează cu evenimentul extern EVEX1;
- T2 se sincronizează cu evenimentul extern EVEX2;
- T3 se sincronizează cu ansamblul celor două evenimente.
După cum se observă din figura 3.29 în care este ilustrată sincronizarea
celor trei taskuri celor două evenimente li se asociază variabilele de tip
eveniment VTE1 şi VTE2 iniţializate cu valoarea FALS. În ceea ce priveşte
13
Timpul de execuţie al taskului T1 este inclus în acest interval.
Capitolul 3 90
taskul T3 execuţia sa este condiţionată de valoarea de adevăr a funcţiei

F  VTE1  VTE 2 .
Task T1 Task T2 Task T3
Iniţializare T1 Iniţializare T2 Iniţializare T3

…VTE1=FALS… …VTE2=FALS… …F=FALS…
AŞTEAPTĂ (F)
NU NU F  VTE1  VTE2
EVEX1? EVEX2?
NU
DA DA F=ADEV ?
ÎNSCRIE(VTE1) ÎNSCRIE(VTE2)
DA
P_T3
P_T1 P_T2
ŞTERGE(VTE1)
ŞTERGE(VTE2)
Fig. 3.29. Utilizarea variabilelor de tip eveniment pentru sincronizarea a trei

taskuri: P_T1 ,P_T2, P_T3 proceduri ale taskurilor T1, T2, T3.
Se observă că P_T3 se execută numai dacă F=ADEVĂRAT , cu alte

cuvinte dacă s-au produs evenimentele EVEX1 şi EVEX2. După execuţie
variabilele VTE1 şi VTE2 se şterg şi cele trei taskuri revin în starea de blocare, în
aşteptarea producerii evenimentelor externe EVEX1 şi EVEX2.
3.4.3.Sincronizarea realizată cu mesaje şi cutii poştale

Cutiile poştale şi mesajele pot fi utilizate atât pentru implementarea
sincronizării cu timpul, cât şi cu evenimente externe.
În cazul sincronizării cu timpul se utilizează de regulă aşteptarea
temporizată la o cutie poştală vidă. Mesajele implicate sunt de regulă mesaje
simbolice, respectiv mesaje cu format şi conţinut fix. În continuare vor fi
prezentate două soluţii de sincronizare bazate pe cutii poştale şi mesaje.
O primă soluţie, ilustrată în figura 3.30 presupune existenţa a două
taskuri T1- cu rol de planificator şi T2 – care trebuie să se execute la intervale
Δt. Soluţia implică prezenţa a trei cutii poştale C0, C1, C2 cu următoarele
funcţii:
- C0 – CP destinată aşteptării temporizate;
Capitolul 3 91
- C1 – CP destinată transferului mesajului de sincronizare MES_SYNC;

- C2 – CP destinată transferului mesajului de confirmare MES_CONF.
Task T1
Task T2
Iniţializare T1
Iniţializare T2
DA
Mes în C0 ?
NU NU
PREIA Mes din C0 MES_SYNC în C1?
GET DA
GET
C0 PREIA MES_SYNC din C1
t=Δt ?
NU C1
DA TRIMITE MES_CONF în C2
TRIMITE MES_SYNC în C1
PUT
P_T2
NU
MES_CONF în C2? C2
DA GET
PREIA MES_CONF din C2
Fig. 3.30. Utilizarea cutiilor poştale pentru sincronizarea cu timpul:

C0, C1, C2 – cutii poştale; P T2 procedură ale taskului T2.
Taskul T1 realizează următoarea secvenţă de operaţii:

1.1 – aşteaptă un interval de timp Δt (intervalul de sincronizare) la
cutia poştală vidă C0;
1.2 – la expirarea acestui intervalul transmite în cutia poştală C1
mesajul de sincronizare MES_SYNC;
1.3 – aşteaptă şi preia din cutia poştală C2 mesajul de confirmare
MES_CONF;
1.4 – se revine la pasul 1.1 , intrându-se din nou în starea de aşteptare
temporizată.
Mesajul de confirmare MES_CONF este un mesaj cu formă fixă care
informează taskul planificator T1 în legătură cu funcţionalitatea taskului T2, care
trebuie să se execute temporizat.
Capitolul 3 92
În ceea ce priveşte taskul T2 , acesta execută următoarea secvenţă:

2.1 – aşteaptă şi preia din cutia poştală C1 mesajul de sincronizare
MES_SYNC;
2.2 - transmite în cutia poştală C2 mesajul de confirmare MES_CONF;
2.3 – execută procedura P-T2.
Din secvenţa de mai sus rezultă faptul că execuţia taskului T2 se produce
în interiorul cuantei de timp Δt , aspect evidenţiat în figura 3.31.
Δt Δt Δt Δt
t
Ex. Ex. Ex. Ex.

Task Task Task Task
T2 T2 T2 T2
Fig. 3.31. Sincronizarea cu timpul: execuţia taskului T2 se face în

interiorul cuantei de timp Δt.
Este posibilă execuţia taskului T2 în afara cuantei Δt, conform

reprezentării din figura 3.32.
Δt Δt Δt Δt
Ex. Ex. Ex. Ex. t

Task Task Task Task
T2 T2 T2 T2
Fig. 2.32. Sincronizarea cu timpul: execuţia taskului T2 se face în
exteriorul cuantei de timp Δt.
În această situaţie nu se mai impune existenţa taskului planificator T1.

Taskul T2 aşteaptă la cutia poştală vidă C0 un interval de timp Δt, deblocarea
producându-se la expirarea acestei cuante de timp. În figura 3.33 se prezintă
structura adaptată a taskului T2 pentru acest tip de sincronizare.
Se observă că nu mai sunt necesare mesaje de sincronizare şi de
confirmare. Dacă se doreşte monitorizarea funcţionalităţii taskului T2, atunci se
menţine taskul T1 care va primeşte la fiecare execuţie a lui T2 câte un mesaj de
confirmare.
Procedeul sincronizării cu timpul, în condiţiile existenţei unui task
planificator poate extins şi la implementarea sincronizării cu un eveniment
extern, corespunzător reprezentării din figura 3.34.
Capitolul 3 93
Task T2
Iniţializare T2
DA
Mes în C0 ?
NU Fig. 3.33. Utilizarea unei cutii poştale

PREIA Mes din C0
vide pentru sincronizarea cu timpul:
GET C0 – cutie poştală; P_T2 procedură
ale taskului T2.
C0
t=Δt ?
NU
DA
P_T2
Task T0 Task T1 Task T2
Iniţializare T0
NU
NU MES_EV NU
EV_EXT ? MES_SYNC
în C0? în C1?
DA PUT DA DA
TRIMITE GET GET
MES_EV PREIA PREIA
în C0 MES_EV MES_SYNC
din C0 din C1
C0
C1
TRIMITE PUT TRIMITE

MES_SYNC PUT MES_CONF
în C1 în C2
NU P_T2
MES_CONF
în C2? C2
DA
PREIA GET
MES_CONF
din C2
Fig. 3.34. Utilizarea cutiilor poştale pentru sincronizarea cu evenimente

externe: C0, C1, C2 – cutii poştale; P_T2 procedură ale taskului T2.
Capitolul 3 94
După cum se observă, înainte de producerea evenimentului EV_EXT

taskurile T0, T1, T2 sunt blocate după cum urmează:
- T0 – în aşteptarea producerii evenimentului EV_EXT;
- T1 – la cutia poştală C0 în aşteptarea mesajului MES_EV care
confirmă producerea evenimentului;
- T2 – la cutia poştală C1 în aşteptarea mesajului de sincronizare
MES_SYNC.
Este important de subliniat faptul că după primirea mesajului de
sincronizare, T2 trebuie să depună în cutia poştală C2 mesajul de confirmare
MES_CONF.
Ca şi în cazul sincronizării cu timpul, taskul T1 poate fi eliminat în
situaţia în care nu se doreşte monitorizarea funcţionalităţii taskului T2, soluţia
principială fiind prezentată în figura 3.35.
Task T2
Task T0
Iniţializare T2
Iniţializare T0
NU
MES_EV
NU în C0?
EV_EXT ?
DA
DA
TRIMITE PUT PREIA
MES_EV GET MES_EV
în C0 din C0
C0
P_T2
Fig. 3.35. Utilizarea unei cutiilor poştale pentru sincronizarea cu evenimente

externe: C0, – cutie poştale; P_T2 procedură ale taskului T2.
După cum se observă între momentele producerii evenimentului extern

EV_EXT taskurile T0 şi T2 sunt blocate după cum urmează:
- T0 – în aşteptarea producerii evenimentului EV_EXT;
- T2 – la cutia poştală C0 în aşteptarea mesajului MES_EV referitor la
producerea evenimentului extern.
Capitolul 3 95
În aceste condiţii taskul T2 este deblocat în momentul în care în cutia

poştală C0 este depus MES_EV asociat producerii evenimentului extern.
3.4.4.Sincronizarea prin monitoare blocuri de întâlnire

 La prezentarea excluderii mutuale a fost introdus conceptul de
monitor care poate fi utilizat şi la sincronizarea taskurilor. În acest scop se
utilizează directive de tip WAIT şi SIGNAL asupra unor variabile de tip condiţie.
Pentru exemplificare considerăm că evoluţia unui task T1 aflat în
monitor este dependentă la un moment dat de realizarea unei condiţii de timp
sau a unui eveniment extern. În această situaţie, la momentul respectiv se va
emite directiva WAIT(C), unde C este variabila de condiţie asociată. Această
directivă va bloca taskul şi îl va scoate din monitor punându-l într-o coadă de
aşteptare, iar în monitor va fi adus un alt task T2.
Dacă între timp condiţia pentru care a fost scos T1 se va îndeplini, T2 va
executa directiva SIGNAL(C), care va avea ca efect scoaterea din monitor a
taskului T2 şi readucerea lui T1. Astfel se realizează execuţia taskurilor la
anumite intervale de timp sau la producerea unor evenimente.
 În anumite situaţii se impune ca un număr de taskuri ale unui
sistem să ajungă toate în anumite stadii ale rulării lor, indiferent în ce ordine, şi
numai după aceea să poată avansa din nou.
TASK A TASK B TASK C
Punct de întâlnire
rendez - vous
TASK A TASK B TASK C
Fig. 3.36. Exemplificarea tehnicii rendez-vous pentru

sincronizarea unui sistem de trei taskuri A, B, C.
Capitolul 3 96
Se poate spune deci, că în spaţiul multidimensional al evoluţiei lor

taskurile şi-au stabilit un punct de întâlnire, ilustrat în figura 3.36, după care din
nou drumurile lor se despart.
O astfel de problemă de sincronizare se rezolvă prin intermediul unui
mecanism dezvoltat în jurul conceptului de bloc de întâlnire cunoscut în
literatura de specialitate ca bloc rendez – vous (BRV).
Principial un BRV reprezintă un ansamblu format dintr-o variabilă
întreagă cu rol de contor şi o coadă de aşteptare. Contorul indică iniţial numărul
taskurilor care încă nu au ajuns la întâlnire. Coada înregistrează indexurile
taskurilor care au sosit în punctul de întâlnire şi care se blochează în aşteptarea
celorlalte.
De fiecare dată când un task a ajuns în punctul de întâlnire conţinutul
contorului cu o unitate. Atingerea valorii zero semnifică realizarea întâlnirii şi în
consecinţă se va trece la deblocarea taskurilor în ordinea în care acestea au fost
înregistrate în coada de aşteptare.
În anumite situaţii un BRV poate conţine şi facilitatea fixării unui timp
limită în care taskurile trebuie să sosească în punctul de întâlnire. Dacă există
taskuri care nu au ajuns în punctul de întâlnire în timpul fixat, aceasta se
contramandează şi taskurile deja sosite se deblochează. Pentru ca taskurile
implicate în procesul rendez-vous să îşi continue evoluţia după trecerea prin
punctul de întâlnire în cunoştinţă de cauză, se impune ca la deblocare să li se
furnizeze o informaţie în care să se codifice succesul sau eşecul întâlnirii.
3.5. Comunicarea între taskuri

După cum s-a arătat procesarea datelor în regim concurent multitasking
implică pe lângă utilizarea de resurse în comun şi schimbul de informaţie între
taskuri concretizat în operaţia de comunicare. Uzual taskurile transferă
informaţia sub formă de mesaje care, după cum s-a văzut la prezentarea
excluderii mutuale pot fi cu conţinut variabil (mesaje informaţionale) sau fix
(mesaje simbolice).
În mod obişnuit comunicarea se implementează prin mecanismul
producător-consumator, taskurile putând fi din acest punct de vedere
- taskuri de tip producător;
- taskuri de tip consumator.
Pentru facilitarea comunicării sistemele de operare trebuie să pună la
dispoziţie instrumente specifice, unul dintre acestea fiind conducta (pipe). O
conductă reprezintă un tampon unidirecţional gestionat conform principiului
FIFO, în care un task producător depune mesaje pe care le preia un task
consumator.
Capitolul 3 97
Mecanismul de comunicare prin conductă trebuie să asigure blocarea

taskului producător care ajunge în faţa unei operaţii de scriere şi conducta este
plină. Acelaşi mecanism va trebui să blocheze un task de tip consumator aflat în
situaţia de preluare a unui mesaj (citire) dintr-o conductă goală.
În situaţia în care două taskuri au atât rol de producător, cât şi de
consumator vor trebui utilizate două conducte, situaţie evidenţiată în figura 3.37.
Taskul i Conducta 1
Conducta 2
Taskul j
Fig. 3.37. Ilustrarea comunicării prin conducte între două taskuri.
După cum se observă Conducta 1 este deschisă la scriere pentru taskul i şi la
citire pentru taskul j, cu alte cuvinte cele două taskuri îndeplinesc rolurile de
producător respectiv consumator. În ceea ce priveşte Conducta 2, aceasta este
deschisă la scriere pentru taskul j şi la citire pentru taskul i, rolurile celor două
taskuri fiind inversate respectiv taskul i – consumator, taskul j – producător.
3.5.1. Utilizarea semafoarelor în comunicare
În mod uzual semafoarele sunt utilizate pentru gestionarea operaţiilor de
înscriere respectiv de citire a mesajelor din conducte. În cele ce urmează va fi
prezentat un exemplu de comunicare, ilustrat principial în figura 3.38, prin
intermediul unui buffer BUF.
BUF
NPROD V(SGO
N-1 N-1
.
pdata . cdata
TPROD . TCONS
2 2
1 1
0 0
Fig. 3.38. Gestionarea comunicării prin conducta BUF .
Taskul TPROD produce date (pdata) pe care le înscrie în BUF. Datele

(cdata) sunt extrase de taskul TCONS şi utilizate în cadrul unei proceduri.
Capitolul 3 98
La rezolvarea problemei de comunicare trebuie avute în vedere

următoarele aspecte:
1 – TPROD trebuie să se blocheze atunci când BUF s-a umplut;
2 – TCONS trebuie să se blocheze atunci cânt BUF este gol, respectiv
nu există date disponibile;
3 – operaţiile de scriere în BUF, respectiv de citire din acesta trebuie să
se excludă reciproc.
Task TPROD Task TCONS
Iniţializare TPROD Iniţializare TCONS

SEMEX=1, SPLIN=0, SGOL=N SEMEX=1, SPLIN=0, SGOL=N
NPROD=0 NCONS=0
NU NU
Δt_ex_TPROD ? Δt_ex_TCONS ?
DA DA
P1_TPROD(pdata) Fig. 2.43.
P(SGOL) P(SPLIN)
P(SEMEX) P(SEMEX)
BUF(NPROD)=pdata cdata =BUF(NCONS)
NPROD=NPROD+1 NCONS=NCONS+1
DA DA
NPROD=N ? NCONS=N ?
NPROD=0 NCONS=0
NU NU
V(SEMEX) V(SEMEX)
V(SPLIN) V(SGOL)
P2_TPROD P2_TCONS(cdata)
Fig. 3.39. Utilizarea semafoarelor în comunicare.
Capitolul 3 99
La rezolvarea problemei de comunicare trebuie avute în vedere

următoarele aspecte:
1 – TPROD trebuie să se blocheze atunci când BUF s-a umplut;
4 – TCONS trebuie să se blocheze atunci cânt BUF este gol, respectiv
nu există date disponibile;
5 – operaţiile de scriere în BUF, respectiv de citire din acesta trebuie să
se excludă reciproc.
Gestiunea corectă a buffer-ului se va face cu ajutorul a două semafoare
generale SPLIN şi SGOL (iniţializate cu valorile 0 respectiv N) asociate
încărcării respectiv descărcării acestuia. Fiecare înscriere în BUF va
presupune decrementarea decrementarea semaforului SGOL respectiv
aplicarea operaţiei P(SGOL) şi incrementarea semaforului SPLIN - aplicarea
operaţiei V(SPLIN). Fiecare extragere din BUF va fi caracterizată de
operaţiile inverse înscrierii respectiv V(SGOL) şi P(SPLIN). Blocarea
taskurilor TPROD şi TCONS în situaţii de excepţie14 va fi realizată după caz
de către semafoarele SPLIN sau SGOL, în conformitate cu cele discutate cu
ocazia prezentării operaţiilor P şi V în paragraful 2.3.2.
Tot pentru gestiunea încărcării / descărcării lui BUF sunt utilizate
contoarele NPROD şi NCONS care parcurg ciclic valori de la 0 la N-1 ceea
ce asigură preluarea datelor conform strategiei FIFO.
După cum se observă din figura 3.39 în care sunt prezentate schemele
logice asociate celor două taskuri pentru excluderea mutuală se utilizează
semaforul binar SEMEX.
Secţiunile critice ale celor două taskuri includ:
- taskul TPROD: înscrierea în BUF şi actualizarea contorului NPROD;
- taskul TCONS: preluarea din BUF şi actualizarea contorului NCONS.
3.5.2. Utilizarea în comunicare a mesajelor şi cutiilor poştale
Mesajele de trecere şi cutiile poştale reprezintă alte două mijloace
destinate asigurării comunicării dintre taskuri. Mesajele se trimit direct de la un
taskul emiţător către cel receptor, în timp ce cutiile poştale reprezintă facilităţi
de comunicare care pot fi utilizate de către toate taskurile aferente aplicaţiei de
timp real.
În figura 3.40 se prezintă un exemplu de comunicare între două taskuri în
care se utilizează ambele modalităţi. Mesajul informaţional MES_INF este
transmis de Taskul T1 sub forma unui mesaj de trecere în timp ce Taskul T2 va
trimite un mesajul simbolic de confirmare MES_CONF prin intermediul cutiei
poştale CP1.
14
Buffer-ul BUF plin sau gol.
Capitolul 3 100
Task T1 Task T2
P1_T1 P1_T2
NU NU
T2 gata recepţie ? T1 gata transmisie ?
DA DA
RECEIVE
TRIMITE MES_ INF la T2 PREIA MES_ INF de la T1
SEND
TRIMITE MES_CONF în CP1

NU
MES_CONF în CP1?
Fig. PUT
NU DA CP1
PREIA MES_CONF din CP1
P1_T1 P2_T2
Fig. 3.40. Utilizarea mesajelor de trecere şi a cutiilor poştale în comunicare.
Este important de subliniat faptul că transmiterea unui mesaj de trecere

este posibilă dacă taskul receptor este gata să îl primească. În ceea ce priveşte
receptorul acesta se va bloca în aşteptarea mesajului dacă taskul emiţător nu este
gata să îl transmită.
În ceea ce priveşte mesajul de confirmare, Taskul T1 se blochează până
la depunerea acestuia în cutia poştală CP1.
3.6. Formalizarea sistemelor multitasking

Din cele expuse pe parcursul prezentului capitol există două
componente ale concurenţei între activităţi şi taskuri şi anume paralelismul şi
interacţiunea. Paralelismul se referă la execuţia paralelă sau pseudoparalelă, iar
interacţiunea are în vedere utilizarea în comun a resurselor şi comunicarea.
În general pentru noţiunea de concurenţă se acceptă următoarele două
sensuri:
- competiţie pentru obţinerea resurselor necesare execuţiei taskurilor;
Capitolul 3 101
- întâlnire (intersecţie) pentru realizarea în comun a scopurilor

aplicaţiei din care fac parte taskurile.
Taskul ca unitate de bază a programării concurente se bucură de
următoarele proprietăţi importante:
- indivizibilitate;
- secvenţialitate;
- asincronism;
- temporalitate.
 Indivizibilitatea se referă la faptul că taskul este unitate atomică din
punctul de vedere al concurenţei, cu alte cuvinte acesta nu poate fi divizat în alte
unităţi cărora SOTRM să le acorde în mod autonom resurse.
 Secvenţialitatea presupune absenţa paralelismului în interiorul unui
task, în consecinţă execuţia fiind pur secvenţială.
 Asincronismul are în vedere o independenţă relativă a execuţiei
taskurilor, cu excepţia momentelor de interacţiune când este necesară
sincronizarea.
 Temporalitatea atestă faptul că taskul se manifestă şi este
recunoscut numai în intervalul cuprins între activarea şi terminarea sa.
Taskurile pot interacţiona în două moduri şi anume:
- direct prin concurenţa asupra unor resurse;
- indirect prin partajare resurselor şi comunicare.
În cadrul interacţiunii directe controlul concurenţei se realizează din
interiorul taskurilor, în timp ce reglementările aferente interacţiunilor indirecte
revin SOTRM .
Consideraţiile de mai sus au în vedere faptul că din punctul de vedere al
comportării exterioare un task se specifică prin următoarele trei elemente:
- intrările (datele);
- ieşirile (rezultatele);
- timpul de execuţie.
În continuare vor fi prezentate câteva elemente care privesc formalizarea
sistemelor de taskuri şi a interacţiunilor din cadrul acestora.
Un sistem de taskuri ST este definit ca un dublet
ST  (T ,  ) , (3.2)
în care T  T1 ,T2 , ,Tn  este o mulţime de taskuri iar < reprezintă o relaţie de
ordine totală (precedenţă) definită pe mulţimea T .
Capitolul 3 102
Pentru două taskuri Ti ,Tj  T relaţia Ti  Tj semnifică faptul că ultima

instrucţiune a taskului Ti trebuie să se încheie înainte de începerea părimei
instrucţiuni a taskului Tj .
În mod obişnuit unui task Ti  T îi sunt asociate două evenimente
semnificative şi anume:
Ti - iniţierea taskului;
T i - terminarea taskului.
 Iniţierea unui task corespunde unei tranziţii de stare care include:
- achiziţia şi asigurarea resurselor necesare execuţiei taskului;
- iniţializarea stării resurselor;
- transferul datelor de la intrare.
 Terminarea unui task are asociată o tranziţie de stare care cuprinde:
- transferul rezultatelor la ieşire;
- eventuala restaurare a stării resurselor;
- eliberarea resurselor.
Se reaminteşte faptul că o resursă reprezintă o entitate fizică sau logică
utilizată de un task pe parcursul execuţiei sale. În rândul resurselor pot fi
incluse UCP, dispozitive de intrare/ieşire, memoria internă, memoria externă,
variabile, fişiere, proceduri, etc. Este important de subliniat faptul că
echipamentul gazdă pe care rulează sistemul de taskuri se consideră partajat în
resurse, definirea resurselor şi partajarea fiind funcţie de aplicaţie.
Relaţia de precedenţă într-un sistem de taskuri poate fi sugestiv
reprezentată printr-un graf de precedenţă. Acesta este un graf orientat care are
ca noduri elementele mulţimii T , iar arcele sunt asociate relaţiei de precedenţă.
Pentru două taskuri Ti ,Tj  T un arc de la Ti la Tj - respectiv arc(Ti, Tj) - apare
în graf numai dacă Ti  Tj şi nu există un task Tk astfel încât Ti  Tk  Tj .
Pentru un graf de precedenţă prezintă interes următoarele elemente:

- lungime a drumului între două taskuri;
- task succesor şi task predecesor;
- task iniţial şi task terminal;
- nivelul unui task neterminal;
- secvenţă de execuţie a unui task,
care vor fi definite în cele ce urmează.
Capitolul 3 103
 Lungimea drumului între două taskuri care aparţin unui graf de

precedenă este egală cu numărul arcelor sau cu numărul nodurilor la care se
adugă 1.
 Într-un sistem format din n taskuri cu 1  i  j  n , taskul Ti se
numeşte predecesor al taskului Tj, iar Tj constituie succesor al Ti. Dacă j  i  1 ,
Ti este predecesor direct al lui Tj, iar Tj succesor direct al lui Ti. Două taskuri
Tk ,Tl  T se numesc independente dacă taskul Tk nu este nici succesor şi nici
predecesor al taskului Tl. Având în vedere că relaţia de precedenţă implică o
ordonare temporală, rezultă că două taskuri pot fi concurente numai dacă sunt
independente.
 Un task iniţial este un task fără nici un predecesor, iar un task
terminal reprezintă un task fără nici un succesor
 Un task neterminal este de nivel K dacă cel mai lung drum care
porneşte din el şi se opreşte într-un task terminal este de lungime K. Prin
definiţie un task terminal este de nivel 1.
 Pentru un sistem de taskuri ST  (T ,  ) cu T  T1 ,T2 , ,Tn  , o
secvenţă de execuţie reprezintă un şir
  { a1 ,a2 , ,a2 n } , (3.3)
de evenimente ai asociate iniţierii şi terminării taskurilor din ST care satisfac
următoarele condiţii de precedenţă:
- pentru orice task Ti  T simbolurile T i ,Ti apar o singură dată;
- dacă am  T i şi an  T i atunci m  n ;
- dacă am  T i şi an  T j cu Ti  Tj atunci m  n .
O secvenţă parţială de execuţie este un subşir β al şirului α de forma
  { a1 , a2 , , ak } , cu k  2n . (3.4)
Un task Tp  T este activ după o secvenţă parţială de execuţie de tipul
celei din relaţia (3.4) dacă există i  k , cu ai  T p , dar a j  T p ( ) j  k.
Oricărei secvenţe de execuţie   { a1,a2 , ,a2 n } îi corespunde o

secvenţă de stări
  { s1, s2 , , s2 n } , (3.5)
unde si  S cu i  1, 2 , , n şi S – spaţiul stărilor sistemului pe care evoluează
taskurile. Starea s0 este starea inițială a sistemului de calcul iar tranziția
Si 1  Si este generat de evenimentul ai.
Capitolul 3 104
La tratarea sistemelor de taskuri este util ca acestea să fie considerate

sisteme închise, respectiv să conţină câte un singur task iniţial şi terminal.
Dacă un sistem de taskuri ST  (T ,  ) cu T  T1 ,T2 , ,Tn  nu este închis,
atunci se construieşte un sistem STʹ  (T ' ,  ) cu T '  T0 ,T1 ,T2 , ,Tn ,Tn1 . În
sistemul de taskuri STʹ taskul T0 este succesorul tuturor taskurilor sistemului ST,
iar taskul Tn+1 predecesorul acestora.
Dacă   { a1 ,a2 , ,a2 n } este o secvenţă de execuţie pentru sistemul ST
atunci o secvenţă pentru sistemul STʹ va fi de forma  ʹ  {T 0 T 0 a T n1 T n1 } .
Din felul în care a fost construit sistemul STʹ rezultă că acesta este închis.
Dacă taskurile T0 şi Tn+1 nu au alte funcţii în afara celor precizate, atunci
sistemele ST şi STʹ sunt echivalente din punctul de vedere al funcţiilor pe care
acestea le execută. În acest fel s-a realizat închiderea sistemului iniţial de
taskuri ST .
În figura 3.41 se prezintă un exemplu de graf de precedenţă, pentru care
vor fi evidenţiate unele dintre noţiunile prezentate mai sus.
T1
T3 Fig. 3.41. Graf de preceden ă.
T2
T4 T5 T6
T7
Pentru graful din figura 3.41, în tabelul 3.1 se prezintă lungimile

drumurilor între taskuri. Analizând datele din acest tabel se observă că funcţie
de calea aleasă lungimile drumurilor pot să difere.
Tabelul 3.1
Nod Nod
Cale Lungime
plecare sosire
T1 T2 T1- T2 2
T1 T4 T1- T3 * T3- T4 3
T1 T7 T1- T2 * T2- T7 3
T1 T7 T1- T3 * T3- T4 * T4- T7 4
Capitolul 3 105
Tot din graf rezultă taskurile succesoare şi predecesoare. De exemplu

taskul T3 este predecesor direct al lui T4, dar acesta este numai predecesor al lui
T7. În ceea ce priveşte taskurile iniţial şi terminal, taskul T1 este task iniţial al
grafului, iar T7 task terminal.
Pe baza definiţiei nivelului unui task, în tabelul 2.2 se prezintă nivelele
taskurilor conţinute în graful din figura 3.41.
Tabelul 3.2
Task T1 T2 T3 T4 T5 T6 T7
Nivel 4 2 3 2 2 2 1
Ţinând cont de definiţia secvenţei de execuţie din relaţia (3.3), în

continuare se prezintă trei asemenea secvenţe posibile notate α1, α2, α3 după cum
urmează:
1  T 1 T 1T 2 T 2 T 3 T 3 T 4 T 4 T 5 T 5 T 6 T 6 T 7 T 7 ;
 2  T 1 T 1 T 2T 3T 2T 3 T 4T 4 T 5 T 6T 5T 6T 7 T 7 ;
 3  T 1 T 1T 3 T 3 T 4 T 4 T 2 T 5 T 6 T 5 T 6 T 2 T 7 T 7 .
Coordonarea unui sistem de taskuri presupune definirea şi soluţionarea
următoarelor probleme generale :
A - determinarea taskurilor;
B - blocarea taskurilor;
C - excluderea mutuală a taskurilor;
D - sincronizarea taskurilor.
A - determinarea taskurilor
Un sistem de taskuri este determinat , dacă prin evoluţia sa conduce la
un rezultat unic, indiferent de ordinea de execuţie a taskurilor sau de vitezele
acestora, în condiţiile respectării unor relaţii de precedenţă definite.
Un sistem nedeterminat 15 poate fi transformat în unul determinat prin
adăugarea unor relaţii de precedenţă.
Pentru formalizarea determinării vom considera V tuturor resurselor
sistemului pe care rulează taskurile. Fie o mulţime M  M1 ,M 2 , ,M n  de
submulţimi ale lui V numite generic locaţii de memorie. Numărul de locaţii
15
Un sistem de taskuri care nu este determinat se numeşte nedeterminat.
Capitolul 3 106
reprezintă numărul de tipuri de resurse ale sistemului, iar valoarea (conţinutul)

locaţiei Mi reprezintă numărul de resurse disponibile din clasa i.
Considerăm în continuare mulţimea de taskuri T  T1 ,T2 , ,Tn , o
secvenţă de execuţie a acestora   { a1, a2 , , a2 n } şi o secvenţă de stări
  { s1, s2 , , s2 n } .
Pentru sistemul de taskuri Mi(k) reprezintă valoarea celulei de memorie
Mi după execuţia secvenţei parţiale β  { a1, a2 , , ak } .
În aceste condiţii starea sk poate fi definită (în contextul problemei
determinării taskurilor) astfel
sk  { M1 k , M2 k , , Mm k } . (3.6)
Fiecărui task Ti  T îi corespund două submulţimi ale mulţimii M şi
anume: DTi – domeniul de definiţie ;
RTi – domeniul de valori,
astfel încât
Ti : DTi  RTi . (3.7)
Două taskuri Ti ,Tj  T se numesc neinterferente dacă Ti este succesor sau
predecesor al lui Tj sau dacă
RTi  RTj  DTi  RTj  DTj  RTi   . (3.8)
Cu alte cuvinte două taskuri sunt neinterferente sunt condiţionate în
raport cu relaţia de precedenţă, sau dacă mulţimile rezultatelor sunt disjuncte şi
mulţimea de definiţie a unui task este disjunctă faţă de mulţimea rezultatelor
celuilalt task.
Pornind de la definiţia determinării taskurilor, rezultă că în condiţiile de
mai sus cele două taskuri sunt determinate. Extrapolând se poate spune că un
sistem de taskuri este determinat, dacă oricare două taskuri ale sistemului sunt
neinterferente, respectiv sunt determinate.
B – blocarea taskurilor
Această situaţie apare când un număr de taskuri este blocat într-o listă
circulară de aşteptare, fiecare task aşteptând eliberarea unei resurse pe care o
deţine un alt task.
Pentru exemplificare considerăm mulţimea de taskuri
M  M1 ,M 2 , ,M n  care se găsesc în situaţia ilustrată în figura 3.42. După cum
se observă taskul T1 deţine resursa R1 şi aşteaptă eliberarea resursei Rn , taskul T2
deţine resursa R2 şi aşteaptă eliberarea resursei R1 ş.a.m.d. iar ultimul task Tn
deţine resursa Rn şi aşteaptă eliberarea resursei Rn-1 .
Capitolul 3 107
Fig.
T1 R1
Tn T2
Rn-1 R2
Tn-1 T3
Rn-2 R3
T4
Tn-2
Rn-1 R4
Fig. 3.42. Taskuri blocate într-o listă circulară.
Pentru a formaliza blocarea unui sistem de taskuri se consideră m tipuri

de resurse R1, R2, . Rm, , cantităţile, disponibile din fiecare resursă fiind c1, c2, .
cm, iar capacităţii sistemului i se asociază vectorul
C  [ c1 , c2 , ,cm ] . (3.9)
Fie mulţimea T  T1 ,T2 , ,Tn  din cadrul unui sistem de taskuri, în care
fiecare task pe parcursul execuţiei sale foloseşte un număr constant de resurse
din fiecare tip.
Pentru fiecare task se defineşte vectorul qi al cererilor suplimentare de
resurse pentru taskul Ti ,
qi  [qi1 , qi 2 , ,qim ] ; (3.10)
şi vectorul ei al resurselor eliberate la terminarea taskului Ti
ei  [ei1, ei 2 , ,eim ] , (3.11)
în care qij , eij reprezentă numerele de resurse Rj solicitate suplimentar / eliberate
de către taskul Ti .
Pentru sistemul de taskuri se consideră secvenţa de execuţie
  T 1 T 1T 2 T 2 T n T n  { 1 , 2 , , 2 n } , (3.12)
căreia îi corespunde secvenţa de stări
  { s1, s2 , , s2 n } . (3.13)
În relaţia (3.13) o stare sk este explicitată prin vectorii
A(k)  [ A1 ( k ) , A2 ( k ), ,Am ( k )] ; (3.14)
Capitolul 3 108
Q(k)  [Q1( k ) ,Q2 ( k ), ,Qm ( k )] , (3.15)

unde: A(k) reprezintă numărul de resurse alocate după evenimentul ak ;
Q(k) - numărul de resurse eliberate după evenimentul ak ;
Aj(k)- numărul de resurse Rj alocate după evenimentul ak ;
Qj(k)- numărul de resurse Rj eliberate după evenimentul ak.
Vectorii A(k) şi Q(k) sunt definiţi recursiv, astfel:
Q( 0 )  q1
…………………………..
Q(k)  0 dacă ak  T i
sau (3.16)
Q(k)  qi 1 dacă ak  T i
……………………………
A( 0 )  0
…………………………..
A(k)  A( k  1)  Q( k  1) dacă ak  T i
sau (3.17)
A(k)  A( k  1)  ei dacă ak  T i
……………………………
Din analiza grupurilor de relaţii (3.16) şi (3.17) rezultă următoarele

aspecte:
a) vectorul cererilor de resurse Q este iniţializat cu cererea primului
task (primul eveniment este T 1 );
b) dacă evenimentul ak este iniţierea unui task, atunci nu sunt cerute
resurse suplimentare;
c) dacă ak reprezintă terminarea unui task, se atribuie lui Q(k)
cererea următorului task (evenimentul următor va fi iniţierea
acestuia);
d) vectorul resurselor alocate A este iniţial zero;
e) dacă ak reprezintă iniţierea unui task, se adaugă la numărul de
resurse alocate numărul de resurse cerute curent;
f) dacă ak este terminarea unui task, se scade din A(k-1) numărul
resurselor eliberate ei;
g) terminarea unui task Ti este asociată cu eliberarea de resurse de
către acesta şi cu solicitarea de resurse de către Ti + 1 ;
Capitolul 3 109
h) Se presupune că, la sfârşitul secvenţei de execuţie, se eliberează

toate resursele, adică :
n
A( 2n)   [ q( k )  e( k )]  0 . (3.18)
k 1
În continuare vom considera un sistem de taskuri T format din mai multe

subsisteme , respectiv T 1 , T 2 , , T N cu T l  T , l  1, 2 ,  ,N ,
unde 
T l  T1( l ) ,T2( l ) , ,Tn(ll )  cu l  1, 2 ,  ,N . (3.19)
Subsistemele Tl se execută în paralel, situaţie în care secvenţele
corespunzătoare fiecărui subsistem se pot întrepătrunde.
Pentru un asemenea subsistem notăm cu
- qi( l ) - vectorul cererilor suplimentare de resurse;
- ei( l ) - vectorul resurselor eliberate;
- A( l ) ( k ) - numărul de resurse alocate după evenimentul ak;
- Q( l ) ( k ) - numărul de resurse eliberate după evenimentul ak.

O secvenţă de execuţie a sistemului de taskuri T va fi de forma
  { a1,a2 , , ak , , a2n } unde, (3.20)
n  n1  n2    nN , (3.21)
un eveniment ak putând fi asociat oricărui subsistem Tl respectiv

(l)
ak  T i sau ak  T (i l ) cu i  1, 2 ,  ,nl
Starea sistemului de taskuri T va fi definită prin perechea de matrice
[ A( k ),Q( k ) ] , unde
 A( 1 ) ( k )  Q( 1 ) ( k ) 
 (2)   ( 2) 
 A ( k ) Q ( k )
A( k )  Q( k )   cu l  1, 2 ,  ,N (3.22)
     
 (l)   (l) 
 A ( k )   Q ( k ) 
Referitor la elementele matricelor A(k) şi Q(k) sunt utile următoarele
precizări:
a) dacă Q( l ) ( k )  0 subsistemul T l aşteaptă alocarea de resurse;
Capitolul 3 110
b) dacă A( l ) ( k )  0 şi Q( l ) ( k )  0 subsistemul T l este în execuţie

sau îndeplineşte condiţiile pentru a continua execuţia.
Un subsistem T l pentru care
A( l ) ( k )  Q( l ) ( k )  0 , (3.23)
se numeşte activ la momentul k , în sensul că are resurse alocate şi/sau solicită
resurse noi.
Pentru un sistem de taskuri se defineşte vectorul resurselor disponibile la
momentul k
N
d(k)  C   A( l ) ( k ) , (3.24)
l 1
respectiv din capacitatea sistemului C se scade totalitatea resurselor alocate celor

N subsisteme la momentul k.
(l)
Dacă un eveniment ak este o iniţiere, respectiv ak  T i , atunci aceasta
este permisă dacă resursele cerute Q( l ) ( k ) nu depăşesc cantitatea de resurse
disponibile d(k), cu alte cuvinte
Q( l ) ( k )  d( k ) . (3.25)
O secvenţă de execuţie se numeşte validă dacă toate iniţierile de taskuri
sunt permise.
O situaţie întâlnită în execuţia unui sistem de taskuri este interblocarea,
pentru a cărei definire vom considera o secvenţă de execuţie parţială
  { a1, a2 , , ak }
şi o secvenţă corespunzătoare de stări
  { s1 , s2 , , sk } .
Se spune că există o interblocare în stare sk dacă există o mulţime
discretă nevidă I  {1, 2 , , N } astfel încât pentru ( ) l  I , cererile să
depăşească disponibilităţile, respectiv să fie satisfăcută inegalitatea 16
Q( l ) ( k )  d( k )   A( i ) ( k ) . (3.26)
iI
Prin definiţie rezultă că, pentru ( ) l  I Q( l ) ( k )  0 , adică evenimentul

următor din subsistemul Tl este o iniţiere a unui task Ti ( i  {1, 2 , , nl } ), iar
această iniţiere nu este permisă pentru nici un indice l  I (întrucât cererea de
resurse este mai mare decât disponibilitatea). Mai mult, din definiţie rezultă că
16
Se spune de asemenea că fiecare sistem Tl cu l  I este interblocat.
Capitolul 3 111
în ipoteza cea mai favorabilă, dacă se eliberează toate resursele deţinute în

prezent de celelalte taskuri, iniţierea este de asemenea nepermisă.
Problemele de bază care se pun în legătură cu interblocarea sunt:
detectarea şi evitarea.
 Detectarea interblocării presupune existenţa unui algoritm având
ca intrare starea curentă sk, şi care să precizeze dacă în starea respectivă există
interblocare.
 Evitarea interblocării implică existenţa unui algoritm care, pornind
dintr-o stare dată şi pe baza cunoaşterii cererilor şi eliberărilor de resurse
aferente evenimentelor din sistemul de taskuri, să precizeze dacă există secvenţe
în care să nu apară interblocări şi să construiască cel puţin o asemenea secvenţă.
C – excluderea mutuală a taskurilor

După cum s-a arătat pe parcursul prezentului capitol anumite resurse
necesare execuţiei unui sistem de taskuri sunt resurse critice şi nu pot fi
deţinute la un moment dat decât de un singur task. Secţiunea dintr-un task în
care acesta accesează o secţiune critică constituie o secţiune critică.
În cadrul unui sistem de taskuri, acestea pot interacţiona, prin accesul
concurent la diferite resurse critice sau prin transmiterea de date (mesaje) între
ele. Pentru buna desfăşurare a activităţii sistemului de taskuri, în sensul
determinării şi evitării interblocării, trebuie prevăzute anumite operaţii specifice
(primitive) care, în esenţă, trebuie să asigure ca secţiunile critice să nu se
execute în paralel (deci să nu se întrepătrundă).
Excluderea mutuală reprezintă operaţia prin care se asigură accesul la un
moment dat a unui singur task în propria secţiune critică referitoare la o anumită
resursă. Este evident faptul că prin modul în care a fost introdus conceptul de
excludere mutuală , această operaţie asigură evitarea execuţiei paralele a
secţiunilor critice.
Pentru a sublinia importanţa excluderii mutuale se prezintă în mai jos
secvenţele aferente execuţiei a două taskuri T1 şi T2.
Task T1 Fig. 2.43. Soluţia lui Knuth

pentru realizarea excluderii
repetă indefinit
mutuale.
{
{observă eveniment}
CONTOR←CONTOR+1
}
Taskul T1 observă un eveniment exterior (care se produce complet

asincron), incrementând variabila CONTOR (iniţializată cu zero) după apariţia
Capitolul 3 112
fiecărui eveniment. Taskul T2 consumă evenimentele produse (le prelucrează) şi

resetează apoi variabila CONTOR, care după cum se observă poate fi accesată
din ambele taskuri.
Să presupunem că taskul T2 a preluat controlul şi a consumat
evenimentele, dar nu a resetat încă variabila CONTOR. Dacă în acest moment se
produce un eveniment, T2 este întrerupt şi controlul este preluat de taskul T1.
Acesta incrementează variabila CONTOR, cedând controlul taskului întrerupt,
deci lui T2, care continuă execuţia din punctul în care a fost întrerupt, resetând
prin urmare variabila CONTOR. Rezultă că evenimentul produs a rămas
neconsumat şi prin urmare taskul T2 nu şi-a realizat funcţionalitatea.
Pentru a nu se ajunge la această disfuncţie este necesar ca operaţiile din
taskurile T1 şi T2 să nu interfere, deci să se excludă mutual.
O primă soluţie la problema excluderii mutuale a fost dată de Donald
Knuth. Pentru un sistem de taskuri T  T1 ,T2 , ,Tn care pot solicita fiecare o
resursă comună R , metoda lui Knuth presupune adăugarea la fiecare task Ti a
două taskuri Si şi Ui situate din punct de vedere al precedenţei înaintea şi
respectiv după Ti potrivit reprezentării din figura 3.43.
Si Ti Ui
Fig. 3.43. Soluţia lui Knuth pentru realizarea excluderii mutuale.
Se introduc de asemenea o coadă de aşteptare şi o variabilă globală p,

ambele iniţializate cu zero. Coada este implementată printr-un tablou Q de
dimensiune n+1, în care se vor trece în ordine, indicii taskurilor care concurează
pentru resursa R. În variabila globală p se înscrie indicele ultimului task din
coada de aşteptare. Iniţializarea cu zero a cozii şi variabilei indică faptul că în
coadă nu aşteaptă nici un task.
Pentru explicarea funcţionalităţii taskurilor Si şi Ui se consideră
următoarea organizare a acestora.
Task Si Task Ui
Q(p) ← i; if(p ≠ i) Q(0) ← Q(i);
p ← i; else
while (Q(0) ≠ i) {
{ p←0;
; Q(0)←0;
} }
Capitolul 3 113
 Taskul Si introduce Ti în coada de aşteptare (prin înscrierea indicelui

i în Q(p)) şi poziţionarea lui p în i) după care aşteaptă (în ciclul while) până
când Ti ajunge în capul cozii (respectiv până când Q(0)= i). După expirarea lui Si
începe execuţia propriu-zisă a taskului Ti.
 Taskul Ui elimină taskul Ti din coadă şi pune următorul task în capul
cozii (Q(0) ← Q(i)). Dacă Ti a fost ultima activitate din coadă, atunci coada se
iniţializează cu zero (p←0, Q(0)←0 adică se consideră coada vidă).
În vederea eliminării interferenţelor între diferite taskuri Si şi Sj sau între
taskuri Si şi Uj, trebuie ca activităţile din Si şi Uj să fie indivizibile (să nu poată fi
întrerupte). Pentru realizarea acestui deziderat, se consideră două proceduri
neîntreruptibile enqueue (i) şi remove (i) care nu pot interfera şi al căror cod
simplificat se prezintă mai jos.
enque(i) remove(i)
{ {
Q(p) ← i; if(p ≠ i) Q(0) ← Q(i);
p ← i; else
} {
p←0;
Q(0)←0;
}
}
În cuprinsul acestui capitol au fost prezentate şi alte instrumente pentru

realizarea excluderii mutuale şi anume: semafoare, variabile de tip eveniment,
cutii poştate, blocuri resursă etc.
D – sincronizarea taskurilor
După cum s-a menţionat la prezentarea acestei operaţii multitasking,
două taskuri se consideră sincronizate, dacă se pot stabili relaţii reciproce între
anumite momente ale execuţiei lor.
În cadrul cooperării a două sau mai multe taskuri, trebuie semnalate
diverse evenimente, acţiuni, etc., astfel încât funcţionalitatea sistemului să fie
cea proiectată.
Sincronizarea unui task poate avea loc fie pe un eveniment exterior
taskului, fie pe o condiţie de timp.
Pentru realizarea sincronizării executivele de timp real pun la dispoziţie
instrumente şi tehnici care au fost prezentate în subcapitolul 3.4.
Capitolul 3 114
CAPITOLUL Resurse pentru
4 programarea în timp real

a datelor achiziționate
O etapă în existenţa unui sistem de programe în timp real o reprezintă

codificarea care presupune transpunerea algoritmului într-un program, utilizând
în acest scop resurse adecvate.
Având în vedere specificitatea aplicaţiilor de timp real rezultă că mediile
de dezvoltare trebuie să răspundă la rândul prin caracteristici unor cerinţe
specifice.
În prezentul capitol vor fi analizate aceste cerinţe şi caracteristici şi se va
prezenta un mediu de programare în timp real.
4.1. Cerinţele şi caracteristicile limbajelor de programare

în timp real
Limbajele de programare în timp real (LPTR) trebuie să prezinte
caracteristici şi să ofere facilităţi care să răspundă în primul rând problemelor
ridicate de execuţia paralelă sau pseudoparalelă a taskurilor.
4.1.1. Tipuri de LPTR

Înainte de evidenţierea unor tipuri de LPTR vor fi prezentate câteva
elemente specifice unui metalimbaj de descriere. Acest metalimbaj presupune
descrierea unor noţiuni cu ajutorul altora, care trebuie la rândul lor definite, până
se ajunge la definiţii în care intervin numai elementele de bază ale limbajului
(adică acelea care au semnificaţie intrinsecă, respectiv litere, cifre, semne
speciale, cuvinte cheie ).
Aceste elemente sunt considerate atomice iar lor li se alocă simboluri
terminale. Spre deosebire de elementele atomice, noţiunilor sintactice care
urmează a se defini li se locă simboluri neterminale.
Metalimbajul de descriere reprezintă un limbaj pentru descrierea
construcţiilor altui limbaj. În continuare se vor prezenta succint câteva elemente
Capitolul 4 115
aferente unui asemenea metalimbaj, în care pentru descriere se utilizează

grafurile sintactice.
Un asemenea graf conţine următoarele elemente:
- simboluri terminale asociate unităţilor atomice, care se prezintă sub
forma unui cerc în care se înscrie respectiva unitate;
- simboluri neterminale asociate noţiunilor sintactice, care se prezintă
sub forma unor dreptunghiuri în care se înscrie respectiva noţiune;
- arce orientate.
Graful se parcurge într-un singur sens de la unica săgeată care intră, la
unica săgeată care părăseşte graful.
Într-un graf sintactic se regăsesc în formă specifică elementele
programării structurate şi anume succesiunea (secvenţa), ramificaţia, iteraţia.
Succesiunea este implementată de concatenare (alipire), ramificaţia de
alternativă, iar iteraţia de repetiţie.
De exemplu graful sintactic pentru simbolul cifră, care conţine numai
simboluri terminale, se prezintă ca în figura 4.1 şi se interpretează în felul
următor: o cifră se reprezintă cu ajutorul unuia dintre simbolurile 0, 1, …, 9.
0 1 2 ... 8 9
Fig. 4.1. Graf sintactic pentru noţiunea cifră.
După cum se observă acest graf conţine numai ramificaţii în sensul că

pentru o cifră se trece o singură dată prin simbolul aferent.
Grafuri asemănătoare se obţin pentru noţiunile literă mică (minusculă) şi
literă mare (majusculă) cu ajutorul simbolurilor a, b, c, …, x, y, z respectiv A, B,
C, …, X, Y, Z.
Dacă se doreşte construcţia grafului sintactic număr algebric cu semn, se
utilizează unitatea atomică semn şi noţiunea cifră potrivit reprezentării din
figura 4.2.
+
cifră
-
Fig. 4.2. Graf sintactic pentru noţiunea număr algebric.
Capitolul 4 116
Din punct de vedere structural există o concatenare a noţiunilor semn şi

cifră. Definirea noţiunii semn implică o ramificaţie, iar pentru a forma numărul
din mai multe cifre o repetiţie.
Un ultim exemplu se referă la definirea noţiunii nume. După cum rezultă
din figura 4.3 în care se prezintă graful sintactic asociat, nume începe obligatoriu
cu o literă, care poate fi urmată sau nu alte litere sau cifre.
literă
literă
cifră
Fig. 4.3. Graf sintactic pentru noţiunea nume.
Alături de descrierea pe care o realizează, metalimbajul contribuie şi la

înţelegerea şi însuşirea rapidă a construcţiilor sintactice specifice unui anumit
limbaj.
Principalul criteriu de clasificare a LPTR îl reprezintă forma sub care
taskurile solicită servicii SOTR respectiv interfaţa sistem de operare – LPTR,
pentru care există următoarele modalităţi de realizare:
a) în program se introduc explicit structuri de date şi de cod necesare
efectuării serviciilor ; introducerea explicită poate avea în vedere şi utilizarea
unor secvenţe în limbaj de asamblare pe lângă construcţiile specifice LPTR
(exemple de limbaje RTL/2, FORTH, etc.);
b) în biblioteca obiect a limbajului se află proceduri apelabile din
programul sursă care apelează la rândul lor executivul de timp real (această
modalitate este în general specifică extensiilor de timp real a unor limbaje de
nivel înalt, cum ar fi FORTRAN 77, BASIC etc.);
c) LPTR conţine construcţiile adecvate – structuri de date şi de
instrucţiuni – care permit exprimarea directă a serviciului dorit (exemple de
limbaje: EDISON, MODULA 2, ADA etc. ).
4.1.2. Cerinţe impuse LPTR

Principala cerinţă impusă LPTR o reprezintă desigur existenţa de
primitive care să implementeze operaţiile multitasking şi instrumentele de
implementare specifice.
În afara acestei cerinţe, un LPTR trebuie să satisfacă şi ale exigenţe
legate în principal de:
Capitolul 4 117
- fiabilitate ;
- eficienţă ;
- flexibilitate ;
- claritate ;
- simplitate;
- portabilitate.
 Fiabilitatea LPTR se referă la facilităţile pe care trebuie să le ofere
limbajul respectiv pentru evitarea erorilor de programare şi detectarea automată
în situaţia în care acestea nu au putut fi evitate. Pe cât posibil detectarea erorilor
trebuie să se facă în faza de compilare pe maşina gazdă.
 Eficienţa LPTR are în vedere aspecte legate de efortul de dezvoltare
şi de gradul de utilizare a resurselor maşinii ţintă pe care rulează aplicaţia.
Cerinţa de eficienţă impune evident un efort cât mai redus dezvoltare şi un grad
de utilizare cât mai ridicat al resurselor maşinii ţintă.
 Flexibilitatea LPTR impune ca toate operaţiile aferente unei aplicaţii
de timp real să fie exprimate exclusiv prin mijloace ale limbajului.
 Claritatea LPTR se referă la necesitatea existenţei de resurse
(începând cu cuvinte cheie şi terminând cu facilităţi pentru modularizare şi
structurare) care să permită elaborarea, descrierea şi modificarea programelor
numai prin mijloace ale limbajului , fără a se face apel la mijloace auxiliare cum
ar fi schemele logice, pseudocodul, etc. Este de menţionat faptul că în ceea ce
priveşte claritatea produsului program rezultat aceasta este influenţată de stilul
programatorului care trebuie să se încadreze în obiectivele ingineriei
programării în timp real.
 Simplitatea LPTR reprezintă o cerinţă care are în vedere următoarele
aspecte:
- reducerea posibilităţilor de erori în programare datorită unor
construcţii sintactice complexe;
- volume mici şi complexitate redusă pentru compilare;
- obţinerea unor programe obiect eficiente.
 Portabilitatea LPTR presupune independenţa codului executabil de
tipul maşinii ţintă. În general portabilitatea contribuie la distribuire costurilor de
elaborare la mai multe aplicaţii. Este de menţionat faptul că portabilitatea este
mai greu de respectat la aplicaţiile de timp real, deoarece pentru ridicarea
performanţelor acestora se caută valorificarea la maximum a disponibilităţilor
hardware ale maşinii ţintă.
Capitolul 4 118
4.1.3. Caracteristicile LPTR

Cerinţelor de mai sus li se răspunde cu următoarele caracteristici ale
LPTR:
- structurare ;
- concurenţă ;
- programare la nivel fizic ;
- tratarea excepţiilor ;
- compilare separată
- existenţa unităţilor generice.
 Structurarea
Când se vorbeşte de structurare se au în vedere aspecte legate de tipizare,
abstractizare şi vizibilitate care se referă atât la date cât şi la cod.
Tipizarea există practic în orice limbaj evoluat şi presupune descrierea
datelor şi a operaţiilor în care sunt implicate, într-o terminologie orientată în
primul rând spre aplicaţie şi mai puţin către maşină.
Un tip de date este caracterizat prin mulţimea valorilor pe care le pot lua
obiectele aferente şi prin mulţimea operaţiilor care le sunt aplicabile.
Abstractizarea presupune conferirea caracterului de generalitate pentru
operaţiile şi funcţiile limbajului (în sensul apropierii de aplicaţie şi de
îndepărtare de maşină). Tipizarea reprezintă alături de ascundere o latură a
abstractizării. Ascunderea presupune transparenţa în ceea ce priveşte folosirea
registrelor şi a locaţiilor de memorie precum şi a transferurilor interne.
Vizibilitatea precizează zonele din program în care o entitate
identificabilă printr-un nume este vizibilă, respectiv poate fi modificată.
 Structurile de date (SD) pot fi simple, compuse sau dinamice.
SD simple sunt tipurile de date care nu au componente, valorile lor fiind
unităţi elementare fără structură internă analizabilă (exemple: real, întreg, logic,
caracter).
Un rol important îl deţin tipurile de enumerare definite de operator prin
indicarea tuturor valorilor tipului. Pornind de la tipul enumerat de bază se pot
genera:
- tipuri derivate care pot moşteni numai o parte dintre atributele tipului
de bază;
- subtipuri care limitează gama valorilor posibile.
SD compuse sunt tipurile de date cu mai multe componente cu mai
multe componente (exemple: şiruri, matrice, etc.). Acestea pot fi referite atât
Capitolul 4 119
global, cât şi pe componente. Ca SD compuse s-au impus tabloul (care grupează

componente de acelaşi tip) şi articolul (care grupează componente de tipuri
diferite). Prin combinarea celor două tipuri se pot obţine structuri de orice
complexitate.
SD dinamice se caracterizează prin aceea că datele pot fi create şi
distruse în timpul execuţiei. Aceste variabile nu au nume (dacă ar avea s-ar
transforma în variabile statice). Referirea la aceste variabile anonime se face
printr-o variabilă de tip acces a cărei valoare este adresa variabilei referite.
 Structurile de cod (SC) pot fi de tip instrucţiune, bloc sau
procedură.
Instrucţiunile sunt grupate în structuri. Pe lângă structurile de bază
(secvenţă, selecţie, iteraţie) mai există şi structurile adiţionale (cum ar fi
alternativa generală CASE, iteraţia cu test iniţial sau final etc.)
Pot fi evidenţiate şi structuri aferente aplicaţiilor de timp real cum ar fi
structura iterativă cu ieşire condiţionată şi structura iterativă cu un număr
necunoscut de paşi.
Structura de bloc are în vedere abandonarea conceptului program
monolitic împărţit în două secţiuni date şi cod. Structurarea în blocuri prezintă
următoarele avantaje:
- permite construcţia modulară rezultată din proiectarea prin detaliere
succesivă;
- oferă posibilitatea creării de memorie locală printr-o formă restrânsă
de alocare dinamică a memoriei. În acest fel o parte a memoriei se
poate recicla , aceasta fiind rezervată la intrarea în bloc şi eliberată
la ieşirea din acesta;
- permite programatorului să controleze domeniile de definiţie şi de
vizibilitate a datelor.
Procedura reprezintă o secvenţă de operaţii executate în scopul
rezolvării unei probleme date, care poate fi apelată din mai multe module
program. Concepute iniţial pentru a evita repetarea codului procedurile sunt
implicate în limbajele evoluate în structurarea programelor.
În ultimă instanţă un program bine structurat va reprezenta o succesiune
de apeluri de proceduri. Lucrul cu proceduri permite proiectarea prin adâncirea
gradului de detaliere.
O categorie aparte de procedură este reprezentată de funcţie la cărei
definire trebuie precizate numele şi tipul precum şi tipurile variabilelor
implicate.
Capitolul 4 120
 Concurenţa
Programarea concurentă este acel stil de programare care permite
implementarea prelucrării paralele sau pseudoparalele a datelor.
Având în vedere cele două laturi ale concurenţei (paralelismul şi
interacţiunea) LPTR trebuie să ofere instrumente care să ofere posibilitatea
tranziţiei taskurilor între stări şi substări precum şi implementarea operaţiilor
multitasking (excludere mutuală, sincronizare, comunicare).
În programarea concurentă entitatea de bază este taskul care după cum se
ştie se bucură de proprietăţile de indivizibilitate, secvenţialitate, asincronism,
dinamism.
Excluderea mutuală prezentată pe larg în capitolul precedent presupune
interzicerea execuţiei paralele a secţiunilor critice referitoare la o aceiaşi resursă.
LPTR trebuie să asigure implementarea acestei operaţii prin semafoare, cutii
poştale, mesaje de trecere, monitoare , etc.
Sincronizarea taskurilor presupune în primul rând o coordonare a
execuţiei acestora în raport cu timpul sau cu evenimente externe. LPTR trebuie
să ofere mijloace care să implementeze nu numai corelarea cu timpul sau cu
evenimente cât şi stabilitatea acestei relaţii.
De asemenea trebuie create posibilităţi pentru realizarea sincronizării
implicite sau explicite sau cu timpul după cum urmează:
- sincronizarea implicită specifică realizării disciplinei de acces la o
resursă comună care se partajează;
- sincronizarea explicită conform căreia un program trebuie să aştepte
(durată impredictibilă) până când altul va finaliza o anumită
activitate;
- sincronizarea cu timpul presupune că evenimentele cu care se
realizează sincronizarea sunt impulsurile ceasului de timp real.
Comunicarea între taskuri se poate realiza în două moduri şi anume:
- prin transfer efectiv, caz în care datele se copiază dintr-o zonă de
memorie a unui task, într-o zonă de memorie a celuilalt şi care se
realizează prin canale de comunicaţie;
- prin partajare, caz în care datele se depozitează într-o zonă
accesibilă ambelor taskuri, şi care se realizează printr-o zonă
comună de memorie.
 Programarea la nivel fizic

Acest stil de programare este aplicabilă în primul rând pentru realizarea
operaţiilor de intrare-ieşire, şi se justifică prin:
Capitolul 4 121
- realizarea lejeră a interactivităţii între taskuri;

- diversitatea perifericelor care necesită realizarea de module de control
de către programator, module care pot necesita prelucrări apropiate
de nivelul maşină;
- scăderea timpului de aşteptare pentru realizarea operaţiilor de intrare
– ieşire.
Primele LPTR au rezolvat această problemă prin inserarea de instrucţiuni
cod maşină între instrucţiuni ale limbajului de asamblare. La limbajele moderne
de nivel înalt apar perfecţionări cum ar fi:
- reprezentarea registrelor prin tipuri de date compuse (tablouri,
articole, mulţimi);
- crearea de mecanisme care să suspende temporar verificările de tip şi
care să permită programarea pe baza reprezentărilor interne.
 Tratarea excepţiilor
Excepţiile reprezintă situaţiile anormale apărute în evoluţia unui
program. Mecanismele de tratare a excepţiilor trebuie să prezinte următoarele
caracteristici:
- simplitate în utilizare;
- să nu încarce procedura de tratare decât la apariţia excepţiei;
- să trateze unitar toate tipurile de excepţii.
 Compilarea separată
Pornind de la modularizarea programelor acest procedeu are în vedere
compilarea separată a fiecărui modul. Unităţile de program (de exemplu
taskurile) se compilează individual, dar cu considerarea pentru verificare a
rezultatelor compilării celorlalte module.
Compilarea separată este justificată , printre altele, de următoarele
aspecte:
- se permite dezvoltarea de aplicaţii complexe pe sisteme cu
disponibilităţi reduse;
- la modificări se vor compila numai modulele în care s-a intervenit.
 Existenţa unităţilor generice

Unităţile generice reprezinte matriţe pentru mulţimi de unităţi de unităţi
de program. Din unităţile generice se obţin unităţile de program propriuzise
(negenerice) prin generare de exemplu (sau instanţiere).
Capitolul 4 122
4.2. Executivul de timp real RTK
RTK reprezintă acronimul de la Real Time Kernel – executiv de timp

real dezvoltat de On Time Company [www.on-time.com ]. Motivaţia prezentării
executivului în prezentul curs constă în faptul că implementează cele mai
importante instrumente ale tratării operaţiilor multitasking şi anume
semafoarele, cutiile poştale şi mesajele de trecere. De asemenea executivul
oferă posibilitatea înţelegerii conceptului de task şi urmărirea evoluţiei
taskurilor.
4.2.1. Caracteristicile executivului RTK
RTK reprezintă a fost dezvoltat pentru a oferi facilităţi de timp real1
sistemului de operare MS-DOS. În acest context RTKernel reprezintă un
planificator multitasking de timp real pentru acest sistem de operare. Încă de la
apariţia sa nucleul a constituit un puternic suport pentru dezvoltarea software a
aplicaţiilor de conducere a proceselor rulabile pe calculatoare DOS şi ulterior pe
sisteme înglobate dedicate2.
RTK are o construcţie compactă care necesită spaţii modeste de memorie
(în jur de 16 KBytes pentru cod şi 6 KBytes pentru date) şi oferă
programatorului instrumentele de bază necesare dezvoltării unor aplicaţii
eficiente de timp real.
Între caracteristicile sale importante sunt de menţionat următoarele:
 poate opera cu un număr nelimitat de taskuri;
 taskurilor li se pot asocia priorităţi, care asigură o gestionare a
comportării acestora;
 prioritatea reprezintă un număr natural cuprins între 1 şi 643;
 există posibilitatea ca două sau mai multe taskuri să deţină aceiaşi
prioritate;
 timpul de comutare a stării taskurilor este în jur de 6 microsecunde;
 comutările între stări se pot realiza la orice moment de timp;
 pune la dispoziţia programatorului semafoare, cutii poştale şi mesaje
de trecere pentru tratarea operaţiilor multitasking;
 nucleul conţine drivere pentru ecran, tastatură, port serial, port
paralel şi reţea.
1
Se are în vedere dezvoltarea de facilităţi destinate implementării execuţiei pseudoparalele a taskurilor.
2
Embedded systems
3
P1< P2<….< P64
Capitolul 4 123
4.2.2. Taskuri sub RTK

În context RTK un task reprezintă o funcţie C/C++ sau procedură Pascal
fără parametri4. La un task RTK variabilele locale sunt alocate pe o stivă proprie.
Existenţa acestei stive permite apelarea simultană a unei funcţii din mai multe
taskuri, cu alte cuvinte nu există probleme cu reentranţa5. În ceea ce priveşte
accesarea variabilelor globale nu există restricţii. În figura 4.1 se prezintă
structura unei aplicaţii RTK destinată să ruleze sub sistemul de operare MS-DOS.
Fig. 4.1. Structura unei aplicaţii RTK.

.
După cum s-a arătat nu există o limitare în ceea ce priveşte numărul
taskurilor utilizator, însă este obligatorie prezenţa unui task principal (main
task), care se creează la iniţializarea nucleului.
Taskurile RTK sunt taskuri interactive, acestea evoluând conform celor
evidenţiate în capitolul 2 într-un spaţiu al stărilor.
Un task RTK se poate găsi într-una dintre următoarele stări6:
 Current;
 Ready;
 Suspended;
 Blocked;
 Delaiyng;
 Timed,
între care pot avea loc tranziţiile potrivit grafului ilustrat în figura 4.2.
4
În cele ce urmează se vor face referiri numai la varianta de RTK bazată pe utilizarea limbajului C.
5
Reentranţa reprezintă proprietatea unei funcţii de a putea fi executată simultan de către mai multe
taskuri utilizator.
6
Stările Blocked şi Timed mai pot avea şi substări care vor fi evidenţiate la prezentarea funcţiilor
specifice.
Capitolul 4 124
 Starea Current corespunde stării Execuţie din prima abordare,

respectiv substării Execuţie din a doua abordare. Sub RTK un singur task se
poate găsi la un moment dat în această stare. Practic taskul aflat la un moment
dat în starea Current deţine la respectivul moment controlul unităţii centrale de
procesare (UCP). Dacă nici un task utilizator nu este planificat pentru execuţie,
controlul UCP este deţinut de Idle Task creat la iniţializarea RTKernel.
Fig. 4.2. Graful de tranziţie a taskurilor în RTK.
După cum se observă din figura 4.2, în starea Current se poate ajunge
numai din starea Ready, în timp ce din starea Current pot fi efectuate tranziţii în
toate celelalte stări.
În ceea ce priveşte planificarea pentru execuţie a taskurilor, aceasta se
poate face în mod preemptiv sau cooperativ, modul implicit fiind cel cooperativ.
Modul preemptiv (preemptive scheduling) corespunde întreruperii periodice a
taskului aflat în execuţie şi transferul controlului către un task aflat în starea
Ready. Acest mod elimină posibilitatea acaparării procesorului de către un
singur task. Procedeul mai este cunoscut şi ca time-slice multitasking
(multitasking cu tranşe de timp)7. Modul cooperativ (cooperative multitasking)
presupune cedarea controlului procesorului de către taskul current către un alt
task aflat în starea Ready.
 Starea Suspended corespunde stării Creat din prima abordare,
respectiv stării inactive din a doua abordare. Un task suspendat nu poate fi rulat
7
Pentru stabilirea tranşei de timp se apelează funcţia RTKTimeSlice din repertoriul de
instruc iuni al RTKernel.
Capitolul 4 125
întrucât a fost stopat prin funcţia RTKSuspend. Taskul poate redeveni rulabil
dacă asupra sa se execută funcţia RTKResume8
 Un task aflat în starea Blocked nu poate fi executat întrucât aşteaptă
producerea unui eveniment extern cum ar fi: un semnal de la un semafor,
sosirea unui mesaj într-o cutie poştală, etc. Un asemenea task devine Ready
după ce evenimentul aşteptat s-a produs.
 Starea Delaying corespunde unui task care a cedat voluntar
controlul procesorului pentru un anumit timp, prin execuţia unei funcţii
RTKDelay9. Tranziţia Delaying – Ready se realizează după trecerea intervalului
de timp specificat prin funcţie.
 Un task se găseşte în starea Timed dacă aşteaptă un anumit timp
specificat producerea unui eveniment (din clasa celor specifice stării Blocked).
Ieşirea din această stare se realizează la producerea evenimentului sau la
expirarea timpului.
Este de remarcat faptul că stările Blocked, Delaying, Timed pot fi
încadrate în starea Blocat din prima abordare, respectiv substarea Blocat
specifică celei de-a doua abordări. Examinând figura 4.2 se observă că tranziţia
în fiecare dintre cele trei stări se poate face din starea Current, ieşirea fiind
numai către starea Ready.
Toate taskurile care nu sunt în starea Current sunt menţinute în cozi10
cum ar fi: coada taskurilor Ready, coada taskurilor care aşteaptă la un semafor,
la o cutie poştală, etc.
4.2.3. Funcţii de iniţializare

Executivul RTK pune la dispoziţia programatorului un număr de 210
funcţii ale căror antete (headere) se găsesc în fişierul rtkernel.h care
trebuie inclus în programul sursă prin directiva de preprocesare
#include "rtkernel.h"
De asemenea trebuie incluse tot printr-o directivă de preprocesare fişierul
cu antetele funcţiilor asociate driverului consolei11 , respectiv
#include "rtkeybrd.h"
8
Cele două funcţii din repertoriul RTKernel vor fi prezentate în secţiunea funcţiilor RTK de
administrare a taskurilor.
9
Funcţia RTKDelay din repertoriul RTKernel va fi prezentate în secţiunea funcţiilor RTK de
gestionare a timpului.
10
Coada (queue) reprezintă o structură de date din care elementele sunt extrase în ordinea introducerii
(administrare FIFO – First Input First Output).
11
În acest context prin driver se înţelege o componentă software care permite sistemului de calcul să
comunice cu un anumit dispozitiv. Dacă în program mai sunt utilizate şi alte dispozitive, în afara
consolei, vor trebui iniţializate şi driverele acestora
Capitolul 4 126
Un program RTKernel conţine funcţii C şi funcţii specifice, acestea din

urmă conţinând prefixul RTK. Pentru execuţie va trebui construit un project C
care să includă codul sursă şi biblioteca rtkth.lib. În cele ce urmează vor fi
prezentate funcţii semnificative care vizează:
- iniţializarea nucleului;
- administrarea taskurilor;
- gestionarea timpului;
- gestionarea semafoarelor;
- gestionarea cutiilor poştale;
- gestionarea mesajelor de trecere.
Din categoria funcţiilor de iniţializare vor fi prezentate cele asociate

nucleului şi driverului asociat consolei.
 Funcţia RTKernelInit iniţializează nucleul RTK şi are următoarea
formă generală
TaskHandle RTKernelInit(unsigned MainPrio); (4.1)
unde MainPrio este o variabilă de tip unsigned care desemnează
prioritatea taskului main.
Pentru a referi taskurile acestora li se pot asocia variabile de mânuire –
handle de tip TaskHandle12. În funcţia (4.1) variabila de tip TaskHandle
este pentru taskul main13.
La execuţia funcţiei (4.1) sunt efectuate, printre altele, următoarele operaţii
importante:
1) iniţializarea structurilor interne de date;
2) verificarea dacă un alt program RTKernel este încărcat (în caz
afirmativ, programul în care se apelează funcţia de iniţializare este
abandonat cu transmiterea unui mesaj de eroare);
3) convertirea funcţiei main în taskul main şi alocarea priorităţii
specificate;
4) crearea taskului Idle 14 şi alocarea priorităţii zero;
5) iniţializarea ceasului intern cu zero.
 Funcţia RTKeybrdInit iniţializează driverul consolei şi are

următoarea formă generală
void RTKeybrdInit(void); (4.2)
12
TaskHandle este un tip de variabilă predefinit în RTKernel
13
Dacă taskul main nu este referit TaskHandle poate lipsi.
14
Taskul Idle se execută atunci când nici un task utilizator nu se află în starea Current.
Capitolul 4 127
Se observă că funcţia (4.2) nu întoarce nici o valoare şi că lista de parametri

a acesteia este vidă.
Exemplul 3.1
În acest exemplu se prezintă utilizarea funcţiilor (4.1) şi (4.2)
-----------------
#define prio_main 3
------------------
TaskHandle handle_main;
-----------------
handle_main= RTKernelInit(prio_main);
RTKeybrdInit();
-----------------
Observaţie
Ieşirea din RTKernel se realizează prin apelarea funcţiei C
exit(0).
4.2.4. Funcţii de administrare a taskurilor

În această secţiune pot fi identificate două categorii de funcţii şi anume:
a) funcţii pentru crearea, terminarea, dezactivarea şi activarea
taskurilor;
b) funcţii care furnizează informaţii privind caracteristicile şi
evoluţia taskurilor.
 Funcţia RTKCreateTask permite crearea unui nou task din alt

task şi are următoarea formă generală
TaskHandle RTKCreateTask(void *TaskCode(void), (4.3)
Unsigned Priority,unsigned Stack, char *Name);
În funcţia de mai sus semnificaţiile notaţiilor din lista de argumente au
semnificaţiile următoare:
- parametrul TaskCode reprezintă o funcţie C care conţine codul ce
urmează a fi executat în noul task;
- parametrul Priority – prioritatea noului task (întreg fără semn);
- parametrul Stack – dimensiunea în octeţi a stivei noului task (întreg fără
semn);
Capitolul 4 128
- parametrul Name – pointer de maximum 15 caractere la numele noului

task.
Funcţia RTKCreateTask întoarce o valoare într-un handle cu ajutorul
căruia va putea fi referit noul task. Dacă în program nu există astfel de referiri
variabila handle poate lipsi.
 Funcţia RTKSuspend permite dezactivarea unui task, respectiv

trecerea sa în starea Suspended şi are următoarea formă generală
void RTKSuspend(TaskHandle Handle); (4.4)
în care parametrul Handle referă taskul care urmează a fi dezactivat
(trecut în starea Suspended). Dacă taskul era deja suspendat , funcţia nu are efect.
 Funcţia RTKResume permite activarea unui task, respectiv

trecerea sa în starea Ready şi are următoarea formă generală
void RTKResume(TaskHandle Handle); (4.5)
în care parametrul Handle referă taskul care urmează a fi activat (trecut în
starea Ready). Dacă taskul nu era suspendat, funcţia nu are efect.
 Funcţia RTKSetPriority, care serveşte la schimbarea priorităţii

taskului referit are următoarea formă generală
void RTKSetPriority(TaskHandle Handle,
unsigned Priority); (4.6)
în care parametrul Handle referă taskul a cărui prioritate se va schimba,
iar Priority reprezintă noua prioritate.
 Funcţia RTKGetTaskState returnează într-o variabilă de tip

TaskState15 starea taskului referit prin Handle şi are următoarea
formă generală
TaskState RTKGetTaskState(TaskHandle Handle); (4.7)
După execuţiei se returnează o valoare care corespunde uneia dintre
stările sau substările în care se gaseşte taskul după cum urmează:
15
Acest tip din RTKernel corespunde tipului enumerat din limbajul C.
Capitolul 4 129
Stare Explicaţie
Ready Task pregătit (aflat în starea Ready)
Current Task în execuţie (aflat în starea Current )
Suspended Task suspendat prin execuţia funcţiei RTKSuspend
Delaying Task în aşteptare după apelarea funcţiei RTKdelay
BlockedWait Task blocat la un semafor după execuţia unei funcţii RTKWait
TimedWait Task în aşteptare temporizată la un semafor după execuţia
unei funcţii RTKWaitTimed
BlockedPut Task blocat la depunerea unui mesaj într-o cutie poştală plină
după execuţia unei funcţii RTKPut
BlockedGet Task blocat la extragerea unui mesaj dintr-o cutie poştală
goală după execuţia unei funcţii RTKGet
TimedPut Task în aşteptare temporizată pentru depunerea unui mesaj
într-o cutie poştală plină după execuţia unei funcţii
RTKPutTimed
TimedGet Task în aşteptare temporizată pentru extragerea unui mesaj
dintr-o cutie poştală goală după execuţia unei funcţii
RTKGetTimed
BlockedSend Task blocat în trimiterea unui mesaj pe care destinatarul nu îl
poate recepţiona, după execuţia unei funcţii RTKSend
BlockedReceive Task blocat în aşteptarea unui mesaj pe care expeditorul încă
nu l-a trimis, după execuţia unei funcţii RTKReceive
TimedSend Task în aşteptare temporizată pentru transmiterea unui mesaj,
după execuţia unei funcţii RTKSendTimed
TimedReceive Task în aşteptare temporizată pentru recepţia unui mesaj,
după execuţia unei funcţii RTKReceiveTimed
Deadlocked Task blocat în transmiterea unui mesaj către un task
dezactivat (interblocare)
Illegal Argumentul Handle se referă la un task inexistent
Terminated Task terminat ca urmare a execuţiei unei funcţii
RTKTerminate
 Funcţia RTKGetTaskPrio, returnează într-o variabilă de tip

unsigned prioritatea taskului referit prin handle şi are forma
generală de mai jos
unsigned RTKGetTaskPrio(TaskHandle Handle); (4.8)
Capitolul 4 130
 Funcţia RTKGetTaskStack, are forma generală de mai jos

unsigned RTKGetTaskStack(TaskHandle Handle); (4.9)
şi returnează într-o variabilă de tip unsigned spaţiul liber din stiva taskului
referit prin handle .
Exemplul 3.2
În acest exemplu se prezintă utilizarea funcţiilor (4.3)…(4.9)
-----------------
------------------
TaskHandle Handle_A;
TaskState State_A;
unsigned New_prio,Task_prio,Free_stack;
-----------------
Handle_A=RTKCreateTask(TaskA,5,1024," Task_A");
-----------------
RTKSuspend(Handle_A);
State_A=RTKGetTaskState(Handle_A);
RTKResume(Handle_A);
-----------------
Task_prio=RTKGetTaskPrio(Handle_A);
New_prio=Task_prio+2;
RTKSetPriority(Handle_A,New_prio);
Free_stack;= RTKGetTaskStack(Handle_A);
-----------------
4.2.5. Funcţii de gestionare a timpului

După cum s-a menţionat în capitolul precedent timpul prezintă o mare
importanţă în sistemele de timp real. În acest context, executivul RTK menţine
un ceas intern care poate fi setat sau citit. În RTK unitatea de măsură pentru
timp este timer tick. O cuantă de timp, respectiv un timer tick are aproximativ 55
ms. Această valoare rezultă ţinând cont că timerul hardware al unui PC
generează de 216 întreruperi pe oră ceea ce reprezintă aproximativ 18,2
întreruperi/secundă care corespunde unei perioade de aproximativ 55 ms.
Pentru gestionarea timpului RTK utilizează tipurile Time – pentru a
memora momente şi Duration – pentru a memora durate, ambele de tipul
unsigned long. După cum s-a arătat, la iniţializarea executivului prin funcţia
RTKernelInit ceasul intern este iniţializat cu zero.
În continuare vor fi prezentate funcţiile uzuale RTK pentru gestionarea
timpului.
Capitolul 4 131
 Funcţia RTKSetTime care poate fi utilizată pentru setarea ceasului

intern la cu o valoare dorită are forma generală
void RTKSetTime(Time NewTime); (4.10)
în care parametrul NewTime de tipul Time reprezintă valoarea exprimată în ticks
la care va fi setat ceasul 16.
 Funcţia RTKGetTime care poate fi utilizată pentru citirea ceasului

intern într-o variabilă de tip Time are forma generală
Time RTKGetTime(void); (4.11)
Exemplul 3.3
În acest exemplu se prezintă utilizarea funcţiilor (4.10) şi (4.11)
-----------------
------------------
Time Set_clock_time,Clock_time;
-----------------
Clock_time =Time RTKGetTime();
Set_clock_time=25468;
RTKSetTime(Set_clock_time);
-----------------
 Funcţia RTKDelay blochează taskul apelant pentru un interval
specificat printr-o variabilă de tip Duration şi are forma generală
void RTKDelay(Duration Ticks); (4.12)
în care numărul de cuante Ticks se obţine cu relaţia
18 ∆ , (4.13)
unde ∆t reprezintă intervalul de temporizare exprimat în secunde.
 Funcţia RTKDelaUntil permite execuţia taskului apelant până la

un moment impus de numărul de Ticks care figurează ca
parametru al funcţei şi are forma generală
void RTKDelayUntil(Time Ticks); (4.14)
16
La iniţializarea RTK în cadrul funcţiei RTKernelInit se execută funcţia RTKSetTime(0);
Capitolul 4 132
Exemplul 3.3
În acest exemplu se prezintă un caz de utilizare a funcţiei
RTKDelay într-un sistem multitasking destinat afişării cu periodicitate de o
secundă a datei şi orei. Sistemul este constituit din taskurile TaskA şi main.
 Taskul TaskA se execută în buclă infinită şi apelează cu
periodicitate de o secundă funcţia afordata care achiziţionează şi tipăreşte
elemente ale timpului sistem şi anume zi, lună, an, oră, minut, secundă.
Aceste elemente se preiau în variabilele d şi t care sunt de tipul struct date,
respectiv struct time din DOS. Afişarea se realizează la nivel de caracter în
regim alfanumeric în care ecranul este văzut ca o matrice cu 80 de coloane
şi 25 de linii, potrivit figurii 3.3.
x
1 2 80
1
25
Fig. 4.3. Sectorizarea ecranului în regim alfanumeric
Poziţionarea cursorului în coordonate absolute se realizează cu

instrucţiunea C gotoxy(x,y), unde parametrii x şi y au semnificaţiile din
figura 4.3.
 Taskul main conţine o primă secţiune de declaraţii şi iniţializări
şi o a doua secţiune în buclă infinită destinată supravegherii tastaturii. La
apăsarea unei taste codul ASCII al acesteia este preluat şi transferat într-o
variabilă de tip caracter cu ajutorul instrucţiunii
char RTKGetCh(); (4.15)
La apăsarea tastei E se iese din program, acţionarea altei taste
rămânând fără efect
//
// Program demonstrativ utilizare funcţie RTKDelay
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
Capitolul 4 133
#include <stdlib.h>
//
struct date d;
struct time t;
//
afordata() //functie preluare si tiparire data si ora
{
getdate(&d); // preia data in variabila d
gettime(&T); // preia timpul in variabila t
gotoxy(55,3); //pozitioneaza cursorul
//se tiparesc: ziua, luna anul
cprintf("%02d-%02d-%4d",d.da_day,d.da_mon,d.da_year);
// se tiparesc: ora, minutul, secunda
cprintf(" 02d-%02d-%02d",t.ti_hour,t.ti_min,t.ti_sec);
}
//
//
TaskA() //task temporizare
{
for(;;) //bucla for infinita
{
RTKDelay(18); //temporizare o secunda
afordata(); //apelare functie afordata
} //sfarsit for
} //sfarsit TaskA
//
//
main() //task main
{
char c;
RTKernelInit(3); //initializare RTK
clrscr(); //stergere ecran
gotoxy(5,8); //pozitionare cursor
cprintf("E - Iesire");
RTKeybrdInit(); //initializare driver consola
RTKCreateTask(TaskA,5,1024,"Task A"); //creare Task A
//
{
c=RTGetCh(); //supraveghere tastatura
if(c==’E’) //testare fata de E
exit(0); //iesire
} //sfarsit for
} //sfarsit main
Capitolul 4 134
4.2.6. Funcţii de gestionare a semafoarelor

După cum s-a văzut în capitolul precedent semaforul reprezintă o
importantă resursă pentru realizarea tuturor celor trei operaţii fundamentale
multitasking.
În context RTK un semafor poate fi privit ca un numărător de evenimente
al cărui conţinut nu poate fi niciodată negativ. Echivalenţa cu definiţia generală
este imediată întrucât o înscriere de eveniment este asociată unei operaţii de tip
V – incrementare, iar o extragere de eveniment unei operaţii de tip P –
decrementare.
Din punctul de vedere al tipului, în RTK sunt recunoscute semafoarele de
tip binar şi întreg. Unui semafor binar i se pot asocia valorile 0 şi 1, iar unuia
întreg una dintre valorile 0, 1,…,65535.
Un semafor poate fi folosit în oricât de multe taskuri, iar într-un task pot fi
utilizate oricât de multe semafoare. Cu alte cuvinte nu există limitări în ceea ce
priveşte numărul te taskuri care pot utiliza un semafor sau al numărului de
semafoare care poate fi utilizat într-un task.
Între funcţiile RTK de gestionare a semafoarelor o importanţă aparte
prezintă cele de iniţializare şi de implementare a operaţiilor de incrementare şi
decrementare. Este de menţionat faptul că în RTK, pentru ca o variabilă să fie
tratată ca un semafor, aceasta trebuie declarată ca fiind de tipul Semaphore.
 Funcţia RTKCreateSemaphore permite crearea şi iniţializarea
unui semafor şi are următoarea formă generală
Semaphore RTKCreateSemaphore(SemaType Typ,
unsigned InitialValue, char *Name); (4.16)
- parametrul Typ de tipul SemaType indică tipul semaforului şi anume
Binary pentru tipul binar, respectiv Counting pentru tipul întreg;
- parametrul InitialValue (întreg fără semn) indică valoarea iniţială
a noului semafor (0 sau 1 pentru un semafor binar sau una dintre valorile
0, 1, …,65535 pentru un semafor general
- parametrul Name – pointer de maximum 15 caractere la numele noului
semafor, care este afişat de funcţia RTKTaskInfo şi de mesajele de
eroare.
Funcţia RTKCreateSemaphore întoarce o valoare într-o variabilă de
tip Semaphore cu ajutorul căruia va putea fi referit noul semafor.
Capitolul 4 135
Observaţie
Pentru funcţia de iniţializare este acceptată şi forma RTKCreateSema.
 Funcţia RTKSemaValue permite returnarea într-o variabilă de tip

întreg fără semn, a numărului de evenimente memorat într-un
semafor şi are următoarea formă generală
unsigned RTKSemaValue(Semaphore S); (4.17)

în care S indică semaforul referit.
 Funcţia RTKSignal memorează un eveniment într-un semafor şi
are următoarea formă generală
void RTKSignal(Semaphore S); (4.18)
Potrivit celor prezentate în capitolul 2 prin funcţia RTKSignal se asigură
implementarea incrementării semaforului S, respectiv a operaţiei V(S).
 Funcţia RTKWait retrage (şterge) un eveniment dintr-un semafor
şi are următoarea formă generală
void RTKSWait(Semaphore S); (4.19)
Potrivit celor prezentate în capitolul 2 prin funcţia RTKWait se asigură
implementarea decrementării semaforului S, respectiv a operaţiei P(S).
Dacă nici un eveniment nu este disponibil (respectiv dacă S=0) taskul
apelant trece în starea BlockedWait. Taskul va rămâne în această stare până
când în semaforul S se va înscrie un eveniment, respectiv până când se va
executa o funcţie RTKSignal(S);
 Funcţia RTKWaitCond retrage (şterge) un eveniment dintr-un
semafor, numai dacă un asemenea eveniment este disponibil şi
are următoarea formă generală
bool RTKSWaitCond(Semaphore S); (4.20)
Potrivit celor prezentate în capitolul 2 prin funcţia RTKWait se asigură
implementarea decrementării semaforului S, respectiv a operaţiei P(S).
Dacă nici un eveniment nu este disponibil (respectiv dacă S=0) taskul
apelant nu se blochează, respectiv nu trece în starea BlockedWait.
Capitolul 4 136
În situaţia în care funcţia se execută, respectiv semaforul S se

decrementează, în variabila logică de tip bool se înscrie valoarea logică
True, altfel în aceiaşi variabilă se va înscrie valoarea False.
 Funcţia RTKWaitTimed retrage (şterge) un eveniment dintr-un

semafor, numai dacă un asemenea eveniment este disponibil sau
devine disponibil într-un interval de timp precizat printr-o
variabilă de tip Duration şi are următoarea formă generală
bool RTKSWaitTimed(Semaphore S,
Duration Timeout ); (4.20)
Potrivit celor prezentate în capitolul 2 prin funcţia RTKWait asigură în
general implementarea decrementării semaforului S, respectiv a operaţiei
P(S). Dacă nici un eveniment nu este disponibil (respectiv dacă S=0) taskul
apelant trece în starea TimedWait pentru un interval de timp Timeout.
În situaţia în care funcţia se execută, respectiv semaforul S se
decrementează, în variabila logică de tip bool se înscrie valoarea logică
True, altfel în aceiaşi variabilă se va înscrie valoarea False.
Exemplul 3.4
În acest exemplu se prezintă un caz de utilizare a semafoarelor
pentru realizarea sincronizării taskurilor. Sistemul este constituit din
taskurile TaskA, TaskB şi main.
 Taskul TaskA are aceleaşi caracteristici şi funcţionalitate ca în
exemplul 3.3.
 Taskul TaskB este blocat la semaforul binar SB iniţializat cu
zero în taskul main. În momentul când din acest task se execută o funcţie
RTKSignal(SB); se deblochează TaskB pentru 10 secunde. Pe durata
deblocării pe ecran se afişează numărul de secunde trecute. După trecerea
celor 10 secunde în TaskB se execută funcţia RTKWait(SB), ceea ce va
determina revenirea TaskB în starea Blocked. De asemenea pe ecran se
afişează starea în care se găseşte TaskB, adică BLOCAT respectiv
EXECU IE.
 Taskul main conţine o primă secţiune de declaraţii şi iniţializări
şi o a doua secţiune în buclă infinită destinată supravegherii tastaturii. La
apăsarea tastei B se execută funcţia RTKSignal(SB), iar la apăsarea
tastei E se iese din program. Ca şi în exemplul precedent, acţionarea altei
taste rămâne fără efect.
Capitolul 4 137
//
// Program demonstrativ utilizare semafoare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
Semaphore SB;
struct date d;
struct time t;
//
//
{
{
} //sfarsit for
} //sfarsit TaskA
//
//
TaskB() //task sincronizat
{
int i;
{
gotoxy(5,10);
cprintf("BLOCAT ");
RTKWait(SB), //decrementare semafor SB
gotoxy(5,10);
cprintf("EXECUTIE");
for(i=0;i<=9;i++) //bucla for in 10 pasi
{
RTKdelay(18); //temporizare o secunda
gotoxy(15,10);
cprintf("%d",i);//tiparire secunde trecute
} //sfarsit for finit
} //sfarsit for infinit
} //sfarsit TaskB
//
//
main() //task main
{
char c;
Capitolul 4 138

cprintf("B – Executie taskB E - Iesire");
// Initializare semafor SB
SB=RTKCreateSema(Binary,0,"Semafor B");
// creare TaskA si TaskB
RTKCreateTask(TaskA,5,1024,"Task A");
RTKCreateTask(TaskB,5,1024,"Task B");
//
{
if(c==’B’) //testarea fata de B
RTKSignal(SB); //incrementeaza semafor SB
exit(0); //iesire
} //sfarsit for
} //sfarsit main
4.2.7. Funcţii de gestionare a cutiilor poştale
O cutie poştală (Mailbox) reprezintă o zonă de memorie (buffer de date)

care poate stoca un număr prefixat de mesaje. În RTKernel mesajele pot avea
orice dimensiune în condiţiile configurării unei cutii poştale până la maximum
64 KB.
Taskurile pot depune mesaje în sau pot extrage mesaje din cutii poştale
în condiţii reglementate prin funcţii RTK. Aceste funcţii tratează cutia poştală ca
fiind organizată ca o coadă (queue) şi în consecinţă administrată potrivit
strategiei FIFO17.
Taskul în care se execută o funcţie de depunere într-o cutie poştală care
este plină se blochează până când se creează spaţiu. De asemenea se blochează
taskul în care se execută o funcţie de extragere a unui mesaj dintr-o cutie poştală
goală.
Nu sunt limitări în ceea ce priveşte numărul de cutii poştale care pot fi
utilizate de către un task şi nici a numărului de taskuri în care se poate utiliza o
cutie poştală.
În continuare vor fi prezentate principalele funcţii RTK ce privesc
gestionarea cutiilor poştale.
 Funcţia RTKCreateMailbox permite crearea şi iniţializarea unei
cutii poştale şi are următoarea formă generală
17
FIFO – First Input First Output - strategie potrivit căreia extragerea din coadă se face în ordinea
introducerii.
Capitolul 4 139
Mailbox RTKCreateMailbox(unsigned DataLen,

unsigned Slots, char *Name); (4.21)
- parametrul DataLen de tipul unsigned indică lungimea în octeţi a
mesajelor care pot fi înscrise în cutia poştală;
- parametrul Slots, tot de tipul unsigned precizează numărul
maxim de mesaje care pot fi stocat în cutia poştală;
- Name - pointer de maximum 15 caractere la numele noii cutii poştale,
care este afişat de funcţia RTKTaskInfo şi de mesajele de eroare.
Funcţia RTKCreateMailbox întoarce o valoare într-o variabilă de tip
Mailbox cu ajutorul căreia va putea fi referită noua cutie poştală. semafor.
 Funcţia RTKMessages permite returnarea într-o variabilă de tip

întreg fără semn, a numărului de mesaje memorate într-o cutie
poştală şi are următoarea formă generală
unsigned RTKMessages(Mailbox Box); (4.22)
în care parametrul Box este asociat cutiei poştale referite.
 Funcţia RTKClearMailbox realizează ştergerea conţinutului unei

cutii şi are următoarea formă generală
void RTKClearMailbox(Mailbox Box); (4.23)
în care parametrul Box este asociat cutiei poştale referite.
 Funcţia RTKPut care permite depunerea unui mesaj într-o cutie
poştală are următoarea formă generală
void RTKPut(Mailbox Box, void *Data); (4.24)
în care variabila Box de tipul Mailbox referă cutia poştală în care se face
depunerea, iar *Data este un pointer la data care se depune.
 Funcţia RTKGet care permite preluarea unui mesaj dintr-o cutie
poştală are următoarea formă generală
void RTKget(Mailbox Box, void *Data); (4.25)
unde variabila Box de tipul Mailbox referă cutia poştală din care se face
extragerea, iar *Data este un pointer la data în care se depune mesajul extras din
cutia poştală.
Capitolul 4 140
Observaţie
Funcţiile (4.24) şi (4.25) sunt de tipul necondiţionat, întrucât acestea
blochează taskul în care sunt apelate până la eliminarea situaţiei de excepţie
(CP plină, în cazul funcţiei RTKPut, respectiv cutie poştală goală în cazul
instrucţiunii RTKGet. Blocarea presupune tranziţia într-una dintre stările
BlockedPut sau după caz, BlockedGet.
 Funcţia RTKPutCond asigură depunerea unui mesaj într-o cutie
poştală, numai dacă există spaţiu disponibil. Forma generală a
funcţiei este cea de mai jos,
bool RTKPutCond(Mailbox Box, void *Data); (4.26)
în care Box reprezintă cutia poştală referită, iar *Data este un pointer la data
care se depune.
Execuţia acestei funcţii nu determină blocarea taskului apelant în situaţia
în care cutia poştală referită este plină. În acest caz, în variabila logică de tip
bool se înscrie valoarea False care atestă faptul că funcţia nu s-a executat. În caz
contrar, respectiv la execuţia cu succes a funcţiei, în aceiaşi variabilă se va
înscrie valoarea True.
 Funcţia RTKGetCond permite preluarea unui mesaj dintr-o cutie
poştală, numai dacă un asemenea mesaj este disponibil. Forma
generală a funcţiei este cea de mai jos,
bool RTKGetCond(Mailbox Box, void *Data); (4.27)
în care Box reprezintă cutia poştală referită, iar *Data este un pointer la data
care se depune.
în care în cutia poştală referită nu există mesaje disponibile. În acest caz, în
variabila logică de tip bool se înscrie valoarea False care atestă faptul că funcţia
nu s-a executat, respectiv nu a fost preluat un mesaj. În caz contrar, respectiv la
execuţia cu succes a funcţiei (preluarea unui mesaj), în aceiaşi variabilă se va
înscrie valoarea True.
 Funcţia RTKPutTimed asigură depunerea unui mesaj într-o cutie

poştală, numai dacă există spaţiu disponibil, sau se creează
spaţiu într-un interval de timp precizat printr-o variabilă de tip
Duration. Funcţia are forma generală de mai jos,
bool RTKPutTimed(Mailbox Box, void *Data,
Duration Timeout); (4.28)
în care Box reprezintă cutia poştală referită, *Data este un pointer la data care se
depune iar Timeout intervalul de timp în care se aşteaptă crearea de spaţiu.
Capitolul 4 141

în care cutia poştală referită are spaţiu disponibil. În caz contrar taskul este
trecut în starea TimedPut pentru un timp care nu poate depăşi Timeout.
Dacă s-a putut înscrie un mesaj în Box imediat sau în intervalul Timeout
execuţia funcţiei se consideră reuşită, iar în variabila de tip bool se va înscrie
valoarea logică True. În caz contrar, respectiv la neexecuţia cu succes a funcţiei,
în aceiaşi variabilă se va înscrie valoarea False.
 Funcţia RTKGetTimed facilitează extragerea unui mesaj dintr-o

cutie poştală, numai dacă un asemenea mesaj există sau apare
într-un interval de timp precizat printr-o variabilă de tip
Duration. Funcţia are furmătoarea forma generală ,
bool RTKGetTimed(Mailbox Box, void *Data,
Duration Timeout); (4.29)
în care Box reprezintă cutia poştală referită, *Data este un pointer la data care se
depune iar Timeout intervalul de timp în care se aşteaptă crearea de spaţiu.
în care în cutia poştală există cel puţin un mesaj. În caz contrar taskul este
trecut în starea TimedGet pentru un timp care nu poate depăşi Timeout.
Dacă s-a putut prelua un mesaj în Box imediat sau în intervalul Timeout
valoarea logică True. În caz contrar, respectiv la imposibilitatea preluării unui
mesaj (respectiv neexecuţia cu succes a funcţiei), în aceiaşi variabilă se va
înscrie valoarea False.
Exemplul 3.5
În acest exemplu se prezintă utilizarea unei cutii pentru realizarea
sincronizării taskurilor. Sistemul este constituit din taskurile TaskA, TaskB
şi main.
exemplele 3.3 şi 3.4.
 Taskul TaskB este blocat pentru aşteptarea sosirii unui mesaj în
cutia poştală CP, iniţializată în taskul main. În momentul când din acest
task se execută asupra cutiei poştale CP o funcţie RTKPut referitoare la
codul unei taste apăsate, TaskB se deblochează. După deblocare se execută
o funcţie RTKGet prin care se preia mesajul (care constă din codul unui
caracter) din CP. Pentru vizualizarea caracterului recepţionat, acesta se
tipăreşte. După această operaţie TaskB trece din nou în starea BlokedPut.
Capitolul 4 142
De asemenea pe ecran se afişează starea în care se găseşte TaskB, adică B

aşteaptă la CP respectiv Sosit mesaj.
 Ca şi în exemplele precedente taskul main conţine o primă
secţiune de declaraţii şi iniţializări şi o a doua secţiune în buclă infinită
destinată supravegherii tastaturii. La apăsarea oricărei taste, alta decât E,
se execută o funcţia RTKPut, prin care codul tastei apăsate este depus în
CP. În ceea ce priveşte apăsarea tastei E, această acţiune va determina
ieşirea din program. Ca şi în exemplul precedent, acţionarea altei taste
rămâne fără efect.
//
// Program demonstrativ utilizare cutii postale
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
#define slots 1
//
Mailbox CP;
struct date d;
struct time t;
//
//
{
{
} //sfarsit for
} //sfarsit TaskA
//
//
TaskB() //task sincronizat
{
char i;
{
gotoxy(5,10);
cprintf("B asteapta la CP ");
RTKGet(CP,&i); //preia din CP si depune in i
RTKdelay(18); //temporizare o secunda
gotoxy(5,10);
//tipareste caracterul din i
Capitolul 4 143
cprintf("Sosit mesaj %c ",i);

} //sfarsit TaskB
//
//
main() //task main
{
char c;
cprintf("Orice tasta - mesaj E - Iesire");
// Initializare cutie postala CP
CP=RTKCreateMailbox(2,slots,"CP");
RTKCreateTask(TaskB,5,1024,"Task B");
//
{
gotoxy(5,9);
cprintf("Transmis din main mesajul ");
gotoxy(41,9);
cprintf("%c"); //tipareste caracterul tastat
exit(0); //iesire
RTKPut(CP,&c); //altfel depune c in CP
} //sfarsit for
} //sfarsit main
4.2.8. Funcţii de gestionare a mesajelor
Mesajul de trecere ( message passing) reprezintă, alături de cutiile

poştale o altă facilitate de comunicare între taskuri oferită de executivul RTK. În
cazul mesajelor, spre deosebire de cutiile poştale, în taskul expeditor trebuie
referit taskul destinatar prin intermediul variabilei taskhandle asociate. În ceea
ce priveşte taskul destinatar, în cazul acestuia nu trebuie nominalizat taskul
expeditor. Reamintim ca în cazul cutiei poştale la depunerea unui mesaj nu
trebuie precizat destinatarul.
O altă diferenţă între cele două modalităţi de comunicare constă în
absenţă unui buffer de date în cazul mesajelor. În aceste condiţii în RTK nu
există un tip predefinit pentru mesajele de trecere, ca în cazul semafoarelor şi
cutiilor poştale.
Capitolul 4 144
Având în vedere trăsăturile de mai sus rezultă că pentru gestionarea

mesajelor există numai funcţii de transmitere şi recepţie. Ca şi în cazurile
semafoarelor şi cutiilor poştale aceste instrucţiuni pot fi necondiţionate,
condiţionate şi temporizate.
 Funcţia RTKSend asigură transmiterea unui mesaj către un task
destinatar şi are forma generală de mai jos
void RTKSend(TaskHandle Receiver,
void *Data); (4.30)
în care parametrul Receiver este un handler al taskului receptor, iar *Data
reprezintă un pointer la data care se depune.
Mesajul va fi transmis dacă taskul receptor este în aşteptare pe una dintre
funcţiile RTKReceive sau RTKReceiveTimed18. În caz contrar taskul emiţător
trece pentru un interval de timp nedeterminat în starea BlockedSend. Ieşirea din
această stare se va produce în momentul în care în taskul destinatar se va
executa una dintre cele două funcţii de mai sus.
 Funcţia RTKReceive permite recepţionarea unui mesaj de la un

task receptor şi are forma generală de mai jos
void RTKReceive(void *Data,
unsigned DataLen); (4.31)
în care *Data reprezintă un pointer la data care se depune, iar DataLen
lungimea în octeţi a mesajului aşteptat.
Mesajul va fi imediat recepţionat dacă un task emiţător este în aşteptare
pe una dintre funcţiile RTKSend sau RTKSendTimed19. În caz contrar taskul
receptor trece pentru un interval de timp nedeterminat în starea BlockedReceive.
Ieşirea din această stare se va produce în momentul în care într-un task emiţător
se va executa una dintre cele două funcţii de mai sus, pe handlerul
destinatarului.
 Funcţia RTKSendCond asigură transmiterea datelor altui task cu
condiţia ca taskul receptor să fie gata să accepte imediat datele.
Dacă această condiţie nu este îndeplinită se continuă execuţia
taskului transmiţător fără a se transmite datele. Forma generală a
funcţiei este următoarea
Bool RTKSendCond(TaskHandle Receiver,
void *Data); (4.32)
18
Respectiv se găse te în una din stările BlockedReceive sau TimedReceive
19
Respectiv se găse te în una din stările BlockedSend sau TimedSend
Capitolul 4 145
în care parametrul Receiver este un handler (variabilă de tip TaskHandle) al

taskului receptor, iar *Data este un pointer la datele care se transmit.

în care datele n-au putut fi transmise. În acest caz, în variabila logică de tip bool
se înscrie valoarea False care atestă faptul că funcţia nu s-a executat. În caz
contrar, respectiv la execuţia cu succes a funcţiei RTKSendCond, în aceiaşi
variabilă se va înscrie valoarea logică True.
 Funcţia RTKReceiveCond preluarea datelor de la un alt task, cu
condiţia ca acesta să fie gata să le transmită imediat. Dacă această
condiţie nu este îndeplinită se continuă execuţia taskului receptor
fără a se prelua datele. Forma generală a funcţiei este următoarea
Bool RTKReceiveCond(void *Data,
unsigned DataLen ); (4.33)
în care *Data este un pointer la datele care se transmit, iar DataLen lungimea
în octeţi a mesajului aşteptat.
în care datele n-au putut fi preluate. În acest caz, în variabila logică de tip bool
se înscrie valoarea False care atestă faptul că funcţia nu s-a executat. În caz
contrar, respectiv la execuţia cu succes a funcţiei RTKreceiveCond, în aceiaşi
variabilă se va înscrie valoarea logică True.
 Funcţia RTKPSendTimed asigură trimiterea unui mesaj, numai

dacă taskul destinatar devine disponibil pentru recepţie într-un
interval de timp precizat printr-o variabilă de tip Duration.
Funcţia are forma generală de mai jos,
bool RTKSendTimed(TaskHandle Receiver,
void *Data, Duration Timeout); (4.34)
în care parametrul Receiver este un handler al taskului receptor, *Data este
un pointer la data care se depune iar Timeout intervalul de timp în care se
aşteaptă disponibilizarea taskului receptor.
în care taskul receptor poate prelua imediat datele. În caz contrar taskul este
trecut în starea TimedSend pentru un timp care nu poate depăşi Timeout.
Dacă s-a putut transmite mesajul imediat sau în intervalul Timeout
valoarea logică True. În caz contrar, funcţia nu se execută, iar în aceiaşi
variabilă se va înscrie valoarea False.
Capitolul 4 146
 Funcţia RTKReceiveTimed facilitează recepţia unui mesaj,

numai dacă un task emiţător devine disponibil pentru
transmiterea datelor într-un interval de timp precizat printr-o
variabilă de tip Duration. Funcţia are următoarea formă gene-
rală,
bool RTKReceiveTimed(void *Data,
unsigned DataLen Duration Timeout); (4.35)
în care *Data este un pointer la data care se depune, DataLen lungimea în
octeţi a mesajului aşteptat, iar Timeout intervalul de timp în care se aşteaptă
disponibilizarea taskului receptor.
în care taskul emiţător poate transmite imediat datele. În caz contrar taskul este
trecut în starea TimedReceive pentru un timp care nu poate depăşi Timeout.
Dacă s-a putut transmite mesajul imediat sau în intervalul Timeout
valoarea logică True. În caz contrar, funcţia nu se execută, iar în aceiaşi
variabilă se va înscrie valoarea False.
Exemplul 3.6
În acest exemplu se prezintă utilizarea mesajelor de trecere pentru
comunicarea între două taskuri. Sistemul multitasking este constituit din
taskurile TaskA, TaskB şi main.
exemplele 3.3, 3.4 şi 3.5.
 Taskul TaskB are rolul de task receptor executând în buclă
infinită o secvenţă RTKReceive, cprintf. Rezultă că acest task se găseşte
cvasipermanent în starea BlockedReceive, deblocarea producându-se în
momentul când TaskB a fost referit prin handlerul asociat HandleB în taskul
emiţător. După recepţia mesajului sub forma unui caracter, acesta este
tipărit în coordonate prestabilite, însoţit de mesajul B a recepţionat.
 Ca şi în exemplele precedente taskul main conţine o primă
secţiune de declaraţii şi iniţializări şi o a doua secţiune în buclă infinită
destinată supravegherii tastaturii. La apăsarea oricărei taste, se intră într-o
buclă for pe 25 de paşi , în care se transmit, către TaskB în ordine numerele
1, 2, …, 25. Fiecare număr transmis este tipărit, iar intervalul dintre două
transmisii este de o secundă. Dacă tasta apăsată a fost E, această acţiune
va determina ieşirea din program.
Capitolul 4 147
//
// Program demonstrativ utilizare mesaje de trecere
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
TaskHandle HandleB;
struct date d;
struct time t;
//
//
{
{
} //sfarsit for
} //sfarsit TaskA
//
//
TaskB() //task receptor
{
char j2;
{
RTKReceive(&j2,2);// preia mesaj si depune in j2
Goto(5,8);
cprintf("B a receptionat %c ",j2);//tipareste j2
} //sfarsit TaskB
//
//
main() //task main
{
char c, j1=’0’;
int i;
cprintf("Orice tasta – main transmite E - Iesire");
Capitolul 4 148
HandleB=RTKCreateTask(TaskB,5,1024,"Task B");
//
{
//
for(i=1;i<=25;i++)//bucla for finita
{
j1++;
gotoxy(5,10);
cprintf("main transmite %c ",j1);
RTKSend(HandleB,&j1); //transmite catre TaskB
RTKDelay(18);
} //sfarsit for finit
//
if(c==’E’) //testare c fata de E
exit(0); //iesire
j1=’0’; //altfel initializeaza j1
} //sfarsit main
Capitolul 4 149
Ingineria aplicaţiilor de timp real
CAPITOLUL
Aplicații bazate pe
5 achiziția datelor
Se cunoaşte faptul că desfăşurarea unui proces necesită mai multe

categorii de resurse, între care o importanţă aparte prezintă resursele materiale,
energetice, financiare, umane, informaţionale. Este important de subliniat că un
proces nu reprezintă un scop în sine ci se subordonează unor constrângeri
impuse sub forma a trei categorii de obiective şi anume cele legate de calitate,
eficienţă, securitate.
Obiectivele de calitate se referă la respectarea specificaţiilor de calitate
referitoare la produsele şi serviciile rezultate ca urmare a desfăşurării procesului.
Obiectivele de eficienţă presupun impun profitabilitatea respectivului proces, în
condiţiile unei pieţe concurenţiale. În ceea ce priveşte obiectivele de securitate,
acestea au în vedere desfăşurarea procesului astfel încât să nu fie afectată
securitatea personalului de operare a mediului şi a infrastructurii aferente
procesului.
Din punctul de vedere al conducerii fluxurile informaţionale prezintă o
importanţă deosebită întrucât prin intermediul acestora se realizează cunoaşterea
procesului şi se implementează comenzile.
În prima secţiune a prezentului capitol tratează problema procesării
primare a informaţiei preluate din proces şi a celei destinate procesului sub
forma comenzilor.
A doua secţiune prezintă taskurile asociate unor algoritmi de reglare
numerică cu o arie largă de răspândire.
În ultima secţiune sunt expuse câteva consideraţii referitoare la
organizarea bazelor de date de proces (BDP) în calitate de principală resursă
destinată stocării datelor aferente aplicaţiilor de conducere în timp real.
5.1. Prelucrarea primară a datelor de proces

Aceste operaţii sunt necesare din mai multe motive cum ar fi: extragerea
componentei utile din mărimile achiziţionate, compatibilizarea cu dispozitivele
de conversie analog-numerică şi numeric-analogică aferente sistemelor de
150
interfaţă, testarea respectării domeniilor pentru mărimile achiziţionate şi

comenzile elaborate.
Pornind de la această motivaţie, în sfera prelucrării primare a datelor de
proces sunt încadrate următoarele tipuri de operaţii:
- filtrarea mărimilor achiziţionate;
- conversia în/din unităţi inginereşti;
- validarea mărimilor achiziţionate şi a comenzilor elaborate,
care vor fi prezentate în cele ce urmează.
5.1.1.Filtrarea mărimilor achiziţionate

În general un filtru reprezintă un bloc funcţional cu proprietăţi selective
pentru anumite frecvenţe. Spre deosebire de filtrele analogice, la care intrarea şi
ieşirea sunt reprezentate de semnale analogice la cele numerice, atât intrarea cât
şi ieşirea sunt constituite din secvenţe de numere, potrivit reprezentării din
figura 5.1.
x[n] y[n]
FILTRU
NUMERIC
Fig. 5.1. Schema bloc a unui filtru numeric: x[n]- secvenţă

numerică de intrare, y[n] – secvenţă numerică de ieşire.
Practic un filtru numeric reprezintă un algoritm care produce la ieşire o

secvenţă y[n] pornind de la o secvenţă de intrare x[n] şi care are ca obiectiv o
comportare selectivă faţă de semnale de frecvenţă diferită conţinute în secvenţa
de intrare.
Un important criteriu împarte filtrele numerice în filtre nerecursive şi
recursive.
 În cazul unui filtru nerecursiv valoarea filtrată y[n] depinde de
ultimele N valori din secvenţa de intrare x[n] potrivit relaţiei
· , 5.1
unde h[k] reprezintă coeficienţi ai filtrului.
151
Relaţiei (5.1) i se poate ataşa o schemă de calcul de tipul celei din figura
5.2 care pune în evidenţă circulaţia fluxului de date. Din analiza acestei figuri se
observă că valorile succesive x[n-k] se obţin prin întârzieri succesive cu
perioada de achiziţie Te a mărimii de intrare x. După efectuarea produselor
· valorile rezultate se însumează într-un bloc sumator şi în final
rezultă mărimea filtrată y[n].
x[n-2]
x[n-1]
x[n-(N-2)] x[n-(N-1)]
x[n]
Te Te Te
h[0] h[1] h[2] h[N-2] h[N-1]
+
y[n]
Fig. 5.2. Schemă de calcul al unui filtru nerecursiv.
 La filtrele recursive valoarea filtrată y[n] depinde atât de ultimele

N valori din secvenţa de intrare x[n] , cât şi de ultimele M valori din secvenţa de
ieşire conform relaţiei
· · , 5.2
unde h[k] şi b[j] reprezintă coeficienţi ai filtrului.
Din relaţia (5.2) se observă că în secţiunea care include termenii

recursivi, respectiv cei care se referă la ieşirea y , sunt conţinuţi toţi termenii
începând cu y[n-1] . Pe baza aceloraşi consideraţii ca în cazul nerecursiv în
figura 5.3 se prezintă o schemă de calcul a filtrului recursiv care implementează
relaţia (5.2).
152
x[n-1]
x[n-(N-2)] x[n-(N-1)]
x[n]
Te Te Te
h[0] h[1] h[2] h[N-2] h[N-1]
y[n]
+
…
-b[M] -b[M-1] -b[1]
y[n-M] Te Te Te
y[n-(M-1)] y[n-2] y[n-1]
Fig. 5.3. Schemă de calcul al unui filtru recursiv.
O variantă simplificată a filtrului nerecursiv este aceea în care se

utilizează un singur coeficient. Dacă acest coeficient este 1/N atunci filtrul se
numeşte cu mediere şi relaţia (5.1) devine
1
, 5.3
unde N reprezintă ultimele N valori ale intrării.
Transpunând relaţia (5.3) pentru următorul pas rezultă
1
1 1 . 5.4
153
Prin scăderea celor două relaţii se obţine
1 1
1 1 , 5.5
care după câteva transformări elementare devine

1
1 xn 1 xn 1 N . 5.6
Relaţia (5.6) este de tip recurenţial întrucât valoarea curentă a mărimii

filtrate y depinde de valoarea anterioară a acesteia şi de două valori ale intrării
(valoarea curentă şi cea din urmă cu N paşi). Pentru determinarea valorii
întârziate cu N paşi se utilizează o structură de tip coadă reprezentată în figura
5.4 pentru care se poate construi subalgoritmul AVANS_C a cărui schemă logică
este evidenţiată în figura 5.5.
x[n+1-(N)]
x[n+1-(N)]
x[n+1-(N-1)]
x[n+1-(2)]
x[n+1-(1)]
x[n+1]
Fig. 5.4. Organizarea cozii pentru relaţia (5.6).
Subalgoritmul AVANS_C are ca intrare valoarea curentă achiziţionată,

notată cu w_in în figura 5.5 şi ca ieşire valoarea întârziată cu M perioade de
eşantionare, notată cu w_out în aceiaşi figură.
Pentru construcţia taskului FILTR_MED asociat filtrului cu mediere se

fac următoarele notaţii:
- y[n+1] = YFC - valoare filtrată curentă;

154
- y[n] = YFA - valoare filtrată anterioară;

- x[n+1] = XAC - valoare achiziţionată curentă;
- x[n+1-N] = XAI - valoare achiziţionată întârziată.
M,w_in
AVANS_C
w_out
w_out=z(M)
j=M
z(j)=z(j-1)
j=j-1
Nu
Da
j=1
?
z(1)=w_in
EXIT
Fig. 5.5. Schema logică aferentă subalgoritmului de avans în coadă.
Cu aceste notaţii relaţia (5.6) devine
XAC XAI /N , 5.7
care va fi utilizată în taskul care implementează algoritmul de filtrare cu

mediere, a cărui schemă logică este prezentată în figura 5.6.
Taskul FILTR_MED este sincronizat cu timpul, intervalul de execuţie

fiind egal cu intervalul de eşantionare, respectiv Te. La fiecare execuţie este
apelat subalgoritmul AVANS_C în care parametrii fictivi capătă valorile
w_in=XAC, respectiv w_out=XAI.
155
Se consideră că valoarea achiziţionată provine dintr-o bază de date de

proces BDP, iar valoarea filtrată este plasată în aceiaşi bază. Întrucât BDP este
considerată resursă critică accesul la aceasta va trebui supus excluderii mutuale.
În acest scop se utilizează semaforul binar SEMEX potrivit procedurii indicate
în capitolul 2 al prezentei lucrări.
Initializare task
FILTER_MED
SEMEX=1, determină valori
iniţiale pentru N,
YFC, YFA, XAC, XAI
Nu
∆t=Te ?
Da
P(SEMEX)
Preia din BDP

XAC
V(SEMEX)
YFA=YFC
N, XAC
AVANS_C
XAI
YFC=YFA+(XAC-XAI)/N
P(SEMEX)
Transfera in BDP
YFC
V(SEMEX)
Fig. 5.6. Schema logică asociată taskului FILTER_MED.

156
4.1.1. Circuitul informaţional aferent unei aplicaţii de conducere
Într-o aplicaţie de conducere în timp real poate fi evidenţiată următoarea

secvenţă de operaţii:
- achiziţia din proces a datelor;
- determinării comenzilor;
- implementarea în proces a comenzilor.
Realizarea acestei secvenţe traversarea frontierelor evidenţiate în figura
4.7, în care procesul este reprezentat de traductoare şi elemente de execuţie.
ANALOGIC DIGITAL DIGITAL
Semnale uCAN uING

analogice Calcul i
de la traductoare
PROCES generare
ANALOGIC DIGITAL DIGITAL comenzi
Semnale uCNA uING

analogice
către elemente
de execu ie
F1 F2
Fig. 5.7. Frontiere asociate circuitului informaţional într-o aplicaţie de
conducere.
Acestea se consideră că generează, respectiv sunt acţionate de semnale

analogice. Întrucât procesarea impune intrări în formă numerică şi generează
rezultate în aceiaşi formă, rezultă necesitatea frontierei F1. Aceasta este
reprezentată de SIA (Subsistemul Intrărilor Analogice) şi SEA (Subsistemul
Ieşirilor Analogice) din structura sistemului de interfaţă cu procesul. În cazul
aparaturii inteligente de automatizare (Smart) această frontieră este situată la
limita respectivei instrumentaţii, iar transmiterea semnalelor se face în format
digital.
Dacă respectiva aparatură este de natură analogică, atunci frontiera F1
este situată în zona echipamentului de procesarea şi transmiterea semnalelor se
face în format digital.
Din cele expuse până în prezent rezultă că frontiera F1 schimbă , funcţie
de sensul de transmitere, natura semnalelor. Astfel, pe sensul de la proces are loc
157
o conversie analog / numerică, pe sensul către proces o conversie numeric /

analogică. Indiferent de sens mărimea analogică este exprimată în unităţi
inginereşti iar în mărimea numerică în unităţi CAN (uCAN), respectiv CNA1
(uCNA).
O altă frontieră este F2 , la nivelul căreia se păstrează natura digitală dar
se schimbă conţinutul mărimii. Astfel pe sensul de la proces se produce o
conversie în unităţi inginereşti, iar pe sensul către proces se realizează o
conversie din unităţi inginereşti.
Dacă frontiera F1 este asociată sistemului de interfaţă cu procesul (SIP),
frontiera F2 este asociată conversiei în, respectiv conversiei din unităţi
inginereşti.
În figura 5.8 se prezintă circuitul informaţional, în cadrul unei aplicaţii
de conducere, în care un regulator după perturbaţie elaborează un semnal de
comandă care se transmite sub forma referinţei externe unui sistem de reglare
automată cu acţiune după abatere. În această figură deasupra fiecărei săgeţi este
notată o mărime iar sub săgeată unitatea de măsură.
F2 F1
iP1 P2_1 P2_k P2_n
uP1
P* NP uP CIU1 TP1
V mA
BC1 CAN
uPk iPk
uCAN TPk
REG uING CIUk
V mA
PERT
REG AB P2
y1* P1 y2
N1 u1
i1
SP1 y1 SP2
BC2 CNA CUI BFA EE
uING
u
uING uCNA
V mA TA
r1
y2i
Fig. 5.8. Circuitul informaţional într-un SRA ierarhizat.
Structura din figura 5.8 asigură invarianţa mărimii y22 la modificarea

perturbaţiilor P2_1…P2_k. Mărimea de comandă a regulatorului după
perturbaţie REG PART este reprezentată de valoarea y1*, exprimată în unităţi
inginereşti uING, care se aplică în calitate de referinţă unui SRA abatere în care
REG AB reprezintă regulatorul aferent acestui sistem. În aceiaşi figură CUI şi
CIU reprezintă convertoarele tensiune – curent respectiv curent – tensiune.
1
CAN i CNA sunt abrevieri pentru Convertor Analog Numeric, respectiv Convertor Numeric
Analog.
2
În raport cu referin a y2i
158
Analizând figura 5.8 rezultă că frontiera F1 este localizată la nivelul

CAN şi CNA, componente ale subsistemelor de intrări respectiv ieşiri analogice
din cadrul SIP.
În ceea ce priveşte frontiera F2, aceasta este implementată de blocurile
de calcul BC1 şi BC2. Modulul BC1 parte integrantă a unui sistem numeric de
măsurat asigură conversia din unităţi CAN în unităţi inginereşti. Funcţia inversă,
respectiv conversia unităţi inginereşti – unităţi CNA este asigurată de către
modulul BC2 care se consideră inclus într-un sistem numeric te transmitere a
comenzii. În cele ce urmează vor fi prezentate elemente privind sinteza celor
două module de calcul.
4.1.2. Conversia în unităţi inginereşti
După cum s-a menţionat în paragraful anterior această conversie se

realizează de către blocul BC1, parte integrată a unui sistem numeric de măsurat
la distanţă SNMD cu structura evidenţiată în figura 5.9.
Δx Δi Δu ΔN Δx* Δx Δx*
T CIU CAN BC1 SNMD
uING mA V uCAN uING uING uING
Fig. 5.9. Structura unui sistem numeric de măsurat la distanţă.
În figura 5.9 mărimile sunt reprezentate prin variaţii . Pentru o mărime z

care ia valori într-un domeniu [zmin, zmax] se definesc două tipuri de variaţii şi
anume :
- variaţia curentă ∆ , 5.7
- variaţia maximă ∆ . 5.8
Determinarea relaţiei asociate modulului BC1 se va realiza impunând

pentru SNMD o caracteristică statică liniară, ilustrată în figura 5.10.
Δx*
Δx*max
Fig. 5.10. Caracteristica statică impusă pentru

SNMD.
Δxmax Δx
159
Conversia curent-tensiune se realizează pe un rezistor de rezistenţă R,

astfel încât pentru CIU rezultă o caracteristică liniară prezentată în figura 5.11 a.
În ceea ce priveşte CAN , pentru rezoluţiile uzuale din sistemele
industriale de achiziţie de 12 – 16 biţi, caracteristica statică poate fi aproximată
ca fiind liniară, potrivit reprezentării din figura 5.11 b.
Δu ΔN
ΔNmax
Δumax
Δimax Δi Δumax Δu
a b
Fig. 5.11. Caracteristici statice ale convertoarelor: a – CIU; b – CAN.
Având în vedere caracteristicile statice ilustrate în figurile 4.10 şi 4.11

rezultă că relaţia aferentă modulului BC1, din punctul de vedere al liniarităţii,
va depinde numai de forma caracteristicii statice a traductorului T. În cele ce
urmează vor fi considerate două situaţii şi anume:
- SNMD cu traductor de tip liniar;
- SNMD cu traductor de tip neliniar (pătratic).
 Sinteza BC1 pentru un SNMD cu traductor liniar
În figura 5.12 este ilustrată caracteristica statică a traductorului liniar

care se consideră inclus în SNMD.
Δi
Δimax
Fig. 4.12. Caracteristica statică a traductorului liniar

din structura SNMD.
Δxmax Δx
Caracteristicilor statice din figurile 4.10…4.12 li se asociază următorul

sistem de ecuaţii în abateri:
160
SNMD: ∆ 5.9
∆ ·∆ ,
∆
T: ∆ (5.10
∆ ·∆ ,
∆
CIU: ∆ 5.11
∆ ·∆ ,
∆
CAN: ∆ 5.12
∆ ·∆ .
∆
Rezolvând sistemul format din ecuaţiile (5.9)…(5.11) rezultă pentru

BC1 ecuaţia
∆ 5.13
∆ ·∆ ,
∆
sau impunând pentru mărimea x* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică
∆ 5.14
∆ ·∆ .
∆
Examinând relaţia (5.14) se observă că elementul BC1 este un element

liniar, a cărui caracteristică statică este reprezentată în figura 5.13.
Δx*
Δxmax
Fig. 5.13. Caracteristica statică rezultată pentru

modulul de calcul BC1, în cazul traductorului
liniar..
ΔNmax ΔN
Sunt situaţii care necesită utilizarea ecuaţiei modulului BC1 în valori

absolute. Pentru a obţine această formă, în ecuaţia (5.14) se exprimă abaterile
ţinând cont de relaţiile (5.7), (5.8) şi rezultă
161
· . 5.15
După efectuarea calculelor în relaţia (5.15) se obţine,
· · 5.16
·
sau
· 5.17
unde
· · 5.18
(5.19)
O situaţie frecvent întâlnită este aceea în care limita inferioară a

domeniului mărimii x este nulă, respectiv xmin = 0. În acest caz ecuaţia (5.16)
devine
· 5.20
·
sau
· 5.21
unde
· 5.22
. (5.23)
Rezultatele de mai sus confirmă faptul că indiferent de forma de

exprimare (prin variaţii sau valori absolute) BC1 prezintă o caracteristică statică
liniară.
162
 Sinteza BC1 pentru un SNMD cu traductor neliniar

În cele ce urmează se va trata problema determinării ecuaţiei asociate
modulului BC1 în cazul unui traductor neliniar de tip pătratic. Se menţin
ipotezele referitoare la liniaritate din cazul precedent, cu excepţia traductorului,
care prezintă caracteristica statică ilustrată în figura 5.14, astfel încât pentru
SNMD rezultă sistemul de ecuaţii (5.24)…(5.27).
Δi
Δimax
Fig. 5.14. Caracteristica statică a traductorului

neliniar din structura SNMD.
Δxmax Δx
SNMD: ∆ 5.24
∆ ·∆ ,
∆
T: ∆ (5.25
∆ · ∆ ,
∆
CIU: ∆ 5.26
∆ ·∆ ,
∆
CAN: ∆ 5.27
∆ ·∆ .
∆
Rezolvând sistemul format din ecuaţiile (5.24)…(5.27) , în raport cu
mărimea Δx* , rezultă pentru BC1 ecuaţia
∆ 5.28
∆ · √∆ ,
∆
sau impunând pentru mărimea x* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică
∆ 5.29
∆ · √∆ .
∆
neliniar, a cărui caracteristică statică este reprezentată în figura 5.15. Este de
remarcat faptul că neliniaritatea introdusă de BC1 compensează neliniaritatea
163
traductorului T, astfel încât pe ansamblu caracteristica statică a SNMD să rezulte

liniară.
Δx*
Δxmax

modulul de calcul BC1, în cazul traductorului
neliniar..
ΔNmax ΔN
Ca şi în cazul precedent. sunt situaţii care necesită utilizarea ecuaţiei

modulului BC1 în valori absolute. Pentru a obţine această formă, în ecuaţia
(5.29) se exprimă abaterile ţinând cont de relaţiile (5.7), (5.8) şi rezultă
· . 5.30
După efectuarea calculelor în relaţia (5.30), în situaţia frecvent întâlnită

în practică xmin = 0 se obţine,
5.31
· .
sau
5.32
·
·
respectiv
· , 5.33
unde
· 5.34
,
164
(5.35)
.

neliniară care compensează neliniaritatea caracteristicii traductorului T.
În continuare se va deduce o funcţie generală asociată modulului BC1
indiferent de caracteristicile statice impuse pentru sistemul numeric de măsurat
şi traductor. Se menţine ipoteza liniarităţii blocului de conversie format din CIU
şi CAN.
Pentru SNMD, caracteristicii statice i se asociază funcţia continuă
∆ ∆ 5.36
cu
∆ ∆ ,
0 0.
În ceea ce priveşte traductorul , caracteristica statică a acestuia este
descrisă de funcţia continuă şi inversabilă
∆ ∆ 5.37
cu
0 0,
∆ ∆ .
Se consideră că funcţia f este inversabilă, iar funcţia sa inversă

∆ ∆ 5.38
cu
∆ ∆ ;
0 0 ,
este de asemenea continuă.
Înlocuind relaţia (5.38) în (5.36) rezultă
∆ ∆ , 5.39
unde prin înlocuirea lui Δi cu valoarea din relaţia (5.26) se ajunge la
165
∆ 5.40
∆ ·∆ .
∆
Substituind în relaţia (5.40) valoarea Δu din ecuaţia CAN (5.27) se

ajunge la
∆ ∆ 5.41
∆ · ·∆ ,
∆ ∆
respectiv
∆ 5.42
∆ ·∆ .
∆
În contextul figurii 4.9 se notează

∆ 5.43
,
∆
notaţie care semnifică amplificarea grupării de convertoare CIU – CAN.

Înlocuind notaţia (5.43), în relaţia (5.42), se obţine
∆ ·∆ , 5.44
care reprezintă ecuaţia modulului BC1, în următoarele condiţii:
- SNMV este caracterizat de funcţia continuă g – relaţia (5.36);
- T este caracterizat de funcţia inversabilă cu inversă continuă f –
relaţia (5.37);
- convertoarele CIU şi CAN au comportare liniară, amplificarea
grupării fiind K1.
În continuare vor fi prezentate două exemple care tratează aspecte
referitoare la conversia în unităţi inginereşti.
Exemplul 5.1.
Pentru SNMD nivel cu structura ilustrată în figura 5.16 se cunosc

următoarele elemente:
LT - 200 800 , 4 20 , caracteristică
statică liniară;
CIU - R = 250 Ω, caracteristică statică liniară;
CAN - Nmax1 = 1023 uCAN sau Nmax2 = 4095 uCAN, caracteristică
statică liniară;
166
Să se determine:
a – domeniul de valori al tensiunii la intrarea CAN;
b – rezoluţiile n1 şi n2 ale CAN pentru cele două valori Nmax1
şi Nmax2 ;
c – valorile numerelor de cuante N1 şi N2 în cazul unui nivel
din memorie H* =650mm .
Qi i
H N H*
LT R u CAN BC1
Qe
Fig. 5.16. Structura SNMD nivel pentru exemplul 4.1.
Rezolvare
a – conform legii lui Ohm, pentru rezistorul R se poate scrie
· 250 · 4 · 10 1 ;
· 250 · 20 · 10 5 ;
b – pentru un CAN se cunoaşte că 2 - 1 de unde rezultă

log 1 , prin a cărei aplicare se obţine
log 1023 1 log 1024 10 ţ ;

log 4095 1 log 4096 12 ţ .
c – se determină pentru început valorile Nmin1 şi Nmin2 apelând la

caracteristica statică a CAN ilustrată în figura 5.17;
N
Nmax
Fig. 4.17. Caracteristica statică a CAN.

Nmin
U
Umin Umax
167
Caracteristica statică liniară din figura 5.17 este descrisă de ecuaţia
de unde rezultă
respectiv
1023
· ·1 204,6
5
4095
· ·1 819
5
Cu aceste valori se determină coeficienţii din relaţiile (5.18) şi (5.19)

după cum urmează:
· · 800 · 204,6 200 · 1023
50
1023 204,6
· · 800 · 819 200 · 4095

50
4095 819
800 200
0,733138 /
1023 204,6
800 200
0,183150 /
4095 819
Pentru primul caz rezultă următoarea ecuaţie pentru modulul BC1

·
respectiv
50 0,733138 ·
sau
168
650 50 0,733138 ·
Din ultima relaţie rezultă
700
954,8
0,733138
Pentru al doilea caz rezultă următoarea ecuaţie pentru modulul BC1

·
respectiv
50 0,183150 ·
sau
650 50 0,183150 ·
Din relaţia de mai sus rezultă

700
3822
0,183150
Exemplul 5.2.
Fie SNMD debit ilustrat în figura 5.18, pentru care se cunosc:

SNMD - caracteristică statică impusă liniară
FT - 0 60 / , 4 20 , caracteristică statică
neliniară (pătratică);
CIU - R = 250 Ω, caracteristică statică liniară;
CAN - Nmax = 2047 uCAN, caracteristică statică liniară;
Să se determine:
a – domeniul de valori al tensiunii la intrarea CAN, rezoluţia
n şi numărul Nmin de uCAN ale acestuia;
b – deducerea ecuaţiei asociate BC1 pe baza relaţiei (5.44),
considerând funcţia g liniară;
c – valoarea Q * a debitului reprezentat în memorie pentru
N=1500 uCAN.
169
N Q*
u
CAN BC1
i R
FT
Q
Fig. 5.18. Structura SNMD debit pentru exemplul 4.2.
Rezolvare
a – conform legii lui Ohm, pentru rezistorul R se poate scrie
· 250 · 4 · 10 1 ;
de unde rezultă Umax
∆ 1 4 5 ;
log 1 log 1 log 2048 11 ţ.
Conform procedeului indicate în exemplul precedent rezultă Nmin după

cum urmează:
2047
· ·1 409,4
5
b – pentru SNMD funcţia g , coeficientul K1 şi funcţia f au formele de

mai jos:
∆ 5.45
∆ ·∆ ,
∆
∆ 5.46
,
∆
∆ 5.47
∆ · ∆ ,
∆
170
Din relaţia (5.47) rezultă
∆ 5.48
∆ · √∆ ,
∆
respectiv,
∆ ∆
·∆ · · √∆ .
∆ ∆
5.49
Aplicând relaţia (5.44), rezultatul de mai sus conduce la
∆ ∆
∆ ·∆ · · √∆ .
∆ ∆
5.50
sau
∆
∆ · √∆ .
∆
5.51
Considerând domeniile pentru mărimile Q* şi Q egale relaţia (5.51)

devine
∆
∆ · √∆ .
∆
5.52
relaţie identică cu relaţia (5.29).
Pentru exprimarea în valori absolute se calculează mai întâi Nmin apoi

coeficienţii c0 şi c1 cu relaţiile (5.34) şi (5.35). după cum urmează
171
· 409,4 · 3600
, 900 /
2047 409,4
3600
, 2,197 .
2047 409,4
Introducând coeficienţii c0 şi c1 în relaţia (5.33) se obţine
· respectiv
√ 900 2,197 ·
ultima relaţie reprezentând expresia caracteristicii statice a modulului

BC1.
Valoarea solicitată pentru debitul calculat Q* este
900 2,197 · 1500 48,94 /
4.1.3. Conversia din unităţi inginereşti

Aşa cum reiese din figura 5.8 în care se prezintă circuitul informaţional
într-un SRA ierarhizat această conversie se realizează de către blocul BC2, parte
integrată a unui sistem numeric de transmitere a comenzii la distanţă SNTD cu
structura evidenţiată în figura 5.19.
Δy* ΔN Δu Δi Δy Δy* Δy
BC2 CNA CUI SRA SNTD
uING uCNA V mA uING uING uING
Fig. 5.19. Structura unui sistem numeric de măsurat la distanţă.
Ca şi la conversia din unităţi inginereşti , mărimile sunt exprimate prin

variaţii, semnificaţiile tipurilor de variaţii fiind cele din relaţiile 4.7 şi 4.8.
Determinarea relaţiei asociate modulului BC2 se va realiza impunând
pentru SNMD o caracteristică statică liniară, ilustrată în figura 5.20.
172
Δy
Δymax
Fig. 5.20. Caracteristica statică impusă pentru

SNTD.
Δy*max Δy*
Atât pentru convertorul tensiune curent CUI, cât şi pentru cel analog
numeric CNA se presupun caracteristici statice liniare ilustrate în figura 5.21.
Δi Δu
Δimax
Δumax
Δumax Δu ΔN
ΔNmax
a b
Fig. 4.21. Caracteristici statice ale convertoarelor: a – CUI; b – CNA.
Având în vedere caracteristicile statice ilustrate în figurile 5.20 şi 5.21

rezultă că relaţia aferentă modulului BC2, din punctul de vedere al liniarităţii,
va depinde numai de forma caracteristicii statice de măsură a SRA. În cele ce
urmează vor fi considerate două situaţii şi anume:
- SNTD care include SRA cu caracteristică de măsură (CM) de tip
liniar;
- SNTD care include SRA cu caracteristică de măsură (CM) de tip
neliniar;
 Sinteza BC2 pentru un SNTD care include SRA cu CM liniară

În figura 5.22 este ilustrată caracteristica statică a SRA cu CM liniară
care se consideră inclus în SNTD.
Δy
Δymax
Fig. 5.22. Caracteristica statică a SRA cu CM liniară

din structura SNTD.
Δi
Δimax 173
Caracteristicilor statice din figurile 4.34…4.36 li se asociază următorul

sistem de ecuaţii în abateri:
SNTD: ∆ 5.53
∆ · ∆ ,
∆
SRA: ∆ (5.54
∆ ·∆ ,
∆
CUI: ∆ 5.55
∆ ·∆ ,
∆
CNA: ∆ 5.56
∆ ·∆ .
∆

BC2 ecuaţia
∆ 5.57
∆ · ∆ ,
∆
sau impunând pentru mărimea y* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică rezultă
∆ 5.58
∆ ·∆ .
∆

liniar, a cărui caracteristică statică este reprezentată în figura 5.23.
ΔN
ΔNmax

modulul de calcul BC2, în cazul SRA cu CM
liniară.
Δymax Δy*
Ca şi la conversia în unităţi inginereşti sunt situaţii care necesită

utilizarea ecuaţiei modulului BC2 exprimat în valori absolute. Pentru a obţine
174
această formă, în ecuaţia (5.58) se exprimă abaterile ţinând cont de relaţiile

(5.7), (5.8) şi rezultă
5.59
· .

· · 5.60
·
sau
· 5.61
unde
· · 5.62
(5.63)
O situaţie frecvent întâlnită este aceea în care limita inferioară a

domeniului mărimii y este nulă, respectiv ymin = 0. În acest caz ecuaţia (5.60)
devine
5.65
·
sau
· 5.66
unde
5.67
(5.68)
.

liniară.
175
 Sinteza BC2 pentru un SNTD care include SRA cu CM neliniară

În figura 5.24 este ilustrată caracteristica statică a SRA cu CM neliniară
care se consideră inclus în SNTD.
Δy
Δymax
Fig. 5.24. Caracteristica statică a SRA cu CM

neliniară din structura SNTD.
Δi
Δimax
Caracteristicilor statice din figurile 5.20, 5.21 şi 5.24 li se asociază

următorul sistem de ecuaţii în abateri:
SNTD: ∆ 5.69
∆ · ∆ ,
∆
SRA: ∆ (5.70
∆ · √∆ ,
∆
CUI: ∆ 5.71
∆ ·∆ ,
∆
CNA: ∆ 5.72
∆ ·∆ .
∆

BC2 ecuaţia
∆ 5.73
∆ · ∆ ,
∆
sau impunând pentru mărimea y* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică rezultă
∆ 5.74
∆ · ∆ .
∆

liniar, a cărui caracteristică statică reprezentată în figura 5.25 compensează
neliniaritatea caracteristicii de măsură a SRA.
176
ΔN
ΔNmax

modulul de calcul BC2, în cazul SRA cu CM
neliniară.
Δymax Δy*
Şi în această caz sunt situaţii care necesită utilizarea ecuaţiei modulului

BC2 exprimat în valori absolute. Pentru a obţine această formă, în ecuaţia (5.74)
se exprimă abaterile ţinând cont de relaţiile (5.7), (5.8) şi rezultă
5.75
· .
· · 5.76
unde
5.77
·
(5.78)
2· ·
(5.79)
Dacă limita inferioară a domeniului mărimii y este nulă, respectiv ymin

= 0 , ecuaţia (5.76) devine
· 5.80
unde
5.81
177
(5.82)

neliniară care compensează neliniaritatea CM a SRA..
În continuare se va deduce o funcţie generală asociată modulului BC2

care să fie valabilă pentru orice tip de caracteristici statice, liniare sau neliniare,
impuse pentru SNTD şi CM a SRA. Se menţine ipoteza liniarităţii blocului de
conversie format din CUI şi CNA.
Pentru SNTD, caracteristicii statice i se asociază funcţia continuă
∆ ∆ 5.83
cu
∆ ∆ ,
0 0.
În ceea ce priveşte SRA , caracteristica statică de măsură a acestuia este
descrisă de funcţia continuă şi inversabilă
∆ ∆ 5.84
cu
0 0,
∆ ∆ .
Se consideră că funcţia h este inversabilă, iar funcţia sa inversă

∆ ∆ 5.85
cu
∆ ∆ ;
0 0 ,
este de asemenea continuă.
Din ecuaţiile (5.71) şi (5.72) rezultă
∆
CNA+CUI: ∆ ·∆ . 5.86
∆
În contextul figurii 4.33 se notează
178
∆ 5.87
,
∆
notaţie care semnifică amplificarea grupării de convertoare CNA – CUI,

astfel încât relaţia (5.86) devine
∆ ·∆ . 5.88
Înlocuind relaţia (5.85) în (5.38) rezultă
∆ · ∆ . 5.89
în care substituind pe Δy cu valoarea din (5.83) se ajunge la
∆ · ∆ . 5.90
relaţie care reprezintă ecuaţia modulului BC2, în următoarele condiţii:

- SNTD este caracterizat de funcţia continuă q – relaţia (5.83);
- CM a SRA este reprezentată de funcţia inversabilă cu inversă continuă
h – relaţia (5.84);
- convertoarele CNA şi CUI au comportare liniară, amplificarea
grupării fiind K2. – relaţia (5.87).
În continuare vor fi prezentate două exemple care tratează aspecte
referitoare la conversia din unităţi inginereşti.
Exemplul 4.3.
Pentru SNTD cu structura ilustrată în figura 5.26 se cunosc următoarele

elemente:
SRA - 200 800 , caracteristică statică liniară;
CUI - 0,2 1 caracteristică statică liniară;
CNA - Nmax = 1023 uCAN, caracteristică statică liniară;
Să se determine:
a – rezoluţia n a CNA şi numărul minim Nmin de uCNA;
179
b – deducerea ecuaţiei asociate BC2 pe baza relaţiei (5.90),

considerând funcţia q liniară;
c – valoarea calculată H* a nivelului pentru care a rezultat un
număr N=600 uCNA
Qi N H*
i u
CUI CNA BC2
LT LC
Qe
Fig. 5.26. Structura SNTD pentru exemplul 4.3.
Rezolvare
a – pentru un CNA (ca şi în cazul CAN) se cunoaşte că 2 -1

de unde rezultă log 1 , prin a cărei aplicare se obţine
log 1023 1 log 1024 10 ţ ;
pentru determinarea valorii Nmin se apelează la caracteristica statică

a CNA ilustrată în figura 5.27.
U
Umax
Fig. 5.27. Caracteristica statică a CNA.

Umin
N
Nmin Nmax
de unde rezultă
180
respectiv
1023
· 0,2 204,6
1
b – pentru SNMD funcţia q , coeficientul K2 şi funcţia h au formele de
mai jos:
∆ 5.91
∆ ·∆ ,
∆
∆ 5.92
,
∆
∆ 5.93
∆ ·∆ ,
∆
Din relaţia (5.47) rezultă
∆ 5.94
∆ ·∆ ,
∆
respectiv,
∆ ∆
∆ · ·∆ .
∆ ∆
5.95
Aplicând relaţia (5.90), rezultatul de mai sus conduce la
∆ ∆
∆ · ∆ · ·∆ .
∆ ∆
5.96
sau
∆
∆ ·∆ .
∆
5.97
181
Considerând domeniile pentru mărimile H* şi H egale relaţia (5.97)

devine
∆
∆ ·∆ .
∆
5.98
relaţie identică cu relaţia (5.58).
c – se calculează coeficienţii c0 şi c1 din relaţiile (5.62) şi (5.63) după

cum urmează:
· · 800 · 204,6 200 · 1023

68,2
800 200
1023 204,6
1,364 / .
800 200
Rezultă următoarea ecuaţie pentru modulul BC2

·
respectiv
62,8 1,364 ·
sau
600 62,8 1,364 · .
Din ultima relaţie rezultă
662,8
485,92 .
1,364
Exemplul 5.4.
Fie SNTD ilustrat în figura 5.28, pentru care se cunosc:

SNTD - caracteristică statică impusă liniară
SRA - 0 60 / , caracteristică statică neliniară (radical);
CUI - 0,4 2 caracteristică statică liniară ;
182
CNA - n = 12 bit , caracteristică statică liniară;

Să se determine:
a – numerele de Nmin şi Nmax de uCNA pentru CNA;
b – valorile coeficienţilor pentru BC2;
c – valoarea N a numărului de uCAN pentru un debit calculat
Q * = 45 mc/h.
u N Q*
i
CUI CNA BC2
FC
FT
Q
Fig. 5.28. Structura SNMD debit pentru exemplul 5.4.
Rezolvare
a– 2 1 2 1 4096 1 4095
pentru determinarea valorii Nmin se apelează la caracteristica statică a

CNA ilustrată în figura 5.28.
U
Umax = 2 V
Fig. 5.29. Caracteristica statică a CNA.

Umin = 0,4 V
N
Nmin Nmax=4095 uCANA
de unde rezultă
183
respectiv
4095
· 0,4 819
2
c – se calculează coeficienţii f0 şi f2 din relaţiile (5.62) şi (5.63) după
cum urmează:
819 ,
4095 819 3726

1,035 / / .
60 3600
Rezultă următoarea ecuaţie pentru modulul BC2

·
respectiv
819 1,035 ·
sau cu datele din enunţ
819 1,035 · 45 819 1,035 · 2025 2914,875 .
Observaţie
Către CNA se va transmite una dintre valorile N=2914 uCNA sau
N=2915 uCNA, respectiv valoarea trunchiată sau aproximată prin adaos
(deoarece partea fracţionară este > 0,5.
5.1.4 Validarea mărimilor achiziţionate şi a comenzilor elaborate

În sens strict operaţiunea de validare a unei mărimi achiziţionate
presupune testarea încadrării valorii rezultate în unităţi inginereşti în domeniul
declarat pentru respectiva mărime. O eventuală neîncadrare în domeniu va fi
declarată ca eveniment semnificativ, care va fi tratat prin execuţia unei rutine de
testare a integrităţii funcţionale a SNMD şi avertizare.
În afara testării încadrării în domeniu, mai pot fi testate şi alte limite
asociate diferitelor tipuri de avertizări cum ar fi avertizarea de prevenire sau cea
de avarie, situate aşa cum se observă din figura 5.44 în interiorul domeniului
traductorului.
184
Domeniu Traductor
Limite avertizare de prevenire
Limite avertizare de avarie

Fig. 5.30. Limite asociate diverselor tipuri de testări a unei mărimi achiziţionate.
La încălcarea sunt trecute în execuţie taskuri specifice sincronizate cu

aceste evenimente care determină după caz pe lângă avertizări acţiuni de
blocare, izolare, neutralizare, etc.
Înainte ca o comandă calculată să fie aplicată SNTD au loc teste de
încadrare în domeniul specificat şi eventual între limite tehnologice sigure
situate, conform reprezentării din figura 5.31 în interiorul domeniului
comenzilor valide.
Domeniu Comenzi Valide
Ymin Ymax Y
Domeniu Comenzi Sigure
Fig. 5.31. Limite asociate testării unei comenzi calculate.
O neîncadrare în domeniul comenzilor valide va fi declarată ca

eveniment semnificativ, care va fi tratat ca şi în cazul achiziţiei prin execuţia
unei rutine de testare a integrităţii funcţionale a SNTD şi avertizare.
Încălcarea unei limite a domeniului de funcţionare sigură va determina
de regulă aplicarea către SNTD a valorii limitei încălcate, aspect evidenţiat în
procedura ilustrată în figura 5.32.
Este important că toate evenimentele semnificative aferente testării
mărimilor achiziţionate sau a comenzilor elaborate se înscriu in jurnalul cu
evenimente din baza de date de proces.
185
PROCEDURA TESTARE
COMANDA CALCULATA
Ycalc
Transfera
Ycalc
Preia din BDP

Ymin, Ymax
Y ≤ Ymin
Nu
Da Da
Y ≥ Ymax
Nu
Y=Ymin Y=Ycalc Y=Ymax
Transfera
Y
RETURN
Fig. 5.32. Schema logică asociată procedurii de testare a unei comenzi calculate.
5.2. Taskuri asociate unor algoritmi uzuali de reglare

numerică
În prezentul subcapitol vor fi prezentate principalele taskuri asociate
unor algoritmi de reglare numerică cu o arie largă de răspândire.
5.2.1. Taskuri asociate unui SRA cu regulator PID

Se cunoaşte expresia comenzii unui regulator PID în formă continuă
1
, 5.99
186
unde u este comanda;

u0 - comanda în absenţa abaterii;
e – abaterea;
Kp, Ti, Td – parametri de acordare.
Prin discretizare, apelând pentru calculul integralei la metoda

dreptunghiurilor; se obţine pentru pasul k
5.100
,
respectiv k-1
5.101
,
unde T reprezintă intervalul de eşantionare.

Prin scăderea relaţiei (5.101) din relaţia (5.100) rezultă:
2 , 5.102
sau după unele grupări convenabile se obţine relaţia de mai jos (5.103)
1 1 2 .
Din relaţia (5.103) se observă că valoarea pasului curent al comenzii

depinde de valoarea acesteia aferentă pasului anterior şi de valorile
, , .
abaterii e pentru trei paşi consecutivi, respectiv
Introducând notaţiile (5.104)
(5.104)
1 2
187
relaţia (5.103) devine
· · · 5.105
Pentru implementarea relaţiei (5.105) aferentă determinării comenzii

regulatorului PID în formă incrementală se poate construi taskul REG_PID a
cărui schemă logică se prezintă în figura 5.33.
Initializare task
REG_PID
SEMEX=1, stabileşte valori
iniţiale pentru UC, UA, EC,
EA, EAA.
Nu
∆t=T ?
Da
P(SEMEX)
Preia din BDP EAA=UA

I, CC, CA, CAA
V(SEMEX) EAA=EA
Achiziţioneză R UA=UC
EC = I-R
· ·
Transfera UC
la EE via SEA
Fig. 5.33. Schema logică asociată taskului REG_PID.

188
Examinând figura 5.33 se observă că taskul REG_PID este sincronizat

cu timpul, intervalul de execuţie fiind T, respectiv intervalul de eşantionare din
relaţiile (5.100)…(5.103). Referinţa I şi coeficienţii CC, CA, CAA se preiau din
baza de date de proces BDP în cadrul unei secţiuni critice, excluderea mutuală
fiind implementată cu semaforul binar SEMEX . Semnalul de reacţie R şi
comanda calculată UC se achiziţionează de la traductor, respectiv se distribuie la
EE prin intermediul subsistemului ieşirilor analogice SEA.
Operarea regulatorului se realizează prin taskul consolă CNS_OP a cărui
schemă logică este prezentată în figura 5.34.
Initializare task
CNS_OP
SEMEX=1, stabileşte valori
iniţiale pentru I, CC, EA, CAA.
Nu
Tast ?
V(SEMEX)
Da
Da
P? Modif Kp Transfera I,
Nu CC, CA, CAA
în BDP
Da
I? Modif Ti
Nu
P(SEMEX)
Da
D? Modif Td
Nu
Calculează
CC, CA, CAA
Da
R? Modif I
Nu
Nu
E?
Da Fig. 5.34. Schema logică asociată taskului
CONS_OP.
EXIT
189
Din figura 5.34 reiese că taskul CNS_OP este sincronizat cu un

eveniment extern legat de apăsarea unei taste sau acţionarea unui buton virtual.
La introducerea uneia dintre comenzile P, I sau D se execută procedurile de
modificare a parametrilor de acordare Kp, Ti respectiv Td, urmate fiecare de
secvenţa de recalculare a coeficienţilor CC, CA şi CAA. Dacă se acţionează
tasta R se iniţiază procedura de modificare a referinţei I. Taskul CNS_OP oferă
şi posibilitatea opririi programului la apăsarea tastei E.
Indiferent de parametrul modificat se transferă în BDP referinţa şi cei
trei coeficienţi. Ca şi în taskul REG_PID accesul la BDP se face într-o secţiune
critică, pentru excluderea mutuală fiind utilizat tot semaforul binar SEMEX.
5.2.2. Taskuri asociate unui SRA cu regulator bipoziţional

Spre deosebire de regulatorul PID regulatorul bipoziţional prezintă
pentru mărimea de comandă numai două valori de tipul totul sau nimic. În figura
5.35 este prezentată structura unui SRA temperatură cu regulatorul TC
bipoziţional.
Qr TT
Qr Tm
Tm
TC
Tref u T
2 EE Proces
TC m
1 (W)
r
Tref TT
220 V
50 Hz
a) b)
Fig. 5.35. Scheme ale SRA temperatura bipoziţional: a - schema principiala; b -
schema de structura; 1 – încălzitor electric; 2 – serpentină evacuare căldură; Tref,
T - temperatura prescrisă, respectiv reglată; u - mărime de comanda (stare
contact); m - mărime de execu ie (debit caloric W); Tm – temperatură ambiantă;
Qr – debit agent răcire.
Acesta va conecta sau după caz va deconecta încălzitorul electric 1 funcţie de

valoarea curentă a temperaturii T în raport cu starea de referinţă Tref.
Perturbaţiile principale sunt reprezentate de temperatura ambiantă Tm şi de
debitul Qr prin serpentina de evacuare a căldurii 2.
Regulatorul TC prezintă o caracteristică de tip releu cu hysterezis
ilustrată în figura 5.36 şi descrisă de relaţia (5.106).
190
u HYST
CON
DECON
T
Tmin Tref Tmax
Fig. 5.36. Caracteristica statică a unui regulator bipozi ional: u – comandă;

HYST – lă ime a benzii de hysterezis, Ti – temperatură prescrisă; Tmin, Tmax
– limite minimă respectiv maximă permise pentru temperatura reglată.
ă 1
.
ă 1
5.106
În relaţia (5.106) Tmin şi Tmax se calculează cu relaţiile
5.107
2
5.108
2
HYST reprezintă lăţimea benzii de hysterezis.
Funcţionarea SRA poate fi uşor înţeleasă pe baza caracteristicilor

dinamice din figura 5.37. La cuplarea sistemului, in situaţia To < Tref
regulatorul va comanda conectarea (comanda CON) rezistenţei de încălzire 1.
Temperatura va începe să crească, iar in momentul in care va atinge valoarea
Tmax se va comanda deconectarea (comanda DECON) rezistenţei de încălzire.
Ca urmare, temperatura va începe sa scadă, iar la atingerea valorii Tmin se va
produce recuplarea rezistentei de încălzire.
191
u
CON
a)
DECON
t
T
Tmax
Tref
Tmin HYST
T0 b)
Fig. 5.37. Caracteristici dinamice asociate SRA temperatură cu regulator

bipoziţional: a – variaţia în timp a comenzii u; b – variaţia în timp a
temperaturii reglate T.
Examinând caracteristica din figura 5.37 a se observă că regimul

permanent este unul oscilant în jurul valorii Tref cu amplitudinea HYST/2.
Pentru creşterea preciziei de reglare ar trebui micşorată lăţimea benzii de
hysterezis HYST, ceea ce va determina o creştere a frecvenţei de comutare cu
implicaţii negative în ceea ce priveşte fiabilitatea regulatorului.
În realitate, datorita inerţiei procesului, temperatura va continua sa crească
şi după decuplarea rezistentei, respectiv să scadă şi după recuplarea acesteia.
Pentru a se respecta limitele pentru temperatura T, comenzile CON şi DECON
vor trebui anticipate, astfel încât comutările să se producă la Tmin respectiv
Tmax.
Pentru implementarea algoritmului de reglare bipoziţională a temperaturii
se propune taskul REG_BP a cărui schemă logică este evidenţiată în figura 5.38.
Din figura 5.52 reiese că taskul REG_BP este sincronizat cu timpul, intervalul
de execuţie fiind Tcom. Valorile limită Tmin şi Tmax se preiau din baza de date
de proces BDP în cadrul unei secţiuni critice, excluderea mutuală fiind
implementată cu semaforul binar SEMEX . Semnalul de reacţie R corespunzător
temperaturii reglate T se achiziţionează de la traductorul de temperatură iar
comanda U (CON sau DECON) se transmite întrerupătorului care conectează
respectiv deconectează încălzitorul electric prin intermediul subsistemului
ieşirilor numerice al sistemului de interfaţă cu procesul.
Analizând schema logică din figura 5.38 se observă că se poate comanda
închiderea întrerupătorului (comanda CON), deschiderea întrerupătorului
(comanda DECON) sau se poate menţine starea acestuia dacă
.
192
Initializare task
REG_BP
SEMEX=1, determină valoarea
iniţială UC pentru comanda U
Nu
∆t=Tcom ?
Da
P(SEMEX)
Preia din BDP

Tmin, Tmax
V(SEMEX)
Achizi ionează R
i calculează T
Nu Da
T ≤ Tmin ?
Nu
T ≥ Tmax ?
Da
U = DECON U= CON
Transmite U la EE
via SEN
Fig. 4.38. Schema logică asociată taskului REG_BP.
Al doilea task asociat SRA temperatură cu regulator

bipoziţional este taskul care CNS_BP a cărui schemă logică se
prezintă în figura 5.39.
193
Ini ializare task

CNS_BP
SEMEX=1, stabileşte valori iniţiale
pentru Tref, Hyst, Tmin, Tmax.
Nu
Tast ?
V(SEMEX)
Da
Da
I? Modif Tref
Transfera
Nu Tmin, Tmax
Da în BDP
H? Modif Hyst
Nu
P(SEMEX)
Nu
E?
Da Calculează
Tmin, Tmax
EXIT
Fig. 5.39. Schema logică asociată taskului CNS_BP.
Din figura 5.39 reiese că taskul CNS_BP este sincronizat cu un

eveniment extern legat de apăsarea unei taste sau acţionarea unui buton virtual.
La introducerea uneia dintre comenzile I sau H se execută procedurile de
modificare a referinţei Tref sau lăţimii benzii de hysterezis Hyst. Fiecare
modificare este urmată de recalcularea valorilor limită Tmin şi Tmax. Programul
poate fi oprit din taskul CNS_BP prin apăsarea tastei E.
Indiferent care parametru se modifică, valorile calculate pentru Tmin şi
Tmax se transferă în BDP în cadrul unei secţiuni critice. Accesul în această
secţiune este reglementat prin excludere mutuală implementat cu semaforul
binar SEMEX, utilizat în acelaşi scop şi în taskul REG_BP.
5.2.3. Taskuri asociate unui SRA cascadă
Reglarea în cascadă presupune, potrivit reprezentării din figura

5.40, existenţa unui regulator principal C1 a cărui mărime de comandă
se aplică nu direct unui element de execuţie ci unui SRA, care
conţine regulatorul C2, în calitate de referinţă externă.
194
Bucla de reglare care conţine regulatorul C1 se numeşte buclă

exterioară sau coordonatoare, iar cea care conţine regulatorul C2
constituie bucla interioară sau subordonată. Din punctul de vedere al
inerţiei, bucla interioară trebuie să fie mai rapidă decât cea exterioară.
C1 C2 P2 P1
EC1 EC1
y1
i1* i1 e1 u1=i2 e2 u2 m y2
Tint BF1 BF2 EE SP2 SP1
+ - +
-
r2
T2
r1
T1
Fig. 4.40. Schema de structură a unui SRA cascadă.
Pentru a exemplifica funcţionalitatea unui SRA cascadă, în

figura 5.41 este prezentată schema principială a unui sistem de reglare
automată a temperaturii T la ieşirea unui cuptor tubular CT în cascadă
cu presiunea combustibilului Pc.
Qp T0 CT
r1
r2
Qa Pc PT
TT
u1=Pi Ti
Qc TC
PC
u2
RR
Fig. 5.41. Schema principială a unui SRA temperatură în cascadă cu presiunea

combustibilului: TT, PT- traductoare de temperatură, presiune; TC, PC - regulatoare
de temperatură, presiune; RR - robinet de reglare.
Pentru exemplul de mai sus regulatorul de temperatură TC este

coordonator, iar cel de presiune PC este subordonat, mărimea de comandă u1
fiind referinţă pentru acesta.
195
Taskul asociat SRA cascadă din figura 5.40, a cărui schemă logică este
ilustrată în figura 5.42 este sincronizat cu timpul, intervalul de execuţie Texec
fiind impus de inerţia SRA interior.
Initializare task
REG_CASCADA
K=1, SEMEX=1stabileşte valori
iniţiale pentru comenzile u1 şi u2
Nu
∆t=Texec ?
Da
1 2
K?
Selectare algoritm Selectare algoritm

regulator C1 regulator C2
P(SEMEX) i2 = u1
Preia din BDP

i1*
V(SEMEX)
Achizi ioneză
rk
K=2 ek = ik - rk K=1
Calculează Transfera u2
comanda uk
la EE via SEA
K =2?
Fig. 5.42. Schema logică asociată taskului REG_CASCADĂ.
196
Examinând schema logică din figura 5.56 se observă că cele două

comenzi se determină în cadrul aceleiaşi cuante de timp, pentru selecţia
algoritmilor aferenţi fiind utilizat contorul K. Preluarea referinţei i1* se face în
cadrul unei secţiuni critice, la care accesul se realizează prin excludere mutuală.
5.2.4. Taskuri asociate unui SRA cu acţiune combinată
După cum s-a arătat în primul capitol al lucrării de faţă la

nivelul automatizării convenţionale există două tipuri fundamentale de
SRA şi anume SRA cu acţiune după abatere (efect) şi SRA cu acţiune după
perturbaţie (cauză). Pentru a fructifica avantajele oferite cde cele două principii
de reglare şi a le diminua neajunsurile se utilizează reglarea combinată după
abatere şi perturbaţie.
Un asemenea SRA acţionează preventiv la modificarea perturbaţiilor
luate în considerare şi corectiv la modificarea celorlalte perturbaţii şi a referinţei.
În aceste condiţii la modificarea perturbaţiilor considerate nu există regim
tranzitoriu pentru mărimea reglată în timp ce modificarea altora determină un
regim staţionar pentru aceasta până la eliminarea diferenţei dintre aceasta şi
valoarea de referinţă.
p21…p2k…p2n
Tp21
.. ..
. .
Tp2k
r21
r2k
P2
i I
SP2 y2
CP
+
y
CA up ∑
+ P1
EC +
i e ua u m y1
- Tint +
BF ∑ EE SP1
+
-
ra
Ta
Fig. 5.43. Schema de structură a unui SRA combinat abatere – perturbaţie: CA , CP –

regulatoare abatere, perturbaţie, ∑ - sumator.
197
În figura 5.43 se prezintă schema de structură a unui SRA combinat

caracterizat de prezenţa a două regulatoare şi anume: CA cu acţiune după abatere
şi CP cu acţiune după perturbaţie. La modificarea uneia dintre perturbaţiile
p21…p2k regulatorul CP îşi va actualiza mărimea de comandă up iar la
modificarea altor perturbaţii va apare o abatere e ≠ 0 care va determina
actualizarea comenzii ua. În final comanda u care se aplică elementului de
execuţie va rezulta ca sumă a componentelor ua şi up.
Pentru a exemplifica funcţionalitatea unui SRA combinat , în
figura 5.44 este prezentată schema principială a unui sistem de reglare
combinată a temperaturii T la ieşirea unui cuptor tubular CT.
Qp T0 CT
FTa TTp
rp1 T
rp2
Ti I
… TCp Qc Qa TTa
up u ra
∑
TCa
RR Ti
ua
Fig. 5.44. Schema principială a unui SRA temperatură combinat cu acţiune după
abatere şi perturbaţie: TTa, TTp - traductoare de temperatură; FTp - traductor de
debit; TCa, Tcp - regulatoare de temperatură abatere, perturbaţie,; RR - robinet de
reglare, ∑ - sumator.
La variaţii ale debitului de produs Qp şi/sau temperaturii acestuia T0 ,

regulatorul TCp îşi va modifica mărimea de comandă up. La variaţii ale altor
perturbaţii va apărea o diferenţă între T şi Ti care va determina modificarea de
către regulatorul TCa a comenzii ua.
Taskul asociat SRA combinat din figura 5.57, a cărui schemă logică
este prezentată în figura 5.59 este sincronizat cu timpul, intervalul de execuţie
Texec fiind impus de inerţia procesului.
Examinând schema logică din figura 5.59 se observă că cele două
comenzi se determină în cadrul aceleiaşi cuante de timp, pentru selecţia
algoritmilor aferenţi fiind utilizat contorul K. Preluarea referinţei i se face în
cadrul unei secţiuni critice, la care accesul se realizează prin excludere mutuală.
198
Initializare task
REG_COMB
K=1, SEMEX=1stabileşte valori
iniţiale pentru comenzile ua şi up
Nu
∆t=Texec ? K=1
Da
1 2
K?
Selectare algoritm Selectare algoritm

regulator CA regulator CP
P(SEMEX) P(SEMEX)
Preia din BDP i Preia din BDP I
V(SEMEX) V(SEMEX)
Achiziţioneză ra Achiziţioneză ra,

via SIA r21…r2k via SIA
e = i - ra Calculează
comanda up
Calculează Transfera u
comanda ua
la EE via SEA
Nu Da
K=2 K =2? u = ua+up
Fig. 5.45. Schema logică asociată taskului REG_COMB.
199
5.2.5. Taskuri asociate unui SRA multivariabil
Un proces multivariabil este caracterizat de intrări şi ieşiri multiple. În

majoritatea cazurilor aceste procese sunt caracterizate de interacţiuni. Aceste
interacţiuni presupun modificarea mai multor ieşiri la modificarea unei singure
intrări.
Reglarea unui asemenea proces are ca principal obiectiv realizarea
decuplării, respectiv variaţia unei singure ieşiri atunci când este modificată o
referinţă.
În figura 5.46 se prezintă un SRA multivariabil cu acţiune după abatere în
care procesul este caracterizat de interacţiuni. Aceste interacţiuni sunt
concretizate de subprocesele SP21 şi SP12 care semnifică influenţarea ieşirii y2
de către mărimea de execuţie m1 şi a ieşirii y1 de către mărimea m2. Decuplarea
va trebui să elimine aceste interacţiuni, cu alte cuvinte comanda u1 va influenţa
numai ieşirea y1 iar comanda u2 numai ieşirea y2.
În acest scop reculatorul multivariabil RMV este structurat în patru
blocuri funcţionale care asigură compensări în vederea anulării efectelor produse
de subprocesele SP21 şi SP12.
.
T1
r1
-
i1 *
i1 e1 u11 u1 m1 y1
Ti1 BF11 ∑ EE1 SP11 ∑
+ + +
+
+
BF21 u21 SP21
RMV PROCES
BF12 u12 SP12
+ +
i2 *
i2 + u2 + y2
Ti2 BF22 u22 ∑ EE2 SP22 ∑
+ e2 m2
-
r2
T2
Fig. 4.46. Schema de structură a unui SRA multivariabil: RMV – regulator

multifuncţional; BF11…BF22 – blocuri funcţionale ale RMV, SP11 – SP22 -
subprocese , ∑ - sumatoare.
După cum indică figura 5.46 comenzile u1 şi u2 se formează potrivit relaţiilor de

mai jos
200
1 11 21 ; 5.109
2 22 12. 5.110
În relaţiile (5.109) şi (5.109) într-o componentă de forma uKJ indicele

K este asociat canalului destinaţie iar indicele J canalului sursă.
Pentru a exemplifica funcţionalitatea unui SRA multivariabil ,
în figura 5.47 este prezentată schema principială a unui sistem de
reglare multivariabilă a compoziţiilor produselor extrase la vârful şi
baza unei coloane de fracţionare binară.
P PC Pi
AT xD
HVR
Li
xDi FC
RMV LC
xBi L(t) HVRi
Bi FC
F xF LC
HBi D, xD
HB FC
Qab
AT B B, xB
FC
Fig. 5.47. Schema principială a unui SRA concentraţie multivariabil: RMV – regulator
multivariabil; xDi, xBi – referinţe pentru SRA compoziţie produse vârf şi bază.
Regulatorul RMV este astfel proiectat încât să asigure numai

modificarea compoziţiei pentru care s-a schimbat referinţa (de exemplu la
creşterea specificaţiei xDi să se modifice corespunzător numai concentraţia xD
nu şi xB.
Taskul asociat SRA multivariabil combinat din figura 5.46, a cărui
schemă logică este prezentată în figura 5.48 este sincronizat cu timpul,
intervalul de execuţie Texec fiind impus şi în acest caz de inerţia procesului.
201
Initializare task
REG_MULTIVAR
J=1, SEMEX=1stabileşte valori
iniţiale pentru comenzile u1 şi u2
Nu
∆t=Texec ?
Da
P(SEMEX)
Preia din BDP iJ
V(SEMEX)
Achiziţioneză rJ
via SIA
eJ = iJ - rJ
K=1
K=1 Transferă u1 şi u2
la EE via SEA
Selectare algoritm
J=2 regulator cKJ u2 = u21+u22
K=2 Calculează u1 = u11+u12

comanda uKJ
Nu
Da Nu
K =1? J=1?
Da
Fig. 4.48. Schema logică asociată taskului REG_MULTIVAR.
202
Examinând schema logică din figura 5.62 se observă că toate

componentele celor două comenzi se determină în cadrul aceleiaşi cuante de
timp, pentru selecţia algoritmilor aferenţi fiind utilizate variabilele de tip contor
K şi J. Preluarea referinţei i1 şi i2 se face în cadrul unei secţiuni critice, la care
accesul se realizează prin excludere mutuală.
Al doilea task asociat SRA multivariabil este taskul care
CNS_MULTIVAR a cărui schemă logică se prezintă în figura 5.49.
Iniţializare task
CNS_MULTIVAR
SEMEX=1, stabileşte valori iniţiale
pentru i1, i2,
Nu
Tast ?
V(SEMEX)
Da
Da
I? Modif i1*
Transfera
Nu i1, i2
Da în BDP
J? Modif i2*
Nu
P(SEMEX)
Nu
E?
Da Calculează
i1, i2
EXIT
Fig. 4.49. Schema logică asociată taskului CNS_MULTIVAR.
Acest task este sincronizat cu un eveniment extern legat de apăsarea unei

taste sau acţionarea unui buton virtual. La introducerea uneia dintre comenzile I
sau J se execută procedurile de modificare a referinţelor, exprimate în unităţi
ale mărimilor reglate, i1* sau i2* . Indiferent de modificare, în continuare se
recalculează referinţele, exprimate în unităţi în care se calculează comenzile, i1
şi i2. Practic această ultimă procedură este asociată traductoarelor de intrare
Ti1 şi Ti2.
203
Indiferent de referinţa modificată , se transferă în BDP ambele referinţe

recalculate. Ca şi în taskul REG_MUTIVAR, accesul la BDP se face într-o
secţiune critică, pentru excluderea mutuală fiind utilizat tot semaforul binar
SEMEX.
5.3. Baze de date de proces
În general o bază de date reprezintă o mulţime de date organizate după

anumite criterii în scopul de a facilita prelucrarea acestora într-un anumit tip de
aplicaţii.
Aplicaţiile de conducere timp real impun prezenţa într-o bază de date
aferentă a datelor care privesc:
- cunoaşterea stării procesului;
- elaborarea mărimilor de comandă;
- adoptarea unor decizii de natură tehnico – economică legate de
proces.
O bază de date care conţine date organizate pentru a fi utilizate în
aplicaţii de conducere în timp real se numeşte bază de date de proces (BDP).
Aplicaţiile care privesc consultarea şi actualizarea unei BDP trebuie să fie
compatibile cu cerinţele impuse prelucrării în timp real. Cu alte cuvinte execuţia
celor două tipuri de aplicaţii nu trebuie să determine întârzieri peste limitele
admise.
Un sistem de gestiune aferent unei BDP trebuie să răspundă
următoarelor cerinţe importante:
- să asigure securitatea datelor;
- să asigure integritatea datelor;
- să asigure independenţa datelor.
Cerinţa de securitate impune existenţa de proceduri care să permită
accesul la date numai pentru persoanele şi/sau programele autorizate. Aceste
proceduri impun implementarea unui sistem adecvat de chei de acces, parole,
etc. Tot pentru securitate se poate apela la criptarea datelor, însă trebuie să se
ţină cont că operaţiile de criptare/decriptare sunt consumatoare de timp.
Cerinţa de integritate presupune protecţia datelor la o funcţionare
necorespunzătoare a echipamentului pe care rulează aplicaţiile sau chiar a
programelor aferente acestor aplicaţii. O posibilitate de asigurare a acestei
cerinţe o reprezintă crearea copiilor de siguranţă pentru BDP.
Cerinţa de independenţă implică adoptarea unor structuri de descriere a
datelor care să nu implice schimbări ale acestora la înlocuirea sau modificarea
programelor aferente aplicaţiilor de conducere.
Într-o BDP sunt uzual cuprinse următoarele categorii de date:
204
a) date din proces în cadrul fişierelor istorice ale valorilor

parametrilor;
b) comenzi aplicate procesului în cadrul fişierelor istorice ale valorilor
comenzilor;
c) evenimente semnificative din proces în cadrul jurnalului
evenimentelor;
d) adrese ale perifericelor de proces (traductoare şi elemente de
execuţie);
e) referinţe şi parametri de acordare pentru regulatoarele automate
după abatere;
f) parametri de acordare a modelelor aferente automatizării avansate;
g) intervenţii ale personalului de operare, în cadrul jurnalelor de
intervenţii;
h) date privind funcţionalitate sistemului de conducere în timp real.
În evoluţia unei BDP intervin următoarele etape:

a) structurarea bazei de date;
b) încărcarea datelor în bază;
c) actualizarea datelor în bază.
Structurarea BDP implică adoptarea de structuri pentru organizarea
datelor, definirea atributelor şi a tabelelor etc.
Încărcarea datelor se referă la datele din categoriile d, e, f din
enumerarea de mai sus şi este realizată la iniţializarea sistemului programelor de
conducere.
Actualizarea datelor se realizează prin funcţiile achiziţie date, generare
comenzi, intervenţii operator.
Din punctul de vedere al amplasamentului secţiuni ale BDP se pot găsi
în memoria primară sau secundară (pe harddisk sau suporturi externe). În
memoria primară sunt locate datele a căror schimbare se realizează cu o
frecvenţă ridicată, cum ar fi de exemplu referinţele regulatoarelor după abatere.
Pe harddisk sunt păstrate date asociate evoluţiei procesului (parametri, comenzi,
evenimente), însă nu pentru perioade îndelungate. Pentru perioade de timp mari
datele se arhivează şi se transferă pe suporturi externe magnetice sau optice.
205

Curs Apd PDF

Încărcat de

Drepturi de autor:

Formate disponibile

S-ar putea să vă placă și

Curs Apd PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curs Apd PDF

Încărcat de

Drepturi de autor:

Formate disponibile

NICOLAE PARASCHIV

UNIVERSITATEA PETROL – GAZE DIN PLOIEŞTI

CAPITOLUL Problematica sistemelor

1.1. Funcţiile automatizării proceselor

Obiective Comenzi Rezultate

Fig. 1.1. Sistem de conducere deschis: MC – mijloc de

Existenţa unor perturbaţii care acţionează asupra OC independent de

Obiective Comenzi Rezultate

Fig. 1.2. Sistem de conducere cu acţiune după efect.

Caracterul corectiv este dat de faptul că prin acţiunea comenzilor

Obiective Comenzi Rezultate

Fig. 1.3. Sistem de conducere cu acţiune după cauză.

La un asemenea sistem comenzile sunt astfel determinate încât la

Obiective Comenzi Rezultate

Fig. 1.4. Sistem de conducere cu acţiune după efect şi după cauză.

Sistemul acţionează după cauză (respectiv preventiv) la modificarea

Este de menţionat faptul că pentru primele trei fucţii apar constrîngeri

- structura parţial distribuită, în care există câte un IV pentru fiecare

1.1.2. Reglarea automată

Fig. 1.5. Schema bloc simplificată de structură a unui SRA:

O altă structurare identifică la nivelul unui SRA o parte fixată şi una

Parte variabilă Parte fixată

Parte variabilă Parte fixată

Fig. 1.6. SRA cu evidenţierea părţilor fixată şi variabilă:

Este important de subliniat că din punctul de vedere al echipamentelor

În figura 1.7 se prezintă structura unui sistem ierarhic organizat pe două

SP1 SP2 SPn

Fig. 1.7. Structura unui sistem de conducere ierarhizată:

1.1.3. Protecţia automată

Sistemele automate de avertizare (SAA) informează personalul de

P1lim Pklim Pnlim

Parametri din proces

Funcţie de situaţia semnalată avertizarea poate fi: de poziţie, de

reglării convenţionale. plicarea către un caz particular al conducerii prin fixarea

1.2. Tipuri de aplicaţii în timp real

- procesarea comenzilor în vederea transmiterii către elementele de

Procesare Date Procesare

SEN SIA SEA

Din analiza figurii 1.9 se observă că sistemul de interfaţă se situează la

Pentru exemplificare în figura 1.10, se prezintă structura unui sistem

MGT MMT MATk SGBD

Fig. 1.10. Structura unui sistem de tranzacţionare în timp real: BDST-baza

După cum se observă din figura 1.10 sistemul tranzacţional implică

1.3. Trăsături specifice ale sistemelor de operare în timp

- servicii comune pentru programe aplicative;

În contextul prelucrării în timp real unitatea funcţională elementară de

planificator într-o coadă de aşteptare, care poate fi organizată funcţie de

singur task. Pentru a se putea realiza execuţia funcţie de priorităţi taskurile

se utilizează un asemenea tampon cererea de intrare-ieşire este plasată într-un şir

1.4. Obiectivele şi principiile ingineriei programării în

marca modificări ale obiectivelor, a strategiei de conducere şi implicit a

regulă într-o structură ierarhic , fiecare nivel reprezintă o abstractizare a

 Codificarea presupune generarea programelor pentru modulele

Start dezvoltare aplicaţie

Încheiere dezvoltare aplicaţie

Pe parcursul derulării etapelor de mai sus repartiţia aproximativă a

Costurile operaţiilor de întreţinere le pot depăşi pe cele de elaborare.

Pe parcursul diverselor etape, sunt implicaţi, în ordine; următoarele