Vári-Kakas Ștefan [628624]
Vári-Kakas Ștefan
SISTEME TOLERANTE LA DEFECTE
curs
1. INTRODUCERE
1.1. Conceptul de toleranță la defecte
Cerințele de bază ale utilizatorului față de oricare sistem de calcul pot fi
rezumate sub forma atributelor de corectitudine și fiabilitate, în condiții de cost
acceptabile. Prin corectitudine se înțelege satisfacerea funcțiilor prescrise, iar
prin fiabilitate funcționarea fără defectare (în sens calitativ).
Fiabilitatea este o caracteristică dorită de la orice sistem de calcul, dar și
o cerință necesară pentru anumite sisteme a căror defectare poate fi critică sau
inacceptabilă. Din prima categorie fac parte aplicații cum ar fi aparatura de
zbor, sistemele de dirijare a zborului, sistemele de semaforizare pentru trenuri,
sistemele de cond ucere a reactoarelor nucleare. În categoria aplicațiilor unde
nu se acceptă defectări intră sistemele de tranzacții bancare, sistemele
telefonice, sistemele pentru rezervări de bilete etc.
Funcționarea fără defectare este un obiectiv, ea nu poate fi însă
niciodată garantată. Pe de o parte componentele din care este construit
sistemul sunt expuse la defectare, iar pe de altă parte chiar un proiect
considerat perfect poate conține defecte care nu au fost puse în evidență.
Soluțiile posibile pentru a atinge o fiabilitate ideală sunt sintetizate în figura
1.1. Acestea sunt în principiu de două feluri: măsuri de prevenire a defectelor și
măsuri de tolerare a defectelor.
Prevenirea defectelor (fault prevention ) constă în înlăturarea tuturor
cauzelor de nefiabilita te înainte de punerea în funcțiune a sistemului. Acest
lucru se poate realiza atât prin evitarea defectelor ( fault avoidance ), cât și prin
eliminarea lor ( fault removal ). Evitarea este posibilă prin utilizarea unor
metode de proiectare adecvate și a unei t ehnologii constructive
corespunzătoare, care se bazează de exemplu pe componente fiabile.
Eliminarea defectelor presupune existența unei tehnologii de testare, respectiv
a metodelor formale de verificare și a tehnicilor de simulare pentru punerea în
eviden ță a defectelor. Cu toate aceste măsuri, pot rămâne în sistem defecte
nepuse în evidență sau se pot introduce defecte noi tocmai în timpul acțiunilor
de verificare menționate. În general măsurile de prevenire a defectelor au
dezavantajul de a fi scumpe și insuficiente. Prețul ridicat se datorează
necesității de a utiliza componente fiabile, respectiv dezideratului de a efectua
o testare exhaustivă a sistemului. Oricum testarea nu poate fi niciodată
completă, ea se poate întinde numai până la o anumită limit ă. Chiar sistemul
deja testat poate conține defecte de proiectare ascunse și persistă în
continuare posibilitatea potențială a defectării oricărei componente hardware.
Prezența defectelor în sistemele complexe este în general inevitabilă
pentru că nu se pot elimina cele a căror existență nu este cunoscută. Dacă se
recurge numai la aceste metode de prevenire, atunci rezultatul este un sistem
intolerant la defecte (fault intolerant system ). O creștere a disponibilității se
poate obține prin includerea în sistem a unor mecanisme de detecție a erorilor
care să -l facă ușor testabil ( easily testable system ) în situația de funcționare
necorespunzătoare. O astfel de abordare pre supune utilizarea tehnicilor de
proiectare pentru testabilitate ( design for testability ). Diagnoza ușoară permite
izolarea și înlocuirea rapidă a subsistemului defect, în acest caz sistemul având
proprietatea de a fi asigurat la defecte (fault -secure ).
Tolerarea defectelor (fault tolerance ) impune luarea de măsuri astfel
încât sistemul să fie operațional chiar în prezența unor defecte. Problema a fost
studiată prima dată de John von Neumann, care în anul 1956 a propus sinteza
unor sisteme fiabile din compon ente nefiabile. Atunci el a arătat că acest lucru
este posibil numai prin adăugarea de componente suplimentare (redundante)
la cele utile. De exemplu, prin triplarea sistemului și efectuarea unui vot de tip
2-din-3 asupra ieșirilor se poate tolera un modul defect. Acest concept de vot
majoritar a fost aplicat mai târziu și la navele spațiale ale programului Apollo.
Mult timp implementarea toleranței la defecte a fost însă neglijată pentru a nu
crește excesiv costurile.
Dezvoltarea tehnologiei de integrare p e scară largă VLSI ( Very Large Scale
Integration ) în anii ’80 a condus la o răspândire fără precedent a sistemelor
electronice de calcul. Odată cu creșterea complexității sistemelor, a crescut și
importanța defectelor de proiectare. Astfel a revenit în act ualitate importanța
Figura 1.1. Clasificarea măsurilor de creștere a fiabilității
construirii de sisteme tolerante la defecte, lucru posibil datorită reducerii
prețurilor componentelor și a miniaturizării. Evoluția tehnologiei VLSI a impus
elaborarea unor noi tehnici de toleranță față de proiectul cu componente
discr ete, chiar unele circuite VLSI având integrate facilități de toleranță.
Ca și o sinteză a celor prezentate, în figura 1.2 se arată împletirea în timp
a măsurilor necesare pentru a atinge o fiabilitate ridicată . În abordarea clasică,
creșterea fiabilităț ii s-a rezumat doar la prevenirea defectelor.
Figura 1.2. Aplicarea în timp a măsurilor de creștere a fiabilității
Sistemul tolerant la defecte (fault tolerant system ) se poate defini ca un
sistem capabil de a -și îndeplini funcțiunile specificate chiar în prezența unui
număr (limitat) de subsisteme (hardware și software) defecte. În privința
defectelor care trebuie tolerate, acestea pot fi anticipate sau neanticipate.
Defectele anticipate (anticipated faults ) sunt cele legate de defectarea
componentelor hardware. Comportarea componentelor fiind previzibilă prin
calcule probabilistice (pe baza caracteristicilor de viață), această categorie de
defecte permite implementare a măsurilor de toleranță. Defectele neanticipate
(unanticipated faults ) constau în defecte de proiectare ( design faults ).
Producerea lor este inerentă în sistemele foarte complexe, dar efectul lor nu
este previzibil. Defectele de proiectare se pot întâlni atât la nivel hardware, cât
și software. La nivel hardware, defectele sunt în general eliminabile prin tehnici
de prevenire, ca urmare ele nu necesită măsuri de toleranță. În schimb la nivel
software, defectele sunt greu de pus în evidență datorită numărul ui imens de
stări posibile ale sistemelor complexe. Această categorie reprezintă sursa
majoră a defectelor în sistemele de calcul, cu toate măsurile de prevenire
(medii de dezvoltare de nivel înalt, programare structurată, programare
orientată pe obiecte, tehnici de depanare a programelor etc.). De asemenea,
orice modificare a programelor, cum ar fi elaborarea de versiuni actualizate,
poate introduce noi defecte. În concluzie, este puțin probabil ca un sistem
complex să fie lipsit de defecte de proiectare ș i deci se impune necesitatea
tehnicilor de toleranță nu numai pentru defectele anticipate, ci și pentru cele
neanticipate.
Toleranța la defecte reprezintă un obiectiv de proiectare , dar și un mijloc
care face parte din activitatea globală de proiectare a unui sistem, alături de
tehnicile clasice. Elaborarea unui sistem de calcul tolerant la defecte presupune
un alt mod de abordare a proiectării sistemelor decât cele care se rezumă doar
la satisfacere a funcțiilor prescrise. În acest context se impune și o altă viziune
asupra relației hardware -software, diferențierea dintre ele fiind din ce în ce mai
puțin evidentă. Aceste părți ale sistemului se proiectează împreună, fiind
încetățenit deja termenul de hardware -software co -design . Tehnicile de
toleranță oferă în general principii de bază valabile atât în hardware, cât și în
software, diferența fiind în mecanismele de implementare.
Apare ca un lucru firesc necesitatea unui cadru de proiectare adecvat
Figura 1.3. Cadrul de proiectare pentru atingerea unei
fiabilități ridicate
(figura 1.3), care să asigure ca introducerea de elemente redundante să ducă la
creșterea și nu cumva la reducerea fiabilității sistemului. Pe lângă mijloacele de
proiectare, acest cadru trebuie să conțină în paralel și metode de evaluare a
fiabilității și performanței, cum ar fi modele Markov, analiză combinatorie,
scheme bloc de fiabilitate, modele de fiabilitate software, modele de
performabilitate etc. Modelele d e fiabilitate software se aplică mai ales în faza
de elaborare, unde se introduc în mod aleator erori reziduale și mai puțin în
faza operațională, care reprezintă un fenomen determinist.
Regulile clasice de proiectare a sistemelor digitale, tehnicile de
programare, tehnicile de testare, metodele de evaluare a fiabilității și
disponibilității, nu sunt tratate în această carte, ele făcând obiectul altor lucrări.
Această sinteză se ocupă de prezentarea tehnicilor de toleranță la defecte și
implementarea lor în sistemele de calcul. Este de menționat faptul că în acest
domeniu un rol deosebit revine proiectării asistate de calculator, prin punerea
la dispoziția inginerilor de cercetare -dezvoltare a mediilor integrate de lucru.
1.2. Domenii de aplicație
Odată cu extinderea masivă a domeniilor de utilizare a calculatoarelor,
toleranța la defecte joacă un rol tot mai important. Acest lucru este motivat de
faptul că beneficiarii formulează pretenții din ce în ce mai ridicate de fiabilitate,
iar fabricanții obțin o s cădere a costurilor activității de întreținere la asemenea
produse.
Câteva domenii semnificative de aplicație a sistemelor tolerante la
defecte vor fi enumerate în continuare.
Sistemele critice pentru viața umană, protecția mediului sau a
echipamentelor s cumpe, necesită o înaltă siguranță ( safety ) în funcționare.
Astfel, navele spațiale prezintă o dependență totală de funcționarea
calculatoarelor. În cazul sistemelor de comandă ale avioanelor, dacă ele sunt de
tip “fly -by-wire“ (cu comanda electrică cablat ă a elementelor de execuție, fără
componente intermediare mecanice și hidraulice), crește importanța fiabilității
sistemului electronic. La sistemele în timp real pentru conducerea proceselor
(chimice, nucleare etc.) apare ca o cerință fundamentală restabi lirea rapidă
după detectarea unei erori. Continuitatea funcționării reprezintă un atribut
esențial al aparaturii medicale de terapie intensivă, care include tehnică de
calcul.
Sistemele cu durată lungă de viață , cum ar fi navele spațiale fără
personal uman sau sateliții artificiali, dispun de suficientă redundanță pentru a
putea îndeplini misiunile îndelungate. Majoritatea pot fi depanate de la sol și
reconfigurate în caz de sesizare a unui defect.
Sistemele cu amânarea mentenanței se caracterizează prin fa ptul că
depanarea și întreținerea sunt posibile numai în momente de timp și în locuri
bine stabilite. În această categorie se încadrează aparatele de zbor și sistemele
de prelucrare la distanță (militare, telefonice). În acest ultim caz, o degradare
parți ală a performanțelor se admite până la mentenanța planificată.
Sistemele cu disponibilitate ridicată trebuie să asigure serviciile scontate
atunci când ele sunt cerute. Exemple tipice sunt serverele din rețelele de
calculatoare și sistemele de tranzacție d istribuite, la care se impune necesitatea
integrității datelor (de exemplu la cele bancare). În cazul sistemelor comerciale
cu rețea de comunicație întinsă (de exemplu pentru bursă sau rezervări de
bilete) crește importanța factorului de acoperire a defect elor ( fault coverage ),
adică a probabilității de restabilire în caz de apariție a unui defect.
Sistemele de înaltă performanță , cum ar fi supercalculatoarele și
calculatoarele paralele, au nevoie de operarea corectă a tuturor
componentelor care conlucrează la satisfacerea funcțiilor prestabilite.
2. PRINCIPIILE TOLERANȚEI LA DEFECTE
2.1. Noțiuni de bază
Termenul cel mai general pentru a caracteriza calitatea serviciului furnizat
utilizatorului este dependabilitatea (dependability ). Ea surprinde faptul că
sistemele de calcul livrează un anumit serviciu, iar utilizatorul depinde de
acesta. Se poate defini dependabilitatea, ca fiind proprietatea sistemului de a i
se putea acorda în mod îndreptățit încredere pentru serviciul furnizat.
Ordonarea arborescent ă a noțiunilor aferente dependabilității este dată în
figura 2.1, care este o adaptare după Laprie.
Distincția între comportarea acceptabilă, respectiv inacceptabilă a unui
sistem necesită un standard de referință riguros. El trebuie conceput pe baza
unei specificații și nu a satisfacției oferite utilizatorului, care este subiectivă.
Specificația exactă (exact specification ) trebuie să fie:
consistentă, adică să conțină cerințe realiste, realizabile
completă, și anume să se refere la toate combinațiile posi bile de
intrare
autoritară, ceea ce înseamnă că nu i se mai admit modificări
Se definește un sistem de referință autoritar (authoritative system reference ),
ca o unitate fictivă care produce o comportare corectă a sistemului.
Dacă funcționarea sistemului nu se desfășoară conform așteptărilor,
atunci are loc o defectare a sistemului, numită și cădere sau malfuncționare .
Defectarea (failure ) reprezintă evenimentul care corespunde primei abateri a
comportării sistemului față de ce a specificată. Odată apărută, defectarea nu
poate fi făcută reversibilă, doar eventual efectele sale remediate.
Pot exista și specificații multiple (multiple specifications ), care prevăd
specificații separate pentru diferite aspecte ale comportării sistemului. Rezultă
astfel diferite categorii de defectare, clasificate de exemplu după gravitatea
defectării. Specificația este în acest caz ierarhică, mergând de la defectele
mino re (corespunzătoare unei specificații cuprinzătoare), la cele majore
(corespunzătoare cerinței strict necesare). O altă clasificare se poate face după
cerințele de siguranță, defectele fiind împărțite în critice, esențiale și
neesențiale.
Analizând evoluți a în timp a unui sistem, acesta trece printr -o secvență
de stări interne și de tranziții (figura 2.2). Defectarea sistemului reprezintă
manifestarea exterioară a unei stări interne eronate a sistemului. În figură,
prima stare eronată s -a atins în urma tran ziției T1. Starea internă eronată
presupune existența unei erori în sistem, ca fiind o diferență față de starea
Figura 2.1. Clasificarea noțiunilor legate de dependabilitate
validă. Se poate deci defini eroarea (error ), care înseamnă o valoare incorectă
într-o stare internă a sistemului. Dintr -o stare internă eronată se poate ajunge
la căderea sistemului printr -o succesiune de tranziții valide, dacă nu intervine o
acțiune corectivă (cum este T2) sau nu au loc interacțiuni particulare care
readuc sistemul într -o stare corectă.
Se remarcă următoarele proprietăți ale erorii:
latența erorii ( error latency ), care este intervalul de timp dintre
apariția erorii și căderea sistemului
propagarea erorii ( error propagation ), ceea ce înseamnă că eroarea se
poate răspândi în sistem datorită interacțiunii dintre componente
Dintr -o stare internă validă sistemul poate ajunge în stare eronată printr –
o tranziție eronată (cum este T1). Cauzele acestei tranziții sunt denumite
defecte și pot fi datorate atât stric ării unei componente (cauze previzibile), cât
și deficiențelor de proiectare hardware și software sau constructive (cauze
imprevizibile). Defectul (fault ) este deci o alterare fizică, o imperfecțiune sau un
viciu într -o componentă hardware sau software a s istemului. Defectul
reprezintă cauza unei erori și ca urmare se poate vorbi despre latența
defectului (fault latency ), ca fiind intervalul de timp dintre producerea
defectului și apariția erorii.
Între defect -eroare -defectare se poate descoperi o relație de tip cauză –
efect: manifestarea unui defect va produce eroare în starea internă a
sistemului, care la rândul său poate duce la căderea sistemului (o schimbare de
stare externă). De exemplu, punerea pe zero a unei linii de date va genera o
eroare de parita te, care, dacă nu este corectată, va duce la o funcționare
defectuoasă a sistemului. În funcție de locul producerii evenimentelor, aceste
concepte pot fi privite într -un model cu trei universuri (figura 2.3):
universul fizic, reprezentat de componentele (h ardware și software)
în care se pot produce defecte
Figura 2.2. Secvența stărilor interne ale unui sistem
universul informațional, conținând datele (în sens general) care pot fi
afectate de eroare
universul extern (al utilizatorului), în care se percepe o eventuală
defectare a sistemului
Relația de cauzalita te dintre defect -eroare -cădere poate fi pusă în
evidență și pornind de la cauzele defectelor , care pot fi în principal
următoarele:
greșeli de specificare, care constau în alegerea unor soluții
arhitecturale incorecte sau superficiale, respectiv a unor algoritmi
necorespunzători
greșeli de implementare, produse de o proiectare logică deficitară, o
compilare incorectă, sau utilizarea de componente neadecvate
perturbații externe, și anume radiații electromagnetice sau variații de
temperatură nepermis de mari
defecte de componente, care pot fi de fabricație, aleatoare sau
datorită îmbătrânirii
Relațiile de cauzalitate prezentate sunt ordonate ierarhic în figura 2.4.
Tot aici au fost reprezentate și limitele de aplicabilitate a mijloacelor de
realizare a unei dependabilități ridicate a sistemului. Evitarea defectului (fault
avoidance ) se înfăptuiește prin metode de proiectare adecvate, măsuri
constructive potrivit e, respectiv o selecție corespunzătoare a componentelor.
Figura 2.3. Relația defect -eroare -defectare intr -un model
cu trei universuri
Prin mascarea defectului (fault masking ) se urmărește prevenirea de se
introduce erori în sistemul informațional ca urmare a defectelor. Acest lucru se
poate realiza de exemplu prin coduri corectoare de eroare sau vot majoritar.
Tolerarea defectelor (fault tolerance ) presupune îndeplinirea sarcinilor
sistemului și după apariția unor defecte. De exemplu, prin reconfigurarea
sistemului devine posibilă eliminarea unității defecte și restaurarea sistemulu i
într-o stare operațională. Reconfigurarea este posibilă uneori doar prin
degradarea „grațioasă” a performanțelor ( graceful degradation ), și anume cu
menținerea unui set restrâns de funcții ale sistemului. Termenul „graceful
degradation” se referă la capa citatea sistemului de a -și reduce automat nivelul
de performanță în vederea compensării defectelor apărute, dar cu continuarea
funcționării.
Evaluarea modului în care s -au atins dezideratele propuse, legate de
dependabilitate se face prin verificarea și eliminarea defectelor găsite ( fault
removal ), respectiv prin prognosticarea defectelor (fault forecasting ). Această
din urmă soluție constă în analiza preventivă a sistemului pe bază de modele
stohastice.
Mărimile prin care se cuantifică dependabilitatea sistemului și pentru
Figura 2.4. Limitele de aplicabilitate a măsurilor de
creștere a dependabilității
care se fac evaluări, sunt:
Fiabilitatea (reliability ) R(t), care reprezintă probabilitatea ca sistemul să
funcționeze conform specificațiilor pe o perioadă de timp t, cu condiția ca la
începutul perioadei să fi fost operațional. Inversul fiabilității, și anume funcția
Q(t)=1R(t) arată nefiabilitatea sistemului (probabilitatea de defectare). O
mărime uzuală de exprimare a fiabilității este timpul mediu până la defectare ,
notat MTTF (Mean Time To Failure ). Acest indicator, spre deosebire de timpul
mediu dintre defectări (MTBF Mean Time Between Failures ), se folo sește
pentru a caracteriza un sistem în care momentele de nefuncționare sunt
inacceptabile. Toleranța la defecte reprezintă o tehnică de îmbunătățire a
fiabilității, dar un sistem de fiabilitate ridicată nu trebuie să fie în mod necesar
tolerant la defecte . De exemplu, un sistem poate fi construit din componente
de foarte bună calitate, dar la prima defectare sistemul cade. Creșterea de
fiabilitate obținută prin toleranță poate fi ilustrată simplist prin câteva calcule.
Dacă pentru sistemul netolerant fiabi litatea este dată de
R(t) = 1P1(t) ,
atunci pentru sistemul tolerant rezistent la n defecte ( n-resilient system ),
funcția de fiabilitate se poate evalua sub forma:
Rn(t) = 1Pn+1(t) = 1[P1(t)]n+1
Este evident că Rn(t)>>R(t). Cu P1(t) s-a notat probabilitatea de a avea un defect
în sistem.
Mentenabilitatea (maintainability ) M(t) înseamnă probabilitatea ca un
sistem neoperațional să fie repus în funcțiune într -un interval de timp t. Acest
indicator exprimă cât de ușor poate fi reparat sistemul. În această privință
trebuie remarcată importanța testabilității sistemului, care se poate asigura
printr -o proiectare pentru testabilitate ( DFT Design for Testability ).
Disponibilitatea (availability ) A(t) reprezintă probabilitatea ca sistemul să
fie operațional la un moment de timp t. Cu acest indicator se lucrează atunci
când este admisă defectarea sistemului, dar se presupune o depanare rapidă
sau înlocuirea părții defecte cu o unitate de rezervă. Dispo nibilitatea este
folosită pentru caracterizarea sistemelor la care este important ca să poată
furniza serviciile atunci când ele sunt cerute.
Performabilitatea (performability ) P(L,t) este probabilitatea ca la
momentul t sistemul să funcționeze cel puțin l a nivelul de performanță L.
Indicatorul este util atunci când se acceptă mai multe niveluri de performanță
specificate în funcțiile sistemului. Performabilitatea asigură un cadru unitar de
tratare a fiabilității și performanței.
Siguranța (safety ) S(t) rep rezintă probabilitatea ca sistemul să nu sufere
o cădere catastrofică pe durata t. Siguranța se mai definește ca și probabilitatea
ca sistemul ori să funcționeze corect ori, în caz de defectare, să -și întrerupă
funcțiile într -o manieră sigură pentru mediul său (fără a cauza o cădere
catastrofică). Un concept apropiat, dar diferit este securitatea (security ), care
se referă însă de exemplu la dificultatea de a avea acces la o bază de date.
Robustețea (robustness ) înseamnă probabilitatea ca sistemul să nu
furnizeze ieșiri incorecte, dacă i se aplică o intrare eronată. Această mărime
descrie modul în care sistemul reacționează la o intrare eronată.
Există diverse m etode de evaluare a mărimilor enumerate : calcul analitic,
scheme bloc de fiabilitate, arbori de defectare, modele bazate pe lanțuri
Markov etc. Ele sunt importante în procesul de elaborare a unui sistem tolerant
la defecte, deoarece permit demonstrarea caracteristicilor de toleranță la
defecte a sistemului.
2.2. Modelarea sistemelor
Complexitatea s istemelor de calcul actuale cere o structurare corespunzătoare
chiar din faza de proiectare, care trebuie să țină cont și de restricțiile impuse de
tehnologia de realizare. Prin adoptarea unei structuri adecvate se reduce
numărul de defecte reziduale și de vine mai ușoară introducerea tehnicilor de
toleranță la defecte.
Modelul este necesar (în contextul prezentei cărți) pentru a permite
studiul aspectelor de dependabilitate în general și de toleranță la defecte în
particular. Este util ca modelul să captez e pe lângă proprietățile sistemului și
caracteristicile structurale ale acestuia. Un sistem este format din subsisteme,
denumite și componentele sistemului. În cazul unui sistem de calcul se
deosebesc resursele hardware, interconectate prin legături fizice , și
componentele software, interconectate prin legături logice.
Sistemul (system ) constituie un ansamblu identificabil de componente a
căror interacțiune produce un comportament observabil la nivelul interfeței
sale cu mediul. Comportamentul sistemului es te rezultatul unei secvențe
controlate de stări interne și tranziții. La sistemele de calcul, interacțiunea
dintre componente are loc sub controlul unui proiect, care poate fi considerat
tot o componentă a sistemului.
În continuare se prezintă succint câte va modele frecvent întâlnite în
literatura de specialitate, grupate pe modele cu separare și modele ierarhice.
a) Modelele cu separarea părții hardware de cea software consideră
programul ca o parte izolată a sistemului, care este responsabilă de
manipularea resurselor hardware și a datelor. Un exemplu elocvent este
modelul interpretor , redat schematic în figura 2.5. Existența hardware -ului (H)
nu influențează comportarea sistemului, aceasta fiind determinată numai de
comportarea componentei software ( S) pentru toate combinațiile de intrare.
Ca urmare componenta H este un interpretor al lui S, iar i este interfața
interpretativă.
Figura 2.5. Modelul interpretor
b) Modelele ierarhice pun în evidență ierarhia structurală a componentelor
unui sistem. Exemple de astfel de modele sunt:
Modelul pe niveluri al lui Görke . Acest model se bazează pe principiul că
Figura 2.6. Principiul modelului pe niveluri
Figura 2.7. Exemplu de modelare a unui sistem distribuit
dacă dintr -un anumit nivel se solicită un serviciu unui subsistem din nivelul
imediat inferior, atunci funcția cerută se furnizează cu confirmarea îndeplinirii
sau anunțarea unui def ect (figura 2.6). O astfel de abordare oferă un model
pentru interpretarea influențelor din interiorul sistemului de calcul, așa cu se
poate vedea pe exemplul de sistem distribuit din figura 2.7. Un defect din
nivelul inferior se pune în evidență doar la a ccesul funcției corespunzătoare de
către nivelul superior.
Modelul pe componente consideră sistemul format din componente
care interacționează între ele. În această accepțiune, componenta reprezintă o
parte (hardware sau software) a sistemului care recepționează cereri (semnale,
instrucțiuni de apel, întreruperi etc.), le interpretează și furnizează un răspuns
(serviciu). Pentru satisfacerea serviciului componenta face apel la o
subcomponentă a sa, exceptând componenta atomică, care este ultima în
nivelul ierarhic (figura 2.8). Răspunsurile componentelor se defalcă în
răspunsuri normale și anormale (figura 2.9). Cele anormale provin ca urmare a
Figura 2.8. Principiul modelului pe componente
Figura 2.9. Defalcarea răspunsurilor la nivelul unei
componente
unui defect în componentă și se numesc excepții (exceptions ). Acest mod de
abordare permite separarea activității componentei în două părți (figura 2.10):
activitatea normală, reprezentând partea în care se implementează
serviciile corespunzătoare funcționării normale
tratarea excepțiilor ( exception handling ), constituind partea în care se
implementează măsurile de toleranță la defecte
După locul producerii, excepțiile se clasifică în excepții externe și interne.
Excepțiile externe pot fi de interfață sau de defectare. Cele de interfață
sugerează un defect de proiectare și apar ca răspuns la o cerere ilegală
(instrucțiuni inexistente, violare de adresă, de protecție), iar cele de defectare
indică defectarea componentei (de exemplu o eroare de paritate la citirea din
memorie). Excepțiile interne se generează ca urmare a detectării unei erori
chiar în cadrul compone ntei (de exemplu o eroare de paritate, dar corectabilă
pe baza informației redundante). Dacă se semnalează o excepție, atunci se
invocă automat handler -ul de excepții (exception handler ), acesta fiind extern
componentei la excepțiile externe, respectiv int ern acesteia la excepțiile
interne. Datorită structurii ierarhice a componentelor, excepțiile se propagă
automat de la un nivel la altul. Pe baza acestor concepte se poate modela
componenta idealizată tolerantă la defecte , reprezentată în figura 2.11. Este
de remarcat faptul că excepțiile de interfață fac parte din activitatea normală a
componentei. Dacă tratarea unei excepții (de la subcomponentă sau internă) se
face cu succes, atunci componenta revine la funcționarea normală. În caz
contrar însă, componen ta va semnala o excepție de defectare nivelului
superior.
Figura 2.10. Separarea activităților la nivelul unei
componente
Modelul orientat pe obiecte (propus de Levi). Obiectul se definește ca un
element distinct și accesibil în mod selectiv, a cărui logică (software) rezidă pe
una din resursele de memorare ale sistemu lui. Rezultă de aici că obiectul poate
ascunde și elemente hardware. Există un set de operații la care poate fi supus
un obiect și un set de operații pe care le poate solicita de la alte obiecte.
Vizibilitatea unui obiect este limitată, invocarea fiind pos ibilă numai printr -un
punct de acces pentru serviciu. Modelul propus se bazează pe unități
elementare (EU Elemental Unit ), o astfel de unitate fiind constituită din cinci
entități logice (figura 2.12):
date de intrare, invocații
condiționări și verificări de intrare
obiectul, care poate fi server (un obiect executabil care este supus
unei operații de către un alt obiect executabil, fără să poată opera el
însuș i asupra unui obiect executabil) sau agent (un obiect executabil
care operează asupra altui obiect executabil în folosul unui al treilea
obiect)
teste și stare de ieșire
Figura 2.11. Componenta idealizată tolerantă la defecte
date de ieșire, sincronizare
Unitatea elementară permite modelarea sistemului sub form a unui graf în care
nodurile sunt unitățile elementare, iar arcele orientate reprezintă transferuri
de date sau sincronizări (figura 2.13).
Figura 2.12. O unitate elementară
Figura 2.13. Un model cu unități elementare
2.3. Clasificarea defectelor
Clasificarea defectelor se poate face după mai multe criterii , cele mai uzuale
fiind: cauza, natura, extinderea și durata. Tipurile de defecte corespunzătoare
acestor criterii sunt sistematizate în schema din figura 2.14.
Defectele de proiectare se datorează unor greșeli umane, care pot fi de
specificare, de implementare ș.a. Defectele fizice corespund defectărilor de
componente (bruște sau parametrice), respectiv unor perturbații externe.
Sistemele abstracte c onțin numai defecte de proiectare, defectele fizice
datorate erodării în timp și modului de construcție sunt caracteristice
sistemului fizic prin care se realizează un sistem abstract.
Defectele hardware pot fi defalcate după valoare în defecte determinate
(a căror stare nu se schimbă, de exemplu punerea pe 1 sau 0) și nedeterminate
(care produc valori logice oscilante). Partea de software poate conține de
asemenea defecte datorate greșelilor din program, de compilare ș.a. Este de
remarcat faptul că defectele hardware pot produce uneori aceleași manifestări
ca și defectele software. Exemple clasice în acest sens sunt alterarea memoriei
programului sau a contorului de program.
Extinderea defectului se referă la răspândirea erorii generate, care poate
fi locală sau distribuită în întregul sistem (globală).
Clasificarea defectelor după durată se referă la timpul cât defectul este
activ. Defectul permanent (numit și monoton sau durabil) se menține activ pe
timp nelimitat dacă nu se ia nici o măsură de corecție. Defectul tranzitoriu
(temporar, trecător) apare pentru un timp, după care dispare în mod spontan.
De exemplu, perturbațiile fac parte din această clasă. Defectul intermitent
reprezintă un defect tranzitori u care revine în mod repetat.
Figura 2.14. Tipuri de defecte
Referitor la consecințele defectelor asupra sistemului, există diferite
moduri de defectare ale acestuia:
căderea ( crash ) corespunde situației când sistemul se oprește din
funcționare
omisiunea ( omission ) înseamnă că în mod tr ecător sistemul nu
produce valoarea de la ieșire
defectarea temporală ( timing failure ) reprezintă cazul când se
produce valoare corectă la ieșire, dar nu la momentul corespunzător
specificațiilor
defectarea de valoare ( value failure ) apare atunci când valo area la
ieșire se produce la momentul potrivit, dar ea este incorectă
defectarea arbitrară sau bizantină ( Byzantine failure ) corespunde
cazului în care sistemul prezintă o comportare oarecare lipsită de
sens, haotică
După previzibilitatea comportării după defectare și riscul implicat,
sistemele pot fi eșalonate pe mai multe niveluri:
fail-operational , dacă sistemul funcționează conform specificațiilor, cu
tolerarea defectelor apărute
fail-soft, când sistemul funcționează, dar cu performanțe reduse
fail-safe, în cazul în care sistemul asigură numai un minim de funcții
cu care se garantează siguranța aplicației
fail-stop , atunci când sistemul se oprește din funcționare la
detectarea erorii pierzându -și starea internă
fail-unsafe , în situația în care comportarea sistemului nu este
previzibilă
2.4. Redundanța
Redundanța (redundancy ) reprezintă totalitatea elementelor suplimentare
adăugate la sistem și care nu ar fi necesare pentru satisfacerea funcțiilor într -o
lume lipsită de defecte. Prevederea r edundanței reprezintă mijlocul prin care
se conferă unui sistem caracterul de toleranță la defecte. Clasificarea se face
după formele redundanței, așa cum este arătată în figura 2.15.
Figura 2.15. Clasificarea tipurilor de redundanță
Redundanța fizică (physical redundancy ) presupune o replicare a
resurselor (hardware și software) în scopul detectării și tolerării defectelor.
Ideea de bază constă în executarea în paralel de alternartive, urmată de o
comparare sau votare asupra rezultate lor. Devine astfel posibilă tolerarea
defectelor permanente. Redundanța fizică (sau structurală) poate fi realizată
atât în partea de hardware, cât și în cea de software. Redundanța hardware
poate fi statică , atunci când maschează efectul căderii unei comp onente,
împiedicând producerea unei erori în sistem, sau dinamică , dacă asigură
detectarea unei erori și apoi întreprinderea unei acțiuni colective cu ajutorul
unei redundanțe până acum pasive pentru înlăturarea defectului. Este necesară
precizarea distinc ției dintre redundanța activă și pasivă. Redundanța activă
(caldă) presupune o participare continuă la realizarea funcțiilor sistemului, pe
când redundanța pasivă de rezervă ( standby redundancy ) își va manifesta
efectul doar după detectarea erorii.
Redunda nța temporală (temporal redundancy ) presupune un timp
suplimentar utilizat pentru repetiția execuției pe aceeași resursă. Metoda este
adecvată pentru tolerarea defectelor tranzitorii, dar totodată impune precauție
în sistemele de timp real.
Redundanța info rmațională (informational redundancy ) necesită
adăugarea unei informații suplimentare la cea utilă, astfel încât prin codificare
să se poată realiza detectarea și corectarea erorii.
Așa cum s -a arătat, prin introducerea toleranței la defecte se urmărește
creșterea fiabilității sistemului. Acest lucru se poate realiza numai prin
redundanță, însă prin prevederea de componente suplimentare crește
complexitatea sistemului. Dar, pe de altă parte, se știe că odată cu mărirea
complexității scade fiabilitatea. So luția la această problemă este una de
optimizare, și anume: minimizarea redundanței utilizate cu maximizarea
fiabilității în condiții de cost acceptabile. În timpul procesului de proiectare se
ivesc soluții alternative pentru măsurile de toleranță și apare întrebarea unde
să fie amplasate aceste măsuri? Există în principiu două soluții extreme asupra
locului unde se pot prevedea măsurile de toleranță:
la nivelul componentei, o soluție ieftină, dar eficientă numai pentru
tolerarea unor anumite tipuri particu lare de defecte
la nivelul sistemului, o rezolvare care permite tolerarea unei game
mai largi de defecte, dar este scumpă
Experiența a demonstrat că pentru defectele previzibile măsurile
specifice la nivelurile inferioare sunt mai eficiente și necesită mai puțină
redundanță, pe când împotriva defectelor neprevăzute sunt de preferat măsuri
globale. Calculele simple de fiabilitate arată că redundanța aplicată la nivelul
componentei este mai eficace decât cea aplicată la nivelul întregului sistem.
Într-adevăr, fie sistemul serial S1 cu două componente identice din figura 2.16,
fiecare componentă având fiabilitatea R. Fiabilitatea acestui sistem este RS1,
expresia ei fiind dată lângă figură. Utilizând conceptul redundanței globale se
obține sistemul S2, cu funcția de fiabilitate RS2. Prin aplicarea redundanței la
nivelul fiecărei componente a sistemului inițial, rezultă sistemul S3, care are
fiabilitatea RS3. Prin compararea celor trei expresii se confirmă afirmația
anterioară, și anume faptul că RS1 < RS2 < RS3 pentru R(0,1).
Introducerea redundanței în sistem poate avea urmări importante
asupra performanței, dimensiunii, consumului și fiabilității sistemului, aspecte
care trebuie cu atenție luate în calcul la elaborarea unui sistem nou.
2.5. Scenariul toleranței la defecte
Scopul toleranței la defecte constă în a preveni ca defectele și erorile pe care
acestea le produc să ducă la defectarea sistemului. În general, în cadrul
acțiunilor de toleranță la defecte se presupun următoarele patru faze:
detectarea erorii, evaluarea și îngrădirea pagubei, tratarea erorii, tratarea
defe ctului și continuarea serviciului. Activitățile legate de aceste faze sunt
sistematizate în figura 2.17.
Detectarea erorii (error detection ) urmărește punerea în evidență a unei
stări interne eronate a sistemului. Pentru a putea tolera un defect în sistem,
prima dată este necesar să se afle despre apariția acestuia, ceea ce se poate
face numai prin detectarea efectului său, adică a erorii.
Evaluarea și îngrădirea pagubei (damage assessment and confinement )
presupune identificarea ariei pe care s -a extins er oarea și limitarea propagării
sale în continuare. Această fază este necesară deoarece între producerea
defectului și detectarea unei erori cauzate de defect există un decalaj în timp.
Figura 2.16. Comparație între un sistem neredundant (S1), un sistem
cu redundanță globală (S2) și un sistem cu redundanță
la nivelul componentelor (S3)
În acest interval de timp se puteau genera și răspândi în sistem informa ții
invalide nedetectate, dar cauzate de același defect.
Tratarea erorii (error procesing ) urmărește construirea unei stări lipsite
de eroare prin tratarea erorii efective (effective error proces sing). Acest
obiectiv se poate realiza în două moduri:
prin transformarea stării curente eronate a sistemului într -o stare
bine definită lipsită de eroare, acțiune numită restabilire din starea
de eroare (error recovery )
prin compensarea erorii (error comp ensation ) datorită informației
redundante disponibile
Restabilirea din eroare are scopul de a aduce sistemul într -o stare consistentă
lipsită de eroare. Starea consistentă (consistent state ) este cea conformă cu
stările interne corect accesibile ale sistemului și cu istoricul evenimentelor
externe reflectate în comportarea sistemului. Restabilirea se poate face în două
feluri:
restabilire înapoi (backward recovery ), când sistemul se aduce într -o
stare anterioară fără eroare, numită punct de restabilir e (recovery
Figura 2.17. Fazele toleranței la defecte
point ) sau punct de control ( checkpoint ) pentru care se cunosc
informațiile de stare necesare reluării execuției
restabilire înainte (forward recovery ), dacă sistemul se duce într -o
nouă stare, lipsită de eroare, conformă cu aplicația și cu con diția de
consistență, fără a fi necesare informațiile de stare trecute
Restabilirea din eroare se realizează pe bază de redundanță dinamică. Se
încearcă să se evite răsfrângerea erorii prin construirea unei stări neeronate,
înlăturând prin aceasta starea e ronată în nivelul afectat. Compensarea erorii
caută să reprime transmiterea erorii în nivelul următor prin mascarea erorii
(error masking ) sau corectarea erorii (error correcting ), fără a înlătura însă
eroarea în nivelul respectiv. Pentru aceasta se utili zează redundanța statică.
Tratarea defectului și continuarea serviciului (fault treatment and
continue service ) presupune revenirea sistemului la modul normal de
funcționare din starea lipsită de eroare. Trecerea la un sistem lipsit de defecte
se face prin tratarea erorii latente (latent error processing ). Tratarea erorii
latente, care reprezintă de fapt tratarea defectului, are ca scop prevenirea unei
reapariții imediate a erorii și presupune înlăturarea cauzei acesteia, adică a
defectului. Această acțiune se efectuează prin localizarea defectului (fault
location ) urmată de pasivizarea erorii (error passivation ) prin excluderea
componentei defecte și reconfigurarea sistemului ( reconfiguration ).
Reconfigurarea reprezintă operația de reparare a sistemului prin înlocuirea
Figura 2.18. Scenariul toleranței la defecte
unei componente defecte cu o rezervă sau redistribuirea sarcinilor printre
resursele rămase funcț ionale. În urma reconfigurării poate rezulta o degradare
„grațioasă” a performanței ( graceful degradation ), astfel încât sistemul să se
rezume numai la îndeplinirea sarcinilor strict necesare.
Pe baza fazelor enumerate, se obține un scenariu al toleranței la defecte,
care este prezentat schematic în figura 2.18. Între faze pot exista suprapuneri,
respectiv ordinea se poate schimba de la caz la caz. Detectarea erorii este în
mod firesc prima fază, dar celelalte pot fi și în altă ordine decât cea d ată mai
sus. Mai mult, nu trebuie ca toate fazele să fie prezente într -un sistem
particular. De exemplu, dacă prin tratarea erorii efective șansele revenirii erorii
au fost înlăturate, atunci tratarea erorii latente nu se mai realizează. În alte
situații u nele măsuri, cum ar fi evaluarea pagubei, se consideră în faza de
proiectare, prin prevederea unui mecanism de protecție pentru izolarea
proceselor. O caracteristică în proiectarea unui sistem de calcul tolerant la
defecte este de a decide în ce măsură ace ste faze vor fi implementate în sistem
și care vor fi acelea prezente în timpul exploatării sistemului.
3. TEHNICI DE TOLERANȚĂ LA DEFECTE
3.1. Redundanța hardware
3.1.1. Redundanța statică
Redundanța statică se bazează pe conceptul mascării defectelor ( fault masking )
și împiedicarea astfel a transformării lor în erori care ar putea să se propage în
sistem. La apariția unui defect nu este necesară nici o modificare structurală a
sistemului, acesta asigurând implicit (în mod static) tolerarea defectului.
Principiul utilizat este cel al multiplicării ( replicării ) sistemului, urmat de un vot
majoritar . De aceea, acest tip de sistem tolerant la defecte se numește
structură redundantă de tip logică majoritară .
Cea mai simplă configurație este sistemul cu redundanță triplă modulară
TMR ( Triple Modular Redundancy ), format din trei module identice (figura 3.1).
Pentru a funcționa corect este necesar ca din totalul de trei, cel puțin două
module să fie operaționale, ieșirile modulelor fiind comparate de un voter care
selectează valoarea corespunzătoare majorității. Astfel sistemul permite
tolerarea defectării unui singur modul. În schimb, voterul reprezintă punctul
slab al sistemului, deoarece dacă e l se defectează, atunci întregul sistem cade.
Este interesant de studiat în ce măsură se poate obține creșterea
fiabilității prin utilizarea sistemului TMR. Dacă R reprezintă fiabilitatea unui
Figura 3.1. Schema de redundan ță triplă modulară
modul și Rv fiabilitatea voterului, atunci corespunzător celor patru situații
funcționale posibile, fiabilitatea sistemului TMR va fi:
RTMR = [R3 + 3R2 (1R)]Rv = (3R2 2R3)Rv
Dacă se admite că voterul este perfect ( Rv=1), pentru ca fiabilitatea sistemului
TMR să fie mai mare decât fiabilitatea unui modul, este necesar ca 3 R22R3>R,
adică 2 R23R+1<0. Aceasta se mai poate exprima (2 R1)(R1)<0, de unde
rezultă R>0,5. Se poate deci scrie:
5,0 dacă 5,0 dacă 5,0 dacă
R RR RR R
RTMR
În concluzie, fiabilitatea sistemului TMR va fi mai mare decât cea a unui singur
modul până când fiabilitatea modulului se situează peste valoarea de 0,5.
Acesta este un exemplu care demonstrează că nu întotdeauna un sistem care
poate tolera defecte trebuie în mod necesar să fie și mai fiabil decât sistemul
simplu netolerant.
Presupunând cazul uzual al unei distribuții exponențiale a timpului de
defectare a unui modul ( R=et), se poate determina timpul T după care RTMR=R.
Se obține:
3 22 3e e eT T T
eT 1
2
Tln , 207
Așa cum se poate observa și pe graficul din figura 3.2, sistemul TMR asigură o
creștere a fiabilității față de sistemul simplu numai pentru un timp de misiune
scurt ( t<T).
Un alt criteriu de comparare a sistemului TMR cu cel simplu este pe baza
timpului mediu de defectare ( MTTF ). Efectuând calculele pentru cazul
distribuției exponențiale, se obține:
pentru sistemul simplu,
MTTF edtSt
01
pentru sistemul TMR,
MTTF e e dtTMRt t
3 25
62 3
0
Figura 3.2. Comparație între fiabilitatea sistemului cu redundanță triplă
modulară (R TMR)și fiabilitatea sistemului singular (R)
Rezultă deci că MTTF TMR<MTTF S, ceea ce ar putea conduce la ideea că sistemul
TMR nu este așa de bun decât cel simplu. MTTF este însă un indicator mediu
care poate să nu reprezinte exact calitatea sistemului, care , așa cum s -a văzut,
pentru t<T prezintă avantaj pentru sistemul TMR sub aspectul fiabilității.
Expresia de fiabilitate calculată pentru sistemul TMR poate fi considerată
pesimistă, dacă se are în vedere faptul că la blocarea pe “1” a ieșirii unui modul
și pe “0” a unui al doilea modul, sistemul maschează ambele defecte:
Întrucât această stare poate apărea în 50% din situațiile în care două module
sunt defecte, funcția de fiabilitate care se scrie corespunzător stărilor
favorabile ale sistemului, devine:
R R R R R R R RTMR3 2 2 33 13
213
21
2( ) ( )
În această relație voterul s -a considerat a fi perfect. Este clar că în acest caz
RTMR>R pentru orice t>0, deoarece
3
21
23R R >R conduce la (1 R)(1+R)>0, ceea
ce este adevărat pentru R subunitar.
Voterul realizează un test relativ între datele furnizate de modulele
sistemului. Acest proces de comparare poate fi realizat atât pe cale hardware,
cât și pe cale software. În ambele cazuri se pune însă problema de a asigura
validitatea datelor la intrări le voterului la momentul oportun. Problema se
rezolvă prin amplasarea unor elemente de memorare pe ieșirile modulelor. La
voterul hardware aceste elemente sunt circuite latch acționate sincron cu un
semnal de tact, iar la voterul software sunt buffer -e sau memorii dublu -port
accesibile atât modulului respectiv, cât și procesorului care rulează programul
de votare.
Pentru a preveni căderea sistemului la defectarea v oterului, s -a conceput
schema cu triplarea voterului. Mai multe astfel de sisteme TMR pot fi conectate
în cascadă, ceea ce duce și la triplarea tuturor căilor de date (figura 3.3). Un
sistem TMR cu votere triple constituie un organ de restabilire , deoarece
produce trei ieșiri corecte, chiar dacă o intrare este defectă. Eroarea introdusă
de defectarea unui voter dintr -un nivel va fi corectată de nivelul următor.
Un exemplu de utilizare a redundanței TMR este cel de la sistemul FTMP
(Fault Tolerant Multiprocessor ), unde procesoarele și memoriile sunt organizate
pe triade (figura 3.4). O triadă de procesoare se comportă ca și cum ar fi un
singur procesor: procesoarele componente execută exact același program și
funcționează riguros sincronizate cu același tact. Asupra rezultatelor se
efectuează un vot majoritar la înscrierea în memorie, fiind astfel posibilă
tolerarea unui procesor defec t. De asemenea, toate componentele de memorie
vor primi date corecte. La transferul informației dinspre memorie spre
Figura 3.3. Conectarea în cascadă a sistemelor TMR
cu triplarea voterelor
Figura 3.4. Utilizarea redundanței triple modulare la
sistemul multiprocesor FTMP
procesoare, se efectuează o nouă operație de votare la intrarea fiecărui
procesor.
O generalizare a conceptului TMR este redundanța N -modulară NMR ( N-
Modular Redundancy ), care utilizează N copii ale modulului cu un vot majoritar
la ieșire (figura 3.5). În mod normal N reprezintă un număr impar, pentru a
evita starea incertă în care nu se poate decide majoritatea. Prin utilizarea
redundanței NMR devine posibilă tolerarea unui număr mai mare de defecte
decât la cazul cu trei module. De exemplu, structura 5MR poate tolera două
defecte, ceea ce îl recomandă pentru aplicații critice.
Dacă se consideră N=2p+1, atunci fiabilitatea sistemului NMR se poate
scrie ca și probabilitatea de a avea cel puțin p+1 module funcționale ( p=1, 2,…).
Expresia funcției de fiabilitate a acestui sistem de tip p+1 din N este
N
piiN i
iN
V NMR R R R R
1) 1(
,
unde RV reprezintă fiabilitatea voterului. Numărul maxim de defecte mascate
este egal cu p. În cazul în care p=1, relația se particularizează pentr u sistemul
TMR.
Așa cum s -a arătat deja, procesul de votare poate fi realizat și pe cale
software, folosind capacitatea de calcul disponibilă a unui procesor. Această
metodă are avantajul de a reduce la minim necesarul de hardware suplimentar,
Figura 3.5. Schema de principiu a red undanței N -modulare
dar timpul c onsumat pentru votare este mai mare decât la soluția hardware.
Votarea prin program se utilizează de exemplu la sistemul SIFT ( Software
Implemented Fault Tolerance ), care implementează conceptul redundanței
NMR. Sistemul constă din N canale independente, interconectate fiecare cu
fiecare prin câte o linie de comunicație. Datele de intrare într -un task al unui
procesor sunt rezultatul unui vot majorita r asupra rezultatelor taskului
anterior, furnizate de toate procesoarele. Este avantajos faptul că acest mod de
lucru nu necesită o sincronizare strictă a procesoarelor. Operația de votare
pentru cazul a trei procesoare este reprezentată schematic în figur a 3.6. Se
consideră că taskul B primește intrările de la taskul A. Când taskul A s-a
terminat, rezultatele sale sunt depuse în câte un buffer la nivelul fiecărui
procesor. Datele de intrare pentru taskul B sunt furnizate de către un executiv
local, care ef ectuează un vot majoritar asupra rezultatelor taskului A, care au
fost recepționate de la toate procesoarele. Executivul local este de asemenea
responsabil de raportarea erorilor care apar.
O problemă a redundanței N -modulare constă în faptul că după
defec tarea unui număr de module, acestea ar putea fi cele care să formeze
majoritatea și să producă o ieșire eronată fără a fi observată. Acest dezavantaj
se poate elimina prin reconfigurarea sistemului, fiind utilizabile două tehnici de
redundanță hibridă. Pri ma se bazează pe modificarea dinamică a procesului de
votare pe măsură ce sistemul se deteriorează, iar a doua urmărește înlocuirea
modulelor defecte cu rezerve până atunci neutilizate.
Redundanța statică se utilizează cu precădere în sistemele critice l a
defectare, la care furnizarea unui rezultat fals, chiar pe durată scurtă, este
Figura 3.6. Efectuarea votului majoritar prin software la
sistemul multiprocesor SIFT
inacceptabilă. Pentru a asigura mascarea defectului este nevoie însă de
hardware suplimentar, care face ca această metodă să fie scumpă.
3.1.2. Redundanța dinamică
Acest tip de redundanță se bazează pe ideea comutării automate a ieșirii
sistemului pe un modul de rezervă funcțional ( standby ) după detectarea unei
erori. Schema de principiu a metodei este cea din figura 3.7. În cazul detectării
erorii la nivelul modulul ui activ M1, comutatorul K va comuta pe modulul M2,
care până acum a fost pasiv (nu a contribuit la formarea ieșirii sistemului).
Datorită posibilității modificării dinamice a sistemului, această configurație se
mai numește și structură redundantă prin com utație . Comutatorul, care poate
fi implementat în variantă digitală sau analogică în funcție de aplicație, trebuie
să fie de fiabilitate înaltă.
Pentru a funcționa corespunzător, la un asemenea sistem se pune
problema implementării unei metode eficiente de detectare a erorii. În acest
scop există mai multe tehnici, cum ar fi efectuarea unui test absolut al ieșirii (de
exemplu verificarea încadrării rezultatului între anumite limite), utilizarea
codurilor detectoare de eroare sau a unui ceas de gardă ( watchdog ) (vezi 4.1).
La rândul său, modulul care stă în așteptare poate fi o rezervă caldă sau
rece. În primul caz modulul lucrează sincron cu cel activ și ca urmare tim pul de
întrerupere a funcționării sistemului va fi minim. Rezerva rece nu se
alimentează cu tensiune decât în momentul în care va înlocui modulul defect.
Această soluție are avantajul unui consum redus de energie electrică, criteriu
important de exemplu în tr-un satelit artificial.
Întrucât, spre deosebire de redundanța statică, la redundanța dinamică
eroarea nu mai este mascată, pe lângă detectarea erorii este necesară și
Figura 3.7. Schema de principiu a sistemului cu
redundanță dinamică
prevenirea propagării datelor eronate peste anumite limite. De asemenea,
reluarea func țiilor sistemului de către noul modul necesită reconstituirea unei
stări operaționale lipsite de eroare. Procesul de detectare și izolare a erorii,
urmat de restabilire prin excluderea modulului defect, reprezintă de fapt o
reconfigurare a sistemului. Este posibil ca modulul de rezervă, dacă nu este
identic cu cel inițial, să nu poată asigura toate funcțiile sistemului, decât o parte
dintre acestea. Se spune în acest caz că prin reconfigurare are loc o degradare
admisibilă a performanței ( graceful degradati on).
Redundanța protectivă dinamică conferă sistemului caracterul de a fi
autoreparabil prin înlocuirea automată a modulului defect cu altul identic, dar
funcțional. Acest lucru face ca asemenea sisteme să fie utilizate în aplicații cu
timpul lung al misiu nii, unde intervenția omului nu este posibilă.
Pentru a calcula fiabilitatea sistemului cu redundanță dinamică, se
consideră că cele două module au fiabilitatea R1, respectiv R2 și comutatorul
este perfect fiabil. Schema bloc de fiabilitate a acestui siste m este o schemă de
tip paralel. Sistemul va funcționa corect dacă este îndeplinit unul din
următoarele evenimente:
1. Modulul M1 funcționează corect.
2. Modulul M1 s-a defectat, defectul a fost detectat și tratat
corespunzător, iar modulul M2 funcționează corect.
Evenimentele 1 și 2 fiind incompatibile, fiabilitatea sistemului este dată de
suma probabilităților corespunzătoare celor două situații favorabile:
Rd = R1 + (1R1)C1R2
În această relație C1 reprezintă factorul de acoperire (fault c overage ) asociat
modulul M1. El exprimă probabilitatea ca în cazul apariției unui defect, acesta
va fi detectat și sistemul va fi capabil să -și restabilească starea operațională:
C1 = Pr{sistemul se restabilește | M1 se defectează}
Dacă cele două module sunt identice, atunci funcția de fiabilitate a
sistemului devine
Rd = R + CR(1R) ,
unde R reprezintă fiabilitatea unui modul, iar C factorul de acoperire.
Fiabilitatea sistemului în funcție de factorul de acoperire este o funcție liniară
care are graficul din figura 3.8. Se observă că dacă acoperirea este zero, atunci
fiabilitatea sistemului este egală cu R, adică tocmai cu probabilitatea ca
modulul primar s ă nu se defecteze. În cazul în care C=1, se obține expresia de
fiabilitate a unui sistem paralel perfect:
Rd = 2RR2 = 1(1R)2
Este de menționat faptul că în analiza de mai sus defectarea modulului
M2 nu are importanță până când modulul primar M1 funcționează corect. Acest
lucru nu este însă adevărat în cazul unui sistem care utilizează tehnica de
duplicare cu comparare (duplicati on with comparison ) ca și o formă de
detectare a erorii (figura 3.9).
Figura 3.8. Graficul fiabilității sistemului cu redundanță
dinamică în funcție de factorul de acoperire
În mod normal această schemă nu permite tolerarea, decât detectarea
apariției unui defect, care reprezintă c azul limită al toleranței la defecte. Este
posibil însă, ca în situația în care comparatorul pune în evidență o eroare,
sistemul să execute un proces de autodiagnoză în vederea identificării
modulului defect. Dacă acesta poate fi localizat, atunci celălalt modul va
îndeplini singur funcțiile sistemului. Acest mecanism se numește duplicare
reconfigurabilă (reconfigurable duplication ). Sistemul funcționează corect dacă
ambele module sunt operaționale sau defectarea unui modul a fost detectată și
tratată cores punzător. Funcția de fiabilitate a sistemului se poate scrie pe baza
stărilor funcționale sub forma
Rd = R1R2 + (1R1)C1R2 + R1(1R2)C2 ,
unde C1 este factorul de acoperire al autodiagnozei modulului M1, iar C2 cel al
modulului M2. Dacă fiabilitățile celor două module, precum și factorii lor de
acoperire sunt identice ( R, respectiv C), atunci funcția de fiabilitate devine:
Rd = R2 + 2RC(1R)
Această funcție are graficul din figura 3.10. Se observă că pentru factorul de
acoperire unitar se obține, ca și înainte, fiabilitatea sistemului perfect de tip
paralel, iar pentru C=0 rezultă Rs=R2, adică probabilitatea ca ambele module să
funcționeze cor ect.
Figura 3.9. Schema de utilizare a duplicării cu comparare
Un exemplu de implementare a duplicării reconfigurabile este dat în
figura 3.11. Procesoarele A și B execută aceeași ap licație și depun rezultatele
atât în propriile memorii, cât și în memoria dublu -port accesibilă ambelor
procesoare. Fiecare procesor execută un proces de comparare software între
datele proprii și cele ale procesorului pereche. În cazul în care o neconcord anță
este detectată, fiecare procesor va genera o excepție pentru tratarea defectului
la nivelul aceleiași componente (vezi modelul pe componente de la 2.2) și va
trece la un program de autodiagnoză pentru a determina dacă el este cel
defectat. Odată ident ificat procesorul defect, acesta va inhiba ieșirile sale,
astfel încât ieșirea corectă a sistemului va fi asigurată de celălalt procesor. În
continuare este evident că un al doilea defect nu mai poate fi tolerat. Printr -o
logică adecvată se poate asigura c a în lipsa oricărui defect, tamponul de ieșire
al procesorului A să fie cel validat. Este de menționat faptul că utilizarea
programului de autodiagnoză duce la un efort de calcul suplimentar, acest
procesor nefiind de tip autotestabil în sensul subcapitolu lui 3.5.
Avantajul metodei de duplicare cu comparare constă și într -o latență
redusă a erorii față de cazul neredundant.
Figura 3.10. Graficul fiabilității sistemului cu duplicare
reconfigurabilă în funcție de factorul de acoperire
În continuare se prezintă două scheme bloc de sisteme tolerante la
defecte care utilizează redundanța dinamică.
La tehnica standby sparing (to spare = a pune de o parte ) unul din cele N
module identice este utilizat pentru furnizarea funcției de ieșire, restul de N1
module fiind de rezervă (figura 3.12). Circuitul de ieșire al schemei lucrează în
principiu ca un comutator, care pe baza semnalelor de eroare sosite de la
circuitele de detectare a erorii selectează modulul care va fi activ. Selecția se
poate face pe bază de priorități fixe, la această acțiune p articipând numai
modulele funcționale. Sistemul astfel construit poate tolera până la N1
defecte apărute la nivelul modulelor.
Extrapolând ideea utilizării rezervelor la un sistem multiprocesor cu N
procesoare identice, prin includerea în sistem a S module de rezervă devine
posibilă protecția sistemului la tot atâtea defectări ale procesoarelor originale.
Coeficientul de redundanță necesar ( S/N) poate fi suficient de redus pentru a
face soluția acceptabilă.
Figura 3.11. Sistem de calcul cu duplicare reconfigurabilă
Tehnica pair-and-spare (pair = pereche) combină caracteristicile metodei
precedente și a dublării cu comparare. În acest caz două module sunt active la
un moment dat, rezultatele lor fiind comparate la ieșire. Dacă se detectează o
discrepanță între datele furnizate, modulul defect se înlocuiește cu unul dintre
cele de rezervă. Identificarea modulului defect al perec hii active reprezintă o
problemă, de aceea s -a propus împerecherea permanentă a modulelor, astfel
Figura 3.13. Schema de p rincipiu a tehnicii pair -and-spare
Figura 3.12. Schema de principiu a tehnicii standby sparing
încât dacă se detectează o eroare atunci ambele module se înlocuiesc. Schema
de principiu a acestei tehnici este ilustrată în figura 3.13. Avantajul său const ă
într-o detectare timpurie a erorilor și prevenirea astfel a propagării lor în
sistem.
Un exemplu de utilizare a metodei pair-and-spare este la sistemul
Stratus, unde fiecare componentă din sistem lucrează prin dublare cu
comparare (figura 3.14). Compone ntele lucrează în perfect sincronism și
debitează tot timpul date pe magistrală. Dacă comparația la nivelul unei
componente indică eroare, atunci se deconectează de magistrală prin driverele
sale, urmând ca cealaltă componentă de același tip să asigure fun cționarea în
continuare a sistemului.
În general redundanța dinamică se utilizează la sistemele cu durata lungă
de viață, respectiv cu disponibilitate ridicată, la care se poate accepta temporar
ca ieșirea să fie eronată, dar restabilirea stării funcționale se face rapid prin
reconfigurare. Această formă de redundanță utilizează cel mai puțin hardware
suplimentar, fiind sub acest aspect cea mai ieftină.
Figura 3.14. Utilizarea tehnicii pair -and-spare la sistemul
de calcul Stratus
3.1.3. Redundanța hibridă
Tehnica de redundanță hibridă îmbină redundanța logică majoritară cu o
structură de comutație. Votul majoritar asigură mascarea unui defect,
împiedicând astfel furnizarea unui rezultat eronat. În cazul producerii unui
defect se face reconfigurarea sistemului prin detectarea și localizarea acestuia,
urmate de operația de restabilire.
Conceptul de bază al redundanței hibride se materializează în
redundanța N -modulară cu rezerve (NMR with spares ), care are schema de
principiu din figura 3.15. Un nucleu format din N module identice participă tot
timpul la vot, determinând ieșirea sistemului. Detectorul de eroare compară
ieșirea voterului cu ieșirile modulelor active și asigură astfel localizarea u nui
modul defect care va fi înlocuit prin intermediul rețelei de comutare cu un
modul de rezervă. Schema va funcționa corect și după epuizarea modulelor de
rezervă ca o structură NMR statică, până la defectarea majorității modulelor
din cele N. Dacă iniția l sistemul conține N+S module și N=2p+1 (unde p = 1, 2,
3,…) , atunci sistemul poate tolera defectarea unui număr de p+S module. De
exemplu, un sistem cu redundanță hibridă cu patru module, dintre care trei
sunt active, poate tolera două defecte. Sub aces t aspect soluția este
avantajoasă față de redundanța statică, unde pentru a tolera două defecte sunt
necesare cinci module în sistem.
Presupunând că fiabilitatea modulelor de bază și de rezervă este aceeași
(R), fiabilitatea sistemului este dată de expresi a
SN
piiSN i
iSN
VSD h R R R R
1) 1(
,
unde RVSD reprezintă fiabilitatea subsistemului voter -comutator -detector. Se
poate calcula că în cazul unui subsistem voter -comutator -detector perfect,
fiabilitatea sistemul TMR cu o rezervă (adică N=3, S=1) este mai mare decât a
unui sistem simplex (cu un singur modul) dacă R>0,23. Fiabilitatea rețelei de
comutare poate fi însă determinantă asupra fiabilității sistemului, având în
vedere faptul că complexitatea comutatorului crește rapid pe măsură ce N și S
devin mai mari.
O altă implementare a conceptului de redundanță hibridă este
redundanța cu autoeliminare (self-purging redundancy ). În acest caz rețeaua
de comutare complicată de la soluția anterioară a fost eliminată, așa cum se
poate constata pe schema din figura 3.16. Inițial toate cele N module sunt
conectate la voter și ieșirea fiecărui modul este comparată cu cea a voterului.
Dacă se detectează o eroare, atunci modulul în cauză se autoelimină din
procesul de votare.
Figura 3.16. Principiul utilizării redundanței cu autoeliminare
Figura 3.15. Schema de principiu a sistemului cu redundanță
N-modulară cu rezerve
Voterul utilizat la această tehnică de redundanță trebuie să fie un
detector de prag. Fiecare intrare a voterului are asociată câte o pondere wi,
astfel încât dacă pe cele n intrări sosesc semnalele binare x1, x2, …, xn și pragul
voterului este T, atunci la ieșirea sa se generează semnalul:
zwxT
wxTii
in
ii
in
1
01
1 dacã
dacã
Decizia voterului se bazează pe suma ponderată a intrărilor, ponderea unei
intrări având de regulă valoarea 1 dacă modulul corespunzător este activ,
respectiv 0 dacă modulul se consideră deconec tat. Datorită acestei modificări
în timp a ponderilor, acest mod de votare se mai numește votare adaptivă .
Tabelul de funcționare al unui voter cu logică de prag care are patru intrări
(fiecare cu ponderea 1) și pragul T=2 este:
x1 x2 x3 x4 Suma
ponderată Ieșirea
0 0 0 0 0 0
0 0 0 1 1 0
0 0 1 0 1 0
0 0 1 1 2 1
0 1 0 0 1 0
0 1 0 1 2 1
0 1 1 0 2 1
0 1 1 1 3 1
1 0 0 0 1 0
1 0 0 1 2 1
1 0 1 0 2 1
1 0 1 1 3 1
1 1 0 0 2 1
1 1 0 1 3 1
1 1 1 0 3 1
1 1 1 1 4 1
În caz de neconcordanță a ieșirii unui modul cu ieșirea sistemului, logica de
comutare trebuie să forțeze la zero ponderea asociată acestui modul, ceea ce
se traduce practic în punerea pe valoare logică zero a liniei respective. De
exemplu, un sistem cu pa tru module și un voter cu pragul 2 va furniza ieșirea
corectă și după defectarea a două module:
Dacă T reprezintă nivelul de prag al voterului și sistemul conține N
module, atunci el poate tolera maxim NT defecte. În general, din punc t de
vedere al capacității de toleranță, un astfel de sistem corespunde celui hibrid
cu rezerve care are P=2T1 module active și NP rezerve. Fiabilitatea
sistemului reconfigurabil prin autoeliminare, pentru cazul voterului și
comutatoarelor perfecte, este dată de
R R RspN
ii Ni
iTN
( ) 1
,
unde R reprezintă fiabilitatea unui modul.
O altă schemă similară este redundanța modulară sift -out (to sift = a
cerne), redată în figura 3.17. Și în acest caz se urmărește eliminarea contribuției
modulelor defecte la realizarea funcției de ieșire, dar diferă modul în care se
face identificarea modulelor defecte. Acest lucru se efectuează aici prin
compararea modulelor între ele.
Comparatorul verifică ieșirea fiecărui modul în raport cu ieșirile celorlalte
module și furnizează câte un semnal pentru fiecare comparație. În total pentru
N module sunt de efectuat N(N1)/2 comparații. Fiecare semnal logic generat
de comparator are valoarea 0 dacă mărimile comparate coincid și 1 în caz
contrar. Pe baza acestor semnale detectorul determină care modul este defect,
generând câte un semnal pentru fiecare modul, care este 1 în caz de defect. Un
modul se va declara defect numai dacă el nu prezintă coincidență cu celelalte
Figura 3.17. Schema bloc a sistemului cu redundanță
modulară sift -out
module rămase. Odată ce un modul defect a fost detectat, el se elimină din
procesul de comparare. Semnalul său de eroare către colector trebuie să fie
menț inut pe 1 până la repunerea în funcțiune a modulului, pentru a nu
influența ieșirea sistemului. Colectorul combină ieșirile modulelor pentru a
asigura semnalul de ieșire al sistemului, astfel încât semnalele sosite de la
modulele defecte sunt inhibate de s emnalele sosite de la detector. Tabelul de
funcționare al detectorului pentru N=5 module este următorul :
Notația de tipul Dij reprezintă semnalul rezultat din compararea modulului i cu
j, astfel încât Dij=1 în caz de neconcordanță. Fi=1 indică modulul i defect,
ecuația logică fiind de forma:
F1 = D12D13D14D15
Semnalul de la ieșirea sistemului este dat de expresia
fFM FM FM FM FM 1 1 2 2 3 3 4 4 5 5
în care Mi reprezintă ieșirea modulului i.
Sistemul cu redundanță modulară sift-out poate tolera N2 defecte.
Acest lucru este adevărat, deoarece trebuie să existe cel puțin două module ale
căror ieșiri să coincidă pentru ca ieșirea sistemului să fie corectă. Fiabilitatea
sistemului se poate calcula cu relația:
N
iiN i
ClDC so R R RRR R
2) 1(
Cu RC, RD și RCl s-au notat respectiv fiabilitățile comparatorului, detectorului și
colectorului.
În concluzie la redundanța hibridă, se poate afirma că prin îmbinarea
tehnicii de mascare a defectului cu reconfigurarea se poate asigura o fiabilitate
mai mare decât la celelalte două cazuri de redundanță. De aceea, redundanța
hibridă își găsește aplicabilitate la sistemele ultrafiabile. Pe de altă parte,
datorită hardului suplimentar folosit pentru votare și pentru modulele de
rezervă, redundanța hibridă este cea mai cos tisitoare formă de redundanță
hardware.
3.2. Redundanța informațională
3.2.1. Coduri detectoare și corectoare de eroare
Cuvintele de cod se obțin prin adăugarea de informație redundantă la cuvintele
de date, în vederea punerii în evidență sau refacerii cuvinte lor afectate de
erori. Prin procesul de codificare , cuvântul de informație utilă se transformă
într-un cuvânt de cod pe baza unei reguli proprii codului respectiv. Operația
inversă, de refacere a datei originale din cuvântul de cod se numește
decodificare .
În funcție de modul în care se realizează corespondența între mulțimea
cuvintelor de codificat și mulțimea cuvintelor de cod, există o mare varietate de
coduri. În sistemele de calcul prezintă interes codurile binare (binary codes ), în
care cuvintele de cod sunt formate numai din simbolurile 0 și 1. O clasificare a
codurilor binare este oferită de schema din figura 3.18.
Figura 3.18. Clasificarea codurilor binare
După lungimea cuvintelor de cod, codurile pot f i cu lungime variabilă sau
fixă. Codurile cu lungime fixă sunt denumite coduri bloc , fiind notate coduri ( n,
k). În această notație n reprezintă numărul de biți ai codului, iar k numărul de
biți utili. Rezultă un număr de nk biți redundanți în fiecare cuvânt de cod.
Codurile liniare sunt acele coduri bloc la care numărul cuvintelor de cod este
M=2k. Codurile liniare se mai numesc coduri de grup, deoarece au proprietatea
unui grup închis față de operația de adunare modulo 2. Astfel dacă X și Y
reprezintă două cuvinte de cod, atunci și XY este un cuvânt de cod valid.
Codurile neliniare, caracterizate prin M2k, se dau în general sub formă
tabelară. Codurile separabile se caracterizează prin faptul că cei nk biți de
control su nt alăturați celor utili, astfel încât procesul de decodificare se face
simplu prin detașarea acestor biți redundanți ai cuvintelor de cod. Codurile
neseparabile nu au această proprietate. În plus, dacă biții de control ocupă
aceleași poziții la toate comb inațiile de cod, codul este sistematic. O clasă
interesantă de coduri (atât separabile, cât și neseparabile) o reprezintă codurile
ciclice , la care orice deplasare ciclică a unui cuvânt de cod va da tot un cuvânt
de cod.
Codurile detectoare de eroare (error detecting codes ) permit detectarea
unei alterări a cuvintelor de cod. Acest lucru este posibil dacă eroarea introdusă
a dat naștere la un cuvânt de cod invalid (ilegal), adică în afara mulțimii celor M
cuvinte de cod valide. Din cele 2n combinații posibi le, în cazul unui cod liniar
numai 2k sunt considerate valide, apariția unei combinații invalide fiind folosită
pentru sesizarea unei erori (figura 3.19).
Figura 3.19. Principiul de detectare a erorii prin codificarea datelor
În general, pentru un cuvânt al unui cod liniar de n biți, pot exista 2n1
erori posibile. Numărul total de erori care rămân nedetectate este egal cu
restul cuvintelor de cod valide, adică 2k1. Ca urmare, probabilitatea de a avea
erori nedetectate este da tă de:
pnk
nk
nk k
2 1
2 112
2 2
Pentru valori mari ale lui k, se poate aproxima
pn nknk 1
22( )
deci probabilitatea de a nu detecta o eroare scade exponențial cu numărul de
biți redundanți.
Asemenea erori pot apărea de exemplu în timpul transferului datelor sau
al păstrării acestora în dispozitive de memorare. Eroarea poate afecta
individual un număr de biți ( eroare singulară , eroare dublă , în general eroare
multiplă ) sau poate apărea sub formă de pachete de eroare (burst error ), când
un anumit număr succesiv de biți pot fi afectați. Mai exact, un pachet de eroare
reprezintă o secvență binară delimitată de doi biți care poate conține între ele
un număr oarecare de biți eronați. Prin procedura de întrețesere ( interleaving ),
erorile sub for mă de pachete pot fi tratate ca și erori aleatoare independente.
Codurile corectoare de eroare (error correcting codes ) permit
restabilirea cuvântului de cod valid din cel invalid afectat de eroare, fiind
capabile de localizarea biților eronați.
Pentru a studia capacitatea de detecție și de corecție a unui cod este
importantă noțiunea de distanță Hamming , care reprezintă numărul de biți
prin care diferă două cuvinte de cod. Dacă X=(x1,x2,…,xn) și Y=(y1,y2,…,yn) sunt
două cuvinte de cod, atunci distanța Hamming dintre ele se calculează sub
forma:
D x yi i
in
1
Ponderea unui cuvânt de cod este egală cu numărul biților săi de 1, de
exemplu cuvântului X=(x1,x2,…,xn) îi corespunde ponderea:
w xi
in
1
Dacă toate cuvintele de cod au aceeași pondere, acesta este un cod cu pondere
fixă. Deoarece la un cod liniar, care prezintă proprietatea de grup, suma
modulo 2 a două cuvinte de cod reprezintă tot un cuvânt de cod, distanța
Hamming dintre două cuvinte de cod este egală cu ponderea cuvî ntului de cod
format prin suma modulo 2 a acestora:
D x y zwXY i i
in
i
in
z
1 1
În această relație s -a notat cu Z=(z1,z2,…,zn) cuvântul de cod format astfel încât
zi=xiyi, i=1,2,…, n. Rezultă că proprietățile de distanță ale unui cod liniar sunt
determinate d e ponderile cuvintelor de cod. Deoarece și cuvântul nul (0,0,…,0)
este un cuvânt de cod valid, distanța Hamming minimă a codului este egală cu
ponderea minimă:
Dmin = min{ wz | z0}
Proprietățile de detectare și corectare ale unui cod sunt caracterizate de
distanța Hamming minimă ( Dmin) dintre orice pereche de cuvinte de cod, adică:
Dmin = min{ DXY | X, Y, XY}
Distanța Hamming minimă se numește distanță de cod și este un parametru
important al unui cod detector sau corector de eroare. Dacă se reprezintă
cuvintele vecine (care diferă printr -un singur bit) pe o axă, atunci se poate
Figura 3.20. Studiul capacității de detecțieși corecție în
funcție de distanța Hamming minimă
studia capacitatea de detecție ș i corecție a codului în funcție de distanța
Hamming minimă (figura 3.20). Dacă Dmin=2, atunci se poate detecta o eroare
singulară, deoarece alterarea unui bit duce la un cuvânt de cod invalid care se
poate pune în evidență. Corectarea unei erori singulare este posibilă însă
numai dacă Dmin3, deoarece în acest caz cuvântul invalid rezultat rămâne în
sfera de influență (sfera de corecție) a cuvântului de cod original și poate fi
readus în mod univoc la acesta. Distanța Dmin=4 nu este suficientă pentru
corect area unei erori duble, cuvântul eronat fiind egal depărtat de două
cuvinte de cod valide și nu se poate stabili de la care provine.
Condiția de corectare a unei erori este ca prin aceasta să nu se
părăsească sfera de corecție a cuvântului de cod original. Pentru ca un cod să
poată corecta c erori, este necesar ca:
Dmin 2c+1
Dacă se dorește numai detectarea a d erori, atunci este suficient ca:
Dmin d+1
În general, pentru ca un cod să poată corecta până la c erori și să poată detecta
până la d erori ( dc), condiția este ca:
Dmin c+d+1
De exemplu, dacă Dmin=4 și se produce o eroare singulară, atunci se poate
corecta, dar dacă apare o eroare dublă ea va fi numai detectabilă.
Pentru un cod ( n, k) cuvintele de cod nu se pot reprezenta pe o axă, ci ele
vor reprezenta noduri într -un spațiu n-dimensional. Pentru a spori eficiența
codului, este necesar ca cele 2k cuvinte de cod să fie amplasate cât mai departe
unul de altul. Considerând cuvintele de c od în centrul unor sfere de același
diametru, problema este de a plasa cât mai multe astfel de sfere în marea sferă
corespunzătoare spațiului n-dimensional (figura 3.21). O împachetare densă
conduce evident la un număr mai mare de cuvinte de cod și la o ra tă mai mică
de redundanță. Redundanța relativă a codului se poate exprima sub forma
raportului ( nk)/k sau ( nk)/n.
Într-un cuvânt de cod de n biți se pot produce i biți eronați în
in feluri.
Dacă codul poate corecta până la c erori, atunci numărul de cuvinte invalide
care se pot corecta este
c
iin
1 . Fiind în total 2k cuvinte de cod, numărul total
de puncte care intră în sfera lor de corecție, inclus iv acestea este
c
iin k
02 .
Acest număr trebuie să fie mai mic decât numărul total de puncte din spațiu
(2n), adică :
c
iin
0
2nk
Pentru corectarea erorilor singulare ( c=1) se obține condiția:
Figura 3.21. Împachetarea cuvintelor de cod
nk log 2 (n+1)
Relația de mai sus dă pentru c o limită superioară a numărului de erori
corectabile cu un cod ( n, k). În caz de egalitate, se obține un cod perfect
corespunzător împachetării maxime, pentru care nu rămâne nici un punct al
spațiului în afara sferelor de corecție. Codul perfect este optimal în sensul că
furnizează o capacitate de corecție maximă la o redundanță minimă.
3.2.2. Coduri de paritate
Codurile de paritate ( parity codes ) se folosesc la controlul operațiilor de
transfer și de păstrare a datelor. Cuvânt ul de cod se obține prin adăugarea unui
bit de paritate la informația utilă, astfel încât numărul total de biți de 1 ai
cuvântului astfel format să fie par (paritate pară) sau impar (paritate impară).
În caz de paritate pară (even parity ), bitul de paritat e (p) se calculează ca
și suma modulo 2 a biților utili:
2 mod 1
0p dk
ii
Pentru sinteza cu circuite logice, suma modulo 2 este realizată de funcția SAU –
EXCLUSIV, ecuația logică corespunzătoare formării acestui bit de control fiind
p = d0 d1 … dk1 ,
unde di (i=0,1,…, k1) reprezintă biții utili de date. De exemplu, octetului
01101011 i se va atașa bitul 1 pentru a se forma cuvântul de cod cu paritate
pară (011010111). Pentru cazul general, lungimea cuvântului de cod este
n=k+1.
Verific area parității cuvântului de cod se face prin regenerarea bitului de
paritate din biții de date și compararea sa cu bitul de paritate atașat cuvântului.
Schema de control sintetizată pentru k=4 este cea din figura 3.22.
Dacă se adoptă convenția de paritate impară (odd parity ), atunci bitul de
control se formează pe baza relației
pp .
Se observă că datorită metodei de formare, codul de paritate este un cod
separabil. Distanța de cod este Dmin=2, deoarece trecerea de la un cuvânt de
cod valid la altul necesită modificarea a cel puțin doi biți. Codul de paritat e
detectează toate erorile singulare , respectiv toate erorile care afectează un
număr impar de biți. Avantajul codului de paritate îl reprezintă simplitatea
implementării și coeficientul de redundanță redus (1/ k), dezavantajul fiind însă
Figura 3.22. Schema controlului de paritate
pentru un cuvânt de 4 biți
Figura 3.23. Utilizarea controlului de par itate la un bloc de memorie
capacitatea redusă de detecție.
Controlul prin cod de paritate se folosește cel mai adesea în memoria
sistemelor de calcul. În figura 3.23 este prezentată schema bloc a unei astfel de
unități. La scriere cuvântul de date este stocat în memorie împreună cu bitul de
paritate, iar la citire se verifică paritatea cuvântului de cod și dacă nu este
corectă, se generează un semnal de eroare. Este de remarcat faptul că metoda
necesită și redundanță hardware.
Atașarea câte unui bit de paritate fiecărui cuvânt, numită paritate pe
cuvânt (bit-per-word parity ), permite punerea în evidență a unei erori de
modificare din 0 în 1 sau din 1 în 0 a unei singure poziții binare (figura 3.24). Nu
se poate detecta punerea pe 1 a tuturor biților, inclusiv a celui de control, în
cazul parității impare, respectiv punerea pe 0 în cazul parității pare.
Figura 3.24. Principiul parității pe cuvânt
Problema anterioară se poate rezolva dacă se utilizează paritatea pe
octet (bit-per-byte parity ), care prevede câte un bit de paritate la fieca re octet,
unul de paritate pară, altul de paritate impară (figura 3.25). Dacă toți biții devin
1, atunci bitul p1 va fi eronat, iar dacă toți devin 0, atunci bitul de control p2 va
pune în evidență eroarea. De asemenea, sunt detectate erorile duble care
afectează câte un bit din fiecare grup (acest caz fiind reprezentat ha șurat pe
figură).
Figura 3.25. Principiul parității pe octet
Dacă se urmărește detectarea erorilor duble care afectează poziții
adiacente, atunci se poate folosi paritatea întrețesută (interlaced parity ) (figura
3.26). Metoda poate fi extinsă și pe grupuri de mai mulți biți, asociind fiecărui
grup câte un bit de paritate. Devine astfel posibilă detectarea erorilor multiple
adiacente, care afectează un număr mai mare d e doi biți.
Figura 3.26. Principiul parității întrețesute
În cazul memoriilor, care sunt realizate din mai multe circuite, se poate
adopta paritatea pe circuit (bit-per-chip parity ), asociind câte un bit de paritate
fiecărui circuit de memorie (figura 3.27).
Figura 3.27. Principiul parității pe circuit
Metoda de mai înainte permite localizarea circuitului defect, dacă
eroarea afectează un singur bit al circuitului. Dacă în schimb tot circuitul este
defect, deci toți biții săi sunt afectați de eroare, atunci metoda de paritate pe
mai multe circuite (bit-per-multiple -chips parity ) este cea adecvată pentru
detectarea cu siguranță a unei astfel de erori multiple (figura 3.28). Această
soluție nu permite însă localizarea c ircuitului defect.
Figura 3.28. Principiul parității pe mai multe circuite
În cazul blocurilor de date, formate din l cuvinte de câte m biți, se poate
utiliza codul dreptunghiular . Considerând biții de informație dispuși pe l
rânduri și m coloane, se calculează paritatea atât pe fiecare rând orizontal, cât
și pe fiecare coloană verticală. În figura 3.29 este ilustrat cazul pentru l=m=4.
Prin utilizarea codului dreptunghiular devine posibilă corectarea unei erori
singulare, în urma localizării bitului respectiv la intersecția rândului cu coloana
la care controlul de paritate a dat eroare. Redundanța necesară este relativ
mică (2/ m la dispunerea sub formă de pătrat), metoda găsindu -și aplicabilitatea
în special la blocuri mari de date.
Figura 3.29. Principiul codului dreptunghiular
3.2.3. Coduri Hamming
Codurile Hamming se obțin prin dispunerea biților utili în grupuri după
ponderile pozițiilor ocupate și aplicarea câte unui bit de paritate la fiecare grup.
Pentru a corecta o eroare singulară, numărul biților de control ( r) ai cuvântului
de cod de lungime n trebuie să satisfacă relația
2r n+1
pentru a se putea acoperi cele n situații de eroare și cea corectă. Dacă 2r=n+1,
atunci un astfel de cod este perfect, d eoarece satisface la egalitate relația de
limită. Exemple în acest sens sunt codurile (7,4), (15,11), (31,26). Distanța de
cod este Dmin=3.
Gruparea biților din cuvântul de cod se face astfel încât din grupul i
(i=0,1,…, r1) să facă parte biții ai căror număr de ordine îl conține pe 2i ca
termen. Se obține în acest fel un cod în care biții redundanți sunt intercalați
printre cei utili, biții de control fiind plasați pe pozițiile 20, 21, …, 2r1:
Cu d s-au notat biții utili de date, iar cu p cei de paritate. Primul grup va conține
deci biții de pe pozițiile impare ( c1, c3, c5, c7, c9,…), al doilea pe cei care se află în
pozițiile care îl conțin pe 21 (c2, c3, c6, c7, c10,…), următorul pe cei de pe pozițiile
care îl conțin pe 22 (c4, c5, c6, c7, c12,…) și așa mai departe. Se observă că
grupurile sunt suprapuse, această metodă de codificare este de fapt un control
prin paritate suprapusă (overlapping parity ), la care fiecare bit de date face
parte din mai multe grupuri. Pentru fiecare grup se calculează bitul de control
de paritate, pe baza ecuațiilor:
p0 = d1 d2 d4 d5 …
p1 = d1 d3 d4 d6 …
p2 = d2 d3 d4 d8 …
p3 = d5 d6 d7 d8 …
Pentru un astfel de cod este adecvată o tratare matricială. Dacă
C=(c1,c2,…,cn) reprezintă cuvântul de cod corespunzător vectorului de date
D=(d1,d2,…,dk), atunci fiecare bit de cod se poate exprima sub forma
,n,,j= gd ck
iiji j 21 ,2 mod
1
,
unde gij are valoarea 0 sau 1. Această relație se poate scrie sub forma
matricială
C = DG ,
în care G=[gij] (i=1,2,…, k și j=1,2,…, n) se numește matrice generatoare , fiind de
dimensiune kn. De exemplu pentru n=7 și k=4, generarea cuvintelor de cod se
poate face prin următoarea înmulțire matricială:
ccccccc dddd1 2 3 4 5 6 7 1 2 3 41110000
1001100
0101010
1101001
Rândurile matricii G formează o bază în spațiul k dimensional al
vectorilor de cod. În această situație prin permutarea coloanelor lui G se obține
un spațiu vectorial echivalent. Separând pe pr imele k coloane ale matricii
generatoare matricea unitate de dimensiune kk, se obține un cod sistematic
separabil, în care cei nk biți de control sunt plasați în urma celor utili. Această
reprezentare a matricii generatoare se mai numește forma canonică derivată a
lui G:
knk k kknkn
k
p p pp p pp p p
2 1 2 22 21 1 12 11
1 000 100 01
:
PIG
Pentru studiul capacității de corecție se construiește matricea de control
H, de dimensiune ( nk)n:
1 000 100 01
:
2 12 22 121 21 11
knk kn knkk
knT
p p pp p pp p p
IPH
Cu PT s-a notat transpusa matricii P. Având în vedere faptul că pij+pij=0 mod2,
este adevărată proprietatea
GHT = ,
unde reprezintă matricea nulă de dimensiune k(nk).
Pentru codul Hamming (7,4), matricea generatoare scris ă sub formă
canonică devine :
1111000110010010100100110001
G
Cu această matrice se generază cuvinte de cod la care informația de control
este separată de datele utile. Acest lucru se poate remarca și din tabelul
următor, care prezintă cuvintele de cod pentru toate combinațiile binare de
patru biți:
Datele utile Cuvântul de cod
d1 d2 d3 d4 c1 c2 c3 c4 c5 c6 c7
0 0 0 0 0 0 0 0 0 0 0
0 0 0 1 0 0 0 1 1 1 1
0 0 1 0 0 0 1 0 0 1 1
0 0 1 1 0 0 1 1 1 0 0
0 1 0 0 0 1 0 0 1 0 1
0 1 0 1 0 1 0 1 0 1 0
0 1 1 0 0 1 1 0 1 1 0
0 1 1 1 0 1 1 1 0 0 1
1 0 0 0 1 0 0 0 1 1 0
1 0 0 1 1 0 0 1 0 0 1
1 0 1 0 1 0 1 0 1 0 1
1 0 1 1 1 0 1 1 0 1 0
1 1 0 0 1 1 0 0 0 1 1
1 1 0 1 1 1 0 1 1 0 0
1 1 1 0 1 1 1 0 0 0 0
1 1 1 1 1 1 1 1 1 1 1
Relațiile care stau la baza generării biților de control sunt:
c5 = c1 c2 c4 = d1 d2 d4
c6 = c1 c3 c4 = d1 d3 d4
c7 = c2 c3 c4 = d2 d3 d4
Matricea de control corespunzătoare este:
100111001011010011011
H
Se remarcă faptul că matricea de control are pe coloane toate combinațiile
binare de biți, cu excepția celei nule.
La decodificare se efectuează produsul:
CHT = DGHT=
S-a obținut matricea rând de nk elemente, toate zerouri. Dacă cuvântul de cod
este afectat de eroare, reprezentată prin vectorul E, atunci verificarea se face
asupra cuvântului C'=C+E:
C'HT = CHT+EHT = EHT
Vectorul rând de nk elemente care s -a obținut reprezintă sindromul
(syndrome ), pe baza căruia se poate face localizarea și corectarea erorii.
Evident un sindrom nul corespunde cazului lipsit de eroare. Pentru a pune în
evidență o eroare este necesar ca
EHT ,
adică vectorul de eroare nu poate fi un cuvânt de cod.
Codurile Hamming corectoare de erori singulare se utilizează în memoria
sistemelor de calcul, fiind implementate în circuitele de detectare și corectare a
erorilor EDC ( Error Detecting and Correcting Circuit ). Schema bloc a unui astfel
de circuit este dată în figura 3.30.
La scriere se generează biții de control care se păstre ază în memorie
alături de datele utile. Generatorul biților de control este un circuit logic
combinațional, sintetizat pe baza ecuațiilor logice date de relația matricială C =
DG. La citirea din memorie, biții de control sunt regenerați și comparați bit cu
bit (prin porți SAU -EXCLUSIV) în generatorul de sindrom cu cei memorați.
Sindromul obținut este decodificat și dacă este diferit de zero va indica către
circuitul de corecție bitul eronat. Acesta se corectează prin complementare,
astfel încât la ieșire se furnizează data corectă. Sindromul care se generează la
fiecare eroare singulară în cazul codului Hamming (7,4) ales ca exemplu este
dat în tabelul de mai jos:
Bitul eronat Sindromul
c1 1 1 0
c2 1 0 1
c3 0 1 1
c4 1 1 1
c5 1 0 0
c6 0 1 0
c7 0 0 1
Figura 3.30. Schema bloc a circuitului de detectare și
corectare a erorii (EDC) utilizat la o memorie
Figura 3.31. Schema circuitului de corecție a erorilor singulare
la utilizarea codului Hamming (7,4)
Schema circuitului de corecție a erorilor singulare la acest cod este dată în
figura 3.31.
Dezavantajul utilizării circuitelor integrate de corectare a erorilor constă
într-un timp de întârziere suplimentar introdus în lucrul cu memoria. În privința
redundanței c erute, la codul Hamming (7,4) redundanța necesară este destul
de ridicată, de 75%. Procentul de redundanță din lungimea cuvântului de cod
scade însă considerabil pe măsura creșterii numărului de biți de informație
utilă:
Biți utili
(k) Biți de control
(r) Redundanța
(r/k)×100%
2 3 150
4 3 75
8 4 50
16 5 31
24 5 21
32 6 19
64 7 11
Pentru a putea trata și cazul erorilor duble, se poate folosi codul
Hamming modificat cu distanța de cod Dmin=4. Acesta este un cod de tip ( n+1,
k) și se obține prin adăugarea unui bit de paritate global asupra tuturor biților
cuvintelor de cod, astfel încât:
2 mod 01
1
n
iic
Acest cod poate să corecteze o eroare și să detecteze două. Dacă la verificare
relația anterioară este satisfăcută, dar celelalte relații de control indică un
sindrom diferit de zero, înseamnă că s -a produs o eroare dublă. Această eroare
se poate deci pune în evidență, dar nu poate fi însă corectată. Matricea de
control pentru codul Hamming modificat se obține prin bordarea lui H cu câte o
linie și coloană, fiind de forma:
001 11
'
HH
Există și un alt procedeu de creștere a distanței de cod la 4, și anume prin
ștergerea din matricea H a tuturor coloanelor cu un număr par de biți de 1. Se
obține o matrice cu r rânduri și 2r1 coloane. Matricea generatoare
corespunzătoare va avea numai k=2r1r rânduri, iar cuvântul de cod va fi de
lungime n=2r1. Acest cod se numește codul Hamming redus , la care creșterea
capacității de corecție s -a obținut pe seama restrânger ii numărului de biți utili
(2r1r față de 2r1r) la același număr de biți de control ( r).
Pentru cazurile când numărul biților de date este un multiplu de 8, se
folosesc codurile M (de la maintainance =întreținere) de forma (13,8), (22,16),
(39,32), (72,64), la care numărul coloanelor matricii H este mai mic decât 2r1,
nefiind folosite toate combinațiile cu număr impar de biți de 1.
3.2.4. Coduri ciclice
Codurile ciclice ( cyclic codes ) sunt coduri liniare c aracterizate prin faptul că prin
deplasarea ciclică a unui cuvânt de cod se obține un alt cuvânt de cod, și
anume:
(cn1, cn2, …, c1, c0) → ( cn2, cn3, …, c0, cn1)
Trebuie făcută însă observația că nu toate cuvintele de cod sunt rotiri ale
aceluiași cuvânt. Importanța acestor coduri rezidă în codificarea și
decodificarea simplă, fiind folosite cu precădere în transferul datelor.
În vederea tratării matematice, reprezentarea cuvintelor se face cu un
polinom asociat, ai cărui coeficienți reprezi ntă biții cuvântului de cod.
Cuvântului ( cn1, cn2, …, c1, c0) de lungime n îi corespunde polinomul de grad
n1:
C(x) = cn1xn1+cn2xn2+…+c1x+c0
Coeficienții polinomului aparțin câmpului Galois cu două elemente: ciGF(2),
i=0,1,…, n1. De exemplu, pentru n=7, polinomul aferent cuvântului 0110101
este:
C(x) = x5+x4+x2+1
În cazul general al unui câmp Galois GF( p) cu p elemente, p fiind număr prim,
acesta respectă axiomele de câmp. Pentru cazul binar, elementele lui GF(2)
sunt 0 și 1, operațiile fiind efectuate modulo 2. Rezultă proprietatea xm+xm=0 și,
implicit, –xm=xm (adunarea și scăderea sunt operații identice în GF(2)). În
continuare se consideră că toți coeficienții polinoamelo r fac parte din GF(2).
Un polinom care nu poate fi descompus în factori de grad mai mic se
numește polinom ireductibil . Un exemplu este polinomul x3+x+1. Exponentul
unui polinom P(x) este cel mai mic întreg pozitiv l pentru care xl+1 este divizibil
cu P(x). De exemplu, pentru P(x)=x3+x+1 se obține l=7, deoarece
(x7+1)/( x3+x+1)= x4+x2+x+1 și nu divide pe xn+1 pentru n<7. Polinomul primitiv
este un polinom ireductibil de grad m, al cărui exponent este 2m1. Astfel
x3+x+1 este primitiv, deoarece exponentul său este 7.
Fiind dat cuvântul de cod care are polinomul
C(x)=cn1xn1+cn2xn2+…+c1x+c0, polinomul corespunzător cuvântului de cod
obținut prin rotirea cu o poziție la stânga se poate exprima sub forma:
C'(x) = xC(x)+cn1+cn1xn
xC(x) = (xn+1)cn1+ C'(x)
Adică se poate scrie:
C'(x) = xC(x) mod( xn+1)
Codul se construiește cu ajutorul unui polinom generator G(x), de grad
nk, unde k reprezintă numărul biților utili:
G(x) = gnkxnk+…+g1x+g0
Acesta trebuie să fie un factor al lui xn+1, adică:
xn+1 = H(x)G(x)
H(x) constituie polinomul de control al codului. Un cuvânt de n biți este cuvânt
de cod dacă și numai dacă el este divizibil cu G(x), deci:
C(x) = Q(x)G(x)
În aceste condiții, presupunând cele două relații precedente îndeplinite, se
poate arăta că se respectă proprietatea de ciclicitate:
C'(x) = xC(x)+cn1(xn+1) = xQ(x)G(x)+c n1H(x)G(x) =
= [xQ(x)+cn1H(x)]G(x) = Q'(x)G(x)
Deci, într -adevăr și C'(x) corespunde unui un cuvânt de cod valid, fiind divizibil
cu G(x).
Pentru codurile ciclice se poate folosi și descrierea matricială, matricea
generatoare fiind:
G
g g g
g g g
g gnk
nk nk
nk0 1
0 1
00 0
0 0
0 0 0
Controlul informației prin redundanță ciclică (CRC Cyclic Redundancy
Check ) este utilizat frecvent la transmisia serială. Schema de principiu este dată
în figura 3.32. La stația de emisie datele utile (reprezentate de polinomul U(x))
sunt codificate sub forma unui cuvânt de cod ciclic, în cazul de față prin
înmulțire cu polinomul generator. La recepție are loc decodificarea p e bază de
împărțire, având ca rezultat extragerea informației utile și semnalarea unei
eventuale erori care a afectat șirul de biți în timpul transmisiei. În continuare se
vor trece în revistă metodele de codificare și decodificare, împreună cu
circuitele utilizate.
A. Codificarea
Fiind dat cuvântul de informație utilă de k biți, reprezentat prin polinomul
U(x) = uk1xk1+…+u1x+u0
transformarea sa în cuvânt de cod se poate face prin înmulțire sau împărțire.
Dacă r reprezintă gradul polinomului generator G(x), cuvântul de cod generat
va avea n=k+r biți (deci va conține r biți redundanți). Acest cod se simbolizează
sub forma ( n,k). Un cod ciclic este complet definit prin indicarea lui G(x) și n.
a) Codificarea prin înmulțire cu G(x) se efectuează pe baza relației:
C(x) = U(x)G(x)
În acest caz evident se respectă condiția de divizibilitate a cuvântului de cod cu
G(x), dar codul obți nut este neseparabil. De exemplu, pentru G(x)=x3+x+1 și n=7
se obține:
C(x) = (u3x3+u2x2+u1x+u0) (x3+x+1) =
= u3x6+u2x5+(u1+u3)x4+(u0+u2+u3)x3+(u1+u2)x2+(u0+u1)x+u0
Figura 3.32. Principiul de utilizare a codului ciclic
la transmisia serială
Se observă că bitul u1 nu este separabil de cei redundanți.
Pentru transmisia serială, înmulțirea se face cu scheme secvențiale de
deplasare formate din celule de memorare ( F) și sumatoare modulo 2. Acestea
pot fi de mai multe tipuri:
cu sumatoare externe (figura 3.33)
cu sumatoare incluse (figura 3.34)
Referitor la aceste scheme se impun câteve observații. Astfel, dacă gi=0 în
polinomul generator asociat ( G(x)=grxr+gr1xr1+…+g1x+g0), atunci conexiunea
corespunzătoare lipsește din schemă. Introducerea datelor în circuit se face
începând cu poziția de rang maxim ( uk1), iar la ieșire primul bit obținut este
cn1. Pe scheme nu s -a reprezentat tactul, iar inițial registrele trebuie să c onțină
zero. Operația de înmulțire se termină după n=k+r deplasări. K reprezintă o
cheie, care după k deplasări asigură valoarea 0 a bitului de la intrare. După
terminarea înmulțirii în registru rămâne zero.
Figura 3.33. Circuit de înmulțire cu sumatoare externe
Figura 3.34. Circuit de înmulțire cu sumatoare incluse
b) Codificarea prin împărțire presupune următoarele etape:
efectuarea produsului xnkU(x)
împărțirea polinomului obținut la polinomul generator, operație
descrisă de relația xnkU(x)=Q(x)G(x)+R(x), unde R(x) este restul, de
grad mai mic decât nk
formarea cuvântului de cod C(x)=xnkU(x)+R(x)
Se constată două lucruri:
1. Cuvântul de cod satisface condiția impusă, fiind divizibil cu G(x)
conform relației xnkU(x)+R(x) = Q(x)G(x).
2. Codul generat este sistematic, biții de control (dați de R(x)) fiind
adăugați la urma celor utili (dați de xnkU(x)).
De exemplu, pentru G(x)=x3+x+1, n=7 și k=4 codificarea decurge pe baza
relațiilor:
x3(u3x3+u2x2+u1x+u0) = [u3x3+u2x2+(u1+u3)x+(u0+u2+u3)](x3+x+1)+
+(u1+u2+u3)x2 +(u0+u1+u2)x+u0+u2+u3
C(x) = u3x6+u2x5+u1x4+u0x3+(u1+u2+u3)x2+(u0+u1+u2)x+u0+u2+u3
În polinomul obținut pentru cuvântul de cod, primii patru termeni corespund
informației utile, iar ultimii trei informației redundante.
Pentru codificare se folosesc scheme secvențiale de împărțire, care pot
fi:
cu sumatoare externe (figura 3.35)
cu sumatoare incluse (figura 3.36)
Și la aceste scheme trebuie făcute câteva precizări. Conținutul inițial al
registrului trebuie să fie zero, iar datele se introduc în ordinea descrescătoare a
puterilor lui x, urmate de r=nk zerouri (care înseamnă înmulțirea cu xnk).
După efectuarea a k deplasări (cu comutatoarele K1 și K2 pe poziția A), în
registru se află restul corespunzător lui R(x) la schema cu sumatoare incluse
(intercalate), respectiv polinomul R'(x) la prima, care deplasat prin circuit va da
la ieșire pe R(x). Expresia lui R'(x) este
)()()(xGxxRxRr
,
unde reprezintă câtul întreg al împărțirii, iar R''(x) valoarea din registrul cu
reacție de pe figura 3.37 după k tacturi . Pentru transmiterea restului mai sunt
necesare încă r deplasări (cu K1 și K2 pe poziția B). Câtul nu prezintă importanță
la această metodă de codificare.
Schema cu sumatoare incluse prezintă și o altă variantă, în care
deîmpărțitul nu se introduce direct prin reacția inversă, dar la care pentru
formarea restului sunt necesare n impulsuri de tact. Acest circuit, care are
schema de principiu din figura 3.37, implică lansarea în linie a biților utili cu o
întârziere de r tacturi, fiind în acest scop prevăzut cu un registru de deplasare
tampon.
Figura 3.35. Circuit de împărțire cu sumatoare externe
Figura 3.36. Circuit de împărțire cu sumatoare incluse
Figura 3.37. O variantă de circuit de împărțire cu sumatoare incluse
B. Decodificarea
Această operație presupune împărțirea polinomului aferent cuvântului
recepționat la polinomul generator și se bazează pe proprietatea oricărui
cuvânt de cod valid de a fi divizibil cu G(x). Dacă însă cuvântul de cod transmis a
fost afectat de eroare, la re cepție va sosi cuvântul descris de polinomul
C'(x) = C(x)+E(x) ,
unde E(x) reprezintă polinomul erorii. Acest polinom are câte un termen pentru
fiecare poziție afectată de eroare. Prin împărțirea la G(x) se obține:
Cx
GxCx
GxEx
GxQxEx
GxQxQxRx
Gx()
()()
()()
()()()
()() ()()
()
Se poate constata că restul împărțirii lui C'(x) la G(x) este dat de restul împărțirii
lui E(x) la G(x), care a fost notat cu R'(x). Dacă transmisia se face fără eroare
(E(x)=0), atunci împărțirea se face fără rest și cuvântul de cod recepționat este
valid . Împărțirea decurge de asemenea fără rest, dacă polinomul de eroare
E(x)0 este divizibil cu G(x) și atunci eroarea nu poate fi detectată. Condiția de
detectare a erorii este deci ca polinomul aferent secvenței eronate să nu fie
divizibil cu polinomul generator. În acest caz operația de împărțire de la
docodificare va da naștere unui polinom rest S(x)0 conform relației:
C'(x) = Q'(x)G(x)+S(x)
Acest polinom S(x) de grad nk1 reprezintă sindromul erorii , care servește la
detectarea și eventual corectarea erorii. Se observă că S(x) este restul împărțirii
lui E(x) la G(x) și nu depinde decât de configurația erorii.
Dacă cuvântul de cod din exemplul precedent este afectat de un polinom
de eroare de forma
E(x) = e6x6+e5x5+e4x4+e3x3+e2x2+e1x+e0
atunci la decodificare se obține:
C'(x) = (u3+e6)x6+(u2+e5)x5+(u1+e4)x4+(u0+e3)x3+(u1+u2+u3+e2)x2+
+(u0+u1+u2+e1)x+(u0+u2+u3+e0) =
= [(u3+e6)x3+(u2+e5)x2+(u1+u3+e4+e6)x+(u0+u2+u3+e3+e5+e6)](x3+x+1)+
+(e2+e4+e5+e6)x2+(e1+e3+e4+e5)x+(e0+e3+e5+e6)
Se poate constata că într -adevăr sindromul obținut depinde numai de
coeficienții polinomului de eroare:
S(x) = (e2+e4+e5+e6)x2+(e1+e3+e4+e5)x+(e0+e3+e5+e6)
În cazul transmisiei seriale, pentru împărțirea cu G(x) de la decodificare
se poate folosi unul din circuitele secvențiale liniare de împărțire prezentate
mai sus. După încărcarea cuvântului de cod recepționat în celulele registrului
(cu n impulsuri de tac t), acestea vor conține biții sindromului de eroare. Dacă
sindromul este zero se consideră că s -a obținut un cuvânt de cod valid, iar în
caz contrar informația recepționată este cu siguranță afectată de eroare.
Bineînțeles atât la emisie cât și la recepție trebuie utilizat același polinom
generator.
Extragerea informației utile din cuvântul de cod recepționat depinde de
modul în care a fost făcută codificarea la emisie:
Dacă codificarea a fost efectuată prin înmulțire și deci codul nu este
separabil, atunci câtul împărțirii cu G(x) va reprezenta tocmai biții de informație
utilă U(x), conform ecuației cunoscute C(x)=U(x)G(x).
Un exemplu de decodificare, folosind schema de împărțire cu sumatoare
externe pentru G(x)=x3+x+1, este prezentat în figura 3.38. Cuvântul de cod de 7
biți utili se încarcă în registru cu șapte impulsuri de tact. După al treilea tact, la
ieșirea U(x) încep să apară biții utili, care corespund cu informa ția originală
dacă nu există eroare. În caz de eroare, după al n-lea tact, registrul va conține
un sindrom diferit de zero, care va activa semnalul de eroare de la ieșirea
schemei. Evoluția schemei în cele două situații este ilustrată în tabelul următor:
Dacă prin codificare s -a generat un cod separabil sistematic folosind o
schemă de împărțire, atunci la recepție se rețin sub formă de informație utilă
primii k biți, restul fiind biții de control. Concomitent se efectuează și
împărțirea secvenței recepțion ate cu G(x) pentru a se obține sindromul de
eroare. Conținutul final diferit de zero al registrului cu reacție va însemna o
situație de eroare.
Uneori, în funcție de capacitatea codului și configurația erorii, este
posibilă corectarea informației alterate. Această operație se realizează prin
decodificarea sindromului și complementarea biților eronați. De pildă, codul
Figura 3.38. Detectarea erorii la recep ție pe baza sindromului
considerat în exemplul anterior permite corectarea oricărei erori singulare
(E(x)=eixi, i=0,1,…,6) pe baza sindromului, așa cum rezultă din următorul tabel:
E(x) Sindromul Bitul eronat
e0xo 1 0 0 c0
e1x 0 1 0 c1
e2x2 0 0 1 c2
e3x3 1 1 0 c3
e4x4 0 1 1 c4
e5x5 1 1 1 c5
e6x6 1 0 1 c6
Poziția 1 x x2
Schema de decodificare, utilizând un circuit secvențial de împărțire cu
sumatoare intercalate, este cea din figura 3.39. Biții recepționați se introduc pe
durata a 7 impulsuri de tact concomitent într -un registru tampon și în circuitul
care face împărțirea cu G(x). Sindromul format este decodificat pentru pozițiile
corespunzătoare biților de informație utilă, în vederea corectării unei erori a
unuia din acești biți. Ecuațiile logicii de decodificare rezultă din tabelul
precedent de sindromuri, și anume:
E FFF
E FFF
E FFF
E FFF3 012
4 012
5 012
6 012
La ieșirea schemei se obține în paralel cuvântul de informație utilă, refăcut
după o eventuală eroare singulară suferită în timpul transmisiei. Pentru
ilustrarea func ționării se dă tabelul de mai jos cu evoluția schemei pentru un
cuvânt recepționat care are bitul al 4 -lea afectat de eroare:
Figura 3.39. Schemă de decodificare cu corectarea unei
erori singulare pe baza sindromului
Desigur asemenea scheme permit doar tolerarea unui număr limitat d e
erori, una singură în cazul considerat. Dacă se produc mai multe erori decât se
acceptă, atunci va rezulta o decodificare falsă a informației. Acest principiu de a
nu putea determina sau corecta orice eroare este de fapt general valabil pentru
sistemele tolerante la defecte.
Capacitatea de detecție și corecție a codului ciclic depinde de expresia
polinomului generator, care determină distanța Hamming a codului respectiv.
În acest sens se prezintă următoarele proprietăți legate de caracteristicile
coduri lor ciclice în funcție de polinomul generator ales:
1. Orice cod ciclic poate detecta o eroare singulară . Polinomul generator G(x)
fiind un factor al lui xn+1, el trebuie să aibă cel puțin doi termeni. Ca urmare,
polinomul de eroare de forma E(x)=xi (0 i n1) nu va fi divizibil cu G(x),
care are mai mult de un termen.
2. Dacă G(x)=x+1, atunci pentru orice n se obține un cod cu Dmin=2, care poate
detecta toate erorile singulare. Acest lucru este adevărat, deoarece G(x) are
mai mult de un termen și x+1 este divizor al tuturor polinoamelor de forma
xn+1. Mai mult, codul generat cu acest polinom permite detectarea tuturor
erorilor multiple care afectează un număr impar de biți . Presupunând
contrariul, ar trebui ca E(x)=(x+1)F(x). Luând x=1 se obține E(1)=(1+1) F(1)=0,
ceea ce este o contradicție, deoarece pentru un număr impar de termeni
E(1)=1. În particular, dacă operația de codificare se face prin împărțirea lui
xU(x) la G(x)=x+1, atunci se obține codul ciclic de paritate (restul atașat
informației uti le fiind 0 sau 1).
3. Dacă G(x) este un polinom primitiv care are exponentul en, atunci codul
generat are Dmin=3. Acest cod poate fi folosit ca și cod corector de erori
singulare sau detector de erori duble (și implicit singulare). Polinomul
asociat unei erori duble este E(x)=xi+xj=xi(1+xji), i<j<n. Evident xi nu este
divizibil cu G(x), dar nici 1+ xji având ji<n nu poate fi divizat de G(x) dacă
acesta este primitiv și deci este divizorul lui 1+ xe cu en. Luând cazul limită
e=n și notând gradul lui G(x) cu r, lungimea cuvintelor de cod este în acest
caz n=2r1, din care un număr de k=2r1r biți sunt utili. Câteva polinoame
primitive sunt date în tabelul de mai jos. Se poate arăta că pentru orice r
întreg și pozitiv există cel puțin un polinom primitiv G(x) de grad r al cărui
exponent este 2r1. De asemenea, este de menționat faptul că un cod ciclic
(n,k) generat de un polinom primitiv este un cod Hamming.
G(x)
(de grad r) Lungimea codului
(n=2r1) Biți utili
(k=nr) Redundanța
(r/k)×100%
x2+x+1 3 1 200
x3+x+1 7 4 75
x4+x+1 15 11 36
x5+x2+1 31 26 19
x6+x+1 63 57 11
x7+x+1 127 120 6
x8+ x4+ x3+ x2+1 255 247 3
4. Dacă polinomul generator este de forma G(x)=(x+1)G1(x), unde G1(x) este un
polinom primitiv cu exponentul e, atunci acest cod de lungime ne are
Dmin=4. Ca urmare el poate corecta erori singulare și detecta erori duble sau
poate detecta până la trei erori . Conform celor prezentate anterior, erorile
singulare și triple sunt detectate datorită factorului ( x+1), iar cele duble de
polinomul G1(x) de grad r care nu poate diviza polinomul aferent erorii duble
dacă n2r1. Prezintă interes cazul în care la o lungime n a codului, numărul
biților de control este minim, adică n=2r1. În acest caz numărul biților utili
este cu unu mai mic decât în situația de la punctul 3, deci
k=2r1(r+1)=2rr2 (gradul polinomului generator și totodată numărul
biților redundanți fiind r+1).
5. Codul ciclic generat de polinomul G(x) de grad r poate detecta toate
pachetele de eroare de lungime lr. Un astfel de pachet este caracterizat de
polinomul de eroare E(x) = xi+…+xi+l1 = xi(1+…+ xl1) = xiE1(x), 0in1. Se știe
că xi nu este divizibil cu G(x), iar polinomul E1(x) care definește modelul de
eroare, având gradul maxim r1, nu poate fi divizat de polinomul generator
G(x) de grad mai mare ( r). Rezultă că pachetul de erori se detectează. Acest
lucru este important în canalele de comunicație, unde transmisia poate fi
afectată de un pachet de erori, de exemplu datorită perturbațiilor.
În continuare se dau câteva exemple de coduri ciclice frecvent întâlnite.
Codurile de control prin redundanță ciclică CRC ( Cyclic Redundancy
Check ), printre care se disting codurile cu următoarele polinoame generatoare:
codul CRC -8, caracterizat prin
G(x) = x8+x7+x5+x4+x+1 = ( x+1)(x7+x4+1)
codul CRC -16, care are
G(x) = x16+x15+x2+1 = ( x+1)(x15+x+1)
codul CRC -CCITT, cu
G(x) = x16+x12+x5+1 = ( x+1)(x15+x14+x13+x12+x4+x3+x2+x+1)
Este de notat faptul că polinoamele generatoare ale acestor coduri se pot pune
sub forma de la punctul 4, punând în evidență factorul x+1 și un polinom
primitiv. Din această cauză ele detectează toate erorile simple, duble și triple.
Dacă transmisia se fac e pe caractere de 8 biți, atunci codurile CRC -16 și CRC –
CCITT pot detecta un pachet de erori care afectează două caractere succesive.
Codurile Hamming , care sunt coduri perfecte corectoare de erori
singulare. Așa cum s -a arătat la punctul 3, acestea se obț in dacă G(x) este un
polinom primitiv. De exemplu, polinomul G(x)=x3+x+1 generează codul
Hamming (7,4), iar G(x)=x4+x+1 codul (15,11).
Codurile BCH (Bose -Chaudhuri -Hocquengem) sunt coduri corectoare de
erori multiple. Se poate demonstra că pentru orice num ere întregi m și t există
un cod BCH ( n,k) cu lungime n=2m1 și cu gradul polinomului generator nkmt
care poate corecta până la t erori ( Dmin2t+1). Polinomul generator este dat de
G(x) = c.m.m.m.c.[ m1(x), m2(x), …, m2t1(x)] ,
unde mi(x) reprezintă polinomul minimal pentru
i , fiind un element primitiv
al câmpului extins GF(2m).
Codurile RS (Reed -Solomon) constituie o subclasă a codurilor BCH cu
lungime n=2m1 și Dmin=nk+1, având polinomul generator dat de
) () )( ()(2 1 minDa a ax x x xG
,
unde este un element primitiv din GF(2m) și a un întreg oarecare. Aceste
coduri se folosesc pentru codificarea simbolurilor de m biți, pentru care
parametrii codului devin n'=mn și k'=mk.
Codurile Golay sunt coduri perfecte, corectoare de erori multiple. De
exemplu codul Golay (23,12), dat de polinomul generator
G(x)=x11+x9+x7+x6+x5+x+1 are Dmin=7 și deci poate corecta până la trei erori.
3.2.5. Coduri m din n
Codurile din clasa m din n (m-out-of-n codes ) se caracterizează prin faptul că un
cuvânt de cod de lungime n conține exact m biți de 1, adică are ponderea m. Un
astfel de cod are distanța de cod Dmin=2, deoarece alterarea oricărui bit duce la
schimbarea numărului de biți de 1 la m+1 sau m1, ceea ce reprezintă cuvinte
invalide. În schimb modificarea a doi biți poate conduce la un nou cuvânt de
cod valid, cu excepția cazului când ambele erori se produc în același sens (din 0
în 1 sau din 1 în 0). Rezultă că la codurile m din n este posibilă detectarea
oricărei erori singulare și a tuturor erorilor multiple unidirecționale .
Deși principial sunt simple, aceste coduri sunt greu implementabile în
privința operației de codificare și decodificare, care au loc de regulă pe baza
tabelului de corespondență. Con strucția cea mai simplă se realizează la codul i
din 2 i, care presupune atașarea la cuvântul util de i biți a încă i biți redundanți,
aleși astfel încât noul cuvânt să conțină exact i biți de 1. Astfel se obține un cod
separabil, ușor de decodificat, dar p e seama unei redundanțe de 100%. Ca un
exemplu, codul 3 din 6 arată în felul următor:
redundantibiți
utilibiți000100010110001101011111
||||||||
111011101001110010100000
Alt exemplu de cod cu pondere fixă este codul 2 din 5 , care conține un
singur bit redundant, dar nu este separabil. El permite codificarea cifrelor
zecimale reprezentate inițial în cod BCD:
Codul BCD Codul 2 din 5
0 0 0 0 0 0 0 1 1
0 0 0 1 1 1 0 0 0
0 0 1 0 1 0 1 0 0
0 0 1 1 0 1 1 0 0
0 1 0 0 1 0 0 1 0
0 1 0 1 0 1 0 1 0
0 1 1 0 0 0 1 1 0
0 1 1 1 1 0 0 0 1
1 0 0 0 0 1 0 0 1
1 0 0 1 0 0 1 0 1
3.2.6. Coduri cu duplicare
Codurile cu duplicare ( duplication codes ) presupun dublarea informațiilor
originale astfel încât dintr -un cuvânt de k biți să se obțină un cuvânt de cod de
2k biți. Prin compararea celor două jumătăți se poate detecta eroarea. Se
observă ușor că orice eroare singulară este detectabilă.
Conceptul are mai multe versiuni de realizare:
Duplicarea cu complementare (duplication with comparison ) constă în
atașarea la informația utilă a complementului său. Metoda este utilă atunci
când prelucrarea datelor se face pe același hard. Exemple de utilizări sunt la
memorarea, respectiv transmiterea datelor. În cazul memoriei ( figura 3.40),
prin compararea unui cuv ânt util cu inversul succesorului său se poate detecta
și localiza rangul defect. În cazul transferului paralel se transmit unul după altul
două cuvinte: cel original și complementul său (figura 3.41). Eroarea este
detectată la recepție prin compararea bit cu bit a primului cuvânt primit cu
negatul celui de -al doilea. Astfel linia defectă este localizabilă, fără a fi însă
posibilă corectarea erorii.
Figura 3.40. Utilizarea duplicării cu comparare în cazul unei memorii
Duplicarea cu interschimbare (swap and compare ) se bazează pe
păstrarea a două copii identice ale informației utile, dar a doua este cu
jumătățile schimbate între ele. Modul de utilizare la o memorie este prezentat
schematic în figura 3.42. Punerea în evidență a erorii se face prin compararea
jumătăților corespunzătoare din două cuvinte succesive de memorie.
Avantajul codurilor cu duplicare constă în faptul că generarea cuvântului
de cod este simplă, dar au dezavantajul unei redundanțe ridicate, de 100%.
Redundanța informațională necesară presupune și o redundanță hardware (de
exemplu dublarea capacității de m emorie), respectiv în timp (dublarea timpului
datorită retransmiterii sau pentru încă o citire/scriere la memorie).
Figura 3.41. Utilizarea duplicării cu co mparare în t ransmiterea datelor
Figura 3.42. Utilizarea duplicării cu interschimbare la o memorie
3.2.7. Coduri de control prin sumă
Aceste coduri se folosesc îndeosebi la controlul transmisiei unui bloc de date,
de exemplu între o unitate de disc și calculator sau în rețele cu comutare de
pachete. Pe baza cuvintelor ce compun blocul se calculează o sumă de control
(checksum ), care se a tașează informației utile. La recepție se recalculează suma
și se compară cu cea primită, în vederea detectării unei erori. Schema de
principiu este dată în figura 3.43, unde notația Di desemnează un cuvânt
original, iar D'i cuvântul recepționat. Codurile de control prin sumă sunt coduri
separabile, ceea ce face decodificarea ușoară.
Suma de control se obține prin însumarea datelor originale. După
numărul de poziții binare rezervate pentru rezultat și modul de tratare a
transportului, exista mai multe vers iuni de formare a sumei de control:
Suma de control în simplă precizie se formează pe k biți ( k fiind lungimea
unui cuvânt al blocului) și se neglijează un eventual transport. În acest fel
redundanța este redusă, dar renunțarea la transport diminuează capacitatea de
detecție a codului.
La varianta denumită sumă de control reziduală , transportul gene rat
este adunat sub formă ciclică la poziția cea mai puțin semnificativă a sumei
Figura 3.43. Schema de principiu a controlului prin sumă
în transmiterea datelor
obținute în prima fază.
Pentru a nu pierde din informația rezultată în urma adunării, se preferă
suma de control în dublă precizie , care se formează pe 2 k biți (se efectuează o
sumă modulo 22k prin renunțarea la transport). Un exemplu este dat în figura
3.44.
Figura 3.44. Exemplu de utilizare a sumei de control în
dublă precizie la o transmisie de date
Figura 3.45. Modul de formare a sumei de control Honeywell
pentru un bloc de date
O altă variantă care generează o sumă pe 2 k biți este suma de control
Honeywell . Ea se obține prin adunarea cuvintelor duble formate prin
concatenarea a câte două cuvinte consecutive din blocul de date (figura 3.45).
O eroare care compromite aceeași poziție a tuturor cuvintelor va afecta cel
puțin doi biți din suma de control, facilitând detectarea erorii.
Sumele de control pot detecta erori, dar nu pot da indicii asupra locului
lor de producere.
3.2.8. Coduri Berger
Codurile Berger sunt coduri separabile, la care biții de control sunt atașați în
urma cuvântului util (figura 3.46). Codificarea decurge în felul următor:
se numără biții de 1 din datele utile
se complementează numărul binar obți nut
rezultatul se atașează informației utile
Evident pentru k biți utili sunt necesari r = log 2(k+1) biți redundanți, unde
reprezintă rotunjirea în sus până la următorul întreg. Codul cel mai eficient (de
lungime maximă) se obține pentru k=2r1.
Figura 3.46. Dispunerea biților de control în urma celor utili
la codul Berger
De exemplu, cuvântul (0111010) cu k=7, conține patru biți de 1, ceea ce
înseamnă (100). Complementul său pe r=3 biți este (011), care atașat datelor
utile va da cuvântul de cod (0111010011).
Codul Berger este important pentru că detectează toate erorile multiple
unidirecționale și pentru acesta utilizează cel mai mic număr de biți redundanți
dintre codurile separabile. Rata de redundanță scade pe măsura creș terii
numărului de biți utili. Acest lucru se poate constata și din tabelul următor:
Biți utili
(k) Biți de control
(r) Redundanța
(r/k)×100%
4 3 75
8 4 50
16 5 31
32 6 19
64 7 11
3.2.9. Coduri aritmetice
Codurile aritmetice ( arithmetic codes ) se folosesc pentru verificarea
corectitudinii execuției operațiilor aritmetice (adunare, scădere, înmulțire,
împărțire). Operația se execută asupra datelor codificate și este considerată
corectă dacă rezultatul reprezintă un cuvânt de cod valid. Pentru a se putea
astfel utiliza, codul aritmetic trebuie să fie invariant față de operația aritmetică
respectivă, adică trebuie satisfăcută relația
C(a)C(b) = C(ab) ,
unde C reprezintă codul aritmetic, a și b sunt operanzii, iar este operația
aritmetică. Rezultatul operației efectuate asupra a două numere reprezentate
sub formă codificată trebuie să fie același cu codul rezultatului operației
respective dintre cele două numere originale.
Există diferite feluri de coduri aritmetice, cele mai frecvent întâlnite fiind
codurile AN și codurile reziduale.
a) Coduri AN
În acest caz cuvântul de cod al unui număr natural N se formează prin
înmulțirea acestuia cu o constantă A. Acest cod este invaria nt numai față de
operațiile de adunare și scădere, deci poate fi folosit numai pentru controlul
acestora. Este evidentă relația:
AN 1±AN 2 = A(N1±N2)
Decodificarea se face prin împărțirea rezultatului la A, care trebuie să se facă
fără rest în cazul lipsit de eroare. Se remarcă despre codul obținut sub această
formă faptul că nu este un cod separabil.
Capacitatea de detecție a codului depinde de valoarea lui A. Pentru a
detecta o eroare singulară, este necesar ca să nu existe două cuvinte de cod
care să difere printr -un singur bit, deci trebuie ca
AN 1AN 2 = A(N1N2) 2i , i = 0,1,.., n1
n fiind lungimea codului. Condiția este îndeplinită dacă A nu este divizibil cu 2 și
A>1, alegerea cea mai simplă fiind A=3. Se obține codul 3 N, care are distanța de
cod Dmin=2 și permite detectarea tuturor erorilor singulare . Codificarea se poate
face simplu printr -o deplasare la stânga și adunare, pe baza relației 3 N=2N+N.
Dacă cuvântul original este de k biți, atunci numărul necesar de biți
pentru a reprezenta numărul AN este:
n log 2AN = log 2A+log 2N = log 2A+k
Termenul log 2A se numește valoarea redundantă a codului . În cazul codului
3N, această valoare este log 23=1,6 și deci cuvântul de cod necesar este de
lungime n=k+2 biți. Pentru exemplificare, se dau în tabelul următor codurile 3 N
ale numerelor binare de 3 biți:
Date Cuvântul de cod 3 N
0 0 0 0 0 0 0 0
0 0 1 0 0 0 1 1
0 1 0 0 0 1 1 0
0 1 1 0 1 0 0 1
1 0 0 0 1 1 0 0
1 0 1 0 1 1 1 1
1 1 0 1 0 0 1 0
1 1 1 1 0 1 0 1
Schema de principiu a utilizării codului 3 N la adunare este dată în figura
3.47. Fie de adunat numerele A=4 care are codul (01100) și B=2 codificat prin
(00110). În cazul fără eroare se obține suma S=(10010), care este codul lui 6.
Dacă însă ieșirea s0 este pusă pe ”1”, atunci rezultă S=(10011), ceea ce
constituie un cod ilegal și astfel eroarea a fost detectată. Detectorul de eroare
reprezintă un circuit logic combinațional sintetizat astfel încât să dea la ieșire
valoarea logică 1 dacă se obține un cuvânt de 5 b iți care nu face parte din cele 8
combinații legale.
O variantă a codurilor AN este codul AN+B, care pentru o alegere
adecvată a lui B prezintă proprietatea de a fi autocomplementar. În acest caz
codul complementului unui număr este identic cu complementul codului acelui
număr.
b) Coduri reziduale
Codurile reziduale ( residual codes ), numite și coduri cu resturi , se obțin prin
atașarea la numărul de codificat a restului obținut prin împărțirea sa la un
întreg numit modul . Prin procesul de codificare rezultă un cuvânt de cod
separabil de forma celui din figura 3.48, unde restul R se obține conform
relației
N = mQ+R ,
adică
Figura 3.47. Schema utilizării codului 3N la adunarea a două numere
N = R mod m ,
m fiind modulul (0 R<m).
Numărul biților redundanți depinde de modulul ales, și anume r=log 2m,
unde reprezintă rotunjirea în sus până la următorul întreg. Dacă m=2r1,
unde r2 este egal cu numărul de biți redundanți, atunci se obține codul
rezidual cu cost redus (low-cost residual code ). De exemplu pentru m=3, codul
va necesita k+2 biți, k fiind lungimea inițială a numărului. Pentru k=3 cuvintele
de cod sunt sintetizate în tab elul următor:
Date Restul Codul rezidual
0 0 0 0 0 0 0 0 0
0 0 1 1 0 0 1 0 1
0 1 0 2 0 1 0 1 0
0 1 1 0 0 1 1 0 0
1 0 0 1 1 0 0 0 1
1 0 1 2 1 0 1 1 0
1 1 0 0 1 1 0 0 0
1 1 1 1 1 1 1 0 1
La codul rezidual cu cost redus generarea restului se poate face relativ
simplu prin evitarea operației de împărțire, pe baza unei sume ponderate a
biților numărului. Fie, pentru k=8 biți, numărul de codificat:
N = d727+ d626+ d525+ d424+ d323+ d222+ d121+ d020
Dacă se lucrează modulo 3, atunci puterea lui 2 poate fi exprimată sub forma
2i = bi mod 3 ,
unde bi este rezultatul împărțirii lui 2i la 3. În particular, pentru i=0,1,..,7 se
obțin valorile b0=1, b1=2, b2=1, b3=2, b4=1, b5=2, b6=1, b7=2. Se observă că
aceste ponderi se repetă luate câte două. Numărul N devine:
N = (2d7+ d6+ 2d5+ d4+ 2d3+ d2+ 2d1+ d0) mod 3
Dar pe de altă parte, R fiind restul împărțirii numărului la 3, se poate scrie:
N = R mod 3
Din cele două relații anterioare rezultă:
Figura 3.48. Dispunerea biților numărului original (N) și a
restului (R) la un cuvânt de cod rezidual
(2d7+d6)+(2d5+d4)+(2d3+d2)+(2d1+d0) = R mod 3
Cu alte cuvinte, restul R se poate calcula prin adunarea modulo 3 a cifrelor
binare obținute prin gruparea câte doi a biților numărului original. Schema de
codificare va conține în acest caz sumatoare modulo 3 (figura 3.49). Pe schemă
s-a luat ca exemplu N=10101101 (173 în baza 10) , care prin împărțirea la 3
generează restul egal cu 2, adică în binar R=10. În general, restul de control
pentru un cod rezidual cu cost redus ( m=2r1) se obține prin gruparea biților
numărului pe grupe de câte r biți, care se adună apoi modulo m.
Pentru controlul operațiilor aritmetice se exploatează proprietatea de
invarianță a codului rezidual față de adunare, scădere și înmulțire (nu și față de
împărțire), și anume
N1N2 = (R1R2) mod m ,
N1N2 = (R1R2) mod m ,
unde R1 și R2 reprezintă rezidurile numerelor N1 și N2. Având în vedere relațiile
Figura 3.49. Modul de obținere a restului prin însumare
la un cod rezidual cu modulul m=3
de mai sus și caracterul separabil al codului, rezultă că resturile pot fi tratate
separat de datele utile în timpul unei operații. Pe lângă simplitatea circuitului
de codificare, acest lucru reprezintă un alt avantaj al c odurilor reziduale.
Schema bloc a unui sumator înzestrat cu capacitate de control prin
coduri reziduale este cea din figura 3.50. Numerele N1 și N2 sunt adunate într –
un sumator pentru a forma suma S=N1+N2. În paralel se însumează modulo m
resturile R1 și R2 ale celor două numere obținute prin procesul de codificare.
Rezultatul ( Rs) trebuie să reprezinte tocmai restul corespunzător sumei celor
două numere, în cazul lipsit de eroare. Restul Rs este comparat cu cel generat
din suma efectiv obținută ( Re) pentru a pune în evidență, la necoincidență, o
eventuală eroare produsă de elementele din schemă.
Utilizarea codului rezidual cu modulul m=3 permite detectarea tuturor
erorilor singulare care afectează operația aritmetică. Presupunând că o eroare
E a afectat numărul N, acesta se va transforma în N+E. Pentru a detecta
eroarea este necesar ca restul obținut la decodificare să fie diferit de cel corect,
adică
N+E R mod 3
Dar, întrucât N=R mod 3, condiția devine E0 mod 3, ceea ce este evident
îndeplinită pentru cazul unei erori singulare pentru care E=2i (i=0,1,…, k1).
Figura 3.50. Schema de principiu a unui sumator care
utilizează codul rezidual
O variantă modificată a codului rezidual este codul rezidual invers , care
se formează prin atașa rea inversului restului obținut prin împărțirea numărului
la modul. În loc de R, informația redundantă va fi Q=mR. Codul rezidual invers
este de asemenea separabil și invariant față de aceleași operații ca și codul
direct. Acest cod este recomandat pentru o mai bună capacitate de detectare a
defectelor de utilizare repetată. Asemenea defecte introduc erori de mai multe
ori înainte de verificarea codului, de exemplu în cazul prelucrării multiple pe
același hardware.
3.3. Redundanța temporală
Acest fel de redundanță reduce necesarul de hardware suplimentar pe seama
unui timp adițional. Utilizarea ei se poate permite în unele sisteme, unde
timpul nu este un factor critic. A fost folosită inițial la detectarea defectelor
tranzitorii, se poate însă aplica și l a detectarea defectelor permanente.
3.3.1. Detectarea defectelor tranzitorii
Principiul detectării defectelor tranzitorii constă în repetarea prelucrării la
diferite momente de timp și compararea rezultatelor obținute. Dacă ele diferă,
atunci se semnalea ză eroare, presupunându -se că aceasta a fost cauzată de un
defect tranzitoriu. Procedeul se poate apoi relua, pentru a constata dacă
eroarea a dispărut. Schema de principiu a detectării defectelor tranzitorii este
dată în figura 3.51.
Problema care se ridi că la acest tip de redundanță este de a asigura
disponibilitatea datelor corecte pentru toate prelucrările ulterioare primeia. În
cazul în care există implementată o tehnică de detectare a erorii (de exemplu
coduri detectoare de eroare), nu mai este necesa ră o comparare a rezultatelor:
dacă la prima prelucrare a apărut o eroare, atunci se repetă prelucrarea pe
același hardware. În situația în care eroarea a dispărut, înseamnă că a existat
un defect tranzitoriu, în schimb dacă ea persistă în continuare atunc i este
cauzată de un defect permanent. Va fi necesară atunci eliminarea părții
defecte.
Figura 3.51. Principiul detectării defectelor tranzitorii
prin utilizarea redundanței temporale
3.3.2. Detectarea defectelor permanente
Și acest concept se bazează pe repetarea prelucrării, dar presupune
modificarea modului în care se face prelucrarea a doua oară. Schema de
principiu este ilustrată în figura 3.52. Înainte de a doua prelucrare se face o
codificare a informației, iar rezulta tul este apoi decodificat, prelucrarea fiind
efectuată pe același hardware. Prin compararea rezultatelor obținute în cele
două cazuri se poate pune în evidență o eroare permanentă, în cazul în care ele
sunt diferite.
Modul de codificare a datelor influențe ază tipurile de defecte
permanente care se pot detecta. Există mai multe metode de codificare
utilizate la repetarea prelucrării, care vor fi prezentate în continuare.
a) Logica alternantă (alternate logic )
Această metodă presupune efectuarea celei de a doua prelucrări asupra
complementului datelor inițiale. Ea se poate aplica cu succes circuitelor
combinaționale autoduale, care au proprietatea:
fxfx () ()
În acest caz, procedeul schematic este cel din figura 3.53. Eroarea se
detectează prin compararea rezultatelor celor doua prelucrări, care trebuie să
fie complementare în situația lipsită de eroare.
Figura 3.52. Principiul detectării defectelor permanente prin
utilizarea redundanței temporale
Figura 3.53. Principiul utilizării logicii alternante la
un circuit autodual
Un exemplu de circuit autodual este sumatorul complet, la care
complementarea intrărilor duce la complementarea ieșirilor (figura 3.54). Se
observă că dacă pe intrare se aplic ă valorile negate ale datelor originale, ieșirile
vor produce de asemenea valori negate, în cazul în care circuitul este lipsit de
defecte. O eroare se detectează dacă pentru intrări complementare ieșirile nu
produc valori alternante. Totuși, nu orice def ect poate fi detectat, de exemplu
pentru nodul D pus pe “1”, vectorii de intrare (000) și (111) vor produce pe
ieșire (10), respectiv (01), deci valori complementare, dar diferite de cea
corectă (00), respectiv (11). De aici se poate trage concluzia, de al tfel valabilă la
orice metodă de toleranță, că trebuie specificată lista acelor defecte care pot fi
tratate cu succes.
În general, pentru a se putea aplica metoda logicii alternante, orice
circuit combinațional cu n variabile poate fi transformat într -unul autodual cu
n+1 variabile în felul următor:
se implementează
fx xn (,,)1
se implementează
f fx xd n (,,)1
se efectuează
fxfxfa n n d 1 1
Conceptul logicii alternante pentru detectarea defect elor permanente se
poate aplica în transmisiile de date, așa cum a fost prezentat la codurile cu
duplicare (vezi 3.2.6): la momentul t0 se transmit datele originale, iar la t0+
datele complementate, apoi se compară datele sosite la recepție.
b) Recalcularea cu operanzi deplasați (RESO Recomputing with Shifted
Operands )
Această metodă utilizează o deplasare aritmetică la stânga pentru codificare,
respectiv o deplasare la dreapta pentru decodificare. Dacă cele două prelucrări
decalate în timp (fără deplasare, respectiv cu deplasarea operanzilor), sunt
efectuate pe același hardware, atunci defectul permanent va produce erori pe
poziții di ferite și prin compararea rezultatelor acesta se poate pune în evidență.
Metoda este adecvată pentru detectarea defectelor din unitățile
aritmetice și logice, precum și în general pentru o organizare bit -slice a
hardware -ului. Schema bloc a unui ALU care u tilizează metoda RESO este
prezentată în figura 3.55.
Figura 3.54. Schema și tabelul de adevăr al unui
circuit autodual: sumatorul complet
Figura 3.55. Schema bloc a unei unități aritmetice și logice care
utilizează recalcularea cu operanzi deplasați (RESO)
În cazul operațiilor logice, efectuate bit cu bit între cei doi operanzi,
pentru determinarea erorii generate de ALU pe o poziție este suficientă
deplasarea cu un singur bit. Însă în cazul operațiilor aritmetice de adunare, este
necesară o deplasare cu doi biți, deci sumatorul trebuie să aibă două poziții
suplimentare față de schema fără redundanță. Tabelul de erori pentru poziția i
a sumatorului este următorul:
Eroarea
introdusă în poziția i Efectul
asupra rezultatului
Si=0 (în loc de 1) 2i
Si=1 (în loc de 0) +2i
Ci=0 2i+1
Ci=1 +2i+1
Si=0, Ci=0 2i+12i = 3·2i
Si=0, Ci=1 +2i+12i = +2i
Si=1, Ci=0 +2i2i+1 = 2i
Si=1, Ci=1 +2i+2i+1 = +3·2i
Cu Si s-a notat suma din poziția i, iar cu Ci transportul din poziția i (vezi figura
3.54) . Sintetizând datele din tabel, în urma defectării poziției i, rezultatul va fi
alterat cu una din valorile {±2i, ±2i+1, ±3·2i}. Prin prelucrarea deplasată cu două
poziții la stânga ( ii2), rezultatul va fi alterat cu {±2i2, ±2i1, ±3·2i2}. Se
observă că mulțimile de erori introduse sunt diferite, deci compararea
rezultatelor va pune în evidență orice eroare din poziția i a sumatorului.
c) Recalcularea cu operanzi interschimbați (RESWO Recomputing with
Swapping Operands )
La această meto dă, cu ocazia celei de -a doua prelucrări, pentru codificare se
utilizează interschimbarea celor două jumătăți ale operanzilor. Astfel orice
defect de pe poziția i se detectează, deoarece el afectează jumătatea inferioară
sau superioară a operanzilor la pri ma prelucrare, respectiv jumătatea cealaltă
la a doua prelucrare. Metoda RESWO nu necesită adăugarea a două poziții
redundante la ALU, dar biții de transport (pe intrare, ieșire și transportul
auxiliar) trebuie tratați într -un mod particular.
Schema de principiu este dată în figura 3.56.
Figura 3.56. Principiul detectării erorii prin metoda recalculării
cu operanzi interschimbați (RESWO)
d) Recalcularea cu duplicare cu comparare (REDWC Recomputing with
Duplication with Comparison )
Această metodă utilizează duplicarea cu comparare pentru detectarea erorii,
respectiv redundanța temporală pentru desăvârșirea calculului. Pentru un
sumator de n biți, care se împarte în două jumătăți de câte n/2 biți, scenariul de
prelucrare a operanzilor este (figura 3.57):
se adună jumătățile inferioare ale operanzilor ( AL și BL) în ambele
sumatoare
se compară rezultatele
se adună jumătățile superioare ale operanzilor ( AH și BH)
se compară rezultatele
se furnizează rezultatul final compus din jumătățile obținute în cele
două etape ( RL și RH)
În acest mod se detectează erorile singulare din oricare jumătate a sumatorului
(dacă nu a apărut același defect în ambele jumătăți).
Figura 3.57. Principiul metodei de recalculare prin
duplicare cu comparare (REDWC)
În concluzie, ca și la redundanța informațională, se poate constata că
toate metodele de toleranță bazate pe redundanța temporală necesită și o
anumită cantitate de hardware suplimentar.
3.4. Redundanța software
Tratarea defectelor fizice prin redundanță hardware, care presupune o
replicare a procesoarelor și datelor, necesită și existența de copii multiple ale
programelor care se execută pe aceste procesoare. Această formă de
redundanță software se bazează pe copii identice ale pro gramelor și în
consecință nu poate tolera și defectele conținute în programe. În cadrul acestui
subcapitol, redundanța software se va considera a fi utilizată pentru tolerarea
însăși a defectelor de proiectare ale programelor, ceea ce se poate obț ine
numai dacă se asigură diversitatea proiectelor software (software design
diversity ). Prin această abordare programele utilizate pentru prelucrări multiple
nu sunt copii, ci elemente elaborate independent pentru a satisface aceleași
cerințe. Datorită complexității mari a programelor actuale s -a dovedit că
tehnicile de prevenție a defectelor nu sunt suficiente pentru asigurarea unei
fiabilități înalte a software -ului. Astfel, utilizarea redundanței software pentru
tolerarea defectelor de proiectare repr ezintă ultima pârghie care poate duce la
creșterea încrederii în fiabilitatea sistemului.
Cele două metode de bază pentru realizarea toleranței la defecte în
sistemele software sunt: programarea N-versională și blocul de restabilire.
3.4.1. Programarea N-versională
Prin metoda programării N-versionale ( N-version programming ), se execută N
versiuni ( N>1) ale unui program, care au fost proiectate independent și care
satisfac aceeași specificație comună, iar rezultatele sunt comparate printr -un
vot majoritar . Concepția utilizată este similară cu structura NMR statică de la
redundanța hardware, schema bloc de principiu fiind corespunzătoare unei
redundanțe modulare (figura 3.58).
Presupunând că același defect nu este conținut în două versiuni diferite,
această tehnică permite tolerarea unui număr de ( N1)/2 defecte. Pentru N=2
sistemul poate oferi doar o detecție de eroare, care reprezintă cazul limită al
toleranței și se poate utiliza în sistemele de tip fail -safe prin tranzitarea într -o
stare sigură în caz de eroare.
Implementarea programării N-versionale este asigurată de un program
driver , care are trei funcții:
invocă fiecare versiune
așteaptă pentru a se executa toate versiunile
colectează rezultatele, le compară și decide asupra datelor de ieșire
Pentru a putea funcționa cu succes, metoda impune satisfacerea
următoarelor cerințe :
Independența versiunilor. Se caută soluții pentru a asigura implementări
diferite ale versiunilor (prin algoritmul utilizat, limbajul de programare etc.)
pornind de la specificații comune, pentru a încerca să se prevină introducerea
aceluiași defect. Fiecare versiune se elaborează de echipe separate de
Figura 3.58. Principiul program ării N -versionale
programatori cu scopul de a îndeplini cerința de diversitate a software -ului. Nu
se pot tolera greșelile de specificare ( specification mistakes ), de aceea trebuie
acordată o importanță deosebită întocmirii specificațiilor inițiale.
Toate versiunile să dispună de același set de date de intrare. Aceste date
sunt transmise de driver sau preluate dintr -o structură globală de tip citire
(read -only). Pentru a reduce schimbul de date, uneori se permite fiecărei
versiuni să -și rețină și struct uri private de date folosite la eventualele execuții
ulterioare ale programului. O astfel de soluție poate însă duce la o eroare prin
efectul cumulat al micilor neconcordanțe din execuțiile succesive.
Fiecare versiune să fie atomică în raport cu celelalte. Versiunile trebuie
astfel elaborate încât să fie fără comunicări și interferențe între ele. În acest caz
nu este necesară nici o acțiune de evaluare a pagubei, execuțiile fiind izolate.
Proprietatea este oferită cel mai simplu de sistemele multiprocesor, la care
fiecare versiune se execută într -un nod separat.
Sincronizarea activității driver -ului cu cea a versiunilor. Sincronizarea este
posibilă cu primitivele de tip wait și send , după modul descris în continuare. O
versiune stă în wait și așteaptă să înc eapă prelucrarea până când driver -ul
execută send , respectiv driver -ul așteaptă ( wait ) terminarea prelucrării care
este indicată de versiunea de program prin send . De asemenea, pentru a trata
defectele de proiectare care cauzează o buclă infinită, este nec esară
prevederea unui mecanism de timeout , menit să genereze o excepție după
expirarea unui timp prestabilit. Dacă programele sunt prea lungi, comparațiile
trebuie efectuate mai rar, dar apare dezavantajul unor așteptări pentru
sincronizarea rezultatelor. Pe de altă parte, programele prea scurte reduc
gradul de independență și diversitatea proiectării.
Comunicarea rezultatelor la driver în același format. Rezultatele se
furnizează de regulă sub forma unui vector de date și fanioane de stare. Aceste
fanioane indică modul în care a reușit execuția, de exemplu pot semnala
apariția unei excepții care nu a fost tratată de handler -ul local. Pentru a
minimiza cantitatea de date transferate, în sistemul SIFT s -a adoptat soluția
votării asupra sumei de control a rez ultatelor.
Modul în care se face votarea asupra datelor rezultate de la fiecare
versiune depinde foarte mult de aplicația în cauză. Astfel, decizia care asigură
detectarea rezultatelor eronate, poate fi:
Votare bazată pe egalitatea între rezultate. În acest caz datele de
ieșire vor fi date de majoritatea rezultatelor identice.
Votare „inexactă”, atunci când între valorile furnizate de fiecare
versiune pot fi admise mici neconcordanțe datorită modului de
reprezentare a numerelor sau din cauza algoritmilor diferiți cu care s –
a lucrat. În acest caz se poate proceda la eliminarea valorilor extreme,
adică selectarea valorilor de mijloc ( mid-value select ) sau se poate
renunța la biții cei mai puțin semnificativi ai numerelor.
În principiu, metoda p rogramării N-versionale se poate utiliza sub forma
execuțiilor succesive ale versiunilor pe același procesor, care apoi alege
rezultatul corect printr -o decizie majoritară. În practică totuși se preferă
execuția simultană a celor N versiuni pe mai multe pr ocesoare. Metoda este
adecvată pentru sistemele distribuite, care prin natura lor au resurse hardware
disponibile și pentru care se poate implementa simplu un vot majoritar. De
asemenea, programarea N-versională este recomandabilă și în structurile
hardwar e NMR pentru a împiedica apariția unei erori cauzate de un defect
software comun în toate modulele.
3.4.2. Blocul de restabilire
Blocul de restabilire ( recovery block ) reprezintă o structură de program care
conține mai multe versiuni și care se pot execu ta succesiv până când un test de
acceptare asupra rezultatului furnizat nu este satisfăcut. În caz de nereușită a
testului, starea sistemului se restaurează la punctul de restabilire înființat la
intrarea în blocul de restabilire. Acesta este un caz de res tabilire înapoi, care
necesită salvarea stării sistemului la punctul de restabilire. Schematic blocul de
restabilire se prezintă ca în figura 3.59.
Metoda este similară cu redundanța hardware dinamică, la care o
rezervă este cuplată dacă modulul de bază se defectează. Presupunând defecte
independente și o detectare perfectă a erorilor prin testul de acceptare, blocul
de restabilire permite tolerarea a maxim N1 defecte. Dacă și ultima versiune
alternativă eșuează, atunci se semnalează eroare.
Figura 3.59. Principiul de lucru al unui bloc de restabilire
Structura blocului de restabilire poate fi descrisă într -un limbaj formal în
felul următor:
Descrierea arată faptul că prima dată se execută modulul primar de program,
ieșirea fiind verificată de testul de acceptare. Dacă rezultatul se consideră
acceptabil, atunci se iese din blocul de restabilire. În caz contrar se trece la ensure <test de acceptare >
by <modulul primar >
else by <alternativa 1>
else by <alternativa N 1>
else eroare
execuția primei alternative, urmată de testul de acceptare. Dacă nici o
alternativă nu a produs rezultat acceptabil, atunci tot blocul de restabilire este
declarat defect.
Porțiunea de program care se structurează sub forma unui bloc de
restabili re reprezintă de regulă un modul, o subrutină sau o procedură care
realizează o anumită funcție bine definită. Modulul primar este acel program
care a fost elaborat să satisfacă întocmai și cel mai eficient (ca și timp, spațiu de
memorie etc.) specificații le impuse și care s -ar folosi în cazul lipsit de
redundanță. Modulele alternative realizează aceeași funcție ca și cel primar,
dar într -o manieră diferită și de regulă mai puțin eficientă (de exemplu pot fi
versiuni mai vechi ale programului). Independența între module se asigură prin
găsirea de algoritmi cât mai ortogonali față de algoritmul folosit în modulul
primar și mai puțin prin apelarea la programatori diferiți ca la programarea N-
versională.
Nu este necesar ca toate modulele dintr -un bloc de restab ilire să
furnizeze exact aceleași rezultate, ele trebuie să producă doar rezultate
acceptabile, conforme cu testul de acceptare. Ca urmare, blocul de restabilire
poate fi utilizat pentru întocmirea unui software cu degradarea „grațioasă ” a
performanțelor (gracefully degrading software ). Aceasta înseamnă că modulul
primar încearcă să furnizeze rezultatul dorit, însă modulul secundar și celelalte
alternative încearcă doar să furnizeze rezultate din ce în ce mai degradate, dar
totuși acceptabile. Evident, cu c ât serviciul oferit este mai slab, cu atât modulul
de program corespunzător este mai simplu și deci probabilitatea de a conține
defecte de proiectare este mai mică.
Testul de acceptare (acceptance test ) reprezintă în principiu o expresie
logică care se eva luează după execuția unui modul de program pentru a stabili
dacă starea rezultată a sistemului este acceptabilă sau nu în raport cu o stare
anticipată a fi corectă. Rezultatul evaluării este de tip „adevărat” sau „fals”.
Testul de acceptare constituie o co mponentă critică a blocului de restabilire,
deoarece un test de acceptare puțin fiabil va duce la un bloc de restabilire de
fiabilitate redusă indiferent de numărul de module alternative pe care le
conține. În consecință, testul de acceptare trebuie să fie cât mai simplu pentru
a reduce atât posibilitatea de a putea conține defecte de proiectare, cât și
pentru a nu introduce întârzieri excesive în timpul de execuție. De asemenea, el
nu trebuie să aibă efecte secundare asupra comportării, în sensul de a pute a
modifica starea sistemului.
Alegerea unui anumit test de acceptare depinde în mare măsură de
aplicația în cauză, neexistând o metodologie unitară în acest scop. Pe de o
parte, așa cum s -a arătat, testul de acceptare trebuie să fie simplu, dar pe de
altă parte este de dorit ca acesta să fie cât mai cuprinzător, pentru a putea
detecta cât mai multe erori posibile. În cazul blocului de restabilire cu
degradare, testul trebuie adaptat modulului care oferă serviciile cele mai
scăzute.
Elaborarea testelor de a cceptare se bazează pe următoarele principii
uzuale:
Satisfacerea cerințelor. Se verifică dacă rezultatul furnizat reprezintă o
soluție pentru problema dată. De exemplu, se controlează dacă în urma unui
program de sortare elementele sunt aranjate în ordine descrescătoare.
Inversarea. Se bazează pe efectuarea operației matematice inverse și
compararea valorii obținute cu data inițială. De exemplu, se poate verifica prin
ridicare la pătrat, dacă s -a extras corect radicalul dintr -un număr.
Aserțiunea executabi lă (executable assertion ). Se verifică dacă este
îndeplinită o anumită condiție (care depinde de problema de rezolvat) între
variabilele rezultate în urma execuției și cele corespunzătoare stării salvate în
punctul de restabilire. Valorile anterioare sunt accesibile pentru testul de
acceptare numai pentru citire, sub forma: prior nume_variabilă . De exemplu,
testul de acceptare poate verifica dacă variabilele modificate de program au
fost cele așteptate.
Rezonabilitatea. Se verifică încadrarea rezultatului î ntre anumite limite
proprii mărimii respective. Acest test este utilizabil mai ales în cazul mărimilor
fizice care trebuie să aparțină unui domeniu admisibil. Un exemplu în acest
sens constituie viteza unui vehicul. O altă posibilitate, în aplicațiile de c ontrol,
constă în compararea valorii măsurate cu cea calculată teoretic pe baza unui
model al sistemului real.
Verificări structurale. Se verifică dacă datele furnizate respectă o
anumită structură așteptată, un exemplu fiind lungimea unui mesaj.
Verificări contabile. Se folosesc în sistemele de tranzacție (de exemplu
de rezervare a biletelor, bancare etc.) și se bazează pe compararea noului total
în urma unei secvențe de operații cu cel vechi.
Verificări temporale. Detectează neîncadrarea execuție i unui program
într-o limită de timp dată. Asemenea verificări sunt utile la sistemele de timp
real.
La intrarea în blocul de restabilire, variabilele sistemului trebuie salvate,
de exemplu într -o memorie cache de restabilire (recovery cache , vezi 4.3.4 ).
Aceasta trebuie să fie cât se poate de rapidă pentru a nu introduce întârzieri
suplimentare la scriere și la restabilirea stării anterioare, dacă este necesară.
Uneori se plasează un test de acceptare și la intrarea în blocul de
restabilire, care verifi că dacă datele de intrare sunt valide. Astfel se urmărește
inițierea cât mai timpurie a unei acțiuni corective și se previne propagarea
datelor invalide. Dacă este posibil, se solicită în acest caz noi date de intrare, de
exemplu dacă ele provin de la un o perator care a greșit la introducere. Această
măsură este menită să ducă la creșterea robusteții (robustness ), care
reprezintă gradul în care software -ul poate furniza serviciul corect în ciuda unor
date de intrare invalide.
În ceea ce privește implementar ea blocului de restabilire, comutarea
între modulele blocului poate fi asigurată prin intermediul unor instrucțiuni
specifice sau poate fi lăsată pe seama unui mecanism de tratare a excepțiilor. În
acest din urmă caz, la o respingere a rezultatelor de cătr e testul de acceptare
se produce o excepție care apelează un handler, acesta făcând inițierea
operației de restabilire și trecerea controlului la următorul modul alternativ.
Tratarea excepțiilor se poate utiliza și în interiorul unui modul al blocului
de r estabilire, de exemplu pentru a asigura o restabilire înainte în cazul unei
situații de eroare din timpul execuției. Astfel la o depășire în jos a domeniului
de reprezentare ca urmare a unei operații aritmetice, handler -ul poate reface
rezultatul la valoar ea cea mai mică care se poate reprezenta și astfel
prelucrarea poate continua. Pentru a crește fiabilitatea programelor, și în
interiorul unui modul este recomandabilă prevederea de verificări de tipul:
assert expresie_logică .
Pentru a trata cazul când blo cul de restabilire eșuează (nici o alternativă
nu trece testul), acesta se poate încadra într -un alt bloc de restabilire de nivel
ierarhic superior. Astfel se formează o structură cu blocuri de restabilire
încuibate (nested recovery blocks ), care este dat ă mai jos într -o descriere
formală. În acest caz blocul de restabilire B2 face parte din modulul primar al
blocului exterior B1. Dacă toate modulele blocului interior eșuează, atunci
clauza else eroare va provoca o excepție care va duce la restabilirea stării în
blocul exterior. Execuția se va relua cu prima alternativă a blocului B1.
B1: ensure <test de acceptare 1>
by /* modul primar B1 */
begin
B2: ensure <test de acceptare 2>
by <modul primar B2>
else by <prima alternativă B2>
else by <a M1-a alternativă B2>
else eroare
end
else by <prima alternativă B 1>
else by <a N1-a alternativă B1>
else eroare
Prin utilizarea blocurilor încuibate se tratează de asemenea cazul în care
testul de acceptare al unui bloc eșuează din cauza unei erori propagate.
Această situație apare dacă starea la intrarea în bloc nu este lipsită de eroare și
atunci îngrădirea erorii nu se mai poate limita la nivelul blocului. În acest caz
revenirea la punctul de restabilire al blocului interior nu este suficientă, fiind
oportună revenirea la un punct anterior lipsit de eroare, și anume cel al
blocului de restabilire extern. În acest sens nu trebuie uitat fapt ul că blocul de
restabilire are menirea de a forma o stavilă ( lock-stop ) împotriva erorilor
neanticipate cauzate de defectele de proiectare ale programului și pentru a
căror tratare nu au fost prevăzute handlere de excepție (și chiar acestea pot
conține de fecte). De asemenea, prin utilizarea blocurilor de restabilire
încuibate devine posibilă includerea mai multor teste de acceptare cu grade
diferite de severitate pentru cazul sistemelor cu degradarea performanțelor.
Implementarea toleranței la defecte cu a jutorul blocurilor de restabilire
duce la o creștere a necesarului de memorie (pentru salvarea stării, păstrarea
modulelor alternative și a testului de acceptare) și a timpului consumat pentru
execuție față de situația neredundantă. Totuși, în cazul unei f uncționări
normale, fără defecțiuni, întârzierea introdusă nu este semnificativă, ea fiind
datorată doar salvărilor pentru stabilirea punctului de restabilire și execuției
testului de acceptare. Datorită faptului că la un moment dat se execută un
singur pr ogram, metoda este adecvată în primul rând sistemelor cu un singur
procesor, dar pot fi concepute și blocuri de restabilire distribuite care
integrează toleranța hardware și software într -o singură structură.
3.5. Sisteme autotestabile
În general prin sistem autotestabil (self-checking system ) se înțelege acel
sistem care are capacitatea de a detecta automat existența unui defect al său,
fără necesitatea oricărui stimul extern. Este de notat faptul că un astfel de
sistem trebuie să pună în evidență defect ul în timpul funcționării sale normale.
În reprezentarea schematică a unui sistem autotestabil (figura 3.60) se
disting două tipuri de ieșiri: cele de date și o ieșire indicatoare de defect
(EROARE). Ieșirea EROARE, dacă se activează, indică defectarea sistemului și
poate fi folosită pentru a declanșa oprirea sau reconfigurarea sistemului.
Autotestabilitatea la nivel de modul este importantă în cadrul tolerării
defectelor prin redundanță dinamică pentr u a putea detecta și înlocui modulul
defect.
Figura 3.60. Schema bloc a unui sistem autotestabil
Pentru caracterizarea cantitativă a unui sistem autotestabil nu este
suficient indicatorul de fiabilitate, deoarece acesta nu reflectă modul în care se
comportă sistemul la apariția unui defect. Fiabilitatea sistemului ( R) reprezintă
probabilitatea ca sistemul să lucreze fără defecțiuni pe o durată dată, adică:
R = Pr(date de ieșire corecte ∩ semnalul EROARE nu a apărut)
Spre deosebire de fiabilitate, siguranța S (safety ) exprimă probabilitatea ca la
ieșirea acestuia să nu apară informație eronată nedetectată, adică:
S = 1Pr(date de ieșire eronate ∩ semnalul EROARE nu a apărut)
Cu alte cuvinte, siguranța sistemului reprezintă probabilitatea ca sistemul să
funcționeze corect sau să se defecteze într -o manieră sigură, evidențiată printr –
o indicare a defectării.
Ilustrarea acestor concepte se poate face cu ajutorul unui model Markov,
pe care se consideră o stare operațională (O) ș i două stări de nefuncționare a
sistemului (figura 3.61):
FS ( failed safe ), ceea ce înseamnă o defectare sigură, care este
detectată
FU ( failed unsafe ), corespunzătoare unei defectări nesigure, care nu
este detectată
Se consideră că rata de defectare a sistemului este , iar probabilitatea de
detectare a defectului este C (fault coverage ). În aceste condiții se poate scrie
Figura 3.61. Modelul Markov al unui sistem autotestabil
expresia fiabilității sub forma
R(t) = pO(t) = eλt ,
unde pO(t) este probabilitatea ca sistemul să fie în stare operațională. Pe de altă
parte:
pFS(t)+pFU(t) = 1 pO(t) = 1 eλt
pFS(t) = C(1 eλt)
Siguranța sistemului este dată de probabilitatea ca sistemul să fie în starea O
sau FS, și anume:
S(t) = pO(t)+pFS(t) = C+(1C) eλt
Evident, dacă C=1, sistemul este perfect sigur. Dacă C=0, defectarea sistemului
va decurge într -o manieră nesigură, nefiind pusă în evidență.
Pentru a se putea detecta apariția unei defecțiuni în sistem, se recurge
de regulă la o tehnică de codificare a datelor, care presupune redundanță
informațională. În cazul lipsit de defecte, la ieșirea sistemului se va furniza un
cuvânt de cod valid, presupunând că pe intrare s -a aplicat un cuvânt de
asemenea valid. Dacă însă sistemul s -a de fectat, acest lucru trebuie să se
manifeste la ieșire prin producerea unui cuvânt de cod invalid, care poate fi
detectat. Rezultă că spațiul cuvintelor de ieșire se împarte în două submulțimi
disjuncte (figura 3.62):
CV, care corespunde cuvintelor de cod v alide și pentru care semnalul
EROARE nu apare
CI, care conține cuvintele de cod invalide, puse în evidență prin
activarea ieșirii EROARE
Pentru a fi autotestabil, un sistem trebuie să posede anumite proprietăți :
1. Sistemul este testabil (self-testing*) dacă pentru fiecare defect din
mulțimea prestabilită de defecte există cel puțin un cuvânt de intrare
valid care să pună în evidență defectul la ieșire, printr -un cuvânt
invalid. Prin această proprietate se asigură ca fiecare defect să fie
detectabil.
2. Sistemul are proprietatea de a fi sigur la defecte (fault -secure ) dacă în
prezența unui defect dintr -o mulțime prestabilită, sistemul va furniza
la ieșire ori cuvântul corect, ori un cuvânt invalid pentru orice cuvânt
de intrare valid. Prin această proprietate se previne ca pentru un
cuvânt de intrare valid, la ieșire să se producă un cuvânt fals (valid,
dar incorect).
Un sistem care este atât testabil, cât și sigur la defecte se numește total
autotestabil (totally self -checking ). La un asemenea sistem toate defectele
singulare sunt detectabile de cel puțin un cuvânt de intrare valid, iar atunci
când defectul nu este det ectat de cuvântul prezent la intrare, ieșirea va furniza
cuvântul de cod corect. Totodată mulțimea cuvintelor de intrare valide trebuie
sa conțină cuvintele de test pentru toate defectele considerate ale sistemului.
Structura de bază a unui sistem total au totestabil este dată în figura 3.63.
* pentru proprietatea de testabilitate literatura de specialitate utilizează termenul de self-
testing , care trebuie însă utilizat diferit de self -checking, tradus prin autotestabil
Figura 3.62. Împărțirea mulțimii cuvintelor de ieșire în cuvinte
valide (CV) și invalide (CI) la un sistem autotestabil
Cuvintele de la ieșirea sistemului funcțional sunt monitorizate de o unitate de
supraveghere, numită checker (verificator). Acesta verifică dacă datele de la
ieșire reprezintă cuvinte de cod valide, iar în caz contrar d ă o indicație de
eroare (EROARE).
Figura 3.63. Subsistemele componente ale unui sistem autotestabil
Pentru a îndeplini condiția de autotestabilitate totală, atât sistemul
funcțional cât și unitatea de supraveghere trebuie să fie ambele total
autotestabile. O defectare a checker -ului trebuie de asemenea pusă în
evidență, ceea ce nu se poate realiza cu un singur semnal de EROARE. De
exemplu, dacă acesta prezintă un defect de punere pe “0”, nici un cuvânt de
cod invalid de la ieșirea sist emului nu mai este detectat. De aici rezultă
necesitatea ca numărul minim al ieșirilor unității de supraveghere să fie de
două, pentru ca informația de eroare să poată evidenția și o defectare a
acesteia. O soluție posibilă constă în implementarea checker -ului sub forma a
doua canale independente. Astfel o defectare a unui canal va afecta doar una
din ieșirile circuitului de supraveghere, fiind detectată. Aceste canale
independente pot avea în comun eventual niște semnale de intrare, orice
defectare pe intr are având același efect ca și aplicarea unui cuvânt invalid
circuitului.
În continuare se prezintă câteva soluții de realizare a sistemelor
autotestabile.
a) Sisteme autotestabile bazate pe duplicarea cu comparare
În acest caz metoda de codificare utilizată este duplicarea, asigurată de
modulul redundant identic ca și funcție cu modulul funcțional. Detectarea
defectului se efectuează prin compararea celor două răspunsuri într -un
comparator (figura 3.64).
Figura 3.64. Schema bloc a sistemului autotestabil bazat
pe duplicarea cu comparare
Pentru calculul funcției de fiabilitate a sistemului se notează cu R1, R2 și
RC fiabilitățile modulului funcțional, a celui redundant, respectiv a
comparatorului. Pentru ca sistemul să furnizeze date corecte și semnalul de
EROARE să nu apară, este necesar ca toate cele trei componente să fie
operaționale, fiabilitatea fiind deci:
R = R1R2RC
Stările nesigure ale sistemului corespund stărilor în care modulul funcțional
transmite informație eronată și comparatorul este defect. Siguranța sistemului
va fi dată în consecință de:
S = 1 (1 R1)(1 RC) = R1 + RC R1RC
Se observă că acea stă funcție nu depinde de modulul redundant, sistemul
având o funcționare sigură dacă cel puțin unul dintre modulul funcțional și
comparator sunt bune. Aceasta corespunde unei structuri de fiabilitate de tip
paralel, deci S>R1, dar fiabilitatea fiind un nu măr subunitar este cu atât mai
mult adevărată expresia S>R1R2RC, adică S>R. Cu alte cuvinte, chiar atunci când
fiabilitatea sistemului are o valoare relativ mică, există șanse mici de a se
transmite la ieșire o informație falsă nedetectată. De exemplu, dacă la un timp
al misiunii tm este adevărat R1(tm) = R2(tm) = Rc(tm) = 0,700 , atunci valorile pentru
fiabilitate și siguranță sunt R(tm) = 0,343 și respectiv S(tm) = 0,910.
Pentru a evita producerea aceluiași defect în cele două module (de
exemplu a unui defect de proiectare), modalitatea de implementare a
modulului redundant poat e fi diferită de cea a modulului funcțional. O altă
tehnică constă în utilizarea duplicării cu logică complementară , ceea ce
presupune ca modulul redundant să realizeze duala funcției de bază. Dacă f(X)
reprezintă funcția modulului neredundant, atunci func ția duală
corespunzătoare este
)( )( Xf Xfd , unde X = {x1,…,xn} reprezintă un vector
de intrare de n biți, iar
} ,…,{1 nx x X . Vectorul de intrare nenegat se aplică
modulului funcțional, iar complementul său celuilalt modul. În cazul fără
defecțiuni, ieșirile celor două module vor fi complementare și anume:
Y = f(X)
Y Xf XfZd )( )(
Elementul de supraveghere va trebui în acest caz să compare două cuvinte care
Figura 3.65. Schema verificatorului cu două canale (two -rail checker)
în mod normal sunt complementare. Un astfel de circuit, care are și
proprietatea de a fi total autotestabil, este verificatorul cu două canale (two-
rail checker ). În figura 3.65 este reprezentat acest circuit în situația în care n=2,
adică cuvintele de comparat sunt de doi biți. Checker -ul trebuie să determine
dacă cuvântul de cod aplicat pe intrările sale este valid sau nu, ceea ce se
traduce aici prin a verifica dacă cele două j umătăți ale cuvintelor sunt
complementare sau nu. În plus, așa cum s -a arătat deja, el trebuie să indice și
propriile sale defecte. Pentru a îndeplini ambele cerințe, ieșirea constă dintr -un
semnal de eroare codificat pe doi biți în felul următor:
Semnalel e e1 și e2 sunt complementare (01 sau 10) dacă intrările sunt
complementare și comparatorul este bun. Acest caz va corespunde lui
EROARE = 0.
Semnalele e1 și e2 nu sunt complementare (00 sau 11) dacă intrările
nu sunt complementare sau comparatorul conține un defect. Acest
caz va corespunde lui EROARE = 1.
Situa țiile posibile în cazul comparatorului lipsit de defect sunt sintetizate în
tabelul de mai jos:
Eroarea de
pe intrări y1 y2 z1 z2 e1 e2 EROARE
nu exist ă 0 0 1 1 0 1
0 0 1 1 0 1 0
1 0 0 1 1 0
1 1 0 0 0 1
1 1yz
0 0 0 1 0 0
1 0 1 0 0 0 0
1 0 1 1 1 1
1 1 1 0 1 1
2 2y z 0 0 1 0 0 0
1 0 1 1 1 1 1
1 0 0 0 0 0
1 1 0 1 1 1
2 21 1și
y zy z
0 0 0 0 0 0
1 0 1 0 1 0 0
1 0 1 0 0 0
1 1 1 1 1 1
În consecință, ecuațiile logice ale semnalelor de ieșire sunt următoarele:
e1 = y1z2 y2z1
e2 = y1y2 z1z2
Se poate verifica ușor că acest comparator este total autotestabil. Pe de
o parte, semnalele de ieșire sunt generate de două grupuri separate de circuite
logice, fapt care asigură proprietatea de siguranță la defecte. Într -adevăr, în
prezența unui cuvânt de intrare valid, orice defect singular dintr -un nod intern
va putea afecta cel mult una din cele două ieșiri, producând semnale
necom plementare. Ca urmare, un defect în comparator ori nu va modifica
ieșirile, ori va duce la valori complementare, cauzând detectarea erorii. Dacă
defectul apare la o intrare primară, acesta este echivalent cu aplicarea unui
cuvânt de intrare invalid, ceea c e produce eroare detectabilă. Astfel cerința de
siguranță la defecte este satisfăcută. Pe de altă parte, comparatorul este
testabil, fiind prin sinteză neredundant. Aceasta înseamnă că oricărui nod al
schemei îi corespunde cel puțin o combinație la intrări le primare astfel încât
ieșirile să depindă numai de valoarea logică a acestui nod. Acest lucru asigură
proprietatea de testabilitate a circuitului. Este de menționat faptul că în cazul
defectelor multiple, circuitul nu mai are proprietatea de a fi total a utotestabil.
În cazul în care numărul de intrări care trebuie comparate este mai mare
decât doi, atunci elementul de supraveghere se poate realiza prin conectarea
pe niveluri a checker -elor cu două canale pe doi biți.
b) Sisteme autotestabile bazate pe codur i detectoare de eroare
În cazul în care modulul funcțional operează asupra datelor codificate, checker –
ul trebuie să verifice dacă rezultatul furnizat aparține sau nu codului respectiv.
O structură posibilă a sistemului pentru coduri separabile este cea din figura
3.66. Elementul de supraveghere regenerează biții de control din partea utilă a
rezultatului și îi compară cu biții originali, iar în caz de neconcordanță se
semnalează eroare. Ca și comparator se poate utiliza un verificator pe două
canale cu semnale complementare ( two-rail checker ), dar în acest caz ieșirile
generatorului de biți de control trebuie complementate.
Soluția se poate apli ca în principiu pentru orice tip de cod separabil (de
paritate, aritmetice etc.), cu condiția ca operația efectuată de modulul
funcțional să asigure conservarea codului în lipsa unei defecțiuni. Acest lucru
înseamnă că dacă C(X) reprezintă codul corespunză tor informației utile X și f
este funcția produsă de modulul funcțional, atunci este necesar ca
Figura 3.66. Schema bloc a sistemului autotestabil bazat pe
utilizarea unui cod separabil
)( )( XfC XCf
De exemplu, funcția de transfer sau de memorare poate fi ușor verificată prin
codul de paritate. În cazul operațiilor aritmetice sau lo gice, trebuie să fie
satisfăcută relația
C(X)C(Y) = C(XY) ,
unde operația respectivă a fost notată cu . Existența acestei egalități depinde
de natura operației și de metoda de codificare adoptată.
Luând pentru sinteză cazul unui checker pentru codul de paritate, acesta
trebuie să verifice egalitatea y1 y2 … yn = 0. Pentru a se asigura siguranța
la defecte, așa cum s -a arătat deja, este de recomandat divizarea schemei pe
două canale independente și furnizarea semnalului de EROARE codificat pe doi
biți. Adoptând structura de principiu din figura precedentă, se ob ține (pentru
n=5) schema checker -ului total autotestabil pentru codul de paritate (figura
3.67). Se observă că în cazul parității, existând un singur bit de control ( y5) nu
mai este necesară utilizarea unui comparator. Circuitul propus este total
autotesta bil întrucât are două canale independente și nu conține redundanță.
Ieșirile sunt identice (00 sau 11) în cazul fără eroare, respectiv complementare
(01 sau 10) în cazul unei erori singulare a cuvântului de intrare sau apărută în
interiorul circuitului.
c) Sisteme autotestabile bazate pe inversarea funcției
Figura 3.67. Verificator total autotestabil
pentru codul de paritate
Schema bloc a unui astfel de sistem autotestabil este dată în figura 3.68.
Modulul redundant reface datele de intrare în sistem, realizând funcția inversă
celei efectuate de modulul funcțional. Comparato rul va detecta o eroare dacă
f1(Y) X.
Figura 3.68. Schema bloc a sistemului autotestabil bazat
pe inversarea funcției
O astfel de soluție de sistem autotestabil este realizabilă numai dacă
aplicația permite inversarea funcției. Acest lucru este posibil de exemplu la
sistemele de codificare și decodificare, dar nu și la sumatoare. Sistemul cu
asemenea structură este relativ scump, ca și sistemul bazat pe duplicarea
modulului de bază, dar mai are dezavantajul unui timp de răspuns m are
datorită propagării datelor prin cele două module.
Sistemele autotestabile își găsesc utilizarea în numeroase implementări
ale toleranței la defecte. Nu trebuie uitat faptul că detectarea erorii reprezintă
primul pas al oricărei măsuri de toleranță la defecte. La un sistem autotestabil
nu crește valoarea fiabilității sistemului, aceasta din contră este mai mică, în
schimb crește indicatorul de siguranță. Activarea indicației de eroare se poate
folosi pentru deconectarea sistemului sau trecerea sa înt r-o stare de rezervă.
De exemplu, la semafoarele de circulație stradală sau de căi ferate se asigură o
comportare sigură la defecte ( fail-safe) dacă ele comută și rămân permanent
pe culoarea roșie după apariția unui defect.
4. FAZELE TOLERANȚEI LA DEFEC TE
4.1. Detectarea erorii
Faza de detectare a erorii ( error detection ) reprezintă primul pas al toleranței la
un defect apărut în sistem și care urmărește punerea în evidență a unei abateri
a comportării sistemului față de cea corectă. Numai dacă se constată că starea
sistemului este eronată se va putea declanșa o acțiune corectivă, în caz contrar
fiind de așteptat defectarea sistemului. Ca urmare, existența unei tehnici
eficiente de detectare a erorii reprezintă un element critic al oricărui sistem
tolerant la defecte.
Detectarea erorii se efectuează printr -un proces de verificare (testare) a
ieșirilor sistemului în raport cu ieșirile așteptate în cazul fără defect. Acest
control, pentru a fi ideal ( ideal check ), trebuie să satisfacă următoarele
propr ietăți :
Să țină cont numai de specificațiile impuse sistemului, fără a fi
influențat de proiect și modul de implementare. Cu alte cuvinte,
testul trebuie să trateze sistemul ca și pe o cutie neagră, fără a
cunoaște detaliile acesteia.
Să fie complet, pentr u a putea acoperi toate stările accesibile ale
sistemului.
Să fie independent față de sistem, adică să nu existe nici un punct
comun de defectare a sistemului și controlului său care ar putea
compromite detectarea erorii.
Îndeplinirea întocmai a condițiilo r de mai sus în practică este foarte
dificilă, în principal datorită restricțiilor privind costul redundanței necesare
pentru verificare și timpul suplimentar alocat controlului pe durata execuției.
Se preferă utilizarea unor teste restrânse menite să dete cteze doar defectele
dintr -o mulțime considerată de defecte. Pentru aceste situații care se pot într –
adevăr anticipa, controlul va putea fi mult mai simplu și eficient decât un test
cu caracter general. Între cele două condiții extreme care se pot impune u nui
control, de a fi exhaustiv și minimal, în majoritatea sistemelor verificarea se
face pentru acceptabilitate, cu scopul de a detecta majoritatea situațiilor
eronate, dar fără a putea garanta absența unor erori nedetectate.
Multe dintre tehnicile de dete ctare a erorilor în sistemele de calcul au
fost deja amintite în capitolul precedent. În principiu se pot distinge
următoarele tipuri principale de verificări:
Controlul prin replicare (replication check ) presupune o multiplicare a
sistemului/subsistemului , urmată de o comparare pentru a decide asupra
funcției corecte. Cea mai simplă formă este duplicarea, dar pentru a obține
avantaje în fazele următoare ale toleranței se pot utiliza și mai multe copii
redundante și o decizie majoritară (votare). Dacă se ut ilizează copii identice,
atunci nu pot fi detectate defectele de proiectare. Pentru a le putea detecta,
replicarea trebuie să se bazeze pe versiuni alternative de implementare. În
cazul în care replicarea se limitează la utilizarea repetată în timp a acele iași
resurse, atunci metoda este eficace numai împotriva defectelor tranzitorii. În
general se poate afirma că metoda controlului prin replicare reprezintă una din
cele mai complete și puternice măsuri de detectare a erorilor, dar totodată este
printre cel e mai costisitoare sub aspectul redundanței pe care o necesită. Dacă
se aplică la nivelul sistemului, atunci nu mai sunt necesare alte mecanisme de
detectare la nivelul inferior al componentelor.
Controlul prin codare (coding check ) se bazează pe transform area
datelor utile în cuvinte de cod, folosind o regulă de codificare. În cazul în care
informația se alterează, această regulă nu mai este satisfăcută și eroarea poate
fi detectată. Alegerea unui anumit cod depinde de operația care se dorește a fi
control ată (memorare, transfer, operații aritmetice etc.) și tipul erorilor
presupuse să apară (singulare, multiple, pachete de eroare etc.). Prin
adăugarea unei sume de control (semnături) la un bloc de instrucțiuni se poate
efectua monitorizarea evoluției activ ității CPU. Recalcularea și compararea
semnăturii cu cea stocată intră în sarcina unui hardware suplimentar numit
procesor watchdog . Verificarea bazată pe codificarea datelor reprezintă o
măsură simplă și puțin costisitoare de detectare a erorilor, dar lim itată la o
mulțime admisibilă de erori în funcție de codul considerat.
Controlul de rezonabilitate (reasonableness check ) constă în a verifica
dacă starea unui obiect este conformă sau nu cu cea așteptată. În această
categorie intră de exemplu testele de încadrare a rezultatului în limite
acceptabile sau aserțiunile referitoare la variabilele programului, care se
evaluează în timpul execuției.
Controlul structural (structural check ) verifică integritatea structurilor
complexe de date, folosind pentru acea sta informații redundante, cum ar fi:
contor al numărului de elemente dintr -o structură, indicatori (pointer -i)
redundanți, informații de stare sau de tip etc.
Controlul prin inversare (reversal check ) presupune, dacă este posibilă,
recalcularea datelor de intrare pe baza rezultatului și compararea cu cele
originale. Metoda se poate aplica la unele operații aritmetice, care admit o
funcție inversă, respectiv în cazurile în care verificarea corectitudinii
rezultatului se poate face prin substituție (de exemp lu la un sistem de ecuații).
De asemena, recitirea datelor înscrise într -o memorie externă și compararea lor
cu cele inițiale reprezintă tot o formă de control prin inversare.
Controlul temporal (timing check ) urmărește punerea în evidență a
depășirii une i limite de timp prevăzute pentru o anumită operație. Dacă
această limită nu este respectată, se produce o excepție de tip timeout , care
indică defectarea componentei care trebuia să furnizeze serviciul solicitat.
Controlul temporal poate fi implementat cu ajutorul unui temporizator
watchdog , care este inițializat periodic pe cale software în cazul funcționării
corecte. Lipsa inițializării va fi considerată ca și aparația unei defecțiuni în
sistem. O altă formă de i mplementare, în sistemele multiprocesor, constă în
schimbul peiodic de mesaje de control între procesoare.
Controlul de interfață (interface check ) se ocupă de verificarea
legitimității unei cereri adresate unei componente, respectiv a validității și
compa tibilității datelor asociate cererii. Cazuri tipice care duc la excepții de
interfață sunt coduri de instrucțiuni ilegale, depășire aritmetică, violarea
mecanismului de protecție, accesul într -o zonă de memorie inexistentă sau în
afara limitelor declarate pentru o variabilă etc.
Controlul de diagnoză (diagnosis check ) implică stimularea unei
componente cu o mulțime de date de intrare și compararea ieșirilor cu valorile
predefinite. Acest control se implementează sub forma programelor de test
care se execută periodic, având astfel dezavantajul de a fi consumatoare de
timp și resurse. Dacă un defect a apărut între două rulări consecutive ale
testului, atunci există pericolul de răspândire a erorii în sistem, ceea ce necesită
măsuri de îngrădire corespun zătoare. În general testele de diagnoză nu
reprezintă metoda principală de detectare a erorilor într -un sistem, ele fiind
utilizate mai degrabă în fazele următoare ale procesului de toleranță pentru
localizarea defectului al cărui efect a fost detectat.
Cu ocazia proiectării unui sistem tolerant la defecte, se poate pune
întrebarea asupra locului unde să fie prevăzute măsurile de control pentru
detectarea erorilor. Cele două opțiuni extreme posibile constau în realizarea
controlului la nivelul sistemului , respectiv la nivelul componentelor .
Controlul la nivelul întregului sistem reprezintă o verificare de ultim
moment ( last-moment check ), fiind efectuată asupra rezultatelor încă înainte
ca acestea să fie furnizate utilizatorului. Acest mod de abordare as igură o
verificare completă a activității sistemului, dar în caz de eroare efortul necesar
pentru restabilire este mare. În schimb, detectarea timpurie a erorilor ( early
check ) oferă șanse reduse acestora de a se răspândi în sistem și astfel acțiunile
nece sare pentru îngrădirea pagubei, restabilirea din eroare și tratarea
defectului vor fi mai simple. Un asemenea control nu poate însă asigura
independența față de sistem, deoarece trebuie să țină cont de structura
acestuia.
Cele două modalități de amplasare a controlului nu se exclud însă
reciproc, prevederea lor fiind la latitudinea proiectantului de sistem în funcție
de aplicația în cauză.
4.2. Evaluarea și îngrădirea pagubei
4.2.1. Principiile evaluării și îngrădirii pagubei
Detectarea unei erori semnalează faptul că undeva în sistem a apărut un
defect, dar nu poate oferi garanția de a se fi identificat toate consecințele
nedorite ale defectului. Datorită întârzierii dintre momentul defectării unei
componente și cel al detectă rii erorii, în urma interacțiunilor dintre
componente eroarea se poate propaga și răspândi în cadrul sistemului. Scopul
fazei de evaluare și îngrădire a pagubei ( damage assessment and confinement )
este de a determina acele obiecte care au fost alterate de eroare și de a stabili
exact limitele până la care s -au extins daunele provocate. (Trebuie menționat
faptul că în această fază nu se urmărește localizarea defectului, ci delimitarea
părții corupte din starea sistemului, așa cum este ea observabilă pe baza
informațiilor pe care le conține.) Numai după ce pagubele au fost evaluate se
poate pune problema restabilirii sistemului într -o stare lipsită de eroare.
Răspândirea erorilor în sistem este rezultatul comunicațiilor dintre
componentele sistemului. Rezultă deci, că pentru a putea evalua extinderea
pagubei produse, trebuie examinat fluxul de informații care a avut loc între
componente. Scopul este de a determina limite în starea sistemului peste care
nu putea să apară nici un schimb de informații. Pentru rezo lvarea acestei
probleme există în principiu două metode: statică și dinamică. Metoda
dinamică urmărește identificarea limitelor prin examinarea înregistrărilor
privind schimburile de date, pe când cea statică se bazează pe incorporarea în
sistem încă de la proiectare a unor bariere ( fire walls ) care împiedică circulația
informației în afara ariei delimitate.
Evaluarea pagubei prin metoda statică presupune prevederea unor
măsuri de îngrădire a fluxului de date prin proiectarea unei structuri adecvate
aceste i cerințe. Un concept eficient pentru structurarea activității sistemului și
examinarea limitelor de extindere a erorii este cel al acțiunilor atomice (atomic
actions ). În principiu o acțiune atomică se caracterizează prin faptul că pe
durata ei nici o com ponentă implicată în acțiune nu interacționează cu restul
sistemului. Astfel, dacă în timpul unei acțiuni atomice s -a detectat o eroare,
atunci există o mare probabilitate ca eroarea să nu se fi răspândit la alte
obiecte decât cele asupra cărora se execută operațiile acțiunii atomice (în afara
cazului când eroarea s -a produs înainte de intrarea prelucrării în zona acțiunii
atomice).
Pentru a putea fi efective în vederea simplificării strategiei de evaluare a
pagubei, activitățile sistemului trebuie construi te din acțiuni atomice în timpul
elaborării acestuia. În timpul execuției, mecanismul bazat pe acțiunile atomice
va permite o îngrădire a efectelor negative ale defectelor, prin identificarea
părții suspecte din starea sistemului și asupra căruia trebuie c oncentrate
măsurile de restabilire.
Utilizarea conceptului de acțiuni atomice este deosebit de important în
sistemele care presupun activități paralele și la care, tocmai datorită
interacțiunilor dintre procesele paralele, evaluarea pagubei este mai difici lă.
Implementarea acțiunilor atomice într -un sistem presupune impunerea
unor restricții în interacțiunile dintre componente, forțând astfel într -un anumit
fel fluxul de informații. Pe partea de hardware asemenea măsuri există în mod
implicit datorită separării fizice a componentelor care dictează schimburile
posibile de date. În software impunerea atomicității se realizează prin
mecanismele de protecție , prin care se interzic accesele nedorite la obiectele
din sistem. Există o multitudine de tehnici de protecți e, cum ar fi acordarea de
drepturi de acces proceselor (de citire, scriere, execuție) sau blocarea
obiectelor ( locking ) împotriva acceselor neautorizate. De asemenea, pentru
evitarea paralelismelor nedorite dintre procese se pot utiliza semafoare sau
monit oare.
Tehnica dinamică de evaluare a pagubei încearcă să îndeplinească
evaluarea prin explorarea informațiilor disponibile. Această examinare se
bazează pe verificarea corectitudinii datelor (prin teste similare cu cele de la
detectarea erorii) și foloseșt e pentru delimitarea porțiunii eronate înregistrarea
tuturor comunicațiilor care au avut loc. Metoda poate fi privită ca și o căutare
pentru identificarea de acțiuni atomice dinamice, fără ca sistemul să fie
conceput structural din asmenea elemente, ca la metoda statică. Strategia
dinamică nu este prea favorabilă de a fi implementată, datorită complexității și
situațiilor neașteptate care pot să apară.
4.2.2. Acțiunea atomică
Acțiunea atomică ( atomic action ) reprezintă o activitate delimitată în timp în
care componenta sau componentele implicate nu interacționează cu restul
sistemului. Pentru celelalte componente din sistem, acțiunea atomică apare ca
și o operație primitivă, la care numai starea inițială și finală este observabilă.
Este de menționat faptul că noțiunea de acțiune atomică se referă la o
structură dinamică a sistemului care se stabilește în timpul evoluției sale și nu
la structura fizică (statică) a acestuia. Acțiunea atomică asigură trecerea
sistemului dintr -o stare consistentă într -o altă st are consistentă, conform
secvenței:
… {stare consistentă} acțiune atomică {stare consistentă} acțiune atomică {stare consistentă} …
Cea mai simplă acțiune atomică o constituie tranziția unei componente
dintr -o stare în alta, care poate fi considerată că se produce instantaneu și este
indivizibilă. Activitatea mai multor componente care lucrează în paralel poate fi
partiționată pe acțiuni atomice după exemplul din figura 4.1. Inițial
componentele 2 și 3 interacționează în cadrul unei acțiuni atomice, în t imp ce
componenta 1 se află într -o acțiune atomică proprie. Acțiunile atomice pot lua
și forma de acțiuni atomice încuibate ( nested atomic actions ), dacă sunt incluse
una în cealaltă. Astfel, în exemplul de pe figură, componentele 1 și 2 intră la un
moment dat în acțiuni atomice proprii, care fac parte dintr -o acțiune atomică
comună de durată mai mare. În acest caz o acțiune atomică inclusă apare ca și
un pas al acțiunii atomice care o cuprinde.
Proprietățile unei acțiuni atomice sunt următoarele:
Indivizibilitatea (indivisibility ): pentru un observator extern acțiunea
atomică nu poate fi descompusă în alte acțiuni, toți pașii pe care -i
conține apar ca și cum s -ar produce instantaneu.
Serializabilitatea (serializability ): două acțiuni atomice nu au voie să
se suprapună, ele trebuie să urmeze o ordine strict secvențială.
Recuperabilitatea (recoverability ): ori se execută complet toată
acțiunea, ori nu se execută deloc (ca și cum nici un pas din acțiune nu
s-ar fi executat).
Proprietățile de indivizibilitate și serializabilitate asigură atomicitatea în cazul
unei execuții corecte. Recuperabilitatea conferă acțiunii atomice un
comportament de tip „totul sau nimic”, ceea ce împ iedică producerea oricăror
efecte externe ale unei execuții parțiale datorate unui defect. Dacă în timpul
unui pas al acțiunii atomice se detectează o eroare, acțiunea atomică nu se mai
poate termina (intră în stare de abort ). Prin utilizara acțiunilor ato mice este
facilitată îngrădirea pagubei, iar proprietatea de recuperabilitate asigură
restabilirea unei stări consistente a sistemului (vezi 4.3.1). Se presupune că
efectele unei acțiuni atomice săvârșite cu succes sunt făcute durabile, deci
Figura 4.1. Delimitarea acțiunilor atomice în evoluția sistemului
starea externă pe care a avut -o sistemul la intrarea în acțiunea atomică
abandonată nu a fost pierdută.
Asigurarea atomicității în sistemele cu un singur proces este simplă,
datele fiind prelucrate în ordinea secvențială a instrucțiunilor. În schimb în
sistemele distri buite, unde datele pot fi accesate simultan de mai multe
procese, problema atomicității devine mai complicată. Accesele concurente la
date comune pot duce la stări inconsistente dacă aceste activități paralele nu
sunt coordonate corespunzător.
Menținerea consistenței datelor prezintă un interes deosebit în aplicațiile
cu baze de date, unde datele sunt accesate de diferiți utilizatori. Mai mult, dacă
în sistem există copii multiple (replici) ale datelor, asigurarea condițiilor de
acțiune atomică întâmpină g reutăți suplimentare.
Acțiunile efectuate asupra unei baze de date, prin care se execută
operații asupra diferitelor obiecte într -o anumită ordine se numesc tranzacții
(transactions ). Tranzacția reprezintă o succesiune de operații de citire și scriere
într-o bază de date, prin care se satisface o operație logică a utilizatorului. De
exemplu, transferul unei sume de 100 $ de pe contul x pe contul y, presupune
efectuarea următoarei tranzacții:
începutul tranzacției :
1. citește contul x
2. citește contul y
3. adună 100$ la contul y
4. scade 100$ din contul x
5. scrie noua valoare a contului x
6. scrie noua valoare a contului y
sfârșitul tranzacției
O tranzacție trebuie privită ca o acțiune atomică de nivel înalt, care
satisface cerințele de indivizibilitate, serializabilitate și recuperabilitate. La
efectuarea unei tranzacții, ori se execută toate operațiile de citire și scriere pe
care le conține în ordinea corespunzătoare, ori nu se execută nici una. La
sfârșitul tranzacției se plasează adesea o comandă de comitere ( commit ), care
asigură permanentizarea efectelor tranzacției în baza de date.
Accesele concurente la date pot viola atomicitatea tranza cțiilor. De
exemplu, se consideră două tranzacții T1 și T2 care transferă 100$, respectiv
500$ de pe contul x pe contul y. Dacă cele două tranzacții se execută succesiv,
ordinea operațiilor primitive de citire (notate cu R de la read ) și scriere (notate
cu W de la write ) asupra bazei de date este:
R1(x)R1(y)W1(x)W1(y)R2(x)R2(y)W2(x)W2(y)
Considerând că inițial contul x a avut 2000$ , iar contul y 3000$ , rezultatul final
al tranzacției trebuie să fie de 1400$ pe x și 3600$ pe y. (Este de remarcat
faptul că rezultatul ar fi același și dacă ordinea tranzacțiilor este T2T1!) În cazul
în care procesele sunt concurente, este posibilă o întrețesere în diferite feluri
între cele două tranzacții, de exemplu sub forma:
R1(x)R1(y)R2(x)R2(y)W2(x)W1(x)W1(y)W2(y)
Ca urmare a acestei secvențe de operații, valorile finale pe cele două conturi
vor fi de 1900$ pe contul x și 3500$ pe contul y. Rezultatul obținut este evident
diferit de cel așteptat, ceea ce determină o stare inconsistentă a bazei de date.
Rezultă deci necesitatea de a prevedea niște măsuri de restricție a concurenței
pentru păstrarea atomicității. Înainte de prezentarea acestora este util a studia
în ce condiții secvența operațiilor primitive aparținând la procese diferite es te
serializabilă, adică garantează obținerea unei stări finale consistente.
4.2.3. Serializabilitatea
Problema serializabilității se pune în sistemele unde este posibilă execuția
paralelă a mai multor procese care operează asupra unor date comune. Astfel,
în cazul unei mulțimi de tranzacții concurente ( T1, T2, …,Tm), fiecare tranzacție
fiind formată din operații primitive, este posibilă întrepătrunderea acestor
operații într -o anumită manieră. Secvența de operații care se obține formează
un șir de primitive, î n care ordinea operațiilor care aparțin fiecărei tranzacții în
parte este respectată. Șirul este serial dacă toate operațiile unei tranzacții apar
unul după altul în secvență. Este evident că un șir serial nu va duce la
inconsistență, deoarece o nouă tranz acție va începe numai după ce toți pașii
tranzacției precedente au fost efectuați.
În cazul în care însă șirul nu este serial, și anume există o întrețesere între
operațiile aparținând tranzacțiilor diferite, apare pericolul producerii unei stări
finale i nconsistente. Întrucât tranzacțiile reprezintă acțiuni atomice, starea
internă a unei tranzacții nu trebuie să fie vizibilă unei alte tranzacții. Starea
finală va fi una consistentă numai dacă este respectat criteriul de
serializabilitate (serializability criteria ): o secvență de acțiuni concurente este
serializabilă dacă duce la același rezultat ca și cum acțiunile ar fi fost executate
într-o oarecare ordine serială.
Se pune în continuare întrebarea: care este condiția ca un șir de primitive
planificate ( schedule ) care aparțin unor tranzacții concurente să fie serializabil?
Pentru ca acest lucru să se realizeze este necesar ca șirul dat să fie echivalent
cu un șir serial corespunzător tranzacțiilor respective. Pentru a studia
echivalența șirurilor, trebuie clarificată mai întâi noțiunea de dependență a
tranzacțiilor.
Fie un șir S de primitive în care sunt evidențiate pe pozițiile i și j (i<j) două
operații ( A și B) care aparțin la tranzacțiile T1 și T2:
S = ……….. [ A1(x)] i ……… [ B2(x)] j ………….
Operația B va depinde de operația anterioară A dacă ambele operații sunt
efectuate asupra aceluiași obiect (în cazul de față x). Deoarece ordinea citirilor
poate fi oarecare, fără să afecteze consistența datelor, cazul în care atât A, cât
și B sunt operații de citir e nu influențează dependența operațiilor. Dependența
operațiilor care aparțin la două tranzacții diferite poate conduce la stabilirea
unei relații de ordine (<) între cele două tranzacții. Astfel T1<T2 dacă oricare ar fi
obiectul x, următoarele afirmații sunt satisfăcute:
1. Nu există nici o poziție k astfel încât i<k<j în care să se efectueze o altă
operație de scriere asupra lui x.
2. Cel puțin una dintre operațiile A și B este de scriere.
Ca urmare, două șiruri de primitive vor fi echivalente dacă ele respectă aceeași
relație de ordine a tranzacțiilor. Întrucât un șir serializabil trebuie să fie
echivalent cu unul serial, se poate formula condiția de serializabilitate : dacă
oricare ar fi i și j asfel încât Ti<Tj pentru un obiect x, atunci nu există nici un
obiect y diferit de x care să implice Tj<Ti. De exemplu, aplicând condiția de
serializabilitate pentru șirul de operații
R1(x)R2(x)R1(y)W2(x)W1(y)R2(y)R3(x)W2(y)W3(y)
se obține aceeași ordine de serializare T1<T2<T3 atât pentru x, cât și pentru y.
Relațiile de serializabilitate se pot modela cu ajutorul unui graf orientat
în care nodurile reprezintă tranzacțiile, iar arcele reprezintă dependențele între
procese pe baza acceselor de forma RW, WR și WW asupra unui obiect. Un arc
orientat va exista de la Ti la Tj pentru a descrie ordinea Ti<Tj, dacă:
1. Ti citește un obiect care va fi mai târziu scris de Tj
2. Ti scrie un obiect care va fi mai târziu citit de Tj
3. Ti scrie un obiect care va fi mai târziu scris de Tj
Pentru exemplul considerat, graful de seriali zabilitate (serializability graph ) se
prezintă în felul din figura 4.2. Pe fiecare arc orientat s -a marcat identificatorul
obiectului accesat. Condiția de serializabilitate a unui șir de primitive se poate
studia și pe graful construit după procedeul arăta t. Astfel, șirul este serializabil,
dacă graful de serializabilitate asociat este aciclic .
Figura 4.2. Graful de serializabilitate
Dacă serializabilitatea este asigurată, atunci starea bazei de date după
execuția unei mulțimi de tranzacții va fi consistentă. Pentru a păstra
consistența, într -o tranzacție se identifică trei pași succesivi:
Declararea intențiilor. În cadrul acestui pas utilizatorii trimit intențiile
lor de citire ( R) sau modificare ( W) a datelor.
Certificarea. În acest pas se verifică condiția de serializabilitate.
Validarea. Dacă tranzacția a fost certificată, atunci intențiile de
scriere devin efective, în caz contrar acest pas nu se execută.
Dacă se adoptă o strategie pesimistă, atunci certificarea se execută când
intențiile au fost declarate. În schimb la o abordare optimistă conflictele se
rezolvă când au fost detectate, certificarea fiind făcută chiar înainte de
validare.
Într-un sistem distribuit, unde există mai multe copii ale acelorași date în
noduri diferite, se impun măsuri mai severe pentru asigurarea consistenței.
Execuția concurentă asupra datelor replicate trebuie să fie echivalentă cu
execuția serială a acțiunilor asupra unei singure copii a datelor. Această
proprietate poartă numele de serializabilitatea unei copii (one-copy
serilizability ).
4.2.4. Excluderea reciprocă
În cazul în care mai multe procese concurente pot avea acces la resurse sau
date partajate este necesară impunerea unor restricții pentru ca criteriul de
serializabilitate să nu fie violat. Problema se poate rezolva dacă pe baza unui
protocol nu se permite accesul decât pentru un singur proces la un moment
dat. Se realizează astfel o excludere reciprocă (mutual exclusion ) între procese.
Acea parte a unui program în care acesta utilizează resurse sau variabile
partajate se numește secțiune critică (critical section ). Prin mecanismul de
excludere reciprocă trebuie asigurat de fapt ca să nu existe nici o suprapunere
în timp între secțiunile critice a proceselor paralele.
Exclusivitatea în utilizarea unui obiect partajat poate fi privită ca și o
excludere reciprocă a secțiunilor critice ale proceselor, ceea ce reprezintă o
problemă de sincronizare. Când un proces dorește să intre într -o secțiune
critică, el va trebui să fie înt ârziat (blocat) dacă un alt proces se află tocmai într –
o regiune similară (figura 4.3, pe care secțiunea critică s -a notat cu SC). Numai
după ce acesta din urmă părăsește regiunea critică se va permite unui proces în
așteptare să își înceapă execuția în se cțiunea critică. Alte procese care se află în
regiuni necritice pot continua, dar nu au voie să intervină în execuția unei
secțiuni critice. Odată ce o secțiune critică a programului a fost începută, ea
trebuie să se termine fără nici o întrerupere. Cu alt e cuvinte prelucrarea într -o
secțiune critică este indivizibilă, fiind executată sub forma unei acțiuni atomice.
Accesul la obiectele partajate prin intermediul unei secțiuni critice poate
fi protejat cu elemente software de genul semafoarelor și monitoare lor.
Semaforul (semaphore ) reprezintă o variabilă globală care poate fi
accesată numai de două operații atomice P și V ). În cazul în care semaforul
este binar (poate lua valori de 0 și 1) el lucrează ca și un blocaj, indicând dacă
obiectul partajat este ocupat sau nu. Astfel, s=1 înseamnă că nici un proces nu
se află în secțiunea sa critică asociată acestui semafor, iar da că s=0 atunci există
un proces aflat în secțiunea critică corespunzătoare semaforului. Operațiile P și
V se folosesc pentru blocarea, respectiv deblocarea accesului la obiectul
) prescurtările provin de la cuvintele olandeze passeren = a pasa și vrijgeven = a elibera,
conceptul fiind introdus de olandezul Dijkstra
Figura 4.3. Accesul la o resursă partajată prin
excludere reciprocă
partajat, fiind definite în felul următor:
var s:semaphore
P(s): begin
whil e s<1 do instruc țiune _vidă ;
s:=s1
end
V(s): begin
s:=s+1
end
Uneori P(s) și V(s) se mai notează cu wait (s), respectiv signal (s), care exprimă
mai bine sensul acestor operații. Inițial semaforului i se atribuie valoarea 1,
indicând faptul că intrarea în secțiunea critică este liberă.
Pentru a fi reciproc exclusive, secțiunile critice ale proceselor sunt
delimitate de câte o operație P și V asupra aceluiași semafor:
Procesul 1 Procesul 2 Procesul 3
<secțiune necritică> <secțiune necritică> <secțiune necritică>
P(s) P(s) P(s)
<secțiune critică> <secțiune critică> <secțiune critică>
V(s) V(s) V(s)
<secțiune necritică> <secțiune necritică> <secțiune necritică>
Un proces intră în secțiunea critică numai da că s=1. Imediat după aceea
execută o operație P, reducând valoarea semaforului la 0 și inhibând astfel
intrarea oricărui alt proces în secțiunea critică. (Un alt proces care și -a atins
operația P va fi înregistrat într -o coadă de așteptare). Atunci când ex ecuția în
secțiunea critică s -a terminat, procesul efectuează o operație V prin care
poziționează semaforul pe 1, ceea ce va permite următorului proces care
așteaptă să intre în secțiunea critică.
Pentru o funcționare corectă a semaforului se impune ca ope rațiile P și V
să fie atomice. Operațiile P și V ale proceselor lucrează cu aceeași variabilă
comună s, deci și aceste operații aparțin secțiunilor critice. Indivizibilitatea
operațiilor P și V se asigură prin implementarea lor cu câte o singură
instrucțiune. O astfel de instrucțiune este „test -and-set”, care într -un singur
ciclu de citire/modificare/scriere poate implementa operația P.
Definiția operațiilor P și V este valabilă și pentru cazul semaforului
general, numit și semafor de tip contor ( counting semaphore ), care poate lua
valori întregi diferite de zero și unu. Semaforul se inițializează cu numărul de
resurse partajate disponibile, fiind decrementat cu unu la fiecare accesare de
resurs ă din partea unui proces care execută operația P. Un proces care încearcă
intrarea în secțiunea critică atunci când semaforul a devenit zero este trecut în
coada de așteptare, continuarea sa fiind posibilă numai dacă un alt proces a
executat o operație V de incrementare a contorului cu unu.
O altă cale de implementare a excluderii reciproce este prin utilizarea
unui monitor (monitor ). Monitorul reprezintă o construcție software care
colectează secțiunile critice sub formă de proceduri într -o singură structu ră. La
un moment dat un singur proces poate lucra cu monitorul, care se constituie
astfel în singura modalitate de accesare a unui obiect partajat.
Prin utilizarea monitorului, datele partajate nu mai sunt globale, ci ele
sunt locale în corpul monitorului. Mai mult, procesele nu mai conțin secțiuni
critice, acestea fiind centralizate și protejate în cadrul funcțiilor monitorului.
Toate regiunile critice ale proceselor se scriu sub formă de proceduri și se
încapsulează împreună cu datele într -o singură unita te de program, prin care se
garantează ca apelurile la aceste proceduri să fie reciproc exclusive. Un proces
poate accesa datele partajate cu ajutorul monitorului prin invocarea uneia din
procedurile sale.
În unele situații se poate însă întâmpla ca proces ul care execută o
procedură a monitorului să nu -și poată continua activitatea datorit ă
neîndeplinirii unei anumite condiții. De aceea, pentru ca metoda să nu fie prea
restrictivă și pentru a evita blocarea, există de regulă posibilitatea suspendării
tempor are a unui proces, care va fi introdus într -o coadă. Gestionarea cozii se
face cu o variabilă de condiție ( condition variable ), care nu ia nici o valoare și
reprezintă practic coada de procese suspendate (care inițial este goală).
Introducerea unui proces în coadă se face cu o operație wait , iar reluarea unui
proces suspendat cu operație signal . Ținând cont și de operațiile de inițializare
a datelor asociate, structura generală a unui monitor este următoarea:
monitor nume _monitor
begin
var c:condition
… /* declararea și inițializarea celorlalte variabile */
procedure procedura_ 1 (… parametri …)
begin
…
wait (c)
…
end
procedure procedura_ 2 (… parametri …)
begin
…
signal (c)
…
end
…
end
Invocarea unei proceduri necesit ă pe lângă specificarea numelui
procedurii și identificarea monitorului din care face parte, sub forma
nume_monitor.procedura_ i (…parametri …). Semafoarele pot fi de asemenea
implementate cu ajutorul monitoarelor.
4.2.5. Blocarea
Concepți a de excludere reciprocă a proceselor concurente este eficientă în
cazul în care datele partajate sunt puține și accesele la acestea sunt rare și de
scurtă durată. În cazul bazelor de date, unde datele partajate pot fi extinse și
acțiunile care trebuie exe cutate atomic asupra lor sunt frecvente, este de dorit
utilizarea unor protocoale mai puțin restrictive. În acest sens este de observat
faptul că vor apărea conflicte la accese multiple numai dacă una din operații
este de scriere, așa cum rezultă din tabel ul de conflicte:
Pi
Pj Citire Scriere
Citire
Scriere
Dacă un proces efectuează citire asupra unui obiect, se poate permite și unui
alt obiect să efectueze o citire fără a viola consistența datelor. Acest mod de
lucru se poate implementa prin mecanismul de blocare (locking ). Atunci când
un proces necesită un acces la un obiect, prima dată îl blochează la dispoziția sa
(îi „pune lacăt”). Evidența obiectelor blocate este ținută de un lock manager ,
care respinge orice încercare de blocare a unui o biect care deja a fost blocat de
un alt proces. Pentru a permite accesul independent în caz de citiri concurente,
trebuie făcută distincția între blocajele pentru citire ( read lock ) și cele pentru
scriere ( write lock ). Astfel, dacă un obiect a fost blocat pentru citire, atunci și
alte blocaje de citire sunt permise. În schimb dacă un proces a blocat un obiect
pentru scriere, atunci autorizația de acces aparține exclusiv procesului
respectiv.
Se poate ușor deduce că efectuarea blocărilor numai în momentul în care
sunt necesare și eliberarea lor atunci când nu mai este nevoie de ele poate
duce la inconsistență în cazul tranzacțiilor concurente. De aceea, pentru a
respecta condiția de serializabilitates s -a introdus blocarea în două faze (two-
phase locking ). Ac est mod de lucru presupune respectarea următoarelor reguli :
1. O tranzacție poate accesa pentru citire, respectiv scriere un obiect
dacă și numai dacă posedă un blocaj de citire, respectiv scriere asupra
acelui obiect.
2. O tranzacție nu poate solicita nici un blocaj după eliberarea unui
blocaj.
Prima cerință este evidentă, în schimb a doua duce la divizarea tranzacției în
două faze (figura 4.4):
Faza de creștere (growing phase ), care include achiziționarea tuturor
blocajelor necesare întregii tranzacții.
Faza de contractare (shrinking phase ), în care are loc eliberarea pe
rând a blocajelor.
Schema tranzacției corespunzătoare unei blocări în două faze este
ilustrat ă în exemplul următor :
tranzacția _i:
begin
…
request (x)
request (y)
… /* utilizează x și y */
request (z)
… /* utilizează x și z */
release (x)
… /* utilizează y și z */
release (y, z)
end
Toate cererile de blocare ( request ) a obiectelor trebuie făcute în timpul fazei
de creștere. Momentul eliberării ( release ) primului obiect blocat specifică
începutul fazei de contractare a tranzacției. Se poate demonstra că prin
utilizarea blocării în două faze de către toate tranzacțiile concurente, ori ce șir
format prin întrepătrunderea lor este serializabil.
Mecanismul de blocare, inclusiv cel în două faze, poate conduce la
interblocaj (deadlock ). Exemplul cel mai elocvent în acest sens este cel în care
două tranzacții T1 și T2 încearcă să blocheze ace leași obiecte x și y, dar în ordine
inversă. După ce x a fost blocat de T1 și y de T2, ambele tranzacții vor aștepta
una după alta. Pentru prevenirea interblocajului este necesară prevederea unei
Figura 4.4. Principiul blocării în două faze
reguli de achiziționare a blocajelor într -o anumită ordine î n timpul fazei de
creștere.
4.2.6. Interblocajul
Fenomenul de interblocaj apare într -un sistem de calcul atunci când acesta nu
mai este capabil să progreseze pentru îndeplinirea sarcinilor din cauza unei
așteptări infinite a proceselor unul după altul. Acest lucru se întâmplă dacă unul
sau mai multe proc ese așteaptă după resurse (fișiere de date, dispozitive de
I/O, buffer -e de comunicație etc.) deținute de un alt proces, care la rândul său
este blocat până la eliberarea resursei aflate la dispoziția primului proces. Cazul
cel mai simplu este interblocaju l cauzat de două procese P1 și P2 care dețin
resursele r1, respectiv r2 și se află în așteptare, fără să -și elibereze fiecare
resursa sa până când nu obține controlul asupra celeilalte resurse (figura 4.5).
Sistemul nu va putea evolua decât dacă un proces va fi abandonat pentru a
sparge interblocajul. Un astfel de interblocaj între două procese se mai
numește îmbrățișare mortală ( deadly embrace ).
Figura 4.5. Interblocajul între două procese
Interblocajul se poate studia pe un graf al aș teptărilor pentru resurse
(wait -for-resource graph ), care se construiește din următoarele elemente:
O mulțime de noduri { Pi}, reprezentând procesele
O mulțime de noduri { rj}, care corespund resurselor
O mulțime de arce orientate, astfel încât Pi→rj dacă și numai dacă Pi
așteaptă pentru resursa rj
O mulțime de arce orientate, astfel încât ri→Pj dacă și numai dacă ri
este deținut (prin lock) de către Pj
Un astfel de graf este și cel din figura precedentă.
Se poate produce și situația unei așteptări circulare între n procese, așa
cum se arată în figura 4.6. În acest caz procesul P1 necesită resursa r2 deținută
de P2, procesul P2 cere resursa r3 deținută de P3 ș.a.m.d. În general situația de
interblocaj se pune în evidență pe graful așteptărilor pentru resurse prin
identificarea unui ciclu între o submulțime de noduri.
Pentru simplitate se poate utiliza și un graf modificat, în care sunt
figurate numai procesel e, resursele fiind omise de pe reprezentare (figura 4.7).
În acest graf un arc orientat PiPj există dacă și numai dacă Pi așteaptă după o
resursă deținută de Pj. Este de remarcat faptul că graful inițial nu furnizează nici
o informație suplimentară referi toare la situația de interblocaj în comparație cu
acest graf.
Alocarea resurselor la procesele din sistem se face cu respectarea
cerințelor de excludere reciprocă, pe baza operațiilor de tip blocare ( lock sau
request ) și deblocare ( unlock sau release ) inițiate de procese. Se presupune că
un proces care a căpătat o resursă nu o va elibera decât în mod v oluntar după
terminarea prelucrării, continuând chiar achiziționarea de alte resurse. Cu alte
cuvinte nu este permisă preemțiunea, adică nu poate exista nici un factor
extern datorat unui proces mai prioritar care să determine eliberarea unei
resurse înain te ca procesul care o deține să inițieze acest lucru. Cu acestea se
pot formula cele patru condiții care, dacă sunt îndeplinite, înseamnă apariția
unui interblocaj în sistem:
1. Procesele revendică controlul exclusiv asupra resurselor utilizate.
Figura 4.6. Interblocajul circular între n procese
Figura 4.7. Graful simplificat pentru evidențierea
interblocajului
2. Resursele nu pot fi retrase de la procesele care le dețin (nu este
permisă preemțiunea).
3. Procesele așteaptă pentru obținerea resurselor solicitate până când
nu vor căpăta blocarea ( lock) acestora.
4. Există un ciclu în graful de așteptare pentru resurse.
Evident metodele de evitare a interblocajelor se bazează pe găsirea unei astfel
de căi, încât cel puțin una din condițiile de mai sus să nu fie realizată.
Pentru stăpânirea interblocajelor există în principiu două tipuri de
abordări: pesimiste și optimiste. Soluțiile pesimiste încearcă să prevină apariția
unei situații de interblocaj, pe când soluțiile optimiste tratează interblocajul
după ce s -a produs. În continuare se trec în revistă câteva metode aparținând
acestor două feluri de abordări.
a) Prevenirea interblocajulu i (deadlock prevention ) presupune respingerea
proceselor care pot crea un ciclu în graful de așteptare, restricțiile
corespunzătoare fiind impuse însăși prin proiectarea adecvată a sistemului. Cea
mai simplă, dar totodată și cea mai restrictiva metodă este aceea de a nu
permite unui proces decât deținerea unei singure resurse la un moment dat. O
altă soluție, mai puțin restrictivă, constă în ordonarea tuturor resurselor și
impunerea regulii ca achiziționarea lor de către procese să se facă într -o ordine
strict crescătoare. Ca urmare, un proces care deține o resursă de ordin înalt nu
va cere niciodată dobândirea uneia cu număr de ordine redus, ceea ce face
imposibilă apariția ciclurilor.
Tehnica bazată pe analiza grafului de așteptare, aplicată preventiv,
presupune o declarare prealabilă ( pre-declare ) de către proces a tuturor
resurselor pe care le va solicita. În cazul proceselor formate din tranzacții
atomice, o astfel de pre -declarație este necesară înaintea fiecărei tranzacții.
Înainte de acceptarea pentru prelucrare a unei noi tranzacții, se analizează dacă
arcele adăugate la graf pe baza cerințelor formulate nu induc un ciclu în graf.
Dacă răspunsul este afirmativ, atunci tranzacția se respinge. Schematic, acest
mod de prevenție poate fi descris astfel:
tranzacția_i :
pre-declare (r1, r2, …, rk)
begin
… /* corpul tranzacției */
end
…
la intrarea în tranzacția_i :
begin
if există un eventual ciclu then
respinge tranzacția_i
else acceptă tranzacția_i
fi
end
În sistemele distribuite se folosesc în mod eficient algoritmi de prevenție
bazați pe ordonarea tranzacțiilor după marcajele de timp. Fiecărei tranzacții i se
asociază un marcaj de timp (timestamp ) în momentul lansării, având grijă ca să
nu existe două tra nzacții cu același marcaj. Acest lucru poate fi garantat prin
utilizarea algoritmului de sincronizare al lui Lamport.
O soluție de prevenire a interblocajelor, care folosește marcajele de
timp, este algoritmul wait and die . Ideea de bază este că pentru a preveni
producerea unui ciclu, tranzacția care solicită o resursă deținută de o tranzacție
mai „bătrână” va fi abandonată (va muri = dies). În schimb, dacă o tranzacție cu
un marcaj de timp mai mic dorește resursa ocupată d e o tranzacție mai
„tânără”, atunci va trebui să stea în așteptare ( wait ) până la eliberarea resursei.
Acest mod de abordare duce la situația ca toate săgețile din graf să indice în
direcția crescătoare a marcajelor tranzacțiilor, făcând ciclurile imposibi le.
Notând cu m(T) marcajul de timp al tranzacției T, algoritmul se poate descrie
formal astfel:
când T vrea să ocupe resursa rk :
begin
if stare (rk)=inactiv then
stare (rk):=ocupat ;
m(rk):=m(T)
else
if m(T)<m(rk) then
T așteaptă /* T e mai bătrână */
else T moare /* T e mai tânără */
fi fi
end
Dacă solicitarea din partea tranzacției se face către o resursă liberă (aflată în
stare inactivă), atunci aceasta îi va fi alocată. În momentul în care o resursă
devine ocupată, atunci ea primește marcajul de timp al tranzacției care a
efectuat blocajul. Dacă solicitarea ajunge la o resursă blocată de o altă
tranzacție mai bătrână, atunci tranzacția solicitantă este abandonată. Ea poate
fi reluată mai târziu cu același marcaj de timp și atu nci, îmbătrânind, va avea
șanse mai mari de rămânere în așteptare sau de dobândire a resursei. Este de
menționat faptul că într -un sistem bazat pe tranzacții atomice, abandonarea
unei tranzacții are consecințe mult mai puțin grave decât în cazul convențion al,
când acest lucru este echivalent cu „uciderea” ( kill) procesului. Când o
tranzacție este abandonată ( abort ), are loc restabilirea la starea de dinaintea
începerii tranzacției și din acest punct ea poate fi din nou reluată.
Figura 4.8 arată modul de aplicare a algoritmului wait and die la un caz
concret. Fiecărei tranzacții îi este asociat câte un marcaj de timp, numărul mai
mic indicând desigur o tranzacț ie mai bătrână. Tranzacția T4, încercând să
acceseze resursa deținută de T1, cu un marcaj mai scăzut, va fi abandonată. T1,
va trebui să aștepte însă după procesele mai tinere, astfel că ordinea de
execuție a proceselor aflate în așteptare este T3 (care va folosi resursa eliberată
de T4), urmat de T2 și T1.
Un alt algoritm, numit wound and wait , admite dreptul de preemțiune al
unei tranzacții asupra unei tranzacții mai tinere care deține resursa solicitată.
Ideea de bază este că va fi abandonată (j ignită = wounded ) acea tranzacție care
deține o resursă cerută de o tranzacție mai bătrână. În schimb o tranzacție mai
tânără va aștepta ( wait ) după resursa ocupată de o tranzacție cu marcajul de
timp mai mic. O descriere formală a algoritmului wound and w ait este
următoarea:
Figura 4.8 . Utilizarea algoritmului wait and die
la o situație de interblocaj
când T vrea să ocupe resursa r k :
begin
if stare (rk)=inactiv then
stare (rk):=ocupat ;
m(rk):=m(T)
else
if m(T)<m(rk) then
tranzacția curentă este abandonată(jignită)
/* T e mai bătrână */
else T așteaptă /* T e mai tânără */
fi fi
end
Deosebirea față de algoritmul precedent constă în faptul că în loc de a
abandona procesul care face cererea, va fi jignit deținătorul curent al resursei.
Acest lucru se întâmplă dacă solicitantul este o tranzacție mai băt rână, care,
exercitându -și dreptul de preemțiune, va reprima o tranzacție mai tânără.
Pe graful așteptărilor luat ca exemplu în figura 4.9 t ranzacția T3, având
marcajul de timp mai mic, va reprima tranzacția T4, care eliberează resursa
ocupată până acum. Probabil T4 va fi repornit imediat, cu același marcaj de
timp și, spre deosebire de algoritmul precedent, va aștepta după tranzacția T1,
mai bătrână. Tra nzacția T2 va rămâne și ea în așteptare după resursa deținută
de T3, care se execută prima.
b) Detectarea interblocajului (deadlock detection ) este o soluție optimistă care
permite producerea interblocajului, o identifică și încearcă restabilirea
Figura 4.9. Utilizarea algoritmului wound and wait
la o situație de interblocaj
sistemului. În acest scop interblocajul trebuie spart, ceea ce presupune
eliberarea a cel puțin unei resurse de la un proces, chiar dacă utilizarea sa nu a
fost încheiată. Procesul întrerupt poate fi mai târziu restabilit printr -un
mecanism de returnare ( rollback ) la starea de dinainte de interblocaj.
O metodă simplă de detectare a interblocajului este cea de timeout ,
utilizată frecvent în sistemele de timp real. Această abordare nu îngăduie unui
proces să aștepte la infinit pentru ca o resursă să devină disponibilă. După
scurgerea unui timp de așteptare impus, procesul va fi abandonat și resursele
eliberate, problema fiind rezolvată. Chiar dacă nu a fost vorba despre un
interblocaj, abandonarea unei tranzacții, așa cum s -a mai arătat, conduce doar
la o penalizare în p erformanță.
Folosind principiul analizei grafului de așteptare, strategia detectării
interblocajului impune apelarea periodică a unui algoritm care să testeze
existența unui eventual ciclu în graf . Acest lucru se face pe baza studierii
alocării curente a resurselor și a cererilor neservite din sistem. Dacă un ciclu
este detectat, atunci unul sau mai multe procese trebuie abandonate. Există
mulți algoritmi bazați pe această tehnică, dintre care se p rezintă în continuare
algoritmul Chandy -Misra -Haas , aplicat în sisteme distribuite.
În cazul acestui algoritm se presupune că fiecare proces conține doar
informații locale, fără să dispună de graful global de așteptare ca la alte
metode. Aceste informații locale se referă la propria stare a procesului
(inactivă, activă, blocată, terminată) și la setul său de dependență. Setul de
dependență ( dependency set ) al unui proces Pi reprezintă mulțimea acelor
procese Pj pentru care există un arc PiPj în graful de așteptare după resurse.
Cu alte cuvinte, acest set include pe toți deținătorii de resurse după care
așteaptă Pi pentru a -și continua execuția.
Figura 4.10. Utilizarea algoritmului Chandy -Misra -Haas
la o situație de interblocaj
Atunci când un proces s -a blocat în așteptarea după o resursă, va iniția o
sesiune de detectare prin apelarea algoritmului. Ca urmare se generează de
către nodul respectiv un mesaj de probă, care se trimite tuturor proceselor din
setul său de dependență. Mesajul constă dintr -o tripletă de numere, și anume:
identificatorul procesului care s -a blocat, al procesului care transmite mesajul și
numărul procesului destinație. De exemplu, pentru graful din figura 4.10,
considerând că P1 este procesul care a inițiat detectarea blocării, mesajul
transmis de el va fi (1,1,2). La recepționarea unui mesaj de către un proces aflat
în așteptare după resurse, mesajul este actualizat (lăsând neschimbat primul
câmp) și trimis mai departe. Dacă mesajul parcurge un ciclu și aju nge înapoi la
inițiator, atunci o situație de interblocaj s -a pus în evidență.
O soluție uzuală pentru deblocarea sistemului este ca procesul care a
emis mesajul original să se sinucidă. Totuși, dacă algoritmul se apelează
simultan de mai multe noduri, ace astă soluție poate duce la abandonarea mai
multor procese decât ar fi necesar. Mai trebuie remarcat faptul că în scopul
funcționării algoritmului, se presupune că și un proces blocat este capabil de a
răspunde la un mesaj de protocol pentru detectarea inte rblocajului.
În concluzie, existența condiției de interblocaj reprezintă o problemă
serioasă de care proiectantul trebuie să țină seama la elaborarea unui sistem cu
procese concurente. Pe de o parte, tehnicile de prevenție nu introduc cheltuieli
suplimen tare semnificative în timpul operării sistemului, dar au dezavantajul
subutilizării resurselor. Datorită prezumțiilor privind cazul cel mai defavorabil în
timpul funcționării, acestea pot rămâne blocate la dispoziția proceselor pentru
intervale lungi de ti mp. Pe de altă parte, metodele de detecție lasă libertatea
evoluției proceselor și alocarea resurselor este dinamică, ceea ce mărește
gradul de utilizare a acestora. În schimb verificarea periodică a alocărilor și
necesitatea unei eventuale restabiliri duc e la un consum de timp adițional pe
durata execuției.
4.3. Restabilirea din starea de eroare
4.3.1. Restabilirea unei stări consistente
Scopul fazei de restabilire din eroare ( error recovery ) este de a elimina eroarea
din starea sistemului și a aduce sistemul într -o stare consistentă, lipsită de
eroare. (Este de menționat că eliminarea defectului care a cauzat eroarea intră
în sarcina fazei următoare a scenariului de toleranță). Definirea stării
consistente (consistent state ) este univocă în cazul unui sistem monoproces,
unde pentru o anumită intrare secvența stărilor parcurse în timpul unei execuții
corecte este întotdeauna aceeași. Toate stările din această secvență liniară sunt
valide sau c onsistente, ele fiind vizitate integral și în aceeași ordine la fiecare
execuție lipsită de defect. Dacă se detectează o eroare și sistemul ajunge într -o
stare invalidă, restabilirea se poate face în oricare din stările consistente, cu
condiția ca noua sta re să fie conformă și cu efectele externe ale evoluției
trecute a sistemului.
În cazul unui sistem cu procese multiple paralele, de genul sistemelor
distribuite, sunt posibile mai multe secvențe de stări valide pornind de la
aceeași stare inițială. Starea următoare în care se produce tranziția dintr -o
stare actuală a sistemului nu este unică și nu poate fi fixată, deoarece depinde
de evenimentul care va apărea primul dintre o mulțime de evenimente posibile
corespunzătoare proceselor. Ca urmare, având aplica te aceleași intrări,
sistemul poate urma diferite secvențe de stări, fiecare dintre ele constituind
câte o execuție validă. O stare a sistemului care apare în oricare dintre aceste
execuții în cazul lipsit de eroare, reprezintă o stare consistentă. Mulțime a
execuțiilor posibile se poate studia pe arborele de accesibilitate (reachability
tree) al sistemului, în care fiecare nod reprezintă o stare validă, iar arcele indică
tranzițiile dintre stări . În figura 4.11 se prezintă arborele de accesibilitate
corespu nzător următorului fragment dintr -un program concurent, în care a, b,
c, d, e reprezintă instrucțiuni atomice (cele care se pot executa în paralel fiind
cuprinse între cobegin și coend ):
a
cobegin b || c || d coend
e
În acest arbore, orice cale care pornește de la nodul rădăcină (starea inițială)
constituie o secvență de execuție a sistemului, toate stările unei astfel de
secvențe fiind consistente. Ca urmare restabilirea si stemului în caz de eroare se
poate face în oricare din stările corespunzătoare execuției actuale sau cele prin
care ar fi trecut sistemul în cazul unei alte execuții corecte posibile. În
concluzie, se poate afirma că starea consistentă a sistemului este o stare
accesibilă lipsită de eroare și conformă cu istoricul evenimentelor reflectate la
interfața sistemului cu exteriorul.
Dacă s -a detectat o eroare, cea mai simplă cale de a aduce sistemul într -o
stare consistentă este de a abandona execuția curentă și de a aplica o
inițializare globală ( global reset ). Aceasta va aduce sistemul într -o stare inițială,
fixă, de unde se poate reîncepe execuția. Resetarea sistemului într -o stare fixă
prezintă însă serioase penalizări de performanță și principala slăbiciune e ste că
o singură stare nu poate ține cont de istoricul actual al intrărilor sistemului. De
Figura 4.11. Fragment dintr -un arbore de accesibilitate
aceea se încearcă fie corectarea stării eronate și continuarea execuției din
punctul în care eroarea a fost detectată, fie readucerea sistemului până la o
stare ante rioară corectă, de preferință nu chiar până la starea inițială. Rezultă
două tehnici uzuale de restabilire din eroare: restabilirea înainte și restabilirea
înapoi .
Atunci când o eroare este detectată în sistem, se apelează un handler de
excepție care va lu a măsuri de eliminare a erorilor din starea sistemului. Aceste
măsuri pot fi bazate atât pe restabilirea înainte, cât și pe restabilirea înapoi.
4.3.2. Restabilirea înainte
Restabilirea înainte (forward recovery ) urmărește restaurarea stării sistemului
prin întreprinderea unor acțiuni asupra părții eronate din starea curentă, în
scopul de a elimina erorile și a permite mersul înainte al sistemului fără
defectare. În această abordare punctul de reluare va fi acel punct în timp în
care starea lipsită de er oare este făcută disponibilă. Pentru a obține o stare
nouă corectă este necesară cunoașterea extinderii exacte a erorii, ceea ce face
ca succesul restabilirii să depindă de acuratețea fazei de evaluare a pagubei. De
aceea, metoda este adecvată pentru cazul defectelor anticipate, pentru care se
pot prevedea prin proiectare măsuri eficiente de delimitare a erorilor. Aceasta
face ca implementarea restabilirii înainte la apariția erorii să aibă un caracter
specific pentru un anumit sistem.
Măsurile de restabili re înainte se bazează în general pe utilizarea
redundanței informaționale sau a redundanței modulare (hardware și
software). Din prima categorie fac parte codurile corectoare de eroare, care
folosesc datele redundante pentru determinarea poziției biților e ronați. Prin
inversarea acestora se restabilește corectitudinea informației și se previne
defectarea sistemului. Această tehnică se utilizează îndeosebi pentru
restabilirea de la defectele anticipate în cazu l unităților de memorie și a
transferului datelor (vezi 3.2).
Tehnicile bazate pe redundanța modulară utilizează un anumit grad de
replicare pentru tolerarea defectelor și un mecanism de decizie asupra ieșirilor.
Din această categorie fac parte tehnicile de mascare a defectelor prin vot
majoritar, cum a r fi redundanța TMR și NMR (vezi 3.1.1) sau programarea N –
versională (vezi 3.4.1). Chiar și în cazul redundanței dinamice (vezi 3.1.2) se
poate renunța la revenirea într -o stare anterioară pentru eliminarea erorii.
Astfel, dacă după detectarea erorii și el iminarea modulului defect, comutarea
ieșirii se face pe un modul de rezervă cald ( hot standby spare , care a operat în
sincronism cu modulul activ), atunci continuarea serviciului se poate face din
punctul în care a fost detectată eroarea. În acest mod se r ealizează toleranța la
defectele permanente. Pentru restabilirea în cazul defectelor tranzitorii de tip
hardware, a fost concepută de Pradhan și Vaidya o schemă bazată pe
redundanță dinamică, numită RFCS ( Roll Forward Checkpointing Scheme ).
Soluția propusă presupune replicarea procesului pe un sistem duplex cu două
module, care efectuează periodic, la punctele de control, câte o salvare a stării
(checkpointing ). La fiecare astfel de punct se efectuează și câte o comparare a
semnăturilor corespunzătoare stăr ilor, în vederea detectării unei erori.
Principiul metodei este ilustrat în figura 4.12. Presupunând că un defect a fost
detectat în momentul t1, au loc următoarele acțiuni :
Starea salvată în t0 se încarcă într -un modul de rezervă, pe care se
repornește procesul aferent intervalului I1. Procesele de pe modulele
A și B vor executa în continuare intervalul I2.
La momentul t2 starea rezervei se compară cu stările salvate (la t1) ale
modulelor A și B. Rezultă o neconcordanță cu B (în cazul de față), deci
acesta a fost afectat de defect.
Starea lui A se încarcă în B (la t2), pentru a restabili consistența
sistemului.
Starea rezervei de la sfârșitul intervalului I2 este comparată cu starea
anterior salvată a lui A, pentru a determina dacă acesta nu a suferit o
defectare în intervalul I2. Dacă nu se constată o neconcordanță, atunci
sistemul se consideră a fi lipsit de eroare. În caz contrar însă, este
necesară efectuarea unei restabili ri înapoi a întregului sistem la starea
din t0.
Figura 4.12. Restabilirea înainte pri n metoda RFCS
O schemă mai optimistă se obține dacă se acordă încredere unui mijloc
de detectare a defectelor ( built -in fault detection ) implementat în modulele
procesoare (figura 4.13). Dacă la sfârșitul intervalului I1 a fost semnalată
prezența unui defect de către modulul B, atunci starea lui A se copiază în B și
procesul poate fi derulat în continuare.
Un avantaj a strategiei de restabilire înainte în raport cu cea de
restabilire înapoi constă în timpul economisit, deoarece după refacerea stării
neeronate nu mai este necesară o repetare a prelucrării. De asemenea,
întârzierea introdusă în activarea ieșirilor este numai temporară, așa cum se
poate observa în schema din figura 4.14. Se consideră că ieșirile se fac
consistente la sfârșitul fiecărui interval dintre două puncte de restabilire, dacă
nu a apărut un defect ( x după I1, y după I2, z după I3 etc.). Dacă în intervalul I1 se
produce un defect, atunci în urma restabilirii înapoi, activarea tuturor ieșirilor
va fi în continuare decalată. În cazu l alegerii restabilirii înainte, procesul va
Figura 4.13. Retabilirea înainte cu mecanism inclus
de detectare a erorii
Figura 4.14. Comparație între momentele de activare a ieșirilor sistemului
la cele două metode de restabilire
continua cu I2, activarea ieșirii x fiind cel mult întârziată cu un interval, dar în
continuare se revine la normal. Această caracteristică poate fi importantă în
sisteme de timp real.
4.3.3. Restabilirea înapo i
Restabilirea înapoi (backward recovery ) realizează eliminarea erorii prin
înlocuirea întregii stări a sistemului cu o stare prealabilă, care se presupune a fi
lipsită de eroare. Se simulează astfel o reîntoarcere în timp a sistemului la o
stare deja oc upată înainte de manifestarea defectului. Reluarea execuției se va
efectua dintr -un punct în timp situat anterior punctului în care eroarea a fost
detectată. Prin această soluție de înlocuire integrală a stării sistemului se
realizează eliminarea tuturor e rorilor din sistem, ceea ce face ca faza de
evaluare a pagubei să -și piardă importanța. De asemenea, devine posibilă
restabilirea sistemului și pentru cazul defectelor neanticipate (cum ar fi cele de
proiectare), care nu pot fi tolerate prin transformări s elective asupra stării
sistemului.
Restabilirea înapoi poate fi considerată ca și un concept general de
refacere a stării corecte, care este implementabilă sub forma unui mecanism la
orice sistem. Pentru a funcționa corespunzător, trebuie îndeplinite două
condiții:
1. Starea anterioară să fie restaurată cu succes.
2. Starea restaurată să fi precedat manifestarea defectului.
Pentru a satisface primul deziderat, este necesară pe de o parte
existența unei informații care să permită refacerea stării, iar pe de altă parte
componentele afectate de operație trebuie să permită restabilirea (să fie
componente recuperabile, recoverable components ). În general componentele
sistemului, a căror schimbare de stare este observabilă prin efectele sale
asupra mediului extern, sun t irecuperabile. Dacă rezultatele eronate au putut
părăsi sistemul, atunci restabilirea unei stări anterioare neeronate devine
inoportună.
Acel punct din timpul activității sistemului în care se va efectua o
eventuală restabilire ulterioară a stării sistemului, se numește punct de
restabilire (recovery point ). În cadrul protocolului care ține de mecanismul de
restabilire înapoi, se identifică următoarele operații :
Constituirea (establish ) unui punct de restabilire, ceea ce înseamnă
asigurarea stocării unor date de restabilire ( recovery data ) care să
permită în orice moment ulterior revenirea în punctul de restabilire.
Restaurarea (restore ), care reprezintă operația de refacere a stării pe
care a avut -o sistemul în punctul de restabilire.
Înlăturarea (discard ) punctului de restabilire, ceea ce reprezintă
renunțarea la păstrarea în continuare a datelor de restabilire.
Este de menționat faptul că odată ce punctul de restabilire a fost înlăturat,
activitatea sistemului se consideră a fi comisă ( commit ), fără a se mai putea
restabili starea din punctul de restabilire anterior. Intervalul de timp dintre
constituirea unui punct de restabilire și înlăt urarea sa acoperă regiunea de
restabilire (recovery region ) a punctului respectiv (figura 4.15).
Figura 4.15. Limitele regiunii de restabilire în evoluția unui sistem
Regiunile de restabilire pot fi succesive, se pot intersecta sau pot fi
incluse una în alta (încuibate). Dacă la momentul detectării erorii există mai
multe puncte de restabilire active, atunci se poate pune problema alegerii
acelui punct care corespunde c ondiției de a prezenta o stare lipsită de eroare.
Prin alegerea punctului cel mai vechi se oferă șanse mai mari de eliminare a
tuturor erorilor, pe când alegerea ultimului punct constituit reprezintă soluția
cea mai economică. În general fixarea punctelor de restabilire se poate face la
intervale egale de timp sau acolo unde proiectantul le consideră a fi cele mai
utile. În cazul în care implementarea tehnicii de restabilire înapoi se realizează
prin blocuri de restabilire pentru tolerarea defectelor de pro iectare software
(vezi 3.4.2), atunci la fiecare intrare într -un bloc de restabilire trebuie constituit
câte un punct de restabilire. Restabilirea înapoi reprezintă totodată o soluție
eficientă împotriva defectelor tranzitorii și intermitente, prin repetar ea
prelucrării din punctul de restabilire pe același hardware. Tolerarea defectelor
hardware permanente poate fi realizată numai prin restaurarea stării
neeronate (inclusiv a programului) pe o componentă de rezervă, pe care se va
continua aplicația (redund anță dinamică).
În funcție de datele de restabilire care se stochează, există două metode
de implementare a mecanismului de restabilire înapoi, și anume cea bazată pe
punctul de control, respectiv pe jurnalul de evenimente. La prima metodă
datele de restab ilire se bazează pe starea sistemului, iar la a doua pe operațiile
efectuate de sistem.
Punctul de control (checkpoint ) reprezintă un punct de restabilire în care
se salvează într -o memorie nevolatilă toate informațiile privind starea
sistemului. Această operație de copiere a stării mai este denumită ca și luarea
unui punct de control ( checkpointing ). Restabilirea în caz de eroare se va realiza
simplu prin înlocuirea stării curente (eronate) a sistemului cu starea înregistrată
în prealabil la punctul de co ntrol. Această măsură radicală de înlăturare a stării
actuale nu prezintă încredere față de nici o parte a acestei stări și de aceea
oferă o mare siguranță privind îndepărtarea erorilor. Ea este totuși costisitoare
sub aspectul cantității substanțiale de d ate care trebuie depuse la fiecare punct
de control într -o resursă de memorie dimensionată corespunzător, precum și a
timpului consumat pentru această operație.
La metoda cealaltă, bazată pe un jurnal al evenimentelor ( log sau audit
trail), pe parcursul ex ecuției se efectuează o înregistrare a tuturor operațiilor
care au dus la modificarea stării, din momentul părăsirii punctului de
restabilire. Ca urmare, la constituirea unui punct de restabilire nu se face nici o
salvare de date ceea ce face metoda mai ec onomicoasă. Cu ocazia restabilirii,
acest jurnal este utilizat pentru derularea activităților în ordine inversă, în
scopul de a anula efectul fiecărei tranziții din timpul execuției. Modificând
succesiv starea sistemului, se urmărește aducerea acesteia înt r-o stare
consistentă, lipsită de eroare. Se remarcă faptul că acest fel de restaurare a
stării acordă o oarecare încredere stării curente eronate a sistemului și prezintă
limitări în sensul că nu orice operație permite revenirea la valoarea anterioară.
Cele două metode de restabilire înapoi discutate mai sus sunt prezentate
schematic în figura 4.16.
Restabilirea înapoi reprezintă o tehnică puternică de restabilire a
sistemului în caz de eroare, capabilă să facă față defectelor arbitrare. Acest
avantaj se înfăptuiește însă pe seama unui necesar suplimentar de resurse de
memorare (redundanță fizică) și a scăderii vitezei de prelucrare (redundanță
temporală). Penalizarea î n timp este cauzată atât de operațiile de salvare a
datelor de restabilire, cât și de durata restabilirii în situațiile de eroare.
4.3.4. Luarea punctului de control
Implementarea mecanismului de restabilire înapoi presupune stocarea într -un
loc sigur a unei informații de stare neeronate, care să poată fi folosită la
reluarea execuției dintr -o stare consistentă după detectarea unei erori. Cea mai
uzuală metodă pentru r ealizarea acestui deziderat constă în salvarea stării
sistemului (operație denumită checkpointing ) de fiecare dată când execuția
ajunge într -un punct de restabilire, care se va numi punct de control
(checkpoint ). În caz de eroare, prin reactivarea stării s alvate procesul este
practic derulat înapoi ( rollback ) la un asemenea punct, de unde urmează să fie
pornit din nou.
Ce anume să conțină starea salvată depinde de la caz la caz, dar în
general ea cuprinde conținutul registrelor CPU și a datelor din memorie cu care
lucrează procesul. În privința locului în care se efectuează salvarea, acesta
poate fi un suport de memorie de gen disc magnetic sau o memorie sigură care
folosește coduri corectoare de eroare, duplicare și eventual este prevăzută și
cu alimentare de la baterie.
Figura 4.16. Schema de principiu a metodelor de restabilire înapoi
De regulă salvarea întregii stări a sistemului este costisitoare sub
aspectul timpului consumat și a spațiului de memorie pe care o necesită. Se
preferă de aceea adoptarea unei tehnici de salvare parțială ( partial
checkpointing ), referitoare numai la datele care suferă modificări între două
puncte de control consecutive. Se prezintă în continuare două soluții bazate pe
acest concept.
Mecanismul bazat pe o memorie rapidă ( cache) de restabilire (recovery
cache ) construiește punctul de control în mod incremental, adăugând la datele
de restabilire valoarea unei variabile chiar înainte de schimbarea ei. Astfel nu se
acumulează informații de restabilire separat pentru fiecare punct de restabilire
activ. Funcționare a corectă a acestui mecanism este asigurată de respectarea
următoarelor reguli :
1. Constituirea unui punct de restabilire nu implică practic nici o
operație, decât pregătirea unei noi zone a memoriei cache în care
urmează să fie depuse datele de restabilire c orespunzătoare acestui
punct. Zonele menționate sunt organizate sub forma unei stive,
existând câte una pentru fiecare regiune de restabilire.
2. La actualizarea unei variabile, se verifică dacă aceasta reprezintă
prima operație de acest gen asupra variabilei respective de când s -a
constituit punctul de restabilire curent. Dacă da, atunci se înscrie în
cache valoarea curentă a variabilei (dinainte de modificare) însoțită
de numele acesteia. În caz contrar nu se efectuează nici o acțiune
asupra memoriei cache d e restabilire.
3. În caz de eroare, refacerea punctului de restabilire curent se face
simplu prin aducerea variabilelor la valorile păstrate în zona curentă a
memoriei cache.
4. Înlăturarea punctului de restabilire curent se realizează prin unificarea
zonei cach e curente cu cea precedentă și ștergerea ultimei înregistrări
pentru fiecare variabilă care este prezentă de două ori în zona
comasată. Ca urmare a acestor operații, zona cache precedentă
suplimentată cu eventuale înregistrări după modul descris devine
zona curentă, iar punctul de restabilire anterior devine cel curent.
Ca o ilustrare, figura 4.17 indică evoluția conținutului memoriei cache de
restabilire, în paralel cu execuția unui program care efectuează operații asupra
variabilelor x și y. Până în momen tul surprins de figură au fost constituite trei
puncte de restabilire ( R1, R2, R3). Se observă că zona curentă conține doar o
înregistrare pentru y, deoarece x nu a fost modificată în această regiune de
restabilire. Pentru înlăturarea punctului R3 este suf icientă ștergerea înregistrării
„y 50”. În schimb, înlăturarea în continuare a lui R2 presupune eliminarea
înregistrării „ x 30” și transferarea înregistrării pentru y în zona anterioară,
întrucât pentru această variabilă nu există nici o intrare în această zonă.
Din cele prezentate reiese că organizarea memoriei cache de restabilire
sub formă de stivă permite numai înlăturarea punctului de restabilire curent.
Înlăturarea unui punct de restabilire anterior necesită restaurarea pe rând a
fiecărui punct de restabilire până la cel dorit, pornind de la cel mai recent
constituit. Totuși această metodă este eficientă mai ales în cazul programelor
structurate s ub formă de blocuri de restabilire încuibate (vezi 3.4.2), unde
regiunile de restabilire sunt incluse succesiv. Trebuie amintit insă faptul că
economia în datele de restabilire stocate s -a înfăptuit pe baza unui timp
adițional consumat de căutările necesar e la acțiunile de actualizare a
variabilelor, respectiv de înlăturare a unui punct de restabilire.
Într-o altă abordare a restabilirii înapoi, organizarea ierarhică a memoriei
unui calculator este folosită pentru soluționarea problemei punctului de
control . În acest caz datele corespunzătoare stării sistemului la punctul de
restabilire sunt amplasate în memoria principală, toate actualizările fiind
păstrate în memoria intermediară rapidă (cache) asociată procesorului (tehnica
fiind de aceea denumită process or cache -based checkpoint ). Separarea dintre
starea activă (curentă) și cea salvată în punctul de control este arătată
Figura 4.17. Conținutul memoriei cache de restabilire în timpul
rulării unui program
schematic în figura 4.18.
Este cunoscut faptul că memoria cache reprezintă o memorie
intermediară rapidă și conține la un moment dat acele linii (blocuri) transferate
din memoria principală care cuprind datele care au fost accesate de procesor.
Tehnica de restabilire prezentată aic i se bazează pe următoarele principii :
1. Toate actualizările de date între două puncte de control se efectuează
numai asupra memoriei cache. Ca urmare ea va conține linii murdare
(dirty lines ), care au suferit modificări, și linii curate ( clean lines ).
2. Luare a unui punct de control constă în transferarea liniilor de cache
murdare în memoria principală și salvarea registrelor CPU în memorie
(sau cache). Momentul efectuării unei astfel de operații poate fi
declanșat pe cale hardware, respectiv el are loc implici t de fiecare
dată când memoria cache este plină ( cache full condition ). Această din
urmă situație se produce atunci când data căutată nu se află în cache
(cache -miss ) și o linie trebuie eliminată pentru a face loc noii linii care
urmează să fie adusă din m emorie.
3. Restabilirea stării din punctul de control, după ce o eroare a fost
detectată se face simplu prin invalidarea tuturor liniilor murdare din
cache și reîncărcarea registrelor CPU din memorie (sau cache). O
soluție alternativă constă în epurarea între gului cache, liniile solicitate
de CPU fiind oricum aduse din memorie după reluarea execuției.
Pentru ca tehnica descrisă să poată lucra cu succes, memoria cache
trebuie să utilizeze o strategie de tip write -back . Aceasta înseamnă, spre
deosebire de meto da write -through , că procesorul nu efectuează nici o scriere
în memorie, conținutul ei fiind modificat doar cu ocazia înlocuirii unei linii.
Figura 4.18. Utilizarea ierarhiei de memorii pentru luarea
punctului de restabilire
Ca o limitare față de tehnica precedentă se poate menționa faptul că se
acceptă existența unui singur punct de res tabilire activ la un moment dat.
Metoda de restabilire bazată pe cache -ul procesorului a fost utilizată la
sistemul multiprocesor Sequoia pentru a face posibilă toleranța la defectele de
procesor. Se folosesc două bancuri de memorie și marcaje de timp în s copul de
a permite restabilirea și de la defectele care ar putea să apară tocmai în timpul
luării punctului de control.
În anumite sisteme tehnica de checkpointing nu este suficientă ca să
asigure restabilirea unei stări consistente, ea trebuie combinată cu tehnica
bazată pe jurnalul de operații ( audit trail ) dintre două puncte de control. Astfel,
dacă devine necesară restaurarea unui punct de restabilire dintre două puncte
de control, acest lucru se poate înfăptui prin restaurarea punctului de c ontrol și
prelucrarea jurnalului înspre înainte (cu operații de tip REDO) sau înspre înapoi
(cu operații de tip UNDO). Pentru a putea efectua aceste operații, datele de
restabilire corespunzătoare jurnalului trebuie să conțină câte o înregistrare
pentru fi ecare eveniment care a provocat modificarea valorii unui obiect.
Câteodată este suficientă precizarea numelui acestei funcții (dacă ea este
reversibilă), dar la operațiile de citire/scriere se înregistrează valoarea veche și
cea nouă a obiectului modificat . Acestea se mai numesc imaginile de dinainte și
de după tranziție ( before – and after -images ).
Cazul de mai sus se întâlnește de exemplu în sistemele cu procese
multip le, când mai multe tranzacții concurente acționează asupra unei baze de
date. Fie pentru ilustrare situația din figura 4.19. După defectare, baza de date
trebuie readusă într -o stare consistentă prin procesul de restabilire. În acest caz
starea consistentă trebuie raportată la tranzacții ( transaction consistent state ),
Figura 4.19. Restabilirea înapoi în cazul unor tranzacții concurente
în sensul că baza de date va trebui să conțină rezultatele tuturor tranzacțiilor
încheiate (comise), dar nu trebuie să conțină rezultatele tranzacțiilor
incomplete. În punctul de control s -a salvat o copie a datelor din acel moment,
cu unele tranzacții aflate în derulare. Ca urmare, sunt necesare operații de tip
UNDO asupra tranzacției T1 pe baza jurnalului, pentru a anula efectele acestei
tranzacții neterminate asupra bazei de date. Prin rest abilirea stării din punctul
de control, efectele lui T2 sunt automat anulate, pentru T4 se impune aplicarea
de operații de tip REDO numai pentru acele acțiuni ale sale care au fost
efectuate după punctul de control. De asemenea se vor executa operații de t ip
REDO asupra tuturor acțiunilor lui T5, pentru ca efectele acestei tranzacții să
apară în baza de date. Asupra lui T3 nu trebuie efectuată nici o operație,
deoarece efectele sale sunt prezente în datele din punctul de control. În
concluzie, dacă se sesizează un defect, prima dată se restabilește starea
sistemului de la punctul de control, iar apoi cu ajutorul jurnalului de tip UNDO –
REDO se anulează efectele tranzacțiilor neterminate, respectiv se refac efectele
celor încheiate. Acesta se mai numește modelul RR (Rollback and Recovery ).
Fixarea punctelor de restabilire se poate face la intervale egale de timp,
după un anumi t număr de tranzacții sau în mod aleator. Mărimea intervalului
dintre două puncte de control are o influență hotărâtoare asupra
performanțelor sistemului. Pe măsură ce acest interval crește, se mărește
timpul de restabilire și ca urmare scade disponibilita tea sistemului. Pe de altă
parte însă un interval mai lung reduce timpul afectat pentru luarea punctelor
de control, ceea ce duce la creșterea disponibilității. De aici rezultă că se poate
determina un interval optim între punctele de control care maximali zează
disponibilitatea. Dacă se notează cu T intervalul dintre două puncte de control,
atunci disponibilitatea
(T) se poate exprima sub forma:
suplim total TTT
TTα(T)
Se observă că disponibilitatea va fi maximă dacă timpul suplimentar ( Tsuplim )
cheltuit pentru luarea punctului de control, respectiv pentru restabilire în cazul
unei eventuale defectări, este minim. Pentru a exprima valoarea optimă a lui T,
presupunând că punctele de control se iau la intervale fixe, se introduc
următoarele notații:
defectăr ile se produc după o distribuție exponențială cu rata
, fiind
imediat detectate
tranzacțiile sosesc cu rata constantă
timpul mediu de prelucrare a unei tranzacții este
.1const
salvarea informației în punctul de control are durata medie
restaurarea informației din punctul de control are durata medie
Durata așteptată a procesului de restabilire, la momentul t de la fixarea
unui punct de control, este:
1)( t tR
În expresia de mai sus primul termen reprezintă timpul afectat pentru
restaurarea informației de control, iar al doilea corespunde prelucrării
jurnalului de evenimente. Se presupune că acest din urmă timp este
proporțional cu dimensiunea jurnalului. Factor ul
reprezintă numărul de
tranzacții care au sosit în timpul t, care înmulțit cu durata medie a prelucrării va
da timpul necesar operației de audit. Raportul
k este o constantă de
proporționalitate, care se numește factor de compresi e.
Cheltuielile suplimentare de timp pe întregul interval (0, T) sunt date de
Tsuplim = + C(0) ,
unde C(0) constituie timpul total legat de restabilire. Cheltuiala de timp pentru
restabilirea efectivă pe ( x, T), notată cu C(x), depinde de numărul de defectări
care apar pe acest interval. Considerând intervalul elementar ( tt, t),
probabilitatea de a detecta o defectare în cadrul acestuia este t. Dacă
defectarea se produce, atunci costul pe intervalul ( tt, T) este R(t)+C(t), în
schimb dacă ea nu a pare atunci costul este numai C(t). Se poate deci scrie:
C(tt) = t [R(t)+C(t)] + (1t) C(t)
C(t) C(tt) = t R(t)
Trecând la limită pentru t→ 0 se obține:
kt tRdttdC )()(
Prin integrarea ecuației și ținând cont că C(T)=0 (deoarece la t=T este următorul
punct de restabilire și nu mai este necesară revenirea), se obține:
2
2)0( TkT C
Înlocuind rezultatele obținute în expresia disponibilității, rezultă:
Tk
TT
211)(
Valoarea maximă se obține pentru
0)()(TdTd , ceea ce conduce la
022k
T
de unde rezultă în final expresia timpului optim între punctele de control:
kTopt2
Este de remarcat faptul că valoarea optimă a intervalu lui dintre două
operații de checkpointing nu depinde de timpul consumat pentru restaurare
(
), deși costul suplimentar introdus este influențat de acest timp. Cu toate
simplificările făcute, modelul matematic prezentat s -a dovedit a fi rezonabil în
sisteme le practice.
4.3.5. Efectul domino
În cazul sistemelor cu mai multe procese concurente, restabilirea în caz de
eroare poate ridica probleme suplimentare față de cazul unui proces singular.
Dacă procesele ar fi independente între ele, neavând acces la obi ecte comune,
atunci restabilirea fiecărui proces poate fi tratată individual, fără a ține seama
de celelalte procese din sistem. În schimb la procesele concurente cooperante,
între care există schimburi de date (cum ar fi sistemele distribuite),
comunicați ile dintre procese implică interdependențe între ele care
îngreunează găsirea unei stări consistente cu ocazia restabilirii.
În situația în care s -a semnalat o eroare într -unul din procese, datorită
dependențelor care există este necesară aducerea întregului sistem (deci a
tuturor proceselor) într -o stare consistentă. Adoptând o strategie de restabilire
înapoi pe baza mecanismului de checkpointing, punctul de control global al
sistemului va consta din mulțimea formată din câte un punct de control pe ntru
fiecare proces. Această mulțime nu reprezintă însă totdeauna o stare
consistentă a sistemului, fiind întâlnite două cazuri care duc la inconsistență.
Este vorba aici despre mesajele pierdute și mesajele orfane .
Mesajul pierdut (lost message ) reprezintă situația în care transmiterea
mesajului este reflectată în starea unui proces, dar recepționarea acestuia nu
se regăsește în starea nici unui alt proces. Fie două procese ( P1 și P2) între care
se transmite un mesaj m de la P1 la P2 și care au fi xat câte un punct de control
r1, respectiv r2 după modul indicat în figura 4.20a. Se observă că dacă
restabilirea după eroare a proceselor se face în aceste puncte, atunci mesajul m
rămâne nerecepționat, adică este un mesaj pierdut. Situația inversă este c ea
din figura 4.20b, în care m devine mesaj orfan (orphan message ) după
restabilire, deoarece a fost recepționat fără să fi fost trimis. Evident în cazul
execuției normale, fără eroare urmată de restabilire, nu apar mesaje pierdute
sau orfane. Evitarea lor în timpul restabilirii înapoi necesită impunerea de
restricții privind alegerea mulțimii de puncte de control pentru a constitui o
stare consistentă a sistemului.
Figura 4.20. Situații de inconsistență la restabilirea înapoi a
două pr ocese concurente cooperante
Efectul domino (domino effect ), descris de Randell, apare tocmai în
încercarea de căutare prin revenire după o mulțime de puncte de restabilire
care să formeze o stare consistentă a sistemului. Acest fenomen poate
declanșa o derulare înapoi necontrolată a tuturor proceselor, chiar până la
starea inițială a sistemului.
Pe exemplul din figura 4.21 sunt reprezentate trei procese concurente
(P1, P2, P3) care comunică între ele. Presupunând că o eroare a fost detectată în
procesul P1, acesta va fi readus în punctul de control r14. Dar, deoarece P1 a
recepționat un mesaj de la P2 după r14, și P2 trebuie adus înapoi în r23. Cu
această ocazie însă P2 anulează mesajul trimis către P3, ceea ce necesită
restabilirea acestuia din urmă în r33. Revenirea lui P3 în r33 declanșează în
continuare readucerea lui P1 în r13, și așa mai departe până când starea
sistemului devine consistentă. Această stare se întâlnește pentru mulțimea de
puncte { r13, r22, r32}, care formează o linie de restabilire. Linia de restabilire
(recovery line ) reprezintă deci o mulțime de puncte de control a tuturor
proceselor la care acestea pot fi aduse înapoi în caz de defectare pentru a
asigura o stare consistentă lipsită de eroare a sistemului. Se observă pe figură
că o astfel de linie nu se întretaie cu nici un arc aferent mesajelor. Într -o
codificare mai exactă, o mulțime de puncte de control formează linie de
restabilire dacă sunt satisfăcute următoarele condiții :
1. Mulțimea conține exact câte un punct pentru fiecare proces.
2. Nu există nici un caz de transmitere a unui mesaj de către un proces Pi
înaintea punctului său de control astfel încât recepționarea sa să se
situeze în procesul Pj după punctul său de control (cu alte cuvinte, nu
există mesaje pierdute).
3. Nu există nici un caz de transmitere a unui mesaj de către un proces Pi
după punctul său de control astfel încât recepționarea sa să se situeze
în procesul Pj înaintea punctul său de control (cu alte cuvinte, nu
există mesaje orfane).
În vederea localizării unei linii de restabilire, și evitarea astfel a efectului
domino, există în principiu două abordări: statică și dinamică.
Figura 4.21. Ilustrarea efectului domino în cazul restabilirii
a trei procese concurente
Abordarea statică , pesimistă, presupune proiectarea sistemului de așa
manieră ca o linie de restabilire să fie totdeauna disponibilă și planificată
dinainte. Pentru aceasta se impune forțarea unor restricții asupra
comunicărilor dintre procese, respectiv prevederea unor măsuri de sincronizare
între procese. O soluție ar putea fi stabilirea simultană a punctelor de
restabilire pentru toate procesele, care ar avea avantajul unui efort minim de
restabilire. Pe de altă parte însă, necesarul mare de memorie pentru păstrar ea
datelor de restabilire și timpul consumat pentru luarea unui număr mare de
puncte de control, fac ca metoda să nu fie atractivă. Limitări în comunicațiile
dintre procese se pot introduce printr -o structurare adecvată a sistemului
bazată pe conceptul acț iunilor atomice. În acest caz amplasarea corelată a
punctelor de restabilire devine posibilă dacă fiecare proces își fixează un punct
de restabilire la intrarea în acțiunea atomică. Aceste puncte nu sunt înlăturate
în timpul acțiunii, dar pentru ca ea să f ie restaurabilă se impune ca procesele să
părăsească acțiunea simultan (unele vor trebui eventual să aștepte).
O formă de acțiune atomică aplicabilă la sistemele monoproces este
blocul de restabilire (vezi 3.4.2). Pentru cazul proceselor paralele care comu nică
între ele a fost propusă de Randell o extensie a blocului de restabilire, numită
conversație (conversation ). Fiecare proces care face parte dintr -o conversație
trebuie privit ca un bloc de restabilire care dispune de un punct de restabilire,
un test de acceptare și algoritmi alternativi. Dacă oricare proces nu trece testul
de acceptare, atunci toate procesele din conversație se readuc înapoi în
punctele lor de restabilire de la intrare și se reiau cu un alt algoritm. Un proces
aflat în conversație nu are voie să comunice decât cu celelalte procese din
aceeași conversație, pentru a păstra atomicitatea. Linia de restabilire,
prevăzută prin proiectare, va consta din mulțimea punctelor de restabilire ale
proceselor fixate la intrarea în conversație.
În exe mplul din figura 4.22, procesele P1 și P2 intră într -o conversație prin
punctele A și B, unde își stabilesc puncte de revenire. La atingerea punctelor
finale ale conversației ( C și D), fiecare proces va executa propriul test de
acceptare și nici unul nu ar e voie să părăsească conversația decât dacă ambele
teste sunt reușite. În caz contrar, atât P1, cât și P2 vor reveni la linia de
restabilire. Procesul P2 va putea intra în a doua conversație, cu P3 (prin punctele
E și F) numai după ce conversația precedent ă a luat sfârșit. Este de menționat
faptul că mai multe conversații pot fi încuibate, la fel ca la blocurile de
restabilire.
Abordarea dinamică , optimistă, permite proceselor individuale să -și
fixeze puncte de restabilire în mod asincron, fără nici o restricție. Concomitent
cu execuția proceselor se efectuează câte o înregistrare asupra schimburilor de
mesaje dintre procese. Restabilirea unei stă ri consistente după eroare va
consta dintr -o căutare dinamică după o linie de restabilire pe baza
înregistrărilor disponibile privind fluxul de date din sistem. Utilizarea liniilor de
restabilire neplanificate este o metodă costisitoare datorită monitoriză rii
comunicațiilor și nu duce totdeauna la rezultat. Uneori se păstrează o
înregistrare a tuturor mesajelor sosite la un proces, ceea ce duce la o
îmbunătățire a mecanismului de restabilire. Astfel, dacă se detectează o eroare
într-un proces receptor, se e fectuează restabilirea acestuia la ultimul punct de
control, iar mesajele care au fost primite ulterior acestui punct vor fi preluate
din înregistrarea proprie fără implicarea procesului emițător. Dacă însă
defectarea este semnalată la procesul emițător, r estabilirea va fi necesară și la
celelalte procese cărora le -au fost trimise mesaje ulterior punctului de
restabilire al procesului emițător. O altă tehnică dinamică se bazează pe
construirea grafului de evenimente (occurrence graph ) al sistemului în timpu l
execuției, care reflectă succesiunea de stări a elementelor din sistem.
Restabilirea înapoi se traduce prin identificarea unui astfel de subgraf al
acestuia (numit subgraf de restabilire), a cărui eliminare să ducă la un set de
stări consistente.
În co ncluzie, din cele prezentate rezultă că evitarea efectului domino în
sistemele cu procese concurente se poate face numai pe seama unor penalizări
Figura 4.22. Utilizarea conversațiilor pentru restabilirea
proceselor paralele
sub forma memoriei suplimentare (pentru salvarea informațiilor din punctele
de control, respectiv a înregistră rii fluxului de date) și a suspendării activității
utile pentru efectuarea salvărilor și restabilirilor. Abordarea statică limitează
derularea înapoi la restabilire, dar crește costurile de luare a punctelor de
control, pe când abordarea dinamică reduce co sturile legate de operația de
checkpointing, dar efortul de restabilire nu este limitat, nefiind sub control.
4.3.6. Tratarea excepțiilor
Tratarea excepțiilor ( exception handling ) oferă un cadru software pentru
organizarea activităților legate de toleran ța la defecte. Se consideră că
modulele soft ale sistemului sunt dispuse ierarhic, astfel încât un modul M
poate cere serviciul modulului N aflat în nivelul inferior (figura 4.23). Răspunsul
modulului N este normal dacă în timpul execuției sale (și a modul elor apelate la
rândul său pe cale ierarhică) nu a fost detectată nici o situație de eroare. În caz
contrar, modulul invocat va furniza un răspuns anormal prin care indică apariția
unei nereguli la nivelul său, care poartă numele de excepție (exception ).
Modulul solicitant ( M), după ce i s -a semnalat excepția, este în continuare
responsabil de reluarea execuției lui N care a fost abandonat din cauza
excepției.
Figura 4.23. Tratarea excepției apărute într -un modul software
apelat din nivelul superior
O clasificare a excepțiilor (în externe și interne) a fost dată în subcapitolul
2.2. Rolul mecanismului de tratare a excepțiilor trebuie să fie acel a de
semnalare a excepțiilor, respectiv de mascare a acestora către nivelurile
superioare. Punerea în evidență a unei excepții într -un modul soft se poate face
cu ajutorul unui model orientat pe domeniile unui program , propus de Cristian.
Fie programul P care începe în starea s, se termină în starea s' și care furnizează
un serviciu specificat prin post -condiția post (s, s'). Măsura în care comportarea
programului satisface serviciul solicitat depinde de starea de intrare sub care se
execută. Mulțimea tuturo r intrărilor posibile formează domeniul de intrare al
lui P, care se poate împărți în două subdomenii complementare: standard și de
excepție. Domeniul standard ( standard domain ) al programului P (notat DS)
reprezintă mulțimea stărilor s pentru care P se te rmină normal într -o stare s' cu
respectarea condiției post (s, s'). Restul stărilor din domeniul de intrare, pentru
care se produce o excepție în cazul apelării lui P, alcătuiesc domeniul
excepțiilor ( exception domain ) al programului P. La rândul său, acest domeniu
se subdivide în domeniul excepțiilor anticipate ( DEA) și domeniul excepțiilor
neanticipate ( DEN ), după cum proiectantul poate prevedea sau nu situațiile de
excepție posibile (figura 4.24).
Pentru domeniul excepțiilor anticipate se poate prevedea î ncă de la
elaborarea sistemului un mecanism de tratare a excepțiilor, care să ia măsuri
corespunzătoare de gestionare a acestor situații. În schimb apelarea
programului în domeniul excepțiilor neanticipate ( sDEN ) va duce la
defectarea modulului (netermina rea sa sau încheierea într -o stare s'
neconformă cu post (s, s')).
În cazul în care o excepție anticipată a fost semnalată, se invocă un
handler de excepție (exception handler ). Handler -ul conține acțiuni
suplimentare prevăzute de programator în scopul rest abilirii unei situații lipsite
de eroare. Această activitate corectivă se poate baza atât pe tehnica restabilirii
Figura 4.24. Împărțirea pe domenii a mulțimii intrărilor
unui program
înapoi, cât și pe cea a restabilirii înainte.
Se consideră că în timpul execuției unei proceduri se pot semnala
excepțiile apărute în cazul în care sunt detectate. Aceste semnalizări trebuie
declarate în cadrul procedurii în contextul său de tratare a excepțiilor. Este
necesar a asocia fiecărui tip de excepție un handler, care poate fi local (pentru
excepțiile interne) sau la distanță (pentru ex cepțiile externe). În acest din urmă
caz, excepția este semnalată nivelului superior, responsabilitatea tratării
excepției fiind predată astfel modulului care a apelat procedura.
Un exemplu de gestionare a excepțiilor într -o procedură care efectuează
împăr țirea a două numere reale este dată în continuare:
procedure divide (x,y: real) return (rezultat : real)
begin
if (x ilegal y ilegal ) then
signal excepție_de_interfață
else
if y=0 then
raise divizare_cu_zero
else
return rezultat :=x/y
fi fi
exception /* handler -ele de excep ție */
when divizare_cu_zero
signal excepție_de_defectare
when depășire_inferioară
return rezultat :=0
when depășire_superioară
signal excepție_de_defectare
when altele
signal excepție_de_defectare
end
Pentru a face distincție între excepțiile externe și interne, semnalarea lor a fost
notată cu cuvintele cheie signal , respectiv raise . Dacă cererea de apel a
procedurii a fost ilegală, de exemplu datorită formatului de reprezentare
necorespunzător al opera nzilor, atunci se semnalează o excepție de interfață
către programul apelant. Procedura divide nu a produs nici o eroare și nu are
cum să trateze o astfel de excepție. Partea de excepție din cadrul procedurii
tratează situațiile când ( when ) s-a produs un e veniment anormal în timpul
execuției sale. Dacă se semnalează o excepție internă cauzată de valoarea nulă
a împărțitorului, atunci se caută în acest nivel un handler de excepție cu
numele de divizare_cu_zero . Acesta în cazul de față nu este capabil de
rezo lvarea problemei și va genera către nivelul superior o excepție de
defectare. Dacă interpretorul hardware a detectat la împărțire o depășire în jos
a capacității de reprezentare ( underflow ), atunci se poate face o restabilire
înainte însăși în cadrul modul ului prin rotunjirea rezultatului la zero. Acest
eveniment nedorit, dar anticipabil, este un exemplu de excepție internă. În
schimb dacă a apărut o depășire în sus ( overflow ), atunci s -a prevăzut
semnalizarea acestui fapt către nivelul superior sub forma u nei excepții de
defectare a procedurii. Același tratament se aplică și celorlalte situații de
excepție care pot să apară, dar care intră în categoria celor neprevăzute.
Pentru a trata și cazul excepțiilor neanticipate, pentru care nu sunt
prevăzute handle r-e particulare, este eficientă includerea in sistem a unui
handler implicit (default handler ). Acesta trebuie să fie cât mai general, pentru
a putea capta toate excepțiile care nu au fost acoperite prin alte măsuri. În
acest scop este adecvată utilizarea tehnicii de restabilire înapoi de către
handler -ul implicit, ceea ce nu necesită cunoașterea naturii problemei apărute.
Blocul de restabilire (vezi 3.4.2), care este bazat pe restabilirea înapoi,
reprezintă o posibilitate de implementare a tratării implici te a excepțiilor.
Principiul este simplu, modulul alternativ fiind considerat handler de excepție
pentru cel primar. Descrierea formală, pentru cazul a două module ( M0 primar
și M1 alternativ) și un test de acceptare < TA> este dată mai jos. La intrarea în
blocul de restabilire se fixează un punct de restabilire prin salvarea stării într -o
memorie cache. O eroare în modulul M0 este detectată prin utilizarea testului
de acceptare. Dacă acesta este refuzat, se restabilește st area de la intrarea în
bloc și se execută modulul M1. În cazul în care nici acesta nu trece testul,
alternativa de eroare va informa nivelul superior despre eșuarea execuției
blocului. Bineînțeles eficiența tratării excepțiilor în acest mod depinde în mare
măsură de capacitatea de detecție a erorilor de către testul de acceptare.
bloc_de_restabilire :
begin
init cache /* salvare stare curentă */
do <algoritm primar M 0>
if not <TA> then
signal neacceptat
else
discard cache /* înlăturare punct de restabilire */
fi
exception
when neacceptat
begin
restore cache /* restabilire stare */
do <algoritm alternativ M 1>
if not <TA> then
signal eroare
else
discard cache
fi
exception
when eroare
discard cache
signa l defectare
end
end
Tratarea excepțiilor se poate concepe și într -o abordare multinivel, în
care semnalul de excepție urcă în ierarhia de apelare a modulelor până când
este captat de cel mai apropiat handler pentru servire. Modulul care generează
semnalul nu trebuie să adreseze declarația sa de excepție către un anumit
handler. După captarea excepției ( exception catching ), controlul revine
handler -ului, care încearcă prelucrarea corespunzătoare a excepției. Reluarea
execuției aplicației se va face la nivelul handler -ului, ceea ce necesită însă
rezolvarea prealabilă a unor probleme legate de procesele neterminate din
nivelurile inferioare. Astfel în timpul căutării după handler, sistemul de operare
trebuie să permită părăsirea unui modul numai după ce a efectuat „curățirea”
acestuia de toate elementele legate de apelarea sa (desființarea variabilelor
locale, eliberarea resurselor blocate etc.). După tratarea excepției, aplicația va
continua din modulul în care se află handler -ul de excepție.
Gestionarea erorilor se efectuează în multe limbaje de programare prin
mecanismul de tratare a excepțiilor. Exemple elocvente în acest sens sunt
limbajele Java, Ada, Eiffel, Clu și Mesa.
4.3.7. Comiterea
În cazul sistemelor distribuite, problema asigurării și restab ilirii unei stări
consistente este complicată de lipsa unui control centralizat. Între nodurile
participante la un proces distribuit trebuie asigurată o sincronizare astfel încât
să rezulte numai una din următoarele două stări observabile ale sistemului:
comis ( commit ) sau abandonat ( abort ). De exemplu, o tranzacție inițiată de un
nod poate implica și date aflate în alte noduri autonome, de la care va cere
efectuarea unor operații locale. Dacă există noduri în care aceste procese locale
eșuează datorită uno r defectări, atunci s -ar obține o stare inconsistentă a
sistemului, soluția fiind abandonarea întregii tranzacții. Pentru respectarea
proprietății de atomicitate a tranzacției este deci necesar ca ea să fie săvârșită
(comisă) numai dacă toate nodurile care iau parte sunt în stare să comită (să
facă permanente modificările în propriile lor baze de date). În acest scop au
fost concepute protocoale de comitere distribuite, menite să asigure fixarea
liniilor de restabilire (comitere) preplanificate. Dacă s -a produs defectarea unui
nod în timpul procesului sau al comiterii, atunci se declanșează operația de
restabilire, de la care se așteaptă ca să aducă la comitere, în caz contrar
tranzacția fiind abandonată.
Protocolul clasic care asigură atomicitatea acțiunii de comitere într -un
sistem distribuit este comiterea în două faze (two-phase commit ). În acest
protocol, nodul care inițiază tranzacția se numește coordonator, iar celelalte n
noduri care iau parte la tranzacție poartă numele de participanți. Se consideră
că procesul distribuit a fixat o linie de restabilire (câte un punct de restabilire
pentru fiecare nod), apoi a actualizat datele în nodurile implicate și în
continuare dorește să comită (desăvârșească) acțiunea. Această comitere va
avea loc în două faze, care pot fi descrise confortabil cu câte un automat de
stare al coordonatorului, respectiv al unui participant (figura 4.25). Stările
nodului sunt reprezentate prin cercuri, iar tranzacțiile prin muchii orientate.
Lângă fiecare tranziție se prezintă condiț ia asupra mesajelor recepționate
pentru declanșarea tranziției (deasupra liniei), respectiv mesajul transmis de
nod în cazul producerii tranziției (sub linie).
În prima fază coordonatorul pornește din starea inițială q0 și atunci când
este invocat ( BEGIN ) de proces trimite câte un mesaj fiecărui participant
(REQUEST i), prin care îi întreabă dacă sunt în stare să comită. După aceea trece
în starea de așteptare w0. Participantul i este invocat în starea inițială qi de
recepționarea mesajului REQUEST i. Dacă este capabil de comitere răspunde
„da” ( YES i) și trece în starea de așteptare wi. În caz contrar răspunde cu „nu”
(NO i) și abandonează (starea ai).
În faza a doua, coordonatorul adună răspunsurile de la toți participanții.
Dacă toți participanții, inclusiv coordonatorul, au votat pentru comitere, atunci
trimite mesaje COMMIT i către participanți, prin care le cere să comită. După
aceea, coordonatorul t rece în starea sa de comitere ( c0). În schimb, dacă există
vreun participant (sau chiar coordonatorul) care nu este de acord cu comiterea,
coordonatorul transmite mesaje ABORT i acelor participanți care au votat cu
„da” și trece în starea de abandon a0. Fiecare dintre acești participanți așteaptă
în starea wi decizia de la coordonator. Dacă sosește un mesaj COMMIT i, atunci
participantul comite și trece în starea ci, iar în caz contrar (se recepționează
ABORT i) abandonează în starea ai.
Rolul protocolului de comitere în două faze este de a asigura ca ori toate
nodurile să comită, ori toate să abandoneze, cu alte cuvinte să lase s istemul
într-o stare consistentă. Abandonarea trebuie considerată ca fiind echivalentă
cu restaurarea sistemului la ultima linie de restabilire, fără să se fi săvârșit vreo
modificare asupra bazei de date distribuite.
În cazul în care nu se produce nici o defectare (a unui nod sau de
comunicație) în timpul execuției protocolului, este clar că se poate respecta
proprietatea de atomicitate. Problema care se pune este de a asigura acest fel
de comportament la nivelul sistemului și după defectare. Legat de acea stă
problemă, se pot pune următoarele întrebări:
1. Cum află un nod operațional de apariția defectării într -o parte a
sistemului și ce măsuri adoptă ?
2. Cum detectează un nod propria defectare și ce acțiune întreprinde ?
Pentru a împiedica blocarea procesului d intr-un nod într -o stare de
așteptare se folosește o excepție de tip timeout . Aceasta se generează atunci
când mesajul așteptat nu sosește până la expirarea timpului indicat de un
temporizator local, datorită unui defect de comunicație sau al nodului
emiță tor. Ca urmare nodul în cauză (destinatar) va efectua o tranziție de tip
Figura 4.25. Grafurile automatelor de stare de la coordonator și participant
în cazul comiterii în două faze
timeout într -o altă stare, care poate fi de abandon ( a) sau de comitere ( c), după
cum rezultă din situațiile de mai jos:
Când coordonatorul așteaptă în starea w0 voturile de la partic ipanți și
apare o excepție de timeout, coordonatorul poate abandona în
siguranță deoarece nu a fost luată încă nici o decizie.
Când participantul așteaptă în starea qi și nu sosește solicitarea
pentru vot, el poate abandona în siguranță la apariția unui ti meout,
votul său nefiind încă dat.
Când participantul stă în așteptare în starea wi după ce a votat „da” și
se produce excepția de timeout, este necesară execuția unui protocol
de terminare (termination protocol ) pentru a lua decizia asupra stării
următoar e.
Scopul protocolului de terminare este de a asigura ca toate nodurile
operaționale să ajungă în aceeași stare finală. Protocolul se bazează pe
interogarea unui alt nod participant operațional asupra deciziei comunicate
de coordonator privind comiterea. E vident în cazul în care nodul întrebat a
votat cu „nu”, nu mai interesează rezultatul de la coordonator, singura
posibilitate fiind abandonul. Dacă nodul întrebat a primit decizia de
comitere, atunci și participantul interogator va putea comite. Totuși, no dul
participant nu va putea lua o decizie nici cu ajutorul protocolului de
terminare în următoarele două situații: coordonatorul s -a defectat înainte de
transmiterea deciziei și de asemenea toți participanții care au răspuns cu
„nu” (dacă este cazul) s -au defectat la rândul lor; respectiv coordonatorul s -a
defectat după ce a trimis decizia unei submulțimi de noduri care însă au
căzut și ele ulterior (împreună cu participanții care au abandonat). În aceste
cazuri nodul în cauză nu poate face altceva decât să aștepte în continuare,
până când se va restabili un nod defect care cunoaște decizia finală. Rezultă
că protocolul de comitere în două faze poate duce la blocare în anumite
situații.
Defectarea unui nod se detectează de un mecanism de testare local
încorporat ( built -in test ). După detectarea defectării, nodul intră într -o operație
de restabilire, după care trebuie să se afle într -o stare finală consistentă
conformă cu a celorlalte noduri din sistem (ori toate în stare comisă, ori toate
în stare de ab andon). Se presupune că fiecare nod conține o memorie stabilă în
care își poate păstra starea dinainte de defectare , având astfel la dispoziție un
jurnal ( log) al acțiunilor efectuate la nodul respectiv. Astfel după restabilirea
din eroare, nodul va putea determina pe baza înregistrărilor din jurnal starea în
care s -a aflat în momentul defectării. Este de dorit ca după restabilire, nodul să
poată lua o decizie privind starea finală numai pe baza informațiilor proprii de
care dispune. Aceasta se numește restabilirea independentă (independent
recovery ), care însă nu este totdeauna realizabilă. Sunt posibile următoarele
cazuri:
După restabilirea coordonatorului, el verifică în primul rând o
înregistrare ( START -2PC) din care să afle că a fost într -adevăr
inițiatorul unei tranzacții. După aceea, dacă găsește o înregistrare de
tip COMMIT sau ABORT în jurnal, înseamnă că a fost luată deja o
decizie înainte de defectare căreia poate să i se conformeze; dacă nu
găsește n ici o înregistrare, atunci va abandona.
Dacă un participant după restabilire găsește în propriul jurnal o
înregistrare de tip COMMIT sau ABORT , atunci înseamnă că decizia a
fost deja luată înainte de defectarea sa și poate să i se conformeze.
Dacă particip antul nu găsește după restabilire nici o înregistrare,
înseamnă că defectarea s -a produs înainte de a vota și deci va putea
decide cu siguranță abandonarea.
Dacă după restabilire un participant găsește numai o înregistrare
aferentă unui vot afirmativ ( YES) făcută înainte de defectare, atunci
nu poate decide de unul singur asupra stării finale, fiind necesară
consultarea altui nod printr -un protocol de terminare; acesta poate
determina însă, cum s -a văzut, o situație de blocare dacă comunicarea
cu un nod car e cunoaște rezultatul final nu se poate realiza.
Descrierea formală a algoritmului de comitere în două faze pentru
coordonator și participant este dată în continuare. Cu WriteLog ( ) s -a notat
operația de înscriere în jurnal a unei înregistrări. Se remarcă încadrarea fiecărui
context de tratare a excepțiilor de câte o pereche de instrucțiuni begin -end.
2PC_coordonator (la recepționarea lui BEGIN ):
begin
/* faza 1, de votare */
send REQUEST tuturor participanților ;
WriteLog ( START -2PC)
begin
wait mesaje de vot de la toți participanții
exception
when timeout ;
WriteLog ( ABORT )
send ABORT tuturor proceselor care au votat YES
signal defectare
end
/* faza 2, de decizie */
if toate voturile au fost YES then
WriteLog ( COMMIT )
send COMMIT tuturor participanților
else
WriteLog ( ABORT )
send ABORT tuturor proceselor care au votat YES
fi
return
end
2PC_participant :
begin
/* faza 1 */
wait REQUEST de la coordonator
if Votul_meu =NO then
WriteLog ( ABORT )
send NO la coordonator
else
WriteLog ( YES)
send YES la coordonator ;
Nici_o_decizie := adevărat
/* faza 2 */
while Nici_o_decizie do
begin
wait Mesaj_de_decizie de la coordonator ;
Nici_o_decizie := fals
exception
when timeout
do protocol de terminare
end
if Mesaj_de_decizie = COMMIT then
WriteLog ( COMMIT )
else WriteLog ( ABORT )
fi fi
return
exception
when timeout ;
WriteLog ( ABORT )
end
Protocolul de comitere în două faze necesită în total 3 n mesaje, dacă
numărul de participanți este n. Dezavantajul acestui protocol constă în faptul
că el este un protocol cu blocare, și anume există anumite situații în care un
nod operațional poate rămâne blocat fără a fi în stare să ia o decizie până când
nodurile defectate nu se restabilesc. Pentru a transforma acest protocol într –
unul fără blocare ( nonblocking protocol ), trebuie adăugată o stare tampon
după starea de așteptare. Se obține astfel protocolul de comitere în trei faze
(three -phase commit ), ale că rui automate de stare sunt prezentate în figura
4.26.
Noua stare p constituie o stare de pregătire ( prepare ) în vederea
comite rii. La acest protocol, după ce coordonatorul a primit mesaje favorabile
(YES i) de la toți participanții, le trimite ca răspuns mesaje de pregătire pentru a
comite ( PREP i) și trece în starea p0. Participantul care primește PREP i trece și el
în pi și dă o confirmare ( ACK i). Coordonatorul va trimite solicitările de comitere
(COMMIT i) numai după ce a primit toate confirmările. Odată ce un proces a
ajuns în starea p, el știe cu siguranță că va comite, în cazul lipsit de defectare.
Dacă însă apar defec tările unor noduri, atunci se poate arăta că nodurile
rămase pot lua o decizie referitoare la a comite sau nu, fără să aștepte
Figura 4.26. Grafurile automatelor de stare de la coordonator și participant
în cazul comiterii în trei faze
restabilirea nodurilor căzute. În orice caz se admite numai defectarea nodurilor,
deoarece nu poate exista nici un protocol fără blocare în condițiile unei rețele
de comunicație nefiabile. Aceasta ar putea duce la izolarea unui nod
operațional, care rămâne blocat în așteptare pentru aflarea deciziei finale.
4.4. Tratarea defectului și continuarea serviciului
După primele trei faze ale toleranței la un defect apărut în cadrul sistemului,
acesta a fost adus într -o stare lipsită de eroare, fără să fi fost eliminată însă
cauza care a condus la eroare, și anume defectul. Scopul ultimei faze de
toler anță este tocmai acela de a înlătura d efectul din sistem, astfel încât el să -și
poată relua îndeplinirea serviciului. Faza are două părți: tratarea defectului și
continuarea serviciului.
Trebuie făcută distincția între tratarea defectelor permanente și a celor
tranzitorii. În cazul unui defect tranzitoriu nu sunt necesare măsuri de eliminare
a defectului, acesta fiind considerat dispărut de la sine. Sistemul poate fi
repornit imediat după faza de restabilire din eroare. În schimb, în cazul unui
defect permanent se poate produce aceeași eroare d in nou dacă nu se
ident ifică și elimină componenta defectă.
În general capacitatea de toleranță la defecte permanente și tranzitorii se
poate studia pe graful de dependență (dependency graph ). Nodurile grafului
reprezintă obiectele software și resursele hardware, iar arcele orientate
corespund serviciilor pe care le solicită un obiect de la resurse sau alte obiecte.
Resursele sunt totdeauna noduri -frunză, deoarece se presupune că ele nu cer
servicii de la alte resurse.
Pentru tolerarea defectelor permanen te este adecvată utilizarea
redundanței fizice. Un exemplu este dat în figura 4.27, unde B1 și B2 reprezintă
alternative ale serviciului solicitat de obiectul A. În aceeași situație sunt C1 și C2,
iar resursa 2 este o alternativă redundantă pentru 1 și la fel 4 pentru 3. Se
observă că execuția obiectului A este tolerantă la un defect permanent,
deoarece în caz că defectul apare, se poate executa ramura cealaltă,
alternativă, care este disjunctă cu prima. La o analiză mai atentă a grafului, se
constată că re dundanța singură nu duce la toleranță, aceasta depinde și de
modul în care s -a făcut alocarea resurselor la obiecte. De exemplu, dacă s -ar fi
alocat B1 cu C2 și B2 cu C1, rezultatul ar fi fost o alocare 0 -rezistentă la defecte,
deoarece defectarea oricărei resurse făcea imposibilă execuția obiectului A prin
oricare alternativă de alocare. În general o alocare pentru execuția obiectului p
este n-rezistentă la defecte permanente dacă există cel puțin n+1 alternative de
alocare distincte a căror intersecții co nțin cel mult obiectul p. Cu această
condiție, fiecare alternativă se bazează pe servicii și resurse diferite,
prezentând astfel și o îngrădire completă a pagubelor față de celelalte
alternative.
Tolerarea defectelor tranzitorii se realizează uzual prin redundanță
temporală, ceea ce presupune execuția repetată a mai multor instanțe ale
aceluiași obiect, pe aceleași resurse. Un exemplu este dat în figura 4.28, unde
obiectele B și C sunt alocate cu redundanță temporală. Numărul de instanțe
distincte alocabile este limitat de regulă de constrîngeri de timp. De aceea,
când nu se mai poate asigura gradul de toleranță la defecte tran zitorii numai
prin redundanță temporală, se apelează la redundanță fizică și se utilizează o
altă alternativă de alocare. Rezultă deci următoarea condiție generală cu
referire la defectele tranzitorii: o alocare este n-rezistentă la defecte tranzitorii
dacă ea este k-rezistentă la defecte permanente și fiecare dintre cele k+1
Figura 4.27. Alocarea prin redundanță fizică pentru tolerarea
defectelor permanente
alternative de alocare ale sale are mi instanțe distincte de alocare (0 ik) astfel
încât:
1
0
n mk
ii
Pentru restabilirea stării lipsite de eroare în cazul defectelor tranzitorii
este adecvată utilizarea restabilirii înapoi, bazată pe redundanță temporală.
După restabilire execuția poate fi repetată din punctul de restabilire. În cazul
defectelor permanent e, în principiu se poate utiliza o restabilire înainte pe bază
de redundanță fizică , dar anterior continuării serviciului este necesară tratarea
defectului apărut.
Figura 4.28. Alocarea prin redundanță temporală pentru
tolerarea defecte lor tranzitorii
Tratarea defectului (fault treatment ) constă din două etape: localizarea
defectului și repararea sistemului.
Localizarea defectului (fault location ) urmărește identificarea
componentei defecte, metoda aleasă depinzând mult de specificul sistemului.
În orice caz localizarea este ajutată de fazele de detectarea erorii și evaluarea
pagubei, o estimare inițială asupra defectului fiind dată chiar de excepția
cauzată de eroare. Urmează apoi verificări de diagnoză asupra componentelor
suspecte p rintr -o tehnică de testare incorporată în sistem ( built -in testing ).
Aceasta poate lua forme diferite de la sistem la sistem, cum ar fi aplicarea
vectorilor de test dintr -o memorie ROM, analiza de semnături, programe de
autotestare pornind de la un miez de hardware ( hardcore ) considerat a fi
funcțional, teste de diagnoză asupra nodurilor vecine (în sistemele distribuite)
etc. Este de subliniat faptul că nu se urmărește identificarea defectului în
interiorul componentei (modulului), ci numai localizarea comp onentei defecte.
În urma identificării componentei defecte, aceasta trebuie împiedicată să
mai contribuie la furnizarea serviciului către utilizator. Rolul etapei de reparare
a sistemului (system repair ) este tocmai de a efectua reconfigurarea dinamică a
sistemului, astfel încât componenta defectă să nu mai fie utilizată și sistemul să
fie adus în stare de funcționare. O observație importantă este faptul că nu se
urmărește repararea unei componente defecte, ci înlăturarea acesteia, iar
acest lucru trebuie f ăcut on-line, adică fără intervenție manuală pentru a
asigura caracterul tolerant la defecte al sistemului.
Reconfigurarea sistemului presupune existența unei redundanțe
incorporate suficiente, cea mai simplă soluție fiind înlocuirea componentei
defecte cu o rezervă ( standby spare ). Aceasta trebuie să îndeplinească aceeași
funcțiune ca și componenta originală care a fost invalidată. Dacă nu există
rezerve, atunci în anumite situații se poate accepta o degradare a
performanțelor ( graceful degradation ). Acest lucru presupune că după
înlăturarea componentei defecte, restul componentelor să preia și funcțiile
sale, sistemul fiind în stare să îndeplinească numai sarcinile cruciale. În general,
în scopul de a putea efectua reconfigurarea sistemului, este necesară existența
unui anumit element sau chiar a unei rețele, de comutare.
După ce atât eroarea, cât și defectul au fost eliminate din sistem, poate fi
continuată furnizarea serviciului către utilizator. Continuarea serviciului
(continue service ) este posibilă în principiu dintr -un punct fix de repornire, dar
în mod normal se efectuează din punctul de restabilire, și anume din locul
indicat de handler -ul de excepție. După cum s -a arătat la punctul 4.3.6, reluarea
se poate face de la nivelul obiectului software î n care s -a detectat eroarea sau
de la un nivel superior, în cazul din urmă fiind necesară însă gestionarea
corespunzătoare a tuturor obiectelor apelate și neterminate.
Într-un sistem de calcul tolerant la defecte, implementarea toleranței
presupune, așa cum s -a văzut, pe lângă existența de resurse redundante și
parcurgerea unor faze din momentul punerii în evidență a erorii până la
continuarea normală a serviciului. Este de dorit ca efectul sesizat de utilizator
ca urmare a acestor activități să fie m inim, acesta fiind rezumat doar la o mică
discontinuitate a funcționării (o întârziere) și eventual o scădere a
performanțelor. Sistemul trebuie să fie însă capabil de satisfacerea cerințelor
impuse.
5. FIABILITATEA, MENTENABILITATEA ȘI DISPONIBILITATEA
5.1. Definiția fiabilității
Într-un sens mai larg, fiabilitatea poate fi considerată o parte
componentă a calității unui produs. Calitatea unui produs se exprimă printr -un
set de descriptori care conțin mărimi referitoare la caracteristicile fizice ale
acestuia și atribute care arată în ce măsură produsul corespunde cerințelor
utilizatorului. Aceste atribute funcționale duc la luarea unei decizii de tip
„go/no go” asupra produsului, în sensul că el este considerat acceptabil sau
deficient. În context calitativ, fiabilitatea reprezintă o măsură a cum produsul
îndeplinește specificațiile impuse de funcționare pe o anumită perioadă de
timp. Caracteristica studiată de teoria fiabilității o reprezintă durata de viață a
produsului aflat în exploatare, exprimând conservarea în timp a performa nțelor
produsului sub forma unei calități dinamice.
În sens mai restrâns, fiabilitatea este o mărime cantitativă care exprimă
probabilitatea ca un produs să fie operațional. Prin produs se poate înțelege o
componentă singulară, un sistem compus din mai mu lte componente sau chiar
un program de calculator. Analiza de fiabilitate ține cont de apariția unor
evenimente neanticipate și nedorite în cursul exploatării produsului, care au
influență asupra comportării sale. Aceste evenimente pot fi defectări ale
com ponentelor sau modificări ale parametrilor acestora în afara limitelor
admisibile, cauzate de condițiile de mediu sau uzură, precum și probleme de
proiectare și tehnologice care ies la iveală în timpul utilizării. Problema de fond
o constituie faptul că do uă produse identice care lucrează în condiții similare nu
se defectează de regulă în același moment. Acest fenomen poate fi descris
numai în termeni probabilistici. Durata de viață utilă (sau timpul până la
defectare) constituie o variabilă aleatoare T , a cărei lege probabilistică se
poate exprima în mai multe feluri. Este de subliniat faptul că în această
accepțiune produsul este caracterizat printr -o comportare bivalentă, cu două
stări: funcționează sau este defect. Starea defectă semnifică faptul că el n u este
în stare să satisfacă funcțiile cerute.
Fiabilitatea R(t) (reliability ) a unui produs (componentă sau sistem) se
definește ca fiind probabilitatea ca acesta, lucrând în condiții date de mediu,
să-și îndeplinească adecvat funcțiile specificate pe d urata unui interval dat de
timp [0, t]:
R(t) = Pr(T>t) (5.1)
Se observă că definiția fiabilității presupune următoarele aspecte:
Admiterea posibilității de defectare, adică a unei noțiuni probabiliste
Acceptarea unui nivel de performanță preciza t de proiectant sau de
utilizator
Exploatarea produsului în condiții de funcționare prescrise
Funcția R(t) se mai numește funcție de supraviețuire în cazul sistemelor
monotone, caracterizate prin ireversibilitatea defectărilor.
Legea de defectare probabilistă a unui produs se exprimă adesea prin
funcția de distribuție cumulată F(t), definită prin probabilitatea ca produsul să
funcționeze cel mult până în momentul t:
F(t) = Pr(Tt) (5.2)
Aceasta mai este referită ca funcția de defectare sau de nefiabilitate
(unreliability ), fiind complementară funcției de fiabilitate:
F(t) = Pr(Tt) = 1Pr(T>t) = 1R(t) (5.3)
Pe baza acestei definiții și având în vedere faptul că la momentul inițial
produsul este cu certitudine funcțional , F(t) este o funcție monotonă
nedescrescătoare astfel încât F(0)=0 și
1)( lim
tF
t . Ca urmare a relației ( 5.3)
rezultă imediat că R(0)=1 și
0)( lim
tR
t .
Caracterizări statistice ale duratei de viață sunt date de timpul mediu
până la defectare MTTF (Mean Time To Failure ) și de dispersia relativă a
timpului de defectare RFTD (Relative Failure Time Dispersion ). Fiind cunoscută
legea de distribuție pentru T, MTTF se calculează ca valoarea așteptată
(expected value ), adică media variabilei aleatoare,
MTTF = m = E[T] (5.4)
iar RFTD reprezintă deviația standard a lui T raportată la media sa (adică
coeficientul de variație al variabilei aleatoare):
]E[]) E[( σ2
TmT
mRFDT
(5.5)
Prin deviație standard (standard deviation ) sau abaterea medie pătratică
a variabilei aleatoare se înțelege rădăcina pătrată a dispersiei sau varianței
(variance ), care caracterizează gradul de împrăștiere a valorilor variabilei
aleatoare în jurul valorii medii:
]) E[( σ] Var[2 2mT T
(5.6)
Este de remarcat faptul că atât MTTF , cât și RFTD , reprezintă
caracteristici ale repartiției timpului de defectare T, fiind independente de
timpul de observare t. Timpul de misiune (mission time ) al unui produs nu
trebuie confundat cu durata de viață a acestuia, ci acesta reprezintă durata
maximă TMAX pentru care fiabilitatea produsului respectă o limită specificată
RMIN, adică pentru tTMAX funcția de fiabilitate R(t)RMIN.
Întrucât prezentul curs abordează probleme de fiabilitate ale sistemelor
de calcul, se va trata în continuare pe lângă cazul distribuției de tip continuu a
timpului de defectare și cazul distribuției discrete. Acest lucru este justificat de
faptul că procesoarele au o funcți onare compusă din cicluri instrucțiune, care
pot fi considerate ca segmente discrete de timp.
5.2. Fiabilitatea în spațiul timpului continuu
În acest caz variabila aleatoare T corespunzătoare momentului de
apariție a defectului poate lua orice valoare pe axa timpului t0.
Admițând că F(t) constituie conform (2.2) probabilitatea ca variabila
aleatoare să ia valoare mai mică sau egală cu t, legea de repartiție a variabilei
aleatoare se exprimă adesea prin viteza instantanee de defectare f(t). Aceasta
reprezintă probabilitatea de defectare pe unitatea de timp, adică:
dttdF
ttFttFttT ttT
tttTttf
tt t
)( )( ) (lim ) Pr() Pr(lim) Pr(lim)(
00 0
(5.7)
În termeni probabilistici, funcția f(t)0 se numește funcția de densitate de
probabilitate (probability density function, p.d.f. ) și are proprietatea:
01 )(dttf
(5.8)
Este de menționat faptul că f(t) nu este o probabilitate, însă cantitatea
f(t)dt este interpretată ca element de probabilitate. Pe baza celor prezentate,
rezultă că funcția de distribuție cumulată (CDF, cumulative dis tribution
function ), o funcție continuă, se exprimă ca
t
duuf tF
0)( )(
(5.9)
și pe grafic reprezintă aria de sub curba de densitate până la abscisa
considerată (figura 2.1). Pe baza complementarității exprimată de relația ( 5.3),
este ev ident că aria din dreapta corespunde fiabilității R(t):
tduuf tR )( )(
(5.10)
De asemenea, se verifică imediat și egalitățile:
f(t) = F'(t) = R'(t) (5.11)
Figura 5.1. Interpretarea grafică a unor indicatori de fiabilitate
Fiind dat f(t), probabilitatea ca variabila aleatoare să aparțină intervalului
t1, t2 se poate calcula prin integrare:
2
1)( )( )( ) Pr(1 2 2 1t
tdttf tF tF tTt
(5.12)
Probabilitatea ca variabila aleatoare să ia o anumită valoare, deci ca defectarea
să aibă loc la un anumit moment de timp este însă zero, deoarece:
1
10 )( ) Pr() Pr(1 1 1t
tdttf tTt tT
De aici rezultă și egalitățile:
) Pr() Pr() Pr() Pr(2 1 2 1 2 1 2 1 tTt tTt tTt tTt
Există încă o posibilitate de caracterizare a legii la care se supune timpul
până la defectare, utilizând probabilități cond iționate. Din teoria
probabilităților este cunoscută formula de calcul a probabilității producerii unui
eveniment A, cu condiția ca să se producă și evenimentul B:
) Pr() Pr()| Pr(BBABA
Aici A semnifică evenimentul „sistemul se defectează în intervalul [t, t+t)”, iar
B evenimentul „sistemul funcționează până în momentul t”. Ca urmare,
Pr(AB=F(t+t)F(t), iar Pr(B)=1F(t). Prin definiție, funcția de hazard (hazard
function ) z(t) reprezintă probabilitatea de defectare pe unitatea de timp la
momentul t, cu condiția ca să nu fi apărut defecțiunea până la momentul t,
deci:
)()(
)()(
)( 1)(
)( 1)( ) (1lim)(
0 tRtf
tRtR
tFtF
tFtFttF
ttz
t
(5.13)
Funcția de hazard reprezintă o densitate de probabilitate condiționată și în
context fiabilistic se mai numește rata de defectare (failure rate ) sau
intensitatea de defectare . Cantitatea z(t) nu are semnificație grafică clară pe
figura 5.1, fiind ordonata împărțită la aria din dreapta sa.
Se poate constata că fiind dat oricare din indicatorii de fiabilitate f(t), F(t),
R(t) sau z(t) pentru a caracteri za repartiția timpului de defectare, ceilalți trei se
pot deduce din acesta:
Cazul 1. Dacă este dat f(t), ceilalți indicatori se calculează astfel:
t
duuf tF
0)( )(
(5.14)
)( 1 )( )( tF duuf tR
t
(5.15)
)()()(tRtftz
(5.16)
Cazul 2. Dacă este dat F(t), atunci:
f(t) = F'(t) (5.17)
R(t) = 1F(t) (5.18)
)( 1)()(tFtFtz
(5.19)
Cazul 3. Fiind dat R(t), relațiile de calcul pentru ceilalți indicatori sunt:
F(t) = 1R(t) (5.20)
f(t) = R'(t) (5.21)
)()()(tRtRtz
(5.22)
Cazul 4. Când este dat z(t) calculul este mai greu, R(t) fiind obținut ca soluția
unei ecuații diferențiale:
duuzuRduuR)()()(
Prin integrarea membrului stâng, ținând cont că R(0)=1, se obține
)(ln)0(ln)(ln0)(ln tR R tRtuR
de unde rezultă:
)()(
)(0 tZeduuz
etRt
(5.23)
Relația ( 5.23) este cunoscută și ca formula exponențială a fiabilității . Funcția
Z(t) se numește funcția de hazard cumulată (cumulative hazard function ) și se
poate scrie ca și o funcție de supraviețuire logaritmică:
Z(t) = ln R(t)
Celelalte două relații de calcul rezultă imediat, și anume:
)(1)(tZe tF
(5.24)
)()()(tZetztf
(5.25)
În afară de cei patru indicatori de fiabilitate menționați mai sus, în
practică este convenabil să se lucreze cu valoarea medie și dispersia variabilei
aleatoare T. Valoarea medie, adică MTTF , reprezintă conform ( 5.4) valoarea
așteptată a lui T și se calcu lează cu formula mediei:
0dtttf T m )( ]E[ (5.26)
TEOREMA 5.1. Timpul până la defectare fiind o variabilă aleatoare
continuă, media ei ( MTTF ) este dată de aria de sub curba de fiabilitate, adică:
0)(dttR m MTTF
(5.27)
Demonstrație. Înlocuind relația ( 5.11) în ( 5.26), se obține:
0 0)( )( ttdR dtttf
Se recurge la integrarea prin părți, notând u=t, dv=dR(t), du=dt, v =R(t). Rezultă:
0 0 0 0)( )0(0)( lim )( )( )( dttR R ttR dttR ttRttdR
t
Știind că R(0)=1, iar
01)(lim
ttR
t deoarece se poate admite că R(t) tinde mai
repede către 0 decât 1/ t atunci când t pentru distribuțiile uzuale, se obține
rezultatul căutat:
0 0)( )( dttR dtttf
ٱ
Dispersia (varianța) variabilei aleatoare este dată conform ( 5.6) de
valoarea așteptată a pătratului abaterii:
2 2
02
002
02 2 2
] E[ )( )( 2 )( )() ( ]) E[(
m T dttf mdtttfmdttft dttfmt mT
(5.28)
În evaluarea expresiei precedente s -a ținut cont de ( 5.8) și ( 5.26).
5.3. Distribuții de fiabilitate
5.3.1.Distribu ții de tip continuu
Dintre legile de distribuție continue cu aplicație în teoria fiabilității, se
amintesc aici:
Distribuția exponențială negativă, cu rata constantă a defectărilor:
z(t) = = constant (5.29)
Distribuția normală (Gauss), utilă în prelucrări statistice, fiind caracteristică
mediei unui eșantion de n variabile independente și care are funcția de
densitate:
22
σ2) (
π2σ1)(mt
e tf
(5.30)
Distribuția Weibull , care are funcția de densitate:
β
θ1β
θθβ)(
t
ettf
(5.31)
Aceasta este cea mai des utilizată distribuție parametrică, > 0 fiind un
parametru de scară, iar > 0 un parametru de formă. Dacă < 1 atunci z(t)
scade, dacă = 1 atunci z(t) este constant (distribuția este exponențială), iar
dacă > 1 atunci z(t) este crescătoare.
Distribuția Rayleigh , cu rata liniar crescăto are a defectărilor, fiind un caz
particular al distribuției Weibull pentru = 2.
Distribuția gamma , cu funcția de densitate
)()(
t
et
tf1
(5.32)
unde > 0 este un parametru de formă, iar > 0 parametru de scară. Funcția
gamma este definită prin:
01dtett α)(
care pentru întreg dă () = (1)!. În cazul în care =1 se obține distribuția
exponențială negativă.
Distribuția χ2, numită și Pearson , este distribuția pătratelor mai multor
variabile aleatoare normale. Dacă T1, T2, …, Tn reprezintă n variabile aleatoare
independente, fiecare cu distribuție normală de parametri (0, σ), atunci
variabila aleatoare
n
iiT T
12 va avea o distribuție χ2 cu ν = n–1 grade de
libertate, funcția de densitate fiind dată de:
22σν
2ν
νννσ)(
et tf1
2
221
(5.33)
De obicei se tabelează valorile
)(χ2
α , unde α reprezintă valoarea riscului, adică
Pr(T>
)(χ2
α ) = α. Această lege de distribuție se folosește în fiabilitate îndeosebi
pentru verificarea concordanței dintre rezultatele experimentale și ipotezele
teoretice.
5.3.2. Distribuții fără memorare
Comportarea ratei de defectare (a funcției de hazard) a unei componente
în funcție de timp, numită și caracteristică de viață sau curbă de mortalitate,
are aspectul de „cadă de baie” ( bathtub curve ) din figura 5.4. Curba prezintă
trei zone distincte. Prima perioadă (A), de rodaj ( burn -in) sau mortalitate
infantilă ( infant mortality ), pune în evidență defecțiunile precoce, cu o r ată de
defectare în scădere. Porțiunea B reprezintă viață utilă ( useful life ), cu rata de
defectare considerată constantă, iar etapa finală (C) prezintă creșterea ratei de
defectare corespunzătoare uzurii ( wear out ) și îmbătrânirii. Este de menționat
faptu l că pentru produse reparabile, curba nu mai prezintă zona cu rata de
defectare constantă.
Figura 5.4. Caracteristica de viață a unei componente
Curba se poate descrie matematic cu o funcție polinomială de forma
ctctz2
1)(
, unde c1>0, iar pentru c2<0 se obține funcția de hazard
descrescătoare, pentru c2=0 constantă și pentru c2>0 crescătoare. Notând
c1= și c2=1 se obține forma cunoscută a funcției de hazard pentru
distribuția Weibull:
z(t) = t1 (5.34)
Funcția de repartiție și densitatea de probabilitate sunt date, ca urmare a
relațiilor ( 5.24) și ( 5.25) de:
teduu
e tFt
1 1)(01
(5.35)
tet tf1)(
(5.36)
Distribuția exponențială. Pentru activitatea practică prezintă interes
zona B a caracteristicii, care corespunde vieții utile a unei componente a unui
sistem. Este de subliniat însă faptul că, în funcție de modul în care sunt
interconectate componentele sistemului pentru a asigura funcționalitatea
acestuia, nu va rezulta neapărat o funcție de hazard constantă și pentru sistem.
Rata de defectare constantă se obține pentru cazul particular când parametrul
distribuției Weibull se ia =1. În acest caz, pe baza relațiilor precedente,
rezultă:
z(t) = = constant (5.37)
F(t) =1e t (5.38)
R(t) = e t (5.39)
f(t) = e t (5.40)
Legea de repartiție caracterizată prin funcțiile ( 5.37–5.4„) constituie o
distribuție (negativ) exponențială (negative exponential distribution ), cea mai
frecvent utilizată distribuție de tip continuu în teoria fiabilității, fiind singura
care prezintă o rată de defectare constantă. Curba funcției de fiabilitate are
forma din figura 5.5. Timpul mediu până la defectare ( MTTF) se calculează
conform ( 5.27) ca fiind:
MTTF = E[T] =
1
0dtet (5.41)
Figura 5.5. Graficul funcției de fiabilitate pentru o
distribuție exponențială
Distribuția exponențială este adecvată pentru a modela comportarea
componentelor (inclusiv cele electronice), care dacă sunt bune se consideră ca
și cum ar fi noi ( used -good -as-new ). Acest lucru se datorează proprietății de a
nu ține cont de evoluția trecută, ceea ce rezultă din următoarea teoremă :
TEOREMA 5.2. În cazul unei distribuții exponențiale a timpului până la
defectare, F(t) = 1e t, (t 0), timpul așteptat până la următoarea defectare
este 1/ indiferent de momentul în care se începe observarea.
Demonstrație. Conform ipotezei, F(t) = Pr( T t) = 1e t. Pornind observarea
de la t=0, timpul mediu până la defectare este 1/ , conform ( 5.41).
Presupunând că până la noul moment de observare t=x nu a apărut defectarea,
distribuția timpului rămas până la defectare este Pr( TxtT>x). Aceasta este o
probabilitate condiționată de faptul ca defectarea să nu fi apărut până în acest
moment, care se calculează cu formula Pr( AB) =
BBA
Pr) Pr( :
)( 1) 1( ) 1() 1( ) Pr() Pr() Pr(
) Pr() Pr() | Pr(
) (
tF e
ee e
ee exTxT txT
xTtxTxxTtxT
t
xt x
xx tx
S-a obținut aceeași distribuție ca pentru situația t=0, media variabilei aleatoare
fiind și aici 1/ .
Datorită acestei proprietăți de a fi fără memorarea trecutului
(memoryless property ), în perioada duratei de viață cu rata constantă a
defectărilor, componentele se defectează nu din cauza uzurii, ci din cauza unor
influențe externe care apar într -o manieră Poisson. De exemplu, un
microprocesor va cădea datorită unui supracurent și nu a uzurii. Asemenea
defectări sunt accidentale, aleatoare, corespunzătoare unei funcționări
normale. Un proces Poisson creează puncte regenerativ e, proprietate
exploatată de programele de evaluare a fiabilității și performanțelor prin
simulare.
5.4. Mentenabilitatea
În capitolele precedente defectările produselor au fost considerate
ireversibile, un produs defect fiind declarat inutilizabil în continuare. Realitatea
practică impune însă și admiterea repunerii în funcțiune a anumitor produse
după apariția unei defecțiu ni. Aceste sisteme se numesc reparabile sau cu
reînnoire. Se impune în acest caz interpretarea noțiunii de fiabilitate într -un
sens mai larg, și anume acela ca sistemul să -și îndeplinească sarcinile inclusiv
prin capacitatea de refacere a performanțelor du pă o defectare. Totalitatea
acțiunilor necesare pentru menținerea sau restabilirea stării de funcționare a
produsului constituie mentenanța. Mentenanța poate fi preventivă sau
corectivă, după cum ea urmărește întreținerea, respectiv reparația sistemului.
Mentenabilitatea reprezintă din punct de vedere calitativ aptitudinea
produsului de a fi repus în stare de funcționare prin operația de mentenanță.
Sub aspect cantitativ, mentenabilitatea se exprimă prin funcția de
mentenabilitate.
Funcția de mentenabili tate M(t) ( maintainability ) este
probabilitatea ca prin operația de mentenanță efectuată în condiții date
produsul defect să fie repus în funcțiune până la momentul t considerat:
M(t) = Pr( t > Tr) (5.42)
În relația ( 5.42) Tr reprezintă timpul de reparație, care este o variabilă
aleatoare.
Un alt indicator de mentenabilitate este densitatea de probabilitate a
timpului de reparație , dată de derivata funcției de mentenabilitate
)()()( tMdttdMtfr
(5.43)
iar rata de reparație (repair rate )se obține pe baza formulei:
)( 1)()(tMtMt
(5.44)
Relația ( 5.44) se poate scrie și sub forma unei ecuații diferențiale:
dtttMtdM)()( 1)(
Prin integrare, ținând cont și de faptul că M(0)=0, se obține:
ttduu uM
00)(μ )( 1ln |
t
duu tM
0)( )( 1ln
Soluția ecuației, adică expresia funcției de mentenabilitate dacă se cunoaște
rata reparațiilor, este dată de următoarea formulă exponențială:
t
duu
e tM01)(
)(
(5.45)
Un indicator practic es te timpul mediu de reparație (Mean Time To
Repair ), prescurtat MTTR . Acesta se poate calcula ca și valoarea așteptată a
timpului de reparație, adică:
dtttf T MTTRr r
0)( ]E[
(5.46)
În cursul vieții sale un produs reparabil trece prin mai multe cicluri de
defectare -restabilire, așa cum este ilustrat sugestiv în figura 5.6. Bineînțeles că
timpii până la defectare, respectiv reparație nu sunt identici între ei, fiind
variabile aleatoare , pe desen fiind trecute valorile medii. De pe figură se poate
deduce relația cu care se poate exprima timpul mediu dintre defectări MTBF
(Mean Time Between Failures ) în funcție de MTTF și MTTR :
MTBF = MTTF + MTTR (5.47)
În practică de reg ulă durata reparațiilor este neglijabilă față de cea de bună
funcționare ( MTTR << MTTF ), deci se poate considera MTBF MTTF .
Figura 5.6. Ciclurile de defectare -restabilire în timpul vieții unui produs
Caz particular. În situația în care se admite că rata de reparație a
produsului este constantă, adică (t) = = constant, expresia de calcul a
funcției de mentenabilitate ( 5.45) devine:
te tMμ )(1
(5.48)
Forma grafică a acestei funcții este arătată î n figura 5.7. Distribuția timpului de
reparație va fi exponențială, densitatea de distribuție fiind, conform ( 5.43):
t
r e tfμ μ)(
(5.49)
Media timpului de reparație este dată în cazul distribuției exponențiale de
inversul ratei de reparație, deoarece în conformitate cu relația ( 5.46) se poate
scrie:
μ μμ μ μ μ μ 1 1
0
0 00
0
| |t t t t te dte te tde dtte MTTR
(5.50)
Figura 5.7. Funcția de mentenabilitate în cazul
unei distribuții exponențiale
În general rata de reparație se specifică separat pentru diferite niveluri
de mentenanță. Astfel, ea poate fi considerată la nivel organizațional, adică la
locul de exploatare al sistemului, unde reparația constă de regulă în
schimbarea modulului defect. L a nivelul intermediar rata de reparație este mai
mică, fiind necesară identificarea și înlocuirea piesei defecte pe modul. Dacă
aceste operații necesită trimiterea modulului la fabricant, atunci rezultă un
MTTR mare.
5.5. Disponibilitatea
Fiabilitatea , ca și mărime cantitativă, se referă la un interval de timp în
care sistemul trebuie să funcționeze fără defectare. În anumite situații însă este
mai important ca un sistem, de exemplu un calculator, să fie în stare de
funcționare la un anumit moment de t imp, când este nevoie de el. Cu alte
cuvinte sistemul trebuie să fie disponibil utilizatorului, fără să intereseze
istoricul duratelor de funcționare si de reparație. Mărimea care caracterizează
această proprietate a sistemelor reparabile este disponibilit atea.
Disponibilitatea A(t) (availability ) a unui sistem este probabilitatea ca
sistemul să fie în stare de funcționare la momentul t, indiferent de istoricul său
de defectări și reparații:
A(t)=R(t) + [1 R(t)] M(tr) = R(t) + F(t) M(tr) (5.51)
În relația ( 5.51) primul membru se referă la funcționarea fără defectare
până la momentul t, iar al doilea corespunde situației când a apărut o defectare
care a fost reparată în timpul de reparație permis tr. Disponibilitatea exprimată
sub forma acestei re lații se mai numește disponibilitatea misiunii . Se poate
constata faptul că, pentru ca sistemul să aibă o disponibilitate ridicată,
problema depanării cât mai rapide în caz de defectare devine esențială.
Admițând posibilitatea defectării la orice moment 0, t și repararea în
intervalul elementar ( , +d), funcția de disponibilitate se poate exprima sub
forma:
t
dh tR tRtA
0)() ( )( )(
(5.52)
În această relație R(t) constituie probabilitatea ca sistemul să nu se defecteze în
intervalul [0, t , adică fiabilitatea sa. Presupunând că a apărut totuși o defectare
la momentul τ, factorul h(τ)dτ reprezintă probabilitatea de reînnoire în
intervalul (τ, τ + dτ), iar R(tτ) este probabilitatea de a nu se mai defecta în
intervalul (τ, t). Prin prisma dis ponibilității, ceea ce s -a întâmplat înainte de
momentul τ, și anume câte defectări -reînnoiri au avut loc, nu are importanță.
Însumarea acestor probabilități pe tot intervalul [0, t conduce la integrala din
membrul drept al relației ( 5.52).
Funcția h(t) reprezintă densitatea de probabilitate a reînnoirilor. Pentru a
o exprima trebuie să se studieze comportarea sistemului, care decurge conform
figurii 5.9. Timpul până la defectarea i este notat cu xi, cel până la reînnoirea i
cu yi, astfel încât timpul dintre două restabiliri este zi=xi+yi. Intervalul de timp cu
durata aleatoare T+Tr dintre două reînnoiri consecutive este distribuit, conform
distribuției sumei de variabile aleatoare independente, cu densitatea de
probabilitate dată de convoluția densităților corespunzătoare:
t
r r duutfuf tftftg
0) ()( )( )( )(
Figura 5.9. Comportarea unui sistem cu reînnoire
Expresia lui h(t) este dată de ecuația reînnoirii :
t
d tgh tgtgthtgth
0) ()( )( )()()( )(
(5.53)
Primul termen al formulei corespunde cazului când la momentul t are loc prima
reînnoire, iar al doilea situației când la momentul [0, t a avut loc ultima
reînnoire înainte de momentul t. Interpretarea grafică, pe care s -au trecut
densitățile corespunzăt oare, este dată în figura 5.10.
Figura 5.10. Interpretarea grafică a ecuației reînnoirii
Elementul de probabilitate h(t)dt reprezintă probabilitatea producerii
unei reînnoiri în jurul momentului t, indiferent de ordinul acesteia (prima, a
doua sau de oricare alt ordin). Notând cu H(t) funcția de reînnoire , ca fiind
numărul mediu de reînnoiri în intervalul [0, t, densitatea de probabilitate a
reînnoirilor este dată de derivata acestei funcții, și a nume:
dttdHth)()(
(5.54)
Dacă variabila aleatoare Tn reprezintă timpul până la a n-a reînnoire, având
funcția de distribuție
Kn(t) = Pr( Tn < t)
și Nt este egal cu numărul de reînnoiri din intervalul [0, t, atunci conform
formulei mediei funcția de reînnoire va fi:
1 1 11 11 1
)( )( )( ) Pr() Pr( )1 Pr() Pr( ) Pr( )(
n nn
nn n n nnt t
nt
tK t KtKn t T tTnn N n N n n Nn tH
Rezultă că
h(t) =
1)(
nntk (5.55)
kn(t) fiind densitatea de probabilitate a variabilei aleatoare Tn. Având în vedere
faptul că Tn la rândul lui este o sumă de variabile alea toare, adică Tn = z1 + z2 +
… + zn (figura 5.11), kn(t) se poate exprima sub forma produsului de convoluție:
nn tg tgtgtk )( )()( )(
Aplicând transformata Laplace acestei egalități rezultă relația
n
n sg sk )( )(* *
astfel încât pe baza ( 5.55) se poate scrie:
)( 1)()( )(**
1* *
sgsgsg sh
nn
(5.56)
Se observă imediat că relația obținută corespunde tocmai ecuației înnoirii,
scrisă sub forma transformatei Laplace.
Figura 5.11. Reprezentarea timpului aleator până la a n -a înnoire (Tn)
Pentru evaluarea disponibilității, scriind transformata Laplace a lui A(t)
dat de ( 5.52) rezultă:
A*(s) = R*(s) + h*(s)R*(s) (5.57)
Expresia lui h*(s) este dată de ( 5.56), iar R*(s) se calculează în felul următor:
ssf
ssf
sduuf duuf sR* *
t* )( 1)( 1)( 1 )( )(
0
L L
Înlocuind în ( 5.57) și ținând cont de faptul că g*(s) = f*(s) fr*(s), se obține:
)()( 1)( 1
)()( 1)()(1)( 1)(* **
* ** * *
*
sfsf ssf
sfsfsfsf
ssfsA
r rr
(5.58)
Trecând la limită pentru t→∞, pe baza relației ( 5.58) se obține
disponibilitatea staționară (steady -state availability ):
MTTR MTTFMTTFssA tA A
s ts
)( lim)( lim*
0
(5.59)
Mărimile MTTF și MTTR reprezintă, așa cum s -a mai arătat timpul mediu până
la defectare, respectiv timpul mediu de reparație. Pentru a se ajunge la această
relație trebuie luate în considerare câteva elemente. Se cunoaște că MTTF se
poate calcula cu relația
0*
0)( lim )( sR dttR MTTF
s
care, având în vedere că
)( 1)0( )()( )( 1)( ssR RssRdttdR
dttR dsf* * * L L
se mai poate scrie:
ssfMTTF
s)( 1lim*
0
(5.60)
În mod similar:
ssfMTTRr
s)( 1lim*
0
(5.61)
Pentru a calcula numitorul relației ( 5.59) trebuie evaluată limita
MTTF MTTRsfsRssf
ssfssR
ssfsf
rr
sr
sr
s
)()()( 1lim)()( 11lim)()( 1lim* **
0* *
0* *
0
unde s -a ținut cont că
1)( )( )( lim
0*
0
Mdttf sfr rs . Pe baza acestor
rezultate, trecând la limită în expresia ( 5.58) a disponibilității, se obține relația
căutată ( 5.59) pentru As.
Este important de menționat, că relația de calcul ( 5.59) a disponibilității
staționare este o expresie independentă de legile de distribuție a timpilor de
defectare și de reparație. În cazul unor distribuții exponențiale a acestor timpi,
pentru disponibilitatea staționară (numită și coeficient de disponibilitate ) se
obține formula uzuală:
λμμ
μ1
λ1λ1
sA
(5.62)
5.6. Funcția de structură a sistemelor bivalente
Problema centrală a teoriei fiabilității constă în studiul fiabilității
sistemelor pe baza fiabilității componentelor. Pentru aceasta sunt necesare
modele matematice care captează simultan relațiile logice și structurale dintre
componentele sistemului, pre cum și evenimentele aleatoare de tipul
defectărilor componentelor. Un astfel de model, general valabil, este
descrierea sistemului cu funcția de structură. Pentru a o defini, trebuie
formulate în prealabil următoarele ipoteze:
1. Sistemul are numai două st ări posibile: funcțional sau defect.
2. Sistemul poate fi descompus în n componente, astfel încât la un
moment dat fiecare componentă se poate afla într -una din stările
funcțională sau defectă. Starea sistemului depinde numai de stările
componentelor sale.
3. Fiecare componentă ci (i = 1, 2, …, n) a sistemului posedă o durată de
viață aleatore Ti, căreia îi corespunde câte o funcție de fiabilitate Ri(t):
Ri(t) = Pr( Ti >t) (i = 1, 2, …, n)
4. Variabilele aleatoare Ti sunt independente.
Sistemul astfel considerat, în care atât componentele, cât și sistemul pot
avea numai două stări, este un sistem bivalent . La un moment dat t, o
componentă ci are probabilitatea pi de a fi în stare funcțională, respectiv
probabilitatea qi de a fi defectă, astfel încât:
pi = Ri(t) (5.63)
qi = 1 pi = Fi(t) (5.64)
În relația precedentă Fi(t) reprezintă funcția de distribuție cumulată a
timpului până la defectare pentru componenta ci, conform unei anumite legi de
distribuție. Fiecărei componente i se asociază o variabilă aleatoare Bernoulli,
adică o variabilă binară xi, care reprezintă starea componentei ci la un
momentul t, astfel încât prin convenție:
xi =
defectă este dacă ă funcțional este dacă
ii
cc
01
Rezultă imediat că:
pi = Pr( ci este bună) = Pr( xi=1) = E[xi] (5.65)
Se numește funcție de structură (structure function ) a unui sistem
bivalent cu n componente, o funcție n {0,1} indicatoare a stării
sistemului în funcție de stările componentelor sale, astfel încât:
(x1, x2, …, xn) =
defect este sistemul dacă 0 funcțional este sistemul dacă 1
Relația dintre funcția de structură și fiabilitatea sistemului este dată de:
R = Pr(sistemul este bun) = Pr( =1) = E[] (5.66)
Cu alte cuvinte funcția de fiabilitate a unui sistem este egală cu valoarea
așteptată (media) funcției sale aleatoare de structură.
Este de subliniat faptul că funcția de structură a unui sistem bivalent
poate fi exprimată în funcție de variabilele sale, atât sub formă booleană cât și
algebrică. Acest lucru este posibil, deoarece pe mulțimea {0,1} se consideră atât
structura de algebră Boole, cât și cea de corp comutativ. Pentru a evita
confuziile ulterioare, se ilustrează pe u n exemplu faptul că funcția de fiabilitate
se poate exprima pornind de la ambele reprezentări ale funcției de structură.
Exemplu
Fie sistemul cu trei componente, interconectate din punct de vedere al
fiabilității conform figurii 5.12. Condiția ca sistem ul să fie operațional este ca să
funcționeze componenta c1, precum și una din componentele c2 sau c3. (Acest
caz ar putea fi întâlnit la un calculator cu un CPU și două unități de memorie.)
Corespunzător, definiția tabelară a funcției de structură este c ea din tabelul
5.12. Considerând pe ca o funcție booleană, din tabel se obține forma ei
disjunctivă:
31 21 321 321 321 xx xxxxxxxxxxx
(Pentru simplitatea scrierii, fără a afecta însă înțelegerea, s -a omis operatorul
, deci în loc de
321xxx se va subînțelege
3 2 1 x xx ș.a.m.d.). Aceeași
funcție se poate exprima și sub formă algebrică, folosind operațiile de adunare
și înmulțire:
= x1[1(1x2)(1x3)] = x1x2 + x1x3 x1x2x3
x1 x2 x3
0 0 0
0 0 1
0 1 0
0 1 1
1 0 0
1 0 1
1 1 0
1 1 1 0
0
0
0
0
1
1
1
Figura 5.12. Exemplu de sistem Tabelul 5.12. Funcția de structură
cu trei componente tabelară corespunzătoare fig. 3.1
Un sistem cu n componente implică existența a 2n vectori care formează
mulțimea stărilor componentelor. Între doi vectori de stare X = (x1, x2, …, xn) și Y
= (y1, y2, …, yn) se poate defini o relație de ordine astfel:
X = Y dacă și numai dacă xi = yi i = 1, 2, …, n
X Y dacă și numai dacă xi yi i = 1, 2, …, n
X > Y dacă și numai dacă xi > yi i = 1, 2, …, n
Un sistem cu funcția de structură este monoton sau coerent (coherent
system ) dacă pentru orice pereche de vectori de stare sat isface proprietatea că
X Y implică:
(X) (Y) (5.67)
Pentru ca un sistem să fie coerent, trebuie să fie îndeplinite următoarele
două condiții:
1. (X) este nedescrescătoare pentru fiecare din variabilele sale, deci
pentru oricare i este respectată relația:
(x1, …, xi1, 1, xi+1, …, xn) (x1, …, xi1, 0, xi+1, …, xn)
2. Fiecare componentă este relevantă , adică pentru orice i există o
combinație ( x1, x2, …, xi1, , xi+1, …, xn) pentru care este adevărată
inegalitatea:
(x1, …, xi1, 1, xi+1, …, xn) > (x1, …, xi1, 0, xi+1, …, xn)
Cu alte cuvinte, un sistem este coerent dacă defectarea oricăreia din
componentele sale nu poate duce la restabilirea stării funcționale a sistemului.
O componentă ci este irelevantă (inutilă) din punct de vedere al funcționării
sistemului dacă pentru orice xj (ji):
(x1, …, xi1, 1, xi+1, …, xn) = (x1, …, xi1, 0, xi+1, …, xn)
5.7. Scheme bloc de fiabilitate
Relațiile logice dintre componentele unui sistem din punct de vedere al
fiabilității pot fi puse în evidență cel mai simplu cu ajutorul schemelor bloc de
fiabilitate. Componentele a căror funcționare este strict necesară pentru ca
sistemul să fie operațional sunt conectate în serie, iar componente le
redundante, care se pot substitui reciproc, sunt conectate în paralel pe aceste
scheme. Este de subliniat că aceste scheme bloc nu reprezintă conexiunile fizice
ale componentelor, ci numai relațiile dintre ele pentru o funcționare cu succes
a sistemului .
Figura 5.12. Schema bloc de fiabilitate a unui sistem serie
În cazul unui sistem serie (serial system ) cu n componente (figura 5.12)
având vectorul de stare X = (x1, x2, …, xn), funcția de structură sub formă
algebrică are expresia:
(X) = x1x2 xn = min( x1, x2, …, xn) (5.68)
Funcția de fiabilitate corespunzătoare este, folosind ( 5.65), (5.66) și având în
vedere independența componentelor:
R = E[x1x2 xn] = E[x1] E[x2] E[xn] = p1p2 pn (5.69)
Același rezultat se obține dacă funcția de structură se exprimă sub formă
booleană:
(X) = x1x2 … xn (5.70)
Folosind de data aceasta relația probabilității evenimentelor independente,
rezultă:
R = Pr( x1x2 … xn=1) = Pr( x1=1) P r(x2=1) Pr(xn=1) = p1p2 pn (5.71)
Se constată din expresia obținută că fiabilitatea unui sistem serie este mai mică
decât fiabilitatea oricărei componente.
Dacă componentele au o distribuție exponențială a timpului până la
defectare, adică
t
iiep , atunci fiabilitatea sistemului serie cu n componente
este:
n
ii
it n
ite e tR1
1
)(
(5.72)
Se poate observa că rata de defectare a sistemului este egală cu suma ratelor
de defectare ale componentelor:
n
ii
1 (5.73)
Întrucât = constant, sistemul își păstrează legea de distribuție exponențială a
timpului de funcționare, timpul mediu până la defectare fiind dat de relația
cunoscută:
1MTTF
(5.74)
În proiectare se lucrează cu o valoare
n
iiik
1 , unde ki < 1 reprezintă
coeficienți de corecție, care țin cont de supradimensionarea sistemului 17.
Dacă componentele sunt identice ( 1, 2, …, n), atunci timpul mediu
până la defectare al sistemului este de n ori mai mic decât timpul mediu până
defectare al unei componente ( MTTF 1):
11MTTFnMTTF
(5.75)
Figura 3. 13. Schema bloc de fiabilitate a unui sistem paralel
În cazul unui sistem paralel (parallel system ) (figura 5.13), funcția de
structură sub cele două forme se exprimă astfel:
(X) = 1(1x1)(1x2) (1xn) = max( x1, x2, …, xn) (5.76)
(x) = x1x2 … xn (5.77)
Funcția de fiabilitate, conform celor două forme de exprimare și ținând cont de
independența componentelor, va fi dată pe baza ( 5.65), (5.66) de
R = E[1 (1x1)(1x2) (1xn)] = 1 E[(1x1)(1x2) (1xn)] =
= 1 1E[x1]1E[x2] 1E[xn] = 1 (1p1)(1p2) (1pn) (5.78)
respectiv:
) 1() 1)( 1(1 )1 Pr(1 )1 Pr(1)1 Pr(11 )1 Pr()1 Pr()1 Pr(1)1 … Pr(1 )1 … Pr(1) … Pr(
2 12 12 1 2 12 1 2 1
nnn nn n
p p px x xx x x x xxx xx x xx R
(5.79)
Evident prin cele două metode de calcul s -a obținut aceeași expresie pentru R.
Fiabilitatea sistemului paralel este mai mare decât fiabilitatea oricărei
componente din sistem.
La un sistem paralel format din componente cu legi de defectare
exponențiale, timpul de defectare al sistemului nu va mai păstra caracterul
exponențial, ca în cazul sistemelor seriale. De exemplu, pentru n=2 funcția de
fiabilitate a sistemului are expresia
t t t t te e e e e tR) (2 1 2 1 2 11 11)( (5.80)
iar rata de defectare nu mai este constantă în timp:
t t tt t t
e e ee e e
tRtRt) () (
2 1 2 1
2 1 2 12 1 2 1 ) (
)()()(
(5.81)
Timpul mediu până la defectare al sistemului se calculează conform relației
(5.27):
2 1 2 10)λλ( λ λ
0
λλ1
λ1
λ1 )(2 1 2 1
dt e e e dttR MTTFt t t
(5.82)
În cazul în care componentele sunt identice ( 1=2), timpul mediu de
defecta re al sistemului paralel va crește numai cu 50% față de timpul mediu al
unei singure componente:
1
15,123MTTF MTTF
(5.83)
5.8. Mărimi empirice de fiabilitate
În scopul de a descrie cantitativ modul cum se comportă un produs
relativ la posibilitatea defectării pe durata unei perioade de sarcini se folosesc
indicatori de fiabilitate. Aceste mărimi sunt utile și atunci când se pune
problema de a compara fiabilitatea a două produse diferite, dar din aceeași
categorie.
Indicatorii de fiabil itate se pot obține pe baza datelor de defectare
furnizate de utilizatorii aceluiași tip de produs, acest caz fiind cel al fiabilității
operaționale . O altă posibilitate este de a supune un eșantion omogen din
produsul respectiv la un test de supraviețuire (life test ) în condiții de mediu și
funcționale similare cu cele de exploatare. Aceste încercări de fiabilitate fiind
efectuate în laboratorul fabricantului, se încadrează în contextul fiabilității
experimentale sau empirice . Datele obținute se prelucreaz ă cu metode
statistice, obținându -se ca rezultat estimatori de fiabilitate.
Prin încercările de fiabilitate se urmărește comportarea în cadrul testului
de supraviețuire a unui număr mare de produse identice, care formează o
populație statistică. Fie N num ărul de produse supuse testului la momentul t=0
și n(t) numărul de produse care supraviețuiesc la momentul t (funcția de
supraviețuire). Este însă mai convenabil să se lucreze cu o funcție independentă
de mărimea eșantionului, și anume cu numărul relativ d e supraviețuitori. Se
poate defini astfel funcția de fiabilitate empirică ca și numărul de produse în
funcțiune la momentul t raportat la numărul inițial de produse:
NtntRˆ)()(
(5.84)
Reprezentarea grafică a lui
)(ˆtR este dată in figura 5.14, unde ti este
momentul de defectare al produsului i (i=1, …, N). Se observă că fiabilitatea
empirică este o funcție crescătoare continuă la dreapta în punctele ti, fiind
caracterizată prin
1)0(ˆ R și
0)(ˆR , produsele nefiind perfecte.
Figura 5.14. Funcția empirică de fiabilitate
O altă mărime de caracterizare a fiabilității se obține dacă se pornește de
la numărul de defectări pe intervalul [ t, t + t) raportat la mărimea intervalului:
tn
tttntn
) ()(
Dacă această rată de defectare pe unitatea de timp este standardizată pe
unitatea de produs, rezultă estimarea empirică a densității de defectare în
intervalul [ t, t+t), adică viteza instantanee de defectare :
11
1
ii
ii i
tNn
tNt tntntfˆ) ()()(
(ti t < ti+1) (5.85)
Dacă raportarea se face la numărul de produse de la începutul intervalului,
atunci se obține
11
1 )( )() ()()(ˆ
i ii
i ii i
ttnn
ttnt tntntz
(ti t < ti+1) (5.86)
unde
)(ˆtz este funcția de hazard empirică . Această mărime se mai numește
intensitate de defectare și se poate exprima cu ajutorul raportului viteza
instantanee de defectare / funcția de fiabilitate.
Se mai definește un al patrulea indicator de fiabilitate, și anume funcția
empirică de nefiabilita te, dată de relația:
)(ˆ1)(ˆ tR tF
(5.87)
Datele pentru calculul indicatorilor empirici de fiabilitate pot fi culese în
două feluri: prin monitorizare continuă sau prin monitorizare sporadică.
a) Culegerea datelor prin monitorizare co ntinuă se aplică dacă numărul
de produse este mic. În acest caz se înregistrează timpul de defectare exact al
fiecărei componente, obținându -se mulțimea ti, i=1, …, N, a timpilor de
defectare.
Funcția de fiabilitate empirică este o funcție în trepte cu
)(ˆtR = constant
pe [ti, ti+1), care descrește la fiecare moment de defectare cu aceeași valoare.
Figura 4.1 corespunde acestei situații. Funcția se poate transforma în poligon
prin interpolare liniară pe fiecare interval ti+1 = ti+1 ti.
Având în vedere faptul că numărul de supraviețuitori scade cu o unitate
pe fiecare interval ti+1, adică
ni+1 = n(ti) n(ti+1) = 1
se pot determina și ceilalți indicatori de fiabilitate pe baza formulelor ( 5.85) și
(5.86), care devin:
11
itNtfˆ)(
1)(1)(ˆ
i ittntz
Aceste funcții sunt valabile pentru ti t < ti+1, ele prezentând de asemenea
discontinuități în momentele ti.
Având înregistrați timpii de defectare ti ai componentelor, se poate
calcula ușor timpul mediu până la defectare MTTF (Mean Time To Failure ):
Nt
MTTFN
ii
1
(5.88)
b) La metoda de lucru prin monitorizare sporadică (necontinuă),
sistemul se observã din timp în timp la momente ti (nu neapărat egale) și se
notează numărul de supraviețuitori n(ti). Această soluție se preferă dacă
numărul de produse este mare, relațiile de calcul ( 5.84), (5.85), (5.86) și ( 5.87)
pentru indicatorii de fiabilitate fiind valabile. Forma graficului pentr u funcția de
fiabilitate empirică este arătată pentru această situație în figura 5.15.
Figura 5.15. Funcția de fiabilitate empirică obținută
prin monitorizare sporadică
Tratarea matematică a mentenabilității este similară cu cea a fiabilității
(în sens restrâns), și aici fiind posibilă obținerea unor mărimi empirice
(estimatori) de mentenabilitate pe o populație statistică. Dacă N reprezintă
numărul de produse defecte la t=0 și nr(t) numărul de produse reparate până la
momentul t, atunci funcția de mentenabilitate empirică este dată de:
NtntMˆ r)()( (5.88)
Un alt indicator de mentenabilitate este viteza instantanee de reparație
empirică , definită prin numărul de produse reparate în unitatea de timp
raportat la numărul inițial de produse defecte:
tNn
tNtnt tntfˆ r ir ir
r)( ) ()(
(5.89)
Relația este valabilă pe intervale de forma t=ti+1ti, deci pentru ti t < ti+1. În
cazul în care raportarea se face la numărul de produse rămase defecte la
momentul evaluării, se obține rata de reparație empirică :
ttnNn
ttntnt tntˆ
irr
idir ir
)( )()( ) ()(
(5.90)
Este evident că între cele trei mărimi există relația:
)(ˆ1ˆ
)(ˆ
tMftr
Pe baza datelor de exploatare, având în vedere faptul că produsul poate suferi
mai multe defectări și restabiliri, se poate estima timpul mediu de reparație
prin
mt
MTTRm
iri
1 (5.91)
unde
irt reprezintă timpul reparației cu numărul de ordine i al produsului, iar m
numărul de reparații.
Dacă pe o durată lungă de observare produsul se defectează de m ori,
atunci o valoare estimată pentru timpul mediu între defectări (MTBF ) se poate
calcula cu formula:
mMTBF
(5.92)
Evaluarea experimentală a disponibilității se poate face pe o durată
mare de observare 0, t cu relația
rep opop
t tttA)(ˆ
(5.93)
unde top este timpul total de funcționare corectă, iar trep este timpul cât
sistemul a fost în reparație pe durata observării.
5.9. Fiabilitatea software
Studiul funcționalității unui sistem de calcul, deosebit de important în cazul
unor aplicații critice, nu poate fi redus numai la evaluarea fiabilității hardwa re.
Îndeplinirea de către sistem a sarcinilor prevăzute presupune și existența unui
set de programe corecte, astfel că software -ul a devenit un obiect de studiu în
privința fiabilității. Acest lucru s -a accentuat pe măsura creșterii continue a
costului pro gramelor în raport cu cel al componentelor, atât în faza de
dezvoltare, cât și în cea de exploatare a sistemului.
Un program (P) este în principiu un instrument care transpune o mulțime de
date de intrare (I) într -o mulțime de date de ieșire (O), corespond ența fiind
univocă dacă se presupune că variabilele de stare fac parte atât din I, cât și din
O (figura 5.1 6.a).
Figura 5.1 6. Comportarea unui program lipsit de eroare (a),
respectiv afectat de erori (b)
Defectul software (software fault ) reprezintă o eroare în program care
duce la o abatere a comportării sistemului față de cerințele formulate. Rezultă
că în mulțimea intrărilor se poate separa o submulțime de elemente care,
afectate de eroarea din program, vor da ieșiri incorecte, co respunzătoare unei
funcționări defectuoase a sistemului (figura 5.1 6.b). Se admite că totdeauna
este posibilă sesizarea unei comportări incorecte a programului. Defectele
software sunt evident în esență defecte de proiectare, datorate în primul rând
unei c auze umane, nefiind posibilă deteriorarea fizică sau alterarea aleatoare a
programelor.
Fiabilitatea software (software reliability ) se definește ca fiind
probabilitatea de a nu apare pe o anumită durată de expunere și într -un mediu
specificat un defect software, care cauzează o deviere mai mare a ieșirii decât o
toleranță admisă specificată.
Mediul specificat înseamnă că datele de intrare vor face parte din
mulțimea intrărilor pentru care s -a conceput programul. Perioada de expunere
poate fi un număr de rulări al programului sau un timp calendaristic ori timp –
CPU. Corespunzător se exprimă următoarele mărimi pentru determinarea
fiabilității software:
R(i) = fiabilitatea după i rulări = Pr{fără defectare după i rulări}
R(t) = fiabilitatea după timpul t = Pr{fără defectare în intervalul [0, t]}
Se poate defini fiabilitatea operațională R = R(1) ca fiind
nnlim Rf
n1
(5.94)
unde n reprezintă numărul de rulări, iar nf numărul de defectări care au apărut
în acest timp. Dacă se presupune o selecție aleatoare a intrărilor, fiabilitatea
după i rulări va fi
i iR RiR 1 . Observând numărul de defectări ( nf) în
timpul unui număr de rulări ( n) a programului în mediul său specificat, se poate
calcula un estimator de fiabilitate:
nnRˆf1
(5.95)
Găsirea defectelor software într -un program este o problemă cu atât mai
dificilă, cu cât programul este mai complex. Metodele de verificare automată a
programelor nu sunt prea eficiente, iar verificarea manuală, prin deducții
succesive, este greoaie, îndelungată și expusă la greșeli. De aceea, pentru
evaluarea corectitudinii unui program se utilizează fiabilitatea software, ca o
măsură a încrederii în fu ncționalitatea programului. Pentru determinarea
acestei mărimi se efectuează testarea programului, care constă din execuția
(fizică sau simbolică) a acestuia corespunzător unui ansamblu de condiții de
test, în vederea punerii în evidență a defectelor conți nute de program. Un
avantaj al testării este faptul că furnizează informații despre comportarea
programului chiar în mediul său de lucru. Datele privind erorile constatate în
timpul testării se folosesc în continuare pentru evaluarea fiabilității software pe
baza unui model matematic de fiabilitate. Există un număr mare de astfel de
modele propuse, care încearcă să descrie cât mai exact comportarea reală a
programului, dar conțin ipoteze și restricții simplificatoare care le restrâng
aplicabilitatea la anum ite faze ale dezvoltării programelor.
Majoritatea modelelor pornesc de la o paralelă între fiabilitatea software
și cea hardware, cu corecțiile de rigoare impuse de diferențele inerente dintre
cele două părți. De exemplu, rata de defectare a hardware -ului urmează o
scădere în faza de rodaj, iar în perioada de îmbătrânire se constată o tendință
de creștere. La programe neexistând noțiunea de uzură, rata de defectare este
descrescătoare pe măsură ce erorile de program se localizează și se corectează.
Valoare a estimată a fiabilității software depinde totdeauna și de mediul de
utilizare, deoarece parcurgerea a două căi diferite în același program duce de
obicei la întâlnirea unui număr diferit de defecte.
BIBLIOGRAFIE SELECTIVĂ
[Angheloiu72] I. Angheloiu, Teoria codurilor, Editura Militară, București, 1972.
[Băjenescu97] T. I. Băjenescu, Fiabilitatea, disponibilitatea și mentenabilitatea sistemelor
electronice complexe, Editura de Vest, Timișoara, 1997.
[Cătuneanu89] V. M. Cătuneanu, A. Bacivarof, Structuri electronice de înaltă fiabilitate,
Editura Militară, București, 1989.
[Dubrova13] E. Dubrova, Fault -Tolerant Design, Springer, 2013.
[Felea96] I. Felea, Ingineria fiabilității în electroenergetică, Editura Didactică și Pedagogică
R.A., București, 1996.
[Görke89] W. Görke, Fehlertolerante Rechensysteme, R. Olderbourg Verlag München Wien,
1989.
[Grosh89] D. L. Grosh, A Primer of Reliability Theory, John Wiley & Sons, 1989.
[Jalote94] P. Jalote, Fault Tolerance in Distributed Systems, PTR Prentice Hall, Engle wood
Cliffs, New Jersey, 1994.
[Johnson89] B. W. Johnson, Design and Analysis of Fault -Tolerant systems, Addison -Wesley,
1989.
[Koren07] I. Koren, C. M. Krishna, Fault -Tolerant Systems, Morgan Kaufmann, 2007.
[Lee90] P. A. Lee, T. Anderson, Fault Tolerance – Principles and Practice, Springer -Verlag
Wien New York, 1990.
[Levi94] S. -T. Levi, A. A. Agrawala, Fault Tolerant System Design, McGraw -Hill, Inc., 1994.
[Lyu96] Lyu, M. R., Handbook of Software Reliability Engineering, McGraw -Hill, 1996.
[Mihalache95] A. Mihalache, Când calculatoarele greșesc… Fiabilitatea sistemelor de
programe (software), Editura Didactică și Pedagogică R. A., București, 1995.
[Popescu02] Popescu, C., Popescu, D. E., Fiabilitatea și testabilitatea sistemelor digitale,
Editura Matrix R om, 2002.
[Pradhan95] D. K. Pradhan, Fault -Tolerant Computer System Design, Prentice Hall PTR,
Upper Saddle River, New Jersey, 1995.
[Rai90] Rai, S., Agrawal, D. P., Advances in Distributed System Reliability, IEEE Computer
Society Press, Los Alamitos CA, 1990.
[Vlăduțiu89] M. Vlăduțiu, M. Crișan, Tehnica testării echipamentelor automate de prelucrare
a datelor, Editura Facla, Timișoara, 1989.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Vári-Kakas Ștefan [628624] (ID: 628624)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.