Sisteme de ncredere

- Fiabilitatea Ciprian Dobre

ciprian.dobre@cs.pub.ro

Fiabilitatea
Laprie
Fiabilitatea reprezint continuitatea unui
serviciu (un serviciu este corect atunci cnd
implementeaz funcia corect)

Mai pragmatic
ntr-o perioad de timp, pentru un model de
folosire presupus, care e probabilitatea ca
sistemul s se defecteze?
Defect = devierea de la specificaia sistemului
Pentru unele sisteme Defectul poate nsemna devierea de
la ateptrile utilizatorului

Calificatori pentru evaluare

Evaluarea fiabilitii depinde de:
Folosirea sistemului (intenia)
Profilul
P fil l operaional
i
l (i
(intenia)
t i )
Context i mediul de folosire
Timpul i perioada de folosire
ncrcare i intensitatea folosirii

Fiabilitatea este o funcie a tuturor acestor factori

n cazul unor modificri,, trebuie re-evaluat

Msur de Fiabilitate
Fiecare este adecvat pentru diverse sisteme
POFOD - Prob. de apariie a defectelor la cerere (n
experimente
i
t statistice)
t ti ti )
ROCOF Rata de apariie a unui defect
MTTF - Mean time to failure

Trebuie alese uniti de msur adecvate

Perspectiva fizic vs. logic

Uniti de msur???
Determinarea unor uniti de msur pentru:

Retrageri de la ATM
Nr. de tranzacii
Minute
Edi
Editarea
ffolosind
l i d un procesor word
d
Cereri
Un Web server ce furnizeaz pagini
Diagnosticul pacienilor de ctre medic Boli diagnosticate
Oprirea unui reactor nuclear
Alerte

Bath tub curve

Defecte

Efecte:
Ef
t
Hardware (degradare)
Software (evoluie)
Umane (faciliti mentale)

Timp

Software & curba defectelor

C
Curba
b anterioar
t i reprezint
i t o schem
h a
probabilitii apariiei defectelor hardware
Diferit
Dif it n
cazull aplicaiilor
li iil software
ft
Pe perioade de timp trendul este similar
ns operaii de upgrade conduc la scderea fiabilitii
De obicei urmate de alte perioade de scdere conform curbei

n mod ideal, efectele cauzate de upgrade scad n timp

ns, de ndat ce software-ul nu mai este ntreinut curba
d fifiabilitate
de
bilit t titinde
d s
rmn
constant
t t

Curba disponibilitii software

v1 0
v1.0

v2 0
v2.0

Dezvoltarea
iniial

v3 0
v3.0
Software-ul nu mai este
activ/ntreinut

Defecte

Timp

ns toate acestea sunt doar

modele
Sistemele reale sunt construite att din software,
software ct i
hardware
i mai intr i factorul uman?

Cum arat curbele de apariie a defectelor n cazul

unor sisteme reale?
Scdere a fiabilitii n perioade =
training/familiarizare
Poate cpta scderi brute n timp
Modificrile organizaionale au efecte
Ex: ncrcare/stress ridicat afecteaz capacitatatea mental

Modificrile personale au efecte

Manifestrile defectelor
Defect
(fault)

Eroare
(error)

Defeciune
(failure)

Defect
Cauza adjudecat sau ipotetic a erorii. De obicei const ntr-o
greeal
g

sau lipsa
p p
pregtirii
g
corecte a unei componente.
p
Eroare
Deviaia iniial de la starea sistemului care conduce la apariia
defeciunii De obicei const ntr-un
defeciunii.
ntr un comportament
neintenionat/neateptat.
Defeciune
Deviaia de la funcionarea corect a serviciului (ex
(ex., de la
specificaii sau funcia sistemului).

Cu alte cuvinte

Defect

Eroare

Defeciune

Exemple
Defect
Erori de programare
Training
g de slab calitate
Pini ndoii pe procesor

Eroare
Calcularea incorect a unui operaii n virgul mobil
Completarea incorect a unor documente
Dispariia unui semnal pe o plac hardware

Defeciune
Abatarea de la traseul de navigaie corect
Lipsa unui tratament corect aplicat unui pacient
Alarma
Al
pentru h
hoii nu se d
declaneaz
l

Clasificarea defectelor
Se
S pott clasifica
l ifi di
din maii multe
lt perspective:
ti
Faze ale creaiei/apariiei
Defecte de dezvoltare / Defecte operaionale

Limitele sistemului
Defecte interne / externe

Cauze fenomenologice
Defecte naturale / Defecte avnd cauz uman

Dimensiuni
Defecte hardware / software

Obiective
Defecte maliioase / ne-maliioase

Clasificarea defectelor (2)

Se pot clasifica din mai multe perspective:
Intenie
Defecte deliberate / ne-deliberate

Capabilitate
Defecte accidentale / cauzate de incompeten

Persisten
Defecte permanente / tranziente

Clasificarea defeciunilor
Din
Di nou, apar maii multe
lt perspective:
ti
Domeniul defeciunii
Content failure / Timing failure

Detectibilitate
Defeciuni semnalate / nesemnalate

Consisten
Defeciuni consistente / inconsistene (bizantine)

Consecine
Defeciuni minore / catastrofice

Defect Eroare Defeciune

O cauz
comun
de
d confuzie
f i apare ca
rezultat al perspectivei asupra sistemului:
Defeciune cauzat de mintea uman
Eroare de p
programare
g

Defect software
Eroare software
Defeciune a sistemului

Cazul general

Fault
Fault
Fault
Failure
Error
Failure

Error

Failure

Latene
Defect

Eroare
Lantena
defectului

Defeciune
Latena
defeciunii

Defectele pot fi nedetectate o lung perioad de timp

Defectele pot fi mascate (ex, nu ajung niciodat s
declaneze o eroare) sau active
Erorile interne se poate s nu afecteze niciodat starea
extern a sistemului

Teste statistice de fiabilitate

Se identific
profilul op.
op

Se creaz
datele de test

Se testeaz
sistemul + log

Se calculeaz
fiabilitatea

Greu
G
de
d identificat
id tifi t profile
fil operaionale:
i
l
Nu exist un pattern de folosire standard
Modele particulare de folosire i utilizatori Maverick
Maverick
Modelele de folosire pot fi dinamice n timp

Greu de efectuat un numr semnificativ de teste pentru o

ncredere sporit n fiabilitatea astfel calculat

Testare statistic automatizat

Conduc la captarea profilelor operaionale
Auto-generarea de seturi de test minimale
Folosite pentru evaluarea fiabilitii
sistemului
nc ne-realiste/insuficiente pentru anumite
sisteme

Prevenirea defectelor

Fault
Fault
avoidance
id

Fault
removall

Error

Fault
t l
tolerance

Failure

Evitarea defectelor
nlturarea defectelor
Tolerarea defectelor ne mpiedicm, dar ne recptm echilibrul
Este de preferat s evitm defectele dect s le tolerm
(
(prevenirea
i
este
t maii bun
b dect
d t ttratamentul)
t
t l)
S-ar putea s nu reuim s ne rectigm echilibrul !

Evitarea defectelor
Prevenirea introducerii de noi defecte
Dezvoltare controlat
Metode formale
Cultura calitii la nivel organizaional

Dezvoltare controlat
F
Folosirea
l i
unuii proces d
de d
dezvoltare
lt
matur
t
(Proces Certificat?)
Gestiunea i controlul:

Cerinelor i proiectului
Evoluiei

Testrii
Configurrii
Documentrii

Auditare
Review-uri

Metode formale
Specificarea sistemului folosind un limbaj
formal
Vocabular, sintax, semantic bine
definite
Bazate pe elemente mprumutate din
matematic,
t
ti tteoria
i mulimilor,
li il llogic,
i etc.
t
Spec.
p
p
pot fi p
procesate formal

Beneficii ale metodelor

formale
Reducerea
Red cerea ambig
ambiguitilor
itilor & nenelegerilor
Analiza automat a:
Consistenei
Corectitudinii
Completitudinii

Specificaiile pot fi emulate sau simulate

Verificarea conduce la dezvoltarea de sisteme
f l i dd
folosind
demonstraii
t ii
Verificarea diverselor proprieti ale sistemului
Transformarea n scopul construirii sistemului

Calcul propoziional
Bazat pe fraze i propoziii
Permite operatori implic, negare, i, sau
Expresii i demonstraii
Notational conventions: Let G be a variable ranging over sets of sentences. Let A, B, and C range
over sentences. For "G syntactically entails A" we write "G proves A". For "G semantically entails
A" we write "G implies A".
We want to show: (A)(G)(if G proves A, then G implies A).
We note that "G proves A" has an inductive definition, and that gives us the immediate resources for
d
demonstrating
i claims
l i off the
h form
f
"Iff G proves A, then
h ...". So our prooff proceeds
d bby iinduction.
d i
Basis. Show: If A is a member of G, then G implies A.
Basis. Show: If A is an axiom, then G implies A.
Inductive step (induction on n, the length of the proof):
A
Assume
ffor arbitrary
bi
G andd A that
h if G proves A in
i n or fewer
f
steps, then
h G implies
i li A.
A
For each possible application of a rule of inference at step n + 1, leading to a new
theorem B, show that G implies B.

Logic bazat pe predicate

Extensii ale propositional calculus

Logic
g
mai puternic
p
Permite folosirea de variabile
Cuantificatori pentru
pentru toi
toi (universali)
Cuantificator dac exist (existenial)

Metode populare
OBJ Orientat obiectual, limbaj executabil
VDM Bazat pe stri i operaii
Z Teoria mulimilor i scheme grafice
Lotos Sisteme paralele & concurente
CCS Sisteme paralele & concurente

Probleme ale metodelor formale

Consumatoare
C
t
de
d titimp ii costisitoare
ti it
Greu de neles (specialiti, nu e fun)
Experii pe domenii au dificulti n folosire
Problemele pot fi chiar acoperite de formalism
Transformarea sistemului poate fi greoaie i dificil
Suportul instrumental poate fi problematic
Cum putem s dovedim c nsi specificaia este
corect?
Nu exist un singur limbaj care s acopere toate
cazurile
il

Aplicarea metodelor formale

Sunt utile pentru sub-sisteme particulare
Sunt utile pentru sub-probleme
sub probleme specifice
(ex., verificarea siguranei)
Balanseaz costurile de producie doar
dac sunt folosite corespunztor
Folosire limitat n industrie
nc nu sunt disponibile pe scar larg

nlturarea defectelor

Fault
Fault
avoidance

Fault
removal

Error

Failure

nlturarea defectelor
Detecia i nlturarea defectelor existente
Testare i depanare
p
Review i inspecii
Analiz static a codului
Nu implic execuia codului
Instrumente, metrici software

Testare
Alpha/Beta
/
Cod
C operaional de acceptare / de
producie
Black/White box Componente
p
opace
p
/ transparente
p
Testare funcional / structural
Teste pentru defecte / statistice cutare explicit /
folosire normal
Teste de unitate / de integrare testare la nivelul unei
componente / ntregului sistem
Teste de regresie set de teste repetitive dup fiecare
reparaie
la limit
limit , ncercarea de
Stress test testarea sistemului la
forare a sistemului la graniele specificaiei iniiale

Review-uri i inspecii

Focus pe artefacturile
F
t f t il produse
d
Nu necesit un sistem operaional
Examinarea & criticarea artefacturilor produse
Bazate pe revizii din partea unor experi respectiv,
revizii cu implicarea
p
de specialiti
p
din mai multe
discipline
Necesit nelegerea artefacturilor i a domeniului
Mai puin costisitoare dect testarea
Nu toate problemele pot fi identificate
F l it pentru
Folosite
t evaluarea
l
atributelor
t ib t l non-testabile
t t bil

Tolerana la defecte

Fault
Fault
avoidance

Fault
removal

Error

Fault
tolerance

Failure

Tolerana la defecte
Gestiunea defectelor i a erorilor rezultate
Prevenia
p
propagrii
p g
defeciunilor

Detecia
D f t l i
Defectului
Self- verificare
Monitoare externe

Evaluarea
Da nei
Daunei
Sume de control
Legturi redundante

Recuperarea
Din Eroare
E oa e
Redundan
Stri sigure

Repararea
Defect l i
Defectului
Reparare
Restaurare

Aseriuni
Verificri fcute la run-time
Efectuate p
periodic
Verificare asupra siguranei strii curente a
sistemului
Suntem siguri asupra strii nainte de
co t ua e
continuare?

Cotate manual / sau / auto-generate

Redundana modular

Redundan modular tripl (TMR)

3 componente efectueaz acelai task n acelai timp
Comparator la ieire
Decizie luat prin vot

Probabilitatea de apariie a
defectelor
Probabilitate mic ca toate modulele s se
defecteze simultan
Cu condiia ca funcionarea modulelor s fie
independent !!!
Soluia poate scala pn la sisteme N-version
Completat
p
cu soluii
de reparare/nlocuire
p
automat a modulelor

Blocuri de recuperare
(Recovery Blocks)
Componente
C
t redundante
d d t ffolosite
l it n serie
i
Teste de acceptan folosite pentru evaluarea rezultatelor
Dac o component se defecteaz, se ncearc urmtoarea
Se ncearc reluarea strii anterioare nainte de ncercarea
urmtoare
Testele continu pn cnd ajungem la succes sau nu mai
avem componente

Abordri bazate pe comparaie

Redundana modular nu e foarte eficient
Deoarece TOATE modulele trebuie
executate
Blocurile de recuperare sunt mai buna
(presupunnd c nu avem defecte)
Dar cum putem scrie un test de
acceptan ?

Diversificarea componentelor
Diversitatea este esenial pentru aceste metode
Att n faza de proiectare, ct i n faza de
implementare
Fiecare component trebuie s foloseasc alte:
Specificaii de sistem
Paradigme de proiectare
Limbaje de programare
Medii de dezvoltare
Algoritmi
Culturi
C lt i organizaionale
i i
l

Probleme cu redundana
D
Defectele
f t l duplicate
d li t pott nc
exista
i t !!!
Oamenii nc fac aceleai greeli
E greu de imaginat diverse moduri de a efectua aceleai
operaii
Complexitatea adugat poate ascunde la rndul ei noi
defecte
Nu putem face teste de acceptare pentru orice
Ce se ntmpl dac componentele nu ajung deloc la un
consens?
Problem legat de eficien (important pentru sisteme RT)
Poate fi costisitoare (de trei ori costul iniial al operrii
sistemului))

? Care e gradul de fiabilitate al

acestui curs ?
Ce nseamn evitarea erorilor n cazul acestui curs:
Evitarea defectelor
Folosirea de lucrri de calitate (aproape metode formale;o)
Evitarea defectelor
Folosirea
F l i
d
de surse alternative
lt
ti
Redundan, diversitate
Spell checker pentru slide-uri nlturarea defectelor
nlturarea defectelor
Al doilea an n care in acest curs Testare
Acoperim materia mpreun Redundan
defectelor Ne verificm reciproc prezentrile nlturarea
review
la
Comentariile voastre asupra cursului Tolerana
defecte

Injectarea defectelor
(Fault injection)
E
Evaluarea
l
sistemului
i t
l i sau a sub-componentelor
b
t l
acestuia
Suit de teste pentru evaluarea toleranei la
defecte
Create artificial prin introducerea de defecte
Pot fi efectuate asupra:
Simulrii unei componente
Componentei
C
t i reale
l supus
unuii load
l d de
d ttestt
Componentei reale n condiii reale de folosire

Fiecare abordare are pros i cons

Folosirea injeciei de defecte

Id
Identificarea
tifi
problemelor
bl
l d
de fifiabilitate
bilit t /
ncredere
S
Studierea
di
comportamentului
l i sistemului
i
l i n
prezena defectelor
Evaluarea mecanismelor de detecie a
erorilor
Evaluarea mecanismelor de recuperare
Evaluarea mecanismelor de reparare din
eroare

Injectarea defectelor
Controlor

Bibliotec de
Defecte

Bibliotec de
Workloads

Date
Colectate

Injector
de Defecte

Generator
de Workload

Colector
de Date

Sistem evaluat

Tipuri de injectare
Injectare la compilare
Injectare
j
la run-time
Injectare interactiv
Adugarea de entiti noi
Alterarea celor existente
nlturarea unor entiti vechi

Probleme cu injectarea
defectelor
Profile operaionale nerealiste
Consumatoare de timp pentru sisteme
complexe
Instrumentele pot interfera cu operaiile
Limitare n cazul componentelor Software
i Hardware

Discuie de grup
Marius lucreaz la birou. El folosete un PC cu un sistem de
operare obinuit. Majoritatea activitilor le realizeaz folosind o
suit Office standard ((word, etc.).
) Atunci cnd intervine p
plictiseala,
Marius navigheaz pe Web i schimb e-mail-uri cu prietenii.
Cinele lui Marius se numete Azorel.
Computerul lui Marius nu e foarte fiabil i adesea acesta i pierde
munca. Care sunt posibilele cauze ale lipsei de fiabilitate? Ce ar
putea fi fcut pentru mbuntirea fiabilitii?
Se vor considera att p
perspectivele
p
sociale,, ct i cele tehnice.

Cteva soluii
Este sistemul nefiabil ? Din perspectiva lui Marius
desigur
Hardware vechi sau defect (ex, memoria)
Software de slab calitate
Lipsa unor update-uri periodice
Marius a avut parte de un training neadecvat
Fire de cel n interiorul unitii CD
Interfaa cu utilizatorul neadecvat (OS i suita)
Folosire neanticipat a suitei Office (ex, jocuri Excel)
Infecie cu virus cauzat de e-mail-uri
Entiti auxiliare s/w slab calitative (ex
(ex, browserul)

Cteva soluii
V
Verificarea
ifi
h
hardware-ului
d
l i ii repararea acestuia
t i
Instalarea ultimelor update-uri s/w
Un comportament pro
pro-activ
activ din partea lui Marius
(salvri regulate)
Proceduri de back-up
p
Evitarea folosirii funciilor cu problem (ex., tabele)
replicarea
p
muncii lui Marius
Redundan
Mai bun testare, review-uri, inspecii, etc.
Modelarea formal a biroului lui Marius (?)
Studii etnografice ale biroului lui Marius (?)