Dependability

Mezníky (poskytovaní správných výpočetních služeb)
(1834) Dionysius Lardner.
- článek “ Babbage’s calculating engine” v Edinburgh Review
(konec 40. – začátek 50. let minulého století) První generace počítačů.
Prostředky pro zlepšení spolehlivosti:
- detekční a korekční kódy;
- zdvojení a porovnání;
- ztrojení s hlasováním;
- diagnostika porušených komponentů, atd.
I. von Neumann, E.F. Moore a C.E. Shannon.
Teorie maskující nadbytečnosti.
(1965) W.H. Pierce.
Pojem odolnost proti poruchám.
(1967) A. Avizienis.
Maskující nadbytečnost + praktické metody (odhalení chyb; diagnostika
závad; obnovení) ⇒ pojem odolnost proti závadám.
(1980) IFIP WG 10.4 “Dependable computing and fault tolerance”.
Pojem Dependability.
OPZ + obrana před záměrnými zlomyslnými závadami (bezpečnostní hrozby)
⇒ integrace bezpečnosti do rámce dependable computing.
1
Dependability
Výpočetní systémy se dají charakterizovat pomocí 5
základních vlastností:
funkčnost
■ použitelnost
■ výkonnost
■ cena
■ dependability (dependabilita)
■
Dependabilita je schopnost výpočetního systému
poskytovat službu na niž se dá spolehnout
2
Dependability
3
Tři důležité části při realizaci Dependability :
Hrozby
Atributy
Prostředky pro zajištění dependability
Dependabilita
Hrozby
Hrozby
Selhání
Chyba
Závada
Atributy
Dostupnost
Spolehlivost
Bezpečí
Důvěrnost
Integrita
Udržovatelnost
Prostředky
Prevence závad
Odolnost proti závadám
Odstranění závad
Předpověd´ závad
Dependability
Hrozby
Závada – je posouzená nebo hypotetická příčina chyby.
Chyba (chybný stav) – je takový stav systému, který může vést k selhání.
Selhání (porucha) – je událost, která se vyskytuje když se poskytována
služba liší od spravné služby.
◘ Systém může selhat bud´ protože se nedodrží specifikace, nebo specifikace
nepopisuje adekvátně funkce systému.
Režimy selhání (způsoby, jakým systém může selhat)
Podle 4 různých hledisek režimy mohou být charakterizovaný takto:
• selhávací doména;
• ovladatelnost selhání;
• konzistence selhání, když systém má dva a více uživatelů;
• následky selhání pro prostředí.
4
5
Dependability
Hrozby
Planý poplach
doména
ovladatelnost
hodnotové
Degradovaná
Degradovaná
služ
služba
časové
Přeruš
erušení
ení prá
práce
ovládané
Signalizované
Signalizované
selhá
selhání
Symptomy
neovládané
Totá
Totální
lní selhá
selhání
selhání
selhání
konzistence
konzistentní
Klamné
Klamné selhá
selhání
nekonzistentní
mírné
následky
Nesignalizované
Nesignalizované
selhá
selhání
katastrofické
Byzantské
Byzantské
selhá
selhání
vážnost
selhá
selhání
Obrázek ukazuje režimy selhání a také ukazuje možné symptomy selhání,
které jsou výsledky kombinací: domény, ovladatelností a konzistence.
Symptomy selhání mohou být mapovány na závažnost selhání, které jsou
třídění následků selhání.
Dependability
6
Hrozby
Závada (Z) obvykle způsobí Chybu (Ch) ve stavu jednoho nebo více komponentů,
ale k Selhání systému nedojde do té doby pokud Chyba nedosáhne Rozhraní
služby systému.
SYSTÉM
Component 2
Component N
Z
Ch
Ch
Ch
Rozhraní služby
Component 1
SLUŽBA
Dependability
Hrozby
Třídění chyb
Hodnotové ver. Časové chyby
Konzistentní ver. Nekonzistentní (“Byzantské“) chyby
Chyby různých závažností:
méně závažné ver. obvyklé ver. katastrofické
■ Chyba je odhalená, jestli na její přítomnost ukazuje zpráva nebo signál.
■ Chyba která je přítomná, ale neodhalená se jmenuje Latentní chyba.
7
Dependability
fáze vytváření
nebo výskytu
meze
doména
Závady
původ
záměr
stabilita
Tři hlavní třídy závad:
• závady návrhu;
• fyzikální závady;
• interaktivní závady.
vývojové závady
provozní závady
interní závady
externí závady
HW závady
SW závady
přirozené (vlastní) závady
lidmi zapříčiněné závady
nahodilé nebo nezlomyslné závady
záměrně zlomyslné závady
permanentní závady
přechodní závady
8
9
ZÁVADY
vývojové
vývojové
fáze
interní
interní
meze
doména
původ
záměr
provozní
provozní
interní
interní
SW
HW
lidské
lidské
Nah
nebo
nezlo
lidské
lidské
Zám
zlo
Zám
zlo
Nah
nebo
nezlo
HW
přiroz
nah
stabilita
přiroz
nah
přech
SW
závady
zlomys
kody
HW
závady
externí
externí
výrobní
výrobní
defekt
fyzické
fyzické
deteriori
zace
HW
přiroz
nah
SW
lidské
lidské
Nah
nebo
nezlo
přech přech
fyzická
fyzická
interference
lidské
lidské
Zám
zlo
Zám
zlo
přech
přech
Napadení
Napadení
Nah
nebo
nezlo
přech
vstupní
vstupní
chyby
zlomys
kody
závady návrhu
fyzikální závady
interaktivní závady
10
Dependability
Vztah mezi Závadami, Chybami a Selháními
Rozhraní
služby
Komponent A
Interní
závada
(spící stav)
Ak
t iv
ac
e
Vstupní
chyba
Šíření
Chyba
Rozhraní
služby
Komponent B
Šíření
Chyba
Ch
Šíření
Exrerní
Šíření
Chyba
Chyba
Závada
ní
rer
x
E
a
ad
záv
Stav služby
komponentu A
Správná služba
Selhání
Nesprávná služba
Stav služby
komponentu B
Správná služba
Závada
Aktivace
Chyba
Šíření
Selhání
Příčina
Závada
Selhání
Nespr.
služba
Dependability
11
Závady podle jejich aktivační reprodukovanosti
Stálé (pevné)
ZÁVADY
Nestále (občasné) nebo unikající
Terminologie pro SW:
• Unikající závady návrhu ( bugs) = Heisenbugs;
• Stálé závady návrhu = Bohrbugs.
Výpočetní systémy
(např. [Gray 1990],
[Cramp et al. 1992])
Hodnocení Procento
selhání
Řízené systémy
(např. Komerční letadla
[Ruegger 1990], telefonní sít´
[Kuhn 1997])
Hodnocení Procento
selhání
Interní fyzické závady
3
~10%
2
15-20%
Externí fyzické závady
3
~10%
2
15-20%
Interaktivní závady
způsobené člověkem
2
~20%
1
40-50%
Závady návrhu SW
1
~60%
2
15-20%
Dependability
12
Atributy Dependability
Dostupnost: pohotovost k provedení správné služby.
Spolehlivost: kontinuita poskytování správné služby.
Zabezpečenost: absence katastrofických následků pro uživatele a prostředí.
Důvěrnost: absence nepovolených odhalení informace.
Integrita: absence nevhodných změn stavu systému.
Udržovatelnost: schopnost procházet opravy a modifikace.
Jiné atributy dependability:
Robustnost – odolnost proti chybným vstupním datům.
Důvěrnost
Integrita
Dostupnost
Bezpečnost
Sekundární atributy:
• zodpovědnost;
• originalita;
• nepopíratelnost
(absence neoprávněného přístupu ke stavu
systému nebo neoprávněného ošetření
stavu systému)
Dependability
13
Metody pro zajištění Dependability
Prevence závad: jak zabránit výskytu závad.
Odolnost proti závadám: jak poskytnout správnou službu v přítomnosti závad.
Odstranění závad: jak zredukovat počet závad nebo zmenšit závažnost závad.
Předpověd´ závad: jak zhodnotit počet stávajících závad, a počet nastávajících
závad (které mohou vzniknout), a takže jak zhodnotit
pravděpodobné následky závad.
Odolnost proti závadám
Odhalení
Chyb
Obnovení
Systému
Kompensace
(maskování
závad)
Ošetření
Závad
Přerolování
Odrolování
Předběžné
Souběžné
Ošetření
Chyb
Krok 1: Diagnostika závad
Krok 2: Izolace závad
Krok 3: Rekonfigurace systému
Krok 4: Znovuinicializace
(reinicializace)
Dependability
14
Odolnost proti závadám
Odhalení chyb
Odhalení chyb: se projevuje jako chybový signál nebo zpráva o chybě uvnitř
systému.
Souběžné OCh – probíhá v průběhu poskytování služby;
Předběžné OCh – probíhá když poskytování služby je pozastaveno;
Obnovení systému
Obnovení systému: transformuje stav systému, který obsahuje jednu nebo více
chyb a závad, do stavu bez odhalených chyb a závad, které
by mohly být znovu aktivovány.
A. Ošetření chyb:
chyb odstraňuje chybu ze stavu systému.
• Odrolování,
když transformace stavu probíhá jako vracení stavu systému do
zachovaného stavu, který byl před odhalením chyby;
• Kompensace,
když chybový stav obsahuje dostatek nadbytečnosti pro odstranění chyby;
• Přerolování,
přechod do nového stavu, který neobsahuje již odhalené chyby.
Dependability
15
Odolnost proti závadám
B. Ošetření závad:
vad zabraňuje lokalizovaným závadám v opakované aktivaci.
1) Diagnostika závad
Identifikuje a zaznamenává příčiny chyb. V záznamech se uvádí lokalita a typ
závady;
2) Izolace závad
Vykonává fyzické nebo logické vyloučení závadných komponentů z další účasti
v poskytování služby;
3) Rekonfigurace systému
Bud´ přepíná na náhradní komponenty nebo používá nezávadné komponenty
(které zůstaly v systému) a přerozdělí úkoly mezi nezávadnými komponenty;
4) Znovuinicializace
kontrola, aktualizace a záznam nové konfigurace.
Dependability
16
Odolnost proti závadám
Systémy s ovladatelným selháním: systémy jejichž návrh a implementace jsou
takové že tyto systémy selžou pouze specifickým způsobem popsaným v
požadavcích k dependabilitě a pouze do přijatelné míry.
Příklady:
-Stálá výstupní hodnota (nesprávná) na rozdíl od nahodilé výstupní hodnoty;
-absence výstupní hodnoty (ticho) na rozdíl od „blábolení“;
-konsistentní na rozdíl od nekonsistentního selhání.
■ Systém jehož selhání se vždycky do přijatelné míry jeví jako zastavení,
se jmenuje systém s selhání typu:
“selhání→zastavení” (nebo “selhání→mlčení”) Fail-halt (or Fail-silent)
■ Systém jehož selhání jsou do přijatelné míry méné závažná, se jmenuje
systém s neškodnými selháními. Fail-safe
Dependability
17
Běžné otázky:
• Proč SW systémy selhávají?
• Co tvoří základ procesu selhání SW?
• Jestli-že selhání SW jsou ”systematické”, proč pořad mluvíme o spolehlivosti
s použitím termínů pravděpodobnosti?
Systematické: pokud se závada tohoto druhu (systematická závada) projeví v určitých
podmínkách, pak můžeme garantovat že tato závada se projeví vždycky
při opakování podmínky.
Selhání SW jsou vždy výsledkem závad návrhu , které se projeví při určitých
výpočetních okolnostech. Tyto závady (závady návrhu = bugs) budou v
SW od okamžiku jeho vytvoření, nebo při následujících změnách.
Proces selhání – je proces ve kterém se závady jeví jako výsledek zpracování
(výpočtu) vstupních dat.
Dependability
18
Koncepční model procesu selhání SW
Systém na vyžádání (demand-based system)
(např. Systém zajišt´ující bezpečnost jaderné elektrárny)
D
O
Program
DF
nepřipustný
připustný
D – prostor požadavků;
O – množina výstupních dat;
DF – množina požadavků, které
způsobí selhání systému;
● - konkrétní fyzický požadavek.
▌Každý bod v D si můžete představit
jako konkrétní fyzický požadavek.
(např., vektor teplot, tlak, rychlost toku
apod., odebrané v pravidelných
intervalech skenovacími senzory)
Dependability
Stochastický proces
Není jistota ve
znamená
výběru požadavku
Není jistota bude-li
se požadavek
nacházet v oblasti
DF nebo nikoliv
19
vyplývá
Není jistota bude-li
selhání systému
Závěr:
• Všechna tvrzení ohledně spolehlivosti musí počítat s touto nejistotou;
• Systematická selhání jsou stejně “nahodilá” jako obvyklé nahodilé selhání.
Závada v kontextu Koncepčního modelu
Fs – Podmnožina bodů v DF, které se změnily z bodů
DF
Fs
selhání na body spojené s požadavky, které budou správně
zpracovány.
Můžeme si myslet že Fs je “závada” která byla odstraněná
Pr(d)
pfd – probability of failure upon demand
pfd =
(pravděpodobnost selhání při zpracování požadavku)
Zlepšení pfd po odstranění závad:
pfd =
∑
d ∈ Fs
∑ P (d )
r
d∈ D F
Pr (d )
Dependability
20
Odstranění závad
Vývojová fáze
1. Verifikace & Validace
2. Diagnostika
3. Korekce
Provozní fáze
Korekční údržba
Preventivní údržba
Verifikace- je proces kontroly jestliže systém dodržuje nastavené vlastností.
Validace – je proces kontroly specifikace systému.
Cena V&V = ½ nebo ¾ ceny vývoje systému
V&V umožňuje: zredukovat četnost závad
z
10 – 300 závad/kLoC → následek vývoje SW
na
0.01 – 10 závad/kLoC → po odstranění závad
Důležité: 1 závada/kLoC zůstavá v systému ( v průměru)
Dependability
21
Odstranění závad
Provozní fáze
Korekční údržba – má za cíl odstranit závady, které způsobily jednu
nebo více chyb, a byly odhaleny.
Preventivní údržba – má za cíl odhalit a odstranit závady ještě před tím
než závady způsobí chyby v průběhu normálního
fungování systému.
Dependability
22
Předpověd´ závad
Striktní odvozovací procedura:
- Systém na vyžádání ( e.g. Ochranný systém)
Když potřebujeme 99% jistoty že pfd nebude horší než 10-3 , musíme obdržet
přibližně 4600 požadavků, které by nevedly k selhání;
Pro 99% jistoty v 10-4 , toto číslo stoupá na 46000 požadavků.
(Toto testování bylo provedené pro ochranný systém jaderného reaktoru
SizeWellB v UK).
- Systém s nepřetržitou obsluhou (e.g. Řídicí systém)
99% jistoty v MTTF (střední doba do poruchy) 104 hodin (1.14 roku) potřebují
přibližně 46000 hodin testování bez selhání (t.j. Bezporuchového testování);
Zvýšení MTTF na 105 hodin, bude potřebovat dobu testování 460000 hodin.
Efektní pravděpodobnostní metody
Krátkodobé pozorování → předpověd´ na dlouhé období
CRL:
“krátkodobé pozorování přidává velmi málo k jistotě že systém bude
dlouho bezporuchové fungovat v budoucnosti”.
Dependability
23
Příklady systémů odolných proti závadám
Odolnost proti závadám
Systémy
s vysokou
dostupností
unikající závady návrhu
SW
závady návrhu HW a SW
a závady kompilátoru
Systémy
kritické
k
bezpečnosti
závady návrhu HW a SW
závady návrhu HW a SW
závady návrhu HW
a závady kompilátoru
[Wilson 1985] D. Wilson, “The STRATUS Computer System”, in Resilient Computing
24
Systems (T. Anderson, Ed.), pp.208-31, Collins, London, UK, 1985.
[Baker et al. 1995] W. E. Baker, R. W. Horst, D. P. Sonnier and W. J. Watson, “A Flexible
ServerNet-based Fault-Tolerant Architecture”, in 25th IEEE Int. Symp. on Fault-Tolerant
Computing (FTCS-25), (Pasadena, CA, USA), pp.2-11, IEEE CS Press, 1995.
[Brown Associates 1998] Competitive Analysis of Reliability, Availability, Serviceability and
Cluster Features and Functions, D.H. Brown Associates, Inc., Report.
[Bowen et al. 1997] N. S. Bowen, J. Antognini, R. D. Regan and N. C. Matsakis,
“Availability in Parallel Systems: Automatic Process Restart”, IBM Systems Journal, 36 (2),
pp.284-300, 1997.
[Hennebert & Guiho 1993] C. Hennebert and G. Guiho, “SACEM: A Fault-Tolerant System for
Train Speed Control”, in 23rd IEEE Int. Symp. on Fault-Tolerant Computing (FTCS-23),
(Toulouse, France), pp.624-28, IEEE CS Press, 1993.
[Kantz & Koza 1995] H. Kantz and C. Koza, “The ELEKTRA Railway Signalling System:
Field Experience with an Actively Replicated System with Diversity”, in 25th IEEE Int. Symp.
on Fault-Tolerant Computing (FTCS-25), (Pasadena, CA, USA), pp.453-58, IEEE CS Press,
1995.
[Brière & Traverse 1993] D. Brière and P. Traverse, “AIRBUS A320/A330/A340 Electrical
Flight Controls - A Family of Fault-Tolerant Systems”, in 23rd IEEE Int. Symp. on
Fault-Tolerant Computing (FTCS-23), (Toulouse, France), pp.616-23, IEEE CS Press, 1993.
[Yeh 1998] Y. C. B. Yeh, “Dependability of the 777 Primary Flight Control System”, in
Dependable Computing for Critical Applications (DCCA-5) (R. K. Iyer, M. Morganti, W. K.
Fuchs and V. Gligor, Eds.), Dependable Computing and Fault-Tolerant Systems, 10, pp.3-17,
IEEE CS Press, 1998 (Proc. IFIP 10.4 Work. Conf. held in Urbana-Champaign, IL, USA,
September 1995).
Dependability
25
Současný stav
Hlavní body:
Dosažení potřební spolehlivosti.
● Je-li možné dosáhnout cílové spolehlivosti?
● Jaké metody SW inženýrství jsou vhodné pro použití v návrzích?
Hodnocení spolehlivosti, která ve skutečnosti byla dosažena.
OPZ via RN byla doporučena jako cesta dopředu
jak pro dosažení vysoké spolehlivosti tak i pro její hodnocení
Argumenty pro a proti RN
Proti: současné selhání verzí je více pravděpodobně než nezávisle selhání
Pro: multiverzní systémy jsou v průměru více spolehlivé (občas mnohem více) než
jednotlivé verzí.
Otevřená otázka: na kolik se zvýší spolehlivost systému při použití RN.
Hlavní směr: zmenšení souvztažnosti mezi jednotlivými verzemi.
Dependability
Experiment (testování rozmanitosti návrhu):
▌
Autory: John Knight (Univerzita v Virginia) a Nancy Levenson (Univerzita v
California).
Místo a Čas: USA v průběhu 1980. let
Cíl:
1. Prověřit hypotézu že “nezávisle ” vyvinuté verzí selhají nezávisle.
2. Zkoumat jestliže RN přispěla k zlepšení spolehlivosti.
Obsah:
Úkolem experimentu bylo vyvinutí 27 verzí programu a jejich následné testování
v 1000000 případů a porovnání výsledků s výsledky předem připravené správné
verzi.
V průběhu experimentu byly zkoušeny všechny možné “2 z 3” systémy.
Results:
• Průměrná spolehlivost “2 z 3” systémů byla výrazně vyšší než průměrná
spolehlivost 27 jednotlivých verzí.
• Jednotlivé “2 z 3” systémy mohou mít spolehlivost menší než spolehlivost
jednotlivých verzí.
26
Dependability
27
.
Implementace
■ RN byla adoptovaná v letecké a vlakové dopravě (např. Airbus A/320/30/40,
různé vlakové signální a řídicí systémy);
Standardy:
● Civilní letectví
RTCA/EuroCAE, DO-178B, Software Consideration in Airbone Systems and
Equipment Certification, № RTCA DO – 178B/EUROCAE ED-12B, December 1992.
● Defence Standard
MoD, Safety Management Requirements for Defence Systems, U.K. Ministry of
Defence, Defence Standard, № 00-56, Issue 2, December 1996.
■ V současné době oblast použití RN výrazně rozšířila a její použití se stalo
běžným. (např. Webové služby)