I. von Neumann, E.F. Moore a C.E. Shannon. Teorie maskující nadbytečnosti. (1965) W.H. Pierce. Pojem odolnost proti poruchám.

Transkript

1 Mezníky 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. 1 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.

2 Dependability 2 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

3 Dependability 3 Tři důležitéčásti při realizaci Dependability : Hrozby Atributy Prostředky pro zajištění dependability Dependabilita Hrozby Atributy Selhání Chyba Závada Dostupnost Spolehlivost Bezpečí Důvěrnost Integrita Udržovatelnost Prostředky Prevence závadz Odolnost proti závadz vadám Odstranění závad Předpověd závad

4 Hrozby Dependability 4 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í.

5 Hrozby Dependability 5 doména hodnotové časové Planý poplach Degradovaná služba Přerušení práce selhání ovladatelnost konzistence následky ovládan dané neovládan dané konzistentní nekonzistentní mírné katastrofické vážnost selhání Signalizované selhání Totáln lní selhání Nesignalizované selhání Klamné selhání Byzantské selhání Symptomy 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í.

6 Hrozby Dependability 6 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. S Y S T É M Component 1 Z Ch Component 2 Ch Rozhraní služby SLUŽBA Component N Ch

7 Dependability 7 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.

8 Dependability 8 Závady fáze vytvářen ení nebo výskytu meze doména původ záměr stabilita vývojové závady provozní závady interní závady externí závady HW závady z SW závady z přirozené (vlastní) ) závady z lidmi zapříčin iněné závady nahodilé nebo nezlomyslné závady záměrně zlomyslné závady permanentní závady přechodní závady Tři hlavní třídy závad: závady návrhu; fyzikální závady; interaktivní závady.

9 9 fáze ze meze meze dom doména na původ vod záměr stabilita stabilita závady návrhu fyzikální závady interaktivní závady ZÁVADY VADY vývojov vývojové provozn provozní intern interní intern interní extern externí SW SW SW SW HW HW HW HW HW HW lidsk lidské lidsk lidské lidsk lidské lidsk lidské přiroz iroz přiroz iroz přiroz iroz přech ech přech ech přech ech přech ech přech ech přech ech nah nah nah nah nah nah Nah Nah nebo nebo nezlo nezlo Zám zlo zlo Zám zlo zlo Zám zlo zlo Zám zlo zlo Nah Nah nebo nebo nezlo nezlo Nah Nah nebo nebo nezlo nezlo Nah Nah nebo nebo nezlo nezlo SW SW závady vady zlomys zlomys kody kody HW HW závady vady výrobn výrobní defekt defekt zlomys zlomys kody kody Napaden Napadení vstupn vstupní chyby chyby fyzick fyzické deteriori deteriori zace zace fyzick fyzická interference interference

10 Dependability Vztah mezi Závadami, Chybami a Selháními 10 Interní závada (spící stav) Exrerní závada Aktivace Komponent A Šíření Šíření Rozhraní služby Vstupní chyba Komponent B Šíření Šíření Rozhraní služby Exrerní Chyba Chyba Ch Chyba Chyba Závada Stav služby komponentu A Správná služba Selhání Nesprávná služba Stav služby komponentu B Správná služba Selhání Nespr. služba Závada Aktivace Šíření Příčina Chyba Selhání Závada

11 Závady podle jejich aktivační reprodukovanosti ZÁVADY Dependability 11 Stálé (pevné) 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% % Externí fyzické závady 3 ~10% % Interaktivní závady způsobenéčlověkem 2 ~20% % Závady návrhu SW 1 ~60% %

12 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 (absence neoprávn vněného přístupup ke stavu systému nebo neoprávn vněného ošetření stavu systému) Sekundární atributy: zodpovědnost; originalita; nepopíratelnost

13 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ávadz vadám Odhalení Chyb Obnovení Systému Ošetření Ošetření Souběž ěžné Předb edběž ěžné Odrolování Chyb Kompensace (maskování závad) Přerolov erolování Závad Krok 1: Diagnostika závad Krok 2: Izolace závad Krok 3: Rekonfigurace systému Krok 4: Znovuinicializace (reinicializace)

14 Odolnost proti závadám Dependability 14 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: 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.

15 Odolnost proti závadám Dependability 15 B. Ošetření zá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.

16 Odolnost proti závadám Dependability 16 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

17 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.

18 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 Program O 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)

19 Dependability 19 Stochastický proces Není jistota ve výběru požadavku znamená Není jistota bude-li se požadavek nacházet v oblasti DF nebo nikoliv 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í. DF Pr(d) Závada v kontextu Koncepčního modelu Fs Fs Podmnožina bodů v DF, které se změnily z bodů 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á pfd probability of failure upon demand (pravděpodobnost selhání při zpracování požadavku) Zlepšení pfd po odstranění závad: pfd = pfd d Fs = d P r (d ) D F Pr (d)

20 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 závad/kloc následek vývoje SW na závad/kloc po odstranění závad Důležité: 1 závada/kloc zůstavá v systému ( v průměru)

21 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.

22 Předpověd závad Dependability 22 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 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) 10 4 hodin (1.14 roku) potřebují přibližně hodin testování bez selhání (t.j. Bezporuchového testování); Zvýšení MTTF na 10 5 hodin, bude potřebovat dobu testování 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.

23 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

24 [Wilson 1985] D. Wilson, The STRATUS Computer System, in Resilient Computing Systems (T. Anderson, Ed.), pp , Collins, London, UK, [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, [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 , [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 , IEEE CS Press, [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 , IEEE CS Press, [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 , IEEE CS Press, [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).

25 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 zka: na kolik se zvýší spolehlivost systému při použití RN. Hlavní směr: zmenšení souvztažnosti mezi jednotlivými verzemi.

26 Dependability 26 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 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 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í.

27 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 Defence Standard MoD, Safety Management Requirements for Defence Systems, U.K. Ministry of Defence, Defence Standard, 00-56, Issue 2, December 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)