Patr

CUPRINS
Prefaţă I
Cuprins III
Modulul A de studiu 1
1. SISTEME DE CONDUCERE ÎN TIMP REAL 3
1.1. Funcţiile automatizării proceselor 3
1.1.1. Monitorizarea automată 6
1.1.2. Reglarea automată 7
1.1.3. Protecţia automată 9
1.1.4. Optimizarea automată 10
1.2. Tipuri de aplicaţii în timp real 11
1.3. Trăsături specifice ale sistemelor de operare în timp real 14
1.4. Obiectivele şi principiile ingineriei programării în timp real 19
2. MECANISMELE PROGRAMĂRII CONCURENTE ÎN TIMP REAL 25
2.1. Stările şi tranziţiile taskurilor 25
2.2. Conflicte potenţiale în sistemele multitasking 32
2.2.1. Resurse şi secţiuni critice 32
2.2.2. Excluderea mutuală realizată cu semafoare 34
2.2.3. Excluderea mutuală realizată cu variabile de tip eveniment 38
2.2.4. Excluderea mutuală realizată cu mesaje şi cutii poştale 41
2.2.5. Alte modalităţi de realizare a excluderii mutuale 43
2.3. Sincronizarea taskurilor 46
2.3.1. Sincronizarea realizată cu semafoare 48
2.3.2. Sincronizarea realizată cu variabile de tip eveniment 50
2.3.3. Sincronizarea realizată cu mesaje şi cutii poştale 51
2.3.4. Sincronizarea prin monitoare şi blocuri de întâlnire 57
2.4. Comunicarea între taskuri 58
2.4.1. Utilizarea în comunicare a semafoarelor 59
2.4.2. Utilizarea în comunicare a mesajelor şi cutiilor poştale 62
IA - Întrebări pentru modulul A de studiu 64

TA - Test de autoevaluare pentru modulul A de studiu 66
iii
Modulul B de studiu 69
3. RESURSE PENTRU PROGRAMAREA ÎN TIMP REAL 71

3.1. Cerinţe şi caracteristici ale limbajelor de programare în timp real 71
(LPTR)
3.1.1. Tipuri de LPTR 71
3.1.2. Cerinţe impuse LPTR 74
3.1.3. Caracteristici ale LPTR 75
3.2. Nucleul de timp real RTK 80
3.2.1. Caracteristicile nucleului RTK 80
3.2.2. Taskuri sub RTK 81
3.2.3. Funcţii RTK de iniţializare 84
3.2.4. Funcţii RTK de administrare a taskurilor 86
3.2.5. Funcţii RTK gestionare a timpului 90
3.2.6. Funcţii RTK gestionare a semafoarelor 94
3.2.7. Funcţii RTK gestionare a cutiilor poştale 99
3.2.8. Funcţii RTK gestionare a mesajelor de trecere 106
4. PRELUCRAREA ÎN TIMP REAL A INFORMAŢIEI DE PROCES 113
4.1. Prelucrarea primară a datelor de proces 114
4.1.1. Filtrarea mărimilor achiziţionate 114
4.1.2. Circuitul informaţional aferent unei aplicaţii de conducere 117
4.1.3. Conversia în unităţi inginereşti 119
4.1.4. Conversia din unităţi inginereşti 130
4.1.5. Validarea mărimilor achiziţionate şi a comenzilor elaborate 141
4.2. Taskuri asociate unor algoritmi uzuali de reglare numerică 144
4.2.1. Taskuri asociate unui SRA cu regulator PID 144
4.2.2. Taskuri asociate unui SRA cu regulator bipoziţional 148
4.3. Baze de date de proces 153
EB - Exerciţii şi întrebări pentru modulul B de studiu 156
TB - Test de autoevaluare pentru modulul B de studiu 158
SAB - Soluţiile testelor de autoevaluare 161
Modulul A 161
Modulul B 164
BIBLIOGRAFIE 173
iv
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 eficienţă;
- 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.
Obiective Comenzi Rezultate
MC OC
Fig. 1.1. Sistem de conducere deschis:

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

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

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
Feedforward Perturbaţii

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
Parte variabilă Parte fixată
a
Perturbaţii
I u y
CP EE PrT
Parte variabilă Parte fixată
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;
- elaborarea comenzilor;
- 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 eficienţă;
- 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);
- activarea şi dezactivarea taskurilor.
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 planificare a execuţiei taskurilor;
- 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
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_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:
- T1 se sincronizează cu evenimentul extern EVEX1;
- T2 se sincronizează cu evenimentul extern EVEX2;
- T3 se sincronizează cu ansamblul celor două evenimente.
După cum se observă din figura 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
Fig. 2.15. Sincronizarea cu timpul: execuţia taskului T2 se face în
interiorul cuantei de timp Δt.
Este posibilă execuţia taskului T2 în afara cuantei Δt, conform

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

Taskul T2 aşteaptă la cutia poştală vidă C0 un interval de timp Δt, deblocarea
producându-se la expirarea acestei cuante de timp. În figura 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ă:
- T0 – în aşteptarea producerii evenimentului EV_EXT;
- T1 – la cutia poştală C0 în aşteptarea mesajului MES_EV care
confirmă producerea evenimentului;
- T2 – la cutia poştală C1 în aşteptarea mesajului de sincronizare
MES_SYNC.
Este important de subliniat faptul că după primirea mesajului de
sincronizare, T2 trebuie să depună în cutia poştală C2 mesajul de confirmare
MES_CONF.
Ca şi în cazul sincronizării cu timpul, taskul T1 poate fi eliminat în
situaţia în care nu se doreşte monitorizarea funcţionalităţii taskului T2, soluţia
principială fiind prezentată în figura 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ă:
- T0 – în aşteptarea producerii evenimentului EV_EXT;
- T2 – la cutia poştală C0 în aşteptarea mesajului MES_EV referitor la
producerea evenimentului extern.
Î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.
TASK A TASK B TASK C
Punct de întâlnire
(rendez – vous)
TASK A TASK B TASK C

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
#include "rtkernel.h"
De asemenea trebuie incluse tot printr-o directivă de preprocesare fişierul
cu antetele funcţiilor asociate driverului consolei38 , respectiv
#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 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
2. http://www.on-time.com/rtkernel-dos.htm
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
{
getdate(&d); // preia data in variabila d
gettime(&t); // preia timpul in variabila t
gotoxy(55,3); //pozitioneaza cursorul
//se tiparesc: ziua, luna anul
cprintf("%02d-%02d-%4d",d.da_day,d.da_mon,d.da_year);
// se tiparesc: ora, minutul, secunda
cprintf(" 02d-%02d-%02d",t.ti_hour,t.ti_min,t.ti_sec);
}
//
// Task afisare temporizata a datei si orei
//
Task_ora(void)
{
for(;;) //bucla for infinita
{
RTKDelay(18); //temporizare o secunda
afordata(void); //apelare functie afordata
} //sfarsit for
} //sfarsit Task_ora
//
// Task main
//
main(void)
{
char c;
RTKernelInit(3); //initializare RTK
clrscr(void); //stergere ecran
gotoxy(5,8); //pozitionare cursor
cprintf("E - Iesire");
RTKeybrdInit(void); //initializare driver consola
// Creare Task_ora
RTKCreateTask(Task_ora,5,1024,"Task_tip_ora");
//
123

{
c=RTGetCh(); //supraveghere tastatura
if(c==’E’) //testare fata de E
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,

Duration Timp_astept); (3.21)
î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
(specificat în ticks).
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;
//
//functie preluare si tiparire data si ora
//
afordata(void)
{
//se tiparesc: ora, minutul, secunda
}
//
//
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
{
RTKdelay(18); //temporizare o secunda
gotoxy(15,10); //tiparire secunde trecute
cprintf("%d",i);
} //sfarsit for finit
} //sfarsit for infinit
} //sfarsit Task_sincr
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");
// creare Task_ora si Task_sincr
RTKCreateTask(Task_ora,5,1024,"Task_af_ora");
RTKCreateTask(Task_sincr,7,1024,"Task_sin");
//
{
c=RTGetCh(void); //supraveghere tastatura
if(c==’B’) //testarea fata de B
//incrementeaza semafor Sem_sincr
RTKSignal(Sem_sincr);
if(c==’E’) //testare fata de E
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);
RTKCreateTask(Task_ora,5,1024,"Task_tip_ora");
//
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
anume: necondiţionată, condiţionată şi temporizată.
• 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);
} //sfarsit Task_sincr
//
//
{
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");
// creare Task_ora si Task_sincr
RTKCreateTask(Task_ora,5,1024,"Task_af_ora");
RTKCreateTask(Task_sincr,7,1024,"Task_sin");
//
{
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.
11-3.5.1 Mesaje de trecere în context RTK

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?
11-3.5.2 Funcții RTK de gestionare a mesajelor 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
BlockedSend, stare în care va rămâne până când TDP.
• Funcţia de transmitere condiţionată este RTKSendCond care
bool exec RTKSendCond(TaskHandle Handler_rec,
void *Var_dep); (3.32)
în care parametrul Handler_rec este handler al taskului destinatar, iar
urmează a fi transmis.
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,
void *Var_dep, Duration Timp_astept); (3.33)
î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
exec se înscrie valoarea logică False.
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
BlockedReceive, stare în care va rămâne până când UTEP.
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,
unsigned Lung_mes); (3.35)
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, 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

care are formă generală
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
continuă rularea, iar în variabila de tip exec de tip bool se înscrie valoarea
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.
• 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ă
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.
//
// 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(void)
{
}
//
//

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

{
char j2;
{
RTKReceive(&j2,2);// preia mesaj si depune in j2
gotoxy (5,8);
cprintf("Dest a receptionat %c ",j2);//tip j2
} //sfarsit TaskB
//
//
{
char c, j1=’0’;
int i;
cprintf("Orice tasta–main transmite E - Iesire");
//initializare driver consola
RTKeybrdInit(void);
// creare TaskA si TaskB
RTKCreateTask(Task_ora,5,1024,"Task-tip_ora");
Handler_dest=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);
} //sfarsit for finit
//
if(c==’E’) //testare c fata de E
exit(0); //iesire
j1=’0’; //altfel initializeaza j1
} //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ă:
- 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;
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ț
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
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);
- cum se realizează sinteza modulului de conversie (scalare) BC2 în
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.
12-4.1.1 Tipuri de operații de prelucrare primară a datelor de proces

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:
- filtrarea mărimilor achiziționate;
- 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
conducere în timp real.
Exerciţiul 1
Care sunt obiectivele unui proces?
Exerciţiul 2
Enumerați operațiile de prelucrare primară a datelor achiziționate și a
comenzilor elaborate.
162
12-4.1.2 Filtrarea datelor achiziționate

În general un filtru reprezintă un bloc funcțional cu proprietăți selective
pentru anumite frecvențe. Spre deosebire de filtrele analogice, la care intrarea și
ieșirea sunt reprezentate de semnale analogice, la cele numerice, atât intrarea cât
și ieșirea sunt constituite din secvențe de numere, potrivit reprezentării din
figura 4.1.
x[n] y[n]
FILTRU
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] ș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
unde h[k] reprezintă coeficienți ai filtrului.
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]
Fig. 4.2. Organizarea cozii termenul pentru obţinerea termenului

x[n-N din] relaţia (4.4).
După efectuarea notaţiilor:
- 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ă,
relaţia (4.4) capătă forma
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.
12-4.1.3 Circuitul informațional aferent unei aplicații de conducere
Î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:
- achiziția din proces a datelor;
- elaborarea comenzilor;
- implementarea în proces a comenzilor.
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
ANALOGIC DIGITAL DIGITAL

T PI
Semnale uCAN uING Calcul și
analogice
PROCES generare
de la traductoare
comenzi
ANALOGIC DIGITAL DIGITAL
EE PE
Semnale uCNA uING
analogice
către elemente
de execuție
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.
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
tensiune – curent respectiv curent – tensiune.
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
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 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
În raport cu referința y2i
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?
12-4.1.4 Conversia în unități inginerești

După cum s-a menționat în paragraful anterior această conversie se
realizează de către blocul BC1, parte integrată a unui sistem numeric de măsurat
la distanţă (SNMD) cu structura evidenţiată în figura 4.5.
Δ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] , respectiv z ∈ [ zmin , zmax ] se definesc
următoarele două tipuri de variaţii:
- 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 impunând
pentru SNMD o caracteristică statică liniară, ilustrată în figura 4.6.
Δx*
Δx*max
Fig. 4.6. Caracteristica statică impusă pentru

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
Δ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 traductorului T. În cele ce
urmează vor fi considerate două situaţii şi anume:
- SNMD cu traductor de tip liniar;
- SNMD cu traductor de tip neliniar (pătratic).
• Sinteza BC1 pentru un SNMD cu traductor liniar

În figura 4.8 este ilustrată caracteristica statică a unui traductor 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.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
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 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
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
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
Fig. 4.10. Caracteristica statică a traductorului

neliniar din structura SNMD.
Δ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
Rezolvând sistemul format din ecuaţiile (4.23)…(4.26) rezultă pentru
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

modulul de calcul BC1, în cazul traductorului
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;
b – rezoluţia n a 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
Fig. 4.12. Structura SNMD nivel pentru exemplul 4.1.
174
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 = log 2 ( N max + 1 ) = log 2 ( 1023 + 1 ) = log 2 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= ⋅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
Rezultă pentru modulul BC1 relaţia

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
Fie SNMD debit ilustrat în figura 4.14, pentru care se cunosc:

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 ;
CIU - CS – liniară cu R = 50 Ω ;
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
12-4.1.5 Conversia din unități inginerești

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
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 î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.
Determinarea relaţiei asociate modulului BC2 se va realiza impunând
pentru SNTD o caracteristică statică liniară ilustrată în figura 4.16.
Δy
Δymax
Fig. 4.16. Caracteristica statică impusă pentru

SNTD.
Δy*max Δy*
Atât pentru convertorul tensiune curent CUI, cât şi pentru cel analog
numeric CNA se presupun caracteristici statice liniare prezentate în figura 4.17.
Δi Δu
Δimax
Δumax
Δumax Δu ΔN
ΔNmax
a b
Fig. 4.17. Caracteristici statice ale convertoarelor: a – CUI; b – CNA.
179
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 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
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.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
modulul de calcul BC2, în cazul SRA cu
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
După efectuarea calculelor în relaţia (4.41) se obţine,
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

exprimare (prin variaţii sau valori absolute), modulul BC2 prezintă o
caracteristică statică liniară.
• 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
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 asociază

următorul sistem de ecuaţii în variații:
Δ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
Rezolvând sistemul format din ecuaţiile (4.50)…(4.53) rezultă
pentru BC2 ecuaţia
ΔN max
ΔN = * 2
⋅ ( Δy* )2 , (4.54)
( Δymax )
sau impunând pentru mărimea y* reprezentată în memorie acelaşi domeniu de
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
element neliniar, a cărui caracteristică statică este reprezentată în figura 4.21.
După cum se observă, prin această caracteristică este compensată neliniaritatea
caracteristicii de măsură a SRA.
183
ΔN
ΔNmax
modulul de calcul BC2, în cazul SRA cu CM
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 )
După efectuarea calculelor în relaţia (4.56) rezultă
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;
b – valoarea calculată H1* a nivelului pentru care a
rezultat un număr N1=800 uCNA .
Qi i u N H*
CUI CNA BC2
LT LC
Qe
Fig. 4.22. Structura SNTD nivel pentru exemplul 4.3.
185
Rezolvare
a – pentru un CNA (ca şi în cazul CAN) se cunoaşte că
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
Fig. 4.23. Caracteristica statică a CNA.

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ă:
H max ⋅ N min − H min ⋅ N max 800 ⋅ 409 ,4 − 200 ⋅ 2047
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
Rezultă modulul BC2 relaţia

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 ;
CUI - CS – liniară cu u ∈ [0, 4 ÷ 2] V ;
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
Fig. 4.24. Structura SNMD debit pentru exemplul 4.4.
Rezolvare
a – N max = 2n − 1= 212 − 1 = 4096 − 1 = 4095 uCNA .

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

Umin = 0,4
N[uCNA]
Nmin Nmax=4095
Caracteristica statică liniară din figura 4.25 poate fi descrisă de relaţia

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 ,
sau cu datele din enunţ
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
Limite Avertizare de Prevenire
Limite Avertizare de Avarie
Fig. 4.26. Limite asociate diverselor tipuri de testări a unei mărimi achiziţionate.
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.
Domeniu Comenzi Valide
Ymin Ymax Y
Domeniu Comenzi Sigure
Fig. 4.27. Limite asociate testării unei comenzi calculate.
191
O neîncadrare în domeniul comenzilor valide va fi declarată ca

eveniment semnificativ, care va fi tratat ca şi în cazul achiziţiei prin execuţia unei
rutine de testare a integrităţii funcţionale a SNTD şi avertizare.
Încălcarea unei limite a domeniului de funcţionare sigură va determina
de regulă aplicarea către SNTD a valorii limitei încălcate, aspect evidenţiat în
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
Y=Ymin Y=Ycalc Y=Ymax
Transfera
Y
RETURN
Fig. 4.28. Schema logică asociată procedurii de testare

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ț
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.
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ț
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 ;
Δ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.
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:
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.
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ă

N max = 2n − 1, de unde rezultă

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-

Gaze din Ploieşti, 2013.
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.
- implementezi în cadrul taskurilor de achiziții date și generare comenzi a
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
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
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
SEMEX=1, stabileşte valori iniţiale
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
SEMEX=1, determină valoarea
iniţială UC pentru comanda U
Nu
∆t=Tcom?
Da
P(SEMEX)
Preia din BDP

Tmin, Tmax
V(SEMEX)
Achiziționează R 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
SEMEX=1, stabileşte valori iniţiale
pentru Tref, HYST, Tmin, Tmax.
Nu
Tast?
V(SEMEX)
Da
Da
I? Modif _Tref
Transfera
Nu
Tmin, Tmax
Da în BDP
H? Modif _HYST
Nu
P(SEMEX)
Nu
E?
Da Calculează
Tmin, Tmax
EXIT
Fig. 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)
Preia din BDP EAA=UA

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
SEMEX=1, determină valoarea
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-

Gaze din Ploieşti, 2013.
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;
- să asigure securitatea datelor;
- să asigure integritatea datelor;
- să asigure independenţa datelor.
• 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ă?

2. Ce obiectiv al unui proces este asigurat prin funcţia de protecţie
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.
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 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?
17. Ce valoare are un semafor utilizat în excludere mutuală 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?
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.
2. Ce obiectiv al unui proces este asigurat prin funcţia de protecţie

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.
8. Explicaţi diferenţa dintre taskurile disjuncte şi cele interactive.

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 planificare a execuţiei taskurilor;
- 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ă.
17. Ce valoare are un semafor utilizat în excludere mutuală pe durata

Rezolvare
Variabila întreagă din structura semaforului (implicit semaforul) 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?
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?
17. Rezolvaţi problema din exemplul 4.1 pentru Nmax=4095 uCAN .
18. Rezolvaţi problema din exemplul 4.2 pentru Nmax=1023 uCAN .
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.
7. Enumeraţi tipurile de variabile specifice nucleului RTK.
8. Prin ce se implementează frontiera F2 la achiziţia datelor şi
transmiterea 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 ș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?

13. Deduceţi relaţia asociată modulului BC1 în următoarele condiţii:
* Δ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;

caracteristică statică liniară;
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
16. Fie SNTD ilustrat în figura de mai jos, pentru care se cunosc:
SNTD : caracteristică statică impusă liniară
SRA : Q ,Q* ∈ [ 0 ÷ 30 ] mc / h , caracteristică statică
neliniară (radical);
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

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?
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);
7. Enumeraţi tipurile de variabile specifice nucleului RTK.

Rezolvare
Tipurile sunt: TaskHandle, TaskState, Time, Duration, Semaphore,
SemaType, Mailbox
241
8. Prin ce se implementează frontiera F2 la achiziţia datelor şi

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.
10. Denumiţi operaţiile de prelucrare primară a datelor de proces.

Rezolvare
Operaţiile de prelucrare primară a datelor de proces sunt:
- conversia în/din unități inginerești;
- 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;

caracteristică statică liniară;
CIU - R = 50 Ω, Umax=1 V, caracteristică statică liniară;
CAN - Nmin = 409,4 uCAN, caracteristică statică liniară;
243
Să se determine:
a – Umin şi imax;
b – rezoluţia n a CAN şi Nmax;
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.
15. Deduceţi relaţia asociată modulului BC2 în următoarele

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
16. Fie SNTD ilustrat în figura de mai jos, pentru care se cunosc:
SNTD : caracteristică statică impusă liniară
SRA : Q ,Q* ∈ [ 0 ÷ 30 ] mc / h , caracteristică statică
neliniară (radical);
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
sau cu datele din enunţ
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

pentru implementarea unui algoritm PID în formă numerică.
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;
- să asigure securitatea datelor;
- să asigure integritatea datelor;
- să asigure independenţa datelor.
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

Patr

Î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

Încărcat de

Drepturi de autor:

Formate disponibile

CUPRINS

IA - Întrebări pentru modulul A de studiu 64

3. RESURSE PENTRU PROGRAMAREA ÎN TIMP REAL 71

EDITURA UNIVERSITĂŢII PETROL-GAZE DIN PLOIEŞTI

Lucrarea a fost avizată în cadrul Departamentului de Învăţământ la Distanţă şi cu

Descrierea CIP a Bibliotecii Naţionale a României

Prezenta lucrare a fost elaborată pe baza fișei disciplinei aferente cursului

• Al treilea modul, care conține 5 unități de învățare (sinteze) se deschide

Prof. Univ. Dr. Ing. Nicolae Paraschiv

9-3.3.4 Funcții RTK de gestionare a semafoarelor ........................................................ 125

MODULUL DE STUDIU 5 ............................................................................................................ 231

1-1.1.1 Strategii de conducere

Conducerea încadrează activitatea de dirijare a evoluţiei procesului în

Dacă OC se află numai sub influenţa comenzilor şi are caracteristici

Fig. 1.1. Sistem de conducere deschis:

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

Obiective Comenzi Rezultate

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

Caracterul corectiv al acestei strategii este conferit de faptul că prin

legături informaţionale face ca sistemele de conducere cu acţiune corectivă să fie

Obiective Comenzi Rezultate

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

La un asemenea sistem de conducere comenzile sunt astfel determinate

Obiective Comenzi Rezultate

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

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

În contextul conducerii automate pot fi identificate patru categorii de

1-1.1.2 Monitorizarea automată

M – numărul de relaţii independente dintre cele L variabile;

Pentru cele F variabile care trebuie măsurate se impune existenţa câte

1-1.1.3 Reglarea automată

În această categorie pot fi incluse:

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

Pentru asigurarea funcţionalităţii, un SRA convenţional conţine pe lângă

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

Parte variabilă Parte fixată

Parte variabilă Parte fixată

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

În ceea ce privește numărul maxim de SRA care pot fi asociate unui

echipamente periferice de proces. Această încadrare are în vedere faptul că prin

SRA cu structură evoluată (reglare avansată) au asociate obiective

1-1.1.3 Protecția automată

P1lima Pklima Pnlima AA

Fig. 1.7. Structura unui sistem de avertizare:

Avertizarea de poziţie informează în legătură cu starea de funcţionare

• Sistemele de blocare automată (SBA) determină scoaterea din

Fig. 1.8. Structura unui sistem de blocare:

figurat sub forma unui comutator care conectează/deconectează procesul la/de la

Fig. 1.9. Structura unui sistem de comandă:

Este de menționat faptul că tot prin intermediul SCA se poate realiza

Răspunsurile la testele de autoevaluare

Răspunsurile la testele de autoevaluare (continuare)

2-1.2.1 Tipuri de aplicații de timp real

că pentru a se păstra consistența informațională (respectiv pentru a nu se pierde

SDCN SADA SDCA

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

Procesul este accesat prin intermediul traductoarelor analogice și

distribuție aferente comenzilor analogice (SDCA) și numerice (SDCN). Este de

• Aplicaţiile tranzacţionale presupun rezolvarea unor solicitări pe

MGT MMT MATk SGBD

Fig. 1.11. Structura unui posibil sistem tranzacțional în timp real:

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

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,