Megbízhatósági modellezés és analízis: Mire jó ez egyáltalán?

Megbízhatósági modellezés és analízis: Mire jó ez egyáltalán?

Majzik István Méréstechnika és Információs Rendszerek Tanszék

2007. november 14.

Bevezetés: Mi a szolgáltatásbiztonság? • Szolgáltatásbiztonság: Igazoltan bízni lehet a rendszer szolgáltatásában – Megbízhatóság: Folyamatos hibamentes működés – Rendelkezésre állás: Használatra kész rendszer – Biztonságosság: Katasztrofális következmények (baleset, káreset) nélküli működés – Bizalmasság: Nincs jogosulatlan információközlés – Integritás: Hibás változ(tat)ás elkerülése – Karbantarthatóság: Javítás és fejlesztés lehetősége

• Terjedő fogalom: Resilience – Szolgáltatásbiztonság + adatbiztonság + dinamikus (adaptív, mobil, ad-hoc) működés

Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények

Komponensek megbízhatósági paraméterei

Miért van az analízisre szükség? Rendszerekkel Komponensek szemben megbízhatósági támasztott paraméterei követelmények Szolgáltatási szint szerződések (SLA): • Ügyfél által elvárt jellemzők (pl. rendelkezésre állás) • Telekom szolgáltatások szerver rendszerei: „Öt kilences”: 99,999% (5 perc/év kiesés)

Ha 15 év az élettartam, akkor ez alatt kb. 750 berendezésből 1-ben lesz hiba

Biztonságkritikus rendszerek: • Szabvány előírások a véletlen hibák gyakoriságára • Biztonságintegritási szintek (SIL) szerint SIL

Biztonságkritikus funkció hibája / óra

1

10-6 ≤ THR < 10-5

…

…

4

10-9 ≤ THR < 10-8

Hiba nélküli működés ~ 11.000 év?



Technológia korlátai: • Jobb minőségbiztosítás, jobb anyagok • De növekvő bonyolultság (érzékenység) Szokásos becsült értékek: • CPU: 10-5…10-6 hiba/óra • HDD: ~ 3…5 év élettartam • LCD: ~ 2…3 év élettartam Környezeti hatások (zavarok)



Redundáns architektúra, aktív hibakezelés Redundáns komponensek: • Alkatrész szint: Kettős tápegység, RAID, … • Szerver szint: Fürtözés (klaszterek), … Aktív hibakezelés, hibatűrés: • Hibadetektálás és helyreállítás • Hiba esetén biztonságos állapot •…



Redundáns architektúra, aktív hibakezelés Teljesülnek-e a követelmények? • Megfelelő-e az architektúra? • Elég jók-e a komponensek? • Hol érdemes javítani? • Hatékony-e a hibakezelés?

Milyen analízis módszerek vannak? • Mérések működés közben: Hibanaplózás és az eredmények feldolgozása – Jellegzetes hibák illetve faktorok kiszűrése – Statisztikai jellemzők kinyerése

• Kísérleti kiértékelés: Hibainjektálás (várható hibák bevitele) – Hibakezelési eljárások, hibatűrés vizsgálata – Modellen vagy prototípuson is elvégezhető – Hibák lehetnek: hardver, szoftver, környezeti (sugárzás), …

• Megbízhatósági modellezés és modell alapú számítások: – Komponens meghibásodási, hibaterjesztési, javítási folyamatok modellezése • Adott előfeltételezések (pl. független hibák) és absztrakció mellett

– Komponensek (ismert) paraméterei alapján rendszerszintű jellemzők számítása, architektúra-változatok összevetése

Mik a módszerek korlátai? • Mérések működés közben: Hibanaplózás és• azHosszú eredmények feldolgozása idejű ill. nagyszámú mérés kell – Jellegzetes hibák faktorok kiszűrése • illetve Tervezési időben nem ad segítséget – Statisztikai jellemzők kinyerése

• Kísérleti kiértékelés: Hibainjektálás (várható hibák bevitele) – Hibakezelési eljárások, hibatűrés vizsgálata • Kérdéses a magas szinten bevitt hibák valósághűsége – Modellen vagy prototípuson is elvégezhető • Költséges az alacsony szintű hibák bevitele – Hibák lehetnek: hardver, szoftver, környezeti (sugárzás), …

• Megbízhatósági modellezés és modell alapú számítások: – Komponens meghibásodási, hibaterjesztési, • Mennyire valósághű a modellezés? javítási folyamatok modellezése

• Jogosak-e az előfeltételezések és az absztrakció? • Adott előfeltételezések (pl. független hibák) és absztrakció mellett

• Ismertek-e a komponensek paraméterei? – Komponensek alapján rendszerszintű • Szoftver(ismert) esetén aparaméterei tesztelés adhat támpontot jellemzők számítása, architektúra változatok összevetése • Mennyire bonyolult lesz a modell, megoldható-e? •

Analitikus megoldás nem mindig van (szimuláció kell)

Megbízhatósági modellezés • Kombinatorikus modellek – Hibafa, eseményfa, hibamód- és hatás analízis – Rendszerhiba: Komponensek független hibáinak statikus kombinációjaként vagy időbeli forgatókönyveként felírva – A hibák és hatások szisztematikus áttekintését támogatják

Megbízhatósági modellezés • Kombinatorikus modellek – Hibafa, eseményfa, hibamód- és hatás analízis – Rendszerhiba: Komponensek független hibáinak statikus kombinációjaként vagy időbeli forgatókönyveként felírva – A hibák és hatások szisztematikus áttekintését támogatják

• Sztochasztikus állapot-alapú modellek – Markov-láncok, sztochasztikus Petri-hálók • Feltételezés: Meghibásodási, javítási folyamat: exp. eloszlás

– Rendszerhiba: Adott állapot-partíció eléréséhez kötve, ennek bekövetkezési valószínűségét számítva – Finomabb modellezésre ad lehetőséget: • Degradált működési állapotok • Összefüggő (közös módusú) hibák • Javítási függőségek, javítási illetve helyreállítási stratégiák

Érdekes analízis eredmények • Redundáns architektúrák analízise – Rossz minőségű (kis megbízhatóságú) komponenseket nem lehet replikációval és szavazással „feljavítani” • Az eredő megbízhatóság csökken az egyszereshez képest

– Jó minőségű (nagy megbízhatóságú) komponensekből sem mindig érdemes redundáns rendszert kialakítani K1 (pl. átkapcsoló logika) bejövő hibája • A redundancia kezelés „leronthatja” a rendszert az egyszeres komponenshez képest

K2 Szavazó – Szavazásos redundáns rendszer: az első rendszerhiba bekövetkezésének várható ideje kisebb lesz K3 • De ennél rövidebb időtartam túlélési valószínűsége jobb lesz

(„misszió” idejének túlélése hiba nélkül) • Rendszeres karbantartással fenntartható magas rendelkezésre állás (pl. repülőgép fedélzeti rendszerek, erőművi rendszerek)

Érdekes analízis eredmények • Redundáns architektúrák analízise – Rossz minőségű (kis megbízhatóságú) komponenseket nem lehet replikációval és szavazással „feljavítani” • Az eredő megbízhatóság csökken az egyszereshez képest

– Jó minőségű (nagy megbízhatóságú) komponensekből sem mindig érdemes redundáns rendszert kialakítani • A redundancia kezelés (pl. átkapcsoló logika) bejövő hibája „leronthatja” a rendszert az egyszeres komponenshez képest

– Szavazásos redundáns rendszer: az első rendszerhiba bekövetkezésének várható ideje kisebb lesz • De ennél rövidebb időtartam túlélési valószínűsége jobb lesz („misszió” idejének túlélése hiba nélkül) • Rendszeres karbantartással fenntartható magas rendelkezésre állás (pl. repülőgép fedélzeti rendszerek, erőművi rendszerek)

Aktuális kutatási területeink I. • •

Hibainjektálás: Szoftver alapú hibák Hibanaplók feldolgozása adatbányászattal – Milyen paraméterektől függ a hibajelenség?

DBMS is PostgreSQL? Accidental shutdown or session killed

DBMS is Oracle8i?

Session killed?

Remove table?

Accidental shutdown ? Remove table?

0 Session killed

400-1000 200 200-400 -400 Accidental shutdown

200-600

Remove data file/table

Remove table

0 Remove data file

0-200 Accidental shutdown

200 -600 Remove table

0 Remove data file

Aktuális kutatási területeink II. • •

Megbízhatósági modellek automatikus generálása mérnöki modellek alapján Általános séma: 1. Rendszer modellje (pl. UML, AADL) 2. Komponensek felparaméterezése • • • •

Típus (szoftver, hardver, állapota van-e) Meghibásodási gyakoriság, hiba lappangási idő, javítási idő Hibaterjedési valószínűség komponensek között Redundancia típusa

3. Megbízhatósági modell generálása 4. Rendszerparaméterek számítása a modell megoldásával (pl. Markov-lánc állapotvalószínűség)

Eszközfejlesztés Paraméterezett UML modell

UML → SPN transzformáció

Megbízhatósági modell (SPN)

Külső megoldó eszköz

Rendszerszintű jellemzők


Rendszermodell UML osztály/objektum diagram






Megbízhatósági modell






Rendszerszintű megbízhatóság






Redundanciaés hibakezelés tervezési minták


Analízis modellkönyvtár Hibaterjedés modellje


Propagation New restart

t1 prop(PP)


Choice

Rendszerszintű jellemzők [to]E|F

Used

no_prop(1-PP) [to]H

[from]F

[from]H

Aktuális projekt: SAFEDMI •

Biztonságkritikus mozdonyvezetői kezelőfelület fejlesztése, analízise és tesztelése – Bemenet: Rendszerarchitektúra UML modellje (komponens paraméterekkel kiegészítve) – Hierarchikus megbízhatósági modellezés • •

Üzemmódok, taszkok szerinti rész-modellek Rész-modell megoldása magasabb szintű modell paramétere

– Számítás: Rendszer megbízhatóság (veszélyes hiba gyakoriság megfelel-e a SIL-nek)

Aktuális projekt: SAFEDMI Architektúra Követelmények

Analitikus modellezés


Szimuláció

Kísérleti vizsgálat

Kommunikáció

Prototípus

Aktuális projekt: SAFEDMI Architektúra Követelmények

Analitikus modellezés


Szimuláció

Érzékenységvizsgálat, finomítás

Kísérleti vizsgálat Modell paraméterek, absztrakció

Kommunikáció

Prototípus

Aktuális projekt: HIDENETS •

IP alapú hálózati szolgáltatások mobil ad-hoc környezetben (mozgó autók között) – Bemenetek: • • •

Felhasználói aktivitások modellje (workflow) Rendszerarchitektúra UML modellje Mobil ad-hoc környezet modellje (hálózati topológia)

– Időbeli fázisok modellezése •

Mobil környezet, aktivitás változása, hibák bekövetkezése

– Számítás: Felhasználói munkafolyamat hibamentes végrehajtásának valószínűsége

Aktuális projekt: HIDENETS Fázisok azonosítása

Rész-modellek megoldása

Absztrakció

Összefoglalás: A megbízhatósági analízis technikái • Tervezési fázisban: Becsült (nem pontos) paraméterek alapján végzett modell alapú analízis – Architektúra változatok összehasonlítása – Szűk keresztmetszetek keresése, érzékenységvizsgálat

• Prototípus fázisban: Hibainjektálás – Hibakezelési módszerek tesztelése – Paraméterek származtatása

• Működési fázisban: Paraméterek mérése, finomított modell alapú analízis – Tervezési fázis feltételezéseinek, döntéseinek igazolása – Előrejelzés, karbantartás optimalizálás, hatásvizsgálat

Megbízhatósági modellezés és analízis: Mire jó ez egyáltalán?

Recommend Documents