CUPRINS

CUPRINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 INTRODUCERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 METODE DE CREùTERE A FIABILIT^¼II ùI DISPONIBILIT^¼II

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Indicatori pentru caracterizarea fiabilit_½ii úi disponibilit_½ii . 11

2.1.1 Clasificarea defec½iunilor . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Estimarea fiabilit_½ii . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.3 Disponibilitatea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.4 Dependabilitatea . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.5 Mentenabilitate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.6 Cerin½ele fiabilit_½ii aplicate . . . . . . . . . . . . . . . . . . . 17

2.1.7 Tehnici de redundan½_ . . . . . . . . . . . . . . . . . . . . . . . . 19

5
 2.2 Metode de autocontrol, implementate hardware . . . . . . . . . . 20

2.2.1 Controlul prin copii . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Controale de codificare . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.3 Controale de temporizare . . . . . . . . . . . . . . . . . . . . . . 23

2.2.4 Controale de excep½ie . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.5 Restabilirea erorii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.5.1 Clasificarea procedurilor de restabilire . . . . 26

2.2.5.2 Reconfigurarea . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Metode de autocontrol implementate software . . . . . . . . . . . . 29

2.3.1 Func½ia unui proces . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.2 Secven½a de comand_ a unui proces . . . . . . . . . . . . . 30

2.3.3 Date de proces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.4 Restabilirea software . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.5 Diagnosticarea erorii . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.6 Validarea fiabilit_½ii . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 AUTOCONTROLUL CA MIJLOC DE CREùTERE A FIABILIT^¼II ùI

DISPONIBILIT^¼II SISTEMELOR DE CALCUL . . . . . . . . . . 33

3.1 Metode de autocontrol aplicate la diferite niveluri de structur_

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6
 3.1.1 Caracteristicile metodelor de proiectare structurat_ la nivel
de bistabil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.2 Caracteristicile metodelor de proiectare structurat_ la nivel

de registru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1.3 Proiectarea structurat_ la nivel de bloc . . . . . . . . . . . 40

3.1.3.1 Autocontrolul bazat pe principiul BILBO . . 42

3.1.3.2 Modulul comutator de testare, încorporat, pentru

izolarea defectelor . . . . . . . . . . . . . . . . . . . . . 43

3.1.4 Controlul erorilor la nivel de procesor . . . . . . . . . . . 44

3.2 Problematica construc½iei checker-elor de erori . . . . . . . . . . . 45

3.2.1 Circuite de verificare dubl_ cale . . . . . . . . . . . . . . . . 46

3.2.1.1 Checker de egalitate . . . . . . . . . . . . . . . . . . . 46

3.2.1.2 Checker M din N . . . . . . . . . . . . . . . . . . . . . 46

3.2.2 Circuite cu autoverificare total_, încorporate . . . . . . 47

BIBLIOGRAFIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7
8
 1 INTRODUCERE

Fiabilitatea unui sistem a fost o preocupare major_ înc_ din momentul apari½iei
calculatoarelor electronice numerice. Exist_ preocup_ri legate de analiza de
fiabilitate, constând în evaluarea de indicatori numerici, atât previzional cât
úi experimental, pentru dezideratul siguran½ei în func½ionare. Pe lâng_ aceast_
arie de preocup_ri, fiabilitatea implic_ sinteza unor sisteme de calcul care, prin
proiectare, s_ îndeplineasc_ anumi½i indicatori de fiabilitate impuúi. În acest
sens se apeleaz_ la metode de creútere a fiabilit_½ii care, în accep½iunea cea
mai larg_, sunt divizate în dou_ clase: evitarea defectelor (fault avoidance)
sinonim cu netolerarea defectelor (fault intolerance) úi tolerarea defectelor
(fault tolerance). Obiectivul esen½ial al unui sistem fiabil este reprezentat de
c_tre defect, fie în sensul evit_rii acestuia, fie în sensul toler_rii lui, context
în care se impun unele preciz_ri legate de terminologie. Asupra acestora se
insist_ in extenso în capitolul al doilea al lucr_rii, dar, anticipând, vom în½elege
prin defect orice deviere de la func½ionarea normal_ a unui sistem, aceasta
putând fi cauzat_ fie prin erori de proiectare, fie prin anomalii ale echipa-
mentelor, fie prin erori ale operatorilor sau ale personalului de între½inere,
acestea din urm_ fiind denumite în lucrare erori de interac½iune. Prima clas_
de metode foloseúte componente de înalt_ fiabilitate, tehnici conservative de
proiectare úi recenzii vaste în faza de proiectare, pentru eliminarea defectelor
de proiectare. Obiectivul acestor metode este reducerea posibilit_½ilor de
defectare. Totuúi, apar eúecuri chiar úi în cazul celei mai atente evit_ri a
defectelor úi de aici termenul de netolerare a defectelor (fault intolerance).
În mod firesc, se justific_ existen½a celei de-a doua clase de metode care, în
scopul de a tolera defectele, foloseúte componente adi½ionale, numite
redundante. Pentru claritate, amintim c_ indicele aproape unanim recunoscut
ca obiectiv de proiectare este raportul performan½_/cost. În vederea optimiz_rii
acestuia, majoritatea tehnicilor de proiectare apeleaz_ la eliminarea redundan½ei.
În mod contrar, fa½_ de tehnicile anterioare, noile metode introduc redundan½a
pentru a conferi sistemelor acest deziderat aparte al proiect_rii: fiabilitatea prin

9
tolerare la defecte. Redundan½a poate fi introdus_ prin solu½iile eminamente
hardware, eminamente software sau prin solu½ii hibride (hardware/software),
dar în toate cazurile se urm_reúte evitarea efectelor defectelor. Ambele tehnici
sunt uzual folosite în sistemele de înalt_ fiabilitate.

În trecut, sistemele de calcul tolerante la defec½iuni ocupau doar o mic_ parte

din pia½a comercial_, datorit_ costului excesiv. Multe sisteme au fost proiectate
ca s_ dea solu½ii unor aplica½ii specializate, dar, în ultimul timp, calculul tolerant
la defec½iuni începe s_ joace un rol important în proiectarea calculatoarelor
comerciale din mai multe motive, cum sunt: progresele deosebite în tehnologia
VLSI, posibilitatea de integrare pe tot wafer-ul (WSI), costul mare de între½inere
al echipamentelor sofisticate, câmpul vast de aplica½ii care pot fi abordate de
c_tre un sistem úi preten½iile utilizatorilor pentru fiabilitate superioar_. Deoarece
calculatoarele continu_ s_ preia din ce în ce mai multe servicii critice pentru
func½ionarea cu succes a spitalelor, a uzinelor produc_toare, a combinatelor
energetice, a b_ncilor, a oficiilor etc., au crescut substan½ial preten½iile
utilizatorilor, fiind imperativ necesar_ construirea úi utilizarea sistemelor
tolerante la defec½iuni. În acest context, prezenta lucrare abordeaz_ aspectul
creúterii fiabilit_½ii úi disponibilit_½ii sistemelor numerice de calcul, valorificând
avantajele oferite de utilizarea autocontrolului.

10
 2 METODE DE CREùTERE A FIABILI-
T^¼II ùI DISPONIBILIT^¼II

2.1 Indicatori pentru caracterizarea fiabilit_½ii úi disponi-

bilit_½ii

2.1.1 Clasificarea defec½iunilor

Într-un sistem exist_ trei categorii majore de surse de erori: a) greúeli de

proiectare, b) defec½iuni fizice úi c) erori de intreac½iune ale operatorului uman
(procedural errors). Aceste surse de erori contribuie la c_derile sistemului.
Pe de o parte, greúelile de proiectare apar atât în hardware, cât úi în software.
Acestea din urm_ sunt predominante úi se elimin_ greu din sistem. Pe de alt_
parte, defec½iunile fizice sunt rezultatul îmb_trânirii componentelor sau a
influen½ei mediului, care cauzeaz_ devierea unor caracteristici ale echipa-
mentului peste limitele câmpului specificat al toleran½ei. Se produc, astfel, erori
determinate de aúa-numitele defec½iuni parametrice hardware. Ac½iunile
improprii ale operatorului, la panourile de control úi de între½inere, pot
determina func½ionarea defectuoas_ a sistemului. Ceea ce introduce operatorul
are prioritate mare, sistemele fiind foarte vulnerabile la comenzi improprii úi
la erori de operare. Proiectarea unui sistem tolerant la defec½iuni necesit_
g_sirea unei metode care s_ împiedice ca o component_ hardware deteriorat_

11
s_ determine o defec½iune logic_ úi ca aceasta s_ determine, la rândul ei, o
eroare.

În relativ scurta istorie a designului tolerant la defecte au existat multe confuzii

între defini½ii úi concepte fundamentale. De exemplu, se foloseau, în mod
interschimbabil, termeni ca: defec½iune, deteriorare úi eroare. Unii autori sus½in
c_ o deteriorare a avut loc atunci când calculatorul nu mai r_spunde la comenzi.
Dimpotriv_, al½i autori afirm_ c_ o deteriorare este o defec½iune fizic_ specific_,
mai degrab_, componentelor electronice. Datorit_ diversit_½ii de p_reri în
privin½a în½elegerii acestor no½iuni úi pentru a se evita echivocul în lectura
acestei lucr_ri, consider util_ definirea unor termeni, care, deúi au serioase
trimiteri bibliografice, sunt înc_ departe de acceptarea universal_. Aceste
definiri sunt:

 Deteriorarea (failure) apare atunci când ieúirea ob½inut_ difer_ de cea

proiectat_. Ieúirea poate fi privit_ la diferite niveluri de abstrac-
tizare: la nivel de component_ electronic_, la nivel de bloc sau
la nivel de sistem;

 Defec½iunea sau defectul (fault) este o stare eronat_ a maúinii sau a

sistemului de programe, stare generat_ de: deterior_ri ale
componentelor, interferen½e fizice cu mediul, erori ale operato-
rului uman sau proiectare incorect_;

 Eroarea (error) este manifestarea unei defec½iuni într-un program sau

într-o structur_ de date. Ea poate ap_rea la o anumit_ distan½_ în
spa½iu úi timp fa½_ de locul, respectiv momentul, defect_rii;

Defini½iile de mai sus pot fi caracterizate de urm_toarele adjective:

 Adjectivul „permanent“ (idem în englez_) descrie o deteriorare, o

defec½iune sau o eroare cu caracter continuu úi stabil. Dac_ este
vorba despre echipament, atunci o deteriorare permanent_ reflect_
o schimbare fizic_ ireversibil_;

12
  Adjectivul „intermitent“ (intermittent) descrie o defec½iune sau o
eroare care se repet_ ocazional;

 Adjectivul „tranzitoriu“ (transient) descrie o defec½iune sau o eroare

non-repetitiv_, cauzat_ de condi½ii temporare. Exemple sunt
ac½iunea particulelor . asupra memoriilor semiconductoare sau
varia½ia tensiunii de alimentare a echipamentelor. Astfel de erori
sunt nereparabile, pentru c_ nu exist_ defect fizic al echipamen-
tului. Evitarea lor se poate face doar printr-o proiectare mai
riguroas_.

Deterior_rile sistemului sunt clasificate, func½ional vorbind, în defec½iuni

hardware, erori software úi erori de procedur_. Exist_ rela½ii strânse între cele
trei tipuri de deterior_ri de sistem úî categoriile surselor de defec½iuni.
Defec½iunile fizice apar numai la echipament. Erorile de proiectare, chiar dac_
apar în hardware, produc, în majoritatea lor, erori de tip software. Erorile de
interac½iune sunt cauzate, de obicei, de greúelile f_cute de operator.

În afara deterior_rilor normale ale dispozitivelor, la defec½iunile hardware mai

contribuie condi½iile mediului înconjur_tor (perturba½iile), erorile de proiectare
(greúelile) úi cronografiile improprii (timing problems). Greúelile de proiectare,
ca în cazul erorilor software, sunt foarte greu de apreciat cantitativ. Calculele
de fiabilitate se bazeaz_ mai mult pe defec½iunile dispozitivelor.

2.1.2 Estimarea fiabilit_½ii

Estimarea fiabilit_½ii este un proces de apreciere a fiabilit_½ii realizabile de un

articol (element, subsistem sau sistem), având disponibile datele ratei de
defectare, adic_, prin estimarea fiabilit_½ii, se apreciaz_ probabilitatea
îndeplinirii obiectivelor articolului respectiv pentru o aplica½ie specific_. Aceste
calcule sunt utile în stadiile de început ale unui proiect.

13
Dup_ îndep_rtarea defec½iunilor timpurii, componentele se men½in pe o perioad_
lung_ la o rat_ de defectare aproximativ constant_. În timpul acestei perioade,
rata de defectare este, de obicei, sc_zut_ úi este pu½in probabil ca defec½iunile
s_ provin_ de la o singur_ cauz_. Rata constant_ de defectare, reprezentat_ în
por½iunea de via½_ util_, scoate în eviden½_ faptul c_ probabilitatea de defectare
este independent_ de vârst_. Pentru orice rat_ constant_ de defectare, valoarea
fiabilit_½ii depinde numai de timp. Func½ia fiabilit_½ii R (t) (reliability), care
este caracterizat_ de o rat_ constant_ de defectare este o distribu½ie negativ_
exponen½ial_ úi are forma:

R (t)
e  t

unde  este rata de defectare, iar t este timpul.

Timpul mediu dintre defect_ri (Mean Time Between Failures; MTBF) este
timpul mediu, exprimat, de obicei, în ore, în care un articol ar putea s_
func½ioneze corect înainte de a se deteriora úi reprezint_ m_sura cantitativ_
a fiabilit_½ii. În general, MTBF-ul unui sistem ar putea fi tratat ca integrala
func½iei de fiabilitate a întregului sistem:


R (t) d t
20

În câteva c_r½i de literatur_, intervalul este definit ca timp mediu de defectare

(Mean Time To Failure; MTTF). Din punct de vedere tehnic, MTTF úi MTBF
nu sunt identici, MTBF-ul poate fi definit, într-o form_ alternativ_, astfel

MTBF
MTTF  MTTR

unde MTTR este timpul mediu de repara½ie (Mean Time To Repair).

Rata de repara½ie µ (repair rate) sau inversul timpului mediu de repara½ie, adic_

1
µ

MTTR

14
este un alt factor care afecteaz_ substan½ial fiabilitatea úi mentenabilitatea unui
sistem. Când o unitate dintr-un sistem duplicat este defect_, sistemul este
dependent de a doua unitate pentru a-úi continua opera½ia. Dac_ unitatea defect_
este reparat_ repede, riscul deterior_rii întregului sistemului este mic deoarece
unitatea a doua va opera astfel încât s_ p_streze integritatea func½ion_rii
sistemului. Întrucât sistemul este vulnerabil numai pân_ la repara½ia unit_½ii
defecte, un timp scurt de repara½ie poate creúte foarte mult fiabilitatea
sistemului.

2.1.3 Disponibilitatea

Disponibilitatea A(t) (availability) unui echipament este o func½ie de timp. Ea

se poate defini ca probabilitate de func½ionare a echipamentului la momentul t ,
atât timp cât este folosit conform specifica½iilor. Conceptul de disponibilitate
este utilizat în m_surarea eficacit_½ii sistemului. Atât fiabilitatea, cât úi mentena-
bilitatea, îúi aduc aportul la definirea conceptului de disponibilitate. Aceast_
conexiune poate fi exprimat_ în felul urm_tor:

MTTF
A(t)

MTTF  MTTR

unde func½ia fiabilit_½ii se presupune c_ este distribu½ia exponen½ial_ R

e  t .
Deoarece MTTF-ul este o m_sur_ a fiabilit_½ii, iar MTTR-ul este o m_sur_ a
mentenabilit_½ii, ele se pot negocia astfel încât s_ se ob½in_ o disponibilitate
dat_.

2.1.4 Dependabilitatea

Laprie úi Coste au definit formal dependabilitatea ca un cadru de specifica½ii

de nivel înalt, care include m_rimi ca fiabilitatea úi disponibilitatea, ca dou_

15
fa½ete distincte ale specifica½iilor sistemului. Pe baza caracteristicilor unui
sistem, dependabilitatea lui se descrie fie prin fiabilitate, fie prin disponibilitate.
De exemplu, putem caracteriza mai bine un sistem nereparabil prin fiabilitatea
lui, iar un sistem reparabil prin disponibilitatea lui.

În literatura mai recent_, se men½ioneaz_ c_ termenul de dependabilitate

include, pe lâng_ conceptele de fiabilitate úi disponibilitate men½ionate anterior,
úi pe cele de siguran½_ în func½ionare, mentenabilitate, performabilitate úi
testabilitate. Dependabilitatea reprezint_ calitatea deservirii furnizate de c_tre
un anumit sistem. Fiabilitatea, disponibilitatea, siguran½a, mentenabilitatea,
performabilitatea úi, în fine, testabilitatea sunt m_rimi utilizate pentru estimarea
cantitativ_ a dependabilit_½ii unui sistem. ¼inta proiect_rii tolerante la
defec½iuni este îmbun_t_½irea dependabilit_½ii prin înarmarea unui sistem pentru
realizarea func½iei cerute, în prezen½a unui num_r dat de defecte. Totuúi, este
de notat c_ un sistem tolerant la defec½iuni nu este neap_rat de înalt_
dependabilitate úi nici înalta dependabilitate nu necesit_ neap_rat toleran½a
la defectare.

2.1.5 Mentenabilitate

Sistemele de calcul, ca orice alte produse, se pot clasifica în dou_ categorii:

a) sistemele cu func½ie unic_ (simpl_), la care prima defectare constituie úi
finalul vie½ii lor úi b) sistemele cu func½ie repetat_ sau sistemele cu reînnoire
(restabilire), la care elementele defecte pot fi înlocuite cu altele bune, caz în
care aceste produse au caracter reparabil. Prin mentenan½_ se în½elege ansamblul
tuturor ac½iunilor tehnico-organizatorice necesare, efectuate în scopul
men½inerii sau restabilirii unui produs în starea necesar_ îndeplinirii func½iei
cerute. Aceste ac½iuni pot avea caracter corectiv (depistarea cauzei unei
defec½iuni, repararea defectului prin înlocuirea elementelor defecte, verificarea
corectitudinii opera½iilor de mentenan½_ întreprinse) sau caracter preventiv

16
(revizii, reglaje, verific_ri úi repara½ii planificate, executate în vederea evit_rii
unor viitoare defec½iuni).

În aceste condi½ii, este necesar s_ se exprime cantitativ aptitudinea unui produs

de a fi repus în func½iune în urma unui defect. Exprimarea se face, ca úi în cazul
fiabilit_½ii, printr-o probabilitate în func½ie de timp. Mentenabilitatea este,
aúadar, aptitudinea unui produs ca, în condi½ii date, s_ fie men½inut sau restabilit
în starea de a-úi îndeplini func½ia specificat_, atunci când ac½iunile de
mentenan½_ se efectueaz_ în condi½ii precizate úi într-un timp dat, cu procedee
úi remedii prescrise. Corespunz_tor acestei defini½ii, leg_tura dintre aspectul
probabilistic úi cel func½ional se exprim_ astfel:

M (tr )
Prob (t rTr )

unde tr este timpul de restabilire, Tr este o limit_ impus_ duratei de restabilire,

iar M (tr ) este func½ia de mentenabilitate.

Rela½ia între mentenabilitatea M úi rata de repara½ie µ sau timpul mediu de

repara½ie MTTR este urm_toarea:

tr
(µ t r )
M (tr )
1 e
1 e MTTR

La fel ca fiabilitatea, testabilitatea, dependabilitatea etc., mentenabilitatea

trebuie planificat_ úi estimat_ sau evaluat_ înc_ din fazele cele mai timpurii
ale conceperii unui produs.

2.1.6 Cerin½ele fiabilit_½ii aplicate

Cerin½ele fiabilit_½ii variaz_ considerabil de la o aplica½ie la alta. De exemplu,

obiectivele fiabilit_½ii unui oficiu telefonic cu comutare digital_, proiectat
pentru aplica½ii telefonice, sunt:

17
 a) timpul total în care sistemul r_mâne neoperativ s_ nu dep_úeasc_ trei
minute pe an, cu un timp mediu de repara½ie (MTTR) de patru
ore;

b) în timpul func½ion_rii s_ nu se piard_ sau s_ nu se trateze incorect

mai mult de 0,01% dintre apeluri.

Func½ionarea satisf_c_toare nu înseamn_, în acest caz, o fiabilitate de 100%.

Sunt permise, totuúi, câteva apeluri incorecte, avându-se in vedere c_
utilizatorul va forma din nou num_rul dorit, ob½inând corec½ia erorii. Pe de alt_
parte, o defec½iune într-un echipament critic, cum ar fi transponderele de
telecomunica½ii de pe sateli½ii artificiali, ar determina c_derea unor întregi
sisteme, ceea ce este inadmisibil. În astfel de cazuri, func½ionarea satisf_c_toare
impune o fiabilitate de 100%.

Durata timpului de func½ionare pentru un sistem de comutare telefonic_ este,

pur úi simplu, durata de de via½_ a echipamentului care a fost folosit în sistem.
Sistemul de comutare trebuie s_ func½ioneze continuu, f_r_ întreruperi, pân_
când echipamentul este înlocuit la sfârúitul vie½ii lui sau este îndep_rtat pentru
orice alt motiv. Deoarece servirea trebuie s_ fie asigurat_ 24 de ore pe zi, nu
poate s_ existe timp programat pentru repara½ii sau pentru între½inere, timp în
care sistemul s_ fie neopera½ional. Obiectivul fiabilit_½ii de trei minute de
neoperare pe an (dou_ ore de nefunc½ionare în patruzeci de ani) úi MTTR-ul
de patru ore pot fi traduúi într-o disponibilitate de sistem de 99,9995%.

În contrast, aplica½ii critice pentru controlul avioanelor, ca în cazul lui SIFT

(Software-Implemented Fault Tolerance) úi FTMP (Fault-Tolerant MultiPro-
cessor), pretind fiabilitate ultraînalt_. Parametrii proiect_rii cer ca sistemul
s_ treac_ prin mai pu½in de 10-9 deterior_ri în timpul unei misiuni de 10 ore
cu un MTTR de 10 ore. Factorul de disponibilitate este egal, în aceast_ situa½ie,
cu 99,9999999%.

Cerin½ele fiabilit_½ii determin_ într-un grad mai mare arhitectura sistemului,

tipul úi cantitatea de redundan½_ precum úi costul sistemului. Redundan½a dual_
se dovedeúte a fi adecvat_ aplica½iilor telefonice. Pe de alt_ parte, pentru

18
controlul critic al avioanelor, triplarea cu rezerv_ este necesar_ pentru a achita
un grad mare de fiabilitate.

2.1.7 Tehnici de redundan½_

Defec½iunile hardware pot afecta secven½ele de comand_ sau cuvintele de date

care se afl_ în interiorul maúinii. Acest lucru duce la dou_ tipuri de erori:

a) secven½a programului este neschimbat_, dar defec½iunea a afectat

rezultatele finale;

b) secven½a programului este schimbat_, iar programul nu mai execut_

algoritmul specificat.

Erorile software sunt rezultatul unor traduceri (translat_ri) greúite sau ale unor
implement_ri improprii ale algoritmilor originali úi, de asemenea, deviaz_
execu½ia instruc½iunilor de la secven½a corect_. În multe situa½ii, din p_cate,
defec½iunile hardware nu pot fi distinse de cele software. Din acest motiv,
sistemele trebuie s_ fie tolerante la defec½iuni, indiferent de sursa acestora.

O modalitate bun_ de a produce calculatoare tolerante la defecte este aceea

de a introduce redundan½a prin multiplicarea p_r½ilor lor. Redundan½a permite
calculatoarelor s_ ocoleasc_ erorile, în felul acesta rezultatele fiind corecte.
Aceast_ metod_ este cunoscut_ ca redundan½_ de protec½ie, fiind compus_ din
redundan½e hardware, software úi de timp.

Redundan½a hardware este constituit_ din componente adi½ionale, care

detecteaz_ úi corecteaz_ erorile. Performan½a este superioar_ celorlaltor dou_
tipuri de redundan½_, îns_ úi costurile implement_rii sunt sensibil mai mari.

Redundan½a software con½ine programe adi½ionale, care au capacitatea de a

restabili func½ionalitatea sistemului, în condi½ii problematice. De asemenea,

19
mai poate con½ine programe de detec½ie a erorilor, de diagnoz_ úi de
autocontrol, prin care s_ testeze periodic toate circuitele logice ale calcula-
torului.

Redundan½a temporal_ este ob½inut_ prin repetarea unei opera½ii eronate, imediat
dup_ repetarea unei erori. Redundan½a temporal_ se implementeaz_ adesea prin
hardware. De exemplu, logica hardware poate ini½ia recitirea automat_ a unei
loca½ii de memorie în care s-a detectat o eroare de paritate.

Chiar dac_ redundan½a de protec½ie este clasificat_ func½ional în trei tipuri

diferite, în practic_ ele se contopesc adesea, pentru asigurarea unei fiabilit_½i
sporite. În cazul redundan½ei software, programul de control are nevoie atât
de spa½iu de memorie (hardware), cât úi de timp de execu½ie

Fiecare dintre aceste tipuri de redundan½_, precum úi diferitele lor combina½ii,

au fost folosite în proiectarea calculatoarelor tolerante la defec½iuni. Prioritatea
acordat_ la implementare unuia dintre tipurile de redundan½_ enumerate mai
sus se face în func½ie de tipul aplica½iei úi de restric½iile impuse de costuri, de
cerin½ele de timp úi de cerin½ele de fiabilitate.

2.2 Metode de autocontrol, implementate hardware

Atât structura redundan½ei dinamice cât úi cea a redundan½ei statice, descrise

mai sus, sunt metode care folosesc p_r½i de rezerv_ pentru a face sistemul
capabil s_ tolereze defec½iunile. Atunci când se foloseúte redundan½a static_,
unit_½ile de rezerv_ (circuite, componente sau subsisteme) sunt p_r½i permanent
active ale sistemului. Ele corecteaz_ erorile sau le mascheaz_ împiedicând,
astfel, propagarea lor în sistem. Func½ia masc_rii intervine automat, iar ac½iunea
de corectare este imediat_ úi încorporat_ (wired in). Tipuri statice de redundan½_
au fost folosite, mai întâi, în aplica½iile militare care pretindeau o înalt_
fiabilitate pentru o perioad_ scurt_ de timp, iar, mai recent, în aplica½iile

20
comerciale. Redundan½a dinamic_, la care subsistemele adi½ionale servesc ca
rezerve în interiorul sistemului, s-a folosit în aplica½iile comerciale.

Componentele majore ale toler_rii defec½iunilor sunt: detectarea erorii,

diagnosticarea erorii (izolarea), restabilirea úi repararea. În cazul redundan½ei
dinamice, cea mai important_ component_ este detectarea erorii. Dac_ toate
erorile ar fi detectate úi s-ar aplica tehnicile corespunz_toare de restabilire,
atunci nici o defec½iune n-ar conduce sistemul la deteriorare. Din p_cate,
aceast_ acoperire nu se poate realiza în practic_.

Viteza detect_rii erorii influen½eaz_ procesul de localizare a defec½iunii úi

st_pânirea ei. De asemenea, este important s_ se realizeze cât mai repede
urm_torul pas, mânuirea sau izolarea defec½iunii, astfel încât defec½iunea s_
nu se propage. Detectarea întârziat_ poate deforma date importante în tot
sistemul. Viteza detect_rii este, de asemenea, important_ pentru localizarea
sursei de erori: cu cât întârzierea este mai mare, cu atât este mai greu s_ se
g_seasc_ sursa. Diagnosticarea incorect_ împiedic_ rezervele func½ionale de
la înlocuirea corect_ a unit_½ilor defecte. Mai mult decât atât, viteza de detectare
afecteaz_ direct revenirea sistemului.

În general, detec½ia erorii este realizat_ prin utilizarea de hardware, firmware

úi software. Tipul schemelor de control utilizate depinde atât de structura logic_
a maúinii cât úi de utilizarea opera½ional_ úi func½ional_ a datelor úi a semnalelor
de comand_.

Schemele hardware de detectare a erorii încorporate într-un sistem de calcul

pot avea mai multe forme. Majoritatea acestor tehnici se încadreaz_ în
clasificarea urm_toare:

a) controale prin copii (replication checks);

b) controale de codificare (coding checks);

c) controale de temporizare (timing checks);

21
 d) controale de excep½ii (exception checks).

Detectarea erorii poate fi amplasat_ strategic în interiorul unei unit_½i

func½ionale sau la interfa½_. Este mai avantajos dac_ detec½ia erorii se face
intern, la stadiul ei timpuriu, în timpul func½ion_rii sistemului care genereaz_
rezultatele.

Controalele interne sau timpurii minimizeaz_ cantitatea activit_½ii sistemului

úi tranzi½iile eronate cauzate de o defec½iune. Astfel, nu este timp suficient
pentru a se propaga defec½iunea în interiorul sistemului, iar ac½iunile necesare
pentru izolarea ei úi pentru revenire la normal vor fi, probabil, mai simple. Pe
de alt_ parte controalele de interfa½_ sau cele de ultimul moment sunt activate
înainte de a se transmite orice fel de rezultat de la o unitate func½ional_ la alta.
Acest fapt împiedic_ propagarea erorilor în exterior spre o alt_ unitate
func½ional_ úi simplific_ cea mai dificil_ problem_, úi anume revenirea global_.
Eroarea este con½inut_ în interiorul nivelului în care a fost detectat_.

2.2.1 Controlul prin copii

Controlul prin copii este una dintre cele mai complete metode de detectare
a erorilor dintr-un sistem de calcul. Din cauza echipamentului hardware
necesar, aceast_ metod_ este, de asemenea, úi cea mai costisitoare tehnic_ de
redundan½_. Num_rul copiilor dintr-un sistem nu trebuie s_ fie limitat la doi.
Atunci când trei sau mai multe copii ale unui sistem sunt implicate, controlul
compar_rii este referit ca votare. Votarea asigur_ suprimarea unei ieúiri eronate
prin mascarea în favoarea majorit_½ii ieúirilor. Un exemplu de controlare prin
copii într-un sistem de redundan½_ tripl_, modular_ este FTMP (Fault Tolerant
Multiple Processor) dezvoltat pentru calculatoarele avioanelor.

Controalele prin copii bazate pe copii identice ale unui sistem nu detecteaz_
consecin½ele greúelilor de proiectare, deoarece sunt afectate toate copiile

22
unit_½ii. Din acest motiv, este necesar_ apelarea la tehnici formale de verificare
a proiect_rii astfel încât s_ se asigure c_ nu exist_ greúeli de proiectare în
structur_ care ar putea ocoli protec½ia realizat_ de copiere.

Mahmood úi McCluskey prezint_ câteva tehnici de detec½ie a erorilor bazate

pe utilizarea unui procesor watchdog. Acest procesor, care poate fi numit
coprocesor de control, este mai pu½in complex decât procesorul principal úi
detecteaz_ erorile prin monitorizarea comportamentului sistemului. Informa½ia
furnizat_ c_tre coprocesorul de control poate fi legat_ de comportamentul
acceselor la memorie, cursul comenzilor, semnalele de comand_ sau chiar de
justificarea rezultatelor. Asemenea duplic_rii, pentru detec½ia erorilor, aceast_
tehnic_ nu depinde de modelul de defec½iuni adoptat úi are, în schimb, avantajul
c_ necesit_ mai pu½in hardware.

2.2.2 Controale de codificare

Codurile detectoarelor de erori se formeaz_ prin ad_ugarea unor bi½i de control

la un cuvânt de date. În acest caz, capacitatea de detec½ie a erorilor este direct
propor½ional_ cu num_rul de bi½i de control incluúi într-un cuvânt. Exist_ dou_
tipuri de controale de codificare: separabile úi neseparabile. În literatura de
specialitate, ele mai poart_ denumirea de controale de codificare sistematice
úi nesistematice. Controalele separabile (separable checks), cum sunt controlul
de paritate úi codurile aritmetice, sunt caracterizate prin ad_ugarea bi½ilor de
control la cuvintele de date. Controalele neseparabile (nonseparable checks),
cum este codul m-din-n, sunt codificate în formate specializate.

2.2.3 Controale de temporizare

Controlul de temporizare este o form_ eficace de a controla software-ul pentru

detec½ia erorilor în programele duplicate, atunci când specifica½ia unei
componente include constrângeri de timp.

23
Un temporizator hardware, numit úi watch-dog timer, este folosit în sisteme
de comutare telefonic_ pentru ap_rarea împotriva erorilor de programare din
cauza c_rora sistemul nu-úi mai poate reveni. Conceptul este relativ simplu.
Un ceas hardware merge continuu în procesor úi este resetat periodic de c_tre
programul principal dac_ nu se întâmpl_ nimic neobiúnuit care s_ devieze
programul din secven½a lui normal_ de execu½ie.

Dac_ dintr-un anumit motiv (eroare software sau defec½iune hardware) secven½a
execu½iei nu se mai întoarce la programul principal, ceasul nu se reseteaz_.
În aceast_ situa½ie, ceasul pune în circula½ie o cerere de întrerupere de înalt_
prioritate úi întreprinde ac½iunile necesare reini½ializ_rii sistemului. În cazul
în care exist_ în sistem înc_ un procesor stand-by, întreruperea ceasului poate
produce comutarea automat_ a controlului pe maúin_ stand-by, într-o tentativ_
de revenire din eroarea de time-out.

Controalele de temporizare asupra func½ion_rii unui circuit nu sunt controale

complete pentru sistem. Ele relev_ prezen½a defec½iunilor (erorilor), dar nu úi
absen½a lor. Ca urmare, arhitec½ii calculatoarelor folosesc controalele de
temporizare ca s_ suplimenteze alte controale úi ca s_ acopere un procent mai
mare de defec½iuni ale unui sistem.

2.2.4 Controale de excep½ie

Programele ruleaz_ în medii protejate folosind seturi de constrângeri

prestabilite. Dac_ programele nu con½in erori, ele ½in cont de aceste constrângeri
úi îúi realizeaz_ în mod corespunz_tor func½iile specificate. Totuúi, greúelile
de proiectare din software violeaz_, adesea, aceste constrângeri, influen½ând,
în mod nefavorabil, întregul sistem. Unele circuite hardware de detec½ie sunt
adesea proiectate în sistem pentru a recunoaúte erorile de proiectare úi pentru
a le trata ca excep½ii. Deci, tratarea excep½iilor se refer_ la detectarea úi
„mânuirea“ evenimentelor anormale úi nedorite.

24
Constrângerile pot fi atribuite structurii hardware sau celei software. Exemple
de constrângeri hardware sunt: alinierea improprie de adrese, loca½ii de
memorii neechipate, opcod neutilizat, dep_úirea stivei etc. Structura software
pune, de asemenea, câteva constrângeri sistemului pentru a-i îmbun_t_½i
rezisten½a úi pentru a furniza un mediu protejat programelor de aplica½ii.

Câteva controale software de excep½ie sunt: execu½ia ilegal_ a instruc½iunilor

privilegiate, dep_úirea de adres_ (out of range), violarea memoriei (memory
acces violation), operanzi ilegali, opera½ii aritmetice necorespunz_toare,
dep_úirea sau împ_r½irea cu zero.

Detectarea unei erori ini½iaz_ o excep½ie care este urmat_ de invocarea automat_
a subrutinei de mânuire a excep½iei respective. În multe cazuri, excep½ia este
atribuit_ unei greúeli de proiectare a programului.

2.2.5 Restabilirea erorii

Restabilirea este cea mai complex_ úi mai dificil_ func½ie pentru toate sistemele
din cauza multitudinii st_rilor posibile ale sistemului care pot s_ apar_ sub
condi½ii problematice. Neajunsurile proiect_rii hardware sau software de a
detecta erorile atunci când apar au un efect direct asupra abilit_½ii sistemului
de a se restabili. Când erorile continu_ s_ fie nedetectate, sistemul r_mâne
defect pân_ când problema este recunoscut_. Un alt tip de restabilire apare
atunci când sistemul nu este capabil s_ izoleze corespunz_tor un subsistem
defect úi s_ reconfigureze, în jurul lui, un sistem opera½ional. Detectarea cât
mai rapid_ a unei erori uúureaz_ determinarea componentei defecte úi
restabilirea sistemului. Deci, detectarea rapid_ a erorii úi izolarea ei sunt
condi½iile fundamentale ale restabilirii.

25
 2.2.5.1 Clasificarea procedurilor de restabilire

Exist_ trei clase de proceduri de restabilire: restabilirea total_ (full recovery),

restabilirea degradat_ (degraded recovery) úi închiderea pentru salvare (safe
shutdown). Procedurile de restabilire pot fi invocate automat (f_r_ nici o
interac½iune între operatorul de între½inere úi sistem) sau manual. Restabilirile
ini½iate manual fac uz de secven½e vaste, controlate prin program.

2.2.5.1.1 Restabilirea total_

Într-o facilitate de timp real, sistemul care furnizeaz_ servicii în mod continuu
trebuie s_ r_mân_ opera½ional chiar úi într-un mediu defect. Aceasta înseamn_
c_ simptomele trebuie s_ fie recunoscute repede úi unit_½ile defecte trebuie
s_ fie reparate cu pu½in_ sau chiar f_r_ interven½ie din partea utilizatorului.

Pentru a dispune de sistem — tot timpul úi la întreaga capacitate —

subsistemele corespunz_toare de schimb trebuie s_ fie disponibile ca unit_½i
de înlocuire pentru cele defecte.

O procedur_ de restabilire total_ are nevoie, în mod obiúnuit, de toate cele cinci
aspecte ale calcul_rii tolerante la defecte: detectarea erorii, izolarea erorii,
restabilirea sistemului, diagnosticarea erorii úi repararea ei. Perioada de
întrerupere a servirii, în timpul procesului de restabilire, este minimizat_ úi,
de obicei, nu este observat_ de c_tre utilizator.

Diagnosticarea úi repararea, care consum_ cel mai mult timp în cadrul

procedurii de restabilire, pot fi amânate úi intercalate printre opera½iunile
normale ale sistemului.

26
 2.2.5.1.2 Restabilirea degradat_

Ca úi în cazul restabilirii totale, to½i paúii implica½i în tolerarea defec½iunii

(detectare, izolare, restabilirea sistemului, diagnoz_ úi reparare) trebuie s_ fie
incluúi în procedur_. Aceeaúi secven½_ de evenimente apare la procedura
degradat_, exceptând faptul c_, în acest caz, nu se cupleaz_ alt subsistem în
locul celui defect. În schimb, componenta defect_ este scoas_ din func½ie úi
sistemul se întoarce la o stare opera½ional_ f_r_ defec½iuni. Func½iile de
calculare selectate sunt l_sate s_ opereze în sisteme care utilizeaz_ proceduri
de restabilire degradat_, iar din aceast_ cauz_ caracteristicile performan½ei lor
în timp real scad sub un standard normal acceptat pân_ când se realizeaz_
repara½iile corespunz_toare.

2.2.5.1.3 Închiderea pentru salvare

Aceasta este, adesea, denumit_ úi opera½ie de salvare din malfunc½ionare

(fail-safe operation). Ea apare ca un caz limit_ al restabilirii degradate, când
capacitatea de calcul a sistemului a sc_zut sub limita minim_ acceptabil_ a
opera½iei. Scopurile închiderii pentru salvare sunt:

a) evitarea distrugerii elementelor sistemului sau a modulelor software

stocate (programe sau date) care mai pot fi compromise dup_ ce
a intervenit opera½ia de restabilire degradat_;

b) încetarea interac½iunii cu orice sistem asociat (utilizator) într-un mod

ordonat;

c) distribuirea diagnosticului úi a mesajelor de închidere la utilizatori,

la anumite sisteme úi la personalul de între½inere.

27
Categoria procedurii de închidere pentru salvare este similar_ unui sistem f_r_
redundan½_. Ac½iunea de izolare a defec½iunii trebuie s_ fie ini½iat_ pentru a
se determina identitatea ei úi locul în care se afl_. Func½ionarea normal_ a
sistemului, care a fost întrerupt_ la momentul derect_rii defec½iunii, trebuie
s_ fie, acum, suspendat_ datorit_ diagnozei úi repar_rii. Sistemul trebuie s_
fie restabilit, atât din punct de vedere hardware, cât úi software, astfel încât
s_-úi poat_ relua procesarea normal_.

2.2.5.2 Reconfigurarea

În sistemele redundante, un ansamblu de piese de schimb sau de unit_½i

multifunc½ionale asigur_ continuitatea func½ion_rii sistemului. Structura cea
mai simpl_ este configura½ia duplex, în care fiecare unitate func½ional_ este
duplicat_. Dac_ una dintre unit_½i se defecteaz_, unitatea duplicat_ se cupleaz_
p_strând, astfel, continuitatea func½ion_rii, în timp ce unitatea defect_ se repar_.
În timpul perioadei de repara½ie poate s_ apar_ o defec½iune în unitatea
duplicat_, caz în care întregul sistem se va deteriora. Dac_ intervalul de
repara½ie este scurt, atunci probabilitatea de defectare, simultan_, a dou_ unit_½i
identice este foarte mic_.

Configura½ia duplex cu o singur_ unitate poate fi parti½ionat_ într-o configura½ie

duplex multi-unitate. În acest aranjament, fiecare subunitate con½ine un num_r
mic de componente care pot fi comutate într-un sistem în lucru. Sistemul va
pica numai dac_ o eroare apare în subunitatea redundant_, în timp ce
subunitatea original_ este supus_ repara½iei. Din moment ce fiecare subunitate
con½ine câteva componente, probabilitatea de apari½ie a defec½iunilor simultane
într-o pereche dubl_ de subunit_½i este redus_.

28
2.3 Metode de autocontrol implementate software

Necesitatea dezvolt_rii mecanismelor software pentru detectarea erorilor de

programare este foarte acut_ atunci când se pune problema construirii unor
sisteme fiabile. Mecanismele hardware, chiar dac_ sunt foarte avansate din
punct de vedere tehnologic, nu sunt specializate în analiza erorilor software.

Spre deosebire de ratele de deteriorare ale componentelor hardware, despre

comportamentul úi distribu½ia erorilor de programare nu exist_ statistici de
încredere. Detec½ia erorilor software se poate realiza numai prin recunoaúterea
comportamentului anormal al sistemului.

Pentru detectarea eventualelor devieri, este nevoie de un set de standarde pentru

descrierea comportamentului normal. Prin controlarea motiva½iilor comport_rii
programului în anumite stadii ale calcul_rii, se reuúeúte detectarea rapid_ a
erorilor úi limitarea propag_rii detelor eronate.

Exist_ mai multe tehnici generale pentru urm_rirea comportamentului unui

sistem de calcul úi detectarea devierilor de la comportamentul normal. Printre
acestea sunt: func½ia unui proces, secven½a de comand_ a unui proces, date de
proces. Un proces este definit, aici, ca fiind o por½iune de calcule de sine
st_t_toare, care, o dat_ ini½iat_, se realizeaz_ complet f_r_ a mai avea nevoie
de intr_ri adi½ionale.

2.3.1 Func½ia unui proces

Motivarea ieúirilor pentru un set dat de intr_ri este controlat_ la nivelul blocului
func½ional. Anumite m_suri de performan½_ pot fi folosite pentru a se indica
func½ionarea corespunz_toare. Atunci când înc_rcarea aplicat_ este normal_,

29
dar m_sur_torile care caracterizeaz_ performan½a sistemului (timpul de r_spuns,
debitul úi timpul necesar pentru a se realiza o func½ie standard) sunt în afara
valorilor limit_, sistemul are, probabil, una sau mai multe erori.

2.3.2 Secven½a de comand_ a unui proces

Calculele f_cute de c_tre un proces aflat în execu½ie sunt denumite secven½_

de comand_ (control sequence). Fiecare calcul schimb_ multe st_ri ale
sistemului úi detecteaz_ multe dintre neregulile acestuia. Este evident c_ logica
necesar_ calcului secven½ei de comand_ trebuie s_ fie cât mai fiabil_, pentru
a nu constitui ea îns_úi o surs_ suplimentar_ de erori.

2.3.3 Date de proces

Integritatea datelor unui sistem úi structura lui pot fi observate în timp ce

sistemul execut_ secven½a programului, adic_ în timpul func½ion_rii normale
a sistemului. Deteriorarea datelor poate fi cauzat_ atât de o defec½iune
hardware, cât úi de o eroare software.

2.3.4 Restabilirea software

Obiectivul restabilirii dup_ o eroare este revenirea sistemului la o stare

consecvent_ úi la o func½ionare corespunz_toare.

30
Exist_ trei strategii de restabilire:

a) restabilirea cu întoarcere (backward error recovery);

b) restabilirea cu salt înainte (forward error recovery);

c) reini½ializarea (reset-ul).

2.3.5 Diagnosticarea erorii

¼inând cont c_ detectarea erorii determin_ corectitudinea func½ion_rii unui

circuit, diagnoza erorii localizeaz_ defec½iunea la o unitate înlocuibil_. Unitatea
înlocuibil_ poate fi o component_, un circuit sau un subsistem. Rutina de
diagnosticare a erorii utilizeaz_ hardware pentru detectarea erorii úi secven½e
de test în scopul localiz_rii unit_½ii defecte. Dac_ sursa erorii o constituie o
singur_ entitate, atunci defec½iunea este corectat_, simplu, prin înlocuirea
entit_½ii respective, f_r_ s_ mai fie necesar_ diagnoza. Dac_ circuitul de detec½ie
este mai pu½in specializat, atunci rutina de diagnosticare a erorii poate fi
solicitat_ la izolarea, în continuare, a unit_½ii afectate.

2.3.6 Validarea fiabilit_½ii

Cele mai dificile sarcini ale proiect_rii între½inerii sunt: restabilirea sistemului
úi diagnosticarea. Eficacitatea lor poate fi determinat_ prin simularea modului
de comportare a sistemului în prezen½a unei anumite defec½iuni. Prin
intermediul simul_rii deficien½ele proiect_rii pot fi identificate úi corectate
înainte de a se da sistemul spre utilizare. Este necesar s_ se evalueze abilitatea
sistemului la detectarea erorilor, la revenirea automat_ la func½ionarea normal_

31
úi la furnizarea informa½iei de diagnoz_ (de exemplu: loca½ia defec½iunii).
Simularea, fizic_ sau digital_, a defec½iunii este un aspect important al
proiect_rii între½inerii.

32
 3 AUTOCONTROLUL CA MIJLOC DE
CREùTERE A FIABILIT^¼II ùI
DISPONIBILIT^¼II SISTEMELOR DE
CALCUL

3.1 Metode de autocontrol aplicate la diferite niveluri de

structur_

3.1.1 Caracteristicile metodelor de proiectare structurat_ la nivel de

bistabil

Progresele recente din tehnologia VLSI au avut o mare influen½_ asupra test_rii
sistemelor digitale (numerice). Sistemele digitale de ast_zi au de la o sut_ de
mii pân_ la un milion de por½i de logic_ aleatoare úi de celule de memorie, ceea
ce face ca generarea testului úi simularea defec½iunilor s_ fie extrem de dificile.
Chiar dac_ se pot folosi maúini hardware dedicate sau super-computere pentru
a genera teste eficace, costul acestora face imposibil_ aplicarea lor în practic_.
Pentru a se dep_úi aceast_ problem_, cercetarea s-a îndreptat c_tre g_sirea altor
metode de testare a sistemelor digitale, incluzând proiectarea pentru testabilitate
úi generarea de test la nivel func½ional (simularea defec½iunilor).

33
 Figura 1. Modelul Huffman al tehnicii SCAN.

Dintre toate tehnicile propuse pân_ în prezent, proiectarea pentru testabilitate

(DFT, Design For Testability) este cea mai renumit_, iar dintre toate tehnicile
DFT, cea mai folosit_ este tehnica scan_rii (scan-design). În tehnica scan_rii
(i se mai spune tehnic_ sau metod_ SCAN), bistabilele sunt conectate într-un
circuit serial úi sunt folosite ca terminale de tip I/O. Prin aplicarea tehnicii de
scanare putem transforma un circuit secven½ial în unul combina½ional, f_când
astfel mai simpl_ generarea pattern-urilor de test pentru circuit. De asemenea,
se poate parti½iona logic circuitul în câteva subcircuite úi se pot genera, pentru
fiecare în parte, pattern-urile de test.

Firma NEC a aplicat cu succes tehnica proiect_rii de scanare la sistemele

comerciale de calcul. Tehnica numit_ „cale de scanare“ (scan-path) a fost
implementat_ de la nivel de capsul_ la nivel de sistem úi a devenit o ustensil_
puternic_ pentru testarea úi diagnoza sistemelor de calcul VLSI. Conceptul
scan in/scan out, care st_ la baza tehnicii de scanare, a fost introdus pentru
prima dat_ de c_tre Carter s.a. pentru dezvoltarea testelor de localizare a

34
defec½iunilor la sisteme IBM 360. NEC a dezvoltat metoda c_ii de scanare
pentru a rezolva unele probleme, cum ar fi utilizarea intensiv_ a MSI/LSI din
sistemele comerciale de calcul, precum úi num_rul mare de por½i aflate pe
pl_cile acestor sisteme.

Metoda c_ii de scanare pare s_ fie o solu½ie promi½_toare pentru rezolvarea

acestor probleme, deoarece permite mai mult_ controlabilitate úi observabilitate
asupra circuitului supus test_rii. În plus, se pot testa atât circuitele combina-
½ionale cât úi cele secven½iale. Conceptele de controlabilitate úi observabilitate
se definesc în felul urm_tor:

a) Controlabilitatea arat_ cât de uúor se poate produce un semnal

arbitrar, valid la intr_rile unei componente (subcircuit) prin
excitarea intr_rilor primare ale circuitului. De fapt, ea reprezint_
abilitatea de a comanda un semnal doar prin intermediul intr_rilor
primare. O linie care poate fi pozi½ionat_ pe „1“ logic se numeúte
1-controlabil_, alt_ linie care poate fi pozi½ionat_ pe „0“ logic se
numeúte 0-controlabil_, iar linia care poate avea ambele st_ri
logice se numeúte complet controlabil_;

b) Observabilitatea arat_ cât de uúor se poate determina la ieúirile

primare ale circuitului ceea ce se întâmpl_ la ieúirile unei compo-
nente (subcircuit). Cu alte cuvinte, ea este abilitatea activ_rii unei
c_i de la semnalul cercetat pân_ la un punct m_surabil.

Prin componente se în½eleg fie circuite integrate standard (SSI úi MSI) pentru
circuite la nivel de plac_, fie celule standard de module de bibliotec_ pentru
circuite LSI úi VLSI. De asemenea, se presupune c_ mai multe componente
sunt conectate cu leg_turi unidirec½ionale.

Circuitul testat prin metoda c_ii de scanare poate fi parti½ionat logic în mai
multe subcircuite, iar programele de test pot fi generate, independent pentru
fiecare subcircuit. Costul total al întregului circuit scade la .2 / n , unde n este
num_rul de subcircuite, iar . este rata de suprapunere. Tabelul urm_tor arat_
o compara½ie între m_rime úi cost.

35
 Denumire M_rime Cost
Circuit original 1 1
Subcircuit . /n (. / n )2

Circuit expandat . .2 / n

Evident c_ . depinde de n úi, din acest motiv, proiectan½ii trebuie s_ decid_

cu aten½ie num_rul de subcircuite necesare. Pentru un circuit bine proiectat,
care este preg_tit pentru parti½ionare, valoarea lui . este sub 1,7. Calea de
scanare poate facilita localizarea defec½iunii pentru c_ procesorul de diagnoz_
poate s_ urm_reasc_ uúor starea intern_ a sistemului. Hardware-ul adi½ional
este foarte pu½in (de la 4% la 10%) úi este potrivit pentru un calculator VLSI
deoarece necesit_ relativ pu½ini pini adi½ionali de I/O.

Figura 2. Tehnic_ SCAN bazat_ pe registre

de deplasare.

Bistabilul transformat cu cale de scanare, utilizat ca úi circuitul de baz_, include

dou_ tipuri de semnale de clock, C1 pentru opera½ia normal_ úi C2 pentru

36
opera½ia de deplasare. Astfel, bistabilele unei pl_ci logice sunt conectate în
serie printr-o cale de scanare úi opereaz_ ca un registru serial de deplasare
utilizând Clock II, intrarea de test (scan in) úi ieúirea de test (scan out).
Utilizând o adres_ de selec½ie a pl_cii logice, putem selecta o anumit_ plac_
dintr-o unitate logic_.

Chiar dac_ tehnica scan_rii este o tehnic_ DFT puternic_, pentru testarea logicii
aleatoare, aplicarea ei poate pune probleme în diferite tipuri de circuite. Un
astfel de tip sunt úirurile de memorie încorporate în circuite de logic_ aleatoare.
Aplicarea direct_ a tehnicii de scanare la fiecare celul_ de memorie din úir cost_
foarte mult. O solu½ie posibil_ este aplicarea tehnicii de scanare la un anumit
cuvânt din úirul de memorie úi accesarea cuvântului fixat în timpul test_rii
circuitului. Oricum, din moment ce, în timpul test_rii, memoria func½ioneaz_
ca un registru, ea trebuie testat_ utilizând alt_ procedur_.

Tehnica scan_rii s-a dovedit foarte eficace pentru proiectarea circuitelor

bipolare, dar este greu de aplicat la un circuit MOS úi mai ales la un circuit
MOS dinamic. Dificultatea apare, în primul rând, din cauza hardware-ului
adi½ional. Un bistabil MOS dinamic este limitat la câteva tranzistoare úi
supraînc_rcarea hardware-ului adi½ional este mare pentru un circuit VLSI MOS.

Figura 3. Element SRL în

tehnica LSSD.

IBM introduce tehnica LSSD (Level Sensitive Scan Design) care include
tehnica scan_rii úi, în plus, impune ca toate schimb_rile de stare s_ fie controlate
de nivelul semnalului de ceas úi nu de frontul s_u (Level Sensitive Design).
Aceast_ abordare reduce dependen½a func½ion_rii de timpii de propagare,
eliminând cursele sau hazardul. Celula de baz_ este elementul de memorare

37
a informa½iei, dependent de nivel, care asigur_ úi tratarea semnalului de scan
în modul test, element numit SRL (Shift Register Latch).

3.1.2 Caracteristicile metodelor de proiectare structurat_ la nivel de

registru

Deúi s-au scris foarte multe despre standardul de test boundary-scan

(IEEE 1149.1 Standard Test Acces Port and Boundary-Scan Architecture),
doar câtorva dispozitive li s-a implementat aceast_ arhitectur_. Acordarea
complet_ cu acest standard, ceea ce înseamn_ c_ proiectan½ii ar putea s_
foloseasc_ orice dispozitiv, cu asigurarea c_ este compatibil cu boundary-scan,
va ap_rea numai dup_ câ½iva ani. Pân_ atunci, pl_cile cu cablaj imprimat vor
fi hibride, con½inând circuite (dispozitive) scanabile (dup_ standardul IEEE)
úi dispozitive nescanabile. Aceste pl_ci necesit_ metodologii de testare bazate
pe ambele tehnici: pat de cuie (bed of nails) úi boundary-scan.

Figura 4. Principiul Boundary Scan.

Testarea cu boundary-scan poate micúora drastic timpul de dezvoltare al

sistemelor complexe. De asemenea, ea ofer_ posibilitatea test_rii sistemelor
care utilizeaz_ componente cu montare la suprafa½_ de mare densitate úi pl_ci
multistrat complexe. Ast_zi, aceste sisteme se pot testa cu ajutorul tehnicii
patului de cuie, dar exist_ probleme din cauza geometriei micúorate a pinilor,
geometrie impus_ de tehnologia mont_rii la suprafa½_. ùi în acest caz, având

38
unelte potrivite úi dispozitive de sus½inere pentru boundary-scan, toat_ placa
poate fi testat_ complet, folosind numai calea boundary-scan.

Figura 5. Schema celulei Boundary Scan.

Pe de alt_ parte, patul de cuie úi, în general, metodele de testare în circuit
(in-circuit) ofer_ câteva avantaje importante spre deosebire de boundary-scan.
Un astfel de avantaj cheie al test_rii în circuit este abilitatea diagnozei
deterior_rilor multiple la o singur_ trecere prin test. În plus, detectarea
scurt-circuitelor poate fi realizat_ înainte de punerea sub tensiune a pl_cii,
reducând posibilitatea deterior_rii catastrofale cauzate de acestea între pini
úi tensiunea de alimentare. De asemenea, testele în circuit permit realizarea
simultan_ a test_rii parametrice cu cea digital_.

Figura 6. Testarea interconect_rii

cu Boundary Scan.

Boundary-scan, în general, nu se refer_ la testarea dispozitivelor analogice

sau pasive. Contrar impresiei larg r_spândite, boundary-scan este compatibil

39
cu testarea în circuit úi folosind o combina½ie a celor dou_ se poate simplifica
semnificativ testarea pl_cilor.

Dispozitivul XC4005 FPGA este primul dintr-o familie de circuite compatibile

cu standardul boundary-scan. Fiecare pin de I/O al acestui dispozitiv poate
fi complet controlat úi observat prin utilizarea unor úabloane (pattern) de date
introduse serial în registrul de boundary-scan al lui XC4005 prin pinul TDI
(Test Data Input) úi prin controlul prin pinii TMS (Test Mode Select) úi TCK
(Test Clock) proveni½i din canalele ATE (Automatic Test Equipment). Acest
lucru este echivalent cu stimularea complex_ a intr_rilor pentru a ob½ine aceeaúi
acoperire de test f_r_ boundary-scan.

Figura 7. Testarea
Boundary Scan la
nivel de cip.

3.1.3 Proiectarea structurat_ la nivel de bloc

Încorporarea facilit_½ilor de test (BIT, Built-In Test) poate micúora considerabil

timpul de între½inere úi costurile pentru sistemele electronice complexe prin
accelerarea detec½iei úi izol_rii defec½iunilor. La nivel de plac_, testul încorporat
(BIT) se realizeaz_, de obicei, prin aplicarea unui set de pattern-uri
pseudo-aleatoare pentru a se verifica existen½a defec½iunilor úi prin compri-
marea informa½iei r_spunsului de test pentru a se ob½ine o semn_tur_. Aceste
tehnici sunt eficace pentru pl_cile utilizate în scopuri generale atât timp cât

40
seturile de cipuri care se testeaz_ reac½ioneaz_ la cele dou_ tehnici, dând rar
semn_turi identice pentru pl_ci bune sau defecte.

Figura 8. Principiul unui circuit autotestabil.

Not_: McCluskey precizeaz_ c_ nu este recomandat_ utilizarea expresiei

test-response compression ca un sinonim al expresiei test-res-
ponse compaction, deoarece prin compactare se pierde din
informa½ie, în timp ce prin comprimare se elimin_ doar redun-
dan½a, f_r_ pierderea informa½iei. În majoritatea literaturii de
specialitate pe care am consultat-o nu este respectat_ aceast_
opinie. Din aceast_ cauz_, precum úi datorit_ faptului c_ în limba
român_, când este vorba despre reducerea volumului secven½elor
binare r_spuns, este consacrat termenul de comprimare, în
continuare voi folosi denumirea „comprimare“.

41
 3.1.3.1 Autocontrolul bazat pe principiul BILBO

Tehnica de determinare a st_rii unui cip sau a unei pl_ci prin folosirea
informa½iei comprimate a r_spunsului de test se numeúte analiza semn_turii.
În general, metodele de analiz_ a semn_turii pentru testarea pl_cilor utilizeaz_
circuite cu observatori logici, de bloc, încorpora½i (BILBO, Built-In-Logic
Block Observers) pentru a genera úabloane pseudoaleatoare úi pentru a
comprima r_spunsurile. BILBO este, deci, o schem_ încorporat_ de generare
a testului care utilizeaz_, în conjunc½ie scan-designul cu analiza de semn_turi.
Componenta de baz_ a acestei tehnici de autotest este un registru de deplasare
numit registru BILBO care are patru moduri de func½ionare.

Figura 9. Principiul BILBO.

Aceast_ tehnic_ elimin_ nevoia gener_rii úi aplic_rii din exterior a úabloanelor

de test. Totuúi, este nevoie de simularea defec½iunilor pentru a se determina
acoperirea de defec½iuni, realizat_ de secven½e de vectori pseudoaleatorii. Mai
mult decât atât, circuitul trebuie s_ fie simulat pentru a se ob½ine valorile
semn_turilor în cazul func½ion_rii corecte. Cantitatea datelor de test care trebuie
stocate úi analizate este redus_ din moment ce r_spunsul circuitului la N
úabloane de test este comprimat la un singur cuvânt.

42
 Figura 10. Utilizarea principiului BILBO.

3.1.3.2 Modulul comutator de testare, încorporat, pentru izolarea

defectelor

În unele aplica½ii, în timpul opera½iei normale, circuitele BILBO supraîncarc_,

în mod nejustificat, schema din punct de vedere al consumului de energie, iar
izolarea defec½iunilor dureaz_, de obicei, mult. În locul registrului BILBO,
s-a propus o alt_ variant_ de analiz_ a semn_turii, care utilizeaz_ un modul
numit comutator de testare SW (testing switch). Modulele SW pot îmbun_t_½i,
la nivel de plac_, timpul de testare úi supraînc_rcarea de putere a schemelor
de analiz_ a semn_turii implementate utilizând circuitele BILBO.

În multe probleme de izolare a defec½iunii este mai convenabil_ izolarea

defec½iunii la un grup de cipuri decât la un singur circuit. Aceste grupuri se
numesc grupuri de ambiguitate (AG). Modulul SW genereaz_ úabloane
pseudoaleatorii de test pentru a fi aplicate la intr_rile unui set AG, în timp ce,
simultan, comprim_ datele r_spunsului de test de la ieúirile unui alt set AG.
Aceast_ caracteristic_ poate minimiza timpul total al testului de izolare a
defec½iunii.

43
Utilizarea modulelor SW pentru izolarea defec½iunilor introduce întârzieri
adi½ionale între AG-uri, în timpul modului normal de operare. Totuúi, dac_
proiectan½ii implementeaz_ cipuri cu comutatorul de testare utilizând tehnici
de împachetare úi tehnologii avansate, pot minimiza întârzierile adi½ionale.
Se pare c_, în cazul multor aplica½ii, aceast_ întârziere va avea un efect
neglijabil asupra performan½elor sistemului.

3.1.4 Controlul erorilor la nivel de procesor

Pradhan úi Reddy au ar_tat c_, utilizând redundan½a de ordinul duplic_rii, codul

de paritate poate realiza cu eficacitate controlarea erorilor. Conceptul este deja
utilizat ca un produs comercial, prin sistemul de comutare Philips S2500.
Acesta utilizeaz_ patru perechi procesor-memorie, fiecare procesor fiind pe
16 bi½i, iar memoria pe 8 bi½i. De aceea, exist_ redundan½_ de ordinul patru
pentru procesoare úi de ordinul doi pentru memorie. Ieúirea pe 16 bi½i a fiec_rui
procesor este codificat_ într-o versiune (4,2) GF (28) de cod R-S, producând
un cod de 32 de bi½i. Acest cod poate corecta orice bloc singular de 8 bi½i.
Fiecare codificator al ieúirii procesorului produce doar 8 bi½i din cei 32 de bi½i
ai cuvântului de cod. Memoria asociat_ a celui de-al i -lea procesor stocheaz_
al i -lea octet. De aceea, codificatorul pentru procesorul i produce 8 bi½i care
corespund celui de-al i -lea octet.

La opera½iunea de citire, to½i cei patru octe½i sunt aduúi din memorie úi
decodifica½i de c_tre decodificator, care poate corecta orice octet singular eronat
sau orice eroare de doi bi½i în doi octe½i diferi½i. Este de notat faptul c_
deteriorarea unui singur procesor sau a unei singure memorii afecteaz_ doar
un singur octet din cuvântul de cod. Din acest motiv, sistemul poate tolera
deteriorarea oric_rei perechi singulare procesor-memorie.

În plus, codul poate corecta útergerea unui octet singular precum úi erorile
singulare de bit. Astfel, dac_ se demonteaz_ o pereche procesor-memorie pentru

44
repara½ie, sistemul continu_ s_ opereze utiliz_nd decodificarea de erori-útergeri
(error-erasure decoding). La nivel de bit poate fi corectat_ orice subsecven½_
de eroare singular_.

Aceast_ utilizare a codific_rii pentru controlarea erorii de procesor este

atractiv_. Singurul dezavantaj real este acela c_, datorit_ necodific_rii liniilor
de adrese la memorie, nu are loc corec½ia de eroare la opera½ia de scriere. În
general, prin utilizarea c_ilor netradi½ionale descrise mai sus, codul controlului
de paritate poate furniza un control eficace al erorilor procesorului. Utilizarea
lor va elimina necesitatea de conversie a codului úi întârzierea asociat_ în
transfer procesor-memorie, furnizând astfel controlul uniform al erorii.

3.2 Problematica construc½iei checker-elor de erori

Multe sisteme digitale includ detectoare de erori, adic_ circuite care detecteaz_
úi semnalizeaz_ apari½ia erorilor. Exist_ dou_ motive principale pentru
includerea detectoarelor de erori într-un sistem úi aceste motive sunt: prevenirea
ajungerii erorii pân_ la ieúirea sistemului úi localizarea pozi½iei erorii.

O cale pentru a preveni propagarea erorii este verificarea datelor recep½ionate

dup_ transferul de date úi, dac_ se detecteaz_ o eroare, atunci fie se cere
retransmisia, fie se corecteaz_ datele utilizând un cod corector de erori (ca în
memoriile RAM).

O alt_ cale este verificarea rezultatului unei opera½ii aritmetice úi repetarea

opera½iei dac_ rezultatul con½ine o eroare detectat_. Sistemele mari includ, de
obicei, detectoare de erori împreun_ cu circuite pentru înregistrarea loca½iei
úi frecven½ei evenimentelor de eroare. Aceast_ informa½ie este utilizat_ pentru
a facilita între½inerea rapid_ úi exact_.

45
3.2.1 Circuite de verificare dubl_ cale

Un circuit de verificare dubl_ cale (two-rail checker), adic_ un circuit care

controleaz_ dac_ fiecare pereche de intr_ri are valori complementare, este
utilizat pentru a converti cele n perechi de semnale într-o singur_ pereche de
semnale complementare dac_ úi numai dac_ toate cele n perechi de intrare au
semnale complementare.

3.2.1.1 Checker de egalitate

Un tip foarte important de checker este cel care verific_ egalitatea, adic_ acela
care compar_ dou_ cuvinte de intrare pentru a determina dac_ bi½ii cores-
punz_tori din ambele cuvinte au aceeaúi valoare. Checker-ul de egalitate este
componenta cheie în checker-ele pentru coduri separabile úi pentru compararea
ieúirilor circuitelor duplicate.

Un checker de egalitate cu autotestare poate fi ob½inut prin complementarea

tuturor bi½ilor din unul dintre cuvintele care trebuie s_ fie comparate pentru
a forma un cod dubl_ cale (two-rail code). Checker-ele dubl_ cale discutate
mai sus pot fi utilizate pentru a realiza un checker testabil de egalitate. O alt_
posibilitate este aceea de a concatena cuvântul complementat úi cel necomple-
mentat pentru a forma un cuvânt de cod care are jum_tate din bi½ii lui egali
cu 1. Un checker k din 2k poate fi utilizat pentru a forma un checker testabil
de egalitate.

3.2.1.2 Checker M din N

Checker-ele M din N formeaz_ o alt_ clas_ de checker-e încorporate. Deúi sunt

mai pu½in importante decât celelalte, totuúi sunt utilizate. Checker-ul 1 din n

46
este folosit pentru a monitoriza operarea corect_ a re½elelor complete de
decodificare.

O implementare cu autotestare a acestui checker este format_ prin conectarea

tuturor ieúirilor decodificate care corespund intr_rilor cu paritate par_ la o
poart_ SAU úi tuturor ieúirilor care corespund intr_rilor cu paritate impar_ la
o alt_ poart_ SAU.

Ieúirile celor dou_ por½i au fie 10, fie 01, atunci când decodificatorul opereaz_
corect. Schema este cu autotestare deoarece por½ile SAU recep½ioneaz_ toate
configura½iile de intrare (00, 10, 01) necesare test_rii lor pentru defec½iuni
singulare de tip punere pe (stuck-at) în timpul oper_rii normale. Aceast_ schem_
poate fi convertit_ într-un circuit testabil cu o singur_ ieúire.

Codurile cu ponderea fix_ m-din-n se utilizeaz_ atunci când se doreúte atât

detectarea tuturor defectelor singulare de tip stuck-at, cât úi a celor unidirec½i-
onale.

Codul zecimal 2 din 5 este cel mai cunoscut exemplu al unui cod M din N.
Codurile k din 2k sau k din 2k 1 sunt implement_rile uzuale deoarece con½in
num_rul maxim de cuvinte de cod pentru o lungime cunoscut_ a cuvântului.

3.2.2 Circuite cu autoverificare total_, încorporate

Carter úi Schneider au ridicat obiectivele autoverific_rii (self-checking) úi au

dezvoltat circuitul TSC (Totally Self-Checking), care are mai multe intr_ri úi
ieúiri. În timpul oper_rii normale (f_r_ defec½iuni) un circuit TSC nu recep½i-
oneaz_ toate combina½iile posibile la intr_ri, ci numai un subset al tuturor
combina½iilor posibile numit spa½iul codului de intrare (input-code space). De
asemenea, el nu produce toate combina½iile posibile de ieúire, ci numai un
subset numit spa½iul codului de ieúire (output-code space).

47
Checker-ul TSC este un circuit combina½ional care simplific_ sarcina unui
observator. Dac_ unitatea func½ional_ TSC produce o ieúire care apar½ine
spa½iului codului de ieúire, checker-ul TSC indic_ faptul c_ nu exist_ nici o
eroare. O ieúire care nu apar½ine spa½iului codului de ieúire se numeúte ieúire
ilegal_ (noncode) úi, dac_ checker-ul g_seúte o astfel de ieúire la unitatea
func½ional_, atunci indic_ existen½a unei erori.

O situa½ie interesant_ apare atunci când checker-ul are o defec½iune. Din

moment ce se presupune c_ unitatea are numai o singur_ defec½iune la un
moment dat, se poate considera c_, dac_ checker-ul are o defec½iune, unitatea
func½ional_ nu are nici o defec½iune úi, deci, nu va produce nici o ieúire ilegal_.
Astfel, este nevoie de un mecanism prin care fiecare defect din interiorul
checker-ului s_ se releve ca o eroare la ieúirea lui. Este necesar, de asemenea,
s_ se codifice ieúirile checker-ului printr-un cod detector de erori unidirec-
½ionale. Checker-ul trebuie s_ produc_ un num_r cât mai mic de ieúiri deoarece
acestea vor fi monitorizate din exterior. Cel mai mic cod nesistematic cunoscut,
numit úi cod dubl_ cale (dual-rail code) este {01, 10}. O eroare unidirec½ional_
transform_ acest cod în {00 sau 11} úi astfel ieúirile checker-ului vor indica
o eroare. Deci, se poate detecta o defec½iune/eroare prin observarea unei ieúiri
ilegale la un checker, iar pentru a detecta o defec½iune în interior este nevoie
de aplicarea unor intr_ri specifice (configura½ii de bi½i, vectori) numite intr_ri
de test. Astfel, se presupune, în mod implicit, c_ toate intr_rile de test ale unui
sistem TSC sunt aplicate în modul oper_rii normale.

În literatura de specialitate se întâlnesc urm_toarele defini½ii:

a) Un circuit se numeúte fault-secure (FS) pentru un set - de defec½iuni,

dac_, pentru orice defec½iune singular_ 2 - , circuitul produce
fie o ieúire de cod, aúteptat_ pentru intrarea respectiv_, fie o ieúire
ilegal_ (noncode), dar nu produce un cuvânt de cod neaúteptat
pentru acea intrare;

b) Un circuit este numit self-testing (ST) pentru un set - de defec½iuni

dac_ úi numai dac_, pentru orice defec½iune singular_ 2 - ,

48
 circuitul produce o ieúire ilegal_ (noncode) pentru cel pu½in o
intrare din cod;

c) Un circuit este numit totally-self-checking (TSC) dac_ este atât

self-testing, cât úi fault-secure pentru orice defec½iune singular_
2 -;

d) Un circuit se defineúte drept code-disjoint (CD) dac_ în absen½a

defectelor, aplicând intr_rilor primare un vector binar úi valid al
codului, la ieúire se ob½ine, de asemenea, un vector binar valid
al respectivului cod, aúa cum, dac_ aplicând intr_rilor primare
un vector binar ilegal pentru codul dat, la ieúire se ob½ine, de
asemenea, un vector binar ilegal pentru al respectivului cod. Un
circuit TSC este numit TSC checker dac_ este code-disjoint.

Not_: Pentru circuitele de verificare nu este esen½ial_ proprietatea de

fault-secure.

Ini½ial, defini½ia circuitelor TSC a fost dat_ pentru circuitele combina½ionale,

extinzându-se, ulterior, atât asupra circuitelor secven½iale, cât úi, în general,
asupra unor sisteme întregi (despre care se poate spune c_ se comport_ ca úi
maúinile secven½iale).

Revenind la checker-ul TSC, se puncteaz_ faptul c_ ieúirea lui devine 00 sau 11,
dac_ úi numai dac_ o eroare este detectat_ la ieúirea unei unit_½i func½ionale
sau dac_ checker-ul are o defec½iune hardware. Deci, un checker TSC trebuie
s_ fie code-disjoint.

Adesea exist_ situa½ii în care, chiar dac_ un checker este proiectat pentru
code-disjointness, nu sunt disponibile de la unitatea func½ional_ TSC toate
intr_rile de test, necesare pentru testarea lui. Pentru a face un circuit atât
self-testing, cât úi code-disjoint ar trebui s_ se suspende, din când în când,
opera½ia normal_ pentru a alimenta (to flush) checker-ul cu intr_ri de test care
în mod normal nu sunt disponibile. Dar, în aceast_ situa½ie sistemul nu mai
este on line úi exist_ dificult_½i practice în alimentarea checker-ului. O cale

49
mai bun_ este proiectarea unor checker-e care s_ fie atât self-testing, cât úi
code-disjoint úi care s_ nu aib_ nevoie de acces din exterior, fiind uúor de
încorporat.

În conformitate cu cele discutate anterior, un circuit TSC, ale c_rui ieúiri sunt
codificate într-un cod detector de erori, produce întotdeauna un cuvânt ilegal
ca prim_ ieúire eronat_ din cauza unei defec½iuni. Acest comportament este
foarte avantajos úi este cunoscut sub denumirea de obiectivul proiect_rii TSC
(TSC goal). Exist_, totuúi, úi alte clase de circuite logice care îndeplinesc acest
obiectiv.

Proprietatea de strongly fault-secure caracterizeaz_ o clas_ mai larg_ de circuite

logice care realizeaz_ acest obiectiv sub aceleaúi premize privitoare la
defec½iunile care se iau în considera½ie. Proprietatea se defineúte în felul
urm_tor: un circuit (sistem) este strongly fault-secure (SFS) pentru un set -
de defec½iuni, dac_ pentru orice defec½iune singular_ 2 - , circuitul poate fi:

a) TSC pentru {2} sau

b) FS pentru {2} úi, dac_ defectul 2 apare, atunci circuitul (sistemul)

rezultant este tot SFS pentru - {2} .

Din punct de vedere al proiectantului, este mai avantajoas_ proiectarea

circuitelor SFS care îndeplinesc obiectivul TSC spre deosebire de proiectarea
circuitelor TSC, pentru c_ cele din urm_ impun proiect_rii mai multe restric½ii.
De asemenea, chiar dac_ proiectarea sistemelor fail-safe a fost studiat_ înainte
úi independent de cea a circuitelor TSC úi SFS, circuitele fail-safe sunt
echivalente cu circuitele fault-secure cu o anumit_ codificare.

O alt_ proprietate interesant_ se defineúte dup_ cum urmeaz_: un circuit este

strongly code-disjoint (SCD) pentru un set - de defec½iuni, dac_ pentru orice
defec½iune singular_ 2 - , circuitul este fie:

a) CD úi este ST pentru {2} ,

50
fie

b) CD úi, dac_ defectul 2 apare, atunci circuitul rezultant este tot SCD
pentru - {2} .

Combina½ia dintre un circuit TSC (care realizeaz_ o anumit_ func½ie) úi un

checker TSC apar½ine clasei re½elelor logice cu componente TSC. Aceste re½ele
îndeplinesc obiectivul TSC sub presupunerea defec½iunilor singulare, ceea ce
înseamn_ c_ defec½iunile apar una câte una, iar între dou_ defec½iuni este timp
suficient astfel încât toate intr_rile din cod s_ fie aplicate re½elei. Presupunând
c_ exist_ defec½iuni duble, re½elele de mai sus nu îndeplinesc obiectivul TSC.
Prin defec½iuni duble se în½elege c_ între apari½ia a dou_ defec½iuni care
afecteaz_ circuitul care realizeaz_ func½ia dorit_ sau între apari½ia a dou_
defec½iuni care afecteaz_ checker-ul, exist_ suficient timp pentru ca toate
intr_rile din cod s_ fie aplicate re½elei. Gaitanis prezint_ o nou_ clas_ de circuite
de verificare TSC cu propriet_½i mai puternice de autoverificare (self-checking)
pentru a îndeplini obiectivul TSC în cazul re½elelor de checker-e, când se iau
în considera½ie defec½iunile duble.

Un TSC checker este strongly-self-checking (SSC) pentru un set - de

defec½iuni, dac_ Fc, Fe úi E sunt submul½imi disjuncte ale mul½imii de ieúiri
ilegale, unde:

 Fc este mul½imea ieúirilor neaúteptate, cauzate de defec½iuni interne 2 -

úi intr_ri din cod ale checker-ului TSC;

 Fe este mul½imea ieúirilor neaúteptate, cauzate de defec½iuni interne 2 -

úi intr_ri (ilegale) din afara codului ale checker-ului TSC;

 E este mul½imea ieúirilor produse de checker-ul TSC f_r_ defec½iuni

cauzate de intr_rile ilegale.

51
 BIBLIOGRAFIE

[BURN94] S.W. Burns, N.K. Jha. A Totally Sel-Checking Checker for a

Parallel Unordered Coding Scheme. IEEE Transaction on Computers,
April 1994, vol. 43, pp. 490–495.

[CHKA97] A. Chatterjee, B. Kaminska. Mixed Signals DFT&BIST: Practices

and Realities. 15th IEEE VLSI Test Symposium, Monterey, California,
USA, April 27 – May 1, 1997.

[FUJI90a] E. Fujiwara. Logic Testing and Design for Testability. England:

MIT Press, 1990.

[FUJI90b] E. Fujiwara, K. Pradhan. Error-Control Coding in Computers. IEEE

Computer, July 1990, pp. 63–71.

[JOHN89] B.W. Johnson. Design and Analysisof Fault Tolerant Digital

System. Addison-Wesley Publishing Company, 1989.

[JOHN93] B.W. Johnson. Boundary Scan Eases Test of New Technologies.

Test&Measurement Europe, Autumn 1993.

[MAHM88] A. Mahmood, E.J. McCluskey. Concurrent Error Detection Using

Watchdog Processors — A Survey. IEEE Transaction on Computers,
February 1988, vol. 37, pp. 160–174.

[MARC93] R. M_rculescu. Tehnici de baz_ în proiectarea pentru testabilitate.

Tempus postgraduate school of computer aided electrical engineering.
Editor Daniel Iona, Bucureúti 1993.

[MCCL90] E. McCluskey. Design Techniques for Testable Embedded Error

Checkers. IEEE Computer, July 1990, pp. 84–88.

52
[SING97] G. Singer. Current Trends and Future Directions in Test and DFT.
15th IEEE VLSI Test Symposium, Monterey, California, USA, Ap-
ril 27 – May 1, 1997.

[STMA97] A.P. Ströle, F. Mayer. Methods to Reduce Test Application Time

for Accumulator-Based Self-Test. 15th IEEE VLSI Test Symposium,
Monterey, California, USA, April 27 – May 1, 1997.

[VChN97] P.N. Variyam, A. Chatterjee, N. Nagi. Low Cost and Efficient

Digital Compatible BIST for Analog Cicuits Using Pulse Response
Sampling. 15th IEEE VLSI Test Symposium, Monterey, California, USA,
April 27 – May 1, 1997.

[VLAD82b] M. Vl_du½iu. Contribu½ii la creúterea coeficientului de disponi-

bilitate al echipamentelor automate de prelucrare a informa½iei prin
testare neconven½ional_. Tez_ de doctorat, Bucureúti, 1982.

[VLAD89] M. Vl_du½iu, M. Criúan. Tehnica test_rii echipamentelor automate

de prelucrare a datelor. Editura Facla, Timiúoara, 1989.

[VLAD94a] M. Vl_du½iu, N.S. Petrakis. About New Signature Generation

Techniques for Binary Sequences. International Conference on Techincal
Informatics. Proceedings Vol. 5, Timiúoara 1994, pp. 11–15.

[VLAD94b] M. Vl_du½iu, N.S. Petrakis. Adapted Combinational Array for

Exact Binary Division with Signed Operands. International Conference
on Techincal Informatics. Proceedings Vol. 5, Timiúoara 1994, pp. 1–10.

[VLAD95] M. Vl_du½iu, D. Todinc_, N.S. Petrakis, I. Brînzaú. The Principle

of a Fuzzy Processor with Parityt Check. Buletinul ùtiin½ific al U.T. Ti-
miúoara, 1994, Tomul 39 (53), Seria „Automatiz_ri úi Calculatoare“.

[YARM90] V.N. Yarmolik. Fault Diagnostics of Digital Circuits. New York

Wiley, 1990.

53