6/17/2011

Prevencija i
tolerancija
otkaza

6/17/2011

injenice
90% oruja zahteva raunare i softver za
upravljanje. Desilo se mnogo otkaza i
pogrenih lansiranja.
72 od 141 meteoroloih balona je uniteno
zbog pogrenog itanja zahteva
"emergency self-destruct" umesto "read
data" od strane francuskog
meteorolokog satelita.
.................
2

6/17/2011

injenice
Na svakih milion linija programskog koda,
unese se 20 000 bagova (bugs).
Normalno, 90% otkrije se u toku testiranja,
jo 200 otkaza otkrije se u toku prve
godine rada,
1800 bagova ostane nedetektovano!
U toku odravanja obino se otkrije 200 i
uvede 200 novih otkaza!
3

6/17/2011

Pojmovi
Pouzdanost (reliability) mera uspeha
sa kojim sistem zadovoljava specifikacije
ponaanja.
Kvar (failure) stanje kada sistem
odstupa od specificiranog ponaanja.
Otkaz (fault) Uzrok nastanka kvara.
4

6/17/2011

Pojmovi
Greka (error) detektovano
neodgovarajue ponaanje sistema koje je
uzrokovao otkaz.

6/17/2011

Tipovi otkaza
prolazni (transient) nastanu, postoje
neko vreme i nestanu (napr. ponaanje
komponenata zbog spoljnjeg polja),
stalni (permanent) nastanu i ostaju do
popravke sistema napr. prekid ice ili
softverska greka),
isprekidani (intermittent) nastaju
svemena na vreme (napr. hardverske
komponente osetljive na grejanje).
6

6/17/2011

Tipovi kvara
pogrena vrednost
pogreno vreme izvravanja:
suvie rano
suvie kasno
beskonano kasno (izostanak odgovora)

6/17/2011

Stanje i otkazivanje sistema

nekontrolisano sistem pokazuje
proizvoljne greke i u domenu vrednosti i u
domenu vremena;
zakanjeno dobar odgovor ali kasni;
tiina posle pravilnog rada, prestane da
funkcionie;
zaustavljanje ue u stanje tiine, ali
doputa drugim sistemima da detektuju da
njegovo stanje;
bezotkazno sistem pravilno funkcionie.
8

6/17/2011

Poveanje pouzdanosti sistema:

Dva pristupa:
prevencija otkaza eliminisanje
mogunosti ugradnje otkaza pre uvoenja
sistema u radni reim,
tolerancija otkaza omoguavanje da
sistem nastavi sa radom ak i u sluaju
postojanja otkaza u sistemu.

6/17/2011

Prevencija otkaza:

Dva stepena prevencije otkaza:

izbegavanje otkaza,
uklanjanje otkaza.

10

10

6/17/2011

Izbegavanje otkaza kod hardvera:

upotreba pouzdanih komponenata,

upotreba proverenih tehnika povezivanja
komponenata i formiranja podsistema,
pakovanje hardvera da se onemogui
interferencija.

11

11

6/17/2011

Izbegavanje otkaza kod softvera:

rigorozno specificiranje softvera,
upotreba dokazanih projektnih metodologija
upotreba jezika koji omoguavaju
apstrakciju podataka i modularizaciju,
upotreba ureaja za konstrukciju softvera,
koji omoguavaju manipulisanje softverskih
komponenata i upravljanje kompleksnou.

12

12

6/17/2011

Uklanjanje otkaza:
Procedure nalaenja i otklanjanja otkaza.
Nikada sistem nije tako iscrpno testiran da
se moe rei da su uklonjeni svi
potencijalni otkazi. Problemi su:
Test se koristi tako da pokae odsustvo, a
ne prisustvo otkaza.
Nekada je nemogue testirati sistem u
realnim uslovima.
Neke greke manifestuju se tek kada
sistem ue u upotrebu.
13

13

6/17/2011

Tolerancija otkaza:
Sistem moe da poseduje vie nivoa tolerancije
otkaza:
puna tolerancija otkaza sistem nastavlja sa
radom u prisustvu greaka, bez znaajnog
gubitka funkcionalnosti ili osobina,
blaga degradacija - sistem nastavlja sa radom
u prisustvu greaka, sa deliminom
degradacijom funkcionalnosti ili osobina u toku
oporavka ili popravke,
bezbedno zaustavljanje sistem zadrava svoj
integritet uz privremeni zastoj u radu.
14

14

6/17/2011

Nivo tolerancije otkaza:

Zahtevani nivo tolerancije otkaza zavisi od
aplikacije. Primer - sistem za kontrolu
vazdunog saobraaja:
Potpuna funkcionalnost
unutar zahtevanog vremena
odgovora
Minimalna
funkcionalnost
potrebna za odranje
osnovne kontrole
saobraaja

Funkcionalnost u
sluaju nude
omoguava razlikovanje
aviona.
Backup sa susednog punkta;
koristi se u sluaju
katastrofalnog kvara kao to je
zemljotres.
15

15

6/17/2011

Pristupi projektovanju sistema

tolerantnih na greke:
Algoritmi sistema korektno projektovani,
Poznati su svi mogui naini otkaza
komponenata,
Sagledane su sve mogue interakcije
sistema sa okolinom.

16

16

6/17/2011

Hardverska redundansa:
Protektivna redundansa dodavanje
komponenata koje imaju funkciju
otkrivanja greaka i oporavak od greaka.
Statika redundansa redundantne
komponente unutar sistema koriste se za
skrivanje efekata otkaza.
Dinamika redundansa redundantne
komponente funkcioniu samo kada se
detektuje greka.

17

17

6/17/2011

Statika redundansa:
TMR (Triple Modular Redundancy)

18

18

6/17/2011

Trostruka redundansa:
TMR (Triple Modular Redundancy)

19

19

6/17/2011

Dinamika redundansa:
Redundansa primenjena unutar
komponente koja indicira eksplicitno ili
implicitno da je izlaz pogrean.
Obezbeuje detekciju greke, a ne
maskiranje. Oporavak mora da obezbedi
neka druga komponenta.
Primer: checksum, parity bit.

20

20

6/17/2011

Tolerancija otkaza kod softvera:

Dva opta pristupa:
Programiranje u N verzija (analogno
statikoj redundansi kod hardvera),
Zasnovano na procedurama za
otkrivanje i korekciju greaka (analogno
dinamikoj redundansi kod hardvera jer se
procedure za oporavak ukljuuju u akciju
tek poto je detektovana greka.
21

21

6/17/2011

Programiranje u N verzija:

Nezavisno generisanje N (N2)

funkcionalno ekvivalentnih programa na
osnovu iste inicijalne specifikacije. To
podrazumeva da N i ndividua ili grupa
proizvede potrebnih N verzija softvera bez
meusobne interakcije.

22

22

6/17/2011

Programiranje u N verzija, nastavak1:

Napisani kod izvrava se konkurentno sa
istim ulaznim podacima i njihovi ulazi
porede se drajverom. Rezultat se moe
razlikovati i u tom sluaju se ispravnim
rezultatom smatra rezultat generisan
konsenzusom.

23

23

6/17/2011

Programiranje u N verzija, nastavak2:

Programiranje u N verzija bazira se na
pretpostavci da se program moe
specificirati kompletno, konzistentno i
nedvosmisleno i da e programi koji su
razvijani nezavisno, nezavisno i otkazivati.
Ne postoji veza izmeu otkaza u jednom
programu i u drugom programu. Ova
pretpostavka moe biti pogrena ako su sve
verzije pisane na istom programskom jeziku
jer greke u implementaciji jezika mogu biti
zajednike svim verzijama.
24

24

6/17/2011

Programiranje u N verzija, nastavak3:

Treba koristiti razliite programske jezike i
razliita razvojna okruenja. Alternativno,
ako je korien isti programski jezik, treba
koristiti kompajlere i podrku od razliitih
proizvoaa. Kao zatitu od fizikih
otkaza, N verzija distribuira se odvojenim
mainama koje imaju komunikacione linije
tolerantni na otkaze.
Primer: Boeing 777 ima kontrolni sistem sa jednim Ada programom koji
se izvodi na tri razliita procesora i radi postizanja razliitosti,
koriena su tri razliita kompajlera.
25

25

6/17/2011

Program sa N verzija kontrolie se

drajverskim procesom koji je odgovoran
za:
pozivanje verzija,
ekanje na kompletiranje izraunavanja
svih verzija,
poreenje rezultata i akciju na osnovu
toga
26

26

6/17/2011

Komunikacija verzija programa:

Drajver i verzije programa moraju da komuniciraju
u toku izvravanja. Interakcija je specificirana u
verzijama. Sastoji se od tri komponente:
vektori za poreenje,
indikatori statusa poreenja,
take poreenja.
Kako verzije komuniciraju i sinhronizuju se zavisi
od programskog jezika i modela konkurentnosti.
27

27

6/17/2011

Komunikacija verzija programa,

nastavak1

Vektori za poreenje su strukture podataka

koje predstavljaju izlaze, ili glasove,
proizvedene od strane verzija, plus neki
atribut koji je pridruen njihovom
izraunavanju.
Vektore poredi drajver.

28

28

6/17/2011

Komunikacija verzija programa,

nastavak2

Indikator statusa poreenja prenosi se od

drajvera ka verzijama. Indicira se akcija koju
treba da izvri svaka verzija kao rezultat
poreenja. Akcija zavisi od ishoda poreenja:
da li su se glasovi sloili i da li su isporueni na
vreme.
Mogui izlazi:
nastavak rada,
iskljuenje jedne ili vie verzija,
nastavak rada posle promene jednog ili vie
izlaza na veinski glas.
29

29

6/17/2011

Komunikacija verzija programa,

nastavak3

Take poreenja su take u verzijama gde

one moraju da komuniciraju sa drajverom
aljui mu glasove. Frekvencija pojave
ovih taaka u programu predstavlja
granularnost pripreme tolerancije otkaza.
Mala granularnost tolerancije otkaza
smanjuje nezavisnost verzija.
Velika granularnost tolerancije otkaza moe
da proizvede veliku divergenciju rezultata
30

30

6/17/2011

Poreenje glasova:
Najbitnije kod programiranja u N verzija je
efikasnost i lakoa sa kojom drajverski
program poredi glasove i odluuje da li
postoji neslaganje.
Neki rezultati su takve prirode da verzije ne
proizvode isti rezultat. Tada se obavlja
netano poreenje uzimajui u obzir
opseg ili srednju vrednost.
31

31

6/17/2011

Problem konzistentnosti poreenja:

T1

T2
>Ti

T3
>Ti

ne

da

ne

P1

P3

P2
>Pi

>Ti

da

>Pi

>Pi

ne

V1

V2

V3
32

32

6/17/2011

Principi programiranja u N verzija:

Inicijalna specifikacija kompletna,
konzistentna, sveobuhvatna i
nedvosmislena,
Nezaisnost projektovanja nezavisno
pravljeni softveri pokazuju razliite otkaze,
Adekvatni budet.

33

33

6/17/2011

Dinamika softverska redundansa:

Komponente funkcioniu samo ako se
pojavila greka.
etiri faze:
detekcija greke,
ograniavanje i procena tete,
oporavak od greke,
tretiranje otkaza koji je izazvao greku.

34

34

6/17/2011

Detekcija greke:
Dve klase tehnika detekcije:
detekcija greke u okolini,
detekcija greke u aplikaciji.

35

35

6/17/2011

Detekcija greke u aplikaciji:

Detekcija replikom programa,

Vremenska detekcija (watchdog timer),
Povratna provera,
Kodna provera,
Provera logike reenja,
Strukturne provere

36

36

6/17/2011

Ograniavanje i procena tete:

Firewall
Modularna dekompozicija (razbijanje
sistema na podsisteme),
Atomska akcija:
Za aktivnost komponente kae se da je
atomska ako nema interakcija izmeu
aktivnosti i sistema u toku trajanja akcije,
tj. za ostatak sistema akcija je nedeljiva.
37

37

6/17/2011

Ograniavanje i procena tete, nastavak:

Ostale tehnike koje pokuavaju da

ogranie pristup resursima zasnovane su
na mehanizmima zatite, na primer
dozvola pristupa.

38

38

6/17/2011

Oporavak greke:
Procedure oporavka greke:
napred pokuava se da se iz take
greke nastavi dalje pravei selektivne
korekcije stanja sistema (redundantni
ukazivai, redundantni kodovi),
unazad nastoji da sistem vrati u
bezbedno stanje koje je prethodilo pojavi
greke tj. u taku oporavka.
39

39

6/17/2011

Oporavak unazad ima prednost da brie

stanje greke, ali je nekad to nemogue
(lansirani projektil ne moe se vratiti).
Zahteva dosta vremena (loe za real-time
sisteme)

40

40

6/17/2011

Tretiranje otkaza i nastavak rada:

Greka je manifestacija otkaza i mada je

sproveden oporavak greke i sistem
vraen u stanje bez greke, greka se
moe opet javiti. Dakle, finalna faza
tolerancije otkaza je uklanjanje otkaza iz
sistema da bi sistem nastavio pravilan rad.

41

41

6/17/2011

Tretiranje otkaza i nastavak rada:

Tretman otkaza moe se podeliti u dve faze:
lociranje otkaza,
popravka sistema.
Hardverska komponenta sa otkazom
menja se, a softverska komponenta sa
otkazom koriguje se, ponekad i dok je
sistem u funkciji.
42

42

6/17/2011

Ukratko ....
Prevencija otkaza:
izbegavanje otkaza,
uklanjanje otkaza.
Tolerancija otkaza:
hardverska,
softverska.
43

43