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

Átírás

1 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 november 14.

2 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

3 Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények Komponensek megbízhatósági paraméterei

4 Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények Komponensek megbízhatósági paraméterei 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 1 4 Biztonságkritikus funkció hibája / óra 10-6 THR < THR < 10-8 Hiba nélküli működés ~ év?

5 Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények Komponensek megbízhatósági paraméterei 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: hiba/óra HDD: ~ 3 5 év élettartam LCD: ~ 2 3 év élettartam Környezeti hatások (zavarok)

6 Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények Komponensek megbízhatósági paraméterei 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

7 Miért van az analízisre szükség? Rendszerekkel szemben támasztott követelmények Komponensek megbízhatósági paraméterei 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?

8 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

9 Mik a módszerek korlátai? Mérések működés közben: Hibanaplózás és az eredmények feldolgozása Hosszú idejű ill. nagyszámú mérés kell Jellegzetes hibák illetve Tervezési faktorok időben kiszűrése 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, javítási Mennyire folyamatok valósághű modellezése a modellezés? 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 Szoftver (ismert) esetén a paraméterei tesztelés adhat alapján támpontot rendszerszintű jellemzők Mennyire számítása, bonyolult architektúra lesz a modell, változatok megoldható-e? összevetése Analitikus megoldás nem mindig van (szimuláció kell)

10 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

11 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

12 É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 K 1 A redundancia kezelés (pl. átkapcsoló logika) bejövő hibája leronthatja a rendszert az egyszeres komponenshez képest K 2 Szavazó Szavazásos redundáns rendszer: az első rendszerhiba bekövetkezésének várható ideje kisebb lesz K 3 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)

13 É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)

14 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? Accidental shutdown or session killed DBMS is PostgreSQL? DBMS is Oracle8i? Session killed? Remove table? Accidental shutdown? Remove table? Session killed Accidental shutdown Remove data file/table Remove table Remove data file Accidental shutdown Remove table Remove data file

15 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)

16 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

17 Eszközfejlesztés Paraméterezett UML modell Rendszermodell UML osztály/objektum diagram UML SPN transzformáció Megbízhatósági modell (SPN) Külső megoldó eszköz Rendszerszintű jellemzők

18 Eszközfejlesztés Paraméterezett UML modell Megbízhatósági modell UML SPN transzformáció Megbízhatósági modell (SPN) Külső megoldó eszköz Rendszerszintű jellemzők

19 Eszközfejlesztés Paraméterezett UML modell Rendszerszintű megbízhatóság UML SPN transzformáció Megbízhatósági modell (SPN) Külső megoldó eszköz Rendszerszintű jellemzők

20 Eszközfejlesztés Paraméterezett UML modell Redundanciaés hibakezelés tervezési minták UML SPN transzformáció Analízis modellkönyvtár Megbízhatósági modell (SPN) Hibaterjedés modellje Propagation New t1 restart prop(pp) Külső megoldó eszköz Rendszerszintű jellemzők Choice no_prop(1-pp) Used [to]e F [to]h [from]f [from]h

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

22 Aktuális projekt: SAFEDMI Architektúra Követelmények Analitikus modellezés Külső megoldó eszköz Szimuláció Kísérleti vizsgálat Kommunikáció Prototípus

23 Aktuális projekt: SAFEDMI Architektúra Követelmények Analitikus modellezés Külső megoldó eszköz Modell paraméterek, absztrakció Szimuláció Kísérleti vizsgálat Kommunikáció Érzékenységvizsgálat, finomítás Prototípus

24 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

25 Aktuális projekt: HIDENETS Fázisok azonosítása Rész-modellek megoldása Absztrakció

26 Ö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