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)
