Patr Complet

Programarea aplicaţiilor de timp real
MODULUL A DE STUDIU
1. S i s t e m e d e c o n d u c e r e î n t i m p r e a l
2. M e c a n i s m e l e p r o g r a m ă r i i c o n c u r e n t e î n t i m p
real
Acest prim modul al cursului urmăreşte atingerea

următoarelor obiective:
 definirea comportării în timp real;

 caracterizarea sistemelor de conducere în
timp real;
 însuşirea obiectivelor şi principiilor ingineriei
programării în timp real;
 prezentarea stărilor şi a tranziţiei taskurilor;
 prezentarea principalelor instrumente de im-
plementare a operaţiilor multitasking
 înţelegerea necesităţii operaţiilor fundamen-
tale multitasking şi a posibilităţilor de imple-
mentare a acestora.
Cuvinte cheie: timp real, sistem de operare în timp

real multitasking, programare concurentă, ingineria
programării în timp real, excludere mutuală, sincro-
nizare, comunicare, semafor, cutie poştală, variabilă
de tip eveniment, stări ale taskurilor, tranziţii ale
taskurilor.
1
Modulul A
* *
2
CAPITOLUL
Sisteme de conducere
1 în timp real
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 teh-
nologice 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 aso-
ciate produselor sau serviciilor rezultate, mărimea beneficiilor rezultate
ca urmare a valorificării acestora, norme de protecţie a factorului
uman, a mediului şi a infrastructurii procesului.
Conducerea încadrează activitatea de dirijare a evoluţiei pro-
cesului î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 proce-
sului. Ansamblul celor două entităţi încadrează un sistem de conducere
(SC).
Dacă OC se află numai sub influenţa comenzilor şi are caracte-
ristici invariante în timp, este suficientă determinarea comenzilor ţi-
nând cont numai de obiective. După cum se observă din figura 1.1,
3
Modulul A
sistemul de conducere este deschis , mijlocul de conducere nefiind in-

format în legătură cu rezultatul acţiunilor sale.
Obiective Rezultate
Comenzi
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 indepen-

dent 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 co-
menzilor ş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 de natură corectivă.
Perturbaţii
Obiective Comenzi Rezultate

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

menzilor rezultatele sunt corectate în sensul că sunt readuse la nivelul
obiectivelor. În acest scop 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 corecti-
vă 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
neajuns al acţiunii preventive, determinat de faptul că există intervale
de timp în care rezultatele nu sunt în concordanţă cu obiectivele.
4
Dezavantajul identificat la SC cu acţiune corectivă este diminuat

dacă la elaborarea comenzilor, pe lângă obiective sunt avute în vedere
şi o parte dintre 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.
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, rezulta-
tele să nu se abată de la obiective. Acţiunea, care în acest caz este de
natură preventivă, are în vedere faptul că se previne apariţia unui efect
reprezentat de îndepărtarea rezultatelor de la obiective.
Dacă însă are loc modificarea unei perturbaţii care nu este con-
siderată de MC, rezultatele nu mai sunt conforme cu obiectivele, iar
acest efect nu mai poate fi îndepărtat, întrucât SC prezintă structură
deschisă în raport cu rezultatele.
Dezavantajele celor două tipuri de acţiune sunt parţial eliminate,
dacă se utilizează un SC cu acţiune mixtă după efect şi după cauză,
respectiv cu acţiune corectivă şi preventivă.

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 considerate. La modificarea altor perturbaţii
5
Modulul A
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ă.
Este de menţionat faptul că pentru primele trei funcţ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 aferente 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 exis-
tenţ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ţin microcontrollere
cu convertoare analog-numerice (CAN) încorporate. Sunt încă răspân-
dite traductoarele cu semnal de ieşire analogic în domeniu unificat
(uzual 4…20 mA).
6
Liniile de transmisie pentru semnale analogice sunt realizate în

exclusivitate din conductoare metalice. În cazul traductoarelor numeri-
ce (smart transducers), acestea sunt conectate în reţele în care transmi-
sia 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 indi-
catoarelor şi înregistratoarelor digitale. Instrumentele virtuale prezintă
practic utilizatorului o interfaţă grafică pe monitorul unui calculator,
unde valorile parametrilor sunt evidenţiata pe diferite tipuri de indica-
toare programate.
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 sis-
teme 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ă catego-
rie pot fi incluse SRA cu acţiune după abatere (efect) şi SRA cu acţiu-
ne după perturbaţie (cauză), considerate tipuri fundamentale de SRA
specifice nivelului automatizării convenţionale.
Pentru asigurarea funcţionalităţii, un SRA convenţional conţi-
ne 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 şi elemente de execuţie.
Este important de subliniat faptul că regulatorul elaborează şi transmi-
te comanda deci îndeplineşte rolul mijlocului de conducere din struc-
tura 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.
7
Modulul A
p1 pk pn
… a b
……
i P r1 rk
y ..
DA Pr
m I P y
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.
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ă

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

a - SRA abatere; b - SRA perturbaţie.
8
Este important de subliniat că din punctul de vedere al echipa-

mentelor numerice de conducere, traductoarele şi elementele de exe-
cuţie sunt considerate echipamente periferice de proces. Această înca-
drare are în vedere faptul că prin intermediul traductoarelor procesul
îşi face cunoscută starea, în timp ce elementele de execuţie implemen-
tează în proces comenzile elaborate de echipamentul numeric.
SRA cu structură evoluată (reglare avansată) au asociate ob-
iective specifice întregului proces (instalaţii). În cazul reglării avansa-
te, mărimile reglate sunt adesea reprezentate de parametri sintetici ale
căror valori se determină prin calcul. Prezenţa reglării avansate nu ex-
clude reglarea convenţională, cele două categorii coexistând în cadrul
sistemelor ierarhice de conducere.
1.1.3. Protecţia automată

Sistemele de protecţie automată (SPA) susţin realizarea obiec-
tivelor legate de securitate. Se au în vedere considerente legate de pro-
tecţ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ă catego-
rii importante şi anume:
- funcţii de informare;
- funcţii de intervenţie.
Funcţiile de informare sunt asigurate de către sistemele auto-
mate de avertizare, iar cele de intervenţie de către sistemele automate
de blocare şi comandă.
Sistemele de avertizare automată (SAA) informează personalul
de operare în legătură cu starea momentană a unui utilaj sau cu produ-
cerea unui eveniment. Aceste sisteme sunt cu structură deschisă, după
cum se observă din figura 1.7.
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 sta-
rea de funcţionare sau nu a unui utilaj. Avertizarea de prevenire va tre-
bui 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.
9
Modulul A
Limite de avertizare
P1lim Pklim Pnlim

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

Fig. 1.7. Structura unui sistem de avertizare (SAA) : BLC - bloc logic de coman-
dă; EAA – element acţionare avertizoare; AO - avertizor optic; AA - avertizor
acustic.
Sistemele de blocare automată (SBA) sunt cu structură închisă

şi determină scoaterea din funcţiune a unui utilaj sau secţiune din in-
stalaţie, întrucât nu s-a intervenit după avertizarea de prevenire. Este
de remarcat faptul că SBA acţionează numai la scoaterea din funcţiu-
ne, nu şi la repornire.
Sistemele de comandă automată (SCA) 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ă, condiţii care preced de exemplu cuplarea alimentă-
rii cu energie a utilajului respectiv. Tot la nivelul SCA se asigură opri-
rea normală a unui utilaj (nu în condiţii de avarie).
1.1.4. Optimizarea automată

Conducerea optimală, care asigură realizarea obiectivului de
eficienţă, presupune 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 reglării
convenţionale.
10
1.2. Tipuri de aplicaţii în timp real

Timpul real (TR) reprezintă o noţiune utilizată pentru caracte-
rizarea 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 MC sunt
emise la momentul oportun, respectiv dacă 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 con-
ducerea proceselor. Este o resursă esenţială deoarece toate mărimile
aferente unui proces sunt dependente de timp. Resursa timp este criti-
că 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 ope-
ratorului. Se poate aşadar stabili o legătură directă între inerţia proce-
sului ş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 cu-
noscută teorema lui Shannon 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ă nu
există un comportament universal ci unul 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 transmi-
terea de comenzi către un proces.
Pentru exemplificare în figura 1.8 se prezintă structura unei ast-
fel de aplicaţii, care permite realizarea următoarelor funcţii:
- achiziţii de date;
- procesarea datelor achiziţionate;
- actualizarea bazei de date de proces;
11
Modulul A
- elaborarea comenzilor;
- procesarea comenzilor în vederea transmiterii către elemente-
le de execuţie;
- generarea de rapoarte.
COP
MEC
BGR
CTR
BDP ABDP
Procesare Date Procesare

Comenzi
SDCN SADA SDCA
TA EEA
EEN PROCES
Fig. 1.8. Structura unui sistem de conducere în timp real:

BDP-baza de date de proces; BGR-bloc generare rapoarte; ABDP-modul actualizare a
BDP; MEC – modul elaborare comenzi; COP-consola operator; CTR – ceas de timp real;
SADA – subsistem de achiziţie a intrărilor analogice; SDCA, SDCN – subsistem de dis-
tribuţie a comenzilor analogice/numerice; TA- traductoare analogice; EEA - Elemente de
execuţie analogice; EEN – Elemente de execuţie numerice.
Din analiza figurii 1.8 se observă că sistemul de interfaţă cu sec-

ţiunile SADA, SADN şi SDCA se situează la limita sistemului de con-
ducere în timp real, în timp ce traductoarele şi elementele de execuţie
se află la limita procesului.
12
 Aplicaţiile tranzacţionale presupun rezolvarea unor solici-

tări pe care utilizatorii le adresează sistemului de timp real. Aceste so-
licitări sunt cunoscute sub denumirea de tranzacţii. Rezolvarea tranz-
acţ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.
Pentru exemplificare în figura 1.9, se prezintă structura unui
sistem tranzacţional, unde tranzacţiile sunt introduse de la mai multe
terminale.
MAT1
T1
MACU
T2
MGT MMT MATk SGBD
MATn BDST
Tn
Fig. 1.9. Structura unui sistem de tranzacţionare în timp real:

BDST-baza de date a sistemului tranzacţional ; SGBD – sistem de gestiune
a bazei de date;T1…Tn – terminale; MGT – modul gestiune terminale;
MMT- modul monitorizare tranzacţii; MACU – modul analiză comenzi
utilizatori; MAT1…MATn – module achitare tranzacţii.
După cum se observă din figura 1.9, 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.
13
Modulul A
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 impli-
cate 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ă asi-
gură următoarele funcţii importante:
- servicii comune pentru programe aplicative;
- planificarea şi coordonarea programelor aplicative.
În categoria serviciilor comune sunt de regulă incluse următoa-
rele 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, într-un sistem de timp real aplicaţiile
(taskurile) sunt într-o permanentă competiţie pentru deţinerea resurse-
lor sistemului. În acest context, componente ale software-ului de bază
trebuie să asigure alocarea pe baza unor criterii prestabilite a resurselor
importante ale echipamentului numeric respectiv: timpul unităţii cen-
trale 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ă cate-
14
gorie intră printre altele: mediile de dezvoltare, diagnosticare şi depa-

nare, generatoarele de cod şi de rapoarte etc.
Cea mai importantă componentă a resurselor software de bază
este reprezentată de (SO). În mod obişnuit un SO are două funcţii im-
portante ş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 (aplicaţii, taskuri) care trebuie 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ţi (tas-
kuri) aflate în diverse stadii sau stări.
În contextul prelucrării în timp real unitatea funcţională ele-
mentară 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 tasku-
rilor ş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 da-
telor din proces şi la transmiterea comenzilor către acesta, impune o
prelucrare paralelă sau cel puţin pseudoparalelă a taskurilor. Este cu-
noscut 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.
1
Engl. – scheduler
2
Engl. – time driven
3
Engl. – event driven
15
Modulul A
Un SOTR capabil să asigure o execuţie paralelă sau cel puţin

pseudoparalelă a taskurilor se numeşte Sistem de Operare în Timp
Real Multitasking – SOTRM.
Pe parcursul execuţiei lor, taskurile apelează proceduri sau ru-
tine 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 ve-
dere următoarele tipuri de gestiune:
- gestionarea timpului UCP;
- gestionarea alocării spaţiului de memorie internă;
- gestionarea echipamentelor 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 in-
ternă îşi dispută dreptul de utiliza UCP. Taskurile apte de a prelua con-
trolul UCP sunt dispuse de către 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 si-
tuaţ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 asoci-
ată unei operaţii de intrare-ieşire);
- o întrerupere de la ceasul de timp real;
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ă ne-
modificat pe durata existenţei taskului, sau variabil (care se poate schimba pe parcurs –
vezi funcţia RTK SetTaskPriority)
16
- apelarea de către taskul aflat în execuţie a unei funcţii reali-

zate 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 ri-
dicat din coada de aşteptare.
În cazul în care mai multe taskuri au aceiaşi prioritate, alocarea
UCP se poate realiza potrivit uneia dintre următoarelor strategii:
- primul intrat primul ieşit5 , conform căreia taskurile cu priori-
tate 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 taskurilor î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 ca-
re să fie organizată stiva proprie este o condiţie absolut necesară pen-
tru 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 t un sin-
gur task. Pentru a se putea realiza execuţia funcţie de priorităţi taskuri-
le 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
5
FIFO – First Input First Output
6
Engl – time sharing
17
Modulul A
plătit pentru acest avantaj este reprezentat de timpul consumat cu

transferurile, astfel încât timpul 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ărca-
rea în memorie a altor taskuri.
Strategia planificatorului implică transferul gestionării memo-
riei interne către taskul aflat în execuţie, respectiv către taskul care de-
ţine controlul UCP.
Strategia coexistenţei se caracterizează prin 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 peri-
ferice este controlat, reglementarea acestuia 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 transfe-
rul 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 (respectiv cu taskurile), realizând principial
următoarele funcţii importante:
- semnalarea stării perifericului (liber sau ocupat);
- transmiterea cererilor de intrare-ieşire către driverele echi-
pamentelor care vor fi implicate.
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).
18
La gestionarea operaţiilor de intrare-ieşire, trebuie avut în ve-

dere faptul că acestea se pot efectua cu sau fără implicarea unui tam-
pon de memorie. Dacă 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 în 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 pri-
vesc 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 tre-
ce un 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 orga-
nizarea ş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 dez-
voltate :
- obiective de adaptabilitate;
- obiective de fiabilitate;
- obiective de perceptibilitare.
19
Modulul A
 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) adaptabili-
tatea este impusă, printre altele de caracterul evolutiv al procesului,
evoluţie care poate 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 progra-
melor;
- minimizarea efortului pentru dezvoltarea programelor;
- minimizarea timpului necesar pentru dezvoltarea programe-
lor.
 Fiabilitatea programelor se referă la dezvoltarea de apti-
tudini 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ţa de instrumente şi resurse pentru înlăturarea defec-
telor, dacă acestea se manifestă pe parcursul funcţionării programelor.
Ca şi în cazul echipamentelor, fiabilitatea nu constituie un ada-
os ci se dezvoltă odată cu sistemul de programe.
 Perceptibilitatea se referă la aptitudinea care trebuie con-
ferită programelor de a fi uşor înţelese şi urmărite de către un alt pro-
gramator sau chiar de către autor, la un anumit interval după finaliza-
re8.
Pentru realizarea acestor obiective trebuie respectate o serie de
principii, între care o importanţă aparte prezintă următoarele:
- principiul modularizării;
8
Această obiectiv mai este cunoscut şi sub denumirea de claritate.
20
- principiul abstractizării;
- principiul localizării;
- principiul uniformităţii;
- principiul completitudinii;
- principiul confirmabilităţii;
- principiul acoperirii.
 Principiul modularizării. Modularizarea reprezintă manie-
ra în care trebuie structurat un program pentru a atinge mai uşor un
anumit scop. Modularizarea constituie un factor determinant pentru
satisfacerea obiectivelor de adaptabilitate şi fiabilitate.
 Principiul abstractizării impune identificarea proprietăţi-
lor comune unor entităţi aparent diferite şi omiterea unor detalii speci-
fice neesenţiale. De regulă într-o structură ierarhică , fiecare nivel re-
prezintă o abstractizare a nivelurilor inferioare, detaliile fiind păstrate
pe acestea.
 Principiul localizării se referă dispunerea în vecinătate fi-
zică 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 stabilirea notaţiilor.
 Principiul completitudinii are în vedere includerea în con-
ceptele abstracte a tuturor elementelor semnificative.
 Principiul confirmabilităţii afirmă necesitatea formulării
explicite a tuturor informaţiilor legate de posibilitatea verificării corec-
titudinii programelor.
 Principiul acoperirii promovează afirmarea aspectelor
esenţiale în favoarea celor neesenţiale, care pot fi transparente pentru
utilizator.
Un alt aspect specific IPTR este legat de fazele din existenţa
unui program respectiv:
- analiza cerinţelor;
- elaborarea specificaţiilor;
- proiectarea sistemului de programe;
21
Modulul A
- codificarea în program;
- instalarea şi testarea programelor;
- întreţinerea programelor.
 Analiza cerinţelor este o etapă în care beneficiarul colabo-
rează strâns cu echipa de analişti din partea elaboratorului produsului
informatic, în vederea identificării particularităţilor problemei care ur-
mează 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 opera-
re.
 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 comu-
nicare;
- datele de intrare şi rezultatele pentru fiecare modul;
- algoritmii care vor fi utilizaţi pentru implementarea cerinţe-
lor din tema de proiectare.
 Codificarea presupune generarea programelor pentru mo-
dulele 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 im-
puse fie de neconcordanţe în raport cu tema de proiectare, fie de reve-
niri ale beneficiarului.
Fiecare dintre etapele anterioare conţine câte o secvenţă de va-
lidare, promovarea la etapa următoare fiind condiţionată de validarea
celei precedente. După cum se observă din figura 1.10, î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.
22
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.10. Procesul iterativ asociat etapelor din existenţa

unui produs informatic.
Pe parcursul derulării etapelor de mai sus repartiţia aproxima-

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

borare. 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.
24
CAPITOLUL
Mecanismele programării
2 concurente în timp real
Execuţia aplicaţiilor de timp real impune ca acestea să fie dez-

voltate prin tehnici care să permită rezolvarea problemelor specifice
fără a se declanşa conflicte în utilizarea resurselor maşinii şi cu respec-
tarea constrângerilor de natură temporală.
În prezentul capitol se va realiza o prezentare a principalelor
mecanisme specifice programării în timp real.
2.1. Stările şi tranziţiile taskurilor

Aplicaţiile de timp real se dezvoltă apelând la programarea
paralelă sau concurentă. Două taskuri se numesc paralele sau concu-
rente9 dacă prima instrucţiune a unuia trebuie executată înainte de în-
cheierea 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 sisteme-
lor cu o singură UCP, execuţia este pseudoparalelă , timpul acesteia
fiind partajat între mai multe taskuri.
Execuţia intercalată a taskurilor presupune lucrul în întreruperi,
taskurile executându-se intercalat cu rutina de tratare a întreruperilor,
aspect evidenţiat în figura 2.1.
9
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.
25
Modulul A
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. 2.1. Execuţia intercalată a taskurilor.
În exemplul din figura 2.1a se consideră următoarea

semnificaţie a taskurilor:
- A – task de achiziţie date de la Convertorul Analog
Numeric - CAN (iniţiat de un semnal de întrerupere de la
CAN la încheierea conversiei);
- 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).
În figura 2.1 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ă);
26
- 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 2.2, o asemenea aplicaţie mai conţine taskuri sistem
şi taskuri utilizator.
Taskuri utilizator
Taskuri sistem
Nucleu SOTRM
Hardware
Fig. 2.2. Structura stratificată a unei aplicaţii de timp real.
Posibilitatea execuţiei unei aplicaţii de timp real implică exis-

tenţa în cadrul SOTRM a mecanismelor enumerate mai mai sus, res-
pectiv:
- salvarea şi restaurarea contextului taskurilor;
- excluderea mutuală;
- sincronizarea;
- comunicarea.
În mod obişnuit un task are asociate în memoria internă trei
secţiuni şi anume:
27
Modulul A
- secţiunea de date care conţine operanzi şi rezultate ;

- secţiunea de cod care conţine codul ce implementează al-
goritmul 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 evo-
luţiei lor utilizează resurse în comun şi fac schimb de date .
 Taskurile disjuncte sunt taskuri care nu interacţionează,
respectiv care nu utilizează resurse în comun şi nu fac schimb de date.
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ţiilor între stări şi/sau substări.
Execuţia unei aplicaţii de timp real presupune evoluţia taskuri-
lor într-un spaţiu al stărilor, în care tranziţiile sunt provocate de direc-
tive care pot fi emise de către planificator sau de către taskul aflat în
execuţie. În continuare va fi prezentată o variantă de abordare referi-
toare la stările şi tranziţiile taskurilor.
Conform acestei abordări 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.
Stările şi substările menţionate mai sus, împreună tranziţiile
posibile sunt ilustrate în graful din figura 2.3.
28
 Un task neinstalat este un task rezident în memoria internă

sau externă, necunoscut de către 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.
Aşteptare ACTIV
Aşteptare Preluare
GATA DE
BLOCAT EXECUŢIE EXECUŢIE
Continuare Eliberare ŢIEXECUŢ
IE
Stop forţat din Start Stop forţat din
alt task alt task
INACTIV Stop normal
Instalare Ştergere
NEINSTALAT
Fig. 2.3. Evoluţia taskurilor în spaţiul stărilor şi substărilor.
 Substarea execuţie corespunde situaţiei în care taskul deţi-

ne controlul UCP. La sistemele cu o singură unitate centra-
lă, 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:
- ciclic (ROUND – ROBIN) , taskurile fiind executate succe-
siv în interiorul unei cuante de timp sau până la terminarea
29
Modulul A
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șire.
Tranziţiile între stări şi substări se pot 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 Directive, contextul comutării fiind determinat de numele şi para-
metrii 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 2.3 ş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:
- parametri ai taskului (adresă de început, prioritate, identi-
ficator, nume, etc.);
- mărimea stivei;
- indicatori către alte taskuri.
30
 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 tasku-
lui în substarea Gata De Execuţie , se realizează prin directiva Start.
Această directivă semnifică practic un apel de rulare pentru respecti-
vul task.
 Tranziţia Gata De Execuţie – Execuţie se realizează
printr-o directivă de Preluare. După execuţia acestei directive contro-
lul este cedat taskului din prima poziţie a listei de aşteptare la procesor,
care poate fi organizată după priorităţi sau respectând principiul rotaţi-
ei.
 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ă).
 Tranziţia Execuţie – Blocat se realizează printr-o direc-
tivă 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 directi-
vă 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 aceas-
ta presupune menţinerea BDT pentru respectivul task.
31
Modulul A
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 afe-
rente rezolvării problemei interacţiunii dintre taskuri, operaţii care vor
fi tratate pe parcursul acestui capitol.
2.2. 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ă: exclude-
rea mutuală, sincronizarea şi comunicarea 10
Pentru implementarea acestor operaţii, sistemele de operare sau
executivele de timp real pun la dispoziţie instrumente cum ar fi: sema-
foare, cutii poştale, mesaje de trecere, variabile de tip eveniment, fani-
oane de excluziune, monitoare etc.
2.2.1. Resurse şi secţiuni critice
În general termenul de resursă desemnează orice element ne-
cesar unui task pentru a putea fi executat. Resursele pot fi materiale
şi/sau logice.
În rândul resurselor materiale pot fi considerate:
- procesorul;
- memoria internă;
- memoriile externe;
- dispozitivele de intrare / ieşire;
- ceasul de timp real;
- dispozitivele speciale.
În resursele logice pot fi incluse:
- rutinele (procedurile);
- masivele de date;
- fişierele;
- variabilele.
O altă clasificare divizează resursele în: resurse locale şi resur-
se comune.
10
În mod obişnuit acestea sunt cunoscute ca Operaţii Fundamentale Multitasking.
32
 Resursele locale sunt resursele care pot fi accesate de către

un singur task. Acestea pot fi în primul rând de natură logică (rutine,
fişiere, variabile), dar pot fi şi de natură fizică cum ar fi anumite dis-
pozitive 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ă (rutine, tampoa-
ne 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,
echipamentele de intrare - ieşire, subrutinele care îşi modifică pe par-
curs unele date proprii etc.
 O resursă comună care admite ca n sesiuni de lucru să fie
în derulare asupra sa la un moment dat (respectiv să poată fi accesată
de către n taskuri) se numeşte resursă partajabilă cu n puncte de in-
trare.
 O resursă comună care admite ca oricâte sesiuni de lucru
să fie în derulare la un moment dat se numeşte resursă reentrantă11.
Î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ţiuni-
lor critice. În acest sens se impune existenţa unor modalităţi de im-
plementare a excluderii mutuale.
Excluderea mutuală reprezintă operaţia de autorizare a acce-
sului unui singur task, la un moment dat, într-o secţiune critică referi-
toare la o resursă. Din această definiţie rezultă că dacă la un moment
dat un task se găseşte într-o secţiune proprie în care este accesată o
resursă critică, trebuie exclus accesul oricărui alt task într-o secţiune
critică proprie în care este accesată aceiaşi resursă.
11
Resursele reentrante pot fi considerate resurse partajabile cu n tinzând către infinit.
33
Modulul A
Referitor la implementarea excluderii mutuale sunt de menţio-

nat recomandările făcute de prof. Andrew Tanenbaum de la Universi-
tatea Vrijie din Amsterdam – Olanda, în anul 1987.
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 re-
lativă şi frecvenţa de execuţie a taskurilor (cu alte cuvinte la imple-
mentarea excluderii mutuale nu pot fi avute în vedere considerente le-
gate de frecvenţele sau vitezele de execuţie ale 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 du-
pă un interval finit de timp;
5 – taskurile nu se pot bloca în interiorul propriilor secţiuni cri-
tice.
În continuare vor fi prezentate câteva modalităţi de implemen-
tare a excluderii mutuale.
2.2.2. Excluderea mutuală realizată cu semafoare

Un semafor reprezintă, conform conceptului introdus în anul
1965 de către matematicianul olandez Edsger Wybe Dijkstra, un du-
blet format dintr-o variabilă de tip întreg I şi o coadă de aşteptare C,
respectiv
S  ( I ,C ). (2.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 gene-
ral.
Asupra semafoarelor pot fi efectuate două operaţii denumite
generic P (de la cuvântul olandez Passeren – a trece) şi V (de la cu-
vântul olandez Vrigeven – a elibera). Aceste funcţii sunt indivizibile12
12
Indivizibilitatea are în vedere faptul că cele două funcţii nu pot fi întrerupte.
34
şi se numesc primitive. În ceea ce priveşte coada de aşteptare , aceasta

poate fi gestionată conform principiului FIFO13, sau după priorităţi
(univoce sau neunuivoce).
Primitiva P(S) presupune realizarea următoarelor operaţii (ilus-
trate în organigrama din figura 2.4):
1 - I←I-1;
2 – dacă în urma operaţiei de la punctul 1 rezultă I  0 , funcţia
se încheie şi taskul în care aceasta se execută îşi continuă execuţia;
3 – dacă rezultă 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 execuţie a altui task.
I←I-1
DA NU
I≥0
Continuă execuţia Se scoate taskul apelant din rândul

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

trate în organigrama din figura 2.5):
1 - I←I+1;
2 – dacă în urma operaţiei de la punctul 1 rezultă I  0 , se de-
blochează taskul aflat pe prima poziţie în coada de aşteptare la semafor
13
FIFO - First Input First Output
35
Modulul A
şi se înscrie în rândul taskurilor gata de execuţie, după care se face

apel la dispecer, şi se continuă execuţia taskului apelant ;
3 – dacă rezultă 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 deblocat14.
Din definirea primitivelor P(S) şi V(S)15 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);
- dacă I ≤ 0 , atunci |I| reprezintă numărul de taskuri bloca-
te 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ă planificatorul

taskului apelant
Fig. 2.5. Execuţia primitivei V(S).
14
În figura 2.21 este surprinsă situaţia în care continuă execuţia taskului apelant, deci
taskul deblocat este adus în execuţie logică.
15
În exemplele vor urma prin incrementarea/decrementarea unui semafor se subînțelege
incrementarea/decrementarea variabilei întregi I asociate.
36
În figura 2.6 se prezintă excluderea mutuală a două taskuri rea-

lizată cu semafoare. Cele două taskuri sunt sincronizate cu timpul
intervalele prestabilite de execuţie fiind Δt_ex_T1, Δt_ex_T2. Pentru
excluderea mutuală este utilizat semaforul binar SEMEX, iniţializat cu
valoarea 1. În fiecare dintre taskurile T1 şi T2 care trebuie să se exclu-
dă 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).
Task T1 Task T2
Iniţializare T1 Iniţializare T2
…SEMEX=1… …SEMEX=1…
NU NU
Δt_ex_T1 ? Δt_ex_T2 ?
DA DA
P1_T1 P1_T2
P(SEMEX) P(SEMEX)
SEMEX=0 SCr_T1 SEMEX=0 SCr_T2
V(SEMEX) V(SEMEX)
P2_T1 P2_T2
Fig. 2.6. Excluderea mutuală cu semafoare:

P1_T1, …,P2_T2 - proceduri ale taskurilor T1 şi T2.
Este clar că în intervalul de timp în care un task se află în pro-

pria secţiune critică referitoare la o anumită resursă rezultă
SEMEX=0, aspect evidenţiat şi în figura 2.6. Î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.
37
Modulul A
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 SEMEX , va fi
deblocat16 şi va putea pătrunde la rândul său în propria secţiune critică.
Având în vedere că SEMEX este iniţializat cu valoarea 1, dacă
de exemplu, după iniţializare, pentru T1 se 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 direc-
tiva V(SEMEX). Ca urmare a acestei directive SEMEX va deveni 0
(zero) iar T2 va trece în starea gata de execuţie urmând a fi planificat
pentru execuţia secţiunii sale critice.
Din cele prezentate rezultă că prin utilizarea se poate realiza
excluderea mutuală, respectiv se poate asigura prezenţa unui singur
task la un moment dat în propria sa secţiune în care este accesată o
resursă critică.
2.2.3. Excluderea mutuală realizată cu variabile de tip

eveniment
O variabilă de tip eveniment este o variabilă logică de tip spe-
cială asupra căreia pot acţiona trei tipuri de primitive şi anume ÎN-
SCRIE, ŞTERGE şi AŞTEAPTĂ.
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 .
16
Pentru ca soluţia să fie funcţională, semaforul SEMEX nu trebuie aservit altor scopuri
în afara excluderii mutuale.
38
Este de menţionat faptul că primitiva ASTEAPTA se poate apli-

ca ş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 de tip eveniment (VTE) se ba-

zează pe utilizarea unei singure astfel de variabile, notată generic
EVEX şi care se iniţializează cu valoarea ADEVĂRAT. În fiecare task
care trebuie să se excludă mutual, înainte de intrarea în secţiunea criti-
că se va executa o secvenţă de directive ASTEAPTĂ (EVEX), ŞTER-
GE(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ţi-
unea 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 ÎN-
SCRIE(EVEX) va conduce la EVEX = ADEVĂRAT şi conform celor
precizate referitor la directiva AŞTEAPTĂ, primul task blocat la varia-
bila EVEX , va fi deblocat17 şi va putea pătrunde la rândul său în pro-
pria secţiune critică.
Ca exemplu, în figura 2.7 se prezintă schemele logice aferente
excluderii mutuale cu VTE a două taskuri T1, T2. Se observă că cele
două taskuri se execută la intervale prestabilite Δt_ex_T1, Δt_ex_T2,
respectiv sunt sincronizate cu timpul.
Având în vedere că variabila EVEX este iniţializată cu valoarea
ADEVĂRAT, dacă de exemplu pentru T1 se impune accesul în secţiu-
nea 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 variabila eveniment EVEX. De-
blocarea se va produce când T1 va termina de executat secţiunea sa
critică după care va executa directiva ÎNSCRIE(EVEX). Ca urmare a
17
Ca şi în cazul semafoarelor, variabila de tip eveniment EVEX va trebui utilizată numai
la implementarea excluderii mutuale.
39
Modulul A
execuţiei acestei directive EVEX va căpăta valoarea ADEVĂRAT şi

T2 va deveni executabil urmând a fi planificat pentru execuţia secţiunii
sale critice.
Task T1 Task T2
…EVEX=ADEV… …EVEX=ADEV…
NU NU
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
EVEX=FALS
EVEX=FALS
ÎNSCRIE(EVEX) ÎNSCRIE(EVEX)
P2_T1 P2_T2
Fig. 2.7. 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ă. După cum
reiese din figura 2.7, pe durata execuţiei unei secţiuni critice, în oricare
dintre taskuri EVEX=FALS.
40
2.2.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 un task poate depune mesaje, accesibile oricărui alt task. În
mod normal o CP se specifică prin numărul de poziţii din tamponul
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) sau prin intermediul cutiilor
poştale. Din punct de vedere al conţinutului, mesajele pot fi cu conţi-
nut 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ă blo-
carea taskurilor pe operaţii de depunere , atunci când CP este plină sau
pe operaţii de extragere atunci când CP este vidă. Cu alte cuvinte la
execuţia funcţiei PUT, taskul se blochează dacă nu există spaţiu dis-
ponibil, iar la execuţia funcției GET blocarea se produce dacă nu există
mesaj disponibil.
Excluderea mutuală cu cutii poştale presupune utilizarea unei
singure CP pe care o vom nota CPEX, în care primul task ce se iniţia-
lizează depune un mesaj simbolic, notat MESEX. Înainte de intrarea în
secţiunea critică fiecare task care trebuie să se excludă mutual va ex-
trage 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ţiu-
nea sa critică referitoare la o anumită resursă, cutia poştală CPEX este
41
Modulul A
vidă. În aceste condiţii orice alt task ce va dori să acceseze propria

secţiune critică referitoare la aceiaşi resursă, se va bloca la execuţia
funcţiei de preluare a mesajului simbolic. Deblocarea18 se va produce
în momentul în care CPEX va conţine din nou mesajul simbolic
MESEX.
Task T1 Task T2
PUT MESEX PUT MESEX

NU NU
SAU
Δt_ex_T1? Δt_ex_T2?
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. 2.8. Excluderea mutuală cu cutii poştale şi mesaje:

P1-T1, …,P2 -T2 - proceduri ale taskurilor T1 şi T2.
În figura 2.8 se prezintă schemele logice aferente excluderii

mutuale cu cutii poştale a două taskuri, T1şi T2. Ca şi în cazurile pre-
Utilizarea căsuţei poştală CPEX şi a mesajului MESEX trebuie să fie numai în excludere
18
mutuală. utilizată numai la implementarea excluderii mutuale.

42
cedente, cele două taskuri sunt sincronizate cu timpul, intervalele de

execuţie fiind Δt_ex_T1, Δt_ex_T2.
Având în vedere că la iniţializare cutia poştală CPEX va conţi-
ne 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 blocarea 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.
Ca urmare a acestei depuneri T2 va deveni executabil urmând a
fi planificat pentru execuţia secţiunii sale critice.
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ţi-
une în care este accesată o resursă critică.
2.2.5. Alte modalităţi de realizare a excluderii mutuale

În afara modalităţilor abordate de realizarea a excluderii mutu-
ale (EM), o importanţă practică prezintă şi altele, în cele ce urmează
fiind evidenţiate următoarele :
- EM prin dezactivarea întreruperilor;
- EM prin fanioane de excluziune;
- EM prin blocuri resursă;
- EM prin monitoare.
A. Realizarea EM prin dezactivarea întreruperilor. Această
metodă presupune inhibarea sistemului de întreruperi înainte de intra-
rea în secţiunea critică şi reactivarea acestuia după ieşirea din secţiu-
nea 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:
43
Modulul A
- 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 planifi-
catorului, 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 rezultă că nici o secţiune critică re-
feritoare la respectiva resursă nu este în execuţie;
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ştepta-
re C înregistrează taskurile care nu au putut accesa propriile resurse
critice referitoare la o resursă pusă în corespondenţă cu fanionul de
excluziune pasiv FE_P.
Utilizarea FE_A în cadrul implementării EM, referitoare la o
anumită resursă, presupune respectarea următoarelor reguli:
a – FE_A este asociat numai EM pentru resursa în cauză;
b – în situaţia în care FE_A rezultă că nici un task nu se află în
secţiunea sa critică;
44
c – dacă FE_A = 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(FE_A);
d1 – dacă operaţia TAS a găsit FE_A =1se realizează urmă-
toarele:
d11 – autoînscrierea taskului în coada C a FE-A;
d12 – autoeliminarea sa din rândul taskurilor gata de exe-
cuţie/execuţie;
d13 – autoblocarea şi autoînscrierea în lista taskurilor blo-
cate;
d14 – apelarea planificatorului;
d15 – reluarea după deblocare începând cu punctul d;
d2 – dacă operaţia TAS a găsit FE_A =0 se face FE_A =1
după care se intră în secţiunea critică;
e – la părăsirea secţiunii critice se va efectua următoarea sec-
venţă indivizibilă:
e1 – efectuarea operaţiei RES(FE_A);
e2 – deblocarea tuturor taskurilor înscrise în coada C şi reîn-
scrierea lor în rândul taskurilor rulabile.
C. Realizarea EM cu ajutorul blocurilor resursă. Un bloc re-
sursă este reprezentat de un triplet BR cu structura
BR  ( I ,C , In),
unde: I şi C păstrează semnificaţiile stabilite la descrierea semafoare-
lor;
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ă înregis-
trarea 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 semna-
lează o eroare, întrucât unei primitive P executată într-un task trebuie
45
Modulul A
să îi corespundă o primitivă V executată în acelaşi task.

D. Realizarea EM cu ajutorul monitoarelor
Conceptul de monitor a fost introdus Richard Hoare în 1974 ca
un 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 pro-
pria secţiune critică va face apel la procedura corespunzătoare a moni-
torului. Î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 acesteia.
În acest fel programatorul nu trebuie să fie preocupat de reali-
zarea EM ci de asigurarea prezenţei la un moment dat în monitor a
unui singur task
2.3. 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, mo-
nitorizare etc.). În această situaţie taskurile beneficiare trebuie să aş-
tepte încărcarea buffer-ului, după care în cadrul unei secţiuni critice să
preia 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 sincroni-
ză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.
46
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);
- 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 monitoa-
relor).
Din punctul de vedere al sincronizării cu timpul pot exista do-
uă situaţii, ilustrate în figura 2.9, şi anume:
- taskul aşteaptă expirarea unui interval de timp Δt după care
se execută (figura 2.9 a);
- taskul se execută în interiorul fiecărei cuantei de timp Δt
(figura 2.9 b).
Δt Δt Δt Δt Δt
t t
τ τ τ τ τ
a b
Fig. 2.9. Ilustrarea sincronizării 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 implemen-

tare a sincronizării.
47
Modulul A
2.3.1. Sincronizarea realizată cu semafoare

O primă abordare se referă la 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.10, î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 procedu-
ra P1.
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. 2.10. Utilizarea semafoarelor pentru sincronizarea a două taskuri:

P1_T1, P2_T2 - proceduri ale taskurilor T1 şi T2.
Sincronizarea se realizează cu ajutorul a doua semafoare binare

notate în figura 2.10 cu SEMSYNC1 şi SEMSYNC2 care în taskurile T1
şi T2 se iniţializează cu valorile 1 respectiv 0. În punctul de sincroni-
48
zare 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 deblo-
ca după ce T1 depăşeşte PS1 deoarece va executa directiva
V(SEMSYNC2).
Al doilea exemplu, ilustrat în figura 2.11, se referă la utilizarea
semafoarelor pentru sincronizarea unui task 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 supra-
veghează producerea evenimentului.
Task T0 Task T1
SEMSYNC=0 SEMSYNC=0
NU
P1_T1
EVEXT?
DA
P(SEMSYNC)
V(SEMSYNC)
P2_T1
Fig. 2.11. Utilizarea semafoarelor în pentru sincronizarea cu un eveniment

extern: P1_T1, …,P2_T1 proceduri ale taskului T1.
Semafoarele pot fi utilizate şi în sincronizarea taskurilor cu

timpul, în figura 2.12 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
49
Modulul A
funcţie de tip P la acelaşi semafor, rezultatul fiind acela că taskul T1

se va executa cu periodicitatea Δt_ex_T119 .
Task T0 Task T1
SEMSYNC=0 SEMSYNC=0
NU
Δt_ex_T1 ? P(SEMSYNC)
DA
P_T1
V(SEMSYNC)
Fig. 2.12. Utilizarea semafoarelor în pentru sincronizarea cu timpul:

P_T1 procedură a taskului T1.
2.3.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 aso-
ciate 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;
- T3 se sincronizează cu ansamblul celor două evenimente.
După cum se observă din figura 2.13, în care este ilustrată sin-
cronizarea celor trei taskuri, evenimentelor externe EVEX1 şi EVEX2 li
se asociază variabilele de tip eveniment VTE1 şi VTE2 iniţializate cu
valoarea FALS. În ceea ce priveşte taskul T3 execuţia sa este condiţio-
19
Timpul de execuţie al taskului T1 este inclus în acest interval.
50
nată de valoarea de adevăr a funcţiei F  VTE1  VTE2 asociată produ-

cerii celor două evenimente.
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. 2.13. 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.
2.3.3 Sincronizarea realizată cu mesaje şi cutii poştale

Cutiile poştale şi mesajele pot fi utilizate atât pentru imple-
mentarea sincronizării cu timpul, cât şi cu evenimente externe.
În cazul sincronizării cu timpul se utilizează de regulă aştepta-
rea temporizată la o cutie poştală vidă. Mesajele implicate sunt de re-
gulă 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.
51
Modulul A
O primă soluţie, ilustrată în figura 2.14, presupune existenţa a

două taskuri T1- cu rol de planificator şi T2 – care trebuie să se exe-
cute 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;
- 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 ? C1
NU
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. 2.14. Utilizarea cutiilor poştale pentru sincronizarea cu timpul:

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

1.1 – aşteaptă un interval de timp Δt (intervalul de sincroni-
zare) 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 confir-
mare 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ă fi-
xă care informează taskul planificator T1 în legătură cu funcţionalita-
tea taskului T2, care trebuie să se execute temporizat.
În ceea ce priveşte taskul T2 , acesta execută următoarea sec-

venţă:
2.1 – aşteaptă şi preia din cutia poştală C1 mesajul de sincro-
nizare 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
2.15.
Δt Δt Δt Δt
t
Ex. Ex. Ex. Ex.

Task Task Task Task
T2 T2 T2 T2
Fig. 2.15. Sincronizarea cu timpul: execuţia taskului T2 se face în
interiorul cuantei de timp Δt.
53
Modulul A
Este posibilă execuţia taskului T2 în afara cuantei Δt, conform

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

Task Task Task Task
T2 T2 T2 T2
exteriorul cuantei de timp Δt.
În această situaţie nu se mai impune existenţa taskului planifi-

cator 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 2.17 se prezintă structura adaptată a taskului T2 pentru acest
tip de sincronizare.
Task T2
Iniţializare T2
DA
Mes în C0 ?
PREIA Mes din C0

NU Fig. 2.17. Utilizarea unei cutii poştale
vide pentru sincronizarea cu timpul:
GET C0 – cutie poştală; P_T2 - procedură a
taskului T2.
C0
t=Δt ?
NU
DA
P_T2
Se observă că în acest caz nu se utilizează mesaje de sincroni-

zare şi de confirmare. Dacă se doreşte monitorizarea funcţionalităţii
54
taskului T2, atunci se menţine taskul T1 care va primi 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 2.18.
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. 2.18. Utilizarea cutiilor poştale pentru sincronizarea cu evenimente

externe: C0, C1, C2 – cutii poştale; P_T2 - procedură a taskului T2.
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 sincroni-
zare MES_SYNC.
55
Modulul A
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 elimi-
nat în situaţia în care nu se doreşte monitorizarea funcţionalităţii tasku-
lui T2, soluţia principială fiind prezentată în figura 2.19.
Task T2
Task T0
Iniţializare T2
Iniţializare T0
MES_EV
NU
NU în C0?
EV_EXT ?
DA
D
A
TRIMITE PUT PREIA
MES_EV GET MES_EV
în C0 din C0
C0
P_T2
Fig. 2.19. Utilizarea unei cutiilor poştale pentru sincronizarea cu evenimente

externe: C0 – cutie poştală ; P_T2 procedură ale taskului T2.
După cum se observă între două momente ale producerii eve-

nimentului extern EV_EXT taskurile T0 şi T2 sunt blocate după cum
urmează:
- T2 – la cutia poştală C0 în aşteptarea mesajului MES_EV
referitor la producerea evenimentului extern.
În aceste condiţii taskul T2 este deblocat în momentul în care
în cutia poştală C0 este depus MES_EV asociat producerii evenimen-
tului extern.
56
2.3.4. Sincronizarea prin monitoare blocuri de întâlnire

 La prezentarea excluderii mutuale a fost introdus concep-
tul 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 momen-
tul 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 înde-
plini, T2 va executa directiva SIGNAL(C), care va avea ca efect scoate-
rea 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)

Fig. 2.20. Exemplificarea tehnicii rendez-vous pentru sincroni-
zarea unui sistem de trei taskuri A, B, C.
57
Modulul A
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 2.20,
după care din nou drumurile lor se despart.
O astfel de problemă de sincronizare se rezolvă prin interme-
diul 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 vari-
abilă î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 în-
registrează 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 scade 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 în-
tâlnire. Dacă există taskuri care nu au ajuns în punctul de întâlnire în
timpul fixat, aceasta se contramandează şi taskurile deja sosite se de-
blochează. 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.
2.4. 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 schim-
bul de date între taskuri concretizat în operaţia de comunicare. Uzual
taskurile transferă datele 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 mecanis-
mul producător-consumator, taskurile putând fi din acest punct de ve-
dere
- taskuri de tip producător;
- taskuri de tip consumator.
58
Pentru facilitarea comunicării, sistemele de operare trebuie să

pună la dispoziţie instrumente specifice, unul dintre acestea fiind con-
ducta (pipe). O conductă reprezintă un tampon unidirecţional gestio-
nat conform principiului FIFO, în care un task producător depune me-
saje pe care le preia un task consumator.
Mecanismul de comunicare prin conductă trebuie să asigure
blocarea taskului producător care ajunge în faţa unei operaţii de scrie-
re ş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 2.21.
Taskul i Conducta 1
Conducta 2
Taskul j
Fig. 2.21. Ilustrarea comunicării prin conducte între două taskuri.
După cum se observă, Conducta 1 este deschisă la scriere pentru tas-

kul i şi la citire pentru taskul j, cu alte cuvinte cele două taskuri înde-
plinesc 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 tas-
kul i – consumator, taskul j – producător.
2.4.1. Utilizarea în comunicare a semafoarelor

În mod uzual semafoarele sunt utilizate pentru gestionarea ope-
raţiilor de înscriere respectiv de citire a mesajelor din conducte. În cele
ce urmează va fi prezentat un exemplu de comunicare, ilustrat princi-
pial în figura 2.22, prin intermediul unui buffer BUF.
59
Modulul A
NPROD BUF NCONS

N-1 N-1
. cdata
pdata . TCONS
TPROD .
2 2
1 1
0 0
Fig. 2.22. Gestionarea comunicării prin conducta BUF .
 Taskul TPROD produce în cadrul unei proceduri date

(pdata) pe care le înscrie în BUF.
 Datele (cdata) sunt extrase din BUF de către taskul
TCONS şi utilizate în cadrul unei proceduri.
La implementarea comunicării trebuie avute în vedere urmă-
toarele aspecte:
1 – TPROD trebuie să se blocheze atunci când BUF s-a um-
plut;
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.
Gestiunea corectă a buffer-ului BUF se va face cu ajutorul a do-
uă semafoare generale SPLIN şi SGOL (iniţializate cu valorile 0 res-
pectiv N) asociate încărcării respectiv descărcării acestuia. Fiecare
înscriere în BUF va presupune decrementarea semaforului SGOL res-
pectiv 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-
ţie20 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.2.2.
20
Buffer-ul BUF plin sau gol.
60
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) P1_TCONS
P(SGOL) V(SGOL)
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) P(SPLIN)
P2_TPROD P2_TCONS(cdata)
Fig. 2.23. Utilizarea semafoarelor în comunicare.

Tot pentru gestiunea încărcării / descărcării lui BUF sunt utili-
P1 T1, …,P2 T2 proceduri ale taskurilor T1
zate contoarele NPROD şi NCONS care parcurg ciclic valori de la 0 la
şi T2.
N-1 ceea ce asigură preluarea datelor conform strategiei FIFO.
După cum se observă din figura 2.23, în care sunt prezentate
61
Modulul A
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.
2.4.2. Utilizarea în comunicare a mesajelor şi cutiilor poştale
Mesajele de trecere şi cutiile poştale reprezintă alte două mijloa-
ce 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 toa-
te taskurile aferente aplicaţiei de timp real.
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 GET PUT
DA CP1
PREIA MES_CONF din CP1
P2_T1 P2_T2
Fig. 2.24. Utilizarea mesajelor de trecere şi a cutiilor poştale în comunicare.
62
În figura 2.24 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 trece-
re21 în timp ce Taskul T2 va trimite un mesaj simbolic de confirmare
MES_CONF prin intermediul cutiei poştale CP1.
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 blo-
chează până la depunerea acestuia în cutia poştală CP1.
21
Directivele cu care sunt operate mesajele de trecere sunt Send (pentru trimitere) şi
Receive (pentru recepţie).
63
Modulul A
Întrebări pentru
EA modulul A de studiu
1. Care sunt obiectivele unui proces ?

2. Care sunt funcţiile automatizării proceselor ?
3. Care element din structura unui dispozitiv de automatizare asigură
funcţia de comandă ?
4. Justificaţi denumirea alternativă timp util pentru noţiunea de timp re-
al.
5. Determinaţi frecvenţa minimă cu care trebuie achiziţionat un semnal
cu frecvenţa de 1 kHz pentru păstrarea consistenţei informaţionale.
6. Care sunt nivelurile de planificare a taskurilor în cadrul unui SOTR ?
7. Denumiţi două tipuri de aplicaţii de timp real.
8. Ce este un SOTRM ?
9. Care sunt obiectivele ingineriei programării în timp real ?
10. Care sunt fazele din existenţa unui program (aplicaţii) de timp real ?
11. Definiţi noţiunea de task.
12. Care sunt substările stării active ?
13. Din ce substare a stării active este posibilă tranziţia în substarea Exe-
cuţie ?
14. După ce tranziţie se creează blocul descriptor al taskului ?
15. Ce este o resursă critică ?
16. Care sunt operaţiile fundamentale multitasking ?
17. Ce este un semafor ?
18. Ce este o cutie poştală ?
64
19. Ce este o variabilă te tip eveniment ?

20. Ce presupune excluderea mutuală a taskurilor ?
21. Care sunt recomandările lui Tanenbaum pentru implementarea ex-
cluderii mutuale ?
22. Ce sunt taskurile disjuncte ?
23. Explicaţi utilizarea semafoarelor în implementarea operaţiilor
multitasking: excludere mutuală, sincronizare, comunicare .
24. Explicaţi utilizarea variabilelor de tip eveniment în implementarea
operaţiilor multitasking: excludere mutuală, sincronizare, comunica-
re.
25. Explicaţi utilizarea cutiilor poştale şi a mesajelor în implementarea
operaţiilor multitasking: excludere mutuală, sincronizare, comunica-
re.
65
Modulul A
Test de autoevaluare
pentru modulul A de
TA studiu
1. Care este diferenţa dintre conducerea corectivă şi cea preventivă ?

2. Ce obiectiv al unui proces este asigurat prin funcţia de protecţie auto-
mată ?
3. Care sunt funcţiile dispozitivului de automatizare din structura unui
SRA ?
4. Când prezintă un sistem de conducere comportare în timp real ?
5. Care este diferenţa dintre prelucrarea paralelă şi cea pseudoparalelă ?
6. În ce constă obiectivul de perceptibilitate al IPTR ?
7. Prezentaţi etapa de analiză din dezvoltarea unei aplicaţii informatice.
8. Explicaţi diferenţa dintre taskurile disjuncte şi cele interactive.
9. Ce factori influenţează evoluţia unui sistem de taskuri interactive ?
10. În ce situaţie se produce tranziţia Gata de execuţie – Blocat ?
11. Ce entităţi intervin în definirea unui semafor în caz general ?
12. În ce situaţie se produce blocarea unui task la execuţia unei operaţii de
tip P asupra unui semafor ?
13. Ce operaţie se execută asupra unui semaforului implicat în excluderea
mutuală după ieşirea din secțiunea critică ?
14. Ce presupune directiva ASTEAPTĂ aplicată unei variabile de tip
eveniment ?
15. Ce tip de mesaj se utilizează la excluderea mutuală implementată cu cu-
tii poştale ?
16. Explicaţi utilizarea cutiilor poştale pentru sincronizarea cu timpul ?
17. Ce valoare are un semafor utilizat în excludere mutuală pe durata execu-
ţiei secţiunii critice ?
66
18. Ce valoare are o variabilă de tip eveniment implicată în excludere mutu-

ală pe durata execuţiei secţiunii critice ?
19. Ce conţine o cutie poştală utilizată în excluderea mutuală în timpul exe-
cuţiei secţiunii critice ?
20. Care este diferenţa dintre comunicarea prin mesaje şi comunicarea prin
cutii poştale ?
67
Modulul A
* *
68
MODULUL B DE STUDIU
3. Resurse pentru programarea în timp real

4. Prelucrarea în timp real a informaţiei de
proces
Al doilea modul al cursului urmăreşte atingerea ur-

mătoarelor obiective:
 însuşirea cerinţelor şi caracteristicilor limbajelor de pro-
gramare în timp real;
 însuşirea caracteristicilor importante ale nucleului de
timp real RTK ;
 operarea cu familiile de funcţii RTK pentru administra-
rea taskurilor şi gestionarea timpului;
 operarea cu familiile de funcţii RTK pentru gestionarea
semafoarelor, cutiei poştale şi mesajelor de trecere;
 caracterizarea filtrării numerice şi a circuitului informa-
ţional într-o aplicaţie de conducere;
 caracterizarea operaţiilor de conversie în şi din unităţi
inginereşti în SNMD şi SNTD;
 caracterizarea bazelor de date de proces din punctul de
vedere al cerinţelor impuse SGBD şi tipurilor de date
conţinute.
Cuvinte cheie: limbaj de programare în timp real,

task în context RTK, semafoare, cutii poştale, mesaje
de trecere în context RTK, operaţii de prelucrare
primară a datelor achiziţionate şi a comenzilor elabo-
rate, baze de date de proces
69
Modulul B
* *
70
CAPITOLUL Resurse pentru
3 programarea în timp real
O etapă în existenţa unui sistem de programe în timp real o

constituie 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 caracteris-
tici unor cerinţe specifice.
În prezentul capitol vor fi analizate aceste cerinţe şi caracteris-
tici şi se va prezenta un mediu de programare în timp real.
3.1. Cerinţe şi caracteristici ale limbajelor de pro-

gramare în timp real
Limbajele de programare în timp real (LPTR) trebuie să prezin-
te caracteristici şi să ofere facilităţi care să răspundă în primul rând
problemelor ridicate de execuţia paralelă sau pseudoparalelă a taskuri-
lor.
3.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 meta-
limbaj presupune descrierea unor noţiuni cu ajutorul altora, care trebu-
ie la rândul lor definite, până se ajunge la definiţii în care intervin nu-
mai elementele de bază ale limbajului (adică acelea care au semnifica-
ţie intrinsecă, respectiv litere, cifre, semne speciale, cuvinte cheie ).
71
Modulul B
Aceste elemente sunt considerate atomice cărora li se alocă

simboluri terminale. Spre deosebire de elementele atomice, noţiunilor
sintactice care urmează a se defini li se alocă simboluri neterminale.
Metalimbajul de descriere reprezintă un limbaj pentru descrie-
rea construcţiilor altui limbaj. În continuare se vor prezenta succint
câteva elemente 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
definitorii al 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 3.1 şi se interpre-
tează în felul următor: o cifră se reprezintă cu ajutorul unuia dintre
simbolurile 0, 1, …, 9.
0 1 2 ... 8 9
Fig. 3.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.
72
Grafuri asemănătoare se obţin pentru noţiunile literă mică (mi-

nusculă) ş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
+
cifră
-
Fig. 3.2. Graf sintactic pentru noţiunea număr algebric.
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 3.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. 3.3. Graf sintactic pentru noţiunea nume.
Alături de descrierea pe care o realizează, metalimbajul contri-

buie şi la înţelegerea şi însuşirea rapidă a construcţiilor sintactice spe-
cifice 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 realiza-
re:
73
Modulul B
a) în program se introduc explicit structuri de date şi de cod

necesare efectuării serviciilor; introducerea explicită poate avea în ve-
dere şi utilizarea unor secvenţe în limbaj de asamblare pe lângă con-
strucţiile specifice LPTR (exemple de limbaje RTL/2, FORTH, etc.);
b) în biblioteca obiect a limbajului se află proceduri apelabi-
le 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ţin 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. ).
3.1.2. Cerinţe impuse LPTR

Principala cerinţă impusă LPTR o reprezintă desigur existenţa
de primitive care să implementeze operaţiile multitasking şi instrumen-
tele de implementare specifice.
În afara acestei cerinţe, un LPTR trebuie să satisfacă şi alte
exigenţe legate în principal de:
- 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 se
va executa aplicaţia dezvoltată. Cerinţa de eficienţă impune evident un
efort cât mai redus de dezvoltare şi un grad de utilizare cât mai ridicat
al resurselor maşinii ţintă.
74
 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 resur-
se (începând cu cuvinte cheie şi terminând cu facilităţi pentru modula-
rizare şi structurare) care să permită elaborarea, descrierea şi modifi-
carea 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 exe-
cutabil de tipul maşinii ţintă. În general portabilitatea contribuie la o
distribuire costurilor de elaborare la mai multe aplicaţii. Este de menţi-
onat 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 ţin-
tă.
3.1.3. Caracteristici alele LPTR

Cerinţelor de mai sus li se răspunde cu următoarele caracteris-
tici ale LPTR:
- structurare ;
- concurenţă ;
- programare la nivel fizic ;
- tratarea excepţiilor ;
- compilare separată
- existenţa unităţilor generice.
75
Modulul B
 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 de-
scrierea datelor şi a operaţiilor în care sunt implicate, într-o terminolo-
gie 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 apli-
cabile.
Abstractizarea presupune conferirea caracterului de generalita-
te pentru operaţiile şi funcţiile limbajului (în sensul apropierii de apli-
caţie şi de îndepărtare de maşină). Tipizarea reprezintă alături de as-
cundere o latură a abstractizării. Ascunderea presupune transparenţa
în ceea ce priveşte folosirea registrelor şi a locaţiilor de memorie pre-
cum şi a transferurilor interne.
Vizibilitatea precizează zonele din program în care o entitate
identificabilă printr-un nume este vizibilă, respectiv poate fi modifica-
tă.
 Structurile de date (SD) pot fi statice sau dinamice. Cele
statice pot fi la rândul lor simple sau compuse.
SD statice 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).
SD statice compuse sunt tipurile de date cu mai multe compo-
nente (exemple: şiruri, matrice, etc.). Acestea pot fi referite atât glo-
bal, cât şi pe componente. Ca SD compuse s-au impus tabloul (care
grupează componente de acelaşi tip) şi articolul (care grupează com-
ponente 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.
76
 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 iterati-
vă cu un număr necunoscut de paşi.
Structura de bloc are în vedere abandonarea conceptului de
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 mo-
dule program. Concepute iniţial pentru a evita repetarea codului pro-
cedurile sunt implicate în limbajele evoluate în structurarea programe-
lor.
În ultimă instanţă un program bine structurat va reprezenta o
succesiune de apeluri de proceduri. Lucrul cu proceduri permite pro-
iectarea 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 varia-
bilelor implicate.
 Concurenţa
Programarea concurentă este acel stil de programare care
permite implementarea prelucrării paralele sau pseudoparalele a date-
lor.
77
Modulul B
Având în vedere cele două laturi ale concurenţei (paralelismul

şi interacţiunea), LPTR trebuie să ofere instrumente care să ofere po-
sibilitatea tranziţiei taskurilor între stări şi substări precum şi imple-
mentarea 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ţi-
alitate, asincronism, dinamism.
Excluderea mutuală prezentată pe larg în capitolul precedent
presupune interzicerea execuţiei paralele a secţiunilor critice referitoa-
re 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 coordona-
re a execuţiei acestora în raport cu timpul sau cu evenimente externe.
LPTR trebuie să ofere mijloace care să implementeze nu numai corela-
rea cu timpul sau cu evenimente ci şi stabilitatea acestei relaţii.
De asemenea trebuie create posibilităţi pentru realizarea sin-
croniză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 finali-
za o anumită activitate;
- sincronizarea cu timpul presupune că evenimentele cu ca-
re 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 zo-
nă accesibilă ambelor taskuri, şi care se realizează printr-o
zonă comună de memorie.
78
 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:
- 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 (ta-
blouri, articole, mulţimi);
- crearea de mecanisme care să suspende temporar verificări-
le 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;
- încărcarea procedurii de tratare numai la apariţia excepţiei;
- tratarea unitară a tuturor tipurilor 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ătoa-
rele aspecte:
- facilitarea dezvoltării de aplicaţii complexe pe sisteme cu
disponibilităţi reduse;
79
Modulul B
- compilarea la modificări, numai a modulelor î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 pro-
gram propriuzise (negenerice) prin generare de exemplu (sau
instanţiere).
3.2. Nucleul de timp real RTK

RTK reprezintă acronimul pentru Real Time Kernel – nucleu
de timp real dezvoltat de On Time Company http://www.on-
time.com/rtkernel-dos.htm .
Motivaţia prezentării nucleului RTK î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 me-
sajele de trecere. De asemenea nucleul oferă posibilitatea înţelegerii
conceptului de task şi urmărirea evoluţiei taskurilor.
3.2.1. Caracteristicile nucleului RTK

RTK a fost dezvoltat pentru a oferi facilităţi de timp real1 sis-
temului 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.
1
Se are în vedere dezvoltarea de facilităţi destinate implementării execuţiei pseudoparalele a tas-
kurilor.
2
Embedded systems
80
Î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 gestiona-
re fină 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 mi-
crosecunde;
 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.
3.2.2. Taskuri sub RTK

În context RTK un task reprezintă o funcție C/C++ sau proce-
dură Pascal fără parametri4. În continuare vor fi tratate taskurile dez-
voltate ca funcţii C/C++ . La un task RTK variabilele locale sunt alo-
cate pe o stivă proprie. Existenţa acestei stive permite apelarea simul-
tană a unei funcţii din mai multe taskuri, cu alte cuvinte nu există pro-
bleme cu reentranţa5. În ceea ce priveşte accesarea variabilelor globale
nu există restricţii. În figura 3.4 se prezintă structura unei aplicaţii RTK
destinată să ruleze sub sistemul de operare MS-DOS.
3
P1< P2<….< P64
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.
81
Modulul B
Fig. 3.4. 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 con-
form 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 3.5.
 Starea Current corespunde substării Execuţie din abor-
darea prezentată în capitolul precedent. 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 va fi deţinut de Idle
Task creat la iniţializarea RTKernel.
6
Stările Blocked şi Timed mai pot avea şi substări care vor fi evidenţiate la prezentarea
funcţiilor specifice.
82
Fig. 3.5. Graful de tranziţie a taskurilor în RTK.
După cum se observă din figura 3.5, î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) cores-
punde întreruperii periodice a taskului aflat în execuţie şi transferul
controlului către un task aflat în starea Ready. Acest mod elimină po-
sibilitatea 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 ce-
darea controlului procesorului de către taskul current către un alt task
aflat în starea Ready.
 Starea Suspended corespunde stării stării inactive din a d
abordarea prezentată anterior. Un task suspendat nu poate fi rulat în-
trucât a fost stopat prin funcţia RTKSuspend. Taskul poate redeveni
rulabil dacă asupra sa se execută funcţia RTKResume8
7
Pentru stabilirea tranşei de timp se apelează funcţia RTKTimeSlice din repertoriul de
instrucțiuni al RTKernel.
8
Cele două funcţii din repertoriul RTKernel vor fi prezentate în secţiunea funcţiilor RTK
de administrare a taskurilor.
83
Modulul B
 Un task aflat în starea Blocked nu poate fi executat întru-

câ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 ase-
menea task devine Ready după ce evenimentul aşteptat s-a produs.
 Starea Delaying corespunde unui task care a cedat volun-
tar 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 anu-
mit timp specificat producerea unui eveniment (din clasa celor speci-
fice stării Blocked). Ieşirea din această stare se realizează la produce-
rea evenimentului sau la expirarea timpului.
Este de remarcat faptul că stările Blocked, Delaying, Timed pot
fi încadrate în substarea Blocat specifică abordării din capitolul 2.
Examinând figura 3.5 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
10
în cozi cum ar fi: coada taskurilor Ready, coada taskurilor care aş-
teaptă la un semafor, la o cutie poştală, etc.
3.2.3. Funcţii RTK de iniţializare

Executivul RTK pune la dispoziţia programatorului un nu-
mă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
#include "rtkernel.h"
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).
84
De asemenea trebuie incluse tot printr-o directivă de preproce-

sare fişierul cu antetele funcţiilor asociate driverului consolei11 , respec-
tiv
#include "rtkeybrd.h"
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 semnifica-
tive 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 ce-

le asociate nucleului şi driverului consolei.
 Funcţia RTKernelInit inițializează nucleul RTK şi are
următoarea formă generală
TaskHandle RTKernelInit(unsigned Main_Prio); (3.1)
unde Main_Prio este o variabilă de tip unsigned care desem-
nează prioritatea taskului main.
Pentru a referi taskurile acestora li se pot asocia variabile de mâ-
nuire – handle de tip TaskHandle12. În funcţia (3.1) variabila de tip
TaskHandle este pentru taskul main13.
La execuţia funcţiei (3.1) sunt efectuate, printre altele, următoa-
rele 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-
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
12
TaskHandle este un tip de variabilă predefinit în RTKernel
13
Dacă taskul main nu este referit TaskHandle poate lipsi.
85
Modulul B
ţializare este abandonat cu transmiterea unui mesaj de

eroare);
3) convertirea funcţiei main în taskul main şi alocarea pri-
orităţii specificate;
4) crearea taskului Idle 14 şi alocarea pentru acesta 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); (3.2)
Se observă că funcţia (3.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 (3.1) şi
(3.2)
-----------------
#define prio_main 3
------------------
TaskHandle handler_main;
-----------------
handler_main= RTKernelInit(prio_main);
RTKeybrdInit();
-----------------
Observaţie
Ieşirea din RTKernel se realizează prin apelarea funcţiei C
exit(0).
3.2.4. Funcţii RTK de administrare a taskurilor

În această secţiune pot fi identificate două categorii de funcţii şi
anume:
14
Taskul Idle se execută atunci când nici un task utilizator nu se află în starea Current.
86
a) funcţii pentru crearea, terminarea, dezactivarea şi

activarea taskurilor;
b) funcţii care furnizează informaţii privind caracteris-
ticile şi evoluţia taskurilor.
 Funcţia RTKCreateTask permite crearea unui nou task

din alt task şi are următoarea formă generală
TaskHandle RTKCreateTask(void *Cod_Task(void),
Unsigned Prioritate,unsigned Stiva, cha*Nume_Task); (3.3)
În funcţia de mai sus notaţiile din lista de argumente au semnifica-
ţiile următoare:
- parametrul Cod_Task reprezintă o funcţie C care conţine
codul ce urmează a fi executat în noul task;
- parametrul Prioritate – prioritatea noului task (întreg
fără semn);
- parametrul Stiva – dimensiunea în octeţi a stivei noului task
(întreg fără semn);
- parametrul Nume_Task – pointer de maximum 15 caractere
la numele noului task.
Funcţia RTKCreateTask întoarce o valoare într-un handler
cu ajutorul căruia va putea fi referit noul task. Dacă în program nu
există astfel de referiri variabila handler poate lipsi.
 Funcţia RTKSuspend permite dezactivarea unui task,

respectiv trecerea sa în starea Suspended şi are următoarea formă
generală
void RTKSuspend(TaskHandle Handler_task); (3.4)
în care parametrul Handler_Task 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, res-

pectiv trecerea sa în starea Ready şi are următoarea formă genera-
lă
void RTKResume(TaskHandle Handler_Task); (3.5)
87
Modulul B
în care parametrul Handler_ task 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 Handler_Task,
unsigned Prio_noua); (3.6)
în care parametrul Handler_Task referă taskul a cărui prioritate
se va schimba, iar Prio_noua reprezintă noua prioritate.
 Funcţia RTKGetTaskState returnează într-o variabilă

de tip TaskState15 starea taskului referit prin Handler şi are urmă-
toarea formă generală
TaskState RTKGetTaskState (TaskHandle
Handler_Task); (3.7)
După execuţiei se returnează o valoare care corespunde uneia
dintre stările sau substările în care se găsește taskul după cum urmea-
ză:
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
Task blocat la un semafor după execuţia unei funcţii
BlockedWait
RTKWait
Task în aşteptare temporizată la un semafor după
TimedWait
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
Task în aşteptare temporizată pentru depunerea unui
TimedPut mesaj într-o cutie poştală plină după execuţia unei
funcţii RTKPutTimed
15
Acest tip din RTKernel corespunde tipului enumerat din limbajul C.
88
BlockedGet Task blocat la extragerea unui mesaj dintr-o cutie

poştală goală după execuţia unei funcţii RTKGet
Task în aşteptare temporizată pentru extragerea unui
TimedGet mesaj dintr-o cutie poştală goală după execuţia unei
funcţii RTKGetTimed
Task blocat în trimiterea unui mesaj pe care destina-
BlockedSend tarul nu îl poate recepţiona, după execuţia unei
funcţii RTKSend
Task în aşteptare temporizată pentru transmiterea
TimedSend unui mesaj, după execuţia unei funcţii
RTKSendTimed
Task blocat în aşteptarea unui mesaj pe care expedi-
BlockedReceive torul încă nu l-a trimis, după execuţia unei funcţii
RTKReceive
TimedReceive Task în aşteptare temporizată pentru recepţia unui
mesaj, după execuţia unei funcţii RTKReceiveTimed
Task blocat în transmiterea unui mesaj către un task
Deadlocked
dezactivat (interblocare)
Illegal Argumentul Handle se referă la un task inexistent
Task terminat ca urmare a execuţiei unei funcţii
Terminated
RTKTerminate
 Funcţia RTKGetTaskPrio, returnează într-o variabilă

de tip unsigned prioritatea taskului referit prin handler şi are for-
ma generală de mai jos
unsigned RTKGetTaskPrio(TaskHandle Handler_Task); (3.8)
 Funcţia RTKGetTaskStack, are forma generală de mai

jos
unsigned RTKGetTaskStack(TaskHandle Handler_Task); (3.9)
şi returnează într-o variabilă de tip unsigned spaţiul liber din stiva
taskului referit prin handler .
89
Modulul B
Exemplul 3.2
În acest exemplu se prezintă utilizarea funcţiilor
(3.3)…(3.9)
-----------------
------------------
TaskHandle Handler_A;
TaskState Stare_A;
unsigned Prio_noua,Prio_task,Stiva_libera;
-----------------
Handler_A=RTKCreateTask(TaskA,5,1024," Taskul_A");
-----------------
RTKSuspend(Handler_A);
Stare_A=RTKGetTaskState(Handler_A);
RTKResume(Handler_A);
-----------------
Prio_task=RTKGetaskPrio(Handler_A);
Prio_noua=Prio_task+2;
RTKSetPriority(Handler_A,Prio_noua);
Stiva_libera= RTKGetTaskStack(Handler_A);
-----------------
3.2.5. Funcţii de RTK 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, nucleul
RTK menţine un ceas intern care poate fi setat sau citit. În RTK unita-
tea 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ă 216 întreruperi pe oră
ceea ce reprezintă aproximativ 18,2 întreruperi/secundă care corespun-
de 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 ges-
tionarea timpului.
90
 Funcţia RTKSetTime care poate fi utilizată pentru seta-

rea ceasului intern la cu o valoare dorită nouă are forma generală
void RTKSetTime(Time Timp_nou; (3.10)
în care parametrul Timp_nou de tipul Time reprezintă valoarea expri-
mată în ticks la care va fi setat ceasul 16.
 Funcţia RTKGetTime care poate fi utilizată pentru citi-

rea ceasului intern într-o variabilă de tip Time are forma generală
Time RTKGetTime(void); (3.11)
Exemplul 3.3
În acest exemplu se prezintă utilizarea funcţiilor (3.10) şi
(3.11)
-----------------
------------------
Time Timp_setat,Timp_curent;
-----------------
Timp_curent=RTKGetTime();
Timp_setat=Timp_curent+25321;
RTKSetTime(Timp_setat);
-----------------
 Funcţia RTKDelay blochează taskul apelant pentru un
interval specificat printr-o variabilă de tip Duration şi are forma
generală
void RTKDelay(Duration Intarziere; (3.12)
în care numărul de cuante pentru Intarziere se obţine cu relaţia
Intarziere 18 t ( ticks ) , (3.13)
unde ∆t reprezintă intervalul de temporizare exprimat în secunde.
16
La iniţializarea RTK în cadrul funcţiei RTKernelInit se execută funcţia
RTKSetTime(0);
91
Modulul B
 Funcţia RTKDelaUntil permite execuţia taskului ape-

lant 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 Moment_Impus); (3.14)
Exemplul 3.4
În acest exemplu se prezintă un caz de utilizare a funcţiei
RTKDelay într-un sistem multitasking destinat afişării cu periodi-
citate de o secundă a datei şi orei. Sistemul este constituit din tas-
kurile Task_ora şi main.
 Taskul Task_ora se execută în buclă infinită şi apelea-
ză cu periodicitate de o secundă funcţia afordata care achiziţio-
nează ş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.6.
x
1 2 80
1
25
Fig. 3.6. 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 sem-
nificaţiile din figura 3.6.
 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ă suprav e-
gherii tastaturii. La apăsarea unei taste, codul ASCII al acesteia
92
este preluat şi transferat într-o variabilă de tip caracter cu ajutorul

funcţiei
char RTGetCh(); (3.15)
La apăsarea tastei E se iese din program, iar acţionarea al-
tei taste rămâne fără efect.
//
// Program demonstrativ utilizare funcţie RTKDelay
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
struct date d;
struct time t;
//
afordata() //functie preluare si tiparire data si ora
{
getdate(&d); // preia data curenta in variabila d
gettime(&t); // preia timpul curent 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);
}
//
// Task afisare periodia a datei si orei
//
Task_ora()
{
for(;;) //bucla for infinita
{
RTKDelay(18); //temporizare o secunda
afordata(); //apelare functie afordata
} //sfarsit for
} //sfarsit Task_ora
93
Modulul B
//
// Task main
//
main()
{
char c;
RTKernelInit(3); //initializare RTK
clrscr(); //stergere ecran
gotoxy(5,8); //pozitionare cursor
cprintf("E - Iesire");
RTKeybrdInit(); //initializare driver consola
// Creare Task_ora
RTKCreateTask(Task_ora,5,1024,"Task_tip_ora");
//
{
c=RTGetCh(); //supraveghere tastatura
if(c==’E’) //testare fata de E
exit(0); //iesire
} //sfarsit for
} //sfarsit main
3.2.6. Funcţii RTK pentru gestionarea semafoarelor

După cum s-a văzut în capitolul precedent, semaforul reprezintă
o importantă resursă pentru realizarea tuturor celor trei operaţii funda-
mentale 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 sema-
foarele de tip binar şi întreg. Unui semafor binar i se pot asocia valori-
le 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 de taskuri care pot utiliza un sema-
for 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,
94
pentru ca o variabilă să fie tratată ca un semafor, aceasta trebuie decla-

rată ca fiind de tipul Semaphore.
 Funcţia RTKCreateSemaphore permite crearea şi iniţi-
alizarea unui semafor şi are următoarea formă generală
Semaphore RTKCreateSemaphore(SemaType Tip_semaf,
unsigned Val_init, char *Nume_semaf); (3.16)
În funcţia de mai sus semnificaţiile notaţiilor din lista de argumente
au semnificaţiile următoare:
- parametrul Tip_semaf de tipul SemaType17 indică tipul
semaforului şi anume Binary pentru tipul binar, respectiv
Counting pentru tipul întreg;
- parametrul Val_init (întreg fără semn) indică valoarea iniţială
a noului semafor (0 sau 1 pentru un semafor binar sau una din-
tre valorile 0, 1, …,65535 pentru un semafor general
- parametrul Nume_semaf reprezină un 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 va-
riabilă de tip Semaphore cu ajutorul căruia va putea fi referit noul se-
mafor.
 Funcţia RTKSemaValue permite returnarea într-o vari-

abilă 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); (3.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); (3.18)
în care S reprezintă semaforul referit.
Potrivit celor prezentate în capitolul 2, prin funcţia RTKSignal
se asigură implementarea incrementării semaforului S, respectiv a
operaţiei V(S).
17
Sema Type este un tip de variabilă RTK.
95
Modulul B
În ceea ce priveşte funcţia de decrementare a unui semafor

(retragere a unui eveniment din acesta ) se prezintă în trei forme şi
anume: necondiţionată, condiţionată şi temporizată.
 Funcţia de retragere necondiţionată este RTKWait care
void RTKWait(Semaphore S); (3.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ă există cel puţin un eveniment disponibil, funcţia
se execută şi taskul îşi continuă rularea. 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 se-
maforul S se va înscrie un eveniment, respectiv până când asupra
sa se va executa o funcţie RTKSignal(S);
 Forma condiţionată a funcţiei de retragere este
RTKWaitCond care are următoarea formă generală
bool RTKWaitCond(Semaphore S); (3.20)
Dacă există cel puţin un eveniment disponibil, funcţia se execută
iar în variabila de tip bool se înscrie valoarea logică True. Dacă nici
un eveniment nu este disponibil (respectiv dacă S=0), funcţia nu
se execută, iar taskul îşi continuă execuţia (nu se blochează). În
acest caz în variabila de tip bool se încrie valoarea logică False.
 Varianta temporizată a funcţiei de extragere,

RTKWaitTimed are formă generală
bool RTKWaitTimed(Semaphore S,
Duration Timp_astept); (3.21)
în care S indică semaforul referit, iar Timp_astept , un interval de
aşteptare (specificat în ticks).
Dacă există cel puţin un eveniment disponibil, funcţia se execută
iar în variabila de tip bool se înscrie valoarea logică True. Dacă nici
un eveniment nu este disponibil (respectiv dacă S=0), funcţia nu
se execută, iar taskul trece în starea TimedWait.
96
Dacă în timpul de aşteptare specificat (Timp_astept), un

eveniment se înscrie în semafor, funcţia se execută, taskul iese din
starea TimedWait, iar în variabila de tip bool se înscrie valoarea logi-
că True.
Dacă nici un eveniment nu se înscrie în semafor, în intervalul
de timp specificat, funcţia nu se execută, taskul iese din starea Timed
Wait, iar în variabila de tip bool se încrie valoarea logică False.
Exemplul 3.5
În acest exemplu se prezintă un caz de utilizare a semafoa-
relor pentru realizarea sincronizării taskurilor. Sistemul este con-
stituit din taskurile Task_ora, Task_sincr şi main.
 Taskul Task_ora are aceleaşi caracteristici şi funcţio-
nalitate ca în exemplul 3.4.
 Taskul Task_sincr este blocat la semaforul binar
Sem_sincr iniţializat cu zero în taskul main. În momentul când
din acest task se execută o funcţie RTKSignal(Sem_sincr); se de-
blochează Task_sincr pentru 10 secunde. Pe durata deblocării pe
ecran se afișează numărul de secunde trecute. După trecerea celor
10 secunde, în taskul Task_sincr se execută funcția
RTKWait(Sem_sincr), ceea ce va determina revenirea Task_sincr
în starea BlockedWait. De asemenea pe ecran se afișează starea în
care se găsește Task_sincr, 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ă suprav e-
gherii tastaturii. La apăsarea tastei B se execută funcția
RTKSignal(Sem_sincr), 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.
//
// Program demonstrativ utilizare semafoare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
97
Modulul B
//
Semaphore Sem_sincr;
struct date d;
struct time t;
//
//
//functie preluare si tiparire data si ora

//
afordata()
{
getdate(&d); // preia data in variabila d
gettime(&t); // preia timpul in variabila t
//se tiparesc: ora, minutul, secunda
}
//
//
Task_ora() //task temporizare
{
{
} //sfarsit for
//
//
Task_sincr() //task sincronizat
{
int i;
{
gotoxy(5,10);
cprintf("BLOCAT ");
//decrementare semafor Sem_sincr
RTKWait(Sem_sincr),
gotoxy(5,10);
cprintf("EXECUTIE");
for(i=0;i<=9;i++) //bucla for in 10 pasi
{
RTKdelay(18); //temporizare o secunda
98
gotoxy(15,10);
//tiparire secunde trecute
cprintf("%d",i);
} //sfarsit for finit
} //sfarsit for infinit
} //sfarsit Task_sincr
//
//
main() //task main
{
char c;
//initializare RTK
RTKernelInit(3);
cprintf("B – Executie task_sincr E - Iesire");
//initializare driver consola
RTKeybrdInit();
// Initializare semafor Sem_sincr
Sem_sincr=RTKCreateSemaphore(Binary,0,"Sem_sin");
// creare Task_ora si Task_sincr
RTKCreateTask(Task_ora,5,1024,"Task_af_ora");
RTKCreateTask(Task_sincr,7,1024,"Task_sin");
//
{
if(c==’B’) //testarea fata de B
//incrementeaza semafor Sem_sincr
RTKSignal(Sem_sincr);
exit(0); //iesire
} //sfarsit for
} //sfarsit main
3.2.7. Funcţii RTK 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 tratea-
99
Modulul B
ză cutia poștală ca fiind organizată ca o coadă (queue) și în consecință

administrată potrivit strategiei FIFO18.
Taskul în care se execută o funcție de depunere într-o cutie
poștală care este plină trebuie să se blocheze până când se creează spa-
țiu. De asemenea trebuie să se blocheze 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 ca-
re pot fi utilizate de către un task și nici a numărului de taskuri în care
se poate utiliza o cutie poștală.
Este de menţionat faptul că în RTK, pentru ca o variabilă să fie
tratată în calitate de cutie poştală, aceasta trebuie declarată ca fiind
de tipul Mailbox. În continuare vor fi prezentate principalele funcții
RTK ce privesc gestionarea cutiilor poștale.
 Funcţia RTKCreateMailbox permite crearea şi iniţiali-
zarea unei cutii poștale şi are următoarea formă generală
Mailbox RTKCreateMailbox(unsigned Lung-mes,

unsigned Nr_mes, char *Nume_CP); (3.22)
În funcţia de mai sus semnificaţiile notaţiilor din lista de argumente
au semnificaţiile următoare:
- parametrul Lung-mes de tipul unsigned indică lungimea
în octeți a mesajelor care pot fi înscrise în cutia poștală;
- parametrul Nr_mes, tot de tipul unsigned precizează
numărul maxim de mesaje care pot fi stocat în cutia poștală;
- Nume_CP - 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ă.
 Funcţia RTKMessages permite returnarea într-o varia-

bilă 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 CP); (3.23)
18
FIFO – First Input First Output - strategie potrivit căreia extragerea din coadă se face în
ordinea introducerii.
100
în care parametrul CP este asociat cutiei poștale referite.
 Funcţia RTKClearMailbox realizează ștergerea conți-

nutului unei cutii poştale şi are următoarea formă generală
void RTKClearMailbox(Mailbox CP); (3.24)
în care parametrul CP este asociat cutiei poștale referite.
Principalele funcţii ale nucleului RTK asociate cutiilor poştale
sunt cele depunere şi preluare mesaje care se prezintă în trei forme şi
 Funcţia de depunere necondiţionată este RTKPut care
void RTKPut(Mailbox CP, void *Var_dep); (3.25)
în care variabila CP de tipul Mailbox referă cutia poștală în care se
face depunerea, iar *Var_dep este un pointer la variabila al cărui con-
ţinut se depune în cutia poştală.
Dacă în CP există spaţiu disponibil funcţia se execută şi taskul
îşi continuă rularea.
Dacă în CP nu există spaţiu disponibil, funcţia nu se execu-
tă, iar taskul apelant trece în starea BlockedPut, stare în care va
rămâne până când se va crea spaţiu.
 Funcţia de depunere condiţionată este RTKPutCond

care are următoarea formă generală
bool RTKPutCond(Mailbox CP, void *Var_dep); (3.26)
face depunerea, iar *Var_dep este un pointer la variabila al cărui con-
ţinut se depune în cutia poştală.
Dacă în CP există spaţiu disponibil funcţia se execută, taskul
îşi continuă rularea, iar în variabila de tip bool se înscrie valoarea logi-
că True .
tă, taskul apelant nu se blochează, iar în variabila de tip bool se
înscrie valoarea logică False.
101
Modulul B
 Varianta temporizată a funcţiei de depunere mesaj,

RTKPutTimed are formă generală
bool RTKPutTimed(Mailbox CP, void *Var_dep,
face depunerea, *Var_dep este un pointer la variabila al cărui conţinut
se depune în cutia poştală iar Timp_astept , un interval de aşteptare
(specificat în ticks).
Dacă în CP există spaţiu disponibil funcţia se execută, taskul
că True .
tă, iar taskul apelant trece în starea TimedPut.
Dacă în timpul de aşteptare specificat (Timp_astept), se
creează spaţiu în CP, funcţia se execută, taskul iese din starea
TimedPut, iar în variabila de tip bool se înscrie valoarea logică True.
Dacă la încheierea intervalului de aşteptare specificat
(Timp_astept), nu există spaţiu disponibil în CP, funcţia nu se
execută, taskul iese din starea TimedPut, iar în variabila de tip bool
se înscrie valoarea logică False.
 Funcţia de preluare necondiţionată este RTKGet care

void RTKGet(Mailbox CP, void *Var_prel); (3.28)
în care variabila CP de tipul Mailbox referă cutia poștală din care se
face preluarea, iar *Var_prel este un pointer la variabila în care se de-
pune mesajul preluat din cutia poştală.
Dacă în CP există un mesaj disponibil funcţia se execută şi tas-
kul îşi continuă rularea.
Dacă în CP nu există un mesaj disponibil, funcţia nu se
execută, iar taskul apelant trece în starea BlockedGet, stare în care
va rămâne până când va exista un mesaj în CP.
 Funcţia de preluare condiţionată este RTKGetCond ca-

re are următoarea formă generală
bool RTKGetCond(Mailbox CP, void *Var_prel); (3.29)
102

face preluarea, iar *Var_prel este un pointer la variabila în care se de-
pune mesajul preluat din cutia poştală.
Dacă în CP există cel puţin un mesaj disponibil funcţia se exe-
cută, taskul îşi continuă rularea, iar în variabila de tip bool se înscrie
valoarea logică True .
Dacă în CP nu există cel puţin un mesaj disponibil, funcţia
nu se execută, taskul apelant nu se blochează, iar în variabila de
tip bool se înscrie valoarea logică False.
 Varianta temporizată a funcţiei de preluare mesaj,

RTKGetTimed are formă generală
bool RTKGetCond(Mailbox CP, void *Var_prel,
face preluarea, *Var_prel este un pointer la variabila în care se depune
mesajul preluat din CP iar Timp_astept, un interval de aşteptare
Dacă în CP există un mesaj disponibil funcţia se execută, tas-
kul îşi continuă rularea, iar în variabila de tip bool se înscrie valoarea
logică True .
Dacă în CP nu există cel puţin un mesaj disponibil, funcţia
nu se execută, iar taskul apelant trece în starea TimedGet.
Dacă în timpul de aşteptare specificat (Timp_astept), apa-
re un mesaj în CP, funcţia se execută, taskul iese din starea
TimedGet, iar în variabila de tip bool se înscrie valoarea logică True.
(Timp_astept), nu există cel puţin un mesaj disponibil în CP,
funcţia nu se execută, taskul iese din starea TimedGet, iar în varia-
bila de tip bool se înscrie valoarea logică False.
103
Modulul B
Exemplul 3.6
În acest exemplu se prezintă utilizarea unei cutii poştale
pentru realizarea sincronizării taskurilor. Sistemul este constituit
din taskurile Task_ora, Task_sinc şi main.
nalitate ca în exemplele 3.4 și 3.5.
 Taskul Task_sinc 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, Task_sinc
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 Task_sinc trece din nou în starea
BlokedPut. De asemenea pe ecran se afișează starea în care se gă-
sește Task_sinc, adică T_Sinc așteaptă la CP respectiv Sosit me-
saj.
 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>
//
Mailbox CP;
struct date d;
struct time t;
//
//
104
afordata()
{
gotoxy(55,3);//pozitioneaza cursorul
cprintf(" %02d-%02d-%02d",t.ti_hour,t.ti_min,t.ti_sec);
}
//
Task_ora() //task afisare periodica ora
{
{
} //sfarsit for
//
//
Task_sinc() //task sincronizat
{
char i;
{
gotoxy(5,10);
cprintf("T_sinc asteapta la CP ");
//preia din CP si depune in i
RTKGet(CP,&i);
gotoxy(5,10);
//tipareste caracterul din i
cprintf("Sosit in CP mesaj %c ",i);
} //sfarsit Task_sinc
//
//
main() //task main
{
char c;
cprintf("Orice tasta - mesaj E - Iesire");
// Initializare driver consola
105
Modulul B
RTKeybrdInit();
// Initializare cutie postala CP
CP=RTKCreateMailbox(2,1,"CP_sinc");
// creare Task_ora si Task_sinc
RTKCreateTask(Task_sinc,7,1024,"T_sincr");
//
{
gotoxy(5,9);
cprintf("Transmis din main mesajul ");
gotoxy(41,9);
//tipareste caracterul tastat
cprintf("%c",c);
exit(0); //iesire
RTKPut(CP,&c); //altfel depune c in CP
} //sfarsit for
} //sfarsit main
3.2.8. Funcţii RTK de gestionare a mesajelor de trecere

Mesajul de trecere (passing message) reprezintă, facilitate de
comunicare directă între taskuri oferită de nucleul RTK. În cazul mesa-
jelor, spre deosebire de cutiile poștale, în taskul expeditor trebuie refe-
rit taskul destinatar prin intermediul unui handler asociat. În ceea ce
privește taskul destinatar, în cazul acestuia nu trebuie nominalizat tas-
kul 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 con-
stă în absența unui buffer de date în cazul mesajelor. În aceste condiții
în RTK nu există un tip predefinit pentru mesajele de trecere, ca în ca-
zul semafoarelor și cutiilor poștale.
Având în vedere trăsăturile de mai sus rezultă că pentru gestiona-
rea mesajelor există numai funcții de transmitere și recepție. Ca și în
cazurile semafoarelor și cutiilor poștale aceste instrucțiuni pot fi necon-
diționate, condiționate și temporizate.
În contextul unei funcţii de transmitere a unui mesaj, taskul desti-
natar referit prin handler este pregătit (TDP) dacă se găseşte într-una
din stările BlockedReceive sau TimedReceive.
106
 Funcţia de transmitere necondiţionată este RTKSend

void RTKSend(TaskHandle Handler_rec,void *Var_dep);(3.31)
în care parametrul Handler_rec este handlerul taskului destinatar, iar
*Var_dep reprezintă un pointer la variabila din care se preia mesajul
ce urmează a fi transmis.
Dacă TDP funcţia se execută şi taskul în care este apelată func-
ţia îşi continuă rularea. Dacă taskul destinatar nu este pregătit (TDNP),
funcţia nu se execută, iar taskul apelant trece în starea
BlockedSend, stare în care va rămâne până când TDP.
 Funcţia de transmitere condiţionată este

RTKsendCond care are următoarea formă generală
bool RTKSendCond(TaskHandle Handler_rec,
void *Var_dep); (3.32)
în care parametrul Handler_rec este handlerul al taskului destinatar,
iar *Var_dep reprezintă un pointer la variabila din care se preia mesa-
jul ce urmează a fi transmis.
Dacă TDP funcţia se execută, taskul în care este apelată funcţia
că True.
Dacă TDNP, funcţia nu se execută, taskul apelant nu se blo-
chează, iar în variabila de tip bool se înscrie valoarea logică False.
 Funcţia de transmitere temporizată este

RTKsendTimed care are următoarea formă generală
bool RTKSendTimed(TaskHandle Handler_rec,
void *Var_dep, Duration Timp_astept); (3.32)
în care parametrul Handler_rec este handlerul al taskului destinatar,
*Var_dep reprezintă un pointer la variabila din care se preia mesajul
ce urmează a fi transmis, iar Timp_astept , un interval de aşteptare
Dacă TDP, funcţia se execută, taskul în care este apelată func-
ţia îşi continuă rularea, iar în variabila de tip bool se înscrie valoarea
logică True.
107
Modulul B
Dacă TDNP, funcţia nu se execută, iar taskul apelant trece în

starea TimedSend.
Dacă în timpul de aşteptare specificat (Timp_astept),
TDP, funcţia se execută, taskul iese din starea TimedSend, iar în
variabila de tip bool se înscrie valoarea logică True.
(Timp_astept) TDNP, funcţia nu se execută, taskul iese din starea
TimedSend, iar în variabila de tip bool se înscrie valoarea logică Fal-
se.
În contextul unei funcţii de recepţie a unui mesaj, un task expedi-
tor ce referă destinatarul prin handler este pregătit (UTEP) dacă se gă-
seşte într-una din stările BlockedSend sau TimedSend.
 Funcţia de recepţie necondiţionată este RTKReceive
void RTKReceive(void *Var_rec, unsigned Lung_mes); (3.33)
în care *Var_rec reprezintă un pointer la variabila în care se depune
mesajul, iar Lung_mes este lungimea în octeţi a mesajului care se re-
cepţionează.
Dacă UTEP, funcţia se execută şi taskul în care este apelată
funcţia îşi continuă rularea. Dacă nu este un task expeditor pregătit
(NUTEP), funcţia nu se execută, iar taskul apelant trece în starea
BlockedReceive, stare în care va rămâne până când UTEP.
 Funcţia de recepţie condiţionată este

RTKReceiveCond care are următoarea formă generală
bool RTKReceiveCond(void *Var_rec,
unsigned Lung_mes); (3.34)
mesajul, iar Lung_mes este lungimea în octeţi a mesajului care se re-
cepţionează.
Dacă UTEP funcţia se execută, taskul în care este apelată func-
logică True.
Dacă NUTEP, funcţia nu se execută, taskul apelant nu se
blochează, iar în variabila de tip bool se înscrie valoarea logică Fal-
se.
108
 Funcţia de recepţie temporizată este

RTKReceiveTimed care are următoarea formă generală
bool RTKReceiveTimed(void *Var_dep, unsigned Lung_mes,
mesajul, Lung_mes este lungimea în octeţi a mesajului care se recepţi-
onează, iar Timp_astept , un interval de aşteptare (specificat în
ticks).
Dacă UTEP funcţia se execută, taskul în care este apelată func-
logică True.
Dacă NUTEP, funcţia nu se execută, taskul apelant trece în
starea TimedReceive.
Dacă în timpul de aşteptare specificat (Timp_astept), UTEP,
funcţia se execută, taskul iese din starea TimedReceive, iar în vari-
abila de tip bool se înscrie valoarea logică True.
(Timp_astept) NUTEP, funcţia nu se execută, taskul iese din starea
TimedReceive, iar în variabila de tip bool se înscrie valoarea logică
False.
Exemplul 3.7
În acest exemplu se prezintă utilizarea mesajelor de trecere
pentru comunicarea între două taskuri. Sistemul multitasking este
constituit din taskurile Task_ora, Task_dest şi main.
nalitate ca în exemplele 3.4, 3.5 și 3.6.
 Taskul Task_dest 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, debloca-
rea producându-se în momentul când Task_dest a fost referit prin
handlerul asociat Handle_dest în taskul emițător. După recepția
mesajului sub forma unui caracter, acesta este tipărit în coordonate
prestabilite, însoțit de mesajul Dest a recepționat.
109
Modulul B
 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 Task_dest î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 determi-
na ieșirea din program.
//
// Program demonstrativ utilizare mesaje
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
TaskHandle Handler_dest;
struct date d;
struct time t;
//
afordata()
{
}
//
Task_ora() //Task afisare periodica ora
{
{
} //sfarsit for
//
110
//
Task_dest() //task receptor
{
char j2;
{
RTKReceive(&j2,2);// preia mesaj si depune in j2
goto(5,8);
cprintf("Dest a receptionat %c ",j2);//tip j2
} //sfarsit TaskB
//
//
main() //task main
{
char c, j1=’0’;
int i;
cprintf("Orice tasta–main transmite E - Iesire");
RTKeybrdInit();
// creare Task_ora si Task_dest
RTKCreateTask(Task_ora,5,1024,"Task-tip_ora");
Handler_destB=RTKCreateTask(Task_dest,7,1024,"Dest");
//
{
//
for(i=1;i<=25;i++) //bucla for finita
{
j1++;
gotoxy(5,10);
cprintf("main transmite %c ",j1);
//transmite catre Task_dest
RTKSend(Handler_dest,&j1);
RTKDelay(18);
//
if(c==’E’) //testare c fata de E
exit(0); //iesire
j1=’0’; //altfel initializeaza j1
}
111
Modulul B
* *
112
CAPITOLUL Prelucrarea
4 în timp real a
informaţiei de proces
Se cunoaște faptul că desfășurarea unui proces necesită mai

multe categorii de resurse, între care o importanță aparte prezintă re-
sursele 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 des-
fășurării procesului. Obiectivele de eficiență 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 se 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.
113
Modulul B
Î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.
4.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, compatibili-
zarea cu dispozitivele de conversie analog-numerică și numeric-
analogică aferente sistemelor de interfață, testarea respectării domenii-
lor 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ă.
4.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 analogi-
ce, 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 4.1.
x[n] FILTRU y[n]

NUMERIC
Fig. 4.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].
114
O categorie de filtre este reprezentată de cele cu nerecursive,

pentru un asemenea filtru valoarea filtrată y[n] depinzând de ultimele
N valori din secvența de intrare x[n] potrivit relației
N 1
y[ n ]   h[ k ]  x [ n  k ] ,
k 0
(4.1)
unde h[k] reprezintă coeficienți ai filtrului.
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 (4.1) devine
N 1
 x[ n  k ] ,
1
y[ n ]  (4.2)
N k 0
unde N reprezintă ultimele N valori ale intrării.

Transpunând relaţia (4.2) pentru următorul pas rezultă
N 1
 x[ n  1  k ] .
1
y [ n  1]  (4.3)
N k 0
Scăzând relaţia (4.2) din relaţia (4.3)

N 1 N 1
  x[ n  k ] ,
1 1
y [ n  1]  y [ n ]  x[ n  1  k ] 
N k 0
N k 0
şi efectuând câteva transformări elementare rezultă
1
y [ n  1]  y [ n ]  ( x[ n  1]  x[ n  1  N ]). (4.4)
N
Relaţia (4.4) este de tip recurenţial întrucât valoarea curentă a
mărimii filtrate y depinde de valoarea anterioară a acesteia. În relaţia
(4.4) mai intervin două valori ale intrării şi anume: 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ă ilustrată în figura 4.2.
115
Modulul B
x[n+1-(N)]
x[n+1-(N)]
x[n+1-(N-1)]
x[n+1-(2)]
x[n+1-(1)]
x[n+1]
x[n+1
]
Fig. 4.2. Organizarea cozii termenul pentru obţinerea termenului
x[n+1-N din] relaţia (4.4).
După efectuarea notaţiilor:
- y[n+1] = YFC - valoare filtrată curentă;

- y[n] = YFA - valoare filtrată anterioară;
- x[n+1] = XAC - valoare achiziţionată curentă;
- x[n+1-N] = XAI - valoare achiziţionată întârziată,
relaţia (4.4) capătă forma
YFC  YFA  ( XAC  XAI ) / N , (4.5)
uşor de implementat at în logică de tip programat, cât şi cablat.
116
4.1.2. 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;
- implementarea în proces a comenzilor.
Realizarea acestei secvențe implică existenţa unui circuit in-
formaţional ilustrat în figura 4.3, în care procesul este reprezentat de
traductoare și elemente de execuție.
ANALOGIC DIGITAL DIGITAL

T PI
Semnale uCAN uING
analogice Calcul și
PROCES de la traductoare generare
comenzi
EE PE
Semnale uCNA uING
analogice
către elemente
de execuție
F1 F2
Fig. 4.3. Fluxul informaţional aferent unui sistem de conducere:
F1, F2 - frontiere, T – traductor, EE – element de execuţie, PI – port de intrare,
PE –port de ieşire.
Acestea se consideră că generează, respectiv sunt acționate de

semnale analogice. Întrucât procesarea impune intrări în formă nume-
rică și generează rezultate în aceiași formă, rezultă necesitatea unei
frontiere în care să se schimbe natura semnalelor. Aceasta frontieră
notată F1 în figura 4.3, este reprezentată de SADA (Subsistemul de
117
Modulul B
Achiziţie Date Analogice) și SDCA (Subsistemul Distribuţie Comenzi

Analogice) din structura sistemului de interfață cu procesul19.
Din cele expuse până în prezent rezultă că frontiera F1 schim-
bă , funcție de sensul de transmitere, natura semnalelor. Astfel, pe sen-
sul de la proces are loc 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 numeri-
că în unități CAN (uCAN), respectiv CNA20 (uCNA).
O a doua frontieră evidenţiată în figura 4.3 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 ingine-
reș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 pro-
cesul (SIP), frontiera F2 este asociată unor module de calcul aferente
respectivelor conversii.
În figura 4.4 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ă.
Structura din figura 4.4 asigură invarianța mărimii y221 la mo-
dificarea perturbațiilor P2_1…P2_k. Mărimea de comandă a regulato-
rului după perturbație REG_PERT este reprezentată de valoarea y1*,
exprimată în unități inginerești uING, care se aplică în calitate de refe-
rință 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.
19
În cazul aparaturii inteligente de automatizare (Smart) această frontieră este situată la
limita respectivei instrumentații, iar transmiterea semnalelor se face în format digital.
20
CAN și CNA sunt abrevieri pentru Convertor Analog Numeric, respectiv Convertor
Numeric Analog.
21
În raport cu referința y2i
118
uP1
F2 F1
P2_1 P2_k P2_n
iP1
P* NP uP CIU1 TP1
V mA
BC1 CAN 1
uPk iPk
V CIUk TPk
uING uCAN
REG V
mA
PERT
REG AB P2
u1
y1* N1 P1
i1 y1 SP2
REG EE SP1
BC2 CNA CUI AB
uING uCNA V mA r1
TA y2 uING
y2i mA
uING
Fig. 4.4. Circuitul informațional într-un SRA ierarhizat.
Analizând figura 4.4 rezultă că frontiera F1 este localizată la

nivelul CAN și CNA, componente ale SADA, respectiv SDCA din ca-
drul 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ă in-
clus într-un sistem numeric de transmitere a comenzii. În cele ce ur-
mează vor fi prezentate elemente privind sinteza celor două module de
calcul.
4.1.3. Conversia în unități inginerești

După cum s-a menționat în paragraful anterior această conver-
sie se realizează de către blocul BC1, parte integrată a unui sistem nu-
meric de măsurat la distanţă SNMD cu structura evidenţiată în figura
4.5.
119
Modulul B
Δx Δi Δu ΔN Δx* Δx Δx*
T CIU CAN BC1 SNMD
uING mA V uCAN uING uING uING
Fig. 4.5. Structura unui sistem numeric de măsurat la distanţă.
În figura 4.5 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ă
z  z  zmin , (4.6)
- variaţia maximă
- zmax  zmax  zmin . (4.7)
Determinarea relaţiei asociate modulului BC1 se va realiza im-

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

SNMD.
Δxmax Δx
Conversia curent-tensiune se realizează pe un rezistor de rezis-

tenţă R, astfel încât pentru CIU rezultă o caracteristică liniară prezenta-
tă în figura 4.17 a.
În ceea ce priveşte CAN , pentru rezoluţiile uzuale din sisteme-

le industriale de achiziţie de 12 – 16 biţi, caracteristica statică poate fi
aproximată ca fiind liniară, potrivit reprezentării din figura 4.7 b.
120
Δu ΔN
ΔNmax
Δumax
Δimax Δi Δumax Δu
a b
Fig. 4.7. Caracteristici statice ale convertoarelor: a – CIU; b – CAN.
Având în vedere caracteristicile statice ilustrate în figurile 4.6

şi 4.7 rezultă că relaţia aferentă modulului BC1, din punctul de vedere
al liniarităţii, va depinde numai de forma caracteristicii statice a tra-
ductorului 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 4.8 este ilustrată caracteristica statică a traductorului

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

din structura SNMD.
Δxmax Δx
Caracteristicilor statice din figurile 4.6…4.8 li se asociază ur-

mătorul sistem de ecuaţii în abateri:
121
Modulul B
x*max
SNMD: x 
*
 x , (4.8)
xmax
imax
T: i   x , (4.9)
xmax
umax
CIU: u   i , (4.10)
imax
N max
CAN: N   u . (4.11)
umax
Rezolvând sistemul format din ecuaţiile (4.8)…(4.11) rezultă
pentru BC1 ecuaţia
x*max
x*   N , (4.12)
N max
sau impunând pentru mărimea x* reprezentată în memorie, acelaşi
domeniu de variaţie ca pentru mărimea fizică
xmax
x*   N . (4.13)
N max
Examinând relaţia (4.13) se observă că elementul BC1 este un
element liniar, a cărui caracteristică statică este reprezentată în figura
4.9.
Δx*
Δxmax
Fig. 4.9. 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 (4.13) se ex-
primă abaterile ţinând cont de relaţiile (4.6) , (4.7) astfel încât rezultă
122
xmax  xmin
x*  xmin   ( N  N min ) . (4.14)
N max  N min
După efectuarea calculelor în relaţia (4.14) se obţine,
xmax  N min  xmin  N max xmax  xmin

x*   N. (4.15)
N max  N min N max  N min
sau
x*  a0  a1  N , (4.16)
unde
xmax  N min  xmin  N max

a0  ; (4.17)
N max  N min
xmax  xmin (4.18)
a1  .
N max  N min
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 (4.15) devine
xmax  N min x  xmin
x*   N  max , (4.19)
sau
x*  b0  b1  N , (4.20)
unde
xmax  N min
b0  ; (4.21)
N max  N min
xmax (4.22)
b1  .
N max  N min
Rezultatele de mai sus confirmă faptul că indiferent de forma
de exprimare (prin variaţii sau valori absolute), BC1 prezintă o caracte-
ristică statică liniară.
123
Modulul B
 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 4.10, astfel încât pentru SNMD rezultă sistemul de ecuaţii
(4.23)…(4.26).
Δi
Δimax
Fig. 4.10. Caracteristica statică a traductorului

neliniar din structura SNMD.
Δxmax Δx
x*max
SNMD: x 
*
 x , (4.23)
xmax
imax
T: i   ( x )2 , (4.24)
( xmax )2
umax
CIU: u   i , (4.25)
imax
N max
CAN: N   u . (4.26)
umax
Rezolvând sistemul format din ecuaţiile (4.23)…(4.26) rezul-
tă pentru BC1 ecuaţia
x*max
x  *
 N , (4.27)
N max
sau impunând pentru mărimea x* reprezentată în memorie acelaşi do-
meniu de variaţie ca pentru mărimea fizică
124
xmax
x*   N . (4.28)
N max
element neliniar, a cărui caracteristică statică este reprezentată în figu-
ra 4.11. Este de remarcat faptul că neliniaritatea introdusă de BC1
compensează neliniaritatea traductorului T, astfel încât pe ansamblu
caracteristica statică a SNMD să rezulte liniară.
Δx*
Δxmax

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 (4.28) se exprimă abaterile ţinând cont de relaţiile
(4.6), (4.7) şi rezultă
xmax  xmin
x*  xmin   ( N  N min ) . (4.29)
N max  N min
După efectuarea calculelor în relaţia (4.29), în situaţia frecvent
întâlnită în practică xmin = 0 se obţine,
N  N min
x*  xmax  . (4.30)
N max  N min
sau
 N min xmax
2 2
xmax
x*   N (4.31)
respectiv
125
Modulul B
x*  c0  c1  N , (4.32)
unde
N min  xmax
2
c0   ;
N max  N min (4.33)
2
xmax
c1  . (4.34)
N max  N min

de exprimare (prin variaţii sau valori absolute), BC1 prezintă o caracte-
ristică statică neliniară care compensează neliniaritatea caracteristicii
traductorului T.
Exemplul 4.1
Pentru un SNMD nivel cu caracteristica statică impusă liniară

şi structura ilustrată în figura 4.12 se cunosc următoarele elemente:
LT - H , H *  [ 200  800 ] mm ,i  [ 4  20 ] mA ,
caracteristică statică liniară;
CIU - R = 250 Ω, caracteristică statică liniară;
CAN - Nmax = 1023 uCAN, caracteristică statică liniară;
Să se determine:
a – domeniul de valori al tensiunii la intrarea CAN;
b – rezoluţia n a CAN;
c – valoarea numărului de cuante N1 în cazul unui
nivel din memorie cu valoarea H1*  650 mm .
126
Qi i
H *
N H
LT R u CAN BC1
Qe
Fig. 4.12. Structura SNMD nivel pentru exemplul 4.1.
Rezolvare
a – conform legii lui Ohm, pentru rezistorul R se poate scrie
umin  R  imin  250  4 103 1V ;
umax  R  imax  250  20 103  5V .
b – pentru un CAN se cunoaşte că N max  2n  1 de unde rezultă
n  log2( Nmax  1 )  log2( 1023  1 )  log2 1024 10 biti .
c – se determină pentru început valoarea Nmin apelând la

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

Nmin
U
Umin Umax
Caracteristica statică liniară din figura 4.13 este descrisă de

ecuaţia
N max  N min N
N  u cu N  max u ,
umax  umin umax
127
Modulul B
de unde rezultă
N max 1023
N min   umin   1  204,6 uCAN .
umax 5
Se determină coeficienţii din relaţiile (4.17) şi (4.18) după cum

urmează:
H max  N min  H min  N max 800  204,6  200  1023
a0   
N max  N min 1023  204,6
  50 mm;
H max  H min 800  200

a1    0,733138mm / uCAN .
N max  N min 1023  204,6
Rezultă modulul BC1 relaţia

H *  a0  a1  N ,
respectiv
H *  50  0,733138  N ,
de unde
H *  50
N ,
0,733138
respectiv
H1*  50 650  50 700

N1     954,8uCAN .
0,733138 0,733138 0,733138
Exemplul 4.2
Fie SNMD debit ilustrat în figura 4.14, pentru care se cunosc:

SNMD - caracteristică statică impusă liniară
FT - Q ,Q*  [ 0  60 ] mc / h , i  [ 4  20 ] mA ,
caracteristică statică neliniară (pătratică);
128
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 – valoarea Q1* a debitului reprezentat în memorie
pentru N1=1500 uCAN.
*
N Q
u CAN BC1
i R
FT
Q
Fig. 4.14. Structura SNMD debit pentru exemplul 4.2.
Rezolvare
umin  R  imin  250  4 103 1V ;
umax  R  imax  250  20 103  5V .

Pentru CAN
Conform procedeului indicat în exemplul precedent rezultă

Nmin după cum urmează:
N max 2047
N min   umin   1  409,4 uCAN .
umax 5
b – în condiţiile problemei, coeficienţi c0 şi c1 se calculează

după cum urmează
129
Modulul B
 N min  Qmax
2
 409,4 3600
c0     900( mc / h )2 ;
N max  N min 2047  409,4
2
Qmax 3600
c1    2,198( mc / h )2 / uCAN .
N max  N min 2047  409,4
Cu aceşti coeficienţi, se obţine următoarea relaţie pentru modu-

lul BC1
Q*  c0  c1  N   900  2,198  N ,
sau în condiţiile problemei cu N1=1500 uCAN
Q1*   900  2,198 1500   900  2,198 1500  48,96 mc / h .
4.1.4. Conversia din unități inginerești

Aşa cum reiese din figura 4.4 în care se prezintă circuitul in-
formaţ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 4.15.
Δy* Δu Δi Δy Δy* Δy
ΔN
BC2 CNA CUI SRA SNTD
uING uCNA V mA uING uING uING
Fig. 4.15. Structura unui sistem numeric de transmitere a comenzii

la distanţă.
Ca şi la conversia din unităţi inginerești , mărimile sunt expri-

mate prin variaţii, semnificaţiile tipurilor de variaţii fiind cele din rela-
ţiile 4.6 şi 4.7.
Determinarea relaţiei asociate modulului BC2 se va realiza im-
punând pentru SNMD o caracteristică statică liniară, ilustrată în figura
4.16.
130
Δy
Δymax

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 4.35.
Δi Δu
Δimax
Δumax
Δumax Δu ΔN
ΔNmax
a b
Fig. 4.17. Caracteristici statice ale convertoarelor: a – CUI; b – CNA.
Având în vedere caracteristicile statice ilustrate în figurile 4.16

şi 4.17 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 anu-
me:
- 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;
131
Modulul B
 Sinteza BC2 pentru un SNTD care include SRA cu CM

liniară
În figura 4.18 este ilustrată caracteristica statică a SRA cu CM
liniară care se consideră inclus în SNTD.
Δy
Δymax
Fig. 4.18. Caracteristica statică a SRA cu CM liniară
din structura SNTD.
Δi
Δimax
Caracteristicilor statice din figurile 4.16…4.18 li se asociază

următorul sistem de ecuaţii în abateri:
ymax
SNTD: y   y* , (4.35)
ymax
*
ymax
SRA: y   i , (4.36)
imax
imax
CUI: i   u , (4.37)
umax
umax
CNA: u   N . (4.38)
N max
tă pentru BC2 ecuaţia
N max
N   y* , (4.39)
ymax
*
sau impunând pentru mărimea y* reprezentată în memorie acelaşi do-

meniu de variaţie ca pentru mărimea fizică rezultă
N max
N   y* . (4.40)
ymax
132

element liniar, a cărui caracteristică statică este reprezentată în figura
4.19.
Δ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 relaţiei aferente modulului BC2 exprimată în valori absolu-
te. Pentru a obţine această formă, în ecuaţia (4.40) se exprimă abaterile
ţinând cont de relaţiile (4.6), (4.7) şi rezultă
N max  N min
N  N min   ( y*  ymin ) . (4.41)
ymax  ymin
ymax  N min  ymin  N max N max  N min *
N  y . (4.42)
ymax  ymin ymax  ymin
sau
N  d0  d1  y* , (4.43)
unde
ymax  N min  ymin  N max

d0  ; (4.44)
N max  N min
d1  .
ymax  ymin
O situaţie frecvent întâlnită este aceea în care limita inferioară

a domeniului mărimii x este nulă, respectiv ymin = 0. În acest caz ecua-
ţia (4.42) devine
133
Modulul B
N max  N min *
N  N min  y , (4.46)
ymax
sau
N  e0  e1  y* , (4.47)
unde
e0  Nmin , (4.48)
e1  .
ymax
Rezultatele de mai sus confirmă faptul că indiferent de forma de ex-
primare (prin variaţii sau valori absolute), modulul BC2 prezintă o ca-
racteristică statică liniară.
 Sinteza BC2 pentru un SNTD care include SRA cu CM

neliniară
Pentru SNTD, CNA şi CUI se menţin caracteristicile liniare pre-
zentate la începutul prezentului subcapitol. În ceea ce priveşte SRA, se
va considera o CM neliniară (de tip radical) ilustrată în figura 4.20.
Δy
Δymax
Fig. 4.20. Caracteristica statică a SRA cu CM
neliniară din structura SNTD.
Δi
Δimax
Caracteristicilor statice din figurile 4.16, 4.17 şi 4.20 li se aso-

ciază următorul sistem de ecuaţii în abateri:
134
ymax
SNTD: y   y* , (4.50)
ymax
*
ymax
SRA: y   i , (4.51)
imax
imax
CUI: i   u , (4.52)
umax
umax
CNA: u   N . (4.53)
N max
tă pentru BC2 relaţia
N max
N   ( y* )2 , (4.54)
( ymax )
* 2
sau impunând pentru mărimea y* reprezentată în memorie acelaşi do-

meniu de variaţie ca pentru mărimea fizică rezultă
N max
N   ( y* )2 . (4.55)
( ymax )2

element neliniar, a cărui caracteristică statică reprezentată în figura
4.21 compensează neliniaritatea caracteristicii de măsură a SRA.
ΔN
ΔNmax
modulul de calcul BC2, în cazul SRA cu CM
neliniară.
Δymax Δy*
Şi în acest caz sunt situaţii care necesită utilizarea ecuaţiei mo-

dulului BC2 exprimat în valori absolute. Pentru a obţine această for-
mă, în ecuaţia (4.55) se exprimă abaterile ţinând cont de relaţiile (4.6),
(4.7) şi rezultă
135
Modulul B
N max  N min
N  N min   ( y*  ymin )2 . (4.56)
( ymax  ymin ) 2
După efectuarea calculelor în relaţia (4.56) rezultă
N  f0  f1  y*  f 2  ( y* )2 , (4.57)
unde
N max  N min
f0  N min   ( ymin )2 , (4.58)
( ymax  ymin ) 2
N max  N min
f1  2  ymin  , (4.59)
ymax  ymin
N max  N min
f2  . (4.60)
( ymax  ymin )2
Dacă limita inferioară a domeniului mărimii y este nulă, res-

pectiv ymin = 0 , relaţia (4.60) devine
N  g0  g2  ( y* )2 , (4.61)
unde
g0  Nmin , (4.62)
N max  N min
g 2  g 20  .
( ymax )2
(4.63)

de exprimare (prin variaţii sau valori absolute) BC2 prezintă o caracte-
ristică statică neliniară care compensează neliniaritatea CM a SRA..
În continuare vor fi prezentate două exemple care tratează as-
pecte referitoare la conversia din unităţi inginereşti.
136
Exemplul 4.3
Fie SNTD nivel ilustrat în figura 4.22, pentru care se cunosc:

SNTD - caracteristică statică impusă liniară
SRA - H , H *  [ 200  800 ] mm ,
CUI - u  [ 0,2  1]V , caracteristică statică liniară;
CNA - Nmax = 1023 uCNA, caracteristică statică liniară.

Să se determine:
a – rezoluţia n a CNA şi numărul minim Nmin de uCNA;
b – valoarea calculată H1* a nivelului pentru care a
rezultat un număr N1=600 uCNA .
Qi i u N H*
CUI CNA BC2
LT LC
Qe
Fig. 4.22. Structura SNTD nivel pentru exemplul 4.3.
Rezolvare
a – pentru un CNA (ca şi în cazul CAN) se cunoaşte că
Nmax  2n  1, de unde rezultă
137
Modulul B
Pentru determinarea valorii Nmin se apelează la caracteristica

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

Umin
N
Nmin Nmax
Caracteristica statică liniară din figura 4.23 este descrisă de re-

laţia
umax  umin u
u  N cu u  max  N ,
N max  N min N max
de unde rezultă
N max 1023
N min   umin   1  204,6 uCNA .
umax 5
b – se determină coeficienţii din relaţiile (4.44) şi (4.45) după

cum urmează:
H max  N min  H min  N max 800  204,6  200  1023
d0   
H max  H min 800  200
  68,2 uCNA ;
N max  N min 1023  204,6

d1   1,364 uCNA / mm.
H max  H min 800  200

N  d0  d1  H * ,
respectiv
138
N  68,2  1,364  H * ,
de unde
N  68,2
H*  ,
1,364
respectiv
N1  68,2 600  68,2 668,2
H1*     489,88 mm.
1,364 1,364 1,364
Exemplul 4.4
Fie SNTD ilustrat în figura 4.24, pentru care se cunosc:

SRA - Q ,Q*  [ 0  60 ] mc / h , caracteristică statică
neliniară (radical);
CUI - u  [ 0,2  1]V , caracteristică statică liniară ;
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 N1 a numărului de uCNA pentru un debit
calculat Q1*  45 mc / h .
u N Q*
i BC2
CUI CNA
FC
FT
Q

139
Modulul B
Rezolvare
a – Nmax  2n  1 212  1  4096  1  4095uCNA .
Pentru determinarea valorii Nmin se apelează la caracteristica

statică a CNA ilustrată în figura 4.25.
u [V]
Umax = 2

Umin = 0,4
N[uCNA]
Nmin Nmax=4095
Caracteristica statică liniară din figura 4.25 este descrisă de re-

laţia
umax  umin u
u  N cu u  max  N ,
N max  N min N max
de unde rezultă
N max 4095
N min   umin   0,4  819 uCNA .
umax 2
b – se calculează coeficienţii g0 şi g2 din relaţiile (4.62) şi

(4.63) după cum urmează:
g0  Nmin  819 uCNA;
N max  N min 4095  819 3276

g2  2
 2
  1,035 uCNA /( mc / h )2 .
( Qmax ) ( 60 ) 3600
140
c - rezultă modulul BC2 relaţia

N  g0  g1  ( Q* )2 ,
respectiv
N  819  1,035  ( Q ) .
* 2
sau cu datele din enunţ Q1*  45 mc / h rezultă

N1  819  1,035  ( Q1* )2  819  1,035  ( 45 )2 
 819  1,035  2025  2914,875 uCNA .
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).
4.1.5. Validarea mărimilor achiziționate și a comenzilor

elaborate
În sens strict, operaţiunea de validare a unei mărimi achiziţio-
nate presupune testarea încadrării valorii rezultate în unităţi inginerești
în domeniul declarat pentru respectiva mărime. O eventuală neîncadra-
re în domeniu va fi declarată ca eveniment semnificativ, care va fi tra-
tat 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 4.26
în interiorul domeniului traductorului.
Domeniu Traductor
Limite Avertizare de Prevenire
Limite Avertizare de Avarie
Fig. 4.26. Limite asociate diverselor tipuri de testări a unei mărimi achiziţionate.
141
Modulul B
La încălcarea unei anumite categorii de limite sunt trecute în

execuţie taskuri specifice sincronizate cu aceste evenimente care de-
termină după caz pe lângă avertizări acțiuni de blocare, izolare, neutra-
lizare, etc.
Înainte ca o comandă calculată să fie aplicată SNTD au loc tes-

te de încadrare în domeniul specificat şi eventual între limite tehnolo-
gice sigure situate, conform reprezentării din figura 4.27 în interiorul
domeniului comenzilor valide.
Domeniu Comenzi Valide
Ymin Ymax Y
Domeniu Comenzi Sigure
Fig. 4.27. 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 aver-
tizare.
Î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 4.28.
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.
142
PROCEDURA TESTARE
COMANDA CALCULATA
Y
Transfera
Ycalc
Preia din BDP

Ymin, Ymax
Da
Ycalc ≤ Ymin
Nu
Da
Ycalc ≥ Ymax
Nu
Y=Ymin Y=Ycalc Y=Ymax
Transfera
Y
RETURN
Fig. 4.28. Schema logică asociată procedurii de testare

a unei comenzi calculate.
143
Modulul B
4.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ân-
dire.
4.2.1. Taskuri asociate unui SRA cu regulator PID

Se cunoaște expresia comenzii unui regulator PID în formă
continuă
 t
de 
 1
e(  )d  Td  ,
u  u0  Kp e 
 Ti  dt 
(4.64)
 0 
unde u este comanda curentă;

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
 k 

 ek  ( ek  ek 1 )  ,
T Td
u k  u0  Kp ek  (4.65)
 Ti j 1 T 
 
respectiv pentru k-1
 k 1 

 ek  ( ek 1  ek  2 )  ,
T Td
u k 1  u0  Kp ek 1  (4.66)
 Ti j 1 T 
 
unde T reprezintă intervalul de eșantionare.
144
Prin scăderea relației (4.66) din relația (4.65) rezultă:

 T Td 
u k  u k 1 Kp  ek  ek 1  ek  ( ek  2ek 1  ek  2 )  , (4.67)
 Ti T 
sau după unele grupări convenabile
 T Td   Td 
u k  u k 1 Kp 1   ek  Kp   1  2 ek 1 
 Ti T   T 
(4.68)
Td
 Kp ek  2 .
T
Din relația (4.68) se observă că valoarea pasului curent al co-
menzii uk depinde de valoarea acesteia aferentă pasului anterior uk-1
și de valorile abaterii e pentru trei pași consecutivi, respectiv ek , ek-1,
ek-2 .
Cu notațiile
 T Td 
UC  u k EC  e k CC  Kp 1   
 Ti T 
 Td 
UA  u k 1 EA e k 1 CA  Kp   1  2  (4.69)
 T 
Td
EA A  e k 2 CAA  Kp
T
relația (4.68) devine
UC UA  CC  EC  CA  EA CAA  EAA. (4.70)

Pentru implementarea relației (4.70) aferentă determinării co-
menzii regulatorului PID în formă recurenţială, se poate construi tas-
kul REG_PID a cărui schemă logică se prezintă în figura 4.29.
Examinând figura 4.29 se observă că taskul REG_PID este sin-
cronizat cu timpul, intervalul de execuţie fiind T respectiv intervalul de
eşantionare din relaţiile (4.68) şi (4.69). Referinţa I şi coeficienţii CC,
CA, CAA se preiau din baza de date de proces BDP în cadrul unei secţi-
uni critice, excluderea mutuală fiind implementată cu semaforul binar
SEMEX . Semnalul de reacţie R şi comanda calculată UC se achiziţio-
nează de la traductor prin SADA, respectiv se distribuie la EE prin in-
termediul SDCA.
145
Modulul B
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
prin SADA
EC = I-R
UC UA  CC  EC  CA  EA CAA  EAA.
Transfera UC
la EE prin SDCA
Fig. 4.29. Schema logică asociată taskului REG_PID.
146
Operarea regulatorului se realizează prin taskul consolă

CNS_OP a cărui schemă logică este prezentată în figura 4.30.
Initializare task
CNS_OP
SEMEX=1, stabileşte valori iniţia-
le 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. 4.30. Schema logică asociată taskului
CONS_OP.
EXIT
147
Modulul B
Din figura 4.30 reiese că taskul CNS_OP este sincronizat cu un

eveniment extern legat de apăsarea unei taste sau acționarea unui bu-
ton virtual. La introducerea uneia dintre comenzile P, I sau D se exe-
cută procedurile de modificare a parametrilor de acordare Kp, Ti res-
pectiv 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.
4.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 4.31 este prezentată structura unui SRA temperatu-
ră 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. 4.31. Scheme ale SRA temperatura bipozițional: a - schema principiala; b -
schema de structura; 1 – încălzitor electric; 2 – serpentină evacuare căldură; Tref,
T - temperaturi 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 refe-
148
rință 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 4.32 și descrisă de relația (4.71).
u HYST
CON
DECON
T
Tmin Tref Tmax
Fig. 4.32. 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ă.
u  CON dacă T  T min sau [( T min  T  T max) siT ( k  1 )  CON ];

sau
u  DECON dacă T  T max sau [( T min  T  T max) siT ( k  1 )  DECON ];
(4.71)
În relația (4.71) Tmin și Tmax se calculează cu relațiile
HYST
T min  Tref  ; (4.72)
2
HYST
T max  Tref  . (4.73)
2
unde HYST reprezintă lățimea benzii de hysterezis.
149
Modulul B
Funcționarea SRA poate fi ușor înțeleasă pe baza caracteristici-

lor dinamice din figura 4.33. 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.
u
CON
a)
DECON
t
T
Tmax
Tref
Tmin HYST
T0 b)
Fig. 4.33. 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 4.33 b se observă că regi-

mul permanent este unul oscilant în jurul valorii Tref cu amplitudinea
HYST/2. Pentru creșterea preciziei de reglare ar trebui micșorată lăți-
mea benzii de hysterezis HYST, ceea ce va determina o creștere a frec-
venței de comutare cu implicații negative în ceea ce privește fiabilita-
tea 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ări-
le 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 4.34.
150
Initializare task
REG_BP
SEMEX=1, determină valoarea
iniţială pentru comanda U
Nu
∆t=Tcom ?
Da
P(SEMEX)
Preia din BDP

Tmin, Tmax
V(SEMEX)
Achiziționează R prin
SADA evaluează T
Nu Da
T ≤ Tmin ?
Nu
T ≥ Tmax ?
Da
U = DECON U= CON
Transmite U la EE
prin SDCN
Fig. 4.34. Schema logică asociată taskului REG_BP.
Din figura 4.34 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
151
Modulul B
SEMEX . Semnalul de reacţie R corespunzător temperaturii reglate T se

achiziţionează de la traductorul de temperatură analogic prin SADA iar
comanda U (CON sau DECON) se transmite întrerupătorului care co-
nectează respectiv deconectează încălzitorul electric prin intermediul
Subsistemului Distribuţie Comenzi Numerice – SDCN. Analizând
schema logică din figura 4.34 se observă că se poate comanda închide-
rea întrerupătorului (comanda CON), deschiderea întrerupătorului
(comanda DECON) sau se poate menține starea acestuia dacă
Tmin<T<Tmax.
Al doilea task asociat SRA temperatură cu regulator
bipoziţional este taskul care CNS_BP a cărui schemă logică se
prezintă în figura 4.35.
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
HHYST
Nu
Nu P(SEMEX)
E?
Da Calculează
Tmin, Tmax
EXIT
Fig. 4.35. Schema logică asociată taskului CNS_BP.

Din figura 4.35 reiese că taskul CNS_BP este sincronizat cu un
eveniment extern legat de apăsarea unei taste sau acționarea unui bu-
ton virtual. La introducerea uneia dintre comenzile I sau H se execută
152
procedurile de modificare a referinţei Tref sau lăţimii benzii de

hysterezis HYST. Fiecare modificare este urmată de recalcularea valo-
rilor 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. Acce-
sul în această secţiune este reglementat prin excludere mutuală imple-
mentat cu semaforul binar SEMEX, utilizat în acelaşi scop şi în taskul
REG_BP.
4.3. Baze de date de proces

În general o bază de date reprezintă o mulţime de date organi-
zate 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 pro-
ces (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 au-
torizate. Aceste proceduri impun implementarea unui sistem adecvat
de chei de acces, parole, etc. Tot pentru securitate se poate apela la
153
Modulul B
criptarea datelor, însă trebuie să se ţină cont că operaţiile de cripta-

re/decriptare sunt consumatoare de timp.
Cerinţa de integritate presupune protecţia datelor la o funcţio-
nare necorespunzătoare a echipamentului pe care rulează aplicaţiile
sau chiar a programelor aferente acestor aplicaţii. O posibilitate de asi-
gurare a acestei cerinţe o reprezintă crearea copiilor de siguranţă pen-
tru BDP.
Cerinţa de independenţă implică adoptarea unor structuri de
descriere a datelor care să nu implice schimbări ale acestora la înlocu-
irea sau modificarea programelor aferente aplicaţiilor de conducere,
care utilizează aceste date.
Într-o BDP sunt uzual cuprinse următoarele categorii de date:
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 au-
tomate 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 orga-
nizarea datelor, definirea atributelor şi a tabelelor etc.
154
Încărcarea datelor se referă la datele din categoriile d, e, f din

enumerarea de mai sus şi este realizată la iniţializarea sistemului pro-
gramelor 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 re-
gulatoarelor după abatere. Pe harddisk sunt păstrate date asociate evo-
luţiei procesului (parametri, comenzi, evenimente), însă nu pentru pe-
rioade îndelungate. Pentru perioade de timp mari datele se arhivează şi
se transferă pe suporturi externe magnetice sau optice.
155
Modulul B
Exerciţii şi întrebări
pentru modulul B de
EB studiu
1. Care sunt cerinţele impuse unui Limbaj de Programare în Timp Real

(LPTR) ?
2. Care sunt caracteristicile unui LPTR ?
3. Care este numărul de priorităţi admise de nucleul de timp real RTK ?
4. Definiţi noţiunea de task în context RTK.
5. Care sunt stările unui task în context RTK ?
6. Când se găseşte un task în starea delaying ?
7. Ce se realizează prin execuţia funcţiei RTKernelInit ?
8. Denumiţi tipul de variabilă RTK prin care poate fi referit un task ?
9. În ce tip de variabilă RTK este returnată o valoare corespunzând stării
taskului, după execuţia funcţiei RTKGetTaskState ?
10. Care este mărimea unei cuante de timp cu care operează nucleul RTK ?
11. Scrieţi forma generală şi comentaţi efectul funcţiei RTKWait, aplicată
unui semafor ?
12. Scrieţi forma generală şi comentaţi efectul funcţiei RTKGetCond apli-
cată unei cutii poştale ?
13. Scrieţi forma generală şi comentaţi efectul funcţiei RTKSendTimed
aplicată unui mesaj de trecere.
14. Ce este un filtru nerecursiv ?
156
15. Care sunt operaţiile de prelucrare primară a datelor achiziţionate

şi a comenzilor elaborate ?
16. Enumeraţi elementele din structura unui SNMD ?
17. Rezolvaţi problema din exemplul 4.1 pentru Nmax=4095 uCAN .
19. Enumeraţi elementele din structura unui SNTD ?
20. Rezolvaţi problema din exemplul 4.4 pentru n=11 bit. .
21. Deduceţi relaţia pentru calculul comenzii unui regulator PID în
formă numerică.
22. Cum influenţează lăţimea benzii de hysterezis precizia de reglare
a unui regulator bipoziţional ?
23. Ce este o bază de date de proces (BDP) ?
24. În ce constă cerinţa de independenţă a datelor impusă unui Sis-
tem de Gestiune a unei BDP ?
25. Enumeraţi cinci tipuri de date care pot fi incluse într-o BDP.
157
Modulul B
Test de autoevaluare
pentru modulul B de
TB studiu
1. Care sunt aspectele vizate atunci când se vorbeşte de structurarea unui

limbaj de programare în timp real ?
2. Prin ce funcţie RTK este scos un task din starea Suspended ?
3. Scrieţi funcţia RTK pentru iniţializarea nucleulu, considerând pentru
taskul main prioritatea 5 şi fără handler.
4. Care este rolul taskului Idle creat la iniţializarea nucleului RTK ?
5. În ce situaţie ajunge un task în starea BlockedPut ?
6. Scrieţi funcţia RTK care să realizeze tranziţia taskului apelant în starea
Delaying pentru 4 secunde.
7. Enumeraţi tipurile de variabile specifice nucleului RTK.
8. Prin ce se implementează frontiera F2 la achiziţia datelor şi transmite-
rea comenzilor ?
9. Când se consideră pregătit un task destinatar în contextul unei funcţii
de transmitere a unui mesaj.
10. Denumiţi operaţiile de prelucrare primară a datelor de proces.
11. Determinaţi Nmin, Nmax pentru un CAN cu rezoluţia de 12 biţi şi ur-
mătoarea caracteristică statică
ΔN
ΔNmax=3276 uCAN
Δumax Δu
12. Ce este un filtru nerecursiv cu mediere ?
158
13. Deduceţi relaţia asociată modulului BC1 în următoarele condiţii:
x*max
SNMD: x 
*
 x ,
xmax
imax
T: i   ( x )2 ,
( xmax ) 2
N max
CIU+CAN: N   i.
imax
14. Pentru SNMD presiune reprezentat în figură se cunosc
i
Qi P *
N P
PT R u CAN BC1
Qe
LT - P , P*  [ 0  20 ] bar , imin  4 mA;

CIU - R = 50 Ω, Umax=1 V, caracteristică statică liniară;
CAN - Nmin = 409,4 uCAN, caracteristică statică liniară;
Să se determine:
a – Umin şi imax;
b – rezoluţia n a CAN şi Nmax;
c – valoarea P1* a presiunii pentru N1=1000 uCAN
ymax
SNTD: y   y* ,
ymax
*
ymax
SRA: y   i ,
imax
i
CNA+CUI: i  max  N .
N max
159
Modulul B
16. Fie SNTD ilustrat în figura de mai jos, pentru care se cunosc:
CUI - u  [ 1 5 ]V , caracteristică statică liniară ;
CNA - Nmax = 1023 uCNA , caracteristică statică liniară.
u N Q*
i BC2
CUI CNA
FC
FT
Q
Să se determine:
a – numerele de n şi Nmin şi pentru CNA;
b – relaţia de calcul pentru BC2;
c – valoarea Q1* pentru N1 500 uCNA .
17. Indicaţi cu ce sunt sincronizate taskurile REG_PID şi CNS_OP pentru

implementarea unui algoritm PID în formă numerică.
19. Indicaţi cerinţele la care trebuie să răspundă un sistem de gestiune

(SG) a unei BDP .
20. În ce constă cerinţa de integritate a datelor impusă unui SG-BDP ?
160
Soluţiile testelor de
autoevaluare
SAB
 Modulul A
1. Care este diferenţa dintre conducerea corectivă şi cea preventivă ?
În cadrul conducerii corective prin acţiunea comenzii este corectată o
diferenţă (eroare) dintre obiective şi realizări, în timp ce prin conduce-
rea preventivă, prin acţiunea comenzii se previne apariţia unei aseme-
nea diferenţe.
2. Ce obiectiv al unui proces este asigurat prin funcţia de protecţie
automată ?
Prin funcţia de protecţie automată este asigurat obiectivul de securita-
te al unui proces.
3. Care sunt funcţiile dispozitivului de automatizare din structura
unui SRA ?
Funcţiile unui dispozitiv de automatizare sunt: măsură, comandă,
execuţie.
4. Când prezintă un sistem de conducere comportare în timp real ?
Un sistem de conducere prezintă comportare în timp real atunci când
reacţia sa la schimbările din proces este conformă cu inerţia acestuia.
5. Care este diferenţa dintre prelucrarea paralelă şi cea
pseudoparalelă ?
Prelucrarea paralelă, (posibilă la echipamentele cu mai multe UCP)
mai multe taskuri sunt în execuţie la un moment dat. Prelucrarea
pseudoparalelă presupune un singur task în execuţie la un moment
dat (la sistemele cu o singură UCP).
6. În ce constă obiectivul de perceptibilitate al IPTR ?
161
Modulul B
Obiectivul de perceptibilitate se referă la aptitudinea care trebu-

ie 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ă finalizare.
7. Prezentaţi etapa de analiză din dezvoltarea unei aplicaţii infor-
matice.
Analiza reprezintă o etapă în care beneficiarul colaborează cu
echipa de analişti din partea elaboratorului produsului informa-
tic, în vederea identificării particularităţilor problemei care ur-
mează a se rezolva.
Taskurile disjuncte, spre deosebire de cele interactive, nu utilizează
resurse în comun şi nu fac schimb de date.
9. Ce factori influenţează evoluţia unui sistem de taskuri interactive ?
Evoluţia unui sistem de taskuri interactive este influenţată de doi
factori şi anume:
- modul de efectuare a tranziţiei între stări şi/sau substări.
10. În ce situaţie se produce tranziţia Gata de execuţie – Blocat ?
Tranziţia Gata de execuţie – Blocat se realizează printr-o di-
rectivă de Aşteptare, în situaţia în care taskului nu i se mai poa-
te aloca memorie pentru stivă dacă ar prelua controlul UCP.
11. Ce entităţi intervin în definirea unui semafor în caz general ?
În definirea unui semafor S intervin o variabilă întreagă I şi o coadă
de aşteptare C: S=(I,C).
12. În ce situaţie se produce blocarea unui task la execuţia unei ope-
raţii de tip P asupra unui semafor ?
Blocarea se produce dacă variabila întreagă asociată semaforului este
mai mică sau egală cu zero.
13. Ce operaţie se execută asupra unui semaforului implicat în ex-
cluderea mutuală după ieşirea din secțiunea critică ?
La ieșirea dintr-o secţiune critică, asupra semaforului implicat în ex-
cluderea mutuală se execută operaţia V (incrementare).
14. Ce presupune directiva ASTEAPTĂ aplicată unei variabile de
tip eveniment ?
162
Dacă E este o variabilă de tip EVENIMENT

ASTEAPTA( E )  Blocheaza taskul daca E  FALS ,
Continua executia daca E  ADEVARAT .
15. Ce tip de mesaj se utilizează la excluderea mutuală implementată
cu cutii poştale ?
Se utilizează mesaje simbolice.
16. Explicaţi utilizarea cutiilor poştale pentru sincronizarea cu timpul ?
În cazul sincronizării cu timpul se utilizează aşteptarea temporizată
la o cutie poştală vidă.
17. Ce valoare are un semafor utilizat în excludere mutuală pe durata
execuţiei secţiunii critice ?
Variabila întreagă din structura semaforului are valoarea 0 (zero) pe
durata execuţiei secţiunii critice.
18. Ce valoare are o variabilă de tip eveniment implicată în excludere
mutuală pe durata execuţiei secţiunii critice ?
Variabila de tip eveniment are valoarea FALS pe durata execuţiei sec-
ţiunii critice.
19. Ce conţine o cutie poştală utilizată în excluderea mutuală în tim-
pul execuţiei secţiunii critice ?
Pe durata execuţiei unei secţiuni critice, cutia poştală implicată în ex-
cluderea mutuală este vidă.
20. Care este diferenţa dintre comunicarea prin mesaje şi comunica-
rea prin cutii poştale ?
În cazul comunicării prin mesaje trebuie precizat destinatarul, în timp
ce la comunicarea prin cutii poştale nu se impune această cerinţă.
163
Modulul B
 Modulul B
1. Care sunt aspectele vizate atunci când se vorbeşte de structura-
rea unui limbaj de programare în timp real ?
Când se vorbeşte de structurare se au în vedere aspecte legate de tipi-
zare, abstractizare şi vizibilitate care se referă atât la date cât şi la cod.
2. Prin ce funcţie RTK este scos un task din starea Suspended ?
Prin funcţia RTKResume
3. Scrieţi funcţia RTK pentru iniţializarea nucleului, considerând
pentru taskul main prioritatea 5 şi fără handler.
Forma funcţiei este RTKernelInit(5);
4. Care este rolul taskului Idle creat la iniţializarea nucleului RTK ?
Taskul Idle se execută atunci când nici un task utilizator nu se află în
starea Current.
5. În ce situaţie ajunge un task în starea BlockedPut ?
După execuţia unei funcţii RTKPut asupra unei cutii poştale pline.
6. Scrieţi funcţia RTK care să realizeze tranziţia taskului apelant
în starea Delaying pentru 4 secunde.
Funcţia este RTKDelay(72);
TaskHandle, TaskState, Time, Duration, Semaphore, SemaType,
Mailbox
8. Prin ce se implementează frontiera F2 la achiziţia datelor şi
transmiterea comenzilor ?
La achiziţia datelor prin modulul de calcul BC1iar la transmiterea co-
menzilor prin modulul de calcul BC2.
9. Când se consideră pregătit un task destinatar în contextul unei
funcţii de transmitere a unui mesaj.
În contextul unei funcţii de transmitere a unui mesaj, taskul destinatar
referit prin handler este pregătit) dacă se găseşte într-una din stările
BlockedReceive sau TimedReceive.
164
Operaţiile de prelucrare primară a datelor de proces sunt:

- validarea mărimilor achiziționate și a comenzilor elaborate.
11. Determinaţi Nmin, Nmax pentru un CAN cu rezoluţia de 12
biţi şi următoarea caracteristică statică
ΔN
ΔNmax=3276 uCAN
Δumax Δu
Rezolvare
N max  2n  1 212  1 4096 1 4095 uCAN

N max  N max  N min
N min  N max  N max  4095  3276  819 uCAN
12. Ce este un filtru nerecursiv cu mediere ?

Un filtru nerecursiv cu mediere reprezintă un filtru nerecursiv în care
coeficienţii h[k] sunt egali cu 1/N, N fiind numărul datelor din secven-
ţa de intrare.
13. Deduceţi relaţia asociată modulului BC1 în următoarele

condiţii:
x*max
SNMD: x 
*
 x ,
xmax
imax
T: i   ( x )2 ,
( xmax )2
N max
CIU+CAN: N   i.
imax
165
Modulul B
Rezolvare
N max N max imax
N   i    ( x )2
imax imax ( xmax )2
 max
x   N
N max
x*max x*max xmax

x 
*
 x    N ,
xmax xmax N max
x*max
BC1: x  *
 N .
N max
14. Pentru SNMD presiune reprezentat în figură se cunosc
i
Qi P *
N P
PT R u CAN BC1
Qe
LT - P , P*  [ 0  20 ] bar , imin  4 mA;

CIU - R = 50 Ω, Umax=1 V, caracteristică statică liniară;
Să se determine:
c – valoarea P1* a presiunii pentru N1=1000 uCAN .
166
Rezolvare
umin  R  imin  50  4 103  0,2 V ;
umax 1
imax    0,02 A  20 mA.
R 50
b - se determină pentru început valoarea Nmax apelând la
caracteristica statică a CAN ilustrată mai jos.
N
Nmax
Nmin
U
Umin Umax
Caracteristica statică liniară a CAN este descrisă de ecuaţia
N max  N min N
N  u cu N  max  u ,
umax  umin umax
de unde rezultă
N min 409,4
N max   umax   1  2047 uCAN .
umin 0,2
n  log2( Nmax  1 )  log2( 2047  1 )  log2 2048 11biti .
c
c - având în vedere datele din enunţ rezultă pentru modulul BC1

caracteristica statică liniară cu ecuaţia
167
Modulul B
P*  b0  b1  N ,
cu
Pmax  N min 20  409,4

b0      5 bar ;
N max  N min 2047  409,4,6
Pmax 20
b1    0,012213bar / uCAN .
N max  N min 2047  409,4
respectiv
P*   5  0,012213  N ,
sau
P1*   5  0,012213 1000  7,213bar.

condiţii:
ymax
SNTD: y   y* ,
ymax
*
y
SRA: y  max  i ,
imax
i
CNA+CUI: i  max  N .
N max
Rezolvare
N max N max imax
N   i    y
imax imax ymax
N max ymax
N   *  y*
ymax ymax
168
N max
BC2: N   y* .
ymax
*
SNTD - caracteristică statică impusă liniară;
CUI - u  [ 1 5 ]V , caracteristică statică liniară ;
CNA - Nmax = 1023 uCNA , caracteristică statică liniară.
Să se determine:
a – numerele de n şi Nmin şi pentru CNA;
b – relaţia de calcul pentru BC2;
c – valoarea Q1* pentru N1 500 uCNA .
u N Q*
i BC2
CUI CNA
FC
FT
Q
Rezolvare
N max  2n  1 n  log 2 ( N max  1 ) 

a–
 log 2 ( 1023  1 )  log 2 1024 10 biţi.
Pentru determinarea valorii Nmin se apelează la caracteristica stati-

că a CNA ilustrată mai jos.
u [V]
Umax = 5
Umin = 1
N[uCNA]
Nmin Nmax=1023 169

Modulul B
Caracteristica statică liniară de mai sus este descrisă de relaţia

umax  umin
u N ,
N max  N min
de unde rezultă
N max 1023
N min   umin  1  204,6 uCNA .
umax 5
b – se calculează coeficienţii g0 şi g2 din relaţiile (4.62) şi (4.63)

după cum urmează:
g0  Nmin  204,6 uCNA;
N max  N min 1023  204,6 4  204,6

g2  2
 2
  0,90933uCNA /( mc / h )2 .
( Qmax ) ( 30 ) 900
Rezultă pentru modulul BC2 relaţia

N  g0  g1  ( Q* )2 ,
respectiv
N  204,6  0,90933  ( Q* )2 .
c – din relaţia asociată BC2 rezultă
N  204,6
Q*  .
0,90933
sau cu datele din enunţ
N1  204,6 500  204,6
Q1*   
0,90933 0,90933
500  204,6 295,4
   324,854 18,0237mc / h
0,90933 0,90933
170
17. Indicaţi cum sunt sincronizate taskurile REG_PID şi CNS_OP

pentru implementarea unui algoritm PID în formă numerică.
Taskul REG_PID este sincronizat cu timpul, iar taskul CNS_OP cu un
eveniment extern reprezentat de apăsarea unei taste sau a unui buton
virtual.
O BDP reprezintă o bază de date care conţine date organizate pentru
a fi utilizate în aplicaţii de conducere în timp real.
19. Indicaţi cerinţele la care trebuie să răspundă un sistem de ges-
tiune (SG) a unei BDP .
Un SG-BDP trebuie să răspundă următoarelor cerinţe:
20. În ce constă cerinţa de integritate a datelor impusă unui SG-
BDP ?
Cerinţa de integritate presupune protecţia datelor la o funcţionare ne-
corespunzătoare a echipamentului pe care rulează aplicaţiile sau chiar
a programelor aferente acestor aplicaţii.
171
Modulul B
* *
172
B Bibliografie
1. Bărbat B., Filip Gh. F., Informatica industrială. Ingineria programă-

rii în timp real, Bucureşti, Editura Tehnică, 1997.
2. Călin, S., Dumitrache, I., ş.a., Reglarea numerică a proceselor tehno-

logice, Bucureşti, Editura Tehnică, 1984.
3. Diaconescu E., Achiziţii de date şi instrumentaţie. Fundamente

hardware, Bucureşti, Editura MatrixRom, 2006.
4. Dijkstra, E. W., Solution of a problem in concurent programming

control. A discipline of programming, Communication of the ACM ,
8(9), 1965.
5. Leţia T., Sisteme de timp real, Cluj-Napoca, Editura Albastră, 2006.
6. Marinoiu V., Paraschiv, N., Automatizarea proceselor chimice, Bu-

cureşti, Editura Tehnică, 1992.
7. Paraschiv, N., Echipamente numerice pentru conducerea proceselor,

Ploieşti, Editura Universităţii Petrol-Gaze din Ploieşti, 1996.
8. Paraschiv, N., Introducere în ştiinţa sistemelor şi calculatoarelor,

Ploieşti, Editura Universităţii Petrol-Gaze din Ploieşti, 2011.
9. Paraschiv, N., Achiziţia şi prelucrarea datelor, Introducere în ştiinţa

sistemelor şi calculatoarelor, Ploieşti, Editura Universităţii Petrol-
Gaze din Ploieşti, 2013.
173
Modulul B
10. Robu N., Programare concurentă. Mecanisme suport orientate timp

real, Timişoara, Editura Politehnica, 2007.
11. Sebestyen Gh., Informatică industrială, Cluj-Napoca, Editura Albas-

tră, 2006.
12. Ştefănescu C., Cupcea N., Sisteme inteligente de măsurare şi con-

trol, Cluj-Napoca, Editura Albastră, 2002.
13. Tanenbaum, S. A. Operating systems. Design and implentation,

Prentice Hall, New York, 1987.
14. Toma, L. Sisteme de achiziţie şi prelucrare numerică a semnalelor,

Timişoara, Editura de Vest, 1996.
15. http://www.on-time.com/rtkernel-dos.htm
174
NICOLAE PARASCHIV
PROGRAMAREA
APLICAȚIILOR DE
TIMP REAL
- SINTEZE -
EDITURA UNIVERSITĂŢII PETROL-GAZE DIN PLOIEŞTI

2018
Copyright©2018 Editura Universităţii Petrol-Gaze din Ploieşti
Toate drepturile asupra acestei ediţii sunt rezervate editurii
Autorul poartă întreaga răspundere morală, legală şi materială faţă de editură şi terţe
persoane pentru conţinutul lucrării.
Lucrarea a fost avizată în cadrul Departamentului de Învăţământ la Distanţă şi cu

Frecvenţă Redusă din Universitatea Petrol-Gaze din Ploieşti.
Descrierea CIP a Bibliotecii Naţionale a României

PARASCHIV, NICOLAE
Programarea aplicaţiilor de timp real : sinteze / Nicolae Paraschiv. -
Ploieşti : Editura Universităţii Petrol-Gaze din Ploieşti, 2018
Conţine bibliografie
ISBN 978-973-719-746-7
004
Control ştiinţific:
Prof. univ. dr. ing. Gabriel Rădulescu
Prof. univ. dr. ing. Otilia Cangea
Redactor:
Conf. univ. dr. ing. Gabriela Bucur
Tehnoredactare computerizată:
Prof. univ. dr. ing. Nicolae Paraschiv
Coperta:
Şef lucr. dr. ing. Marian Popescu
Director editură:
Prof. univ. dr. ing. Şerban Vasilescu
Adresa:
Editura Universităţii Petrol-Gaze din Ploieşti
Bd. Bucureşti 39, cod 100680
Ploieşti, România
Tel. 0244-573171, Fax. 0244-575847
http://editura.upg-ploiesti.ro/
PROGRAMAREA APLICAȚIILOR DE TIMP REAL - SINTEZE
PREFAȚĂ
Prezenta lucrare a fost elaborată pe baza fișei disciplinei aferente cursului

Programarea aplicațiilor de timp real, predat studenţilor anului patru ai
specializării Automatică şi Informatică Aplicată (Învățământ cu Frecvență
Redusă) din Facultatea Inginerie Mecanică şi Electrică a Universităţii Petrol-
Gaze din Ploieşti.
Scopul principal al disciplinei şi implicit al acestei lucrări este reprezentat
de formarea unei imagini obiective în ceea ce priveşte problematica dezvoltării
componentei programare a aplicaţiilor de timp real, în primul rând a celor de
conducere a proceselor.
În afara acestui obiectiv general, lucrarea – în calitate de suport al
disciplinei Programarea aplicaţiilor de timp real – îşi propune o serie de
obiective punctuale, între care semnificative sunt următoarele:
• familiarizarea studenţilor cu problematica tratării interacţiunilor dintre
taskuri şi a operaţiilor fundamentale multitasking;
• însuşirea modului de utilizare în aplicaţii a principalelor funcţii ale
nucleului de timp real RTK;
• însuşirea aspectelor relevante care privesc procesarea datelor achiziţionate
şi a comenzilor elaborate;
• familiarizarea cu principalele aspecte referitoare la bazele de date de
proces şi dezvoltării taskurilor aferente unor regulatoare integrate în
sisteme de reglare automată cu acţiune după abatere.
Lucrarea este structurată în patru module, între care primele două sunt
dedicate prezentării principalelor aspecte asociate sistemelor de conducere în
timp real şi mecanismelor programării concurente în timp real. Următoarele două
module sunt consacrate prezentării nucleului RTK (în calitate de resursă pentru
programarea în timp real) şi prelucrării în timp real a informației de proces
• Primul modul al lucrării, structurat în două unități de învățare (sinteze),
expune unele consideraţii privind sistemele de conducere în timp real.
Sunt tratate succint funcţiile automatizării proceselor şi prezentate
caracteristicile aplicațiilor de conducere în timp real şi a celor
tranzacţionale. Se prezintă de asemenea trăsăturilor sistemelor de operare
în timp real alături de obiectivele şi principiile ingineriei programării în
timp real.
• Al doilea modul care include 4 unități de învățare (sinteze) este focalizat
pe prezentarea operaţiilor fundamentale multitasking şi a unor instrumente
de implementare a acestora. Este pe larg prezentată excluderea mutuală ce
reglementează utilizarea neconflictuală a resurselor critice.
1
• Al treilea modul, care conține 5 unități de învățare (sinteze) se deschide

cu o succintă abordare referitoare la cerinţele şi caracteristicilor limbajelor
de programare în timp real. Sunt apoi evidenţiate trăsăturile nucleului de
timp real RTK şi descrise pe larg şase familii de funcţii ale acestuia. Pentru
fiecare familie sunt prezentate exemple care vor fi testate şi ulterior
dezvoltate în cadrul activităţilor aplicative.
• Modulul 4 structurat în 3 unități de învățare tratează (sinteze) detaliază în
prima parte operaţiile de prelucrare primară a datelor preluate de la
traductoare şi a comenzilor destinate elementelor de execuţie. Sunt apoi
prezentate la nivel de schemă logică taskurile asociate implementării
algoritmilor reglare PID şi bipoziţional. Ultima parte a modulului patru
tratează la nivel conceptual bazele da date de proces, cu precădere
cerințele la care trebuie să răspundă sistemul de gestiune al unei asemenea
baze de date.
Lucrarea se încheie cu o a 15-a unitate de învățare care include exerciții și
teste de autoevaluare suplimentare însoțite de răspunsuri.
Fiecare unitate de învățare (sinteză) include pe lângă dezvoltarea teoretică
propriu-zisă secțiuni care includ:
- cunoștințe și deprinderi care vor fi ucumulate după parcurgerea unității
de învățare;
- exerciții și teste de autevaluare (cu răsunsuri);
- lucrare de verificare a cunoștințelor acumulate;
- rezumat;
- bibliografie.
Prezenta lucrare reprezintă o ediție revizuită și adăugită a lucrării
Programarea aplicațiilor de timp real apărută în anul 2014 la Editura
Universității Petrol-Gaze din Ploiești, autor Nicolae Paraschiv.
Disciplina Programarea aplicațiilor de timp real este obligatorie, fiind
prevăzută în planul de învăţământ cu 6 puncte de credit. Cunoștințele expuse în
cele 14 unități de învăţare pot fi asimilate în timpul pentru studiu individual
prevăzut în fișa acestei disciplinei.
Prof. Univ. Dr. Ing. Nicolae Paraschiv

Ploiești, 2018
2
CUPRINS
PREFAȚĂ ........................................................................................................................................ 1
CUPRINS ........................................................................................................................................ 3
MODULUL DE STUDIU 1 ................................................................................................................ 7
SISTEME DE CONDUCERE ÎN TIMP REAL ....................................................................................... 7
Unitatea de învăţare 1-1.1 ......................................................................................................... 7
Funcții ale automatizării proceselor ...................................................................................... 7
1-1.1.1 Strategii de conducere .......................................................................................... 7
1-1.1.2 Monitorizarea automată ..................................................................................... 10
1-1.1.3 Protecția automată ............................................................................................ 14
1-1.1.4 Optimizarea automată ....................................................................................... 18
MODULUL DE STUDIU 1 .............................................................................................................. 21
SISTEME DE CONDUCERE ÎN TIMP REAL ..................................................................................... 21
Unitatea de învăţare 2-1.2 ....................................................................................................... 21
Ingineria aplicațiilor de timp real ........................................................................................ 21
2-1.2.1 Tipuri de aplicații de timp real ............................................................................ 21
2-1.2.2 Trăsături ale sistemelor de operare în timp real ................................................ 26
2-1.2.3 Obiectivele și principiile ingineriei programării aplicațiilor de timp real ............ 31
MECANISMELE PROGRAMĂRII CONCURENTE A ......................................................................... 39
APLICAȚIILOR DE TIMP REAL ....................................................................................................... 39
Stările și tranzițiile taskurilor .............................................................................................. 39
3-2.1.1 Stările taskurilor .................................................................................................. 39
3-2.1.2 Tranzițiile taskurilor ............................................................................................ 43
MECANISMELE PROGRAMĂRII CONCURENTE A ....................................................... 49
APLICAȚIILOR DE TIMP real ............................................................................................. 49
Conflicte potențiale în sistemele multitasking .................................................................... 49
4-2.2.1 Resurse și secțiuni critice .................................................................................... 49
4-2.2.2 Excluderea mutuală realizată cu semafoare ....................................................... 52
4-2.2.3 Excluderea mutuală realizată cu variabile de tip eveniment .............................. 56
4-2.2.4 Excluderea mutuală realizată cu mesaje și cutii poștale..................................... 59
4-2.2.5 Alte modalități de realizare a excluderii mutuale ............................................... 62
3
Sincronizarea taskurilor....................................................................................................... 67
5-2.3.1 Definirea sincronizării ......................................................................................... 67
5-2.3.2 Sincronizarea realizată cu semafoare ................................................................. 69
5-2.3.3 Sincronizarea realizată cu variabile de tip eveniment ........................................ 72
5-2.3.4 Sincronizarea realizată cu mesaje și cutii poștale ............................................... 74
5-2.3.5 Sincronizarea realizată cu monitoare și blocuri de întâlnire .............................. 79
Comunicarea între taskuri ................................................................................................... 85
6-2.4.1 Aspecte introductive ........................................................................................... 85
6-2.4.2 Utilizarea în comunicare a semafoarelor ............................................................ 87
6-2.4.3 Utilizarea în comunicare a mesajelor și cutiilor poștale ..................................... 90
RESURSE PENTRU PROGRAMAREA APLICAȚIILOR ...................................................................... 95
DE TIMP REAL .............................................................................................................................. 95
Cerințe și caracteristici ale limbajelor pentru programarea aplicațiilor de timp real
(LPATR) ............................................................................................................................. 95
7-3.1.1 Tipuri de LPATR ................................................................................................... 95
7-3.1.2 Cerințe impuse LPATR ......................................................................................... 98
7-3.1.3 Caracteristici ale LPATR ....................................................................................... 99
MODULUL DE STUDIU 3 ............................................................................................................ 105
RESURSE PENTRU PROGRAMAREA APLICAȚIILOR .................................................................... 105
DE TIMP REAL ............................................................................................................................ 105
Unitatea de învăţare 8-3.2 ..................................................................................................... 105
Nucleul de timp real RTK – caracteristici, inițializare și administrare ............................. 105
8-3.2.1 Caracteristicile nucleului RTK ............................................................................ 105
8-3.2.2 Taskuri sub RTK ................................................................................................. 106
8-3.2.3 Funcții RTK de inițializare .................................................................................. 110
8-3.2.4 Funcții RTK de administrare a taskurilor ........................................................... 112
DE TIMP REAL ............................................................................................................................ 119
Unitatea de învăţare 9-3.3 ..................................................................................................... 119
Nucleul de timp real RTK – funcții de gestionare a timpului și semafoarelor .................. 119
9-3.3.1 Timpul în context RTK ...................................................................................... 119
9-3.3.2 Funcții RTK de gestionare a timpului ................................................................ 120
9-3.3.3 Semafoare în context RTK ................................................................................ 124
4
9-3.3.4 Funcții RTK de gestionare a semafoarelor ........................................................ 125

DE TIMP REAL ............................................................................................................................ 135
Unitatea de învăţare 10-3.4 .......................................................................................... 135
Nucleul de timp real RTK – funcții de gestionare a cutiilor poștale ................................. 135
10-3.4.1 Cutii poștale în context RTK ........................................................................... 135
10-3.4.2 Funcții RTK de gestionare a cutiilor poștale .................................................... 136
DE TIMP REAL ............................................................................................................................ 149
Nucleul de timp real RTK – funcții de gestionare a mesajelor de trecere ......................... 149
11-3.5.1 Mesaje de trecere în context RTK .................................................................. 149
11-3.5.2 Funcții RTK de gestionare a mesajelor de trecere .......................................... 150
PRELUCRAREA ÎN TIMP REAL A INFORMAŢIEI DE PROCES........................................................ 161
Operații de prelucrare primară a datelor de proces ........................................................... 161
12-4.1.1 Tipuri de operații de prelucrare primară a datelor de proces ........................ 161
12-4.1.2 Filtrarea datelor achiziționate ........................................................................ 163
12-4.1.3 Circuitul informațional aferent unei aplicații de conducere ........................... 165
12-4.1.4 Conversia în unități inginerești ....................................................................... 168
12-4.1.5 Conversia din unități inginerești ..................................................................... 179
12-4.1.6 Validarea mărimilor achiziționate și a comenzilor elaborate ......................... 190
Taskuri asociate unor algoritmi uzuali de reglare numerică ............................................. 201
13-4.2.1 Taskuri asociate unui sistem de reglare automata cu regulator Proporțional
Integrator Derivator (PID) ............................................................................................. 202
13-4.2.2 Taskuri asociate unui sistem de reglare automată cu regulator bipozițional. 208
Baze de date de proces .......................................................................................................... 223
14-4.3.1 Cerințe impuse bazelor de date de proces ..................................................... 223
14-4.3.2 Tipuri de date incluse în bazele de date de proces ......................................... 225
5

STUDIU SUPLIMENTAR .............................................................................................................. 231
Unitatea de învăţare 15................................................................................................. 231
Exerciții și teste de autoevaluare ........................................................................................... 231
15 - ES12 Exerciții suplimentarea pentru modulele de studiu 1 și 2 ............................ 232
15 - TS12 Teste suplimentare de autoevaluare pentru modulele de studiu 1 și 2 ...... 233
15 - RS12 Răspunsuri la testele suplimentare de autoevaluare pentru modulele de
studiu 1 și 2 ................................................................................................................... 234
15 – ES34 Exerciții suplimentarea pentru modulele de studiu 3 și 4 ........................... 237
15 – TS34 Teste suplimentare de autoevaluare pentru modulele de studiu 3 și 4 ...... 238
15 – RS34 Răspunsuri la testele suplimentare de autoevaluare pentru modulele de
studiu 3 și 4 ................................................................................................................... 241
6
MODULUL DE STUDIU 1
SISTEME DE CONDUCERE ÎN TIMP REAL
Unitatea de învăţare 1-1.1
Funcții ale automatizării proceselor
1-1.1.1 Strategii de conducere
1-1.1.2 Monitorizarea automată
1-1.1.3 Reglarea automată
1-1.1.4 Protecția automată
1-1.1.5 Optimizarea automată
Cunoştinţe şi deprinderi
La finalul parcurgerii acestei unităţi de învăţare vei înţelege:
- ce este un proces;
- în ce constă conducerea unui proces;
- care sunt funcțiile automatizării proceselor;
- cum pot fi realizate obiectivele unui proces prin funcții ale automatizării.
La finalul parcurgerii acestei unităţi de învăţare vei putea să:
- caracterizezi obiectivele unui proces;
- faci diferența între conducerea corectivă și cea preventivă;
- interpretezi funcțiile automatizării din perspectiva realizării obiectivelor
unui proces.
1-1.1.1 Strategii de conducere

În mod uzual, 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 (locate în instalații de tip
industrial) 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 securitate.
Aceste obiective sunt de regulă formulate prin specificaţii asociate
produselor sau serviciilor rezultate, mărimea beneficiilor obținute ca urmare a
valorificării acestora, norme de protecţie a factorului uman, a mediului ambiant
şi infrastructurii procesului.
7
Conducerea încadrează activitatea 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).
Exerciţiul 1
Care sunt obiectivele unui proces?
Dacă OC se află numai sub influenţa comenzilor şi are caracteristici

invariante în timp, este suficientă determinarea comenzilor ţinând cont numai de
obiective. După cum se observă din figura 1.1 sistemul de conducere este cu
structură deschisă în sensul că mijlocul de conducere nu este informat în legătură
cu rezultatul acţiunilor sale.
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 strategia de
conducere este corectivă.
Perturbaţii

MC OC
Feedback
Fig. 1.2. Sistem de conducere cu acţiune corectivă (după efect).
Caracterul corectiv al acestei strategii este conferit de faptul că prin

acţiunea comenzilor rezultatele sunt corectate în sensul că sunt readuse la nivelul
obiectivelor. În acest scop 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
8
legături informaţionale face ca sistemele de conducere cu acţiune corectivă să fie

cu structură închisă în raport cu rezultatele.
Este important de subliniat faptul că rezultatele sunt restabilite la nivelul
obiectivelor indiferent de cauza care a determinat alterarea lor. Există însă şi un
neajuns al acţiunii corective determinat de faptul că există intervale de timp în
care rezultatele nu sunt în concordanţă cu obiectivele.
Dezavantajul identificat la sistemele de conducere cu acţiune corectivă
este diminuat dacă la elaborarea comenzilor, pe lângă obiective sunt avute în
vedere şi o parte dintre perturbaţii, strategia (acțiunea) fiind în acest caz
preventivă. 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.

MC OC
Fig. 1.3. Sistem de conducere cu acţiune preventive (după cauză).
La un asemenea sistem de conducere comenzile sunt astfel determinate

încât la modificarea acelor perturbaţii care sunt luate în considerare, rezultatele să
nu se abată de la obiective. Strategia preventivă are în vedere faptul că se
previne apariţia unui efect reprezentat de îndepărtarea rezultatelor de la
obiective.
Dacă se modifică însă obiectivele sau o perturbaţie care nu este
considerată de către MC rezultatele nu mai sunt conforme cu obiectivele, iar
acest efect nu mai poate fi îndepărtat, întrucât acest sistem de conducere prezintă
structură deschisă în raport cu rezultatele.
Dezavantajele celor două tipuri de acţiune sunt parţiale eliminate, dacă
strategia de conducere este mixtă, respectiv cu acțiune după efect şi după cauză.
9

MC OC
Feedback
Fig. 1.4. Sistem de conducere cu acţiune corectivă și preventive

(după efect şi după cauză).
Sistemul acţionează după cauză (respectiv preventiv) la modificarea

perturbaţiilor considerate. La modificarea altor perturbaţii sau a obiectivelor
acţiunea este după efect (respectiv corectivă).
Testul de autoevaluare 1
Enumerați motivele principale care justifică strategia mixtă de
conducere (preventivă și 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ă.
Este de menţionat faptul că pentru primele trei funcţ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.2 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 asociat monitorizării este egal cu numărul gradelor de libertate ale
procesului, respectiv
F = L-M , (1.1)
unde: L este numărul total de variabile aferente procesului;
10
M – numărul de relaţii independente dintre cele L variabile;

F – numărul gradelor de libertate.
Este important de subliniat că parametrul F indică numai numărul
variabilelor care trebuie măsurate nu și care sunt aceste variabile.
Exerciţiul 2
Indicați procedeele prin care pot fi determinate, în cadrul monitorizării,
valorile aferente parametrilor unui proces.
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ţin microcontrollere cu convertoare
analog-numerice (CAN) încorporate. Sunt încă utilizate traductoarele cu semnal
de ieşire analogic în domeniu unificat (uzual 4…20 mA).
Liniile de transmisie pentru semnale analogice sunt realizate în
exclusivitate din conductoare metalice. În cazul traductoarelor numerice (smart
transducers), acestea sunt conectate de regulă în reţele în care transmisia poate fi
cu sau fără fir (wireless).
În ceea ce priveşte instrumentele de vizualizare 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.
1-1.1.3 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
valorii de referinţă pentru un singur parametru.
11
Î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.
…
a
P
i y
DA PrT
m
p1 pk pn
b
… …
..
I P
y
m
DA PrT
Fig. 1.5. Schema bloc simplificată de structură a unui SRA:

a – abatere; b – perturbaţie; DA - dispozitiv de automatizare; PrT – proces
tehnologic.
Pentru asigurarea funcţionalităţii, un SRA convenţional 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 şi 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.
12
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 regulatorul cu acțiune după abatere sau după perturbație.
Parametri de
acordare Perturbaţii
i
u r
CA EE PrT T
a
Perturbaţii
I u y
CP EE PrT
Fig. 1.6. SRA cu evidenţierea părţilor fixată şi variabilă:

a - SRA abatere; CA – regulator abatere;
b - SRA perturbaţie; CP – regulator perturbație; PrT – proces tehnologic.
Exerciţiul 3
Evidențiați principalele avantaje pe care le oferă reglarea după abatere,
respectiv cea după perturbație.
În ceea ce privește numărul maxim de SRA care pot fi asociate unui

proces, acesta este impus de numărul de disponibil de agenți de reglare (mărimi
de execuție) și nu de numărul de parametri care se doresc a fi reglați.
Este important de subliniat că din punctul de vedere al echipamentelor
numerice de conducere, traductoarele şi elementele de execuţie sunt considerate
13
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.
Precizați cine indică numărul minim de sisteme de măsurat respectiv
maxim de sisteme de reglare automată pentru un proces.
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.
Precizați, prin analogie cu sistemele de conducere, strategiile pe care
le implementează SRA abatere, respectiv perturbație.
1-1.1.3 Protecția automată

Sistemele de protecţie automată (SPA) asigură pentru un proces,
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 funcțiile de intervenţie de către sistemele automate de blocare şi
de comandă.
• Sistemele de avertizare automată (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.7.
Funcţie de situaţia semnalată avertizarea poate fi:
- avertizare de poziţie;
- avertizare de prevenire;
- avertizare de avarie.
14
Limite de avertizare
P1lima Pklima Pnlima AA

… …
AO1
ui mi
BLP_A EA AO2
.. ..
… … . .
AOn
T1 Tk Tn
P1 Pk Pn
PROCES
TEHNOLOGIC
Fig. 1.7. Structura unui sistem de avertizare:

BLP_A - bloc logic program avertizare; EAA – elemente acţionare avertizoare;
AA - avertizor acustic AO1, AO2… AOn - avertizoare optice; T1.. Tk… Tn –
traductoare; P1…Pk… Pn – parametri supravegeați; P1lima…Pklima… Pnlima – limite de
avertizare pentru parametrii supravegeați; ui – comenzi pentru EAA; mi - semnale de
acționare pentru avertizoare.
Avertizarea de poziţie informează în legătură cu starea de funcţionare

sau nu a unui utilaj, fără a determina o anume acţiune din partea personalului de
operare a procesului.
Avertizarea de prevenire informează despre apariția unei situații, care
dacă nu este remediată în timp util poate conduce la o avarie. De regulă,
remedierea presupune intervenția personalului care operează procesul.
Avertizarea de avarie informează în legătură cu producerea unui
eveniment care a condus la scoaterea intempestivă din funcțiune a unui utilaj,
respectiv blocarea funcționării acestuia.
O caracteristică a sistemelor de avertizare constă în caracterul deschis al
acestora, aspect evidențiat și în figura 1.7.
Componenta esențială a unui SAA este Blocul Logic Program Avertizare
(BLP_A) care ca intrări semnalele furnizate de traductoarele asociate
parametrilor supravegheați și limitele asociate acestora. BLP_A are implementate
funcțiile logice asociate programului de avertizare (semnalizare). Pe baza
acestor funcții se generează secvența de comenzi care este aplicată, prin
intermediul EAA, avertizoarelor de tip acustic sau optic. Avertizorul acustic este
unic, iar avertizoarele optice sunt în număr egal cu cel al parametrilor
supravegheați.
15
Exerciţiul 4
Care este rolul BLP_A în cadrul SAA?
• Sistemele de blocare automată (SBA) determină scoaterea din

funcţiune a unui utilaj sau secţiune dintr-o instalaţie gazdă a unui proces
tehnologic, întrucât nu s-a intervenit în timp util după avertizarea de prevenire.
Scoaterea din funcțiune presupune blocarea alimentării cu resurse, în primul rând
materiale și/sau energetice.
După cum se remarcă din figura 1.8 în care se prezintă schema bloc a
unui SBA, acesta este cu structură închisă, în sensul că Blocul Logic Program
Blocare (BLP_B) este informat în legătură cu valorile parametrilor supravegheați
implicați în blocare. În afara semnalelor furnizate de traductoarele asociate
parametrilor supravegheați implicați în blocare și BLP_B are ca intrări limitele
asociate acestora (diferite de limitele specifice avertizării).
Limite de blocare
Resurse
P1limb Pklimb Pnlimb pentru
… … proces
ui m
BLP_B EASB SBRP
… …
T1 Tk Tn
P1 Pk Pn
PROCES
TEHNOLOGIC
Fig. 1.8. Structura unui sistem de blocare:

BLP_B - bloc logic program blocare ; EASB – element acționare sistem blocare;
T1… Tk… Tn – traductoare; P1…Pk… Pn – parametri supravegeați; P1limb…
Pklimb… Pnlimb – limite de blocare pentru parametrii supravegeați; ui – comenzi
pentru EASB; SBRP – sistem blocare resurse pentru proces; m-semnal de
acționare pentru SBRP.
Ca și în cazul sistemelor de avertizare, BLP_B are implementate funcții
logice și anume pe cele asociate programului de blocare. Pe baza acestor funcții
se generează secvența de comenzi care este aplicată, prin intermediul EASB
sistemului de blocare a resurselor SBRP. Practic blocarea alimentării cu resurse
determină scoaterea din funcțiune a utilajului protejat. În figura 1.8, SBRB este
16
figurat sub forma unui comutator care conectează/deconectează procesul la/de la

resurse.
Este de remarcat faptul că SBA acţionează numai la scoaterea din
funcţiune, (respectiv, deconectarea de la resurse) nu și la repornire (respectiv,
conectarea la resurse). Această caracteristică este sugerată în figura 1.8 prin
săgeata roșie punctată.
Exerciţiul 5
Care este rolul BLP_B în cadrul SBA?
SBA este conectat cu SAA avarie, în sensul că scoaterea din funcțiune a
unui utilaj, a unei secvențe de instalație sau a întregii instalații este interpretată ca
o avarie.
• Sistemele de comandă automată (SCA) sunt componente ale SPA
care asigură oprirea manuală sau pornirea condiţionată a unui utilaj sau secţiune
dintr-o instalaţie gazdă a unui proces tehnologic. Condiţionarea pornirii constă în
testarea îndeplinirii unor condiţii într-o succesiune temporală impusă, care
preced, de exemplu, conectarea la resurse.
Condiții pornire
Resurse
CP1 CPk CPn pentru
proces
… …
ui m
BLP_C EASVCP SVCP
… …
PP1 PPk PPn
SPM
Parametri urmăriți la
pornire SOM
PROCES
TEHNOLOGIC
Fig. 1.9. Structura unui sistem de comandă:

BLP_C - bloc logic program de comandă; EASVCP – element acționare sistem
validare condiții de pornire; PP1… PPk… PPn – parametri urmăriți la pornire;
CP1… CPk… CPn – condiții pornire ; ui – comenzi pentru EASVCP; SVCP –
sistem validare condiții pornire; m-semnal de acționare pentru SVCP; SPM –
sistem pornire manuală; SOM – sistem oprire manuală; .
17
După cum rezultă din figura 1.9 unde este prezentată structura
principială, a unui SCA, acesta este un sistem cu structură deschisă care conține
ca element central Blocul Logic Program Comandă (BLP_C). Ca și în cazul
sistemelor de avertizare respectiv blocare și acest bloc are implementate funcții
logice, de data aceasta pe cele asociate programului de comandă. Pe baza
acestor funcții se generează secvența de comenzi care este aplicată, prin
intermediul EASVCP sistemului de validare a condițiilor de pornire SVCP.
Validarea este reprezentată în figura 1.9 prin închiderea unui comutator (acțiune
figurată prin săgeata punctată de culoare verde.
În urma validării, conectarea propriuzisă este realizată de către
personalul de operare prin acționarea unui element corespunzător numit generic
sistem de pornire manuală (SPM), care este asmilat, după cum este ilustrat în
figura 1.9 sub forma unui buton de acționare normal deschis.
Exerciţiul 6
Care este rolul BLP_C în cadrul SCA?
Este de menționat faptul că tot prin intermediul SCA se poate realiza

oprirea normală, prin deconectarea procesului de la resurse. În figura 1.9 această
disponibilitate este indicate prin prezența sistemului de oprire manuală SOM,
asimilat unui buton de acționare normal închis.
SCA este conectat cu SAA poziție, care după cum s-a arătat indică dacă
un utilaj, secvență de instalație sau întreaga instalație este în funcțiune sau nu.
1-1.1.4 Optimizarea automată
Conducerea optimală, care asigură realizarea obiectivului de eficienţă
pentru proces presupune aplicarea către aceasta a comenzilor optimale, respectiv
a celor mai convenabile comenzi în raport cu un criteriu de performanță.
Criteriul de performanță se prezintă sub forma unei funcții obiectiv, iar
comenzile optimale rezultă prin soluționarea unei probleme de optimizare.
Soluționarea acestei probleme conduce la determinarea acelor comenzi care
extremizează, respectiv maximizează sau minimizează după caz funcția obiectiv.
Exerciţiul 7
Ce rezultă prin soluționarea unei probleme de optimizare?
Este important de subliniat că nivelul de optimizare se situează de regulă
la un nivel superior reglării convenţionale. În acest context, comenzile rezultate
ca urmare a soluționării problemei de optimizare pot fi aplicate în calitate de
referințe sistemelor de reglare convenționale.
18
Lucrare de verificare
1. Care sunt obiectivele unui proces?
2. Ce reprezintă conducerea unui proces?
3. Care sunt funcțiile automatizării proceselor?
4. Cine indică numărul de SRA pentru un proces?
5. Ce obiectiv al unui proces este realizat prin funcția de protectie
automată?
6. Denumiți tipurile de sisteme de protecție?
7. În ce constă avertizarea de prevenire?
Rezumat
Conducerea unui proces presupune dirijarea acestuia, prin aplicarea de
comenzi, pentru realizarea obiectivelor de calitate, eficiență, securitate.
Strategia de conducere poate fi: corectivă, preventivă, mixtă.
Conducerea automată nu implică prezența factorului uman în
adoptarea și aplicarea de comenzi.
Funcțiile automatizării proceselor sunt: monitorizarea automată,
reglarea automată, protecția automată, optimizarea automată.
Monitorizarea automată este implicată în realizarea tuturor celor patru
obiective.
Reglarea automată susține în primul rând realizarea obiectivului de
calitate.
Protecția automată asigură realizarea obiectivului de securitate.
Optimizarea automată asigură realizarea obiectivului de eficiență.
Reglarea convențională poate fi după abatere (corectivă) sau după
perturbație (preventivă).
Sistemele de protecție automată pot fi: de avertizare, de blocare, de
comandă.
Conducerea optimală presupune aplicarea către proces a comenzilor
Răspunsurile la testele de autoevaluare
1. Enunț
Enumerați motivele principale care justifică strategia mixtă de
conducere (preventivă și corectivă).
19
Răspunsurile la testele de autoevaluare (continuare)
Rezolvare
Componenta preventivă – menținerea realizărilor la nivelul
obiectivelor în condițiile modificării uneia sau mai multor perturbații
considerate.
Componenta corectivă – aducerea realizărilor la nivelul obiectivelor în
condițiile modificării perturbațiilor neluate în considerare sau a
obiectivelor.
2. Enunț
Precizați cine indică numărul minim de sisteme de măsurat respectiv
maxim de sisteme de reglare automată pentru un proces.
Rezolvare
Numărul minim de sisteme de măsurat – este impus de numărul
gradelor de libertate.
Numărul maxim de sisteme de reglare automată – este impus de
numărul disponibil de mărimi de execuție (agenți de reglare).
3. Enunț
Precizați, prin analogie cu sistemele de conducere, strategiile pe care
le implementează SRA abatere, respectiv perturbație.
Rezolvare
SRA abatere – implementează stategia corectivă , deoarece eliminarea
abaterii (efectului) reprezintă o corecție. este impus de numărul
gradelor de libertate.
SRA perturbație – implementează stategia preventivă , deoarece se
previne apariției unei abateri (efect) la modificarea perurbațiilor
(cauzelor) considerate.
Bibliografie
1. Marinoiu V., Paraschiv, N., Automatizarea proceselor chimice.
Bucureşti, Editura Tehnică, 1992.
2. Paraschiv N., Programarea aplicațiilor de timp real, Editura
Universității Petrol-Gaze din Ploiești, 2014.
3. Pricop E., Mihalache S.F., Paraschiv N., Fattahi J., Zamfir F.,
Considerations regarding security issues impact on systems availability.
Proceedings of the 8th International Conference on Electronics,
Computers and Artificial Intelligence, ECAI 2016, Ploiesti, Romania,
2017; pp. 1–6.
20
MODULUL DE STUDIU 1
SISTEME DE CONDUCERE ÎN TIMP REAL
Ingineria aplicațiilor de timp real
2-1.2.1 Tipuri de aplicații de timp real
2-1.2.2 Trăsături ale sistemelor de operare în timp real
2-1.2.3 Obiectivele și principiile ingineriei programării aplicațiilor de timp real
- în ce constă comportarea în timp real a unui sistem de conducere ;
- care sunt trăsăturile și funcțiile unui sistem de operare în timp real;
- care sunt obiectivele și principiile ingineriei programării în timp real
(IPTR);
- să care sunt etapele aferente dezvoltării unei aplicații informatice.
- caracterizezi un sistem de conducere în timp real;
- faci diferența între procesarea paralelă și cea pseudoparalelă;
- interpretezi problemele pe care trebuie să le soluționeze IPTR;
- stabilești etapele aferente dezvoltării unei aplicații informatice.
2-1.2.1 Tipuri de aplicații de 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 mijlocul de conducere sunt emise la
momentul oportun, respectiv dacă 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ă esenţială 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 cuantificat practic prin 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 Această frecvență este reglementată de
teorema Schannon – Nyquist (cunoscută ca teorema eșantionării) , care stabileşte
21
că pentru a se păstra consistența informațională (respectiv pentru a nu se pierde

informaţie), frecvenţa de eşantionare trebuie să fie cel puţin egală cu dublul
frecvenţei semnalului care se achiziţionează. Prin extensie, frecvența cu care se
aplică o comandă procesului coincide cu frecvența cu care a fost achiziționată
mărimea din proces pe baza căreia a fost determinată respectiva comandă1.
Având în vedere corelaţia timp real – inerţie se poate spune că nu există
un comportament universal ci unul specific fiecărui proces2 impus de inerția
acestuia. Din acest motiv o denumire alternativă pentru noţiunea de timp real
este cea de timp util sau timp specific.
Exerciţiul 1
Ce afirmă teorema Nyquist-Shannon?
Justificați din perspectiva dinamicii unui proces sintagma comportare
în timp util sau timp specific, în calitate de alternativă la cea de
comportare în timp real.
În continuare vor fi prezentate două tipuri relevante de aplicaţii de timp
real şi anume aplicaţii de conducere şi aplicaţii tranzacţionale.
• Aplicaţiile de conducere se referă la elaborarea şi transmiterea în
timp real de comenzi, către un proces.
Pentru exemplificare în figura 1.10 se prezintă structura unei astfel de
aplicaţii, care permite realizarea următoarelor funcţii:
- achiziţia datelor;
- procesarea datelor achiziţionate;
- actualizarea bazei de date de proces;
- procesarea comenzilor în vederea transmiterii către elementele de
execuţie;
- intervenții ale operatorului de la o consolă specializată;
- generarea de rapoarte la cerere.
1
Aplicarea către proces a unei comenzi la cărei determinare intervin mărimi cu frecvențe de
eșantionare diferite, se face cu o frecvență egală cu frecvența de eșantionare cea mai ridicată.
2
Un comportament universal ar impune o unică frecvență de eșantionare, indiferent de dinamica
proceselor, ceea ce ar încălca teorema eșantionării.
22
MIJLOC DE CONDUCERE
COP
MEC
MGR
CTR
BDP MABDP
MPDA MPCE
SDCN SADA SDCA
TA EEA
EEN PROCES CONDUS
Fig. 1.10. Structura unui sistem de conducere în timp real:

BDP-baza de date de proces; MGR-modul generare rapoarte;
MABDP-modul actualizare BDP; MEC – modul elaborare comenzi;
COP-consola operator; CTR – ceas de timp real; SADA – subsistem achiziție date
analogice; MPDA-modul prelucrare date achiziționate; SDCA – subsistem distribuție
comenzi analogice; MPCE-modul prelucrare comenzi elaborate; SDCN – subsistem
distribuție comenzi numerice;TA- traductoare analogice; EEA - Elemente de execuţie
analogice; EEN – Elemente de execuţie numerice.
Procesul este accesat prin intermediul traductoarelor analogice și

elementelor de execuție analogice, respective numerice (TA, EEA și EEN), care
după cum s-a menționat în unitatea de învățare numărul 1 (UI 1-1.1), sunt
considerate echipamente periferice de proces (EPP).
Mijlocul de conducere, reprezentat practic de un echipament numeric, este
conectat la EPP printr-un sistem de de interfață adecvat 3 din care în figura 1.10
sunt figurate subsistemul de achiziție a datelor analogice (SADA) și cele de
3
În mod uzual acesta este cunoscut ca Sistem de Interfață Proces Calculator (SIPC).
23
distribuție aferente comenzilor analogice (SDCA) și numerice (SDCN). Este de

menționat faptul că actualele traductoare și elemente de execuție digitale (de tip
SMART) conțin o componentă analogică4, acestea au incluse convertoare analog
numerice (CAN) respectiv convertoare numeric analogice (CNA). Având în
vedere că CAN și CNA sunt componente esențiale ale SADA respectiv SDCA se
consideră că traductoarele digitale includ SADA iar elementelelele de execuție
digitale includ SDCA.
Semnalele digitale furnizate de SADA sunt procesate în MPDA, în vederea
conversiei în unități inginerești, respectiv în unități în care sunt exprimați
parametrii care se achiziționează (unități fizice) . În unitatea de învățare 12 (UI
12-4.1) se prezintă deducerea unor algoritmi de conversie din cadrul MPDA.
În cadrul modulului elaborare comenzi MEC se determină comenzile
corespunzător algoritmului sau algoritmilor de reglare implementați. În unitatea
de învățare 13 (UI 13-4.2) se prezintă elemente care privesc implementarea unor
algoritmi uzuali de reglare.
Mărimile de comandă elaborate în unități inginerești sunt procesate în
modulul MPCE, în sensul conversiei în semnale acceptate de SDCA. În unitatea
de învățare 12 (UI 12-4.1) se prezintă deducerea unor algoritmi de conversie din
cadrul MPCE.
O resursă importantă a sistemului de conducere în timp real este baza de
date de proces BDP care conține fișiere istorice aferente evoluției procesului și
elemente utile pentru determinarea comenzilor. Conținutul BDP este actualizat de
către modulul dedicat MABDP care primește date de la MEC, MPDA și COP.
Probleme specifice ale BDP sunt tratate în unitatea de învățare 14 (UI 14-4.3).
Modulele MPDA, MEC, MPCE sunt sincronizate cu timpul, prezența
ceasului de timp real CTR sugerând acest aspect. În unitatea de învățare 5 (UI 5-
2.3) este abordată sincronizarea aplicațiilor.
Exerciţiul 2
Explicați rolurile MPDA și MPCE în cadrul unui sistem de de
conducere în timp real.
Operatorul procesului are la dispoziție consola operatorului (COP) prin
care poate primi rapoarte privind starea procesului. Aceste rapoarte sunt furnizate
de către modulul generare rapoarte (MGR) care procesează date preluate din
BDP. De asemenea tot de la COP operatorul poate actualiza diverse date din BDP
(prin intermediul MABDP) și poate transmite comenzi manuale (de tipul
închis/deschis) către elemente de execuție specifice (EEN) prin intermediul
SDCN.
4
Aceste componente sunt impuse de faptul că lumea reală, la care sunt conectate EPP este o
lume a analogicului (de exemplu temperatura unui produs care se încălzește într-un cuptor are
variație continuă).
24
Ce presupune sincronizarea modulelor MPDA, MEC și MPCE în
cadrul unui sistem de de conducere în timp real?
• 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 la diverse manifestări, servicii în
cadrul bibliotecilor etc.
Pentru exemplificare în figura 1.11, se prezintă structura unui sistem
tranzacţional, unde tranzacţiile pot fi introduse de la mai multe terminale.
T1 MAT1
MASU
T2
MGT MMT MATk SGBD
Tn MATn BDST
Fig. 1.11. Structura unui posibil sistem tranzacțional în timp real:

BDST- baza de date a sistemului tranzacţional ; SGBD – sistem de gestiune a bazei de
date; T1…Tn – terminale introducere solicitări tranzacții; MGT – modul gestiune
terminale; MMT- modul monitorizare tranzacţii; MASU – modul analiză solicitări
utilizatori; MAT1…MATn – module aplicație tranzacţii.
După cum se observă din figura 1.11 sistemul tranzacţional implică

prezența 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.
25
2-1.2.2 Trăsături ale sistemelor de operare în timp real
La realizarea şi execuţia unei aplicaţii, inclusiv a uneia de timp real,

sunt implicate trei categorii de resurse software (sisteme de programe) şi anume:
- resurse (programe) de sistem;
- resurse (programe) aplicative;
- resurse (programe) utilitare.
• Programele de sistem cunoscute ca resurse software de bază
asigură următoarele funcţii importante:
- servicii comune pentru programele aplicative;
- planificarea ş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;
- gestionarea și tratarea întreruperilor.
După cum se va arăta, într-un sistem de timp real aplicaţiile specifice
(care s-au impus sub denumirea de taskuri) sunt într-o permanentă competiţie
pentru deţinerea resurselor sistemului. În acest context, componente software de
bază trebuie să asigure alocarea pe baza unor criterii prestabilite a resurselor
importante ale echipamentului numeric respectiv: timpul unităţii centrale de
prelucrare, spaţiile de memorie și disponibilitățile de intrare-ieşire.
În ceea ce priveşte gestionarea și 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 hardware
al prelucrării în timp real.
• Programele aplicative realizează prelucrările dorite de utilizator.
În contextul prelucrării în timp real unitatea funcţională elementară de program,
independentă din punct de vedere logic se numeşte task. Aceste programe
aplicative (taskurile) trebuie să se încadreze în clasa aplicaţiilor de timp real (din
care în prima parte a prezentei unități de învățare au fost prezentate cele de
conducere în timp real și tranzacţionale în timp real).
• Programele utilitare sunt cele care asistă programatorul la
dezvoltarea şi implementarea programelor aplicative. În această categorie o
importanță aparte prezintă mediile de dezvoltare, diagnosticare şi depanare.
26
Cea mai importantă componentă a resurselor software de bază este

reprezentată de sistemul de operare (SO), care în mod obişnuit are două funcţii
importante şi anume:
- gestionarea resurselor sistemului de calcul pe care rulează aplicațiile
(taskurile);
- realizarea unei interfeţe de dialog cu utilizatorul.
În contextul funcțiilor automatizării proceselor pot fi definite taskuri
pentru monitorizare, reglare, protecție (avertizare și blocare), optimizare. După
cum rezultă din figura 1.10, aplicațiile asociate reglării sunt sincronizate cu
timpul, executându-se cu o anumită periodicitate. Tot periodic se execută și
aplicațiile de monitorizare și optimizare. În ceea ce privește aplicațiile de
avertizare și blocare acestea trebuie executate când situația o impune, respectiv
atunci când anumiți parametri se află în afara limitelor prestabilite. În ceea ce
privește sistemele tranzacționale, aplicațiile de soluționare a tranzacțiilor sunt
declanșate din momentul în care acestea au fost solicitate de utilizatori.
Sintetizând, există taskuri care se execută la momente sau intervale de timp
prestabilite și taskuri care se execută ca urmare a producerii unor evenimente.
SO care asigură execuția, în condiții impuse, a aplicațiilor specifice
sistemelor de timp real sunt cunoscute ca Sisteme de Operare în Timp Real
(SOTR). Specificitatea SOTR rezultă din existența taskurilor care să fie executate
condiţionat de unul dintre factorii timp şi/sau evenimente externe. O altă trăsătură
specifică a SOTR rezultă din faptul că la un moment dat în memoria
echipamentului numeric se pot găsi mai multe taskuri aflate în diverse stadii sau
stări.
Principala componentă a unui SOTR este planificatorul5 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 timp6;
- planificarea pe condiţii de evenimente7.
Satisfacerea cerinţelor de prelucrare în timp real, în condițiile în care în
memoria echipamentului numeric sunt prezente mai multe taskuri, se impune o
prelucrare paralelă sau cel puţin pseudoparalelă a acestora. 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 acesteia un anumit interval de timp.
5
Engl. – scheduler.
6
Engl. – time driven.
7
Engl. – event driven.
27
Un SOTR capabil să asigure o execuţie paralelă sau cel puţin

pseudoparalelă a taskurilor se numeşte Sistem de Operare în Timp Real
Multitasking (SOTRM).
Pe parcursul execuţiei lor (respectiv atunci când dețin controlul UCP) ,
taskurile pot activa proceduri (subrutine sau funcții) care pot fi de trei categorii şi
anume: dedicate, comune, reentrante.
• Subrutinele dedicate pot fi activate de către un singur task.
• Subrutinele comune pot fi activate din mai multe taskuri, însă
succesiv. Cu alte cuvinte o subrutină poate apelată de un nou task, numai după
ce execuţia sa în precedentul task a fost încheiată.
• Subrutinele reentrante pot fi activate simultan din mai multe
taskuri, cu alte cuvinte se pot autoîntrerupe.
Ca și în cazul unui SO de tip general, atunci când se vorbeşte de funcţia
de gestiune a SOTR (respective SOTRM) se are în vedere gestionarea
următoarelor resurse :
- gestionarea alocării către taskuri a timpului UCP;
- gestionarea alocării către taskuri spaţiului de memorie internă;
- gestionarea operațiilor de intrare-ieșire executate de către
echipamentele periferice.
Gestionarea resurselor de mai sus de către un SOTRM se realizează în
condițiile în care taskurile se concurează pentru obținerea și deținerea acestora.
Exerciţiul 3
Enumerați serviciile comune asigurate de resursele software de bază.
• 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
planificator într-o coadă de aşteptare, care poate fi organizată funcţie de
priorităţi8, sau în ordinea sosirii.
În mod curent SOTRM poate să preia controlul UCP în următoarele
situaţii:
- apariţia unui eveniment extern (de exemplu întreruperi din partea
procesului sau a operatorului);
8
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 UI 8-3.2).
28
- 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 mare din
coada de aşteptare.
În cazul în care mai multe taskuri pot avea aceeaşi prioritate, alocarea
UCP se poate realiza potrivit uneia dintre următoarele strategii:
- primul intrat primul ieşit9 , conform căreia taskurile cu prioritate egală
intră în execuţie în ordinea sosirii;
- timp divizat10, 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. Pentru a putea fi executat, un task
trebuie să beneficieze de spații de memorie pentru cod, date și stivă. 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 un 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 să nu fie rezidente în memoria internă.
Avantajul acestei strategii constă în faptul că taskul aflat în execuţie are
la dispoziţie pe durata execuției întregul spaţiu al memoriei interne. Preţul plătit
pentru acest avantaj este reprezentat de timpul consumat cu transferurile, astfel
încât timpul consumat cu tranziţiile între stări creşte.
9
FIFO – First Input First Output
10
Engl – time sharing
29
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 mici.
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 implică 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
multiprogramare11.
• 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 în execuția
taskurilor, 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ă
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.
Comentați execuția paralelă și pseudoparalelă în condițiile existenței
mai multor SRA monovariabile organizate într-un sistem de conducere
în timp real, de tipul celui ilustrat în figura 1.10.
11
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).
30
2-1.2.3 Obiectivele și principiile ingineriei programării aplicațiilor de

timp real
În general activitatea de inginerie12 presupune aplicarea rezultatelor
cunoașterii in vederea proiectării, executării, întreținerii și modificării unor
structuri capabile să furnizeze rezultate, produse, procese conforme cu așteptări
predictibile și controlabile. Rigoarea științifică, alături de principiile logice și
consistente reprezintă fundamente ale ingineriei. Pe lângă rigoare abordarea în
stil ingineresc a soluționării diferitelor categorii de probleme, induce ordine,
siguranță și eficiență.
În contextul acestui curs prezintă interes dezvoltarea în stil ingineresc a
aplicațiilor software, în speță aplicațiile aferente sistemelor de conducere în timp
real.
Ingineria Programării în Timp Real (IPTR) încadrează o mulţime de
concepte, principii, metode şi instrumente de dezvoltare și întreținere 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. IPTR este o
diviziune a ingineriei programelor (ingineriei software) care implică proiectarea,
crearea și întreținerea programelor (resurselor software) prin aplicarea de
tehnologii și practici din domenii cum ar fi: știința și ingineria calculatoarelor,
informatică, managementul proiectelor.
Principala problemă pe care trebuie să rezolve 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 conexe şi anume:
- stabilirea etapelor şi în cadrul acestora a fazelor prin care trece un
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 probleme, IPTR îşi propune următoarele
categorii de obiective pentru produsele informatice dezvoltate :
- obiective de adaptabilitate;
- obiective de fiabilitate;
- obiective de perceptibilitate.
12
În limba latină ingeniare – a născoci.
31
• Adaptabilitatea presupune dezvoltarea de facilităţi pentru un

produs informatic, astfel încât să fie posibilă efectuarea de modificări într-o
manieră strict controlată. Între cauzele care pot impune modificări sunt de
menționat:
- 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ă în primul rând de caracterul evolutiv al procesului, evoluţie care poate
marca modificări ale obiectivelor, a strategiei de conducere şi implicit a
resurselor software asociate.
• Eficienţa reprezintă un obiectiv impus de argumente care de regulă
au în vedere, printre altele, considerente legate de:
- minimizarea eforturilor pentru dezvoltarea programelor, în corelație
directă cu productivitatea personalului implicat;
- maximizarea gradului de utilizare a echipamentelor pe care rulează
resursele software dezvoltate.
• Fiabilitatea programelor se referă la dezvoltarea de aptitudini
pentru acestea de îndeplinire a sarcinilor trasate, un interval de timp prestabilit în
condiţii de lucru specificate. Este important de subliniat că în cadrul programării
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ţa 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 programe13.
• 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ă finalizare14.
Pentru realizarea acestor obiective trebuie respectate o serie de principii,
între care o importanţă aparte prezintă următoarele:
- principiul modularizării;
- principiul uniformităţii;
- principiul confirmabilităţii;
- principiul acoperirii.
13
O metodă recomandată constă în dezvoltarea de module redundante.
14
Această obiectiv mai este cunoscut şi sub denumirea de claritate.
32
• 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 de
adaptabilitate şi fiabilitate.
• Principiul uniformităţii presupune asigurarea consistenţei, un
exemplu în acest sens fiind stabilirea notaţiilor.
• 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 este legat de o etapizare a fazelor din
existenţa unei aplicații informatice. Experiența în domeniu a confirmat
următoarele faze:
- analiza cerinţelor pentru aplicație;
- elaborarea specificaţiilor pentru aplicație;
- proiectarea aplicației;
- codificarea în program a aplicației;
- instalarea şi testarea aplicației;
- întreţinerea aplicației.
• Analiza cerinţelor este o fază î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 care vor fi implicate în dezvoltarea aplicației.
• Proiectarea aplicației reprezintă o etapă în care se stabilesc:
- modulele funcţionale ale aplicației;
- relaţiile între module ș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;
- elemente utilizabile în programare (variabile, tabele, obiecte, structuri
ecrane de dialog etc.).
33
Start dezvoltare
aplicaţie
Da
Validare
Instalare,
Analiză testare
Nu
Da
Nu Da Nu
Validare Validare
Întreținere
Specificații Codificare
Nu
Validare
Nu Da
Validare Da
Da Contract
întreținere
Proiectare
Nu
Nu Da
Validare
Încheiere dezvoltare
aplicaţie
Fig. 1.12. Modelul iterativ asociat etapelor din existenţa

unui produs informatic.
• Codificarea presupune generarea programelor aferente aplicației,

cu utilizarea resurselor stabilite în faza de elaborarea specificațiilor, pentru
modulele definite în etapa de proiectare şi rularea lor pe un calculator gazdă.
• Instalarea şi testarea aplicației are în vedere transferul
programelor dezvoltate în faza de codificare 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 aplicației presupune eventuale corecţii impuse fie de
neconcordanţe în raport cu tema de proiectare, fie de reveniri ale beneficiarului.
34
Este de menționat faptul că în faza de întreținere, aplicația este corectată sau

adaptată la noi cerințe, motiv pentru care întreținerea este considerată ca fiind o
fază a dezvoltării acesteia.
Pentru abordarea dezvoltării de aplicații informatice conform etapelor
descrise mai sus s-au impus două modele și anume:
- modelul cascadă;
- modelul iterativ.
Modelul cascadă presupune parcurgerea fiecărei etape (mai puțin cea de
întreținere) cu singură verificare după faza de implementare.
Modelul iterativ presupune trecerea la faza următoare numai după
validarea celei precedente. După cum se observă din figura 1.12, în care este
ilustrat acest model sub forma unei scheme logice, etapa de întreţinere conţine o
a doua validare care se referă la existența sau nu a unui contract de întreținere
pentru aplicație
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.
35
1. Când prezintă un sistem de conducere comportare în timp real?
2. Ce este un task?
3. Care sunt nivelurile de planificare a taskurilor de către un SOTR?
4. Ce este un sistem de operare în timp real multitasking?
5. Care sunt obiectivele ingineriei programării în timp real?
6. Denumiți fazele din dezvoltarea unei aplicații informatice.
7. Denumiți categoriile de personal implicat în dezvoltarea aplicațiilor
informatice.
Rezumat
Un sistem de conducere prezintă comportare în timp real dacă reacțiile
sale la schimbările din proces sunt în conformitate cu inerția procesului.
Având în vedere corelarea cu inerția, o denumire alternativă pentru sintagma
timp real este cea de timp util.
Un sistem de operare în timp real (SOTR) asigură planificarea pentru
execuție a taskurilor condiționată de timp sau de evenimente externe. Un
SOTR capabil să asigure o procesare paralelă sau psudoparalelă a taskurilor se
numește sistem de operare în timp real multitasking.
Ingineria programării în timp real (IPTR) încadrează concepte,
principii, metode şi instrumente de dezvoltare și întreținere a programelor
destinate aplicaţiilor de timp real.
Obiectivele IPTR sunt legate de modularitatea, eficiența, fiabilitatea și
perceptibilitatea produselor informatice dezvoltate.
Fazele din dezvoltarea unui produs informatic sunt: analiză, elaborare
specificații, proiectare, codificare în program (programare), instalare și
testare (implementare), întreținere.
Pentru dezvoltarea aplicațiilor (conform fazelor de mai sus) poate fi
utilizat modelul cascadă sau modelul iterativ.
36
1. Enunț
Justificați din perspectiva dinamicii unui proces sintagma comportare
în timp util sau timp specific, în calitate de alternativă la cea de
comportare în timp real.
Rezolvare
Dinamica unui proces este cuantificată în viteza de răspuns, sau în
timpul de răspuns al acestuia la modificarea intrării sau intrărilor.
Funcție de de acest timp se estimează frecvența (respectiv intervalul)
de eșantionare pentru păstrarea consistenței informaționale. De
exemplu un proces de transport prin conducte a unui lichid are o inerție
redusă (răspunde mai repede) în raport cu un proces de amulare a unui
lichid într-un vas. În aceste condiții frecvența de eșantionare a
semnalului de la un traductor de debit va fi mai mare decât frecvența
de eșantionare a semnalului de la un traductor de nivel.
Dependența intervalului între eșantionări față de timpul de răspuns
justifică denumirea de timp util (specific).
2. Enunț
Ce presupune sincronizarea modulelor MPDA, MEC și MPCE în
cadrul unui sistem de conducere în timp real?
Rezolvare
Sincronizarea este realizată cu timpul în sensul că modulele MPDA,
MEC și MPCE se activează la intervale de timp prestabilite.
3. Enunț
Comentați execuția paralelă și pseudoparalelă în condițiile existenței
mai multor SRA monovariabile organizate într-un sistem de conducere
în timp real, de tipul celui ilustrat în figura 1.10.
Rezolvare
Execuție paralelă
a- se achiziționează simultan în cadrul unei cuante de timp, prin
SADA, semnalele de la toate traductoarele;
b- se activează simultan în cadrul unei cuante de timp toate
modulele MPDA (conversie în unități inginerești);
c- se determină simultan în cadrul unei cuante de timp toate
comenzile (în unități inginerești);
37

d- se activează simultan în cadrul unei cuante de timp toate
modulele MPCE (conversie din unități inginerești);
e- se transferă simultan în cadrul unei cuante de timp prin SDCA la
elementele de execuție semnalele corespunzătoare comenzilor.
Execuție pseudoparalelă
a - se achiziționează pe rând în cadrul câte unei cuante de timp, prin
SADA, semnalele de la toate traductoarele;
b - se activează pe rând în cadrul câte unei cuante de timp toate
modulele MPDA (conversie în unități inginerești);
c - se determină în cadrul a câte unei cuante de timp, pe rând,
comenzile (în unități inginerești);
d - se activează pe rând în cadrul câte unei cuante de timp toate
modulele MPCE (conversie din unități inginerești);
e - se transferă pe rând, în cadrul câte unei cuante de timp prin
SDCA la elementele de execuție semnalele corespunzătoare pentru
toate comenzile.
Observație
Pentru N sisteme de reglare automată în execuție paralelă sunt
necesare 5 cuante de timp, iar în execuție pseudoparalelă sunt necesare
5xN cuante de timp.
Bibliografie
1. Bărbat B., Filip Gh. F., Informatica industrială. Ingineria programării în
timp real, Bucureşti, Editura Tehnică, 1997.
2. Davidoviciu A., Bărbat B., Limbaje de programare în timp real, Bucureşti,
Editura Tehnică, 1986.
3. Paraschiv N., Achiziția și prelucrarea datelor, Editura Universității Petrol-
Gaze din Ploiești, 2013.
4. Paraschiv N., Programarea aplicațiilor de timp real, Editura Universității
Petrol-Gaze din Ploiești, 2014.
5. https://ro.wikipedia.org/wiki/Inginerie#cite_note-1
6. https://ro.wikipedia.org/wiki/Inginerie_software
38
MODULUL DE STUDIU 2
MECANISMELE PROGRAMĂRII CONCURENTE A
APLICAȚIILOR DE TIMP REAL
Stările și tranzițiile taskurilor
3-2.1.1 Stările taskurilor
3-2.1.2 Tranzițiile taskurilor
- când două taskuri sunt paralele;
- diferența dintre taskurile interactive și cele disjuncte;
- care sunt mecanismele implementate de un SOTRM în calitate de suport
pentru execuția intercalată a taskurilor;
- structura stratificată a unei aplicații de timp real.
- caracterizezi lucrul în întreruperi asociat execuției intercalate a taskurilor;
- caracterizezi stările și substările unui task;
- caracterizezi tranzițiile între stări și substări împreună cu directivele
aferente;
- să construiești graful tranzițiilor între stări și substări.
3-2.1.1 Stările taskurilor

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 mod uzual, aplicaţiile de timp real se dezvoltă apelând la programarea
paralelă sau concurentă. Două taskuri se numesc paralele sau concurente15 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). După cum s-a arătat, în cazul sistemelor cu o singură UCP
execuţia este pseudoparalelă, timpul acesteia fiind partajat între mai multe
taskuri.
15
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.
39
Execuţia intercalată a taskurilor presupune lucrul în întreruperi, taskurile

executându-se intercalat cu rutina de tratare a întreruperilor, aspect evidenţiat în
figura 2.1.
Operaţii
a
….. ….. A C
A A A B
t
Cereri de
întrerupere
b
Execuţie task
Cerere întrerupere
Execuţie rutină
tratare întrerupere
Reluare execuţie task
Fig. 2.1. Execuţia intercalată a taskurilor.
În exemplul din figura 2.1a se consideră următoarea semnificaţie a

taskurilor:
- A – task de achiziţie date prin Subsistemul de Achiziție a Datelor
Analogice (SADA), iniţiat de un semnal de întrerupere (eveniment
extern) de la Convertorul Analog Numeric (CAN) din structura
SADA, la încheierea conversiei;
- B – task de calcul comenzi (se executa la anumite intervale de
timp);
- C – task de avertizare (se execută ca urmare a unui eveniment
extern determinat de neîncadrarea între limite a mărimii
achiziţionate din proces).
În figura 2.1b este reprezentată execuţia rutinei de tratare a unei
întreruperi. Se remarcă faptul că execuţia acestei rutine presupune întreruperea şi
apoi reluarea execuției unui task.
Exerciţiul 1
Când este posibilă procesarea pur paralelă a taskurilor?
40
În afara activării sistemului de întreruperi, execuţia intercalată a

taskurilor mai presupune existenţa în cadrul sistemului de operare a
mecanismelor pentru:
- salvarea şi restaurarea contextului 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);
Cele cinci mecanisme sunt implementate în nucleul SOTRM (executiv),
care se află în vecinătatea imediată secţiunii hardware şi care se consideră că face
parte din aplicaţia de timp real. După cum se observă din figura 2.2, o asemenea
aplicaţie mai conţine taskuri sistem şi taskuri utilizator.
Taskuri utilizator
Taskuri sistem
Nucleu SOTRM
Hardware
Fig. 2.2. Structura stratificată a unei aplicaţii de timp real.
În mod obişnuit un task are asociate în memoria internă trei secţiuni

după cum urmează:
- secţiunea de date care conţine operanzi şi rezultate ;
- secţiunea de cod care conţine codul ce 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.
41
În structura unei aplicaţii de timp real sunt incluse în mod obişnuit

taskuri interactive şi taskuri disjuncte.
• Taskurile interactive sunt acele taskuri care pe parcursul evoluţiei
lor utilizează resurse în comun şi fac schimb de date.
• Taskurile disjuncte sunt taskuri care nu interacţionează, respectiv
care nu utilizează resurse în comun şi nu fac schimb de date.
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 efectuare a tranziţiei î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 va fi
prezentată o variantă de abordare referitoare la stările şi tranziţiile taskurilor.
Conform acestei abordări, 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.
• Un task neinstalat este un task rezident în memoria internă sau externă,
necunoscut de către executivul de timp real.
• Un task inactiv este un task instalat, pentru care fie nu s-a făcut un apel
pentru execuție, fie şi-a încheiat execuția (prin stop natural sau forţat).
• Un task activ este un task executabil, 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 acestor taskuri se înscriu
într-o coadă, tranziția în substarea execuţie putându-se efectua în
două moduri:
42
- ciclic (ROUND – ROBIN) - mod în care taskurile sunt

executate succesiv în interiorul unei cuante de timp sau până la
terminarea normală;
- după priorităţi – mod în care controlul UCP este preluat de
către 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șire.
Exerciţiul 2
Când se găsește un task în substarea blocat?
3-2.1.2 Tranzițiile taskurilor

Tranziţiile între stări şi substări pot fi realizate în două moduri şi anume:
- prin întreruperi hardware sau software, contextul comutării fiind
determinat de nivelul întreruperii;
- prin apeluri lansate către Executiv din taskul aflat în substarea
Execuţie. Acestea sunt apeluri de subrutine neîntreruptibile numite
Primitive sau Directive, contextul comutării fiind determinat de
numele şi parametrii directivei.
Referitor la directive (primitive) , pentru încadrarea acestora, sunt
identificate două categorii şi anume:
- directive (primitive) care nu declară un eveniment semnificativ și
după a căror execuţie controlul UCP este returnat taskului întrerupt;
- directive care declară un eveniment semnificativ , în urma cărora
controlul UCP este acordat taskului aflat pe prima poziţie în coada taskurilor
aflate în substarea Gata De Execuţie, sau se face un apel de execuție către un
task aflat în starea Inactiv .
Comentați ce presupune preluarea controlului UCP de către taskul C
de avertizare potrivit reprezentării din figura 2.1.
43
Aşteptare ACTIV
Aşteptare Preluare
GATA DE EXECUŢIE
BLOCAT
EXECUŢIE
Continuare Eliberare
Stop forţat din alt task Start Stop forţat din alt task
Stop normal
INACTIV
Instalare Ştergere
NEINSTALAT
Fig. 2.3. Evoluţia taskurilor în spaţiul stărilor şi substărilor.
În cele ce urmează se prezintă tranziţiile între stările și substările

evidențiate mai sus și ilustrate în graful din figura 2.3, împreună cu directivele
(primitivele) asociate.
• Tranziţia Neinstalat – Inactiv se realizează prin directiva
Instalare care face cunoscut executivului taskul implicat, realizând în acelaşi
timp crearea şi alocarea Blocului Descriptor al Taskului (BDT) care poate
conţine următoarele elemente:
- parametri 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 execuție pentru respectivul task.
44
• 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 taskurilor Gata De Execuţie care 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ă.
• 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 normal), 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.
Comentați când, unde și prin ce directive se realizează tranziția unui
task din substarea Execuție a stării Activ.
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.
În modulul de studiu 3, unitățile de învățare 8, 9 și 10 (UI 8-3.2, UI 9-
3.3, UI 10-3.4 ) vor fi caracterizate stările și tranzițiile taskurilor aferente
nucleului de timp real RTK.
45
1. Când două taskuri sunt interactive?
2. Care sunt secțiunile unui task?
3. Care sunt substările stării Activ asociate unui task?
4. Ce directivă determină crearea blocului descriptor al taskului?
5. Din ce stare/substare este posibilă tranziția unui task în substarea
Execuție?
6. În ce situație se realizează tranziția Gata de execuție – Blocat?
7. Ce conține graful ilustrat în figura 2.3 în calitate de noduri și arce?
Rezumat
Pentru dezvoltarea aplicațiilor de timp real se apelează la programarea
paralelă.
Dacă există o singură UCP execuția este pseudoparalelă (intercalată).
Execuția intercalată a taskurilor are ca suport sistemul de întreruperi și
necesită deținerea de către SOTRM a capabilităților pentru taskuri de: activare
și dezactivare, salvare și restaurare a contextului, excludere mutuală,
sincronizare, comunicare.
Evoluția unui sistem de taskuri interactive (respectiv cele care
comunică și utilizează resurse în comun) este influențată de modurile în care
sunt planificate pentru execuție și în care se efectuează tranzițiile.
Unui task i se asociază în memoria internă secțiuni de cod , date și
stivă.
În abordarea prezentată un task se poate găsi într-una din stările
neinstalat, inactiv, activ. Stării activ, îi sunt specifice substările execuție, gata
de execuție, blocat.
Tranzițiile între stări și substări se realizează prin construcții
imperative neîntreruptibile numite directive sau primitive. Acestea pot fi
lansate de către taskul aflat în execuție sau de către SOTRM.
46
1. Enunț
Comentați ce presupune preluarea controlului UCP de către taskul C
de avertizare potrivit reprezentării din figura 2.1.
Rezolvare
Taskul de avertizare este în mod normal în starea Inactiv. Cererea de
întrerupere apare ca urmare a unui eveniment semnificativ, reprezentat
de încălcarea limitei de către un parametru. Prin directiva Start taskul
tranzitează în substarea Gata de Execuție și de aici prin directiva
Preluare în substarea Execuție. Taskul care deținea controlul UCP la
momentul apariției evenimentului semnificativ este trecut prin
directiva Eliberare în substarea Gata de Execuție.
2. Enunț
Comentați când, unde și prin ce directive se realizează tranziția unui
task din substarea Execuție a stării Activ.
Rezolvare
Comentariul se va baza pe graful tranzițiilor ilustrat în figura 2.3.
Din substarea Execuție sunt posibile tranzițiile în:
- starea Inactiv, prin directiva Stop normal, la o terminare normală a
taskului (de exemplu taskul de avertizare din testul de autoevaluare 1);
- substarea Gata de Execuție, prin directiva Eliberare, la declararea
unui eveniment semnificativ, cum ar de exemplu expirarea cuantei de
timp alocate;
- substarea Blocat, prin directiva Așteptare, în situația în care
continuarea execuției este condiționată (un exemplu de condiție este
cea legată de trecerea unui interval de timp).
Bibliografie
2. Paraschiv N., Achiziția și prelucrarea datelor, Editura Universității Petrol-Gaze
din Ploiești, 2013.
4. Robu N., Programare concurentă. Mecanisme suport orientate timp real,
Timişoara, Editura Politehnica, 2007.
47
MODULUL DE STUDIU 2
APLICAȚIILOR DE TIMP real
Conflicte potențiale în sistemele multitasking
4-2.2.1 Resurse și secțiuni critice
4-2.2.2 Excluderea mutuală realizată cu semafoare
4-2.2.3 Excluderea mutuală realizată cu variabile de tip eveniment
4-2.2.4 Excluderea mutuală realizată cu mesaje și cutii poștale
4-2.2.5 Alte modalități de realizare a excluderii mutuale
- diferența dintre resursele locale și cele comune;
- necesitatea excluderii mutuale (EM) pentru utilizarea resurselor critice fără a
genera situații conflictuale;
- cerințele care trebuie respectate la implementarea excluderii mutuale;
- utilizarea diverselor instrumente pentru implementarea excluderii mutuale.
- identifici resursele critice;
- caracterizezi utilizarea semafoarelor și variabilelor de tip eveniment pentru
implementarea excluderii mutuale;
- caracterizezi utilizarea cutiilor poștale și mesajelor pentru implementarea
excluderii mutuale;
- aplici excluderea mutuală în aplicațiile multitasking de conducere în timp
real.
4-2.2.1 Resurse și secțiuni critice

După cum s-a arătat, în cadrul unei aplicații de timp real taskurile
concură pentru deţinerea de resurse. În vederea evitării posibilelor conflicte şi
pentru ca taskurile să-şi poată realiza obiectivele impuse au fost formalizate aşa
numitele operaţii multitasking între care o importanţă aparte prezintă: excluderea
mutuală, sincronizarea şi comunicarea 16 .
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.
16
În mod obişnuit acestea sunt cunoscute ca Operaţii Fundamentale Multitasking.
49
În cadrul acestui modul de studiu, unitățile de învățare 4, 5 și 6 (UI 4-2.2,

UI 5-2.3, UI 6-2.3) vor aborda aspecte referitoare la operațiile multitasking în
cadrul cărora resursele dețin un rol esențial.
În general termenul de resursă desemnează orice element necesar unui
task pentru a putea fi executat.
 O primă clasificare divizează resursele în resurse materiale
(hardware) şi logice (software).
• În rândul resurselor materiale pot fi considerate:
- procesorul;
- memoria internă;
- memoriile externe;
- dispozitivele de intrare / ieşire;
- ceasul de timp real;
- dispozitivele speciale.
• Resursele logice pot conține:
- rutine (proceduri);
- variabile;
- fişiere;
- baze de date.
 O altă clasificare împarte resursele în: resurse locale şi resurse

comune.
• Resursele locale sunt resursele destinate a fi accesate de către
un singur task. Acestea pot fi în primul rând de natură logică (rutine, 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ă (rutine, blocuri 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, echipamentele de
intrare, subrutinele care îşi modifică pe parcurs unele date proprii etc.
50
 O resursă comună care admite ca n sesiuni de lucru să fie în

derulare asupra sa 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 ca oricâte sesiuni de lucru să fie
în derulare la un moment dat se numeşte resursă reentrantă17.
Exerciţiul 1
Care este diferența dintre o resursă locală și una comună?
Î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 stricte pentru accesarea secţiunilor critice. O asemenea
reglementare este reprezentată de excluderea mutuală (reciprocă).
Excluderea mutuală (reciprocă) reprezintă operaţia fundamentală
multitasking prin care este autorizat la un moment dat accesul unui singur task
în propria secţiune critică referitoare la o resursă. Din această definiţie rezultă
că dacă la un moment dat un task se găseşte într-o secţiune proprie în care este
accesată o resursă critică, trebuie exclus (blocat) accesul oricărui alt task într-o
secţiune critică proprie în care este accesată aceiaşi resursă.
Referitor la implementarea excluderii mutuale sunt de menţionat
recomandările făcute în anul 1987 de către Andrew Tanenbaum, fost profesor la
Universitatea Vrije din Amsterdam – Olanda.
Sintetic aceste recomandări au în vedere următoarele aspecte:
1 – orice secţiune critică referitoare la o anumită resursă 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 anumită 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ţele sau vitezele
de execuţie ale taskurilor);
3 – orice task are dreptul să acceseze propria secţiune critică referitoare
la o anumită resursă după un interval finit de timp;
4 – orice task trebuie să evacueze o secţiune critică proprie referitoare la
o anumită după un interval finit de timp;
5 – taskurile nu se pot bloca în interiorul propriilor secţiuni critice.
17
Resursele reentrante pot fi considerate resurse partajabile cu n tinzând către infinit.
51
Exerciţiul 2
Care este condiția ca un task să își execute o secțiune critică referitoare
la o anumită resursă?
În continuare vor fi prezentate câteva modalităţi de implementare a

excluderii mutuale.
4-2.2.2 Excluderea mutuală realizată cu semafoare

Conceptul de semafor a fost introdus în anul 1965 de către
matematicianul olandez Edsger Wybe Dijkstra. Potrivit definiției date de
Dijkstra, un semafor reprezintă un dublet format dintr-o variabilă de tip întreg I
şi o coadă de aşteptare C , respectiv
S = ( I , C ). (2.1)
La iniţializare, coada C (în care sunt înscrise elemente de identificare ale
taskurilor care așteaptă la semaforul S) este vidă, iar variabilei I i se atribuie o
valoare I 0 ≥ 0 . 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 generic de
către Dikstra, P (de la cuvântul olandez Passeren – a trece) şi V (de la cuvântul
olandez Vrigeven – a elibera). Aceste funcţii sunt indivizibile18 şi se numesc
primitive. În ceea ce priveşte coada de aşteptare , aceasta poate fi gestionată
conform principiului FIFO19, sau după priorităţi (univoce sau neunuivoce20).
Primitiva P(S) , este asociată decrementării variabilei I și presupune
realizarea următoarelor operaţii (ilustrate în organigrama din figura 2.4):
1 - I←I-1;
2 – dacă în urma decrementării de la pasul 1 rezultă I ≥ 0 , funcţia se
încheie şi taskul în care aceasta se execută îşi continuă execuţia;
3 – dacă rezultă I < 0, taskul în care se execută primitiva se blochează
iar un element de identificare al său este înscris în coada de aşteptare C. În
aceste împrejurări se provoacă un proces de comutare, realizat de dispecer, care
determină trecerea în execuţie a altui task.
Este important de subliniat faptul că operația P poate determina blocarea
unui task. Semnificația trecerii (Passeren) se referă la trecerea taskului în
substarea blocat (potrivit abordării din unitatea de învățare 3 - UI 3-2.1).
18
Indivizibilitatea are în vedere faptul că cele două funcţii nu pot fi întrerupte.
19
First Input First Output
20
univoce – câte o prioritate pentru fiecare task, neunivoce – o prioritate pentru mai multe taskuri.
52
I←I-1
DA NU
I≥0
Continuă execuţia Se blochează taskul apelant şi se

taskului apelant înregistrează în coada C
Se apelează dispecerul
Se aduce în execuţie alt task
Fig. 2.4. Execuţia primitivei P(S).
Interpretați, pe baza schemei logice din figura 2.4 operația P pentru un
semafor S binar.
Primitiva V(S) care este asociată incrementării variabilei I, presupune

realizarea următoarelor operaţii (ilustrate în organigrama din figura 2.5):
1 - I←I+1;
2 – dacă în urma operaţiei de incrementare de la punctul 1 rezultă I≤0, se
deblochează taskul aflat pe prima poziţie în coada de aşteptare C la semafor şi
se înscrie în rândul taskurilor gata de execuţie, după care se face apel la dispecer
şi se continuă execuţia taskului apelant ;
3 – dacă în urma operaţiei de incrementare de la pasul 1 rezultă I > 0,
taskul în care se execută primitiva (apelant) îşi continuă execuţia.
În timpul execuţiei primitivei V(S), dacă în urma operației de
incrementare 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 deblocat.
53
I←I+1
NU DA
I ≤0
Se deblochează taskul aflat pe prima

poziţie în coada C, şi se înscrie între
taskurile gata de execuție
Continuă execuţia Se apelează dispecerul

taskului apelant
Fig. 2.5. Execuţia primitivei V(S).
Este semnificativ faptul că operația V nu poate determina blocarea unui

task. Semnificația eliberării (Vrigeven) se referă la eliberarea taskului din
substarea blocat (potrivit abordării din unitatea de învățare 3 - UI 3-2.1).
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);
- dacă I ≤ 0 , atunci |I| reprezintă numărul de taskuri blocate la
semaforul S şi înregistrate în coada C.
În abordările care urmează, prin operațiile P(S) și V(S) se vor avea în
vedere operațiile de decrementare respectiv incrementare a variabilei I , potrivit
semnificației din relația (2.1).
Interpretați, pe baza schemei logice din figura 2.5, operația V pentru
un semafor S binar.
54
Semafoarele reprezintă un suport adecvat pentru implementarea

excluderii mutuale între două sau mai multe taskuri. Adecvanța este motivată de
faptul că un task poate fi blocat pe o operație de tip P care se execută asupra sa.
În figura 2.6 este ilustrată excluderea mutuală realizată cu semafoare
pentru două taskuri T1 și T2.. Cele două taskuri sunt sincronizate cu timpul,
intervalele prestabilite de execuţie fiind Δt_ex_T1 pentru taskul T1 și Δt_ex_T2
pentru taskul T2. Cele două taskuri conțin secțiunile critice SCr_T1 și SCr_T2 ,
secțiuni în care este accesată aceiași resursă critică, impunându-se prin urmare
excluderea mutuală.
Pentru excluderea mutuală este utilizat semaforul binar SEMEX,
iniţializat cu valoarea 1 în fiecare dintre cele două taskuri. Implementarea
excluderii mutuale presupune, în fiecare task, execuția unei directive P(SEMEX)
înaintea intrării în secțiunea critică și unei directive V(SEMEX) , după ieşirea din
această secțiune.
TASK T1 TASK T2
..SEMEX=1.. ..SEMEX=1..
NU NU
DA DA
P1_T1 P1_T2
P(SEMEX P(SEMEX
SEMEX=0 SCr_T1 SEMEX=0 SCr_T2
V(SEMEX) V(SEMEX)
P2_T1 P2_T1
Fig. 2.6. Excluderea mutuală realizată cu semafoare:

P1_T1, P2_T1 – proceduri ale taskukui T1,
P1_T2, P2_T2 - proceduri ale taskului T2.
55
Din cele expuse rezultă că în intervalul de timp în care unul dintre cele
două taskuri se află în propria secţiune critică referitoare la o anumită resursă
SEMEX=0, aspect evidenţiat şi în figura 2.6. În aceste condiţii dacă celălalt
task este în situația de a executa propria secţiune critică referitoare la aceiaşi
resursă, va aplica directiva P(SEMEX), ceea ce va determina blocarea sa întrucât
după decrementare va rezulta SEMEX = -1.
După 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 SEMEX , va fi deblocat21 şi va putea
pătrunde la rândul său în propria secţiune critică.
Având în vedere că SEMEX este iniţializat cu valoarea 1, dacă de
exemplu, după iniţializare, pentru taskul T1se impune accesul în secţiunea sa
critică, acest lucru va fi posibil întrucât directiva P(SEMEX) nu va bloca acest
task. 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 trece în starea gata de execuţie urmând a fi
planificat pentru execuţia secţiunii sale critice.
Indiferent de numărul taskurilor care trebuie să se excludă mutual se
utilizează un singur semafor binar iniţializat în fiecare task cu valoarea 1 (unu).
Interpretați, pe baza schemei logice din figura 2.6, în ce situație un al
treilea task T3 își va putea accesa secțiunea critică referitoare la o
resursă utilizată în comun cu taskurile T1 și T2.
4-2.2.3 Excluderea mutuală realizată cu variabile de tip eveniment

O variabilă de tip eveniment (VTE) este o variabilă logică de tip special
asupra căreia pot acţiona trei tipuri de primitive şi anume ÎNSCRIE, ŞTERGE şi
AŞTEAPTĂ.
Fiind variabilă logică, o VTE va lua două valori notate generic
ADEVĂRAT (abreviat ADEV) și FALS 22 .
21
Pentru ca soluţia să fie funcţională, semaforul SEMEX nu trebuie aservit altor scopuri în afara
excluderii mutuale.
22
Alternative pot fi VTE=ADEV →VTE=1 și VTE=FALS →VTE=0.
56
Considerând E o variabilă de tip eveniment cu

E ∈{ADEV , FALS }, (2.2)
semnificaţiile celor trei primitive evidențiate mai sus sunt următoarele:
INSCRIE ( E ) ⇒ E = ADEV ; (2.3)
STERGE( E )  E = FALS ; (2.4)
ASTEAPTA( E ) ⇒ Blocheaza taskul daca E = FALS ,
(2.5)
Continua executia daca E = ADEV .
Este de menţionat faptul că cele trei primitive se pot aplica şi unei funcţii
de tip eveniment, respectiv unei funcții de o variabilă eveniment F(E) după cum
urmează
F ( E ) ∈ {ADEV , FALS }, (2.6)
INSCRIE [ F ( E )] ⇒ F ( E ) = ADEV , (2.7)
STERGE [ F ( E )] ⇒ F ( E ) = FALS , (2.8)
ASTEAPTA[ F ( E )] ⇒ Blocheaza taskul daca F(E) = FALS ,
(2.9)
Continua executia daca F(E) = ADEV .
Excluderea mutuală cu variabile de tip eveniment (VTE) se bazează pe
utilizarea unei singure astfel de variabile, notată generic EVEX şi care se
iniţializează cu valoarea ADEV. Î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ă acceseze 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 deblocat23 şi va putea
pătrunde la rândul său în propria secţiune critică.
Ca exemplu, în figura 2.7 se prezintă schemele logice aferente excluderii
mutuale cu VTE a două taskuri T1, T2. Se observă că cele două taskuri se execută
la intervale prestabilite Δt_ex_T1, Δt_ex_T2
23
Ca şi în cazul semafoarelor, variabila de tip eveniment EVEX va trebui utilizată numai la
implementarea excluderii mutuale.
57
Având în vedere că variabila EVEX este iniţializată cu valoarea ADEV,

dacă de exemplu pentru taskul T1 se impune accesul în secţiunea sa critică, acest
lucru va fi posibil întrucât directiva AŞTEAPTĂ (EVEX) nu va bloca acest task.
Dacă în timp ce T1 se află în secţiunea critică proprie, 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 variabila de
tip eveniment EVEX. Deblocarea se va produce atunci 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 şi prin urmare T2
va deveni executabil urmând a fi planificat pentru execuţia secţiunii sale critice.
TASK T1 TASK T2
…EVEX=ADEV… …EVEX=ADEV…
NU NU
DA DA
P1_T1 P1_T2
NU NU
? ?
EVEX=ADEV EVEX=ADEV
ASTEAPTA (EVEX) DA ASTEAPTA (EVEX) DA
ŞTERGE(EVEX) ŞTERGE(EVEX)
EVEX=FALS SCr_T1 EVEX=FALS SCr_T2
ÎNSCRIE(EVEX) ÎNSCRIE(EVEX)
P2_T1 P2_T2
Fig. 2.7. Excluderea mutuală cu variabile de tip eveniment:

58
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ă. După cum reiese din figura
2.7, pe durata execuţiei unei secţiuni critice, în oricare dintre taskuri
EVEX=FALS.
Exerciţiul 3
Ce valoare trebuie să aibă o VTE utilizată în excluderea mutuală
pentru ca un task să își poată executa secțiunea critică?
4-2.2.4 Excluderea mutuală realizată cu mesaje și cutii poștale

O cutie poştală (CP) reprezintă o structură de date de tip coadă (queue),
gestionată prin urmare conform principiului FIFO24. În mod normal o CP se
specifică prin numărul de mesaje care pot fi stocate şi prin lungimea admisă
pentru un mesaj. Taskurile pot depune mesaje în sau pot prelua mesaje din cutii
poștale. Un mesaj depus într-o CP de către un task este accesibil oricărui alt
task, iar un mesaj preluat dintr-o CP de către un task poate proveni de la oricare
alt task.
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) sau 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 (numită generic DEP) 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 preluare (numită generic PRE) a unui mesaj dintr-o anume CP
va trebui să conţină un pointer la variabila în care se depune mesajul preluat.
După cum este indicat în unitatea de învățare 10 (UI 10-3.4), în context RTK cele
două funcții sunt RTKPut, respectiv RTKGet. Din acest considerent în cele ce urmează
se va face uneori apel la echivalența DEP ~ PUT și PRE ~ GET.
Sistemele de operare în timp real trebuie să asigure o asemenea
gestionare a cutiilor poştale, încât să se producă blocarea taskurilor pe operaţii
de depunere , atunci când CP este plină sau pe operaţii de preluare atunci când
CP este vidă. Cu alte cuvinte la execuţia funcţiei DEP (PUT) taskul se blochează
dacă nu există spaţiu disponibil, iar la execuţia funcției PRE (GET) blocarea se
produce dacă nu există mesaj disponibil.
24
FIFO – First Input First Output (Primul Intrat Primul Ieșit).
59
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 prelua MESEX din CPEX, iar după ieşirea
din secţiunea critică îl va depune în CPEX.
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 va dori să acceseze propria secţiune critică referitoare la
aceiaşi resursă, se va bloca la execuţia funcţiei de preluare a mesajului simbolic.
Deblocarea25 se va produce în momentul în care CPEX va conţine din nou
mesajul simbolic MESEX.
În figura 2.8 se prezintă schemele logice aferente excluderii mutuale a
două taskuri T1şi T2, cu utilizarea cutiilor poștale . Ca şi în exemplele precedente
cele două taskuri sunt sincronizate cu timpul, intervalele de execuţie fiind
Δt_ex_T1, Δt_ex_T2.
Având în vedere că la iniţializare cutia poştală CPEX va conţine mesajul
simbolic MESEX, dacă de exemplu pentru taskul T1 se impune accesul în
secţiunea sa critică, acest lucru va fi posibil întrucât prin funcţia de extragere
PRE (GET) va putea fi preluat mesajul MESEX din CPEX. Dacă în timp ce
taskul T1 se află în secţiunea sa critică, taskul T2 va ajunge la iminenţa intrării în
secţiunea sa critică, acest deziderat nu se va putea realiza întrucât funcţia
execuția PRE (GET) va determina blocarea Taskului T2 la cutia poştală CPEX,
deoarece aceasta este vidă. Deblocarea se va produce atunci când taskul T1 va
termina de executat secţiunea sa critică. După execuția secțiunii critice SCr_T1,
în taskul T1 se a executa funcţia PUT de depunere a MESEX în CPEX. Ca urmare
a acestei depuneri taskul T2 va deveni executabil urmând a fi planificat pentru
execuţia secţiunii sale critice.
Din cele prezentate rezultă că pe durata execuției unei secțiuni critice
cutia poștală CPEX va fi vidă.
Concluzionând se poate spune că 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 în care este
accesată o anume resursă critică.
25
Utilizarea căsuţei poştală CPEX şi a mesajului MESEX trebuie să fie numai în excludere
mutuală. utilizată numai la implementarea excluderii mutuale.
60
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
CPEX
SCr_T1 SCr_T2
PUT PUT
DEPUNE MESEX în CPEX DEPUNE MESEX în CPEX
P2_T1 P2_T2
Fig. 2.8. Excluderea mutuală cu cutii poştale şi mesaje:

61
4-2.2.5 Alte modalități de realizare a excluderii mutuale
În afara instrumentelor prezentate, pentru implementarea excluderii

mutuale (EM) mai pot fi utilizate și altele cum ar fi:
- sistemul de întreruperi al calculatorului;

- fanioanele de excluziune;
- blocurile resursă;
- monitoarele.
A. Realizarea EM prin dezactivarea întreruperilor. Această metodă

presupune dezactivarea sistemului de întreruperi înainte de intrarea în secţiunea
critică şi reactivarea acestuia după ieşirea din respectiva secțiune. 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:
- TAS - Test And Set care presupune testarea față de 0 şi forţarea FE
valoarea la 1 la îndeplinirea condiției (respectiv dacă FE=0) ;
- RES – RESet care presupune forţarea FE la valoarea 0.
După cum tratarea unui fanion implică sau nu apelarea planificatorului
SOTR, fanioanele de excluziune pot fi active (FE_A) sau pasive (FE_P).
Implementarea EM, referitoare la o anumită resursă, cu ajutorul FE_P se
bazează pe următoarele reguli:
a – FE_P este asociat numai EM pentru resursa critică în cauză;
b – dacă FE_P = 0 rezultă că nici o secţiune critică referitoare la
respectiva resursă nu este în execuţie;
c – dacă FE_P = 1, rezultă că un task își execută propria secţiune critică
referitoare la resursa în cauză.
Înainte de pătrunderea în secţiunea critică se realizează în condiţii de
indivizibilitate operaţia TAS(FE_P), care presupune un test și o asignare:
– dacă operaţia TAS a găsit FE_P=1se reia testarea;
– dacă operaţia TAS a găsit FE_P=0 se face FE_P=1 după care se
intră în secţiunea critică;
62
După execuția secţiunii critice se va efectua operația RES(FE-P) care

va determina FE_P=0.
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, respectiv
I este o variabilă de tip întreg, iar C o coadă de așteptare;
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ă. Cu precizările de mai sus, un semafor care
asigură înregistrarea proprietarului curent al resursei critice, 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 la
excluderea mutuală, unei primitive P executată într-un task trebuie să îi
corespundă o primitivă V executată în acelaşi task.
D. Realizarea EM cu ajutorul monitoarelor. Conceptul de monitor a

fost introdus Richard Hoare în 1974 ca fiind un ansamblu de proceduri şi
variabile la care accesul este indivizibil. Referitor la excluderea mutuală, 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 acestuia.
În acest fel programatorul nu trebuie să fie preocupat de realizarea
excluderii mutuale, ci de asigurarea prezenţei la un moment dat în monitor a unui
singur task.
63
1. Care sunt operațiile fundamentale multitasking?
2. Ce este o resursă critică?
3. În ce constă excluderea mutuală (EM)?
4. Care sunt recomandările lui Tanenbaum pentru implementarea
EM?
5. Ce este un semafor?
6. Pe ce operație se poate realiza blocarea unui task la un semafor?
7. Ce valoare are un semafor utilizat în EM pe durata execuției unei
secțiuni critice?
8. Ce tip de mesaj se utilizează la implementarea EM cu ajutorul
cutiilor poștale?
9. Ce valoare are o variabilă de tip eveniment utilizată în EM pe
durata execuției unei secțiuni critice?
10. Indicați alte metode pentru implementarea EM?
Rezumat
Pe parcursul evoluției lor taskurile utilizează resurse, între care
importante sunt cele critice, care pot fi aceesate la un moment dat de către un
singur task. Secțiunea critică este secțiunea în care un task accesează o
resursă critică.
Excluderea mutuală (EM) este operația multitasking ce reglementează
accesarea neconflictuală a resurselor critice, în sensul că autorizează la un
moment dat execuția de către un singur task a propriei resurse critice în care
este utilizată o asemenea resursă.
EM realizată cu semafoare presupune utilizarea unui singur semafor
binar inițializat cu valoarea zero. Înainte de intrarea în secțiunea critică asupra
acestui semafor se execută operația P, iar după execuția secțiunii critice
operația V. Pe durata execuției secțiunii critice semaforul implicat are
valoarea zero.
EM realizată cu cutii poștale (CP) presupune utilizarea unui mesaj
simbolic și a unei singure CP. Primul task ce se inițializează depune mesajul
în CP. Înainte de intrarea în secțiunea critică asupra mesajul este preluat din
CP, iar după execuția secțiunii critice mesajul este depus în CP. Pe durata
execuției secțiunii critice cutia poștală este vidă (nu conține mesajul
simbolic).
Pentru implementarea EM mai pot fi implicate: variabile de tip
eveniment, fanioane, fanioane de excluziune, blocuri de tip resursă,
monitoare, dezacivarea întreruperilor.
64
1. Enunț
Interpretați, pe baza schemei logice din figura 2.4 operația P pentru un
semafor S binar.
Rezolvare
a) I=0 (I este variabila de tip întreg asociată taskului S);
I=I-1= -1 → I<0 → Se blocheză taskul apelant→ Se apelează
dispecerul → Se aduce în execuție alt task.
b) I=1 (I este variabila de tip întreg asociată taskului S);
I=I-1=0 → I=0 → Se continua execuția taskului apelant.
2. Enunț
Interpretați, pe baza schemei logice din figura 2.5 operația V pentru un
semafor S binar.
Rezolvare
a) I=-1 (I este variabila de tip întreg asociată taskului S);
I=I+1= 0 → I=0 → Se deblochează taskul aflat pe prima poziție în
coada de așteptare la semaforul S → Se apelează dispecerul → Se
continuă execuția taskului apelant.
b) I=0 (I este variabila de tip întreg asociată taskului S);
I=I+1=1 → I=1 → Se continua execuția taskului apelant.
3. Enunț
Rezolvare
Un al treilea task T3 își va putea accesa secțiunea critică numai dacă
SEMEX=1, respectiv dacă în acest task se va putea efectua operația
P(SEMEX).
65
4. Enunț
Rezolvare
Un al treilea task T3 își va putea accesa secțiunea critică numai dacă
CPEX conține MESEX, respectiv dacă în acest task se va putea prelua
MESEX din CPEX.
Bibliografie
timp real, Bucureşti, Editura Tehnică, 1997
3. Dijkstra E. W., Solution of a problem in concurent programming control. A

discipline of programming, Communication of the ACM , 8(9), 1965.
5. Paraschiv, N., Programarea aplicațiilor de timp real, Editura Universității
7. Tanenbaum S. A., Operating systems. Design and implentation, Prentice
Hall, New York, 1987.
66
MODULUL DE STUDIU 2
Sincronizarea taskurilor
5-2.3.1 Definirea sincronizării
5-2.3.2 Sincronizarea realizată cu semafoare
5-2.3.3 Sincronizarea realizată cu variabile de tip eveniment
5-2.3.4 Sincronizarea realizată cu mesaje și cutii poștale
5-2.3.5 Sincronizarea realizată cu monitoare și blocuri de întâlnire
- particularitatea sincronizării în cadrul operațiilor multitasking;
- necesitatea definirii punctelor de sincronizare în cazul sincronizării a două
taskuri;
- tratarea uniformă a sincronizării cu timpul și a celei cu un eveniment extern;
- utilizarea diverselor instrumente pentru implementarea sincronizării.
- caracterizezi sincronizarea între taskuri, cu timpul sau cu evenimente
externe;
- caracterizezi utilizarea semafoarelor și variabilelor de tip eveniment pentru
implementarea sincronizării;
sincronizării;
- aplici sincronizarea în aplicațiile multitasking de conducere în timp real.
5-2.3.1 Definirea sincronizării

Sincronizarea este operația multitasking prin care un task este pus în
relație cu un 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 execuției lor.
• Un task este sincronizat cu timpul, dacă pe parcursul execuției sale
există o condiționare temporală (prezentă sub forma unui moment sau a unui
interval).
• Un task este sincronizat cu un eveniment extern, dacă pe parcursul
execuției sale există o condiționare reprezentată de producerea respectivului
eveniment.
Exerciţiul 1
Definiți operația de sincronizare.
67
După cum s-a menționat în unitatea de învățare 3 (UI 3-2.1), un task ce

așteaptă realizarea unei condiții de timp sau producerea unui eveniment extern se
găsește în substarea blocat a stării active.
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ă, sensul
general al sincronizării fiind acela de coordonare în timp, de corelare.
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 să preia datele.
Exerciţiul 2
Când se impune sincronizarea unui task cu timpul, respectiv cu un
eveniment extern?
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.
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);
- momentul sincronizării (cu începutul, zona mediană sau sfârşitul unui
task):
- implementarea sincronizării (prin facilităţi ale limbajelor de
programare specializate, prin funcții ale executivelor de timp real
etc.).
Din punctul de vedere al sincronizării cu timpul pot exista două situaţii,
ilustrate în figura 2.9 şi anume:
- taskul aşteaptă expirarea unui interval de timp Δt după care se
execută (figura 2.9 a);
- taskul se execută în interiorul fiecărei cuantei de timp Δt (figura 2.9
b).
68
Δt Δt Δt Δt Δt
t t
τ τ τ τ τ
a b
Fig. 2.9. Ilustrarea sincronizării 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 cele ce urmează vor fi prezentate câteva modalităţi de implementare a

sincronizării.
5-2.3.2 Sincronizarea realizată cu semafoare

În unitatea de învățare 4 (UI 4-2.2) a fost prezentat conceptul de semafor
și operațiile P și V care se pot aplica acestuia. Dacă S este un semafor, s-a reținut
că operația P(S) poate determina blocarea taskului apelant, în timp ce operația
V(S), poate conduce la deblocarea acestuia.
O primă abordare a utilizării semafoarelor în sincronizare se referă la 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 ∈{1,2} ). Cu alte cuvinte T1 nu poate trece
de PS1 până când T2 nu a ajuns în PS2, iar T2 nu poate trece de PS2 până când
T1 nu a ajuns în PS1.
Din analiza figurii 2.10, în care se prezintă sincronizarea celor două
taskuri 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 2.10 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 ∈{1,2} .
Dacă de exemplu T2 ajunge în PS2 înainte ca T1 să îşi execute procedura
P1, se va bloca întrucât SEMSYNC2=0. Taskul T2 se va debloca după ce T1
depăşeşte PS1 deoarece va executa directiva V(SEMSYNC2).
69
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. 2.10. Utilizarea semafoarelor pentru sincronizarea a două taskuri:

P1_T1, P2_T1 – proceduri ale taskului T1 ;
P1_T2, P2_T2 – proceduri ale taskului T2.
Al doilea exemplu, ilustrat în figura 2.11, se referă la utilizarea

semafoarelor pentru sincronizarea unui task cu un eveniment extern. Acest
eveniment poate fi concretizat, de exemplu prin: apăsarea unei taste, existența
unei alarme, acționarea unui limitator de cursă etc.
În exemplul considerat sunt prezente două taskuri T0 și T1, taskul
sincronizat fiind T1, care trebuie să îşi execute procedura P2_T1 numai după
producerea evenimentului extern EVEXT. Supravegherea producerii
evenimentului este realizată de către taskul T0.
Cele două taskuri interacționează prin semaforul binar SEMSYNC
inițializat cu valoarea 0 (zero). Taskul T1 care este blocat pe directiva
P(SEMSYNC) se va debloca numai după ce în taskul T0 se execută directiva
V(SEMSYNC). Această directivă se va executa numai după producerea
evenimentului EVEXT.
Este important de subliniat faptul că în absența evenimentului cele două
taskuri sunt blocate după cum urmează: taskul T0 – în așteptarea producerii
evenimentului EVEXT, taskul T1 – pe directiva P(SEMSYNC).
70
TASK T0 TASK T1
SEMSYNC=0 SEMSYNC=0
NU P1_T1
EVEXT?
DA
P(SEMSYNC)
V(SEMSYNC)
P2_T1
Fig. 2.11. Utilizarea semafoarelor în pentru sincronizarea cu un eveniment

extern: P1_T1, P2_T1 proceduri ale taskului T1.
Construiți o versiune a reprezentării din figura 2.11, în care EVEXT
este reprezentat de apăsarea unei taste. Deblocarea taskului T1 se
produce la apăsarea tastei D, apăsarea altei taste rămânând fără efect.
TASK T0 TASK T1
SEMSYNC=0 SEMSYNC=0
NU
Δt_ex_T1? P(SEMSYNC)
DA
P_T1
V(SEMSYNC)
Fig. 2.12. Utilizarea semafoarelor în pentru sincronizarea cu timpul:

P_T1 procedură a taskului T1.
71
Semafoarele pot fi utilizate şi pentru sincronizarea taskurilor cu timpul,

în figura 2.12 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
(zero). 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 directivă de tip P la acelaşi semafor.
Rezultatul este acela că taskul T1 se va executa cu periodicitatea
Δt_ex_T126 .
Exerciţiul 3
Explicați de ce taskul T1 din figura 2.12 este blocat între execuții pe
directiva P(SEMSYNC).
5-2.3.3 Sincronizarea realizată cu variabile de tip eveniment

După cum s-a arătat în unitatea de învățare 4 (UI 4-2.2), variabilele de
tip eveniment (VTE) sunt variabile logice de tip special asupra cărora pot acționa
directive de tip ÎNSCRIE, ȘTERGE, AȘTEAPTĂ. Prin extensie, se definesc și
funcțiile de tip eveniment (FTE) cărora li se asociază caracteristici similare celor
ale VTE. Întrucât directiva AȘTEAPTĂ poate determina blocarea taskului în care
se apelează, atât VTE, cât și FTE sunt adecvate pentru sincronizare, în mod
deosebit pentru sincronizarea cu evenimente externe.
Sincronizarea cu VTE și FTE va fi exemplificată pentru un sistem de trei
taskuri T1, T2, T3 cu următoarea funcţionalitate:
- T3 se sincronizează cu ansamblul celor două evenimente.
După cum se observă din figura 2.13 în care este ilustrată sincronizarea
celor trei taskuri, evenimentelor externe EVEX1 şi EVEX2 li se asociază
variabilele de tip eveniment VTE1 respectiv VTE2 iniţializate cu valoarea FALS.
În ceea ce priveşte taskul T3, execuţia sa este condiţionată de valoarea de
adevăr a funcţiei de tip eveniment FTE = VTE1  VTE 2 asociată producerii celor
două evenimente și inițializată în taskul T3 cu valoarea FALS..
Se observă că taskurile T1 și T2 sunt blocate în așteptarea producerii
evenimentelor EVEX1 și EVEX2. După ce aceste evenimente s-au produs
variabilelor VTE1 și VTE2 li se aplică directiva ÎNSCRIE (respectiv acestora li se
atribuie valoarea ADEV ).
26
Timpul de execuţie al taskului T1 este inclus în acest interval.
72
În ceea ce privește taskul T3, acesta este blocat pe directiva AȘTEAPTĂ

(FTE), ieșirea din această stare realizându-se atunci când FTE=ADEV, respectiv
când s-au produs evenimentele externe EVEX1 şi EVEX2.
TASK T1 TASK T2 TASK T3
Iniţializare T1 Iniţializare T2 Iniţializare T3

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

taskuri: P_T1, P_T2, P_T3 proceduri ale taskurilor T1, T2, T3.
După execuția procedurii PT_3 în taskul T3, variabilelor VTE1 şi VTE2

li se aplică directiva ȘTERGE (respectiv li se atribuie valoarea logică FALS) şi
cele trei taskuri revin în starea de blocare, în aşteptarea producerii evenimentelor
externe EVEX1 şi EVEX2.
Raționamentul de mai sus presupune producerea asincronă a
evenimentelor la paritate (cu alte cuvinte după EVEXi urmează întotdeauna
EVEXj).
Construiți o versiune a reprezentării din figura 2.12 (sincronizarea cu
timpul), în care se utilizează pentru sincronizare variabila de tip
eveniment EVSINT .
73
5-2.3.4 Sincronizarea realizată cu mesaje și cutii poștale

După cum s-a prezentat în unitatea de învățare 4 (UI 4-2.2), operația de
extragere a unui mesaj dintr-o cutie poștală vidă determină blocarea taskului în
care se execută respectiva operație. Blocarea va exista până la sosirea unui mesaj
sau până la expirarea unui interval de timp predefinit. Aceleași considerente sunt
valabile și în cazul tentativei de depunere a unui mesaj într-o cutie poștală plină.
În ceea ce privește mesajele transferate în cazul utilizării cutiilor poștale
în sincronizare, acestea sunt în exclusivitate simbolice, respectiv au conținut și
lungime fixe. Cutiile poştale (CP) şi mesajele pot fi utilizate atât pentru
implementarea sincronizării cu timpul, cât şi cu evenimente externe.
În continuare vor fi prezentate soluții de sincronizare cu timpul și cu
evenimente externe bazate pe cutii poştale (CP) şi mesaje. În cadrul acestor
soluții pentru operațiile de depunere și preluare mesaje în/din CP vor fi utilizate
și denumirile DEP (PUT), respectiv PRE (GET).
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 GET
DA
(PRE)
C0 PREIA MES_SYNC din C1
t=Δt?
NU C1
DA DEPUNE MES_CONF în C2
DEPUNE MES_SYNC în C1
PUT
PUT
(DEP) (DEP)
P_T2
NU
MES_CONF în C2? C2
DA GET
PREIA MES_CONF din C2 (PRE)
Fig. 2.14. Utilizarea cutiilor poştale pentru sincronizarea cu timpul:

C0, C1, C2 – cutii poştale; P_T2 procedură a taskului T2.
74
O primă soluţie, ilustrată în figura 2.14, presupune existenţa a două

taskuri T1 - cu rol de planificator şi T2 – taskul sincronizat, 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;
- C1 – CP destinată transferului mesajului de sincronizare MES_SYNC;
- C2 – CP destinată transferului mesajului de confirmare MES_CONF.
În taskul T1 se realizează următoarea secvenţă de operaţii:
1.1 – se aşteaptă un interval de timp Δt (intervalul de sincronizare
pentru taskul T2) la cutia poştală vidă C0;
1.2 – la expirarea acestui interval se depune în cutia poştală C1 mesajul
de sincronizare MES_SYNC;
1.3 – se aşteaptă la cutia cutia poştală C2 mesajul de confirmare
MES_CONF;
1.4 – după sosirea mesajului de confirmare, acesta este preluat;
1.5 – 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ă ce
informează taskul planificator T1 în legătură cu funcţionalitatea taskului T2, care
trebuie să se execute temporizat.
În ceea ce priveşte taskul T2 , în cadrul acestuia se execută următoarea
secvenţă de operații:
2.1 – se aşteaptă sosirea mesajului sincronizare MES_SYNC în cutia
poştală C1;
2.2 – după sosire mesajul este preluat;
2.3 – se depune în cutia poştală C2 mesajul de confirmare MES_CONF;
2.4 – se execută procedura P-T2;
2.5 – se revine la pasul 2.1, intrându-se din nou în starea de aşteptare a
mesajului de sincronizare în cutia poștală C1.
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 2.15.
75
Δt Δt Δt Δt
t
Ex. Ex. Ex. Ex.

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

Δt Δt Δt Δt
t
Ex. Ex. Ex. Ex.
Task Task Task Task
T2 T2 T2 T2
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 2.17 se prezintă
structura adaptată a taskului T2 pentru acest tip de sincronizare.
TASK T2
Iniţializare T2
DA
Mes în C0?
NU
PREIA Mes din C0
Fig. 2.17. Utilizarea unei cutii poştale
GET
(PRE)
vide pentru sincronizarea cu timpul:
C0 – cutie poştală; P_T2 procedură a
C0
t=Δt? taskului T2.
NU
DA
P_T2
76
Se observă că în acest caz 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 primi la fiecare execuţie a lui T2 câte un mesaj de
confirmare.
Exerciţiul 4
Explicați așteptarea temporizată la CP-C0 în exemplele ilustrate în
figurile 2.14 și 2.17.
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 2.18.
TASK T0 TASK T1 TASK T2
Iniţializare T0
NU
NU NU
EV_EXT? MES_EV MES_SYNC
PUT în C0? în C1?
DA GET DA GET
(DEP) DA
DEPUNE (PRE)
PREIA (PRE) PREIA
MES_EV
în C0 MES_EV MES_SYNC
din C0 din C1
C0
C1
DEPUNE PUT DEPUNE

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

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

taskurile T0, T1, T2 sunt blocate după cum urmează:
- 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 2.19.
TASK T2
TASK T0
Iniţializare T2
Iniţializare T0
NU
MES_EV
NU în C0?
EV_EXT?
PUT DA
DA GET
DEPUNE (DEP) PREIA
(PRE) MES_EV
MES_EV
în C0 din C0
C0
P_T2
Fig. 2.19. Utilizarea unei cutiilor poştale pentru sincronizarea cu evenimente

externe: C0 – cutie poştală; P_T2 procedură ale taskului T2.
După cum se observă din figura 2.19, între două momente ale producerii
evenimentului extern EV_EXT taskurile T0 şi T2 sunt blocate după cum urmează:
- T2 – la cutia poştală C0 în aşteptarea mesajului MES_EV referitor la
producerea evenimentului extern.
Î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.
78
Construiți o versiune a reprezentării din figura 2.10 (sincronizarea a
două taskuri), în care se utilizează pentru sincronizare cutiile poștale
CS_1 și CS_2 și mesajul simbolic M_S.
5-2.3.5 Sincronizarea realizată cu monitoare și 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 se va considera considera 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.
Punct de întâlnire
(rendez – vous)

Fig. 2.20. Exemplificarea tehnicii rendez-vous pentru
sincronizarea unui sistem de trei taskuri A, B, C.
79
Se poate spune deci, că în spaţiul multidimensional al evoluţiei lor

taskurile trebuie să ajungă într-un punct de întâlnire, ilustrat în figura 2.20, după
care fiecare evoluează separat.
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 scade 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 la punctul de întâlnire în timpul fixat, aceasta (întâlnirea)
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.
80
1. Când se consideră sincronizate două taskuri?
2. Ce presupune sincronizarea unui task cu timpul?
3. Ce presupune sincronizarea unui task cu un eveniment extern?
4. Ce operație se execută asupra unui semafor în taskul planificator
după producerea evenimentului extern sau după trecerea timpului
specificat?
5. Ce presupune utilizarea unei cutii poștale în sincronizarea cu
timpul?
6. Ce tip de semafor se utilizează în operația de sincronizare?
7. Ce tip de mesaj se utilizează în sincronizarea implementată cu
ajutorul cutiilor poștale?
8. Care este rolul cutiilor poștale C0, C1, C2 în cazul sincronizării cu
timpul ilustrată în figura 2.14?
9. Care este rolul cutiilor poștale C0, C1, C2 în cazul sincronizării cu
un eveniment extern ilustrată în figura 2.15?
10. Explicați utilizarea mecanismului rendez-vous în sincronizare.
Rezumat
Sensul general al sincronizării este acela de corelare în timp, respectiv
de coordonare.
Sincronizarea unui task se poate realiza cu un alt task, cu timpul sau
cu un eveniment extern. Sincronizarea cu timpul poate fi interpretată din
perspectiva sincronizării cu evenimente externe, considerând întreruperile de
la ceasul de timp real ca fiind astfel de evenimente.
Sincronizarea între două taskuri presupune definirea unor puncte de
sincronizare. Pe durata în care un task așteaptă realizarea unei condiții de
timp sau producerea unui eveniment extern un task se găsește în substarea
blocat a stării active.
Semafoarele și variabilele de tip eveniment pot fi utilizate pentru toate
tipurile de sincronizări.
În ceea ce privește cutiile poștale) acestea sunt adecvate cu precădere
sincronizării cu timpul și cu evenimente externe.
Tot pentru implementarea mai pot fi utilizate monitoare și mecanismul
rendez-vous (blocuri de întâlnire).
81

1. Enunț
Construiți o versiune a reprezentării din figura 2.11, în care EVEXT
este reprezentat de apăsarea unei taste. Deblocarea taskului T1 se
produce la apăsarea tastei D, apăsarea altei taste rămânând fără efect.
Rezolvare
TASK T0 TASK T1
SEMSYNC=0 SEMSYNC=0
NU
P1_T1
TAST?
DA
NU P(SEMSYNC)
D?
DA P2_T1
V(SEMSYNC)
82
2. Enunț
Construiți o versiune a reprezentării din figura 2.12 (sincronizarea cu
timpul), în care se utilizează pentru sincronizare variabila de tip
eveniment EVSINT .
Rezolvare
TASK T0 TASK T1
EVSINT=FALS EVSINT=FALS
ASTEAPTĂ(EVSINT)
NU
Δt_ex_T1? NU
EVSINT=
ADEV?
DA
DA
ÎNSCRIE(EVSINT)
ȘTERGE(EVSINT)
P_T1
Răspunsuri la testele de autoevaluare (continuare)
3. Enunț
Construiți o versiune a reprezentării din figura 2.10 (sincronizarea a
două taskuri), în care se utilizează pentru sincronizare cutiile poștale
CS_1 și CS_2 și mesajul simbolic M_S.
83
TASK T1 TASK T2
Rezolvare
PUT
(DEP)
DEPUNE M_S în CS_1
NU NU
DA DA
P1_T1 P1_T2
NU
NU
M_S în CS_1? M_S în CS_2?
PS1
GET
DA (PRE) DA
PS2
PREIA M_S DIN CS_1 CS_1 PREIA M_S DIN CS_2
PUT
DEPUNE M_S în CS_2 (DEP) DEPUNE M_S în CS_1
PUT CS_2 GET

(PRE) P2_T2
P2_T1 (DEP)
Bibliografie
3. Dijkstra E. W., Solution of a problem in concurent programming control. A

discipline of programming, Communication of the ACM , 8(9), 1965.
7. Tanenbaum S. A. Operating systems. Design and implentation, Prentice
84
MODULUL DE STUDIU 2
Comunicarea între taskuri
6-2.4.1 Aspecte introductive
6-2.4.2 Utilizarea în comunicare a semafoarelor
6-2.4.3 Utilizarea în comunicare a mesajelor și cutiilor poștale
- necesitatea comunicării pentru taskurile interactive;
- modul de realizare a comunicării bidirecționale prin conducte;
- utilizarea semafoarelor pentru gestionarea comunicării prin conductă între
două taskuri;
- utilizarea mesajelor de trecere și a cutiilor poștale pentru implementarea
comunicării între două taskuri.
- caracterizezi când se impune utilizarea mesajelor informaționale, respectiv a
celor simbolice pentru implementarea comunicării între taskuri;
- caracterizezi utilizarea semafoarelor pentru implementarea comunicării;
comunicării.
6-2.4.1 Aspecte introductive

După cum s-a arătat, procesarea datelor în regim concurent multitasking
implică pe lângă utilizarea de resurse în comun şi schimbul de date între taskuri
concretizat în operaţia (facilitatea) de comunicare. Uzual taskurile interactive
transferă datele 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 între taskuri 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.
85
Taskurile își pot transmite mesaje direct sau indirect . La transmiterea

directă trebuie indicat taskul consumator, în timp ce la transmiterea indirectă
taskul consumator nu trebuie precizat.
Exerciţiul 1
Care este diferența dintre transmiterea directă și cea indirectă a unui
mesaj?
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.
Mecanismele de implementare a comunicării prin conducte trebuie să
asigure blocarea taskului producător care ajunge în faţa unei operaţii de depunere
a unui mesaj (scriere) şi conducta este plină (nu există spațiu disponibil). Acelaşi
mecanism va trebui să blocheze un task de tip consumator aflat în situaţia de
preluare a unui mesaj (citire) și conducta este goală (nu există mesaje
disponibile).
Î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 2.21.
Taskul i Conducta 1
Conducta 2
Taskul j
Fig. 2.21. 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 – taskul i respectiv consumator – taskul j. Î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.
86
Exerciţiul 2
Ce este o conductă?
Pentru implementarea comunicării între taskuri, ca operație multitasking,

pot fi utilizate instrumentele care au fost prezentate în unitățile de învățare
consacrate excluderii mutuale și sincronizării. În continuare vor fi prezentate
unele aspecte care vizează utilizarea semafoarelor, cutiilor poștale și mesajelor
pentru implementarea comunicării dintre două taskuri.
6-2.4.2 Utilizarea în comunicare a semafoarelor

Î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 2.22, prin
intermediul unui buffer (conductă) BUF.
P1_TCONS TCONS
cdata
NPROD N NCONS
N
.
.
BUF .
3 3
2 2
1 1
pdata
P1_TPROD TPROD
Fig. 2.22. Gestionarea comunicării prin conducta BUF .
87
TASK TPROD TASK TCONS
Iniţializare TPROD Iniţializare TCONS

SEMEX=1, SPLIN=0, SGOL=N-1 SEMEX=1, SPLIN=0, SGOL=N-1
NPROD=1 NCONS=1
NU NU
Δt_ex_TPROD? Δt_ex_TCONS?
DA DA
P1_TPROD(pdata) P1_TCONS
P(SGOL) V(SGOL)
P(SEMEX) P(SEMEX)
BUF(NPROD)=pdata cdata =BUF(NCONS)
NPROD=NPROD+1 NCONS=NCONS+1
DA DA
NPROD=N+1? NCONS=N+1?
NPROD=1 NCONS=1
NU NU
V(SEMEX) V(SEMEX)
V(SPLIN) P(SPLIN)
P2_TPROD P2_TCONS(cdata)
Fig. 2.23. Utilizarea semafoarelor în comunicare.
88
• Taskul TPROD produce date (pdata) în cadrul unei proceduri,

(P1_TPROD), date pe care le înscrie în BUF.
• Datele (cdata) sunt extrase din BUF de către taskul TCONS şi
utilizate în cadrul unei proceduri proprii (P1_TCONS).
La implementarea comunicării (ilustrată detaliat în figura 2.23) trebuie
avute în vedere următoarele aspecte:
1 – taskul TPROD trebuie să se blocheze atunci când BUF s-a umplut,
respectiv nu există spațiu disponibil;
2 – taskul 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 (mutual).
Gestiunea încărcării, respectiv a descărcării buffer-ului BUF se face cu
ajutorul a două semafoare generale SPLIN şi SGOL (iniţializate în ambele taskuri
cu valorile 0 respectiv N-1).
Semaforul SPLIN este asociat încărcării buffer-ului BUF, iar semaforul
SGOL descărcării acestuia. Fiecare înscriere în BUF presupune decrementarea
semaforului SGOL respectiv aplicarea operaţiei P(SGOL) şi incrementarea
semaforului SPLIN, respectiv aplicarea operaţiei V(SPLIN). În mod
corespunzător, fiecare extragere din BUF va fi caracterizată de operaţiile inverse
înscrierii, respectiv V(SGOL) şi P(SPLIN).
În situația în care BUF este plin, rezultă SGOL=0 , iar operația P(SGOL)
va determina blocarea taskului TPROD. Dacă BUF este gol, rezultă SPLIN=0 ,
iar operația P(SPLIN) va determina blocarea taskului TCONS.
Tot pentru gestiunea încărcării / descărcării lui BUF sunt utilizate
contoarele NPROD şi NCONS care parcurg ciclic valori de la 1 la N ceea ce
asigură preluarea datelor conform strategiei FIFO.
Pentru cele două taskuri BUF este resursă critică, deoarece nu se pot
efectua simultan operații de înscriere în și preluare din acesta. În aceste condiții
de impune excluderea mutuală pentru care se utilizează semaforul SEMEX
inițializat cu valoarea 1 în ambele taskuri
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.
Exerciţiul 3
Explicați în ce situații se blochează taskul TPROD.
89
Exerciţiul 4
Explicați în ce situații se blochează taskul TCONS.
6-2.4.3 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 care sunt de tip
informațional se trimit direct de la un taskul producător (transmițător) către cel
consumator (receptor). În ceea ce privește cutiile poștale acestea reprezintă
facilităţi de comunicare care pot fi utilizate de către toate taskurile aferente
aplicaţiei de timp real, mesajele transferate fiind tot tip informațional. Este
important de subliniat faptul că pentru uniformitate se preferă pentru mesajele
informaționale formatul fix.
Când situația o impune, taskul consumator (receptor) poate trimite un
mesaj de confirmare, care este un mesaj simbolic. În cazul transferului mesajului
simbolic rolurile taskurilor se inversează, în sensul că producătorul de mesaje
informaționale devine consumator pentru mesajul de confirmare și invers.
TASK T1 TASK T2
P1_T1 P1_T2
? NU
NU ? T1 gata transmisie
T2 gata recepţie
SEND
DA DA
T1 TRANSMITE MES_ INF la T2 T2 RECEPTIONEAZA MES_ INF
de la T1
RECEIVE
NU ? GET
MES_CONF în CP1 PUT
(PRE) CP1 (DEP)
DA
T1 PREIA MES_CONF din CP1 T2 DEPUNE MES_CONF în CP1
P2_T1 P2_T2
Fig. 2.24. Utilizarea mesajelor de trecere şi a cutiilor poştale în comunicare.
90
În figura 2.24 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 mesaj simbolic de confirmare MES_CONF prin intermediul cutiei
poştale CP1.
Este important de subliniat faptul că transmiterea unui mesaj de trecere
este posibilă numai dacă taskul receptor (consumator) este gata (respectiv este
pregătit) să îl primească. În caz contrar taskul transmițător (producător) se
blochează și rămâne în această stare până când receptorul este gata de recepție.
În ceea ce privește recepția unui mesaj de trecere, aceasta este posibilă
numai dacă taskul transmițător (producător) este gata (respectiv este pregătit) să
îl trimită. În caz contrar taskul receptor (consumator) se blochează și rămâne în
această stare până când transmițătorul este gata de transmisie.
Referitor la mesajul simbolic de confirmare, Taskul T1 se blochează până
la depunerea acestuia în cutia poştală CP1 de către Taskul T2 .
Construiți o versiune a comunicării ilustrate în figura 2.24 în care
pentru transmiterea mesajului informațional se utilizează cutia poștală
CP1 , iar confirmarea se transmite sub forma unui mesaj de trecere.
91
1. Care sunt tipurile de taskuri din punctul de vedere al comunicării?
2. În ce categorie (producător/consumator) se încadrează taskurile
transmițătoare?
3. În ce categorie (producător/consumator) se încadrează taskurile
receptoare?
4. Care este diferența între comunicarea directă și cea indirectă dintre
două taskuri?
5. Ce tip de semafor se utilizează pentru gestionarea comunicării
printr-o conductă (buffer)?
6. În ce moment un task producător poate transmite un mesaj unui
task receptor?
7. În ce moment un task consumator poate recepționa un mesaj de la
un task transmițător?
8. Ce operație execută Task 1 înaintea preluării mesajului de
confirmare din CP1 (figura 2.24)?
Rezumat
Comunicarea este o caracteristică a taskurilor interactive.
Uzual, comunicarea se realizează prin mecanismul producător-
consumator, taskurile care trimit mesaje fiind de tip producător, iar cele care
primesc mesaje de tip consumator.
Comunicarea între două taskuri poate fi directă sau indirectă. Pentru
comunicarea directă se utilizează mesajele de trecere, iar pentru cea indirectă
conductele.
Pentru gestionarea comunicării prin conducte se recomandă utilizarea
semafoarelor generale. Comunicarea prin conducte este posibilă dacă există
spațiu disponibil (la depunere – scriere), respectiv mesaje disponibile (la
preluare – citire).
Comunicarea prin mesaje de trecere se poate realiza dacă ambele
taskuri (producător și consumator) sunt pregătite (respectiv sunt gata) pentru
transmiterea, sau după caz recepționarea mesajului.
Taskurile pot transfera și mesaje de confirmare, prin aceleași metode și
cu respectarea acelorași reguli utilizate la transferul mesajelor informaționale.
92
Răspuns la testul de autoevaluare

1. Enunț
Construiți o versiune a comunicării ilustrate în figura 2.24 în care
pentru transmiterea mesajului informațional se utilizează cutia poștală
CP1 , iar confirmarea se transmite sub forma unui mesaj de trecere.
Rezolvare
TASK T1 TASK T2
P1_T1 P1_T2
PUT GET ?
NU NU
? Mes. disp. în CP1
Sp. disp. în CP1 CP1 ii
i (DEP) (PRE)
DA DA
T1 DEPUNE MES_ INF în CP1 T2 PREIA MES_ INF din CP1
NU ? ? NU
T2 gata transmisie T1 gata recepție
SEND
DA DA
T1 RECEPTIONEAZA MES_ CONF T2 TRANSMITE MES_CONF
de la T2 la T1
P2_T1 RECEIVE
P2_T2
93
Bibliografie
3. Dijkstra E. W., Solution of a problem in concurent programming control.

A discipline of programming, Communication of the ACM , 8(9), 1965.
7. Tanenbaum S. A. Operating systems. Design and implentation, Prentice
94
MODULUL DE STUDIU 3
RESURSE PENTRU PROGRAMAREA APLICAȚIILOR
DE TIMP REAL
Cerințe și caracteristici ale limbajelor pentru programarea
aplicațiilor de timp real (LPATR)
7-3.1.1 Tipuri de LPATR
7-3.1.2 Cerințe impuse LPATR
7-3.1.3 Caracteristici ale LPATR
- ce este un metalimbaj;
- ce este și cum se construiește un graf sintactic;
- care sunt cerințele impuse unui LPATR;
- care sunt caracteristicile cu care un LPATR răspunde cerințelor.
- construiești un graf sintactic a unei noțiuni aferente unui limbaj de
programare;
- caracterizezi un LPATR după modul în care acesta răspunde cerințelor
impuse;
- identifici caracteristicile unui LPATR.
7-3.1.1 Tipuri de LPATR

Limbajele de programare pentru aplicațiile de timp real (LPATR) 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.
Înainte de evidenţierea unor tipuri de LPATR 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 alocă simboluri neterminale.
Metalimbajul de descriere reprezintă un limbaj pentru descrierea
construcţiilor altui limbaj. În continuare se vor prezenta succint câteva elemente
95
aferente unui asemenea metalimbaj, în care pentru descriere se utilizează

grafurile sintactice.
Exerciţiul 1
Ce este un metalimbaj?
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.
Exerciţiul 2
Prin ce se implementează într-un graf sintactic elementele
fundamentale ale programării structurate?
De exemplu graful sintactic pentru simbolul cifră, care conţine numai

simboluri terminale, se prezintă ca în figura 3.1 şi se interpretează în felul
următor: o cifră zecimală se reprezintă cu ajutorul unuia dintre simbolurile 0, 1,
…, 9.
0 1 2 ... 8 9
Fig. 3.1. Graf sintactic pentru noţiunea cifră zecimală.
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.
96
Dacă se doreşte construcţia grafului sintactic număr algebric zecimal

întreg cu semn, se utilizează unitatea atomică semn şi noţiunea cifră zecimală
potrivit reprezentării din figura 3.2.
CZ
Fig. 3.2. Graf sintactic pentru noţiunea număr algebric

zecimal întreg cu semn: CZ – cifră zecimală..
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 3.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. 3.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.
Construiți graful sintactic pentru definirea noțiunii număr real zecimal
cu semn. Numărul va conține parte întreagă, separator (punct) și parte
fracționară.
Principalul criteriu de clasificare a LPATR îl reprezintă forma sub care

taskurile solicită servicii SOTR respectiv interfaţa sistem de operare – LPATR,
pentru care există următoarele modalităţi de realizare:
97
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. ).
7-3.1.2 Cerințe impuse LPATR

Principala cerinţă impusă LPATR o reprezintă desigur existenţa de
primitive care să implementeze operaţiile multitasking şi instrumentele de
implementare specifice.
În afara acestei cerinţe, un LPATR trebuie să satisfacă şi alte exigenţe
legate în principal de:
- fiabilitate ;
- eficienţă ;
- flexibilitate ;
- claritate ;
- simplitate;
- portabilitate.
• Fiabilitatea LPATR 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 LPATR are în vedere aspecte legate de efortul de dezvoltare
şi de gradul de utilizare a resurselor maşinii ţintă pe care se execută 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 LPATR impune ca toate operaţiile aferente unei
aplicaţii de timp real să fie exprimate exclusiv prin mijloace ale limbajului.
• Claritatea LPATR 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
98
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 LPATR 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 LPATR 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ă.
Exerciţiul 3
Enumerați cerințele impuse unui LPATR.
7-3.1.3 Caracteristici ale LPATR
Cerinţelor de mai sus li se răspunde cu caracteristici ale LPATR care

privesc:
- structurarea ;
- concurenţa ;
- programarea la nivel fizic ;
- tratarea excepţiilor ;
- compilarea 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ă.
99
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).
SD compuse sunt tipurile de date cu mai multe componente cu mai multe
componente (exemple: şiruri, matrice, etc.). Acestea pot fi referite atât 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ă sau structura iterativă cu un număr
necunoscut de paşi.
Structura de bloc are în vedere abandonarea conceptului program
monolitic în favoarea programului î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
100
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 contribuind la 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 a cărei
definire trebuie precizate numele şi tipul precum şi tipurile variabilelor implicate.
• 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), LPATR trebuie să dețină instrumente care să ofere posibilitatea
tranziţiei taskurilor între stări şi substări alături de 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 unitatea de învățare 4 (UI 4-
2.2) 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. LPATR trebuie
să ofere mijloace care să implementeze atât corelarea cu timpul sau cu
evenimente, cât şi stabilitatea acestor 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;
101
- 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 se aplică în primul rând pentru realizarea
operaţiilor de intrare-ieşire şi se justifică prin:
- 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 LPATR 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ţii 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
102
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 propriu zise
(negenerice) prin generare de exemplu (sau instanţiere).
Exerciţiul 3
Care sunt caracteristicile prin care un LPATR răspunde cerințelor
impuse?
1. Ce este un metalimbaj de descriere?
2. Care sunt elementele atomice ale unui graf sintactic?
3. Care este cerința esențială impusă unui LPATR?
4. Ce presupune cerința de fiabilitate impusă unui LPATR?
5. Sub ce aspecte este abordată caracteristica de structurare a unui
LPATR?
6. Denumiți două tipuri de structuri de cod utilizabile în
codificarea (programarea) aplicațiilor de timp real.
7. Justificați necesitatea compilării separate în calitate de
caracteristică a unui LPATR?
8. Ce presupune caracteristica de portabilitate a unui LPATR?
9. Ce sunt unitățile generice?
103
Rezumat
Metalimbajul de descriere reprezintă un limbaj pentru descrierea
construcţiilor altui limbaj.
Principalul criteriu de clasificare a LPATR îl reprezintă forma sub care
taskurile solicită servicii Sistemului de Operare în Timp Real ( SOTR).
Exigențele (cerințele) la care trebuie să răspundă un LPATR sunt:
existenţa de primitive care să implementeze operaţiile multitasking şi
instrumentele de implementare specifice, fiabilitate, eficienţă, flexibilitate,
claritate, simplitate, portabilitate.
Caracteristicile importante ale unui LPATR sunt cele legate de:
structurare, concurenţă, programarea la nivel fizic, tratarea excepţiilor,
compilare separată, existenţa unităţilor generice.
Răspuns la testul de autoevaluare

1. Enunț
Construiți graful sintactic pentru definirea noțiunii număr real zecimal
cu semn. Numărul va conține parte întreagă, separator (punct) și parte
fracționară.
Rezolvare
CZ CZ
- CZ – cifră zecimală.
Bibliografie
1. Bărbat B., Filip Gh. F., Informatica industrială. Ingineria programării în timp
real, Bucureşti, Editura Tehnică, 1997
104
MODULUL DE STUDIU 3
DE TIMP REAL
Nucleul de timp real RTK – caracteristici, inițializare și
administrare
8-3.2.1 Caracteristicile nucleului RTK
8-3.2.2 Taskuri sub RTK
8-3.2.3 Funcții RTK de inițializare
8-3.2.4 Funcții RTK de administrare a taskurilor
- motivația studierii nucleului de timp real RTK;
- care sunt caracteristicile nucleului de timp real RTK;
- care sunt stările taskurilor și tranzițiile posibile ale acestora în context RTK;
- ce operații se produc la inițializarea nucleului de timp real RTK;
- importanța funcțiilor de administrare a taskurilor.
- caracterizezi starea în care se găsește un task în context RTK;
- construiești funcțiile pentru inițializarea nucleului RTK și a driverului
consolei;
- construiești funcții RTK pentru crearea, dezactivarea și activarea taskurilor;
- construiești funcții RTK pentru furnizarea de informaţii privind
caracteristicile şi evoluţia taskurilor.
8-3.2.1 Caracteristicile nucleului RTK

RTK reprezintă acronimul pentru Real Time Kernel – nucleu de timp real
dezvoltat de On Time Company. Dezvoltările care urmează în unitățile de
învățare 8. 9, 10 (UI 8-3.2, UI 9-3.3, UI 10-3.4) se bazează pe documentația
RTK prezentată în http://www.on-time.com/rtkernel-dos.htm
Motivaţia prezentării nucleului RTK în dezvoltarea aplicațiilor de timp
real și implicit în prezentul curs constă în faptul că implementează cele mai
importante instrumente ale tratării operaţiilor fundamentale multitasking şi
anume: semafoarele, cutiile poştale şi mesajele de trecere. De asemenea nucleul
oferă posibilitatea înţelegerii conceptului de task alături de urmărirea evoluţiei
taskurilor în spațiile stărilor și/sau substărilor.
105
RTK a fost dezvoltat pentru a oferi facilităţi de timp real27 sistemului de

operare MS-DOS28. Î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 dedicate29.
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 fină a
comportării acestora;
• prioritatea reprezintă un număr natural cuprins între 1 şi 6430;
• 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.
Exerciţiul 1
Care este motivația utilizării planificatorului RTK pentru dezvoltarea
aplicațiilor de timp real?
8-3.2.2 Taskuri sub RTK

În context RTK un task reprezintă o funcție C/C++ sau procedură Pascal
fără parametri31.
27
Se are în vedere dezvoltarea de facilităţi destinate implementării execuţiei pseudoparalele a
taskurilor.
28
MS-DOS (prescurtat de la Microsoft Disk Operating System) a fost cel mai utilizat sistem de
operare din familia DOS și a dominat sistemele de operare pentru PC în anii 1980, El a fost
bazat pe familia de microprocesoare Intel 8086, în special pe IBM PC și compatibil. Un
emulator recomandat pentru o mașină pe care să ruleze MS-DOS este DOSBox
(https://www.dosbox.com/).
29
Embedded systems
30
P1< P2<….< P64
31
În cele ce urmează se vor face referiri numai la varianta de RTK bazată pe utilizarea
limbajului C/C++.
106
În continuare vor fi tratate taskurile dezvoltate ca funcţii C/ C++. În

cadrul unui 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ţa32. În ceea ce priveşte accesarea
variabilelor globale nu există restricţii. În figura 3.4 se prezintă structura unei
aplicaţii RTK destinată să ruleze sub sistemul de operare MS-DOS.
Fig. 3.4. 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 modulul 2 (UI 3-2.1) într-un spaţiu al stărilor.
Un task RTK se poate găsi într-una dintre următoarele stări33:
• Current;
• Ready;
• Suspended;
• Blocked;
• Delaying;
• Timed,
între care pot avea loc tranziţiile potrivit grafului ilustrat în figura 3.5.
32
Reentranţa reprezintă proprietatea unei funcţii de a putea fi executată simultan de către mai
multe taskuri utilizator.
33
Stările Blocked şi Timed mai pot avea şi substări care vor fi evidenţiate la prezentarea
funcţiilor specifice.
107
 Starea Current corespunde substării Execuţie din abordarea

prezentată în unitatea de învățare 3 (UI 3-2.1). 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 va fi deţinut de Idle Task creat la iniţializarea RTKernel.
 Starea Ready corespunde substării Ready din abordarea
prezentată în unitatea de învățare 3 (UI 3-2.1). Taskurile Ready îndeplinesc
condițiile pentru a prelua controlul UCP, respectiv pentru a tranzita în starea
Current.
Fig. 3.5. Graful de tranziţie a taskurilor în context RTK.
După cum se observă din figura 3.5, î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 aflate în
starea Ready,, 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)34. Modul cooperativ
(cooperative multitasking) presupune cedarea controlului procesorului de către
taskul current către un alt task aflat în starea Ready.
34
Pentru stabilirea tranşei de timp se apelează funcţia RTKTimeSlice din repertoriul de
instrucțiuni al RTKernel.
108
 Starea Suspended corespunde stării Inactiv conform abordării din

unitatea de învățare 3 (UI 3-2.1.) Un task suspendat nu poate fi executat (rulat)
întrucât a fost stopat în mod explicit prin funcţia RTKSuspend. Taskul poate
redeveni rulabil dacă asupra sa se execută funcţia RTKResume35
 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
RTKDelay36. 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 substarea Blocat specifică abordării din unitatea de învățare 3 (UI 3-
2.1.) Examinând figura 3.5 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.
Exerciţiul 2
În ce stări se poate găsi un task în context RTK?
Exerciţiul 3
În ce stări se poate tranzita un task din starea Current?.
Toate taskurile care nu sunt în starea Current sunt menţinute în cozi37

cum ar fi: coada taskurilor Ready, coada taskurilor care aşteaptă la un semafor,
la o cutie poştală etc.
Realizați o comparație sintetică (sub forma unui tabel) între stările unui
task în context RTK și stările/substările prezentate în UI 3-2.1.
35
Cele două funcţii din repertoriul RTKernel vor fi prezentate în secţiunea funcţiilor RTK de
administrare a taskurilor.
36
Funcţia RTKDelay din repertoriul RTKernel va fi prezentate în secţiunea funcţiilor RTK de
gestionare a timpului.
37
Coada (queue) reprezintă o structură de date din care elementele sunt extrase în ordinea
introducerii (administrare FIFO – First Input First Output).
109
8-3.2.3 Funcții RTK 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
De asemenea trebuie incluse tot printr-o directivă de preprocesare fişierul
cu antetele funcţiilor asociate driverului consolei38 , respectiv
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.
Exerciţiul 4
Care fișiere header (cu extensia .h) trebuie incluse într-un program
RTKernel?
Observații
 Sintaxa fiecărei funcții include trei câmpuri după cum
urmează: denumirea funcției (culoare albastră), lista cu tipul și
numele argumentelor-variabile de intrare (culoare verde), lista și
tipul variabilelor de ieșire (culoare roșie).
 Denumirea fiecărei funcții include (cu o singură excepție)
prefixul RTK.
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 forma
generală
TaskHandle Handler_Main RTKernelInit
(unsigned Prio_Main); (3.1)
38
Î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
110
unde Prio_Main este o variabilă de tip unsigned care desemnează

prioritatea taskului main.
Pentru a referi taskurile acestora li se pot asocia variabile de mânuire –
(handlere) de tip TaskHandle39. În funcţia (3.1) variabila de tip TaskHandle ,
respectiv handler-ul, este pentru taskul main40.
La execuţia funcţiei (3.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 41 şi alocarea priorităţii zero;
5) iniţializarea ceasului intern cu zero.
• Funcţia RTKeybrdInit inițializează driverul consolei şi are

forma generală
void RTKeybrdInit(void); (3.2)
Se observă că funcţia (3.2) nu întoarce nici o valoare şi că lista de
argumente a acesteia este vidă.
Exemplul 3.1
În acest exemplu se prezintă utilizarea funcţiilor (3.1) şi (3.2)
-----------------
#define prio_main 3
------------------
TaskHandle handler_main;
-----------------
handler_main=RTKernelInit(prio_main);
RTKeybrdInit();
-----------------
39
TaskHandle este un tip de variabilă predefinit în RTKernel
40
Dacă taskul main nu este referit TaskHandle poate lipsi.
41
Taskul Idle se execută atunci când nici un task utilizator nu se află în starea Current.
111
Observaţie
Ieşirea din RTKernel se realizează prin apelarea funcţiei C
exit(0).
8-3.2.4 Funcții RTK de administrare a taskurilor

În această secţiune pot fi identificate două categorii de funcţii şi anume:
a) funcţii pentru crearea, dezactivarea şi activarea taskurilor;
b) funcţii care furnizează informaţii privind caracteristicile şi evoluţia
taskurilor.
În continuare vor fi prezentate 7 funcții dintre care primele 3 incluse în
categoria a), iar ultimele 4 în categoria b).
• Funcţia RTKCreateTask permite crearea unui nou task din

alt task şi are următoarea formă generală:
TaskHandle Handler_Task RTKCreateTask
(void *Cod_Task(void), Unsigned Prioritate_Task,
unsigned Stiva_task, char *Nume_Task); (3.3)
În funcţia de mai sus notaţiile din lista de argumente au semnificaţiile
următoare:
- argumentul (parametrul) Cod_Task reprezintă o funcţie C/C++ care
conţine codul ce urmează a fi executat în noul task;
- argumentul (parametrul) Prioritate_Task – prioritatea noului task
(întreg fără semn);
- argumentul (parametrul) Stiva_Task – dimensiunea în octeţi a stivei
noului task (întreg fără semn);
- argumentul (parametrul) Nume_Task – pointer de maximum 15 caractere
la numele noului task42.
Funcţia RTKCreateTask întoarce o valoare în variabila
handler_task cu ajutorul căreia va putea fi referit noul task. Dacă în program
nu există astfel de referiri variabila handler_task poate lipsi.
Exerciţiul 5
Ce este un handler?
• Funcţia RTKSuspend realizează dezactivarea unui task,
respectiv trecerea sa în starea Suspended şi are următoarea formă generală
42
Acest nume constituie un auxiliar pentru programator și nu are legătură cu argumentul
Cod_Task
112
void RTKSuspend(TaskHandle Handler_task); (3.4)

în care parametrul Handler_Task referă taskul care urmează a fi
dezactivat ( respectiv trecut în starea Suspended).
Observaţie
Dacă taskul era deja suspendat , funcţia nu are efect.
• Funcţia RTKResume asigură activarea unui task, respectiv

trecerea sa din starea Suspended în starea Ready şi are următoarea formă
generală:
void RTKResume(TaskHandle Handler_Task); (3.5)
în care parametrul Handler_ Task referă taskul care urmează a fi
activat (respectiv trecut în starea Ready).
Observaţie
Dacă taskul nu era suspendat, funcţia nu are efect.
• Funcţia RTKSetPriority serveşte la schimbarea priorităţii
taskului referit și are următoarea formă generală:
void RTKSetPriority(TaskHandle Handler_Task,
unsigned Prio_noua); (3.6)
în care parametrul Handler_Task, de tip TaskHandle referă
taskul a cărui prioritate se va schimba, iar Prio_noua , de tipul unsigned
reprezintă noua prioritate.
• Funcţia RTKGetTaskPrio, returnează prioritatea taskului şi
are forma generală de mai jos:
unsigned Val_prio
RTKGetTaskPrio(TaskHandle Handler_Task); (3.7)
taskul a cărui prioritate se va schimba, iar Val_prio , de tipul unsigned este
variabila în care se înscrie prioritatea.
• Funcţia RTKGetTaskStack, returnează mărimea spațiului
disponibil din stiva taskului referit şi are forma generală de mai
jos:
unsigned Lib_stiva
RTKGetTaskStack(TaskHandle Handler_Task); (3.8)
taskul a cărui prioritate se va schimba, iar Lib_stiva , de tipul unsigned
este variabila în care se înscrie mărimea spațiului liber din stivă (în octeți) .
113
• Funcţia RTKGetTaskState, returnează starea (substarea)

taskului referit şi are forma generală de mai jos
TaskState Stare_task
RTKGetTaskStack(TaskHandle Handler_Task); (3.9)
taskul a cărui stare este returnată, iar Stare_task , de tipul TaskState43
este variabila în care se înscrie printr-un cod starea (substarea) taskului referit.
În contextul stărilor prezentate anterior sunt returnate coduri corespunzând
stărilor și substărilor din tabelul de mai jos.
Stare Substare 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
Task blocat la un semafor după execuţia unei funcţii
BlockedWait
RTKWait
Task blocat la depunerea unui mesaj într-o cutie poştală plină
BlockedPut
după execuţia unei funcţii RTKPut
Task blocat la extragerea unui mesaj dintr-o cutie poştală
Blocked BlockedGet
goală după execuţia unei funcţii RTKGet
Task blocat în trimiterea unui mesaj pe care destinatarul nu îl
BlockedSend
poate recepţiona, după execuţia unei funcţii RTKSend
Task blocat în aşteptarea unui mesaj pe care expeditorul încă
BlockedReceive
nu l-a trimis, după execuţia unei funcţii RTKReceive
Task în aşteptare temporizată (AT) la un semafor după
TimedWait
execuţia unei funcţii RTKWaitTimed
Task în AT pentru depunerea unui mesaj într-o cutie poştală
TimedPut
plină după execuţia unei funcţii RTKPutTimed
Task în AT pentru extragerea unui mesaj dintr-o cutie poştală
Timed TimedGet
goală după execuţia unei funcţii RTKGetTimed
Task în AT pentru transmiterea unui mesaj, după execuţia
TimedSend
unei funcţii RTKSendTimed
Task în AT pentru recepţia unui mesaj, după execuţia unei
TimedReceive
funcţii RTKReceiveTimed
43
Acest tip din RTKernel corespunde tipului enumerat din limbajul C
114
Din tabelul de mai sus rezultă că stărilor Blocked și Timed li se asociază

substări în care taskurile tranzitează prin execuția unor funcții specifice
semafoarelor, cutiilor poștale și mesajelor de trecere care vor fi detaliate în
unitățile fe învățare 9, 10, 11 (UI 9-3.3, UI 10-3.4, UI 11-3.5).
Exemplul 3.2
În acest exemplu se prezintă utilizarea funcţiilor (3.3)…(3.9)
-----------------
------------------
TaskHandle Handler_A;
TaskState Stare_A;
unsigned Prio_noua,Prio_task,Stiva_libera;
-----------------
Handler_A=RTKCreateTask(TaskA,5,1024," Taskul_A");
-----------------
RTKSuspend(Handler_A);
Stare_A=RTKGetTaskState(Handler_A);
RTKResume(Handler_A);
-----------------
Prio_task=TRTKGetaskPrio(Handler_A);
Prio_noua=Prio_task+2;
RTKSetPriority(Handler_A,Prio_noua);
Stiva_libera= RTKGetTaskStack(Handler_A);
-----------------
Știind că:
- variabilele Hand_T și Hand_M sunt de tipul TaskHandle;
- variabila Stare_T este de tipul TaskState;
- variabilele Prio_T, Stiva_disp_T sunt de tipul unsigned ,
scrieți funcțiile RTK pentru:
2.1 inițializarea RTK cu prioritatea 5 și handlerul Hand_M pentru
taskul main;
2.2 crearea unui task cu următoarele caracteristici: handler-Hand_T,
funcția C care conține codul- Func_T, prioritate – 8, stiva - 512,
nume (auxiliar) cu numele (auxiliar) - Task_test;
2.3 suspendarea taskului creat la punctul 2.1;
2.4 preluarea în variabila Stare_T a stării taskului creat la punctul 2.1;
2.5 reactivarea taskului creat la punctul 2.1;
2.6 preluarea în variabila Prio_T a priorității taskului creat la punctul
2.1;
2.7 preluarea în variabila Stiva_disp_T a stivei libere aferente taskului
creat la punctul 2.1.
115
1. Câte priorități sunt specifice nucleului RTK?
2. Ce este un handler?
3. După execuția cărei funcții RTK se creează taskul Idle?
4. Ce trebuie precizat la inițializarea nucleului RTK?
5. Ce conține lista parametrilor (argumentelor) funcției
RTKCreateTask?
6. Care este deosebirea între stările Blocked și Timed ale unui task în
context RTK?
7. Caracterizați funcțiile RTKSuspend și RTKResume.
8. Caracterizați funcțiile RTKGetTaskState și
RTKGetTaskStack.
9. După execuția cărei funcții RTK funcția main este transformată în
taskul main
10. Prin ce funcție RTK poate fi schimbată prioritatea unui task?
Rezumat
RTK (Real Time Kernel) dezvoltă pentru sistemul de operare MS-DOS
facilități de prelucrare pseudoparalelă.
RTK pune la dispoziția programatorului semafoare, cutii poștale ,
mesaje de trecere pentru implementarea operațiilor fundamentale
multitasking.
În context RTK un task reprezintă o funcție în limbaj C/C++ fără
parametri și cu stivă proprie. La inițializare unui task i se alocă o prioritate
(număr între 1 și 64). Mai multe taskuri pot avea aceiași prioritate.
Un task sub RTK se poate găsi într-una din stările: Current, Ready,
Suspended, Delaying, Blocked, Timed.
O aplicație RTK conține instrucțiuni și funcții ale limbajului C/C++ la
care se adaugă funcții specifice RTK.
Meniul nucleului RTK conține 210 funcții, din care în cadrul
prezentului curs vor fi abordate cele care privesc: iniţializarea nucleului,
administrarea taskurilor, gestionarea timpului, gestionarea cutiilor
poştale gestionarea mesajelor de trecere.
Din prima categorie au fost prezentate funcțiile: RTKernelInit
și RTKeybrdInit iar din a doua categorie funcțiile:
RTKCreateTask, RTKSuspend, RTKResume, RTKSet
Priority, RTKGetTaskPrio, RTKGetTaskStack.
TaskHandle și TaskState sunt tipuri de variabile RTK.
116
Răspuns la testele de autoevaluare

1. Enunț
Realizați o comparație sintetică (sub forma unui tabel) între stările unui
task în context RTK și stările/substările prezentate în UI 3-2.1.
Răspuns
UI 3-2.1 RTK
STARE SUBSTARE STARE
NEINSTALAT - -
INACTIV - SUSPENDED
EXECUȚIE CURRENT
GATA DE
READY
ACTIV EXECUȚIE
BLOCKED, TIMED
BLOCAT
DELAYING
2. Enunț
Știind că:
- variabilele Hand_T și Hand_M sunt de tipul TaskHandle;
- variabila Stare_T este de tipul TaskState;
- variabilele Prio_T, Stiva_disp_T sunt de tipul unsigned ,
2.1 inițializarea RTK cu prioritatea 5 și handlerul Hand_M pentru
taskul main;
2.2 crearea unui task cu următoarele caracteristici: handler-Hand_T,
funcția C care conține codul- Func_T, prioritate – 8, stiva - 512,
nume (auxiliar) cu numele (auxiliar) - Task_test;
2.3 suspendarea taskului creat la punctul 2.1;
2.4 preluarea în variabila Stare_T a stării taskului creat la punctul 2.1;
2.5 reactivarea taskului creat la punctul 2.1;
2.6 preluarea în variabila Prio_T a priorității taskului creat la punctul
2.1;
2.7 preluarea în variabila Stiva_disp_T a stivei libere aferente taskului
creat la punctul 2.1.
117
Răspuns la testul de autoevaluare 2 (continuare)
Rezolvare
2.1 Hand_M=RTKernelInit(3);
2.2 Hand_T=RTKCreateTask(Func_T,8,512,"Task_Test");
2.3 RTKSuspend(Hand_T);
2.4 Stare_T=RTKGetTaskState(Hand_T);
2.5 RTKResume(Hand_T);
2.6 Prio_task=TRTKGetaskPrio(Hand_T;
2.7 Stiva_disp_T= RTKGetTaskStack(Hand_T);
Bibliografie
3. https://ro.wikipedia.org/wiki/MS-DOS
4. https://www.dosbox.com/
118
MODULUL DE STUDIU 3
DE TIMP REAL
Nucleul de timp real RTK – funcții de gestionare a timpului și
semafoarelor
9-3.3.1 Timpul în context RTK
9-3.3.2 Funcții RTK de gestionare a timpului
9-3.3.3 Semafoare în context RTK
9-3.3.4 Funcții RTK de gestionare a semafoarelor
- cum este tratat timpul în context RTK;
- prin ce funcție RTK se realizează tranziția unui task în starea Delaying;
- cum se definește un semafor în context RTK;
- cum se implementează operațiile de P și V pentru un semafor RTK;
- prin ce funcții se realizează tranziția unui task într-una din stările
BlockedWait, respectiv TimedWait.
- utilizezi funcțiile RTK pentru gestionarea timpului;
- utilizezi funcțiile RTK pentru gestionarea semafoarelor;
- implementezi sincronizarea taskurilor cu timpul;
- utilizezi semafoarele pentru sincronizarea taskurilor cu evenimente
externe.
9-3.3.1 Timpul în context RTK

După cum s-a menţionat în unitatea de învățare 2 (UI 2-1.2) timpul
prezintă o mare importanţă în sistemele de timp real, constituind o resursă
esențială pentru acestea. În aceiași unitate de învățare se relevă faptul că un
sistem de operare în timp real trebuie să permită planificarea pentru execuție a
taskurilor pe condiții de timp. Se are în vedere posibilitatea trecerii în execuție a
taskurilor la momente sau intervale impuse. Aceiași cerință se impune și unor
nuclee de timp real (cum este cazul RTK).
În acest context, nucleul RTK menţine un ceas intern care poate fi setat
(inițializat) sau citit. Practic acesta este reprezentat de un numărător al cărui
conținut este incrementat prin sistemul de întreruperi. Ținând cont de aceste
considerații mărimea cuantei de timp reprezintă intervalul dintre două întreruperi.
119
În RTK unitatea de măsură pentru timp este timer tick. O cuantă de timp,
respectiv un timer tick are o durată aproximativ 55 ms. Această valoare rezultă
ţinând cont că timerul al unei mașini fizice (sau emulate) pe care rulează MS-
DOS generează 216 întreruperi pe oră ceea ce reprezintă aproximativ 18,2
întreruperi/secundă, care corespunde unei perioade de aproximativ 55 ms.
Exerciţiul 1
În ce unitate de măsură se exprimă timpul în context RTK?
Pentru gestionarea timpului, în RTK există tipurile următoarele tipuri de

variabile
- Time – pentru a memora momente;
- Duration – pentru a memora durate,
ambele de tipul unsigned long.
După cum s-a arătat, în unitatea de învățare 8 (UI 8-3.2) la iniţializarea
RTK prin funcția RTKernelInit ceasul intern este iniţializat cu zero, respectiv
în numărătorul care implementează ceasul intern este înscrisă valoarea zero.
Exerciţiul 2
Care sunt tipurile de variabile asociate gestionării timpului în context
RTK?
9-3.3.2 Funcții RTK de gestionare a timpului

Primele funcții RTK asociate gestionării timpului sunt cele legate de
setarea și citirea ceasului intern.
• Funcţia RTKSetTime poate fi utilizată pentru inițializarea

(setarea) ceasului intern la cu o valoare dorită nouă și are forma
generală
void RTKSetTime(Time Timp_nou); (3.10)
în care parametrul Timp_nou de tipul Time reprezintă valoarea exprimată în
ticks la care va fi setat ceasul 44.
• Funcţia RTKGetTime care poate fi utilizată pentru citirea

ceasului intern într-o variabilă de tip Time are forma generală
Time Timp_actual RTKGetTime(void); (3.11)
44
La iniţializarea RTK în cadrul funcţiei RTKernelInit se execută funcţia RTKSetTime(0);
120
Exerciţiul 3
Prin ce funcție RTK poate fi preluată valoarea înscrisă în numărătorul
asociat ceasului intern al RTK?
Exemplul 3.3
În acest exemplu se prezintă utilizarea funcţiilor (3.10) şi (3.11).
-----------------
------------------
Time Timp_setat,Timp_curent;
-----------------
Timp_curent=RTKGetTime();
Timp_setat=Timp_curent+25321;
RTKSetTime(Timp_setat);
-----------------
Următoarele două funcții prezintă o importanță deosebită întrucât determină
tranziții ale taskurilor în care acestea se execută.
• Funcţia RTKDelay asigură tranziția în starea Delaying

taskului în care funcția se execută în starea Delaying și are forma generală.
void RTKDelay(Duration Intarziere); (3.12)
Intervalul pentru care taskul rămâne în această stare este specificat printr-o
variabila Intarziere de tip Duration, valoarea acesteia putând fi calculată
cu relația
Intarziere =18 ⋅ Δt ( ticks ) , (3.13)
unde ∆t reprezintă intervalul de întârziere exprimat în secunde.
• Funcţia RTKDelayUntil permite execuţia taskului apelant

până la un moment impus de numărul de Ticks care figurează ca parametru
al funcției, respectiv Moment_Impus şi are forma generală
void RTKDelayUntil(Time Moment_Impus); (3.14)
Scrieți funcția RTK prin care taskul în care se execută este trecut în
starea Delaying pentru un interval de timp de 5 secunde.
121
Exemplul 3.4
Î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 care au codul în
funcțiile Task_ora, respectiv main.
• Taskul Task_ora 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 MS-DOS. Afişarea se realizează la nivel de caracter
în regim alfanumeric. În acest regim, ecranul este văzut ca o matrice cu 80
de coloane şi 25 de linii, potrivit figurii 3.6.
x
1 2 80
1
25
Fig. 3.6. Sectorizarea ecranului în regim alfanumeric.
Poziţionarea cursorului în coordonate absolute se realizează cu

instrucţiunea C/C++ gotoxy(x,y), unde parametrii x şi y au
semnificaţiile din figura 3.6.
• 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
funcţiei
char var_transf RTGetCh(void); (3.15)
unde var_transf este variabila în care se transferă codul ASCII al tastei
apăsate.
La apăsarea tastei E se iese din program, respectiv se execută
funcția exit(0) , iar acţionarea altei taste rămâne fără efect.
//
122
// Program demonstrativ utilizare funcţie RTKDelay

//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
struct date d;
struct time t;
//
afordata() //functie preluare si tiparire data si ora
{
cprintf(" 02d-%02d-%02d",t.ti_hour,t.ti_min,t.ti_sec);
}
//
// Task afisare temporizata a datei si orei
//
Task_ora(void)
{
{
afordata(void); //apelare functie afordata
} //sfarsit for
//
// Task main
//
main(void)
{
char c;
clrscr(void); //stergere ecran
RTKeybrdInit(void); //initializare driver consola
// Creare Task_ora
//
123

{
exit(0); //iesire
} //sfarsit for
} //sfarsit main
Observații
 În intervalele în care taskul Task_ora este în starea
Delaying și taskul main este în starea Blocked se execută taskul Idle creat cu
funcția RTKernelInit.
 După cum se observă din exempul 3.4 o aplicație dezvoltată în RTK
include: directive de preprocesare, declarații, funcții (inclusiv taskurile).
Construiți schemele logice ale taskurilor Task_ora și main din
Exemplul 3.4.
Adaptați aplicația din Exemplul 3.4 , astfel încât să se tipărească cu
periodicitate de 60 secunde direct ora și minutul (fără utilizarea
funcției afordata) în linia a 4 începând cu coloana 45.
9-3.3.3 Semafoare în context RTK

După cum s-a văzut din unitatea de învățare 4 (UI 4-2.2) 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 (Binary) şi întreg (Counting). Unui semafor binar i se pot asocia
valorile 0 sau 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 de taskuri care pot utiliza un semafor sau al numărului de
semafoare care poate fi utilizat într-un task.
124
Exerciţiul 4
Ce presupune implementarea operațiilor P și V pentru semafoarelor
definite în context RTK?
9-3.3.4 Funcții RTK de gestionare a semafoarelor

Primele funcții aferente gestionării semafoarelor sunt cele creare și
inițializare a unui semafor, respectiv de obținere a numărului de evenimente
înscrise într-un semafor.. 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 forma generală
Semaphore Semaf RTKCreateSemaphore(SemaType
Tip_Semaf, unsigned Val_init, char *Nume_semaf); (3.16)
În funcţia de mai sus semnificaţiile notaţiilor din lista de argumente au
semnificaţiile următoare:
- parametrul Tip_semaf de tipul SemaType indică tipul semaforului şi
anume Binary pentru tipul binar, respectiv Counting pentru tipul întreg;
- parametrul Val_init (î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 Nume_semaf reprezină un pointer de maximum 15 caractere
la numele noului semafor45.
Funcţia RTKCreateSemaphore întoarce o valoare într-o variabilă de
tip Semaphore cu ajutorul căruia va putea fi referit noul semafor.
Exerciţiul 5
Care sunt argumentele funcției de creare a unui semafor RTK?
• 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 forma generală
unsigned nr_ev RTKSemaValue(Semaphore Semaf); (3.17)
în care: Semaf indică semaforul referit, iar nr_ev reprezintă variabila în care
se înscrie numărul de evenimente memorat în semaforul referit .
45
Acest nume constituie un auxiliar pentru programator.
125
Între funcţiile RTK de gestionare a semafoarelor o importanţă aparte

prezintă cele de şi de implementare a operațiilor de incrementare şi decrementare,
respectiv a operațiilor de tip V și P.
• Funcţia RTKSignal memorează un eveniment într-un semafor
şi are următoarea formă generală
void RTKSignal(Semaphore Semaf); (3.18)
în care Semaf reprezintă semaforul referit.
Potrivit celor prezentate în unitatea de învățare 4 ( UI 4-2.2) prin funcţia
RTKSignal se asigură implementarea incrementării semaforului Semaf,
respectiv a operaţiei V(Semaf).
În ceea ce priveşte funcţia de decrementare a unui semafor (respectiv
de retragere a unui eveniment), aceasta se prezintă în trei forme şi anume:
necondiţionată, condiţionată şi temporizată.
• Funcţia de retragere necondiţionată este RTKWait care are
forma generală
void RTKWait (Semaphore Semaf); (3.19)
în care Semaf indică semaforul referit.
Potrivit celor prezentate în unitatea de învățare 4 (UI 4-2.2) prin funcţia
RTKWait se asigură implementarea decrementării semaforului Semaf,
respectiv a operaţiei P(Semaf). Dacă există cel puţin un eveniment disponibil,
funcţia se execută şi taskul îşi continuă rularea. Dacă nici un eveniment nu este
disponibil (respectiv dacă Semaf=0) taskul apelant trece în starea
BlockedWait. Taskul va rămâne în această stare până când în semaforul
Semaf se va înscrie un eveniment, respectiv până când asupra sa se va
executa o funcţie RTKSignal(Semaf);
• Forma condiţionată a funcţiei de retragere este
RTKWaitCond și are structura generală
bool exec RTKWaitCond(Semaphore Semaf); (3.20)
în care Semaf indică semaforul referit, iar exec este o variabilă de tip logic
(bool), în care se înscrie după caz una dintre valorile True sau False.
Dacă există cel puţin un eveniment disponibil, funcţia se execută iar în
variabila exec se înscrie valoarea logică True. Dacă nici un eveniment nu
este înscris în semaforul Semaf (respectiv dacă Semaf=0), funcţia nu se
execută, iar taskul îşi continuă execuţia (nu se blochează). În acest caz în
variabila exec se înscrie valoarea logică False.
• Varianta temporizată RTKWaitTimed a funcţiei de extragere,

are formă generală
126
bool exec RTKWaitTimed(Semaphore Semaf,

în care Semaf indică semaforul referit, iar exec este o variabilă de tip logic
(bool), în care se înscrie după caz una dintre valorile True sau False. În ceea ce
privește argumentul Timp_astept , acesta reprezintă un interval de aşteptare
Dacă există cel puţin un eveniment disponibil, funcţia se execută iar în
variabila exec se înscrie valoarea logică True. Dacă nici un eveniment nu este
disponibil (respectiv dacă Semaf=0), funcţia nu se execută, iar taskul trece
în starea TimedWait.
Dacă în timpul de aşteptare specificat (Timp_astept), este înscris
un eveniment în semafor, funcţia se execută, taskul iese din starea
TimedWait, iar în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat nici un eveniment nu se înscrie în
semafor, funcţia nu se execută, taskul iese din starea Timed Wait, iar în variabila
exec se înscrie valoarea logică False.
Exerciţiul 6
Care sunt funcțiile prin care se implementează operațiile de
incrementare respectiv decrementare a unui semafor RTK?
Exemplul 3.5
În acest exemplu se prezintă un caz de utilizare a semafoarelor
pentru realizarea sincronizării taskurilor. Sistemul este constituit din
taskurile Task_ora, Task_sincr şi main.
• Taskul Task_ora are aceleaşi caracteristici şi aceiași
funcţionalitate ca în exemplul 3.4.
• Taskul Task_sincr este blocat la semaforul binar Sem_sincr
iniţializat cu zero în taskul main. În momentul când din acest task se
execută funcţia RTKSignal(Sem_sincr) se deblochează Task_sincr
pentru 10 secunde. Pe durata deblocării, pe ecran se afișează numărul de
secunde trecute. După trecerea celor 10 secunde în taskul Task_sincr se
execută funcția RTKWait(Sem_sincr), ceea ce va determina revenirea
taskului Task_sincr în starea BlockedWait. De asemenea pe ecran se
afișează starea în care se găsește Task_sincr, 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(Sem_sincr),
127
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.
//
// Program demonstrativ utilizare semafoare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
Semaphore Sem_sincr;
struct date d;
struct time t;
//
//
afordata(void)
{
}
//
//
Task_ora(void) //task temporizare
{
{
} //sfarsit for
//
//
Task_sincr(void) //task sincronizat
{
int i;
128
{
gotoxy(5,10);
cprintf("B - BLOCAT ");
//decrementare semafor Sem_sincr
RTKWait(Sem_sincr),
gotoxy(5,10);
cprintf("EXECUTIE");
for(i=0;i<=9;i++) //bucla for in 10 pasi
{
gotoxy(15,10); //tiparire secunde trecute
cprintf("%d",i);
main(void) //task main

{
char c;
cprintf("B – Executie task_sincr E - Iesire");
RTKeybrdInit(void);//initializare driver consola
// Initializare semafor Sem_sincr
Sem_sincr=RTKCreateSemaphore(Binary,0,"Sem");
//
{
c=RTGetCh(void); //supraveghere tastatura
if(c==’B’) //testarea fata de B
//incrementeaza semafor Sem_sincr
RTKSignal(Sem_sincr);
exit(0); //iesire
} //sfarsit for
} //sfarsit main
Construiți o aplicație RTK care să implementeze utilizarea
semafoarelor în sincronizarea cu timpul ilustrată în figura 2.12, UI 5-
2.3 (în taskul T1, procedura P_T1, va fi reprezentată de funcția
afordata ) .
129
1. Care este mărimea unei cuante de timp cu care operează nucleul RTK?
2. Interpretați funcția RTKDelay(36);
3. Ce reprezintă un semafor în context RTK?
4. Care sunt tipurile de variabile RTK asociate gestionării timpului și
semafoarelor?
5. Care dintre funcțiile RTKSignal, respectiv RTKWait poate
determina blocarea taskului în care se execută?
6. Caracterizați cele trei forme ale funcței RTKWait.
Rezumat
Nucleul RTK conține un ceas intern reprezentat de un numărător al
cărui conținut este incrementat prin sistemul de întreruperi. Intervalul dintre
două întreruperi este de circa 55 ms, acest interval reprezentând mărimea unei
cuante de timp în context RTK, respectiv timer tick.
În toate funcțiile RTK timpul este gestionat ca momente respectiv ca
durate. Momentele sunt specificate prin variabile de tip Time , duratele prin
variabile de tip Duration. Atât momentele cât duratele se exprimă în
numere de timer tick.
Pentru gestionarea timpului au fost prezentate funcțiile
RTKSetTime, RTKGetTime, RTKDelay, RTKDelayUntil.
Funcția RTKDelay prezintă o importanță deosebită întrucât este utilizată
pentru sincronizarea cu timpul a taskurilor. Execuția unei asemenea funcții are
drept efect tranziția taskului în care funcția se execută în starea Delaying
pentru intervalul de timp specificat.
În context RTK un semafor reprezintă practic un numărător de
evenimente al cărui conținut poate fi incrementat (operația de tip V), respectiv
decrementat (operația de tip P). Pentru declararea semafoarelor, în RTK se
utilizează tipul Semaphore. Semafoarele pot fi de tip binar (SemaType
Binary) sau general (SemaType Counting).
Operația de tip V este implementată prin funcția RTKSignal,
iar operația de tip P prin funcția RTKWait, pentru aceasta din urmă
existând formele necondiționat, condiționat, temporizat.
130

1. Enunț
Scrieți funcția RTK prin care taskul în care se execută este trecut în
starea Delaying pentru un interval de timp de 5 secunde
Răspuns
RTKDelay(90);
2. Enunț
Construiți schemele logice ale taskurilor Task_ora și main din
Exemplul 3.4.
Rezolvare
Task_main
Task_ora
Iniţializare
Task main
NU
Δt=1 sec? NU
Tast?
DA
DA
afordata NU
E?
DA
Exit
131
Răspuns la testele de autoevaluare (continuare)

3. Enunț
Adaptați aplicația din Exemplul 3.4 , astfel încât să se tipărească cu
periodicitate de 60 secunde direct ora și minutul (fără utilizarea
funcției afordata) în linia a 4 începând cu coloana 45.
Rezolvare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
struct time t;
//
Task_ora(void)
{
for(;;)
{
RTKDelay(1080);
gettime(&t);
gotoxy(45,4);
cprintf("02d-%02d",t.ti_hour,t.ti_min);
}
}
//
main(void)
{
char c;
RTKernelInit(3);
clrscr(void);
gotoxy(5,8);
RTKeybrdInit(void);
//
for(;;)
{
c=RTGetCh();
if(c==’E’)
exit(0);
}
}
132

4. Enunț
Construiți o aplicație RTK care să implementeze utilizarea
semafoarelor în sincronizarea cu timpul ilustrată în figura 2.12, UI 5-
2.3 (în taskul T1, procedura P_T1, va fi reprezentată de funcția
afordata ) .
Rezolvare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
Semaphore SEMSYNC;
struct date d;
struct time t;
//
afordata(void)
{
getdate(&d);
gettime(&t);
gotoxy(55,3);
}
//
Task_T0(void)
{
for(;;)
{
RTKDelay(18);
RTKSignal(SEMSYNC);
}
}
//
Task_T1(void)
{
for(;;)
{
RTKWait(SEMSYNC);
afordata(void);
}
}
133
//
main(void)
{
char c;
RTKernelInit(3);
clrscr(void);
gotoxy(5,8);
RTKeybrdInit(void);
SEMSYNC=RTKCreateSemaphore(Binary,0,"Sem_sincr");
RTKCreateTask(Task_T0,5,1024,"Task_planif");
RTKCreateTask(Task_T1,7,1024,"Task_sincr");
//
for(;;)
{
c=RTGetCh();
if(c==’E’)
exit(0);
}
}
Bibliografie
134
MODULUL DE STUDIU 3
DE TIMP REAL
Nucleul de timp real RTK – funcții de gestionare a cutiilor
poștale
10-3.4.1 Cutii poștale în context RTK
10-3.4.2 Funcții RTK de gestionare a cutiilor poștale
- cum se definește o cutie poștală în context RTK;
- cum se implementează operația de depunere a unui mesaj într-o cutie
poștală RTK;
- cum se implementează operația de preluare a unui mesaj dintr-o cutie
poștală RTK;
BlockedPut, respectiv TimedPut;
BlockedGet, respectiv TimedGet;
- utilizezi funcțiile RTK pentru gestionarea cutiilor poștale;
- utilizezi cutiile poștale RTK pentru excluderea mutuală a taskurilor ;
- utilizezi cutiile poștale RTK pentru sincronizarea taskurilor timpul ;
- utilizezi cutiile poștale RTK pentru sincronizarea taskurilor cu
evenimente externe;
- utilizezi cutiile poștale pentru comunicarea între taskuri.
10-3.4.1 Cutii poștale în context RTK

După cum s-a arătat în unitatea de învățare 4 (UI 4-2.4), o cutie poștală
(Mailbox) reprezintă o zonă de memorie (buffer de date) care poate stoca un
număr prefixat de mesaje de aceiași lungime. În RTKernel nu există restricții
privind lungimea unui mesaj, î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 FIFO46.
46
FIFO – First Input First Output - strategie potrivit căreia extragerea mesajelor din coadă se
face în ordinea introducerii.
135
Taskul în care se execută o funcție de depunere într-o cutie poștală care

este plină trebuie să se blocheze până când se creează spațiu. De asemenea
trebuie să se blocheze 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 poate fi utilizată o
cutie poștală.
Este de menţionat faptul că în RTK, pentru ca o variabilă să fie tratată în
RTK în calitate de cutie poştală, aceasta trebuie declarată ca fiind de tipul
Mailbox. În continuare vor fi prezentate principalele funcții RTK ce privesc
gestionarea cutiilor poștale.
Exerciţiul 1
Care este mărimea maximă a unei cutii poștale în context RTK?
10-3.4.2 Funcții RTK de gestionare a cutiilor poștale

Pentru început vor fi prezentate funcții cu caracter general care se
referă la crearea unei cutii poștale, returnarea numărului de mesaje stocat
într-o cutie poștală, ștergerea mesajelor stocate într-o cutie poștală.
• Funcţia RTKCreateMailbox permite crearea şi iniţializarea
unei cutii poștale şi are următoarea formă generală
Mailbox Cut_post RTKCreateMailbox(unsigned Lung_mes,
unsigned Nr_mes, char *Nume_cut_post); (3.22)
În funcţia de mai sus notaţiile din lista de argumente prezintă semnificaţiile

următoare:
- parametrul Lung_mes de tipul unsigned indică lungimea în octeți a
mesajelor care pot fi înscrise în cutia poștală;
- parametrul Nr_mes , tot de tipul unsigned precizează numărul
maxim de mesaje care pot fi stocate în cutia poștală;
- Nume_Cut_Post - pointer de maximum 15 caractere la numele noii
cutii poștale47.
Funcţia RTKCreateMailbox întoarce o valoare într-o variabilă de tip

Mailbox cu ajutorul căreia va putea fi referită noua cutie poștală.
Exerciţiul 2
Care sunt argumentele funcției de creare a unei cutii poștale RTK?
47
Ca și în cazul semafoarelor, acest nume constituie un auxiliar pentru programator.
136
• 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
unsigned nr_mes RTKMessages(Mailbox Cut_post); (3.23)
în care: Cut_post reprezintă cutia poștală referită, iar nr_mes indică
variabila în care se înscrie numărul de mesaje din cutia poștală referită.
• Funcţia RTKClearMailbox realizează ștergerea conținutului

unei cutii poştale şi are formă generală
void RTKClearMailbox(Mailbox Cut_post); (3.24)
în care parametrul Cut_post reprezintă cutia poștală al cărui conținut se
șterge.
Știind că:
- variabila CP_Test este de tipul Mailbox;
- variabila Nr_mes_ este de tipul unsigned ;
1.1 crearea și inițializarea cutiei poștale CP_Test cu parametrii:
Lung_mes = 4 octeți, Nr_mes = 16, Nume_cut_post =
Cut_post_test ;
1.2 preluarea în variabila Nr_mes a numărului de mesaje din cutia
poștală CP_test ;
1.3 ștergerea cutiei poștale CP_test.
Principalele funcţii ale nucleului RTK asociate cutiilor poştale sunt cele
depunere respectiv preluare de mesaje, fucții care se prezintă în trei forme şi
• Funcţia de depunere necondiţionată este RTKPut și are

formă generală
void RTKPut(Mailbox Cut_post, void *Var_dep); (3.25)
în care variabila Cut_post de tipul Mailbox referă cutia poștală în care se
face depunerea, iar *Var_dep este un pointer la variabila al cărui conţinut se
depune în cutia poştală.
Dacă în Cut_post există spaţiu disponibil funcţia se execută şi taskul îşi
continuă rularea.
Dacă în Cut_post nu există spaţiu disponibil, funcţia nu se execută,
iar taskul apelant trece în starea BlockedPut, stare în care va rămâne până
137
când se va crea spaţiu, respectiv până când se va executa o funcție de

preluare RTKGet a unui mesaj din această cutie poștală.
• Funcţia de depunere condiţionată este RTKPutCond și are

formă generală
bool exec RTKPutCond
(Mailbox Cut_post, void *Var_dep); (3.26)
face depunerea, iar *Var_dep este un pointer la variabila al cărui conţinut se
depune în cutia poştală.
Dacă în Cut_post există spaţiu disponibil funcţia se execută, taskul îşi
continuă rularea, iar în variabila exec de tip bool se înscrie valoarea logică
True.
Dacă în Cut_post nu există spaţiu disponibil funcţia nu se execută,
taskul îşi continuă rularea, iar în variabila exec de tip bool se înscrie valoarea
logică False.
Exerciţiul 3
În ce situație se produce tranziția unui task în starea BlockedPut?
• Funcţia de depunere temporizată este RTKPutTimed și are

formă generală
bool exec RTKPutTimed
(Mailbox Cut_post, void *Var_dep,
Duration Timp_aștept ); (3.27)
face depunerea, *Var_dep este un pointer la variabila al cărui conţinut se
depune în cutia poştală, iar Timp_astept de tipul Duration , reprezintă un
interval de aşteptare (specificat în ticks)
Dacă în Cut_post există spaţiu disponibil funcţia se execută, taskul îşi
True.
Dacă în Cut_post nu există spaţiu disponibil, funcţia nu se execută,
taskul trece în starea TimedPut, pentru un interval cel mult egal cu
Timp_aștept.
Dacă în timpul de aşteptare specificat (Timp_astept), se creează
spațiu, funcţia se execută, taskul iese din starea TimedPut, iar în variabila
exec se înscrie valoarea logică True.
138
Dacă în intervalul de timp specificat nu se creează spațiu în Cut_post,

funcţia nu se execută, taskul iese din starea TimedPut, iar în variabila exec se
înscrie valoarea logică False.
Exerciţiul 4
În ce situații, după execuția unei funcții RTKPutTimed variabilei
exec i se atribuie valoarea True?
• Funcţia de preluare necondiţionată este RTKGet și are

formă generală
void RTKGet(Mailbox Cut_post, void *Var_prel); (3.28)
în care variabila Cut_post de tipul Mailbox referă cutia poștală din care se
face preluarea, iar *Var_prel este un pointer la variabila în care se depune
conţinutul preluat din cutia poştală.
Dacă în Cut_post există cel puțin un mesaj disponibil funcţia se
execută şi taskul îşi continuă rularea.
Dacă în Cut_post nu există nici un mesaj disponibil, funcţia nu se
execută, iar taskul apelant trece în starea BlockedGet, stare în care va
rămâne până când va apare un mesaj, respectiv până când se va executa o
funcție de depunere RTKPut a unui mesaj în această cutie poștală..
• Funcţia de preluare condiţionată este RTKGetCond și are

formă generală
bool exec RTKGetCond
(Mailbox Cut_post, void *Var_prel); (3.29)
face extragerea, iar *Var_prel este un pointer la variabila în care se depune
conţinutul preluat din în cutia poştală.
execută, taskul îşi continuă rularea, iar în variabila exec de tip bool se înscrie
valoarea logică True.
Dacă în Cut_post nu există cel puțin un mesaj disponibil funcţia nu se
valoarea logică False.
Exerciţiul 5
În ce situație se produce tranziția unui task în starea BlockedGet?
139
• Funcţia de preluare temporizată este RTKGetTimed și are

forma generală
bool exec RTKGetCond
(Mailbox Cut_post, void *Var_prel,
Duration Timp_aștept ); (3.30)
face extragerea, *Var_prel este un pointer la variabila în care se depune
conţinutul preluat din în cutia poştală, iar Timp_astept de tipul Duration ,
reprezintă un interval de aşteptare (specificat în ticks).
valoarea logică True.
Dacă în Cut_post nu există cel puțin un mesaj disponibil, funcţia nu se
execută, taskul trece în starea TimedGet, pentru un interval cel mult egal cu
Timp_aștept.
Dacă în timpul de aşteptare specificat (Timp_astept), se depune un
mesaj în Cut_post, funcţia se execută, taskul iese din starea TimedGet, iar
în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat nu se depune nici un mesaj în
Cut_post, funcţia nu se execută, taskul iese din starea TimedGet, iar în
variabila exec se înscrie valoarea logică False.
Exerciţiul 6
În ce situații, după execuția unei funcții RTKGetTimed variabilei
Știind că:
- variabila CP_Transf este de tipul Mailbox;
- variabilele i și j sunt de tipul unsigned ;
2.1 crearea și inițializarea cutiei poștale CP_Transf cu parametrii:
Cut_post_transf ;
2.2 inițializarea variabilei i cu valoarea 1;
2.3 tipărirea valorii variabilei i începând cu colana 30, linia 4;
2.4 depunerea în CP_Transf a conținutului variabilei i;
2.5 preluarea din CP_Transf și depunerea conținutului preluat în
variabila j;
2.6 tipărirea valorii variabilei j începând cu colana 30, linia 5.
140
Exemplul 3.6
În acest exemplu se prezintă un caz de utilizare a cutiilor poștale
pentru realizarea sincronizării taskurilor. Sistemul este constituit din
taskurile Task_ora, Task_sincr şi main.
• Taskul Task_ora are aceleaşi caracteristici şi aceiași
funcţionalitate ca în exemplele 3.4 și 3.5.
• Taskul Task_sincr este blocat pentru așteptarea sosirii unui
mesaj în cutia poștală Cut_post_sincr, creată și iniţializată în taskul main.
În momentul când din acest task se execută asupra Cut_post_sincr o funcție
de depunere RTKPut a codului unei taste apăsate, taskul Task_sincr se
deblochează. După deblocare, în Task_sincr se execută o funcție RTKGet
prin care se preia mesajul din Cut_post_sincr și se depune în variabila i.
Pentru vizualizarea caracterului recepționat, acesta se tipărește. După
această operație Task_sincr trece din nou în starea BlokedPut. De
asemenea pe ecran se afișează starea în care se găsește Task_sincr, adică
T_Sincr așteaptă la Cut_post_sincr 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 executată, în buclă
infinită, destinată supravegherii tastaturii. La apăsarea oricărei taste, alta
decât tasta E, se execută o funcția RTKPut, prin care codul tastei apăsate
este depus în Cut_post_sincr. În ceea ce privește apăsarea tastei E, această
acțiune va determina ieșirea din program. Ca și în exemplele precedente,
acţionarea altei taste rămâne fără efect.
//
// Program demonstrativ utilizare cutii poștale
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
Mailbox Cut_post_sincr;
struct date d;
struct time t;
//
//
afordata(void)
{
141

}
//
//
{
{
} //sfarsit for
//
//
Task_sincr(void) //task sincronizat
{
int i;
{
gotoxy(5,10);
cprintf("Task_sincr asteapta la Cut_post_sincr");
//preia din Cut_post_sincr si depune in i
RTKGet(Cut_post-sincr,&i);
gotoxy(5,10);
//tipareste caracterul din i
cprintf("Sosit in Cut_post_sincr mesaj %c
",i);
//
//
{
char c;
cprintf("Orice tasta mai putin E – Executie
task_sincr E - Iesire");
RTKeybrdInit(void);//initializare driver consola
// Initializare cutie postala Cut_post_sincr
142
Cut_post_sincr=RTKCreateMailbox(2,1,"CP_sincr");
//
{
gotoxy(5,9);
cprintf("Transmis din main mesajul ");
gotoxy(41,9);
//tipareste caracterul tastat
cprintf("%c",c);
if(c==’E’) //testarea fata de E
exit(0); //iesire
RTKPut(Cut_post_sincr,&c); //altfel depune c in CP
} //sfarsit for
} //sfarsit main
Construiți o aplicație RTK care să implementeze utilizarea cutiilor
poștale în sincronizarea cu timpul ilustrată în figura 2.12, UI 5-2.3 (în
taskul T1, procedura P_T1, va fi reprezentată de funcția afordata ) .
1. Ce reprezintă o cutie poștală în context RTK?
2. Ce tip de variabilă RTK este asociată gestionării cutiilor poștale?
3. Care este dimensiunea maximă a unei cutii poștale cu care poate
opera nucleul RTK?
4. Ce trebuie specificat la inițializarea unei cutii poștale RTK?
5. Interpretați funcția RTKMessages.
6. Ce funcții trebuie să se execute pentru ca un task să realizeze
tranzițiile BlockedPut →Ready respectiv BlockedGet →Ready?
7. Care dintre funcțiile RTKPut, RTKPutCond, RTKPutTimed
poate determina tranziția în starea BlockedPut a taskului în care
se execută?
8. Care dintre funcțiile RTKGet, RTKGetCond, RTKGetTimed
poate determina tranziția în starea BlockedGet a taskului în care
se execută?
9. Caracterizați cele trei forme ale funcței RTKPut.
10. Caracterizați cele trei forme ale funcței RTKGet.
143
Rezumat
În context RTK o cutie poștală reprezintă un buffer în care taskurile pot
depune mesaje sau din care acestea pot extrage mesaje. La crearea unei cutii
poștale trebuie specificate: numărul de mesaje, mărimea în octeți a unui
mesaj. Toate mesajele au aceiași lungime. Pentru specificarea cutiilor poștale,
în RTK există tipul Mailbox. La crearea unei cutii poștale se precizează
numărul de mesaje și mărimea în octeți a unui mesaj.
Principalele funcții pentru gestionarea cutiilor poștale sunt cele de
depunere respectiv de preluare a mesajelor.
Funcția de depunere se prezintă în trei forme și anume: necondiționată
– RTKPut,condiționată – RTKPutCond, temporizată – RTKPutTimed.
Funcția de preluare se prezintă de asemenea în trei forme și anume:
necondiționată – RTKGet,condiționată – RTKGetCond, temporizată –
RTKGetTimed.
Legat de utilizarea cutiilor poștale pot apărea două situații critice și
anume: cutie poștală plină (nu se poate depune un mesaj), cutie poștală goală
(nu poate prelua un mesaj).
Stările unui task aferente situației critice legate de depunerea unui
mesaj sunt BlockedPut, TimedPut.
Stările unui task aferente situației critice legate de preluarea unui mesaj
sunt BlockedGet, TimedGet.

1. Enunț
Știind că:
- variabila CP_Test este de tipul Mailbox;
- variabila Nr_mes_ este de tipul unsigned ;
1.1 crearea și inițializarea cutiei poștale CP_Test cu parametrii:
Cut_post_test ;
1.2 preluarea în variabila Nr_mes a numărului de mesaje din cutia
poștală CP_test ;
1.3 ștergerea cutiei poștale CP_test.
144

Rezolvare
1.1 CP_Test=RTKCreateMailbox(4,16,"Cut_post_test");
1.2 Nr_mes=RTKMessages(CP_Test);
1.3 RTKClearMailbox(CP_Test);
2. Enunț:
Știind că:
- variabila CP_Transf este de tipul Mailbox;
2.1 crearea și inițializarea cutiei poștale CP_Transf cu parametrii:
Cut_post_transf ;
2.2 inițializarea variabilei i cu valoarea 1;
2.4 depunerea în CP_Transf a conținutului variabilei i;
2.5 preluarea din CP_Transf și depunerea conținutului preluat în
variabila j;
Rezolvare
2.1 CP_Transf=RTKCreateMailbox(4,1,"Cut_post_transf");
2.2 i=1;
2.3 gotoxy(30,4);
cprintf("i=%d",i);
2.4 RTKPut(CP_Transf,&i);
2.5 RTKGet(CP_Transf,&j);
2.6 gotoxy(30,5);
cprintf("j=%d",j);
145

3. Enunț
Construiți o aplicație RTK care să implementeze utilizarea cutiilor
poștale în sincronizarea cu timpul ilustrată în figura 2.12, UI 5-2.3 (în
taskul T1, procedura P_T1, va fi reprezentată de funcția afordata )
Rezolvare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
Mailbox CP_SYNC
struct date d;
struct time t;
//
afordata(void)
{
getdate(&d);
gettime(&t);
gotoxy(55,3);
}
//
146
//
Task_T0(void)
{
int i=1;
for(;;)
{
RTKDelay(18);
RTKPut(CP_SYNC,&i);
}
}
//
Task_T1(void)
{
int j;
for(;;)
{
RTKGet(CP_SYNC,&j);
afordata(void);
}
}
//
//
main(void)
{
char c;
RTKernelInit(3);
clrscr(void);
gotoxy(5,8);
RTKeybrdInit(void);
CP_SYNC=RTKCreateMailbox(2,1,"Cut_post_sincr");
RTKCreateTask(Task_T1,7,1024,"Task_sincr");
//
for(;;)
{
c=RTGetCh();
if(c==’E’)
exit(0);
}
}
147
Bibliografie
148
MODULUL DE STUDIU 3
DE TIMP REAL
Nucleul de timp real RTK – funcții de gestionare a mesajelor
de trecere
11-3.5.1 Mesaje de trecere în context RTK
11-3.5.2 Funcții RTK de gestionare a mesajelor de trecere
- ce reprezintă un mesaj de trecere în context RTK;
- cum se implementează operația de transmitere a unui mesaj de trecere
în context RTK;
- cum se implementează operația de recepție a unui mesaj de trecere în
context RTK;
BlockedSend, respectiv TimedSend;
BlockedReceive, respectiv TimedReceive;
- utilizezi funcțiile RTK pentru gestionarea mesajelor de trecere;
- utilizezi mesajele de trecere pentru sincronizarea taskurilor timpul ;
- utilizezi mesajele de trecere pentru sincronizarea taskurilor cu
evenimente externe;
- utilizezi mesajele pentru comunicarea între taskuri.

După cum a reieșit din unitatea de învățare 10 (UI 10-3.4) prin cutii
poștale se poate realiza o comunicare indirectă între taskuri. În aceste condiții un
task expeditor nu trebuie să indice taskul destinatar ci cutia poștală implicată în
comunicare.
Mesajul de trecere (passing message) reprezintă o facilitate de
comunicare directă între taskuri oferită de nucleul RTK. Caracterul direct este
indicat de faptul că spre deosebire de comunicarea prin cutii poștale, taskul
expeditor trebuie să refere taskul destinatar. În aceste condiții, pentru ca un task
să poată fi indicat ca task destinatar trebuie să i se asocieze un handler48. În ceea
ce privește taskul destinatar, recepția unui mesaj de trecere nu presupune
48
Rolul unui handler este evidențiat în UI 8-3.2.
149
cunoașterea expeditorului. Cu alte cuvinte, nu se impune asocierea unui handler

unui task pentru ca acesta să poată expedia (trimite) un mesaj de trecere
O altă diferență între cele două modalități de comunicare constă în
absența unui buffer de date în cazul mesajelor de trecere. În aceste condiții în
RTK nu există un tip predefinit pentru mesajele de trecere, ca în cazul
semafoarelor și cutiilor poștale.
Exerciţiul 1
Care este deosebirea dintre comunicarea prin cutii poștale și
comunicarea prin mesaje de trecere?

Având în vedere trăsăturile de mai sus, nucleul RTK pune la dispoziția
utilizatorilor numai funcții pentru transmiterea respectiv recepția mesajelor. Ca și
în cazurile semafoarelor și cutiilor poștale aceste instrucțiuni pot fi necondiționate,
condiționate și temporizate. În cele ce urmează vor fi prezentate caracteristicile
semnificative ale acestor funcții.
 În contextul unei funcţii de transmitere a unui mesaj, taskul
destinatar referit prin handler este pregătit (TDP) dacă se găseşte într-una din
stările BlockedReceive sau TimedReceive.
• Funcţia de transmitere necondiţionată este RTKSend care are
formă generală
void RTKSend(TaskHandle Handler_rec,void *Var_dep); (3.31)
în care parametrul Handler_rec este handler al taskului destinatar, iar
*Var_dep reprezintă un pointer la variabila din care se preia mesajul ce
urmează a fi transmis.
Dacă taskul destinatar este pregătit (TDP) funcţia se execută şi taskul în
care este apelată funcţia îşi continuă rularea. Dacă taskul destinatar nu este
pregătit (TDNP), funcţia nu se execută, iar taskul apelant trece în starea
• Funcţia de transmitere condiţionată este RTKSendCond care
bool exec RTKSendCond(TaskHandle Handler_rec,
150
Dacă TDP funcţia se execută, taskul în care este apelată funcţia îşi
True.
Dacă TDNP, funcţia nu se execută, taskul apelant nu se blochează, iar
în variabila exec de tip bool se înscrie valoarea logică False.
Exerciţiul 2
În ce situație se produce tranziția unui task în starea BlockedSend?
• Funcţia de transmitere temporizată este RTKSendTimed care

bool exec RTKSendTimed(TaskHandle Handler_rec,
în care parametrul Handler_rec este handler al taskului destinatar,
urmează a fi transmis, iar Timp_astept , un interval de aşteptare (specificat în
ticks).
Dacă TDP, funcţia se execută, taskul în care este apelată funcţia îşi
continuă rularea, iar în variabila de tip exec de tip bool se înscrie valoarea
logică True.
Dacă TDNP, funcţia nu se execută, iar taskul apelant trece în starea
TimedSend, pentru un interval cel mult egal cu Timp_aștept.
Dacă în timpul de aşteptare specificat (Timp_astept), taskul
destinatar devine disponibil (TDP), funcţia se execută, taskul iese din starea
TimedSend, iar în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat taskul destinatar nu devine disponibil
(TDNP), funcţia nu se execută, taskul iese din starea TimedSend, iar în variabila
Exerciţiul 3
În ce situații, după execuția unei funcții RTKSendTimed variabilei
 În contextul unei funcţii de recepţie a unui mesaj, un task expeditor

ce referă destinatarul prin handler este pregătit (UTEP) dacă se găseşte într-una
din stările BlockedSend sau TimedSend.
• Funcţia de recepție necondiţionată este RTKReceive care

151
void RTKReceive(void *Var_rec, unsigned Lung_mes ); (3.34)

în care *Var_rec reprezintă un pointer la variabila în care se depune mesajul
recepționat, iar Lung_mes este lungimea în octeţi a mesajului care se
recepţionează.
Dacă un task expeditor este pregătit (UTEP) funcţia se execută şi taskul în
care este apelată funcţia îşi continuă rularea. Dacă nici un task expeditor nu este
pregătit (NUTEP), funcţia nu se execută, iar taskul apelant trece în starea
Exerciţiul 4
În ce situație se produce tranziția unui task în starea Blocked RECEIVE
• Funcţia de recepție condiţionată este RTKReceiveCond

care are formă generală
bool exec RTKReceiveCond(void *Var_rec,
recepţionează.
care este apelată funcţia îşi continuă rularea, iar în variabila exec de tip bool
se înscrie valoarea logică True.
Dacă NUTEP, funcţia nu se execută, taskul apelant nu se blochează,
iar în variabila exec de tip bool se înscrie valoarea logică False.
• Funcţia de recepție temporizată este RTKReceiveTimed

bool exec RTKReceiveTimed(void *Var_rec,
unsigned Lung_mes, Duration Timp_astept); (3.36)
recepționat, Lung_mes este lungimea în octeţi a mesajului care se
recepţionează, iar Timp_astept , un interval de aşteptare (specificat în ticks).
Dacă UTEP, funcţia se execută, taskul în care este apelată funcţia îşi
logică True.
Dacă NUTEP, funcţia nu se execută, iar taskul apelant trece în starea
TimedReceive, pentru un interval cel mult egal cu Timp_aștept.
152
Dacă în timpul de aşteptare specificat (Timp_astept), un task

expeditor devine disponibil (UTEP), funcţia se execută, taskul iese din
starea TimedReceive, iar în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat NUTEP , funcţia nu se execută,
taskul iese din starea TimedReceive, iar în variabila exec se înscrie valoarea
logică False.
Exerciţiul 5
În ce situații, după execuția unei funcții RTKReceiveTimed
variabilei exec i se atribuie valoarea True?
Știind că:
- variabila Hand_dest (de tip TaskHandle) este un handler asociat
taskului T2
1.1 inițializarea variabilei i cu valoarea 1 (2 octeți);
1.3 transmiterea către taskul T2 a conținutului variabilei i ;
1.4 recepția în taskul T2 (variabila j )a mesajului transmis din taskul
T1;
Exemplul 3.7
În acest exemplu se prezintă utilizarea mesajelor de trecere pentru
comunicarea între două taskuri. Sistemul multitasking este constituit din
taskurile Task_ora, Task_dest şi main.
• Taskul Task_ora are aceleaşi caracteristici şi funcţionalitate ca
în exemplele 3.4, 3.5 și 3.6.
• Taskul Task_dest 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 Task_dest a fost referit prin handlerul asociat
Handle_dest în taskul emițător. După recepția mesajului sub forma unui
caracter, acesta este tipărit în coordonate prestabilite, însoțit de mesajul
Dest a recepționat.
secţiune de declaraţii şi iniţializări şi o a doua secţiune în buclă infinită
153
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 Task_dest î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.
//
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
struct date d;
struct time t;
//
//
//
afordata(void)
{
}
//
//

{
{
} //sfarsit for
//
//
154
Task_dest(void) //task receptor

{
char j2;
{
gotoxy (5,8);
} //sfarsit TaskB
//
//
{
char c, j1=’0’;
int i;
RTKeybrdInit(void);
// creare TaskA si TaskB
Handler_dest=RTKCreateTask(Task_dest,7,1024,"Dest");
//
{
//
{
j1++;
gotoxy(5,10);
RTKDelay(18);
//
exit(0); //iesire
} //sfarsit main
155
Construiți o aplicație RTK care să implementeze utilizarea mesajelor de
trecere în sincronizarea cu timpul ilustrată în figura 2.12, UI 5-2.3 (în
1. Ce reprezintă un mesaj de trecere în context RTK?
2. Când un task se consideră pregătit pentru transmiterea unui mesaj
de trecere?
3. Când un task se consideră pregătit pentru recepția unui mesaj de
trecere?
4. Care este diferența dintre funcțiile RTKSend și
RTKSendCond?
5. Care este diferența dintre funcțiile RTKReceive și
RTKReceiveCond?
6. Ce funcții trebuie să se execute pentru ca un task să execute
tranzițiile BlockedSend →Ready urespectiv BlockedReceive
→Ready?
7. Care dintre funcțiile RTKSend, RTKSendCond,
RTKSendTimed poate determina tranziția în starea
BlockedSend a taskului în care se execută?
8. Care dintre funcțiile RTKReceive, RTKReceiveCond,
RTKReceiveTimed poate determina tranziția în starea
BlockedReceive a taskului în care se execută?
9. Caracterizați funcția RTKSendTimed.
10. Caracterizați funcția RTKReceiveTimed.
156
Rezumat
În context RTK un mesaj de trecere reprezintă o facilitate de
comunicare directă între taskuri
Principalele funcții pentru gestionarea acestei facilități sunt cele de
transmitere respectiv de recepție a mesajelor.
Funcția de transmitere se prezintă în trei forme și anume:
necondiționată – RTKSend, condiționată – RTKSendCond, temporizată –
RTKSendTimed.
Funcția de recepție se prezintă de asemenea în trei forme și anume:
necondiționată – RTKReceive,condiționată – RTKReceiveCond,
temporizată – RTKReceiveTimed.
Legat de utilizarea mesajelor pot apărea două situații critice și anume:
task receptor nepregătit (nu se poate transmite un mesaj), task emițător
nepregătit (nu poaterecepționa un mesaj).
Stările unui task aferente situației critice legate de transmiterea unui
mesaj sunt BlockedSend, TimedSend.
Stările unui task aferente situației critice legate de recepția unui mesaj
sunt BlockedReceive, TimedReceive.

1. Enunț
Știind că:
taskului T2
T1;
Rezolvare
1.1 i=1;
1.2 gotoxy(32,5);
cprintf("i=%d",i);
157
1.3 RTKSend(Hand_dest,&i);
1.4 RTKReceive(&j,2);
1.5 gotoxy(32,6);
cprintf("j=%d",j);
2. Enunț
Rezolvare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
TaskHandle Handler_T1;
struct date d;
struct time t;
//
afordata(void)
{
getdate(&d);
gettime(&t);
gotoxy(55,3);
}
//
//
Task_T0(void)
{
int i=1;
for(;;)
{
RTKDelay(18);
RTKSend(Hand_T1,&i);
}
}
158
//
Task_T1(void)
{
int j;
for(;;)
{
RTKReceive(&j,2);
afordata(void);
}
}
//
//
main(void)
{
char c;
RTKernelInit(3);
clrscr(void);
gotoxy(5,8);
RTKeybrdInit(void);
Handler_T1=RTKCreateTask(Task_T1,7,1024,"Task_sincr");
//
for(;;)
{
c=RTGetCh();
if(c==’E’)
exit(0);
}
}
Bibliografie
159
MODULUL DE STUDIU 4
PRELUCRAREA ÎN TIMP REAL A INFORMAŢIEI DE PROCES
Operații de prelucrare primară a datelor de proces
12-4.1.1 Tipuri de operații de prelucrare primară a datelor de proces
12-4.1.2 Filtrarea datelor achiziționate
12-4.1.3 Circuitul informațional aferent unei aplicații de conducere
12-4.1.4 Conversia în unități inginerești
12-4.1.5 Conversia din unități inginerești
12-4.1.6 Validarea datelor achiziționate și a comenzilor elaborate
- necesitatea operațiilor de prelucrare primară a datelor de proces;
- ce este filtrarea numerică ;
- prin ce se caracterizează un filtru numeric nerecursiv ;
- funcționalitatea circuitului informațional specific unei aplicații de
conducere;
- cum se realizează sinteza modulului de conversie (scalare) BC1 în
cadrul unui Sistem Numeric de Măsurat la Distanță (SNMD);
cadrul unui Sistem Numeric de Transmitere la Distanță (SNTD);
- ce presupune validarea datelor achiziționate și a comenzilor elaborate.
- deduci o relație recurentă pentru implementarea unui filtru numeric
nerecursiv;
- proiectezi modulul de conversii în unități inginerești (fizice) aferent
unui SNMD ;
- proiectezi modulul de conversii din unități inginerești (fizice) aferent
unui SNTD ;
- implementezi în cadrul taskurilor de achiziții date și generare comenzi a
testarea încadrării între limite a datelor achiziționate, respectiv a
comenzilor calculate.

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
161
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ță impun profitabilitatea respectivului proces,
în condițiile unei piețe concurențiale.
• Obiectivele de securitate 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 unitate de învățare (sinteză) a modulului de studiu 4 (UI
12-4.1) este tratată problema procesării primare a informației preluate din proces
și a celei destinate procesului sub forma comenzilor.
Procesarea primară încadrează următoarele operații:
- conversia în unități fizice (inginerești) a datelor achiziționate;
- conversia din unități fizice (inginerești) a comenzilor elaborate;
- validarea datelor achiziționate și a comenzilor elaborate.
În figura 1.10 din unitatea de învățare 2 (UI 2-1.2) modulul MPDA
concentrează pentru datele achiziționate funcțiile de filtrare, conversie în unități
fizice, validare. În aceiași figură modulul MPCE realizează pentru comenzile
elaborate funcțiile care privesc conversia din unități fizice și validare.
 A doua unitate de învățare (sinteză) a acestui modul (UI 13-4.2)
prezintă taskurile asociate unor algoritmi de reglare numerică cu o arie largă de
răspândire.
 În a treia unitate de învățare (sinteză) (UI 14-4.3) 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
Exerciţiul 1
Exerciţiul 2
Enumerați operațiile de prelucrare primară a datelor achiziționate și a
comenzilor elaborate.
162

Î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 4.1.
x[n] y[n]
FILTRU
NUMERIC

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.
O categorie de filtre este reprezentată de cele cu nerecursive, pentru un
asemenea filtru valoarea filtrată la pasul n, respectiv y[n] , depinde de ultimele
N valori din secvența de intrare x[n] potrivit relației49
N −1
y[n] =  h[k ] ⋅ x[n − k ], (4.1)
k =0
Din relația (4.1) rezultă că practic valoarea filtrată se obține ca medie

ponderată a ultimelor N valori din secvența de ieșire, coeficienții h[k]
reprezentând ponderi. 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 aritmetică şi relaţia (4.1) devine
N −1
1
y[n] =
N
 x[n − k ], (4.2)
k =0
unde N reprezintă ultimele N valori din secvența de intrare.
Pentru e evita calculul sumei la fiecare execuție a taskului se va

determina o formă recurențială pentru relația (4.2). În acest scop prin
transpunerea acestei relații pentru pasul anterior, respectiv pasul n-1 rezultă:
49
Dacă valoarea filtrată depinde și de eșantioane din secvența de ieșire filtrul se numește
recursiv.
163
N −1
1
y[n − 1] =
N
 x[n − 1 − k ]. (4.3)
k =0
Scăzând relaţia (4.2) din relaţia (4.3) se obține

N −1 N −1
1 1
y[n] − y[n − 1] =
N
 x[n − k ] − N
 x[n − 1 − k ],
k =0 k =0
şi în urma câtorva transformări elementare rezultă
1
y[n] = y[n − 1] + ( x[n] − x[n − N ]). (4.4)
N
Relaţia (4.4) 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ă - x[n] şi cea din urmă cu N paşi - x[n-N]). Ca element suport
pentru determinarea valorii întârziate cu N paşi se poate utiliza o structură de tip
coadă reprezentată în figura 4.2.
x[n-N]
x[n-N]
x[n-(N-1)]
x[n-2]
x[n-1]
x[n]
x[n+1]

x[n-N din] relaţia (4.4).
- y[n] = YFC - valoare filtrată curentă;

- y[n-1] = YFA - valoare filtrată anterioară;
164
- x[n] = XAC - valoare achiziţionată curentă;

- x[n-N] = XAI - valoare achiziţionată întârziată,
YFC = YFA + ( XAC − XAI ) / N , (4.5)
uşor de implementat atât în logică de tip programat, cât şi cablat.
Construiți schema logică asociată taskului TASK_FILT de

implementare a relației (4.5) cunoscând că:
- TASK_FILT este sincronizat cu timpul, intervalul de execuție fiind
Te_F;
- XAC se preia dintr-o bază de date de proces (BDP)iar YFC se
depune în aceiași BDP în cadrul unor secțiuni critice;
- pentru excludere mutuală se utilizează semaforul binar SEMEX ;
- număr de eșantioane N;
- indice de ciclare i, variabilă indexată de lucru Z(i) cu i=1...N.
Într-o aplicaţie de conducere în timp real, de tipul celei din figura 1.10,
(UI 2-1.2) poate fi evidenţiată următoarea secvenţă de operaţii:
Realizarea acestei secvențe implică existenţa unui circuit informaţional
ilustrat în figura 4.3, în care procesul este reprezentat prin traductoare-T și
elemente de execuție - EE, iar echipamentul numeric prin porturi de intrare – PI
și porturi de ieșiri – PE.
165
F1 F2

T PI
Semnale uCAN uING Calcul și
analogice
PROCES generare
de la traductoare
comenzi
EE PE
Semnale uCNA uING
analogice
către elemente
de execuție

Se consideră că traductoarele generează semnale analogice, iar elementele

de execuție sunt acționate de către același tip de semnale. Întrucât procesarea
impune intrări în formă numerică și generează rezultate în aceiași formă, rezultă
necesitatea unei frontiere în care să se schimbe natura semnalelor. Aceasta
frontieră notată F1 în figura 4.3, este reprezentată de SIA (Subsistemul Intrărilor
Analogice) și de SEA (Subsistemul Ieșirilor Analogice) din structura sistemului
de interfață cu procesul50.
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
o conversie analog / numerică, iar 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 unități
CNA51 (uCNA).
O a doua frontieră evidenţiată în figura 4.3 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.
50
În cazul aparaturii inteligente de automatizare (Smart) această frontieră este situată la limita
respectivei instrumentații, iar transmiterea semnalelor se face în format digital.
51
CAN și CNA sunt abrevieri pentru Convertor Analog Numeric, respectiv Convertor Numeric
Analog.
166
Dacă frontiera F1 este asociată sistemului de interfață cu procesul (SIP),

frontiera F2 este asociată unor module de calcul specifice respectivelor conversii.
În figura 4.4 se prezintă circuitul informațional, în cadrul unei aplicații
de conducere, în care un regulator după perturbație (REG_PERT) elaborează un
semnal de comandă care se transmite sub forma referinței externe regulatorului
după abatere (REG_AB) integrat într-un SRA abatere În această figură deasupra
fiecărei săgeți este notată o mărime iar sub săgeată unitatea de măsură.
Structura din figura 4.4 asigură invarianța mărimii y252 la modificarea
perturbațiilor P2_1…P2_k. Mărimea de comandă a regulatorului după perturbație
REG_PERT este reprezentată de valoarea y1*, exprimată în unități inginerești
uING, care se aplică în calitate de referință unui SRA abatere, implicit
regulatorului REG_AB. În aceiași figură CUI și CIU reprezintă convertoarele
uP1
F2 F1
P2_1 P2_k P2_n
iP1
P* NP uP CIU1 TP1
V mA
PI BC1 CAN
uPk iPk
V CIUk TPk
REG uING uCAN
V
PERT mA
REG AB P2
u1
y1* N1 P1
i1 y1 SP2
PE CUI REG SP1
BC2 CNA AB EE
uING uCNA V r1
mA
TA y2 uING
y2i mA
uING
Analizând figura 4.4 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 de transmitere a
52
167
comenzii. În cele ce urmează vor fi prezentate elemente privind sinteza celor

două module (blocuri) de calcul.
Exerciţiul 3
Care este rolul frontierelor F1 și F2 în cadrul circuitului informațional
asociat unui sistem de conducere?
Exerciţiul 4
Prin ce se implementează frontierele F1 și F2 în cadrul circuitului
informațional asociat unui SRA ierarhizat?

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 4.5.
T CIU CAN BC1 SNMD
[uING] [mA] [V] [uCAN] [uING] [uING] [uING]
În figura 4.5 mărimile sunt reprezentate prin variaţii . Pentru o mărime z

care ia valori într-un domeniu [zmin, zmax] , respectiv z ∈ [ zmin , zmax ] se definesc
următoarele două tipuri de variaţii:
Δz = z − zmin , (4.6)
- variaţia maximă
- Δzmax = zmax − zmin . (4.7)
Determinarea relaţiei asociate modulului BC1 se va realiza impunând
pentru SNMD o caracteristică statică liniară, ilustrată în figura 4.6.
Δx*
Δx*max

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

astfel încât pentru CIU rezultă o caracteristică liniară prezentată în figura 4.7 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 4.7 b.
Δu ΔN
ΔNmax
Δumax
a b
Având în vedere caracteristicile statice ilustrate în figurile 4.6 şi 4.7

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:
• Sinteza BC1 pentru un SNMD cu traductor liniar

În figura 4.8 este ilustrată caracteristica statică a unui traductor liniar
care se consideră inclus în SNMD.
Δi
Δimax

din structura SNMD.
Δxmax Δx
Caracteristicilor statice din figurile 4.6, 4.7 și 4.8 li se asociază următorul

sistem de ecuaţii în variații:
169
* Δx*max
SNMD: Δx = ⋅ Δx , (4.8)
Δxmax
Δimax
T: Δi = ⋅ Δx , (4.9)
Δxmax
Δumax
CIU: Δu = ⋅ Δi , (4.10)
Δimax
ΔN max
CAN: ΔN = ⋅ Δu . (4.11)
Δumax
Rezolvând sistemul format din ecuaţiile (4.8)…(4.11) rezultă pentru
BC1 relaţia
*
Δxmax
Δx* = ⋅ ΔN . (4.12)
ΔN max
Dacă în relația (4.12) se impune pentru mărimea x* (reprezentată în
memorie) acelaşi domeniu de variaţie ca pentru mărimea fizică (respectiv
Δx*max= Δxmax), rezultă
Δxmax
Δx* = ⋅ ΔN . (4.13)
ΔN max
Examinând relaţia (4.13) se observă că elementul BC1 este un element
liniar, a cărui caracteristică statică este reprezentată în figura 4.9.
Δx*
Δxmax

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 (4.13) se exprimă abaterile ţinând cont
de relaţiile (4.6) , (4.7) şi rezultă
xmax − xmin
x* − xmin = ⋅ ( N − N min ) . (4.14)
N max − N min
170
xmax ⋅ N min − xmin ⋅ N max xmax − xmin

x* = − + ⋅ N. (4.15)
N max − N min N max − N min
sau
x* = a0 + a1 ⋅ N , (4.16)
unde
xmax ⋅ N min − xmin ⋅ N max

a0 = − ; (4.17)
N max − N min
xmax − xmin
a1 = . (4.18)
N max − N min
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 (4.15)
devine
xmax ⋅ N min xmax

x* = − + ⋅ N. (4.19)
sau
x* = b0 + b1 ⋅ N , (4.20)
unde
xmax ⋅ N min (4.21)

b0 = − ;
N max − N min
xmax (4.22)
b1 = .
N max − N min
Rezultatele de mai sus confirmă faptul că indiferent de forma de

exprimare (prin variaţii sau valori absolute), modulul BC1 prezintă o
caracteristică statică liniară.
171
• 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 4.10, astfel încât pentru
SNMD rezultă sistemul de ecuaţii (4.23)…(4.26).
Δi
Δimax

Δxmax Δx
* Δx*max
SNMD: Δx = ⋅ Δx , (4.23)
Δxmax
Δimax
T: Δi = 2
⋅ ( Δx )2 , (4.24)
( Δxmax )
Δumax
CIU: Δu = ⋅ Δi , (4.25)
Δimax
ΔN max
CAN: ΔN = ⋅ Δu . (4.26)
Δumax
BC1 ecuaţia
Δx*max
*
Δx = ⋅ ΔN , (4.27)
ΔN max
sau impunând pentru mărimea x* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică, respectiv (respectiv Δx*max= Δxmax), se obține
Δxmax
Δx* = ⋅ ΔN . (4.28)
ΔN max
Examinând relaţia (4.28) se observă că modulul BC1 corespunde unui
element neliniar, a cărui caracteristică statică este reprezentată în figura 4.11.
Este de remarcat faptul că neliniaritatea introdusă de BC1 compensează
172
neliniaritatea traductorului T, astfel încât pe ansamblu caracteristica statică a

SNMD să rezulte liniară.
Δx*
Δxmax

cu caracteristică statică neliniară de tip pătratic.
Δ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 (4.28)
se exprimă variațiile ţinând cont de relaţiile (4.6), (4.7) şi rezultă
xmax − xmin
x* − xmin = ⋅ ( N − N min ) . (4.29)
N max − N min
După efectuarea calculelor în relaţia (4.29), în situaţia xmin = 0 (frecvent
întâlnită în practică) se obţine,
N − N min
x* = xmax ⋅ . (4.30)
N max − N min
sau
2 2
* − N min xmax xmax
x = + ⋅N (4.31)
respectiv
x* = c0 + c1 ⋅ N , (4.32)
unde
2
N min ⋅ xmax
c0 = − ; (4.33)
N max − N min
2
xmax (4.34)
c1 = .
N max − N min
173

exprimare (prin variaţii sau prin valori absolute) modulul BC1 prezintă o
caracteristică statică neliniară care compensează neliniaritatea caracteristicii
traductorului T.
Exerciţiul 5
Ce elemente sunt incluse în structura unui SNMD?
Exerciţiul 6
Care este rolul BC1 în cadrul unui SNMD?
Exemplul 4.1
Pentru SNMD nivel cu structura ilustrată în figura 4.12 se cunosc:

SNMD - caracteristică statică (CS) liniară cu H , H * ∈ [200 ÷ 800] mm ;
LT - CS – liniară cu H ∈ [200 ÷ 800] mm , i ∈ [4 ÷ 20] mA ;
CIU - CS – liniară cu R = 250 Ω ;
CAN - CS – liniară cu Nmax = 1023 uCAN, N(0)=0, N(umin)= Nmin,
N(umax)= Nmax .
Să se determine:
a – domeniul de valori al tensiunii (respectiv umin și umax) la
intrarea CAN;
c – valoarea numărului de cuante N1 în cazul
corespunzătoare unui unei valori a nivelului reprezentată
în memorie H1* = 400 mm .
Qi i
H H*
N
LT R u CAN BC1
Qe
174
Rezolvare
umin = R ⋅ imin = 250 ⋅ 4 ⋅10−3 =1V ;
umax = R ⋅ imax = 250 ⋅ 20 ⋅10−3 = 5V .

b – pentru un CAN se cunoaşte că N max = 2n − 1 de unde rezultă
n = log 2 ( N max + 1 ) = log 2 ( 1023 + 1 ) = log 2 1024 =10 biti .

N
Nmax

Nmin
U
Umin Umax
Caracteristica statică liniară din figura 4.13 este descrisă de ecuaţia
N max
N= ⋅u ,
umax
de unde rezultă
N max 1023
N min = ⋅ umin = ⋅ 1 = 204 ,6 uCAN .
umax 5
Se determină coeficienţii din relaţiile (4.17) şi (4.18) după cum urmează:

H max ⋅ N min − H min ⋅ N max 800 ⋅ 204 ,6 − 200 ⋅ 1023
a0 = − =− = 50 mm;
N max − N min 1023 − 204,6
175
H m a x − H m in 800 − 200
a1 = = = 0 ,7 3 3 1 3 7 8 3 m m / u C A N .
N m a x − N m in 1 0 2 3 − 2 0 4 , 6

H * = a0 + a1 ⋅ N ,
respectiv
H * = 50 + 0,73313783 ⋅ N ,
de unde se obține
H * − 50
N= ,
0,73313783
respectiv
H1* − 50 400 − 50 350

N1 = = = = 477,4 uCAN .
0,73313783 0,73313783 0,73313783
Exemplul 4.2

SNMD - caracteristică statică (CS) liniară cu Q, Q* ∈ [0 ÷ 60] m3 / h ;
FT - CS – neliniară (pătratică) cu
Q ∈ [0 ÷ 60] m3 / h , i ∈ [4 ÷ 20] mA ;
CAN - CS – liniară cu rezoluția n=12 biți, N(0)=0, N(umin)= Nmin,
N(umax)= Nmax .
Să se determine:
a. – domeniul de valori al tensiunii la intrarea CAN, numărul

maxim (Nmax) și minim (Nmin) de uCAN ale acestuia;
b – valoarea Q1* a debitului reprezentat în memorie pentru
N1=2457 uCAN.
176
N Q*
u CAN BC1
i R
FT
Q
Fig. 4.14. Structura SNMD debit pentru exemplul
Rezolvare
umin = R ⋅ imin = 50 ⋅ 4 ⋅10−3 = 0,2 V ;
umax = R ⋅ imax = 50 ⋅ 20 ⋅10−3 =1V .
Pentru CAN cu caracteristica statică liniară din figura 4.13 (exemplul 4.1)
este descrisă de ecuaţia
N max
N= ⋅u ,
umax
de unde rezultă
N max 4095
N min = ⋅ umin = ⋅ 0 ,2 = 819 uCAN .
umax 1
b – în condiţiile problemei, coeficienţii c0 şi c1 se calculează după cum

urmează:
2
− N min ⋅ Qmax −819 ⋅ 3600
c0 = = = − 900 ( m3 / h )2 ;
N max − N min 4095 − 819
2
Qmax 3600
c1 = = =1,0989011( m3 / h )2 / uCAN .
N max − N min 4095 − 819
177
Cu aceşti coeficienţi, se obţine următoarea relaţie pentru modulul BC1

Q* = c0 + c1 ⋅ N = −900 + 1,0989011 ⋅ N ,
sau în condiţiile problemei
Q1* = −900 + 1,0989011 ⋅ 2457 = −900 + 2700 = 1800 = 42,426 m3 / h .
Pentru SNMD temperatură cu structura ilustrată în figură se cunosc:

SNMD - caracteristică statică (CS) liniară
cu T , T * ∈ [0 ÷ 100] grd C ;
LT - CS – liniară cu
T ∈ [ 0 ÷ 100 ] grd C , i ∈ [ imin ÷ imax ] mA, imax = 20 mA;
CIU - CS – liniară
u ∈ [ umin ÷ umax ]V , umin =1V ,umax = 5V ;
CAN - CS – liniară cu Nmin = 819 uCAN, N(0)=0,

N(umin)= Nmin, N(umax)= Nmax ;
BC1 - CS – liniară
ΔTmax
ΔT * = ⋅ ΔN .
ΔN max
Qi
i
N T*
Qat TT R u
CAN BC1
T
Qe
Să se determine:
a – valorile pentru rezistența R (în Ω) și intensității curentului imin
(în mA);
b – numărul maxim Nmax (în uCNA și rezoluţia n (în biți) a CAN;
c – valoarea numărului de cuante N1 corespunzătoare valorii
T1* = 75 grd C temperaturii reprezentate în memorie.
178

Aşa cum reiese din figura 4.4 în care se prezintă circuitul informaţional
într-un SRA ierarhizat, această conversie se realizează de către blocul BC2, parte
integrantă a unui sistem numeric de transmitere a comenzii la distanţă (SNTD)
cu structura evidenţiată în figura 4.15.
Δy* ΔN Δu Δi Δy Δy* Δy
[uING] [uCNA] [V] [mA] [uING] [uING] [uING]

la distanţă.
Ca şi la conversia în unităţi inginerești, mărimile sunt exprimate prin

variaţii, semnificaţiile tipurilor de variaţii fiind cele din relaţiile 4.6 şi 4.7.
pentru SNTD o caracteristică statică liniară ilustrată în figura 4.16.
Δy
Δymax

SNTD.
Δy*max Δy*
Atât pentru convertorul tensiune curent CUI, cât şi pentru cel analog
numeric CNA se presupun caracteristici statice liniare prezentate în figura 4.17.
Δi Δu
Δimax
Δumax
Δumax Δu ΔN
ΔNmax
a b
179

depinde numai de forma caracteristicii statice de măsură a Sistemului de Reglare
Automată (SRA)53.
În cele ce urmează vor fi considerate două situaţii şi anume:
- SNTD include SRA cu caracteristică de măsură (CM) de tip liniar;
- SNTD include SRA cu caracteristică de măsură (CM) de tip neliniar.
• Sinteza BC2 pentru un SNTD care include SRA cu CM liniară

În figura 4.18 este ilustrată caracteristica statică a unui SRA cu CM
Δy
Δymax

din structura SNTD.
Δi
Δimax
Caracteristicilor statice din figurile 4.16, 4.17 și 4.18 li se asociază

următorul sistem de ecuaţii în variații:
Δymax
SNTD: Δy = *
⋅ Δy* , (4.35)
Δymax
Δymax
SRA: Δy = ⋅ Δi , (4.36)
Δimax
Δimax
CUI: Δi = ⋅ Δu , (4.37)
Δumax
Δumax
CNA: Δu = ⋅ ΔN . (4.38)
ΔN max
53
În loc de SRA poate fi considerat un element de execuție EE.
180
Rezolvând sistemul format din ecuaţiile (4.35)…(4.38) se obține pentru

BC2 ecuaţia
ΔN max
ΔN = *
⋅ Δy* , (4.39)
Δymax
sau impunând pentru mărimea y* reprezentată în memorie acelaşi domeniu de
*
variaţie ca pentru mărimea fizică y (respectiv Δymax = Δymax ) rezultă
ΔN max
ΔN = ⋅ Δy* . (4.40)
Δymax
Examinând relaţia (4.40) se observă că modulul BC2 este corespunde unui
element liniar, a cărui caracteristică statică este reprezentată în figura 4.19.
ΔN
ΔNmax
CM liniară.
Δymax Δy*
Ca şi în cazul conversiei în unităţi inginereşti sunt situaţii care necesită

utilizarea relaţiei aferente modulului BC2 exprimată în valori absolute. Pentru a
obţine această formă, în ecuaţia (4.40) se exprimă variațiile ţinând cont de
relaţiile (4.6), (4.7) şi rezultă
N max − N min
N − N min = ⋅ ( y* − ymin ) . (4.41)
ymax − ymin
ymax ⋅ N min − ymin ⋅ N max N max − N min *
N= + ⋅y . (4.42)
ymax − ymin ymax − ymin
sau
N = d 0 + d1 ⋅ y* , (4.43)
181
unde
ymax ⋅ N min − ymin ⋅ N max (4.44)

d0 = ;
N max − N min
N − N min (4.45)
d1 = max .
ymax − ymin
O situaţie frecvent întâlnită în practică este aceea în care limita
inferioară a domeniului mărimii y este nulă, respectiv ymin = 0. În acest caz
ecuaţia (4.42) devine
N max − N min *
N = N min + ⋅y , (4.46)
ymax
sau
N = e0 + e1 ⋅ y* , (4.47)
unde
e0 = N min , (4.48)
N max − N min (4.49)
e1 = .
ymax

• Sinteza BC2 pentru un SNTD care include SRA cu CM neliniară
Pentru SNTD, CNA şi CUI se menţin în acest și caz caracteristicile liniare

prezentate în cazul SRA cu CM liniară.
În ceea ce priveşte SRA, pentru acesta se va considera o CM neliniară (de
tip radical) ilustrată în figura 4.20.
182
Δy
Δymax
Δi
Δimax
Caracteristicilor statice din figurile 4.16, 4.17 şi 4.20 li se asociază

Δymax
SNTD: Δy = *
⋅ Δy* , (4.50)
Δymax
Δymax
SRA: Δy = ⋅ Δi , (4.51)
Δimax
Δimax
CUI: Δi = ⋅ Δu , (4.52)
Δumax
Δumax
CNA: Δu = ⋅ ΔN . (4.53)
ΔN max
pentru BC2 ecuaţia
ΔN max
ΔN = * 2
⋅ ( Δy* )2 , (4.54)
( Δymax )
variaţie ca pentru mărimea fizică rezultă
ΔN max
ΔN = 2
⋅ ( Δy* )2 . (4.55)
( Δymax )
Examinând relaţia (4.55) se observă că modulul BC2 corespunde un
După cum se observă, prin această caracteristică este compensată neliniaritatea
caracteristicii de măsură a SRA.
183
ΔN
ΔNmax
neliniară de tip radical.
Δ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 (4.55)
se exprimă abaterile ţinând cont de relaţiile (4.6), (4.7) şi rezultă
N max − N min
N − N min = 2
⋅ ( y* − ymin )2 . (4.56)
( ymax − ymin )
N = f 0 + f1 ⋅ y* + f 2 ⋅ ( y* )2 , (4.57)
unde
N max − N min
f 0 = N min + 2
⋅ ( ymin )2 , (4.58)
( ymax − ymin )
N max − N min
f1 = −2 ⋅ ymin ⋅ , (4.59)
ymax − ymin
N max − N min
f2 = . (4.60)
( ymax − ymin )2
Dacă limita inferioară a domeniului mărimii y este nulă, respectiv
ymin = 0 , relaţia (4.60) devine
N = g 0 + g 2 ⋅ ( y* )2 , (4.61)
unde
g 0 = N min , (4.62)
N max − N min
g2 = . (4.63)
( ymax )2
184

exprimare (prin variaţii sau valori absolute) BC2 prezintă o caracteristică statică
neliniară care compensează neliniaritatea CM a SRA.
Exerciţiul 7
Ce elemente sunt incluse în structura unui SNTD?
Exerciţiul 8
Care este rolul BC2 în cadrul unui SNTD?
În continuare vor fi prezentate două exemple care tratează aspecte

referitoare la conversia din unităţi inginereşti.
Exemplul 4.3
Pentru SNTD nivel cu structura ilustrată în figura 4.22 se cunosc:

SNTD - caracteristică statică (CS) liniară cu H , H * ∈ [200 ÷ 800] mm ;
SRA - CM – liniară cu H ∈ [200 ÷ 800] mm , i ∈ [4 ÷ 20] mA ;
CUI - CS – liniară cu u ∈ [0, 2 ÷ 1] V ;
CNA - CS – liniară cu Nmax = 2047 uCNA, u(0)=0, u(Nmin)= umin,
u(Nmax)= umax .
Să se determine:
a – rezoluţia n a CNA și numărul minim Nmin de uCNA;
Qi i u N H*
CUI CNA BC2
LT LC
Qe
185
Rezolvare
N max = 2n − 1, de unde rezultă
Pentru determinarea valorii Nmin se apelează la caracteristica statică a

CNA ilustrată în figura 4.23.
U
Umax

Umin
N
Nmin Nmax
Caracteristica statică liniară din figura 4.23 poate fi descrisă de relaţia

umax
u= ⋅N ,
N max
de unde rezultă
N max 2047
N min = ⋅ umin = ⋅ 1 = 409 ,4 uCNA .
umax 5
b – Se determină coeficienţii din relaţiile (4.44) şi (4.45) după cum

urmează:
d0 = = =
H max − H min 800 − 200
= − 136 ,466667 uCNA ;
N max − N min 2047 − 409 ,4

d1 = = = 2 ,72933333 uCNA / mm.
H max − H min 800 − 200
186

N = d0 + d1 ⋅ H * ,
respectiv
N = −136,466667 + 2,72933333 ⋅ H * ,
de unde rezultă
N + 136 ,466667
H* = .
2 ,72933333
Pentru N1=800 uCNA se obține
N1 + 136 ,466667 800 + 136 ,466667 936 ,466667

H1* = = = = 343,11mm.
2 ,72933333 2 ,7293333 2 ,72933333
Exemplul 4.4
Pentru SNTD debit cu structura ilustrată în figura 4.24 se cunosc:

SNTD - caracteristică statică (CS) liniară cu Q, Q* ∈ [0 ÷ 60] m3 / h ;
SRA - CM – neliniară (radical) cu
Q ∈ [0 ÷ 60] m3 / h , i ∈ [4 ÷ 20] mA ;
CNA - CS – liniară cu n = 12 biți, u(0)=0, u(Nmin)= umin,
u(Nmax)= umax .
Să se determine:
a – numerele Nmin şi Nmax de uCNA pentru CNA;
b – valorile coeficienților asociați exprimării relației pentru
BC2 în valori absolute;
c – valoarea N1 a numărului de uCNA pentru un debit calculat
Q1* = 45 m3 / h.
.
187
N Q*
i u
CUI CNA BC2
FC
FT
Q
Rezolvare
a – N max = 2n − 1= 212 − 1 = 4096 − 1 = 4095 uCNA .

u [V]
Umax = 2

Umin = 0,4
N[uCNA]
Nmin Nmax=4095

umax
u= ⋅N ,
N max
de unde rezultă
N max 4095
N min = ⋅ umin = ⋅ 0 ,4 = 819 uCNA .
umax 2
188
c – se calculează coeficienţii g0 şi g2 din relaţiile (4.62) şi (4.63) după

cum urmează:
g 0 = N min = 819 uCNA ;
N max − N min 4095 − 819 3276

g2 = 2
= 2
= = 0 ,91 uCNA / ( m3 / h )2 .
( Qmax ) ( 60 ) 3600

N = g 0 + g1 ⋅ ( Q* )2 ,
respectiv
N = 819 + 0,91 ⋅ ( Q* )2 ,
N1 = 819 + 0,91 ⋅ ( Q1* )2 = 819 + 0 ,91 ⋅ ( 45 )2 =

= 819 + 0,91 ⋅ 2025 = 2661,75 uCNA .
Observaţie
Către CNA se va transmite valoarea una dintre valorile N=2662 uCNA
sau, respectiv valoarea aproximată prin adaos (deoarece partea fracţionară este
mai mare decât 0,5).
189
Pentru SNTD temperatură cu structura ilustrată în figură se cunosc:

SNTD - caracteristică statică (CS) liniară
cu T , T * ∈ [0 ÷ 800] grd C ;
SRA-T - CM – liniară cu i ∈ [ 4 ÷ 20 ] mA;
CUI - CS – liniară cu u ∈ [ 0 ,2 ÷ 1 ]V ;
CNA - CS – liniară cu Nmax = 4095 uCNA,

u(0)=0, u(Nmin)= umin , u(Nmax)= umax;
ΔN max
ΔN = ⋅ ΔT * .
ΔTmax
QP TP
u N T*
TT
Qa QC CNA BC2
i
TC CUI
Să se determine:
a – relația asociată CS a CUI și graficul acesteia ;
b – rezoluția CNA și numărul minim Nmin de uCNA;
c – relația în valori absolute asociată CS a BC2 și graficul acesteia.
190
12-4.1.6 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 acesteia în domeniul declarat pentru respectiva
mărime a valorii rezultate în unităţi inginerești. 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 4.26 în interiorul domeniului
traductorului.
Domeniu Traductor
La încălcarea unei anumite categorii de limite 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 4.27, în interiorul domeniului
comenzilor valide.
Ymin Ymax Y
191

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
rutina a cărei schemă logică este ilustrată în figura 4.28.
Este important de subliniat că toate evenimentele semnificative aferente
testării mărimilor achiziţionate sau a comenzilor elaborate se înscriu in jurnalul
cu evenimente înscris în baza de date de proces (BDP).
RUTINA TESTARE COMANDA

CALCULATA
Y
Transfera
Ycalc
Preia din BDP

Ymin, Ymax
Da
Ycalc ≤ Ymin
Nu
Da
Ycalc ≥ Ymax
Nu
Transfera
Y
RETURN

a unei comenzi calculate Ycalc.
192
Rutina de testare este de regulă apelată în cadrul unui task care

implementează un algoritm de reglare, task ce furnizează comanda calculată
Ycalc. În urma testării este întoarsă comanda Y (care poate fi valoarea calculată
sau valoarea unei limite încălcate) ce urmează a fi aplicată elementului de
execuție.
Exerciţiul 9
Enumerați tipurile de limite cu care se compară valoarea unei mărimi
achiziționate.
Exerciţiul 10
Ce comandă se transmite EE la încălcarea unei limite de către valoarea
calculată a acesteia?
1. Enumerați operațiile de prelucrare primară a datelor achiziționate
și comenzilor elaborate.
2. Prin ce se caracterizează un filtru recursiv?
3. Scrieți relația recurențială pentru calculul valorii filtrate curente a
unui filtru nerecursiv.
4. Prin ce se implementează frontierele F1 și F2 la achiziția datelor
din proces?
5. Prin ce se implementează frontierele F1 și F2 la transmiterea
comenzilor către proces?
6. Enumerați componentele unui SNMD.
7. Enumerați componentele unui SNTD.
8. Justificați necesitatea conversiei în unități inginerești în cadrul
unui SNMD.
9. Justificați necesitatea conversiei din unități inginerești în cadrul
unui SNTD.
10. Ce presupune exprimarea prin variații a unei mărimi?
11. Ce implică validarea unei mărimi achiziționate?
12. Ce implică validarea unei comenzi elaborate?
193
Rezumat
Unui proces i se asociază obiective de calitate, eficiență, securitate.
Prin conducere, procesul este dirijat pentru a realiza aceste obiective.
În circuitul informațional asociat sistemului de conducere a unui proces
tehnologic sunt identificate pe fiecare dintre cele două canale (transmitere
date, respectiv transmitere comenzi) frontierele F1 și F2.
La nivelul frontierei F1 au loc conversii de formă – din analogic în
numeric la transmiterea datelor și din numeric în analogic la transmiterea
comenzilor. Frontiera F1 este implementată prin Convertoare Analog
Numerice (CAN) pe canalul de transmitere a datelor și prin Convertoare
Numeric Analogice (CNA) pe canalul de transmitere a comenzilor.
La nivelul frontierei F2 au loc conversii de conținut – din unități CAN
în unități inginerești (fizice) la transmiterea datelor și din unități inginerești
(fizice) în unități CNA la transmiterea comenzilor. Frontiera F2 este
implementată prin blocuri (module) de calcul și anume: BC1 pe canalul de
transmitere a datelor și BC2 pe canalul de transmitere a comenzilor.
Procesarea primară încadrează următoarele operații;
- conversia datelor achiziționate din unități CAN în unități fizice
(inginerești);
- conversia comenzilor elaborate din unități fizice (inginerești) în
unități CNA;
CAN și BC1 se consideră incluse într-un Sistem Numeric de Măsurat la
Distanță (SNMD).
CNA și BC2 se consideră incluse într-un Sistem Numeric de
Transmitere a comenzilor la Distanță (SNTD).
194

1. Enunț
Te_F;
Rezolvare
Inițializare task
TASK_FILT
SEMEX=1, valori iniţiale pentru N,Z(i)
YFC, YFA,YFAI, XAC, XAI
Nu
∆t=Te_F?
Da
P(SEMEX)
Preia din BDP

XAC
V(SEMEX)
XAI=Z(N) YFA=YFC
i=N V(SEMEX)
Z(i)=Z(i-1)
Transferă în BDP
YFC
i=i-1
Nu P(SEMEX)
i=1?
YFC=YFA+(XAC-XAI)/N
Z(1)=XAC
Da
195

2. Enunț

cu T , T * ∈ [0 ÷ 100] grd C ;

ΔTmax
ΔT * = ⋅ ΔN .
ΔN max
Qi
i
N T*
Qat TT R u
CAN BC1
T
Qe
Să se determine:
(în mA);
196

Rezolvare
umax 5
umax = R ⋅ imax  R = = = 250 Ω ;
imax 20 ⋅10−3
umin 1
umin = R ⋅ imin  imin = = = 0 ,004 A = 4 mA .
R 250
b – pentru CAN cu caracteristica ilustrată în figura de mai jos
N
Nmax
Nmin
U
Umin Umax
se poate scrie
N min
N= ⋅ u , de unde rezultă
umin
N min 819
N max = ⋅ umax = ⋅ 5 = 4095 uCAN .
umin 1
Pe de altă pentru un CAN
N max = 2n − 1 n = log 2 ( N max + 1 ) = log 2 4096 =12 biti .
ΔTmax ΔN max
c – din relația ΔT * = ⋅ ΔN rezultă ΔN1 = ⋅ ΔT1* ,
ΔN max ΔTmax
sau înlocuind valorile numerice
197
N max − N min
N1 − N min = ⋅ ( T1* − Tmin ) sau
Tmax − Tmin
4095 − 819
N1 − 819 = ⋅ ( 75 − 0 ) de unde
100 − 0
3276 ⋅ 75
N1 = 819 + = 3276 uCAN
100
3. Enunț
Pentru SNTD temperatură cu structura ilustrată în figură se

cunosc:
cu T , T * ∈ [0 ÷ 800] grd C ;
ΔN max
ΔN = ⋅ ΔT * .
ΔTmax
QP TP
u N T*
TT
Qa QC CNA BC2
i
TC CUI
Să se determine:
198

Rezolvare
a – ecuația liniară asociată CS a CUI este
i = a0 + a1 ⋅ u.
Știind că i(0,2)=4 și i(1)=20 rezultă a0=0 și a1=20, iar ecuația CS a CUI

devine
i = 20 ⋅ u.
al gărui grafic este reprezentat în figura de mai jos.

i[mA]
20
u[V]
0,2 1
b - pentru un CNA (ca şi în cazul CAN) se cunoaşte că


CNA ilustrată în figura de mai jos.
U
Umax
Umin
N
Nmin Nmax
199
Această caracteristică statică poate fi descrisă de relaţia

umin u
u= ⋅ N sau umax = min ⋅ N max ,
N min N min
de unde rezultă
N max 4095
N min = ⋅ umin = ⋅ 0,2 = 819 uCNA .
umax 1
b – din relația pentru BC2

ΔN max
ΔN = ⋅ ΔT * rezultă
ΔTmax
4095 − 819
N − 819 = ⋅ ( T * − 0 ) sau
800 − 0
N = 819 + 4,095 ⋅ T * , relație reprezentată în figura de mai jos
N[UCNA]
4095
819
T[grd C]
0 800
Bibliografie
1. Diaconescu E., Achiziţii de date şi instrumentaţie. Fundamente hardware,
Bucureşti, Editura MatrixRom, 2006.
2. Paraschiv N., Achiziţia şi prelucrarea datelor, Editura Universităţii Petrol-

200
MODULUL DE STUDIU 4
Taskuri asociate unor algoritmi uzuali de reglare numerică
13-4.2.1 Taskuri asociate unui sistem de reglare automată cu regulator
Proporțional Integrator Derivator (PID)
13-4.2.2 Taskuri asociate unui sistem de reglare automată
cu regulator bipozițional
- cum se obține forma discretizată a expresiei pentru calculul comenzii
unui regulator PID;
- care este diferența între forma pozițională și cea recurențială
(incrementală) a expresiei discretizate pentru calculul comenzii unui
regulator PID;
- cum se construiește un task pentru implementarea unui regulator PID;
- ce funcții pot fi încredințate taskului prin care poate fi operat regulatorul
PID ;
- cum poate fi implementat printr-un task un algoritm de reglare
bipozițional ;
- cum poate fi implementată comunicarea între taskul de reglare și cel de
operare.
- deduci forma discretizată a unui algoritm continuu de reglare;
- să deduci forma recurențială pornind de la forma discretizată
pozițională;
- implementezi în cadrul unui task un regulator bipozițional;
- construiești taskuri de operare ale taskurilor reglare.
testării încadrării între limite a datelor achiziționate, respectiv a
comenzilor calculate .
201
Din examinarea figurii 1.10 (UI 2-1.2) rezultă existența modulului

elaborare comenzi (MEC) care implementează în format numeric algoritmii de
reglare. În cele ce urmează se prezintă taskurile asociate pentru doi astfel de
algoritmi și anume Proporțional Integrator Derivator (PID), respectiv
Bipozițional (BP).
13-4.2.1 Taskuri asociate unui sistem de reglare automată cu

regulator Proporțional Integrator Derivator (PID)
Se cunoaște expresia comenzii unui regulator PID în formă continuă
 1
t
de 
 e( τ )dτ + Td  ,
u = u0 + Kp e +
 Ti  dt 
(4.64)
 0 
unde: u este comanda curentă;

u0 - comanda în absența abaterii;
e – abaterea;
Kp – factor de amplificare (BP = 100/Kp - bandă de
proporționalitate);
Ti – timp de integrare;
Td – timp de derivare.
Uzual parametrii Kp (BP) , Ti și Td sunt cunoscuți ca parametri de
acordare. Din relația (4.64) rezultă că mărimea de comandă u este proporțională
cu abaterea, cu integrala abaterii în timp și cu derivata acesteia în raport cu
timpul.
Exerciţiul 1
Care sunt constantele de proporționalitate în relația (4.64)?
Cele trei componente au următoarele roluri:

- componenta proporțională – asigură o viteză ridicată de răspuns;
- componenta integratoare – asigură eliminarea abaterii staționare;
- componenta derivatoare – asigură un exces de comandă.
Exerciţiul 2
Care sunt rolurile componentelor P , I, D într-un algoritm PID?
Pentru a putea fi implementat pe un echipament numeric (regulator

numeric, sistem distribuit) relația (4.64) trebuie discretizată.
202
O formă discretizată pentru un pas k este a relației (4.64) este

 T k Td 
u k = u0 + Kp  ek +  e j + (ek − ek −1 )  , (4.65)
 Ti j =1 T 
 
unde T reprezintă intervalul de discretizare.
În relația (4.65) pentru exprimarea integralei pe un orizont de timp t în
formă numerică (discretizată) s-a utilizat metoda dreptunghiurilor. Conform
acestei metode integrala definită se aproximează prin suma ariei unor
dreptunghiuri care au înălțimea ej și lățimea T.
În ceea ce privește derivata, în format numeric aceasta se exprimă ca
raport al diferenței abaterilor pentru doi pași consecutivi ( ek – ek-1 ) și intervalul
de timp T .
Exerciţiul 3
Cum se implementează componentele I și D în formă discretizată?
Expresia (4.65) constituie forma absolută (pozițională) a algoritmului PID

în exprimare discretă (numerică). Pentru evitarea calculului sumei la fiecare
evaluare a comenzii se va determina o formă recurențială, de tipul relațiilor (4.4)
și (4.5) din unitatea de învățare 12 (UI 12-4.1), deduse pentru un filtru numeric
nerecursiv.
În acest scop se va construi forma discretizată a relației (4.64) pentru pasul
k-1, respectiv
 T k −1 Td 
u k −1 = u0 + Kp  ek −1 +  e j + (ek −1 − ek −2 )  , (4.66)
 Ti j =1 T 
 
unde T păstrează semnificația din relația (4.65) .
Pentru obținerea formei incrementale (recurențiale) a algoritmului PID
discretizat relația (4.66) se scade din relația (4.65) și rezultă:
 T Td 
u k − u k −1= Kp ek − ek −1 + ek + ( ek − 2ek −1 + ek − 2 )  , (4.67)
 Ti T 
sau după unele grupări convenabile
 T Td   Td 
u k = u k −1+ Kp 1 + + ek + Kp  − 1 − 2 ek −1 +
 Ti T   T 
(4.68)
Td
+ Kp ek − 2 .
T
203
Din relația (4.68) se observă că valoarea uk pentru pasul curent al

comenzii depinde de valoarea acesteia aferentă pasului anterior uk-1 și de
valorile abaterii e pentru trei pași consecutivi, respectiv ek , ek-1, ek-2 .
Cu notațiile
 T Td 
UC = u k EC = e k CC = Kp 1 + + 
 Ti T 
 Td 
UA = u k −1 EA = e k −1 CA = Kp  − 1 − 2  (4.69)
 T 
Td
EA A = e k − 2 CAA = Kp
T
relația (4.69) devine
UC =UA + CC ⋅ EC + CA ⋅ EA + CAA ⋅ EAA . (4.70)

Pentru implementarea relației (4.70) aferentă determinării comenzii
regulatorului PID în formă incrementală se poate construi taskul REG_PID pe
baza schemei logice ilustrate figura 4.29 care prezintă următoarele
particularități:
- taskul REG_PID este sincronizat cu timpul, intervalul de execuție
fiind T, respectiv intervalul de discretizare din relațiile
(4.66)…(4.69);
- la inițializare SEMEX=1 după care se stabilesc valori inițiale pentru
UC, UA, EC, EA, EAA;
- referința I și coeficienții CC, CA, CAA se preiau dintr-o Bază de Date
de Proces (BDP) în cadrul unei secțiuni critice;
- pentru excluderea mutuală se utilizează semaforul binar SEMEX;
- mărimea de reacție R se preia de la traductorul T asociat SRA printr-
un sistem de interfață de intrare adecvat (SIA) în care se realizează și
conversia în unități compatibile cu cele în care se determină comanda
UC;
- abaterea curentă EC se determină cu relația EC=I-R;
- comanda calculată UC se transmite la elementul de execuție EE al
SRA printr-un sistem de interfață de ieșire adecvat (SEA) în care se
realizează și conversia din unități în determină comanda UC în unități
adecvate EE;
- pregătirea pentru pasul următor impune atribuirile UA=UC,
EAA=EA, EA=EC.
204
Initializare task
REG_PID
EA, EAA.
Nu
∆t=T?
Da
P(SEMEX)

I, CC, CA, CAA
V(SEMEX) EAA=EA
Preia R de la T prin SIA UA=UC
EC = I-R
UC =UA + CC ⋅ EC + CA ⋅ EA + CAA ⋅ EAA .
Transmite UC
la EE prin SEA
Fig. 4.29. Schema logică asociată taskului REG_PID.
Completați schema logică din figura 4.29 cu secvența comparare a
comenzii calculate UC cu limitele minimă Umin și maximă Umax
preluate într-o secțiune critică din BDP (se va utiliza figura 4.28 UI 12-
4.1). Excluderea mutuală se va implementa cu semaforul binar SEMEX.
205
Pentru operarea regulatorului PID se propune taskul COP_PID realizat

pe baza schemei logice ilustrate figura 4.30 care prezintă următoarele
particularități:
- taskul COP_PID este sincronizat cu un eveniment extern reprezentat
de apăsarea unei taste (sau acționarea unui buton virtual) ;
referința I și coeficienții CC, CA, CAA;
- pentru taste se stabilesc funcționalitățile descrise în tabelul de mai jos
Funcție
Tastă Efect
apelată
P Modif_Kp Modificare parametru de acordare Kp
I Modif_Ti Modificare parametru de acordare Ti
D Modif_Td Modificare parametru de acordare Td
R Modif_I Modificare referință I
E - Oprire task
Altă tastă - Fără efect
- după modificarea oricărui parametru de acordare se calculează

coeficienții CC, CA, CAA pe baza relațiilor (4.69);
- indiferent de modificare, coeficienții CC, CA, CAA și referința I se
transferă în BDP în cadrul unei secțiuni critice;
- pentru excludere mutuală se utilizează semaforul binar SEMEX;
- taskul poate fi oprit la apăsarea tastei E;
- apăsarea oricărei alte taste rămâne fără efect.
Exerciţiul 4
Cu ce se sincronizează taskul COP_PID?
206
Initializare task
COP_PID
pentru I, CC, CA, 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. 4.30. Schema logică asociată taskului
COP_PID.
EXIT
Completați schema logică din figura 4.30 cu funcțiile de modificare a
parametrilor Umax (la apăsarea tastei M) și Umin (la apăsarea tastei m).
207
Figura 4.31 ilustrează utilizarea BDP pentru comunicarea indirectă

dintre taskurile REG_PID și COP_PID.
I I
CC CC
CA CA
CAA CAA
COP_PID BDP REG_PID
Fig. 4.31. Ilustrarea comunicării dintre taskurile COP_PID și

REG_PID prin baza de date de process BDP.
În contextul celor prezentate în unitatea de învățare 6 (UI 6-2.4) taskul

COP_PID este task producător iar taskul REG_PID este task consumator.
Exerciţiul 4
Explicați, cu referire a figura 4.31, de ce BDP este considerată resursă
critică.
13-4.2.2 Taskuri asociate unui sistem de reglare automată 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
4.32 este prezentată structura unui SRA temperatură cu regulatorul TC de tip
bipozițional.
Qr T TT
Qr Tm
Tm
TC
Tref u T
2 EE Proces
TC m
1 K (W)
r
Tref TT
230 V
50 Hz
a) b)
Fig. 4.32. Scheme ale SRA temperatura bipozițional:
a - schema principială; b - schema de structură; 1 – încălzitor electric; 2 –
serpentină prin care circulă un agent care preia căldura; Tref, T - temperaturi
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 care preia
căldura; K – întrerupător.
208
Acest regulator va conecta (închiderea întrerupătorului K) sau după caz

va deconecta (deschiderea întrerupătorului K) î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 agentului care preia căldura Qr a prin serpentina 2.
Regulatorul TC prezintă o caracteristică neliniară de tip releu cu
hysterezis ilustrată în figura 4.33 și descrisă de relația (4.71).
u HYST
CON
DECON
T
Tmin Tref Tmax
Fig. 4.33. Caracteristica statică a unui regulator bipozițional cu hysterezis:

u – comandă; HYST – lățime a benzii de hysterezis, Ti – temperatură prescrisă;
Tmin, Tmax – limite minimă respectiv maximă asociate temperaturii reglate.
u = CON dacă T ≤ T min sau

[(T min < T < T max) si T (k − 1) = CON ];
respectiv (4.71)
u = DECON dacă T ≥ T max sau
[(T min < T < T max) siT (k − 1) = DECON ].
Observații
1. După cum se observă din figura 4.34 pentru Tmin < T < Tmax
comanda u poate avea una dintre valorile CON (corespunzătoare liniei roșii a
caracteristicii statice) respectiv DECON (corespunzătoare liniei albastre a
caracteristicii statice).
2. Pentru a înlătura această ambiguitate, în oricare dintre aceste
situații comanda va păstra valoarea corespunzătoare pasului anterior, respectiv
pentru T(k-1) din relația (4.71).
209
În relația (4.71) Tmin și Tmax se calculează cu relațiile

HYST
T min = Tref − ; (4.72)
2
HYST
T max = Tref + . (4.73)
2
unde HYST reprezintă lățimea benzii de hysterezis.
Exerciţiul 5
În ce situații este conectată, respectiv deconectată rezistența de
încălzire 1 din figura 4.33?
Exerciţiul 6
Cum influențează lățimea benzii de hysterezis precizia de reglare a
temperaturii?
Funcționarea SRA temperatură cu regulator bipozițional poate fi ușor

înțeleasă pe baza caracteristicilor dinamice ilustrate în figura 4.33. La cuplarea
sistemului, in situația To < Tref regulatorul va comanda conectarea rezistenței
de încălzire 1 (comanda CON).
Temperatura va începe să crească, iar in momentul in care va atinge
valoarea Tmax se va comanda deconectarea rezistenței de încălzire (comanda
DECON). Ca urmare, temperatura va începe sa scadă, iar la atingerea valorii
Tmin se va produce recuplarea rezistentei de încălzire.
u
CON
a)
DECON
t
T
Tmax
Tref
Tmin HYST
T0 b)
Fig. 4.34. 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.
210
Examinând caracteristica din figura 4.34a 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, datorită inerției procesului, temperatura va continua să
crească și după decuplarea rezistentei, respectiv va continua 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 care prezintă următoarele caracteristici
surprinse în schema logică a taskului ilustrată în figura 4.35 :
- taskul REG_BP este sincronizat cu timpul, intervalul de execuție fiind
Tcom ;
- la inițializare se face SEMEX=1 după care se stabilește valoarea
inițială pentru comanda calculată , care se atribuie comenzii U;
- valorile Tmin și Tmax se preiau dintr-o Bază de Date de Proces
(BDP) în cadrul unei secțiuni critice;
- pentru excluderea mutuală se utilizează semaforul binar SEMEX;
- mărimea de reacție se preia de la traductorul de temperatură asociat
SRA printr-un sistem de interfață de intrare adecvat (SIA) în care se
realizează și conversia în unități compatibile cu cele în care se
determină comanda UC;
- comanda calculată UC se transmite la elementul de execuție EE al
SRA printr-un sistem de interfață de ieșire adecvat (Subsistemul
Ieșirilor Numerice - SEN) în care se realizează și conversia din unități
în determină comanda UC în unități adecvate EE.
Observație
Analizând schema logică din figura 4.35 se observă că se poate comanda
închiderea întrerupătorului (comanda CON), deschiderea întrerupătorului
(comanda DECON) sau se poate menține starea acestuia dacă Tmin<T<Tmax.
211
Initializare task
REG_BP
iniţială UC pentru comanda U
Nu
∆t=Tcom?
Da
P(SEMEX)
Preia din BDP

Tmin, Tmax
V(SEMEX)
Achiziționează R prin
SIA și evaluează T
Nu Da
T ≤ Tmin?
Nu
T ≥ Tmax?
Da
UC = DECON UC= CON
Transmite UC la EE
prin SEN
Fig. 4.35. Schema logică asociată taskului REG_BP.
Pornind de la relațiile (4.72) și (4.73), scrieți relațiile pentru calculul
valorilor anticipate Tmin_a și Tmax_a cu considerarea valorii de
anticipare Tant și a figurii 4.34 b.. Adaptați schema logică din figura
4.35 astfel încât comenzile să se dea anticipat la valorile Tmax_a și
Tmin a.
212
Pentru operarea regulatorului BP se propune taskul COP_BP realizat pe

baza schemei logice ilustrate figura 4.36 care prezintă următoarele
particularități:
- taskul COP_BP este sincronizat cu un eveniment extern reprezentat
de apăsarea unei taste (sau acționarea unui buton virtual) ;
referința Tref, lățimea benzii de hysterezys HYST și pentru limitele
Tmin respectiv Tmax;
- pentru taste se stabilesc funcționalitățile descrise în tabelul de mai jos
Funcție
Tastă Efect
apelată
I Modif_Tref Modificare referință Tref
H Modif_HYST Modificare lățime bandă de hysterezis
E - Oprire task
Altă astă - Fără efect
- după modificarea parametrului HYST de acordare se calculează

valorile Tmin și Tmax pe baza relațiilor (4.72) și (4.73);
- indiferent de modificare, valorile limită Tmin și Tmax se transferă în
BDP în cadrul unei secțiuni critice;
- pentru excludere mutuală se utilizează semaforul binar SEMEX;
- taskul poate fi oprit la apăsarea tastei E;
- apăsarea oricărei alte taste rămâne fără efect.
Exerciţiul 7
Cum este sincronizat taskul COP_BP?
Completați schema logică din figura 4.36 cu funcția de modificare a
valorii de anticipare Tant la a apăsarea tastei A, urmată de recalcularea
valorilor pentru Tmin_a și Tmax_a.
213
Inițializare task
COP_BP
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. 4.36. Schema logică asociată taskului COP_BP.
Figura 4.37 ilustrează utilizarea BDP pentru comunicarea indirectă

dintre taskurile REG_BP și COP_BP.
Tmin Tmin
Tmax Tmax
COP_BP BDP REG_BP
Fig. 4.37. Ilustrarea comunicării dintre taskurile COP_BP și

REG_BP prin baza de date de proces BDP.
În contextul celor prezentate în unitatea de învățare 6 (UI 6-2.4) taskul

COP_BP este task producător iar taskul REG_BP este task consumator.
214
1. Deduceți forma discretizată recurențială pentru algoritmii de
reglare Proporțional – P și Proporțional Integrator – PI.
2. Indicați trei metode de discretizare a componentei integratoare.
3. Prin ce se caracterizează taskul REG_PID?
4. Prin ce se caracterizează taskul COP_PID?
5. Care dintre taskurile REG_PID și COP_PID se execută în buclă
infinită?
6. Cum comunică taskurile REG_PID și COP_PID?
7. Cine determină precizia de reglare a unui regulator BP?
8. Ce comandă va fi transmisă pentru T min < T < T max (figura
4.33)?
9. Prin ce se caracterizează taskurile REG_BP și COP_BP?
10. Care dintre taskurile REG_BP și COP_BP permite oprirea
aplicației?
11. Cum comunică taskurile REG_BP și COP_BP?
Rezumat
Dezvoltarea unui task pentru implementarea unui algoritm de reglare
continuu implică discretizarea relației pentru determinarea mărimii de
comandă, pentru acest algoritm.
Pentru algoritmul PID se impune exprimarea în format numeric a
tuturor celor trei componente: proporțională, integratoare, derivatoare.
Pentru implementare facilă se preferă exprimarea în formă recurențială.
S-a dedus o asemenea formă în care mărimea de comandă se determină numai
prin operații de adunare și înmulțire.
Taskul REG_PID este sincronizat cu timpul iar taskul de operare
COP_PID cu un eveniment extern legat de apăsarea unei taste. Cele două
taskuri comunică printr-o Bază de Date de Proces (BDP) care constituie o
resursă critică.
Al doilea algoritm pentru care se propune un sistem de taskuri este
algoritmul bipozițional (BP), pentru care mărimea de comandă are numai
două valori de tipul Conectat - Deconectat.
Taskul dezvoltat REG_BP este asociat unui SRA temperatură în care
este utilizat un regulator bipozițional.
Taskul REG_BP este sincronizat cu timpul iar taskul de operare
COP_BP cu un eveniment extern legat de apăsarea unei taste. Cele două
taskuri comunică printr-o Bază de Date de Proces (BDP) care constituie o
resursă critică.
Pentru realizarea excluderii mutuale aferente celor două sisteme de
taskuri REG_PID-COP_PID respectiv REG_BP-COP_BP este utilizat un
semafor binar inițializat cu valoarea 1.
215

1. Enunț
Completați schema logică din figura 4.29 cu secvența comparare a
comenzii calculate UC cu limitele minimă Umin și maximă Umax
preluate într-o secțiune critică din BDP (se va utiliza figura 4.28 UI 12-
4.1). Excluderea mutuală se va implementa cu semaforul binar
SEMEX.
Rezolvare
Initializare task
REG_PID
EA, EAA.
Nu
∆t=T?
Da
P(SEMEX)

I, CC, CA, CAA,
Umin, Umax
EAA=EA
V(SEMEX)
UA=UC
Preia R de la T prin SIA
EC = I-R
1 2
216
1 2
Da
UC≤ Umin
Nu
Da
UC ≥ Umax
Nu
U=Umin U=UC U=Umax
Transmite U
la EE prin SEA

2. Enunț
Completați schema logică din figura 4.30 cu funcțiile de modificare a
parametrilor Umax (la apăsarea tastei M) și Umin (la apăsarea tastei m).
217
Rezolvare
Initializare task
COP_PID
SEMEX=1, stabileşte valori iniţiale pentru
I, CC, CA, CAA, Umin, Umax.
Nu
Tast?
V(SEMEX)
Da
Da
P? Modif_ Kp
Transfera I,
Nu CC, CA, CAA,
Umin,Umax
Da
în BDP
I? Modif _Ti
Nu
Da P(SEMEX)
D? Modif_ Td
Nu
Calculează
CC, CA, CAA
Da
R? Modif_ I
Nu
Nu Da
M? Modif_ Umax
Da
Da
m? Modif _Umin
Nu Da
E? EXIT
218

3. Enunț
Pornind de la relațiile (4.72) și (4.73), scrieți relațiile pentru calculul a
valorilor anticipate Tmin_a și Tmax_a cu considerarea valorii de
anticipare Tant și a figurii 4.34 b.. Adaptați schema logică din figura
4.35 astfel încât comenzile să se dea anticipat la valorile Tmax_a și
Tmin_a.
Rezolvare
HYST HYST
T min_ a = Tref − + Tant ; T max = Tref + − Tant .
2 2
Initializare task
REG_BP
iniţială UC pentru comanda U
Nu
∆t=Tcom?
Da
P(SEMEX)
Preia din BDP

Tmin_a, Tmax_a
V(SEMEX)
Achiziționează R prin Transmite UC la EE

SIA și evaluează T prin SEN
Nu Da
T≤
Nu
T≥
Da
UC = DECON UC= CON
219

4. Enunț
Completați schema logică din figura 4.36 cu funcția de modificare a
valorii de anticipare Tant la apăsarea tastei A, urmată de recalcularea
valorilor
pentru Tmin_a și Tmax_a.
Rezolvare
Inițializare task
COP_BP
SEMEX=1, stabileşte valori iniţiale pentru
Tref, Tant, HYST, Tmin_a, Tmax_a.
Nu
Tast?
V(SEMEX)
Da
Da
I? Modif _Tref
Transferă
Nu
Tmin_a,
Da Tmax_a
H? Modif _HYST în BDP
Nu
Da
A? Modif _Tant
P(SEMEX)
Da
Nu
E? Calculează
Tmin_a, Tmax_a
Da
EXIT
220
Bibliografie
1. Diaconescu E., Achiziţii de date şi instrumentaţie. Fundamente hardware,
Bucureşti, Editura MatrixRom, 2006.
2. Paraschiv N., Achiziţia şi prelucrarea datelor, Editura Universităţii Petrol-

3. Paraschiv N., Introducere în automatică și calculatoare, Editura
5. Pătrășcioiu Cr., Popescu C., Calcul și metode numerice, Editura
6. Popescu C., Calcul și metode numerice. Lucrări de laborator, Editura
7. Pricop E., Zamfir F., Paraschiv N., Feedback control system based on a
remote operated PID controller implemented using mbed NXP LPC1768
development board, Proceedings of ACD 2015, Journal of Physics:
Conference Series; IOP Publishing: Pilsen, Czech Republic, 2015; Vol. 659,
p. 012028.
221
MODULUL DE STUDIU 4
Baze de date de proces
14-4.3.1 Cerințe impuse bazelor de date de proces
14-4.3.2 Tipuri de date incluse în bazele de date de proces
- rolul unei Baze de Date de Proces (BDP) în cadrul unui sistem numeric
de conducere;
- cerințele la care trebuie să răspundă un Sistem de Gestiune a unei BDP;
- ce presupune asigurarea securității, integrității și independenței datelor
dintr-o BDP;
- caracterul de resursă critică al unei BDP;
- ce tipuri de date pot fi incluse într-o BDP;
- ce operații pot fi efectuate asupra unei BDP;
- unde poate fi locată o BDP.
- construiești taskuri care să utilizeze o BDP ;
- să definești calitatea de producător , respectiv de consumator a unui
task în raport cu o BDP;
- să stabilești care dintre datele cu care operează un task pot fi preluate
dintr-o, respectiv înscrise într-o BDP.
14-4.3.1 Cerințe impuse bazelor de date de proces
În modulul de studii 1 (unitatea de învățare 2 UI 2-1.2) a fost evidențiată

Baza de Date de Proces – BDP în calitate de componentă a unui Sistem de
conducere în timp real (figura 1.10).
În general o bază de date (BD) reprezintă o mulţime de date organizate
după anumite criterii în scopul de a facilita prelucrarea acestora într-un anumit tip
de aplicaţii. Întrucât problemele generale care privesc BD au fost abordate în
cadrul disciplinei Baze de date, în prezenta unitate de învățare vor fi prezentate
223
aspecte referitoare la integrarea BD în structurile sistemelor de conducere în timp

real.
Aplicaţiile de conducere timp real impun prezenţa într-o bază de date
aferentă, printre altele, 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). În
contextul BDP, ca resurse ale sistemelor de conducere în timp real o importanță
esențială prezintă aplicațiile de actualizare (scriere) și de consultare (citire a
datelor Aplicaţiile care privesc actualizarea şi consultarea 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. În figura 1.10 din unitatea de învățare 2 (UI 2-1.2) actualizarea
datelor din BDP este realizată de către modulul MABDP , iar datele din BDP
sunt procesate în modulele de generare rapoarte – MGR și elaborare comenzi –
MEC. Prin intermediul consolei dedicate operatorul de proces are la dispoziție
rapoarte, care permit consultarea datelor din BDP.
Sistemele de Gestiune a Bazelor de Date (SGBD)54 reprezintă totalitatea
programelor utilizate pentru crearea, interogarea și întreținerea unei BD. Un
SGBD aferent unei BDP trebuie să răspundă următoarelor cerinţe importante:
- să respecte constrângerile impuse de prelucrarea datelor în timp
real;
• Cerința de să respectare a constrângerilor impuse de prelucrarea
datelor în timp real impune ca aplicaţiile care privesc actualizarea şi consultarea
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.
• 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.
54
Engl: Database Management System
224
• 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.
Exerciţiul 1
Ce este o bază de date de proces?
Exerciţiul 2
Ce care sunt cerințele impuse unui SGBD aferent unei BDP?
14-4.3.2 Tipuri de date incluse în bazele de date de proces
Într-o BDP sunt uzual cuprinse următoarele categorii de date:

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) limite de semnalizare și de blocare;
g) parametri de acordare a modelelor aferente automatizării avansate;
h) intervenţii ale personalului de operare, în cadrul jurnalelor de
intervenţii;
i) date privind funcţionalitate sistemului de conducere în timp real.
Exerciţiul 3
Enumerați categoriile de date aferente regulatoarelor după abatere care
trebuie înscrise într-o BDP.
225
În ceea ce privește operațiile aferente unei BDP , sunt de menționat

următoarele:
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, g 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 dispunerii, secţiuni ale BDP se pot găsi în
memoria primară sau secundară (pe harddisk-uri sau pe 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-uri 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.
În contextul programării multitasking BDP constituie resursă critică,
motiv pentru care accesarea acesteia se face în fiecare task utilizator în cadrul
unei secțiuni critice. Pentru implementarea excluderii mutuale pot fi implicate
semafoare, cutii poștale, variabile de tip eveniment etc. descrise în UI 4-2.2.
Exerciţiul 4
Enumerați principalele operații aferente utilizării unei BDP.
Adaptați schema logică aferentă taskului REG_PID (figura 4.29) astfel
încât să fie în concordanță figura 1.10 asociată din UI 2-1.2 (ilustrarea
unui Sistem de conducere în timp real). Explicați în ce constă
adaptarea.
226
1. Ce este o Bază de Date de Proces - BDP?
2. Explicați de ce o BDP este considerată o resursă critică în cadrul unei
aplicații de conducere în timp real?
3. Care este principala cerință impuse unui Sistem de Gestiune a unei
4. BDP (SG-BDP)?
5. În ce constă cerința de securitate a datelor impusă unui SG-BDP?
6. În ce constă cerința de integritate a datelor impusă unui SG-BDP?
7. În ce constă cerința de independență a datelor impusă unui SG-BDP?
8. Denumiți trei categorii de date care pot fi înscrise într-o BDP.
9. În ce constă funcția de structurare a unei BDP?
10. Ce tipuri de date aferente unei BDP sunt stocate în memoria primară
a echipamentului numeric de conducere?
11. Unde sunt locate datele aferente fișierelor istorice dintr-o BDP?
Rezumat
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)
Un SGBD aferent unei BDP trebuie să răspundă cerinţelor legate de :
respectarea constrângerilor aferente procesării în timp real, securitatea
datelor, integritatea datelor, independența datelor.
Într-o BDP pot fi înscrise mai multe categorii de date între care o
importanță deosebită prezintă cele care privesc istoricul procesului (valori
parametri, valori comenzi, evenimente, intervenții operator) și cele care
privesc echipamentele (adrese, parametri de acordare, regimuri de lucru);
Principalele operații (funcții) care au ca obiect BDP sunt cele care
privesc: structurarea BDP, încărcarea datelor, actualizarea datelor.
Din punct de vedere fizic secțiuni ale BDP sunt locate funcție de
taskurile care utilizează datele în memoria internă sau externă a
echipamentului numeric de conducere.
Din perspectivă multitasking o BDP se constituie într-o resursă critică,
utilizarea sa trebuind să se facă în cadrul secțiunilor critice în condițiile
excluderii mutuale..
227
Răspuns la testul de autoevaluare (continuare)

1. Enunț
Adaptați schema logică aferentă taskului REG_PID (figura 4.29) astfel
încât să fie în concordanță figura 1.10 asociată din UI 2-1.2 (ilustrarea
unui Sistem de conducere în timp real). Explicați în ce constă adaptarea.
Rezolvare
Initializare task
REG_PID
EA, EAA.
Nu
∆t=T?
Da EAA=UA
P(SEMEX)
EAA=EA
Preia din BDP
I, CC, CA, CAA
UA=UC
V(SEMEX)
V(SEMEX)
Preia R de la T prin SIA
Transferă în BDP
R și UC
EC = I-R
P(SEMEX)
Transmite UC
la EE prin SEA
228
Răspuns la testul de autoevaluare (continuare)

1.
Adaptarea a constă în transferul în BDP a mărimii achiziționate din
proces R și a comenzii calculate UC.
Bibliografie
2. Pătrașcu A., Baze de date – Unități de învățare, Universitatea Petrol-Gaze
din Ploiești, platforma E_learning, 2018.
229
MODULUL DE STUDIU 5
STUDIU SUPLIMENTAR
Unitatea de învăţare 15
Exerciții și teste de autoevaluare
15 - ES12 Exerciții suplimentarea pentru modulele de studiu 1 și 2
15 - TS12 Teste suplimentare de autoevaluare pentru modulele de studiu 1 și 2
15 - RS12 Răspunsuri la testele suplimentare de autoevaluare pentru
modulele de studiu 1 și 2
15 – ES34 Exerciții suplimentarea pentru modulele de studiu 3 și 4
15 – TS34 Teste suplimentare de autoevaluare pentru modulele de studiu 3 și 4
15 – RS34 Răspunsuri la testele suplimentare de autoevaluare pentru
- rolul exercițiilor și testelor pentru verificarea și consolidarea
cunoștințelor acumulate după parcurgerea celor 14 sinteze (unități de
învățare) care se pot constitui în tot atâtea referințe bibliografice;
- racordarea disciplinei Programarea Aplicațiilor de Timp Real (PATR)
cu alte discipline inginerești din planul de învățământ al specializării de
licență Automatică și Informatică Aplicată.
- verifici corectitudinea soluționării exercițiilor propuse;
- rezolvi probleme generate de aplicarea cunoștințelor acumulate în
cadrul disciplinei PATR.
231
15 - ES12 Exerciții suplimentarea pentru modulele de studiu 1 și 2
1. Care sunt obiectivele unui proces?

2. Care sunt funcţiile automatizării proceselor?
3. Care element din structura unui dispozitiv de automatizare asigură
funcţia de comandă?
4. Justificaţi denumirea alternativă timp util pentru noţiunea de timp
real.
5. Determinaţi frecvenţa minimă cu care trebuie achiziţionat un semnal
cu frecvenţa de 1 kHz pentru păstrarea consistenţei informaţionale.
6. Care sunt nivelurile de planificare a taskurilor în cadrul unui SOTR?
7. Denumiţi două tipuri de aplicaţii de timp real.
8. Ce este un SOTRM?
9. Care sunt obiectivele ingineriei programării în timp real?
10. Care sunt fazele din existenţa unui program (aplicaţii) de timp real?
11. Definiţi noţiunea de task.
12. Care sunt substările stării active?
13. Din ce substare a stării active este posibilă tranziţia în substarea
Execuţie?
14. După ce tranziţie se creează blocul descriptor al taskului?
15. Ce este o resursă critică?
16. Care sunt operaţiile fundamentale multitasking?
17. Ce este un semafor?
18. Ce este o cutie poştală?
19. Ce este o variabilă te tip eveniment?
20. Ce presupune excluderea mutuală a taskurilor?
21. Care sunt recomandările lui Tanenbaum pentru implementarea
excluderii mutuale?
22. Ce sunt taskurile disjuncte?
23. Explicaţi utilizarea semafoarelor la implementarea operaţiilor
multitasking excludere mutuală, sincronizare, comunicare.
24. Explicaţi utilizarea variabilelor de tip eveniment la implementarea
operaţiilor multitasking excludere mutuală, sincronizare,
comunicare.
25. Explicaţi utilizarea cutiilor poştale şi a mesajelor la implementarea
operaţiilor multitasking excludere mutuală, sincronizare,
comunicare.
232
15 - TS12 Teste suplimentare de autoevaluare pentru modulele de

studiu 1 și 2
1. Care este diferenţa dintre conducerea corectivă şi cea preventivă?

automată?
3. Care sunt funcţiile dispozitivului de automatizare din structura unui
SRA?
5. Care este diferenţa dintre prelucrarea paralelă şi cea pseudoparalelă?
6. În ce constă obiectivul de perceptibilitate al IPTR?
7. Prezentaţi etapa de analiză din dezvoltarea unei aplicaţii informatice.
9. Ce factori influenţează evoluţia unui sistem de taskuri interactive?
10. În ce situaţie se produce tranziţia Gata de execuţie – Blocat?
11. Ce entităţi intervin în definirea unui semafor în caz general?
12. În ce situaţie se produce blocarea unui task la execuţia unei operaţii
de tip P asupra unui semafor?
13. Ce operaţie se execută asupra unui semaforului implicat în
excluderea mutuală după ieşirea din secțiunea critică?
14. Ce presupune directiva AȘTEAPTĂ aplicată unei variabile de tip
eveniment.
15. Ce tip de mesaj se utilizează la excluderea mutuală implementată cu
utilizarea cutiilor poştale?
16. Explicaţi utilizarea cutiilor poştale pentru sincronizarea cu timpul?
execuţiei secţiunii critice?
mutuală pe durata execuţiei secţiunii critice?
19. Ce conţine o cutie poştală utilizată în excluderea mutuală în timpul
20. Care este diferenţa dintre comunicarea prin mesaje şi comunicarea prin
cutii poştale?
233
15 - RS12 Răspunsuri la testele suplimentare de autoevaluare pentru

1. Care este diferenţa dintre conducerea corectivă şi cea preventivă?

Rezolvare
În cadrul conducerii corective prin acţiunea comenzii este corectată o
diferenţă (eroare) dintre obiective şi realizări, în timp ce prin
conducerea preventivă, prin acţiunea comenzii se previne apariţia unei
asemenea diferenţe.

automată?
Rezolvare
Prin funcţia de protecţie automată este asigurat obiectivul de securitate
al unui proces.
3. Care sunt funcţiile dispozitivului de automatizare din structura

unui SRA?
Rezolvare
Funcţiile unui dispozitiv de automatizare sunt:
măsură, comandă, execuţie.

Rezolvare
Un sistem de conducere prezintă comportare în timp real atunci când
reacţia sa schimbările din proces este conformă cu inerţia acestuia.
5. Care este diferenţa dintre prelucrarea paralelă şi cea

pseudoparalelă?
Rezolvare
Prelucrarea paralelă, (posibilă la echipamentele cu mai multe UCP)
mai multe taskuri sunt în execuţie la un moment dat. Prelucrarea
pseudoparalelă presupune că un singur task se află în execuţie la un
moment dat (la sistemele cu o singură UCP).
6. În ce constă obiectivul de perceptibilitate al IPTR?

Rezolvare
Obiectivul de perceptibilitate 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ă
finalizare.
234
7. Prezentaţi etapa de analiză din dezvoltarea unei aplicaţii

informatice.
Rezolvare
Analiza reprezintă o etapă în care beneficiarul colaborează cu echipa
de analişti din partea elaboratorului produsului informatic, în vederea
identificării particularităţilor problemei care urmează a se rezolva.

Rezolvare
Taskurile disjuncte, spre deosebire de cele interactive, nu utilizează
resurse în comun şi nu fac schimb de date.
9. Ce factori influenţează evoluţia unui sistem de taskuri interactive?

Rezolvare
Evoluţia unui sistem de taskuri interactive, este influenţată de doi
factori şi anume:
- modul de efectuare a tranziţie între stări şi/sau substări.
10. În ce situaţie se produce tranziţia Gata de execuţie – Blocat?

Rezolvare
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.
11. Ce entităţi intervin în definirea unui semafor în caz general?

Rezolvare
În definirea unui semafor S intervin: o variabilă întreagă I şi o coadă
de aşteptare C: S=(I,C).
12. În ce situaţie se produce blocarea unui task la execuţia unei

operaţii de tip P asupra unui semafor?
Rezolvare
Blocarea se produce dacă variabila întreagă asociată semaforului este
mai mică sau egală cu zero.
13. Ce operaţie se execută asupra unui semafor implicat în excluderea
mutuală după ieşirea din secțiunea critică?
Rezolvare
La ieșirea dintr-o secţiune critică, asupra unui semafor implicat în
excluderea mutuală se execută operaţia V (incrementare).
235
14. Ce presupune directiva AȘTEAPTĂ aplicată unei variabile de tip

eveniment.
Rezolvare
Dacă E este o variabilă de tip EVENIMENT
ASTEAPTA( E )  Blocheaza taskul daca E = FALS ,
Continua executia daca E = ADEVARAT .
15. Ce tip de mesaje se utilizează la excluderea mutuală implementată

cu cutii poştale?
Rezolvare
Se utilizează mesaje simbolice.
16. Explicaţi utilizarea cutiilor poştale pentru sincronizarea cu timpul.

Rezolvare
În cazul sincronizării cu timpul se utilizează aşteptarea temporizată la o
cutie poştală vidă.

Rezolvare
Variabila întreagă din structura semaforului (implicit semaforul) are
valoarea 0 (zero) pe durata execuţiei secţiunii critice.

mutuală pe durata execuţiei secţiunii critice?
Rezolvare
Variabila de tip eveniment are valoarea FALS pe durata execuţiei
secţiunii critice.
19. Ce conţine o cutie poştală utilizată în excluderea mutuală în timpul

Rezolvare
Pe durata execuţiei unei secţiuni critice, cutia poştală implicată în
excluderea mutuală este vidă.
20. Care este diferenţa dintre comunicarea prin mesaje şi comunicarea

prin cutii poştale?
Rezolvare
În cazul comunicării prin mesaje trebuie precizat destinatarul, în timp ce
la comunicarea prin cutii poştale nu se impune această cerinţă.
236
15 – ES34 Exerciții suplimentarea pentru modulele de studiu 3 și 4
1. Care sunt cerinţele impuse unui Limbaj de Programare în Timp Real

(LPTR)?
2. Care sunt caracteristicile unui LPTR?
3. Care este numărul de priorităţi admise de nucleul de timp real RTK?
4. Definiţi noţiunea de task în context RTK.
5. Care sunt stările unui task în context RTK?
6. Când se găseşte un task în starea delaying?
7. Ce se realizează prin execuţia funcţiei RTKernelInit?
8. Denumiţi tipul de variabilă RTK prin care poate fi referit un task?
9. În ce tip de variabilă RTK este returnată o valoare corespunzând stării
taskului, după execuţia funcţiei RTKGetTaskState?
10. Ce valoare are cuanta de timp cu care operează nucleul RTK?
11. Scrieţi forma generală şi comentaţi efectul funcţiei RTKWait, aplicată
unui semafor?
12. Scrieţi forma generală şi comentaţi efectul funcţiei RTKGetCond
aplicată unei cutii poştale?
13. Scrieţi forma generală şi comentaţi efectul funcţiei RTKSendTimed
aplicată unui mesaj de trecere.
14. Ce este un filtru nerecursiv?
15. Care sunt operaţiile de prelucrare primară a datelor achiziţionate şi a
comenzilor elaborate?
16. Enumeraţi elementele din structura unui SNMD?
19. Enumeraţi elementele din structura unui SNTD?
20. Rezolvaţi problema din exemplul 4.3 pentru n=11 bit. .
21. Deduceţi relaţia pentru calculul comenzii unui regulator PID în formă
numerică.
22. Cum influenţează lăţimea benzii de hysterezis precizia de reglare a
unui regulator bipoziţional?
23. Ce este o bază de date de proces (BDP)?
24. În ce constă cerinţa de independenţă a datelor impusă unui Sistem de
Gestiune a unei BDP?
25. Enumeraţi cinci tipuri de date care pot fi incluse într-o BDP.
237
15 – TS34 Teste suplimentare de autoevaluare pentru modulele de

studiu 3 și 4
1. Care sunt aspectele vizate atunci când se vorbeşte de structurarea
unui limbaj de programare în timp real (LPTR)?
2. Scrieți funcţia RTK prin care un task cu Handler_Task este scos din starea
Suspended?
3. Scrieţi funcţia RTK pentru iniţializarea nucleului în care taskul main
are prioritatea 5 şi nu necesită un handler.
4. Care este rolul taskului Idle în context RTK?
5. În ce situaţie ajunge un task în starea BlockedPut?
6. Scrieţi funcţia RTK care să realizeze tranziţia taskului apelant în
starea Delaying pentru 4 secunde.
transmiterea comenzilor?
9. Când se consideră pregătit un task destinatar în contextul unei funcţii
de transmitere a unui mesaj?
11. Determinaţi Nmin și Nmax pentru un CAN cu rezoluţia de 12 biţi şi
caracteristica statică ilustrată în figura de mai jos
ΔN
ΔNmax=3276 uCAN
Δu
Δumax
12. Ce este un filtru nerecursiv cu mediere?

* Δx*max
SNMD: Δx = ⋅ Δx ,
Δxmax
Δimax
T: Δi = 2
⋅ ( Δx )2 ,
( Δxmax )
238
ΔN max
CIU+CAN: ΔN = ⋅ Δi .
Δimax
14. Pentru SNMD presiune reprezentat în figură se cunosc:
i
Qi P N P*
PT R u CAN BC1
Qe
LT - P , P* ∈ [ 0 ÷ 20 ] bar , imin = 4 mA;

CIU - R = 50 Ω, Umax=1 V, caracteristică statică liniară;
Să se determine:
c – valoarea P1* a presiunii pentru N1=1000 uCAN
Δymax
SNTD: Δy = *
⋅ Δy* ,
Δymax
Δymax
SRA: Δy = ⋅ Δi ,
Δimax
Δi
CNA+CUI: Δi = max ⋅ ΔN .
ΔN max
SNTD : caracteristică statică impusă liniară
SRA : Q ,Q* ∈ [ 0 ÷ 30 ] mc / h , caracteristică statică
CUI : u ∈ [ 1 ÷ 5 ]V , caracteristică statică liniară ;
CNA: Nmax = 1023 uCNA , caracteristică statică liniară.
239
N Q*
i u
CUI CNA BC2
FC
FT
Q
Să se determine:
a – rezoluția n şi Nmin şi pentru CNA;
b – relaţia de calcul BC2;
c – valoarea Q1* pentru N1 = 500 uCNA .
17. Indicaţi cu ce sunt sincronizate taskurile REG_PID şi COP_PID

19. Indicaţi cerinţele la care trebuie să răspundă un sistem de gestiune
(SG) a unei BDP .
20. În ce constă cerinţa de integritate a datelor impusă unui SG-BDP?
240
15 – RS34 Răspunsuri la testele suplimentare de autoevaluare pentru

1. Care sunt aspectele vizate atunci când se vorbeşte de

structurarea unui limbaj de programare în timp real?
Rezolvare
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.
2. Scrieți funcţia RTK prin care un task cu Handler_Task este scos

din starea Suspended?
Rezolvare
Prin funcţia RTKResume(Handler_Task);
3. Scrieţi funcţia RTK pentru iniţializarea nucleului în care taskul

main are prioritatea 5 şi nu necesită un handler.
Rezolvare
Forma funcţiei este RTKernelInit(3);
4. Care este rolul taskului Idle în context RTK?

Rezolvare
Taskul Idle se execută atunci când nici un task utilizator nu se află în
starea Current.
5. În ce situaţie ajunge un task în starea BlockedPut?

Rezolvare
După execuţia unei funcţii RTKPut asupra unei cutii poştale pline.
6. Scrieţi funcţia RTK care să realizeze tranziţia taskului apelant în

starea Delaying pentru 4 secunde.
Rezolvare
Funcţia este RTKDelay(72);

Rezolvare
Tipurile sunt: TaskHandle, TaskState, Time, Duration, Semaphore,
SemaType, Mailbox
241

transmiterea comenzilor?
Rezolvare
La achiziţia datelor prin modulul de calcul BC1 iar la transmiterea
comenzilor prin modulul de calcul BC2.
9. Când se consideră pregătit un task destinatar în contextul unei

funcţii de transmitere a unui mesaj?
Rezolvare
În contextul unei funcţii de transmitere a unui mesaj, taskul destinatar
referit prin handler este pregătit dacă se găseşte într-una din stările
BlockedReceive sau TimedReceive.

Rezolvare
Operaţiile de prelucrare primară a datelor de proces sunt:
- validarea mărimilor achiziționate și a comenzilor elaborate.
11. Determinaţi Nmin și Nmax pentru un CAN cu rezoluţia de 12

biţi şi caracteristica statică ilustrată în figura de mai jos
ΔN
ΔNmax=3276 uCAN
Δu
Δumax
Rezolvare
N max = 2n − 1= 212 − 1= 4096 −1= 4095 uCAN
ΔN max = N max − N min
N min = N max − ΔN max = 4095 − 3276 = 819 uCAN
12. Ce este un filtru nerecursiv cu mediere?

Rezolvare
Un filtru nerecursiv cu mediere reprezintă un filtru nerecursiv în care
coeficienţii h[k] sunt egali.
242
* Δx*max
SNMD: Δx = ⋅ Δx ,
Δxmax
Δimax
T: Δi = 2
⋅ ( Δx )2 ,
( Δxmax )
ΔN max
CIU+CAN: ΔN = ⋅ Δi .
Δimax
Rezolvare
ΔN max ΔN max Δimax
ΔN = ⋅ Δi = ⋅ 2
⋅ ( Δx )2
Δimax Δimax ( Δxmax )
Δ max
Δx = ⋅ ΔN
ΔN max
*Δx*max Δx*max Δxmax

Δx = ⋅ Δx = ⋅ ⋅ ΔN ,
Δxmax Δxmax ΔN max
Δx*max
*
BC1: Δx = ⋅ ΔN .
ΔN max
14. Pentru SNMD presiune reprezentat în figură se cunosc:
i
Qi P N P*
PT R u CAN BC1
Qe
LT - P , P* ∈ [ 0 ÷ 20 ] bar , imin = 4 mA;

CIU - R = 50 Ω, Umax=1 V, caracteristică statică liniară;
243
Să se determine:
c – valoarea P1* a presiunii pentru N1=1000 uCAN .
Rezolvare
umin = R ⋅ imin = 50 ⋅ 4 ⋅10−3 = 0 ,2 V ;
umax 1
imax = = = 0,02 A = 20 mA.
R 50
b - se determină pentru început valoarea Nmax apelând la caracteristica
statică a CAN ilustrată în figura de mai jos.
N
Nmax
Nmin
U
Umin Umax
Caracteristica statică liniară a CAN este descrisă de ecuaţia
N max − N min
N= ⋅u ,
umax − umin
de unde rezultă
N min 409 ,4
N max = ⋅ umax = ⋅ 1 = 2047 uCAN .
umin 0 ,2
n = log 2 ( N max + 1 ) = log 2 ( 2047 + 1 ) = log 2 2048 =11biti .
c – având în vedere datele din enunţ rezultă pentru modulul BC1

caracteristica statică liniară cu ecuaţia
P* = b0 + b1 ⋅ N ,
244
cu
Pmax ⋅ N min 20 ⋅ 409 ,4

b0 = − =− = − 5 bar ;
N max − N min 2047 − 409 ,4 ,6
Pmax 20
b1 = = = 0 ,012213 bar / uCAN .
N max − N min 2047 − 409 ,4
respectiv
P* = − 5 + 0 ,012213 ⋅ N ,
sau
P1* = − 5 + 0,012213 ⋅ N1 = −5 + 0,012213 ⋅ 1000 = 7, 213 bar.

condiţii:
Δymax
SNTD: Δy = *
⋅ Δy* ,
Δymax
Δymax
SRA: Δy = ⋅ Δi ,
Δimax
Δi
CNA+CUI: Δi = max ⋅ ΔN .
ΔN max
Rezolvare
ΔN max ΔN max Δimax

ΔN = ⋅ Δi = ⋅ ⋅ Δy
Δimax Δimax Δymax
ΔN max Δymax
ΔN = ⋅ * ⋅ Δy*
Δymax Δymax
ΔN max
BC2: ΔN = *
⋅ Δy* .
Δymax
245
SNTD : caracteristică statică impusă liniară
SRA : Q ,Q* ∈ [ 0 ÷ 30 ] mc / h , caracteristică statică
CUI : u ∈ [ 1 ÷ 5 ]V , caracteristică statică liniară ;
CNA: Nmax = 1023 uCNA , caracteristică statică liniară.
N Q*
i u
CUI CNA BC2
FC
FT
Q
Să se determine:
a – rezoluția n şi Nmin şi pentru CNA;
b – relaţia de calcul BC2;
c – valoarea Q1* pentru N1 = 500 uCNA .
Rezolvare
N max = 2 n − 1 n = log 2 ( N max + 1 ) =

a–
= log 2 ( 1023 + 1 ) = log 2 1024 =10 biţi .

CNA ilustrată în figura de mai jos.
u [V]
Umax = 5
Umin = 1
N[uCNA]
Nmin Nmax=1023
246
Caracteristica statică liniară de mai sus este descrisă de relaţia

umax − umin
u= ⋅N ,
N max − N min
de unde rezultă
N max 1023
N min = ⋅ u min = ⋅ 1 = 204 ,6 uCNA .
umax 5
b – se calculează coeficienţii g0 şi g2 din relaţiile (4.62) şi (4.63) după

cum urmează:
g 0 = N min = 204,6 uCNA ;
N max − N min 1023 − 204,6

g2 = = =
(Qmax ) 2 (30) 2
4 ⋅ 204,6
= 0,90933uCNA / ( mc / h) 2 .
900

N = g 0 + g1 ⋅ ( Q* )2 ,
respectiv
N = 204 ,6 + 0 ,90933 ⋅ ( Q* )2 .
c – din relaţia asociată BC2 rezultă
N − 204 ,6
Q* = .
0 ,90933
N1 − 204 ,6 500 − 204 ,6
Q1* = = =
0 ,90933 0 ,90933
500 − 204 ,6 295,4
= = = 324 ,854 =18,0237 mc / h
0 ,90933 0 ,90933
247
17. Indicaţi cu ce sunt sincronizate taskurile REG_PID şi COP_PID

Rezolvare
Taskul REG_PID este sincronizat cu timpul, iar taskul COP_PID cu
un eveniment extern reprezentat de apăsarea unei taste sau a unui
buton virtual.

Rezolvare
O BDP reprezintă o bază de date care conţine date organizate pentru
a fi utilizate în aplicaţii de conducere în timp real.
19. Indicaţi cerinţele la care trebuie să răspundă un sistem de

gestiune (SG) a unei BDP .
Rezolvare
Un SG-BDP trebuie să răspundă următoarelor cerinţe:
- să respecte constrângerile impuse de prelucrarea datelor în timp
real;
20. În ce constă cerinţa de integritate a datelor impusă unui SG-

BDP?
Rezolvare
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.
248
MODULUL DE STUDIU 3
DE TIMP REAL
Nucleul de timp real RTK – funcții de gestionare a mesajelor
de trecere
- ce reprezintă un mesaj de trecere în context RTK;
- cum se implementează operația de transmitere a unui mesaj de trecere
în context RTK;
- cum se implementează operația de recepție a unui mesaj de trecere în
context RTK;
BlockedSend, respectiv TimedSend;
BlockedReceive, respectiv TimedReceive;
- utilizezi funcțiile RTK pentru gestionarea mesajelor de trecere;
- utilizezi mesajele de trecere pentru sincronizarea taskurilor timpul ;
- utilizezi mesajele de trecere pentru sincronizarea taskurilor cu
evenimente externe;
- utilizezi mesajele pentru comunicarea între taskuri.

După cum a reieșit din unitatea de învățare 10 (UI 10-3.4) prin cutii
poștale se poate realiza o comunicare indirectă între taskuri. În aceste condiții un
task expeditor nu trebuie să indice taskul destinatar ci cutia poștală implicată în
comunicare.
Mesajul de trecere (passing message) reprezintă o facilitate de
comunicare directă între taskuri oferită de nucleul RTK. Caracterul direct este
indicat de faptul că spre deosebire de comunicarea prin cutii poștale, taskul
expeditor trebuie să refere taskul destinatar. În aceste condiții, pentru ca un task
să poată fi indicat ca task destinatar trebuie să i se asocieze un handler48. În ceea
ce privește taskul destinatar, recepția unui mesaj de trecere nu presupune
48
Rolul unui handler este evidențiat în UI 8-3.2.
149
cunoașterea expeditorului. Cu alte cuvinte, nu se impune asocierea unui handler

unui task pentru ca acesta să poată expedia (trimite) un mesaj de trecere
O altă diferență între cele două modalități de comunicare constă în
absența unui buffer de date în cazul mesajelor de trecere. În aceste condiții în
RTK nu există un tip predefinit pentru mesajele de trecere, ca în cazul
semafoarelor și cutiilor poștale.
Exerciţiul 1
Care este deosebirea dintre comunicarea prin cutii poștale și
comunicarea prin mesaje de trecere?

Având în vedere trăsăturile de mai sus, nucleul RTK pune la dispoziția
utilizatorilor numai funcții pentru transmiterea respectiv recepția mesajelor. Ca și
în cazurile semafoarelor și cutiilor poștale aceste instrucțiuni pot fi necondiționate,
condiționate și temporizate. În cele ce urmează vor fi prezentate caracteristicile
semnificative ale acestor funcții.
 În contextul unei funcţii de transmitere a unui mesaj, taskul
destinatar referit prin handler este pregătit (TDP) dacă se găseşte într-una din
stările BlockedReceive sau TimedReceive.
• Funcţia de transmitere necondiţionată este RTKSend care are
formă generală
void RTKSend(TaskHandle Handler_rec,void *Var_dep); (3.31)
Dacă taskul destinatar este pregătit (TDP) funcţia se execută şi taskul în
care este apelată funcţia îşi continuă rularea. Dacă taskul destinatar nu este
pregătit (TDNP), funcţia nu se execută, iar taskul apelant trece în starea
• Funcţia de transmitere condiţionată este RTKSendCond care
bool exec RTKSendCond(TaskHandle Handler_rec,
150
Dacă TDP funcţia se execută, taskul în care este apelată funcţia îşi
True.
Dacă TDNP, funcţia nu se execută, taskul apelant nu se blochează, iar
în variabila exec de tip bool se înscrie valoarea logică False.
Exerciţiul 2
În ce situație se produce tranziția unui task în starea BlockedSend?
• Funcţia de transmitere temporizată este RTKSendTimed care

bool exec RTKSendTimed(TaskHandle Handler_rec,
în care parametrul Handler_rec este handler al taskului destinatar,
urmează a fi transmis, iar Timp_astept , un interval de aşteptare (specificat în
ticks).
Dacă TDP, funcţia se execută, taskul în care este apelată funcţia îşi
logică True.
Dacă TDNP, funcţia nu se execută, iar taskul apelant trece în starea
TimedSend, pentru un interval cel mult egal cu Timp_aștept.
Dacă în timpul de aşteptare specificat (Timp_astept), taskul
destinatar devine disponibil (TDP), funcţia se execută, taskul iese din starea
TimedSend, iar în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat taskul destinatar nu devine disponibil
(TDNP), funcţia nu se execută, taskul iese din starea TimedSend, iar în variabila
Exerciţiul 3
În ce situații, după execuția unei funcții RTKSendTimed variabilei
 În contextul unei funcţii de recepţie a unui mesaj, un task expeditor

ce referă destinatarul prin handler este pregătit (UTEP) dacă se găseşte într-una
din stările BlockedSend sau TimedSend.
• Funcţia de recepție necondiţionată este RTKReceive care

151
void RTKReceive(void *Var_rec, unsigned Lung_mes ); (3.34)

recepţionează.
care este apelată funcţia îşi continuă rularea. Dacă nici un task expeditor nu este
pregătit (NUTEP), funcţia nu se execută, iar taskul apelant trece în starea
Exerciţiul 4
În ce situație se produce tranziția unui task în starea Blocked RECEIVE
• Funcţia de recepție condiţionată este RTKReceiveCond

bool exec RTKReceiveCond(void *Var_rec,
recepţionează.
care este apelată funcţia îşi continuă rularea, iar în variabila exec de tip bool
se înscrie valoarea logică True.
Dacă NUTEP, funcţia nu se execută, taskul apelant nu se blochează,
iar în variabila exec de tip bool se înscrie valoarea logică False.
• Funcţia de recepție temporizată este RTKReceiveTimed

bool exec RTKReceiveTimed(void *Var_rec,
unsigned Lung_mes, Duration Timp_astept); (3.36)
recepționat, Lung_mes este lungimea în octeţi a mesajului care se
recepţionează, iar Timp_astept , un interval de aşteptare (specificat în ticks).
Dacă UTEP, funcţia se execută, taskul în care este apelată funcţia îşi
logică True.
Dacă NUTEP, funcţia nu se execută, iar taskul apelant trece în starea
TimedReceive, pentru un interval cel mult egal cu Timp_aștept.
152
Dacă în timpul de aşteptare specificat (Timp_astept), un task

expeditor devine disponibil (UTEP), funcţia se execută, taskul iese din
starea TimedReceive, iar în variabila exec se înscrie valoarea logică True.
Dacă în intervalul de timp specificat NUTEP , funcţia nu se execută,
taskul iese din starea TimedReceive, iar în variabila exec se înscrie valoarea
logică False.
Exerciţiul 5
În ce situații, după execuția unei funcții RTKReceiveTimed
variabilei exec i se atribuie valoarea True?
Știind că:
taskului T2
T1;
Exemplul 3.7
În acest exemplu se prezintă utilizarea mesajelor de trecere pentru
comunicarea între două taskuri. Sistemul multitasking este constituit din
taskurile Task_ora, Task_dest şi main.
• Taskul Task_ora are aceleaşi caracteristici şi funcţionalitate ca
în exemplele 3.4, 3.5 și 3.6.
• Taskul Task_dest 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 Task_dest a fost referit prin handlerul asociat
Handle_dest în taskul emițător. După recepția mesajului sub forma unui
caracter, acesta este tipărit în coordonate prestabilite, însoțit de mesajul
Dest a recepționat.
secţiune de declaraţii şi iniţializări şi o a doua secţiune în buclă infinită
153
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 Task_dest î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.
//
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
struct date d;
struct time t;
//
//
//
afordata(void)
{
}
//
//

{
{
} //sfarsit for
//
//
154
Task_dest(void) //task receptor

{
char j2;
{
gotoxy (5,8);
} //sfarsit TaskB
//
//
{
char c, j1=’0’;
int i;
RTKeybrdInit(void);
// creare TaskA si TaskB
Handler_dest=RTKCreateTask(Task_dest,7,1024,"Dest");
//
{
//
{
j1++;
gotoxy(5,10);
RTKDelay(18);
//
exit(0); //iesire
} //sfarsit main
155
1. Ce reprezintă un mesaj de trecere în context RTK?
2. Când un task se consideră pregătit pentru transmiterea unui mesaj
de trecere?
3. Când un task se consideră pregătit pentru recepția unui mesaj de
trecere?
4. Care este diferența dintre funcțiile RTKSend și
RTKSendCond?
5. Care este diferența dintre funcțiile RTKReceive și
RTKReceiveCond?
6. Ce funcții trebuie să se execute pentru ca un task să execute
tranzițiile BlockedSend →Ready urespectiv BlockedReceive
→Ready?
7. Care dintre funcțiile RTKSend, RTKSendCond,
RTKSendTimed poate determina tranziția în starea
BlockedSend a taskului în care se execută?
8. Care dintre funcțiile RTKReceive, RTKReceiveCond,
RTKReceiveTimed poate determina tranziția în starea
BlockedReceive a taskului în care se execută?
9. Caracterizați funcția RTKSendTimed.
10. Caracterizați funcția RTKReceiveTimed.
156
Rezumat
În context RTK un mesaj de trecere reprezintă o facilitate de
comunicare directă între taskuri
Principalele funcții pentru gestionarea acestei facilități sunt cele de
transmitere respectiv de recepție a mesajelor.
Funcția de transmitere se prezintă în trei forme și anume:
necondiționată – RTKSend, condiționată – RTKSendCond, temporizată –
RTKSendTimed.
Funcția de recepție se prezintă de asemenea în trei forme și anume:
necondiționată – RTKReceive,condiționată – RTKReceiveCond,
temporizată – RTKReceiveTimed.
Legat de utilizarea mesajelor pot apărea două situații critice și anume:
task receptor nepregătit (nu se poate transmite un mesaj), task emițător
nepregătit (nu poaterecepționa un mesaj).
Stările unui task aferente situației critice legate de transmiterea unui
mesaj sunt BlockedSend, TimedSend.
Stările unui task aferente situației critice legate de recepția unui mesaj
sunt BlockedReceive, TimedReceive.

1. Enunț
Știind că:
taskului T2
T1;
Rezolvare
1.1 i=1;
1.2 gotoxy(32,5);
cprintf("i=%d",i);
157
1.3 RTKSend(Hand_dest,&i);
1.4 RTKReceive(&j,2);
1.5 gotoxy(32,6);
cprintf("j=%d",j);
2. Enunț
Rezolvare
//
#include <dos.h>
#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
//
TaskHandle Handler_T1;
struct date d;
struct time t;
//
afordata(void)
{
getdate(&d);
gettime(&t);
gotoxy(55,3);
}
//
//
Task_T0(void)
{
int i=1;
for(;;)
{
RTKDelay(18);
RTKSend(Hand_T1,&i);
}
}
158
//
Task_T1(void)
{
int j;
for(;;)
{
RTKReceive(&j,2);
afordata(void);
}
}
//
//
main(void)
{
char c;
RTKernelInit(3);
clrscr(void);
gotoxy(5,8);
RTKeybrdInit(void);
Handler_T1=RTKCreateTask(Task_T1,7,1024,"Task_sincr");
//
for(;;)
{
c=RTGetCh();
if(c==’E’)
exit(0);
}
}
Bibliografie
159
MODULUL DE STUDIU 4
Operații de prelucrare primară a datelor de proces
12-4.1.6 Validarea datelor achiziționate și a comenzilor elaborate
- necesitatea operațiilor de prelucrare primară a datelor de proces;
- ce este filtrarea numerică ;
- prin ce se caracterizează un filtru numeric nerecursiv ;
- funcționalitatea circuitului informațional specific unei aplicații de
conducere;
cadrul unui Sistem Numeric de Măsurat la Distanță (SNMD);
cadrul unui Sistem Numeric de Transmitere la Distanță (SNTD);
- ce presupune validarea datelor achiziționate și a comenzilor elaborate.
- deduci o relație recurentă pentru implementarea unui filtru numeric
nerecursiv;
- proiectezi modulul de conversii în unități inginerești (fizice) aferent
unui SNMD ;
- proiectezi modulul de conversii din unități inginerești (fizice) aferent
unui SNTD ;
testarea încadrării între limite a datelor achiziționate, respectiv a
comenzilor calculate.

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
161
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ță impun profitabilitatea respectivului proces,
în condițiile unei piețe concurențiale.
• Obiectivele de securitate 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 unitate de învățare (sinteză) a modulului de studiu 4 (UI
12-4.1) este tratată problema procesării primare a informației preluate din proces
și a celei destinate procesului sub forma comenzilor.
Procesarea primară încadrează următoarele operații:
- conversia în unități fizice (inginerești) a datelor achiziționate;
- conversia din unități fizice (inginerești) a comenzilor elaborate;
- validarea datelor achiziționate și a comenzilor elaborate.
În figura 1.10 din unitatea de învățare 2 (UI 2-1.2) modulul MPDA
concentrează pentru datele achiziționate funcțiile de filtrare, conversie în unități
fizice, validare. În aceiași figură modulul MPCE realizează pentru comenzile
elaborate funcțiile care privesc conversia din unități fizice și validare.
 A doua unitate de învățare (sinteză) a acestui modul (UI 13-4.2)
prezintă taskurile asociate unor algoritmi de reglare numerică cu o arie largă de
răspândire.
 În a treia unitate de învățare (sinteză) (UI 14-4.3) 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
Exerciţiul 1
Exerciţiul 2
Enumerați operațiile de prelucrare primară a datelor achiziționate și a
comenzilor elaborate.
162

Î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 4.1.
x[n] y[n]
FILTRU
NUMERIC

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.
O categorie de filtre este reprezentată de cele cu nerecursive, pentru un
asemenea filtru valoarea filtrată la pasul n, respectiv y[n] , depinde de ultimele
N valori din secvența de intrare x[n] potrivit relației49
N −1
y[n] =  h[k ] ⋅ x[n − k ], (4.1)
k =0
Din relația (4.1) rezultă că practic valoarea filtrată se obține ca medie

ponderată a ultimelor N valori din secvența de ieșire, coeficienții h[k]
reprezentând ponderi. 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 aritmetică şi relaţia (4.1) devine
N −1
1
y[n] =
N
 x[n − k ], (4.2)
k =0
unde N reprezintă ultimele N valori din secvența de intrare.
Pentru e evita calculul sumei la fiecare execuție a taskului se va

determina o formă recurențială pentru relația (4.2). În acest scop prin
transpunerea acestei relații pentru pasul anterior, respectiv pasul n-1 rezultă:
49
Dacă valoarea filtrată depinde și de eșantioane din secvența de ieșire filtrul se numește
recursiv.
163
N −1
1
y[n − 1] =
N
 x[n − 1 − k ]. (4.3)
k =0
Scăzând relaţia (4.2) din relaţia (4.3) se obține

N −1 N −1
1 1
y[n] − y[n − 1] =
N
 x[n − k ] − N
 x[n − 1 − k ],
k =0 k =0
şi în urma câtorva transformări elementare rezultă
1
y[n] = y[n − 1] + ( x[n] − x[n − N ]). (4.4)
N
Relaţia (4.4) 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ă - x[n] şi cea din urmă cu N paşi - x[n-N]). Ca element suport
pentru determinarea valorii întârziate cu N paşi se poate utiliza o structură de tip
coadă reprezentată în figura 4.2.
x[n-N]
x[n-N]
x[n-(N-1)]
x[n-2]
x[n-1]
x[n]
x[n+1]

x[n-N din] relaţia (4.4).
- y[n] = YFC - valoare filtrată curentă;

- y[n-1] = YFA - valoare filtrată anterioară;
164
- x[n] = XAC - valoare achiziţionată curentă;

- x[n-N] = XAI - valoare achiziţionată întârziată,
YFC = YFA + ( XAC − XAI ) / N , (4.5)
uşor de implementat atât în logică de tip programat, cât şi cablat.

Te_F;
Într-o aplicaţie de conducere în timp real, de tipul celei din figura 1.10,
(UI 2-1.2) poate fi evidenţiată următoarea secvenţă de operaţii:
Realizarea acestei secvențe implică existenţa unui circuit informaţional
ilustrat în figura 4.3, în care procesul este reprezentat prin traductoare-T și
elemente de execuție - EE, iar echipamentul numeric prin porturi de intrare – PI
și porturi de ieșiri – PE.
165
F1 F2

T PI
Semnale uCAN uING Calcul și
analogice
PROCES generare
de la traductoare
comenzi
EE PE
Semnale uCNA uING
analogice
către elemente
de execuție

Se consideră că traductoarele generează semnale analogice, iar elementele

de execuție sunt acționate de către același tip de semnale. Întrucât procesarea
impune intrări în formă numerică și generează rezultate în aceiași formă, rezultă
necesitatea unei frontiere în care să se schimbe natura semnalelor. Aceasta
frontieră notată F1 în figura 4.3, este reprezentată de SIA (Subsistemul Intrărilor
Analogice) și de SEA (Subsistemul Ieșirilor Analogice) din structura sistemului
de interfață cu procesul50.
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
o conversie analog / numerică, iar 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 unități
CNA51 (uCNA).
O a doua frontieră evidenţiată în figura 4.3 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.
50
În cazul aparaturii inteligente de automatizare (Smart) această frontieră este situată la limita
respectivei instrumentații, iar transmiterea semnalelor se face în format digital.
51
CAN și CNA sunt abrevieri pentru Convertor Analog Numeric, respectiv Convertor Numeric
Analog.
166
Dacă frontiera F1 este asociată sistemului de interfață cu procesul (SIP),

frontiera F2 este asociată unor module de calcul specifice respectivelor conversii.
În figura 4.4 se prezintă circuitul informațional, în cadrul unei aplicații
de conducere, în care un regulator după perturbație (REG_PERT) elaborează un
semnal de comandă care se transmite sub forma referinței externe regulatorului
după abatere (REG_AB) integrat într-un SRA abatere În această figură deasupra
fiecărei săgeți este notată o mărime iar sub săgeată unitatea de măsură.
Structura din figura 4.4 asigură invarianța mărimii y252 la modificarea
perturbațiilor P2_1…P2_k. Mărimea de comandă a regulatorului după perturbație
REG_PERT este reprezentată de valoarea y1*, exprimată în unități inginerești
uING, care se aplică în calitate de referință unui SRA abatere, implicit
regulatorului REG_AB. În aceiași figură CUI și CIU reprezintă convertoarele
uP1
F2 F1
P2_1 P2_k P2_n
iP1
P* NP uP CIU1 TP1
V mA
PI BC1 CAN
uPk iPk
V CIUk TPk
REG uING uCAN
V
PERT mA
REG AB P2
u1
y1* N1 P1
i1 y1 SP2
PE CUI REG SP1
BC2 CNA AB EE
uING uCNA V r1
mA
TA y2 uING
y2i mA
uING
Analizând figura 4.4 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 de transmitere a
52
167
comenzii. În cele ce urmează vor fi prezentate elemente privind sinteza celor

două module (blocuri) de calcul.
Exerciţiul 3
Care este rolul frontierelor F1 și F2 în cadrul circuitului informațional
asociat unui sistem de conducere?
Exerciţiul 4
Prin ce se implementează frontierele F1 și F2 în cadrul circuitului
informațional asociat unui SRA ierarhizat?

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 4.5.
T CIU CAN BC1 SNMD
[uING] [mA] [V] [uCAN] [uING] [uING] [uING]
În figura 4.5 mărimile sunt reprezentate prin variaţii . Pentru o mărime z

care ia valori într-un domeniu [zmin, zmax] , respectiv z ∈ [ zmin , zmax ] se definesc
următoarele două tipuri de variaţii:
Δz = z − zmin , (4.6)
- variaţia maximă
- Δzmax = zmax − zmin . (4.7)
pentru SNMD o caracteristică statică liniară, ilustrată în figura 4.6.
Δx*
Δx*max

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

astfel încât pentru CIU rezultă o caracteristică liniară prezentată în figura 4.7 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 4.7 b.
Δu ΔN
ΔNmax
Δumax
a b

depinde numai de forma caracteristicii statice a traductorului T. În cele ce
urmează vor fi considerate două situaţii şi anume:
• Sinteza BC1 pentru un SNMD cu traductor liniar

În figura 4.8 este ilustrată caracteristica statică a unui traductor liniar
care se consideră inclus în SNMD.
Δi
Δimax

din structura SNMD.
Δxmax Δx
Caracteristicilor statice din figurile 4.6, 4.7 și 4.8 li se asociază următorul

sistem de ecuaţii în variații:
169
* Δx*max
SNMD: Δx = ⋅ Δx , (4.8)
Δxmax
Δimax
T: Δi = ⋅ Δx , (4.9)
Δxmax
Δumax
CIU: Δu = ⋅ Δi , (4.10)
Δimax
ΔN max
CAN: ΔN = ⋅ Δu . (4.11)
Δumax
BC1 relaţia
*
Δxmax
Δx* = ⋅ ΔN . (4.12)
ΔN max
Dacă în relația (4.12) se impune pentru mărimea x* (reprezentată în
memorie) acelaşi domeniu de variaţie ca pentru mărimea fizică (respectiv
Δx*max= Δxmax), rezultă
Δxmax
Δx* = ⋅ ΔN . (4.13)
ΔN max
Examinând relaţia (4.13) se observă că elementul BC1 este un element
liniar, a cărui caracteristică statică este reprezentată în figura 4.9.
Δx*
Δxmax

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 (4.13) se exprimă abaterile ţinând cont
de relaţiile (4.6) , (4.7) şi rezultă
xmax − xmin
x* − xmin = ⋅ ( N − N min ) . (4.14)
N max − N min
170
xmax ⋅ N min − xmin ⋅ N max xmax − xmin

x* = − + ⋅ N. (4.15)
sau
x* = a0 + a1 ⋅ N , (4.16)
unde
xmax ⋅ N min − xmin ⋅ N max

a0 = − ; (4.17)
N max − N min
xmax − xmin
a1 = . (4.18)
N max − N min
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 (4.15)
devine
xmax ⋅ N min xmax

x* = − + ⋅ N. (4.19)
sau
x* = b0 + b1 ⋅ N , (4.20)
unde
xmax ⋅ N min (4.21)

b0 = − ;
N max − N min
xmax (4.22)
b1 = .
N max − N min

171
• 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 4.10, astfel încât pentru
SNMD rezultă sistemul de ecuaţii (4.23)…(4.26).
Δi
Δimax

Δxmax Δx
* Δx*max
SNMD: Δx = ⋅ Δx , (4.23)
Δxmax
Δimax
T: Δi = 2
⋅ ( Δx )2 , (4.24)
( Δxmax )
Δumax
CIU: Δu = ⋅ Δi , (4.25)
Δimax
ΔN max
CAN: ΔN = ⋅ Δu . (4.26)
Δumax
BC1 ecuaţia
Δx*max
*
Δx = ⋅ ΔN , (4.27)
ΔN max
sau impunând pentru mărimea x* reprezentată în memorie acelaşi domeniu de
variaţie ca pentru mărimea fizică, respectiv (respectiv Δx*max= Δxmax), se obține
Δxmax
Δx* = ⋅ ΔN . (4.28)
ΔN max
Examinând relaţia (4.28) se observă că modulul BC1 corespunde unui
Este de remarcat faptul că neliniaritatea introdusă de BC1 compensează
172
neliniaritatea traductorului T, astfel încât pe ansamblu caracteristica statică a

SNMD să rezulte liniară.
Δx*
Δxmax

cu caracteristică statică neliniară de tip pătratic.
Δ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 (4.28)
se exprimă variațiile ţinând cont de relaţiile (4.6), (4.7) şi rezultă
xmax − xmin
x* − xmin = ⋅ ( N − N min ) . (4.29)
N max − N min
După efectuarea calculelor în relaţia (4.29), în situaţia xmin = 0 (frecvent
întâlnită în practică) se obţine,
N − N min
x* = xmax ⋅ . (4.30)
N max − N min
sau
2 2
* − N min xmax xmax
x = + ⋅N (4.31)
respectiv
x* = c0 + c1 ⋅ N , (4.32)
unde
2
N min ⋅ xmax
c0 = − ; (4.33)
N max − N min
2
xmax (4.34)
c1 = .
N max − N min
173

exprimare (prin variaţii sau prin valori absolute) modulul BC1 prezintă o
caracteristică statică neliniară care compensează neliniaritatea caracteristicii
traductorului T.
Exerciţiul 5
Ce elemente sunt incluse în structura unui SNMD?
Exerciţiul 6
Care este rolul BC1 în cadrul unui SNMD?
Exemplul 4.1
Pentru SNMD nivel cu structura ilustrată în figura 4.12 se cunosc:

SNMD - caracteristică statică (CS) liniară cu H , H * ∈ [200 ÷ 800] mm ;
LT - CS – liniară cu H ∈ [200 ÷ 800] mm , i ∈ [4 ÷ 20] mA ;
CAN - CS – liniară cu Nmax = 1023 uCAN, N(0)=0, N(umin)= Nmin,
N(umax)= Nmax .
Să se determine:
a – domeniul de valori al tensiunii (respectiv umin și umax) la
intrarea CAN;
c – valoarea numărului de cuante N1 în cazul
corespunzătoare unui unei valori a nivelului reprezentată
în memorie H1* = 400 mm .
Qi i
H H*
N
LT R u CAN BC1
Qe
174
Rezolvare
umin = R ⋅ imin = 250 ⋅ 4 ⋅10−3 =1V ;
umax = R ⋅ imax = 250 ⋅ 20 ⋅10−3 = 5V .

b – pentru un CAN se cunoaşte că N max = 2n − 1 de unde rezultă

N
Nmax

Nmin
U
Umin Umax
Caracteristica statică liniară din figura 4.13 este descrisă de ecuaţia
N max
N= ⋅u ,
umax
de unde rezultă
N max 1023
N min = ⋅ umin = ⋅ 1 = 204 ,6 uCAN .
umax 5
Se determină coeficienţii din relaţiile (4.17) şi (4.18) după cum urmează:

a0 = − =− = 50 mm;
N max − N min 1023 − 204,6
175
H m a x − H m in 800 − 200
a1 = = = 0 ,7 3 3 1 3 7 8 3 m m / u C A N .
N m a x − N m in 1 0 2 3 − 2 0 4 , 6

H * = a0 + a1 ⋅ N ,
respectiv
H * = 50 + 0,73313783 ⋅ N ,
de unde se obține
H * − 50
N= ,
0,73313783
respectiv
H1* − 50 400 − 50 350

N1 = = = = 477,4 uCAN .
0,73313783 0,73313783 0,73313783
Exemplul 4.2

SNMD - caracteristică statică (CS) liniară cu Q, Q* ∈ [0 ÷ 60] m3 / h ;
FT - CS – neliniară (pătratică) cu
Q ∈ [0 ÷ 60] m3 / h , i ∈ [4 ÷ 20] mA ;
CAN - CS – liniară cu rezoluția n=12 biți, N(0)=0, N(umin)= Nmin,
N(umax)= Nmax .
Să se determine:
a. – domeniul de valori al tensiunii la intrarea CAN, numărul

maxim (Nmax) și minim (Nmin) de uCAN ale acestuia;
b – valoarea Q1* a debitului reprezentat în memorie pentru
N1=2457 uCAN.
176
N Q*
u CAN BC1
i R
FT
Q
Fig. 4.14. Structura SNMD debit pentru exemplul
Rezolvare
umin = R ⋅ imin = 50 ⋅ 4 ⋅10−3 = 0,2 V ;
umax = R ⋅ imax = 50 ⋅ 20 ⋅10−3 =1V .
Pentru CAN cu caracteristica statică liniară din figura 4.13 (exemplul 4.1)
este descrisă de ecuaţia
N max
N= ⋅u ,
umax
de unde rezultă
N max 4095
N min = ⋅ umin = ⋅ 0 ,2 = 819 uCAN .
umax 1
b – în condiţiile problemei, coeficienţii c0 şi c1 se calculează după cum

urmează:
2
− N min ⋅ Qmax −819 ⋅ 3600
c0 = = = − 900 ( m3 / h )2 ;
N max − N min 4095 − 819
2
Qmax 3600
c1 = = =1,0989011( m3 / h )2 / uCAN .
N max − N min 4095 − 819
177
Cu aceşti coeficienţi, se obţine următoarea relaţie pentru modulul BC1

Q* = c0 + c1 ⋅ N = −900 + 1,0989011 ⋅ N ,
sau în condiţiile problemei
Q1* = −900 + 1,0989011 ⋅ 2457 = −900 + 2700 = 1800 = 42,426 m3 / h .

cu T , T * ∈ [0 ÷ 100] grd C ;

ΔTmax
ΔT * = ⋅ ΔN .
ΔN max
Qi
i
N T*
Qat TT R u
CAN BC1
T
Qe
Să se determine:
(în mA);
178

Aşa cum reiese din figura 4.4 în care se prezintă circuitul informaţional
într-un SRA ierarhizat, această conversie se realizează de către blocul BC2, parte
integrantă a unui sistem numeric de transmitere a comenzii la distanţă (SNTD)
cu structura evidenţiată în figura 4.15.
Δy* ΔN Δu Δi Δy Δy* Δy
[uING] [uCNA] [V] [mA] [uING] [uING] [uING]

la distanţă.
Ca şi la conversia în unităţi inginerești, mărimile sunt exprimate prin

variaţii, semnificaţiile tipurilor de variaţii fiind cele din relaţiile 4.6 şi 4.7.
pentru SNTD o caracteristică statică liniară ilustrată în figura 4.16.
Δy
Δymax

SNTD.
Δy*max Δy*
Atât pentru convertorul tensiune curent CUI, cât şi pentru cel analog
numeric CNA se presupun caracteristici statice liniare prezentate în figura 4.17.
Δi Δu
Δimax
Δumax
Δumax Δu ΔN
ΔNmax
a b
179

depinde numai de forma caracteristicii statice de măsură a Sistemului de Reglare
Automată (SRA)53.
În cele ce urmează vor fi considerate două situaţii şi anume:
- SNTD include SRA cu caracteristică de măsură (CM) de tip liniar;
- SNTD include SRA cu caracteristică de măsură (CM) de tip neliniar.
• Sinteza BC2 pentru un SNTD care include SRA cu CM liniară

În figura 4.18 este ilustrată caracteristica statică a unui SRA cu CM
Δy
Δymax

din structura SNTD.
Δi
Δimax
Caracteristicilor statice din figurile 4.16, 4.17 și 4.18 li se asociază

Δymax
SNTD: Δy = *
⋅ Δy* , (4.35)
Δymax
Δymax
SRA: Δy = ⋅ Δi , (4.36)
Δimax
Δimax
CUI: Δi = ⋅ Δu , (4.37)
Δumax
Δumax
CNA: Δu = ⋅ ΔN . (4.38)
ΔN max
53
În loc de SRA poate fi considerat un element de execuție EE.
180
Rezolvând sistemul format din ecuaţiile (4.35)…(4.38) se obține pentru

BC2 ecuaţia
ΔN max
ΔN = *
⋅ Δy* , (4.39)
Δymax
*
variaţie ca pentru mărimea fizică y (respectiv Δymax = Δymax ) rezultă
ΔN max
ΔN = ⋅ Δy* . (4.40)
Δymax
Examinând relaţia (4.40) se observă că modulul BC2 este corespunde unui
element liniar, a cărui caracteristică statică este reprezentată în figura 4.19.
ΔN
ΔNmax
CM liniară.
Δymax Δy*
Ca şi în cazul conversiei în unităţi inginereşti sunt situaţii care necesită

utilizarea relaţiei aferente modulului BC2 exprimată în valori absolute. Pentru a
obţine această formă, în ecuaţia (4.40) se exprimă variațiile ţinând cont de
relaţiile (4.6), (4.7) şi rezultă
N max − N min
N − N min = ⋅ ( y* − ymin ) . (4.41)
ymax − ymin
ymax ⋅ N min − ymin ⋅ N max N max − N min *
N= + ⋅y . (4.42)
ymax − ymin ymax − ymin
sau
N = d 0 + d1 ⋅ y* , (4.43)
181
unde
ymax ⋅ N min − ymin ⋅ N max (4.44)

d0 = ;
N max − N min
N − N min (4.45)
d1 = max .
ymax − ymin
O situaţie frecvent întâlnită în practică este aceea în care limita
inferioară a domeniului mărimii y este nulă, respectiv ymin = 0. În acest caz
ecuaţia (4.42) devine
N max − N min *
N = N min + ⋅y , (4.46)
ymax
sau
N = e0 + e1 ⋅ y* , (4.47)
unde
e0 = N min , (4.48)
N max − N min (4.49)
e1 = .
ymax

• Sinteza BC2 pentru un SNTD care include SRA cu CM neliniară
Pentru SNTD, CNA şi CUI se menţin în acest și caz caracteristicile liniare

prezentate în cazul SRA cu CM liniară.
În ceea ce priveşte SRA, pentru acesta se va considera o CM neliniară (de
tip radical) ilustrată în figura 4.20.
182
Δy
Δymax
Δi
Δimax
Caracteristicilor statice din figurile 4.16, 4.17 şi 4.20 li se asociază

Δymax
SNTD: Δy = *
⋅ Δy* , (4.50)
Δymax
Δymax
SRA: Δy = ⋅ Δi , (4.51)
Δimax
Δimax
CUI: Δi = ⋅ Δu , (4.52)
Δumax
Δumax
CNA: Δu = ⋅ ΔN . (4.53)
ΔN max
pentru BC2 ecuaţia
ΔN max
ΔN = * 2
⋅ ( Δy* )2 , (4.54)
( Δymax )
variaţie ca pentru mărimea fizică rezultă
ΔN max
ΔN = 2
⋅ ( Δy* )2 . (4.55)
( Δymax )
Examinând relaţia (4.55) se observă că modulul BC2 corespunde un
După cum se observă, prin această caracteristică este compensată neliniaritatea
caracteristicii de măsură a SRA.
183
ΔN
ΔNmax
neliniară de tip radical.
Δ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 (4.55)
se exprimă abaterile ţinând cont de relaţiile (4.6), (4.7) şi rezultă
N max − N min
N − N min = 2
⋅ ( y* − ymin )2 . (4.56)
( ymax − ymin )
N = f 0 + f1 ⋅ y* + f 2 ⋅ ( y* )2 , (4.57)
unde
N max − N min
f 0 = N min + 2
⋅ ( ymin )2 , (4.58)
( ymax − ymin )
N max − N min
f1 = −2 ⋅ ymin ⋅ , (4.59)
ymax − ymin
N max − N min
f2 = . (4.60)
( ymax − ymin )2
Dacă limita inferioară a domeniului mărimii y este nulă, respectiv
ymin = 0 , relaţia (4.60) devine
N = g 0 + g 2 ⋅ ( y* )2 , (4.61)
unde
g 0 = N min , (4.62)
N max − N min
g2 = . (4.63)
( ymax )2
184

exprimare (prin variaţii sau valori absolute) BC2 prezintă o caracteristică statică
neliniară care compensează neliniaritatea CM a SRA.
Exerciţiul 7
Ce elemente sunt incluse în structura unui SNTD?
Exerciţiul 8
Care este rolul BC2 în cadrul unui SNTD?
În continuare vor fi prezentate două exemple care tratează aspecte

referitoare la conversia din unităţi inginereşti.
Exemplul 4.3
Pentru SNTD nivel cu structura ilustrată în figura 4.22 se cunosc:

SNTD - caracteristică statică (CS) liniară cu H , H * ∈ [200 ÷ 800] mm ;
SRA - CM – liniară cu H ∈ [200 ÷ 800] mm , i ∈ [4 ÷ 20] mA ;
CNA - CS – liniară cu Nmax = 2047 uCNA, u(0)=0, u(Nmin)= umin,
u(Nmax)= umax .
Să se determine:
a – rezoluţia n a CNA și numărul minim Nmin de uCNA;
Qi i u N H*
CUI CNA BC2
LT LC
Qe
185
Rezolvare

U
Umax

Umin
N
Nmin Nmax

umax
u= ⋅N ,
N max
de unde rezultă
N max 2047
N min = ⋅ umin = ⋅ 1 = 409 ,4 uCNA .
umax 5
b – Se determină coeficienţii din relaţiile (4.44) şi (4.45) după cum

urmează:
d0 = = =
H max − H min 800 − 200
= − 136 ,466667 uCNA ;
N max − N min 2047 − 409 ,4

d1 = = = 2 ,72933333 uCNA / mm.
H max − H min 800 − 200
186

N = d0 + d1 ⋅ H * ,
respectiv
N = −136,466667 + 2,72933333 ⋅ H * ,
de unde rezultă
N + 136 ,466667
H* = .
2 ,72933333
Pentru N1=800 uCNA se obține
N1 + 136 ,466667 800 + 136 ,466667 936 ,466667

H1* = = = = 343,11mm.
2 ,72933333 2 ,7293333 2 ,72933333
Exemplul 4.4
Pentru SNTD debit cu structura ilustrată în figura 4.24 se cunosc:

SNTD - caracteristică statică (CS) liniară cu Q, Q* ∈ [0 ÷ 60] m3 / h ;
SRA - CM – neliniară (radical) cu
Q ∈ [0 ÷ 60] m3 / h , i ∈ [4 ÷ 20] mA ;
CNA - CS – liniară cu n = 12 biți, u(0)=0, u(Nmin)= umin,
u(Nmax)= umax .
Să se determine:
a – numerele Nmin şi Nmax de uCNA pentru CNA;
b – valorile coeficienților asociați exprimării relației pentru
BC2 în valori absolute;
c – valoarea N1 a numărului de uCNA pentru un debit calculat
Q1* = 45 m3 / h.
.
187
N Q*
i u
CUI CNA BC2
FC
FT
Q
Rezolvare
a – N max = 2n − 1= 212 − 1 = 4096 − 1 = 4095 uCNA .

u [V]
Umax = 2

Umin = 0,4
N[uCNA]
Nmin Nmax=4095

umax
u= ⋅N ,
N max
de unde rezultă
N max 4095
N min = ⋅ umin = ⋅ 0 ,4 = 819 uCNA .
umax 2
188
c – se calculează coeficienţii g0 şi g2 din relaţiile (4.62) şi (4.63) după

cum urmează:
g 0 = N min = 819 uCNA ;
N max − N min 4095 − 819 3276

g2 = 2
= 2
= = 0 ,91 uCNA / ( m3 / h )2 .
( Qmax ) ( 60 ) 3600

N = g 0 + g1 ⋅ ( Q* )2 ,
respectiv
N = 819 + 0,91 ⋅ ( Q* )2 ,
N1 = 819 + 0,91 ⋅ ( Q1* )2 = 819 + 0 ,91 ⋅ ( 45 )2 =

= 819 + 0,91 ⋅ 2025 = 2661,75 uCNA .
Observaţie
Către CNA se va transmite valoarea una dintre valorile N=2662 uCNA
sau, respectiv valoarea aproximată prin adaos (deoarece partea fracţionară este
mai mare decât 0,5).
189
Pentru SNTD temperatură cu structura ilustrată în figură se cunosc:

cu T , T * ∈ [0 ÷ 800] grd C ;

ΔN max
ΔN = ⋅ ΔT * .
ΔTmax
QP TP
u N T*
TT
Qa QC CNA BC2
i
TC CUI
Să se determine:
190
12-4.1.6 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 acesteia în domeniul declarat pentru respectiva
mărime a valorii rezultate în unităţi inginerești. 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 4.26 în interiorul domeniului
traductorului.
Domeniu Traductor
La încălcarea unei anumite categorii de limite 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 4.27, în interiorul domeniului
comenzilor valide.
Ymin Ymax Y
191

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
rutina a cărei schemă logică este ilustrată în figura 4.28.
Este important de subliniat că toate evenimentele semnificative aferente
testării mărimilor achiziţionate sau a comenzilor elaborate se înscriu in jurnalul
cu evenimente înscris în baza de date de proces (BDP).
RUTINA TESTARE COMANDA

CALCULATA
Y
Transfera
Ycalc
Preia din BDP

Ymin, Ymax
Da
Ycalc ≤ Ymin
Nu
Da
Ycalc ≥ Ymax
Nu
Transfera
Y
RETURN

a unei comenzi calculate Ycalc.
192
Rutina de testare este de regulă apelată în cadrul unui task care

implementează un algoritm de reglare, task ce furnizează comanda calculată
Ycalc. În urma testării este întoarsă comanda Y (care poate fi valoarea calculată
sau valoarea unei limite încălcate) ce urmează a fi aplicată elementului de
execuție.
Exerciţiul 9
Enumerați tipurile de limite cu care se compară valoarea unei mărimi
achiziționate.
Exerciţiul 10
Ce comandă se transmite EE la încălcarea unei limite de către valoarea
calculată a acesteia?
1. Enumerați operațiile de prelucrare primară a datelor achiziționate
și comenzilor elaborate.
2. Prin ce se caracterizează un filtru recursiv?
3. Scrieți relația recurențială pentru calculul valorii filtrate curente a
unui filtru nerecursiv.
4. Prin ce se implementează frontierele F1 și F2 la achiziția datelor
din proces?
5. Prin ce se implementează frontierele F1 și F2 la transmiterea
comenzilor către proces?
6. Enumerați componentele unui SNMD.
7. Enumerați componentele unui SNTD.
8. Justificați necesitatea conversiei în unități inginerești în cadrul
unui SNMD.
9. Justificați necesitatea conversiei din unități inginerești în cadrul
unui SNTD.
10. Ce presupune exprimarea prin variații a unei mărimi?
11. Ce implică validarea unei mărimi achiziționate?
12. Ce implică validarea unei comenzi elaborate?
193
Rezumat
Unui proces i se asociază obiective de calitate, eficiență, securitate.
Prin conducere, procesul este dirijat pentru a realiza aceste obiective.
În circuitul informațional asociat sistemului de conducere a unui proces
tehnologic sunt identificate pe fiecare dintre cele două canale (transmitere
date, respectiv transmitere comenzi) frontierele F1 și F2.
La nivelul frontierei F1 au loc conversii de formă – din analogic în
numeric la transmiterea datelor și din numeric în analogic la transmiterea
comenzilor. Frontiera F1 este implementată prin Convertoare Analog
Numerice (CAN) pe canalul de transmitere a datelor și prin Convertoare
Numeric Analogice (CNA) pe canalul de transmitere a comenzilor.
La nivelul frontierei F2 au loc conversii de conținut – din unități CAN
în unități inginerești (fizice) la transmiterea datelor și din unități inginerești
(fizice) în unități CNA la transmiterea comenzilor. Frontiera F2 este
implementată prin blocuri (module) de calcul și anume: BC1 pe canalul de
transmitere a datelor și BC2 pe canalul de transmitere a comenzilor.
Procesarea primară încadrează următoarele operații;
- conversia datelor achiziționate din unități CAN în unități fizice
(inginerești);
- conversia comenzilor elaborate din unități fizice (inginerești) în
unități CNA;
CAN și BC1 se consideră incluse într-un Sistem Numeric de Măsurat la
Distanță (SNMD).
CNA și BC2 se consideră incluse într-un Sistem Numeric de
Transmitere a comenzilor la Distanță (SNTD).
194

1. Enunț
Te_F;
Rezolvare
Inițializare task
TASK_FILT
SEMEX=1, valori iniţiale pentru N,Z(i)
YFC, YFA,YFAI, XAC, XAI
Nu
∆t=Te_F?
Da
P(SEMEX)
Preia din BDP

XAC
V(SEMEX)
XAI=Z(N) YFA=YFC
i=N V(SEMEX)
Z(i)=Z(i-1)
Transferă în BDP
YFC
i=i-1
Nu P(SEMEX)
i=1?
YFC=YFA+(XAC-XAI)/N
Z(1)=XAC
Da
195

2. Enunț

cu T , T * ∈ [0 ÷ 100] grd C ;

ΔTmax
ΔT * = ⋅ ΔN .
ΔN max
Qi
i
N T*
Qat TT R u
CAN BC1
T
Qe
Să se determine:
(în mA);
196

Rezolvare
umax 5
umax = R ⋅ imax  R = = = 250 Ω ;
imax 20 ⋅10−3
umin 1
umin = R ⋅ imin  imin = = = 0 ,004 A = 4 mA .
R 250
b – pentru CAN cu caracteristica ilustrată în figura de mai jos
N
Nmax
Nmin
U
Umin Umax
se poate scrie
N min
N= ⋅ u , de unde rezultă
umin
N min 819
N max = ⋅ umax = ⋅ 5 = 4095 uCAN .
umin 1
Pe de altă pentru un CAN
N max = 2n − 1 n = log 2 ( N max + 1 ) = log 2 4096 =12 biti .
ΔTmax ΔN max
c – din relația ΔT * = ⋅ ΔN rezultă ΔN1 = ⋅ ΔT1* ,
ΔN max ΔTmax
sau înlocuind valorile numerice
197
N max − N min
N1 − N min = ⋅ ( T1* − Tmin ) sau
Tmax − Tmin
4095 − 819
N1 − 819 = ⋅ ( 75 − 0 ) de unde
100 − 0
3276 ⋅ 75
N1 = 819 + = 3276 uCAN
100
3. Enunț
Pentru SNTD temperatură cu structura ilustrată în figură se

cunosc:
cu T , T * ∈ [0 ÷ 800] grd C ;
ΔN max
ΔN = ⋅ ΔT * .
ΔTmax
QP TP
u N T*
TT
Qa QC CNA BC2
i
TC CUI
Să se determine:
198
Răspuns la testul de autoevaluare 3 (c

Patr Complet

Încărcat de

Informații document

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

Patr Complet

Încărcat de

Drepturi de autor:

Formate disponibile

Programarea aplicaţiilor de timp real

Acest prim modul al cursului urmăreşte atingerea

 definirea comportării în timp real;

Cuvinte cheie: timp real, sistem de operare în timp

1.1. Funcţiile automatizării proceselor

sistemul de conducere este deschis , mijlocul de conducere nefiind in-

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

Existenţa unor perturbaţii care acţionează asupra OC indepen-

Obiective Comenzi Rezultate

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

Caracterul corectiv este conferit de faptul că prin acţiunea co-

Dezavantajul identificat la SC cu acţiune corectivă este diminuat

Obiective Comenzi Rezultate

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

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

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

acţiunea este după efect (respectiv corectivă).

Liniile de transmisie pentru semnale analogice sunt realizate în

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

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 echipa-

1.1.3. Protecţia automată

P1lim Pklim Pnlim

Parametri din proces

Sistemele de blocare automată (SBA) sunt cu structură închisă

1.1.4. Optimizarea automată

1.2. Tipuri de aplicaţii în timp real

Procesare Date Procesare

SDCN SADA SDCA

Fig. 1.8. Structura unui sistem de conducere în timp real:

Din analiza figurii 1.8 se observă că sistemul de interfaţă cu sec-

 Aplicaţiile tranzacţionale presupun rezolvarea unor solici-

MGT MMT MATk SGBD

Fig. 1.9. Structura unui sistem de tranzacţionare în timp real:

După cum se observă din figura 1.9, sistemul tranzacţional

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

gorie intră printre altele: mediile de dezvoltare, diagnosticare şi depa-

Un SOTR capabil să asigure o execuţie paralelă sau cel puţin

- apelarea de către taskul aflat în execuţie a unei funcţii reali-

plătit pentru acest avantaj este reprezentat de timpul consumat cu

La gestionarea operaţiilor de intrare-ieşire, trebuie avut în ve-

1.4. Obiectivele şi principiile ingineriei programă-

 Adaptabilitatea presupune dezvoltarea de facilităţi pentru

Start dezvoltare aplicaţie

Încheiere dezvoltare aplicaţie

Fig. 1.10. Procesul iterativ asociat etapelor din existenţa

Pe parcursul derulării etapelor de mai sus repartiţia aproxima-

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

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

Execuţia aplicaţiilor de timp real impune ca acestea să fie dez-

2.1. Stările şi tranziţiile taskurilor

Fig. 2.1. Execuţia intercalată a taskurilor.

În exemplul din figura 2.1a se consideră următoarea

- coordonarea execuţiei taskurilor interactive

Fig. 2.2. Structura stratificată a unei aplicaţii de timp real.

Posibilitatea execuţiei unei aplicaţii de timp real implică exis-

- secţiunea de date care conţine operanzi şi rezultate ;

 Un task neinstalat este un task rezident în memoria internă

INACTIV Stop normal