SZOFTVER-MINŐSÉGBIZTOSÍTÁS BIZTONSÁGKRITIKUS RENDSZEREK. Széchenyi István Egyetem. Alapfogalmak

Átírás

1 Alapfogalmak Biztonságkritikus rendszer: Olyan informatikai rendszer, amely azzal az elsődleges követelménnyel működtetendő, hogy ne veszélyeztesse az emberi életet, egészséget, ne okozzon gazdasági vagy környezeti károkat. Hibatűrő rendszer: Egy informatikai rendszer hibatűrő, ha képes elvégezni, ill. tovább folytatni előírt feladatának helyes végrehajtását hardvermeghibásodások és szoftver-hibák jelenléte esetén. 1

2 Minőségi és megbízhatósági követelmények Megbízhatóság (Reliability): Annak feltételes valószínűsége, hogy a rendszer hibátlanul működik a [t 0, t] időintervallumban, feltéve, hogy a t 0 t időpontban hibátlanul működött. A megbízhatóságot leíró valószínűségi függvény jele R(t). 2

3 Minőségi és megbízhatósági követelmények Rendelkezésre állás (Availability): Annak valószínűsége, hogy a rendszer helyesen működik a t időpontban, vagyis a t időpontban rendelkezésre áll. A rendelkezésre állást leíró valószínűségi függvény jele A(t). 3

4 Minőségi és megbízhatósági követelmények Biztonságosság (Safety): Annak valószínűsége, hogy a rendszer helyesen vagy hibásan működik a t időpontban, de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem befolyásolja károsan más rendszerek működését. Másként fogalmazva: Annak valószínűsége, hogy a rendszer a t időpontban biztonságosan működik. A biztonságosságot leíró valószínűségi függvény jele S(t). 4

5 Minőségi és megbízhatósági követelmények A biztonság fenntartása úgy oldandó meg, hogy a rendszer olyan sorrendben hagy fel, egymás után, a funkciók ellátásával, ami a katasztrófa elkerülését teszi lehetővé. Ez a fokozatos leépülés esete (angol elnevezéssel: graceful degradation). A másik elterjedt vészmegoldás az, hogy a rendszer, még utolsó intézkedéseként mindent úgy állít le, hogy a katasztrófa semmiképpen ne tudjon bekövetkezni 5

6 Minőségi és megbízhatósági követelmények Teljesítőképesség (Performability): Annak valószínűsége, hogy a rendszer teljesítőképessége a t időpontban eléri vagy meghaladja az L szintet. A teljesítőképességet leíró valószínűségi függvény jele P(L, t). 6

7 Minőségi és megbízhatósági követelmények Karbantarthatóság (Maintainability): Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt. Ebbe az időbe beletartozik a hiba helyének meghatározása, a fizikai javítás vagy csere elvégzése, valamint az újraindítás. A karbantarthatóságot leíró valószínűségi függvény jele M(t). 7

8 Minőségi és megbízhatósági követelmények Igen fontos tulajdonsága egy rendszernek a tesztelhetőség (testability) is. A tesztelhetőség azt a lehetőséget jelenti, hogy vizsgálatok, tesztek segítségével meg tudjuk határozni a rendszer egyes működési tulajdonságait. A tesztelhetőség mértéke azt fejezi ki, hogy mekkora ráfordítással, nehézséggel jár egy-egy tesztelési folyamat elvégzése. Ehhez a fogalomhoz igen nehéz jól használható kvantitatív mérőszámot rendelni, ilyen mérőszám jelenleg nincs még definiálva. 8

9 A hibatűrés fő alkalmazási területei Hosszú élettartamú alkalmazások több éves időtartamban működnek, általában a javításra kevés lehetőséggel, pl.: űrrepülés, műholdak, űrszondák Kritikus számítások viszonylag rövid időtartamra, amíg egy kritikus működési, számítási szakaszban üzemel a rendszer, a megbízhatósága garantáltan magas legyen, pl.:vegyi üzem szabályozó rendszere Elhalasztott karbantartás a karbantartási műveleteket igen nehéz, vagy igen költséges elvégezni, pl.: telefonközpont Magas szintű rendelkezésre állás on-line tranzakció-feldolgozást végző rendszerek, pl.: banki alkalmazások 9

10 Hibatűrő rendszerstruktúrák előre betervezett redundancia saját hibás működés felismerése redundancia mind a hardverben, mind pedig a szoftverben a hardver és a szoftver a hibafelismerésben és az ilyenkor szükséges reakciókban is kiegészítik, vagy átfedik egymást 10

11 Hibatűrő rendszerstruktúrák A redundancia megvalósítása Hardver-redundancia Szoftver-redundancia Információs redundancia Idő-redundancia 11

12 Hardver-redundancia A hibatűrés elérése érdekében kiegészítő hardver elemeket alkalmaznak, különböző funkciókkal. A funkciók egyrészt a működéshez kapcsolódó tesztelést (beépített öntesztelést), másrészt pedig egyes elemek ismétlését (tartalékként) jelentik általában. 12

13 Szoftver-redundancia A hibatűrés elérése érdekében kiegészítő szoftver elemeket, ill. szoftverrel megvalósított módszereket alkalmaznak. Itt is számításba kell vennünk a szoftvert az öntesztelés megvalósításában, valamint az ismétlődő funkciók ellátásában. 13

14 Információs redundancia A működési biztonság növelése érdekében többletinformációt, többletbiteket használnak fel. Ezáltal a hibák detektálására és/vagy tolerálására kerülhet sor. Tipikus elterjedt megoldás például a paritásbitek, hibadetektáló kódok, hibajavító kódok, ellenőrző összegek (check sum) használata. A hibajavító kódok nemcsak detektálásra, hanem tolerálásra, vagyis a hiba elfedésére, hatásának megszüntetésére is alkalmasak. 14

15 Idő-redundancia A szükségesnél hosszabb feldolgozási idő igénybevétele. A legelterjedtebb megoldás a feldolgozás, a számítások ismételt lefolytatása, az eredmények összehasonlításával egybekötve. Ezzel elérhető az, hogy a hardverben fellépő átmeneti hibát, amely az egyik végrehajtás alatt érvényesült, egy újabb végrehajtással ki lehessen ejteni. 15

16 A hardver-redundancia megvalósítása Párhuzamos duplikálás Tartalékelemes üzemeltetés Hárommodulos redundancia 16

17 Párhuzamos duplikálás hardver egységnek a megkettőzése és párhuzamos működtetése mindkét egység ugyanazokat a bemenő jeleket kapja, és helyes működés esetén ugyanazokat az eredményeket is kell produkálniuk az eredmények megfigyeléséről és összevetéséről egy külön beiktatott összehasonlító egység gondoskodik hibát csak detektálni lehet, de elfedésére, tolerálására már nincs mód 17

18 Párhuzamos duplikálás 1. modul Bemenet Összehasonlító egység Kimenet 2. modul 18

19 Tartalékelemes üzemeltetés két azonos egység vesz részt, de csak az egyik, a normál egység fejt ki üzemszerű működést, a másik tartalékként szerepel azt, hogy melyik egység jelei jutnak a kimenetre, az átkapcsoló modul intézi el, a hibadetektor modul parancsa alapján a tartalékmodult kétféle állapotban szokás használni a normál üzemelés folyamán nincs tápfeszültség alá helyezve (hideg tartalék) állandóan be van kapcsolva, és működést fejt ki (meleg tartalék) 19

20 Tartalékelemes üzemeltetés Hibadetektáló egység Bemenet Normál modul Átkapcsoló egység Kimenet Tartalék modul 20

21 Hárommodulos redundancia angolul: Triple Modular Redundancy, -TMR. a három megismételt modul jelei egy ún. szavazóegységre (voting unit, voter) jutnak többségi szavazás elvén működik ha tehát egy modul meghibásodik, akkor a másik kettő azonosan helyes működése érvényesül ha két vagy három modul hibásodna meg, akkor várhatólag három különböző jel jutna a szavazóra, amely ilyenkor deklarálná a teljesen téves működést 21

22 Hárommodulos redundancia Az eltűrt hibás modulok száma úgy növelhető, hogy növeljük a párhuzamosan dolgozó modulok számát, de mindig úgy, hogy ez a szám páratlan legyen a többségi szavazással összhangban. Könnyen belátható, hogy az eltűrt hibás modulok száma N 3 esetén az (N 1) / 2 képlettel határozható meg 22

23 Hárommodulos redundancia 1. modul Bemenet 2. modul Szavazó egység Kimenet 3. modul (Többségi szavazás) 23

24 A szoftver-redundancia megvalósítása A szoftver-hibatűrés két céllal valósítható meg: A szoftver saját hibájának elfedésére. A szoftver saját és a hardver hibáinak együttes elfedésére. 24

25 Kétcsatornás szoftverműködés SW 1 SW 2 CPU 1 CPU 2 Összehasonlító 25

26 Szoftver-diverzitás SW 1 SW 2, CPU 1 CPU 2 Csak hardver hiba detektálható SW 1 SW 2 Szoftver-diverzitás N-verziós programozás Javító blokkok módszere 26

27 N-verziós programozás A teljes szoftvert N db. példányban valósítják meg, két lehetséges megközelítésben: Ugyanazt a programozási nyelvet alkalmazva, egymástól független, különböző fejlesztő csoportok, team-ek. Eltérő programozási nyelveket alkalmazva, egymástól független, különböző fejlesztő csoportok, team-ek. 27

28 N-verziós programozás Az N program a számítógépes szervezéstől függően lefut, akár párhuzamosan, akár sorosan. N = 2 esetén, ha párhuzamos feldolgozás történik, csak hibadetektálás N = 3, mód nyílik a TMR-szisztéma alkalmazására 28

29 Javító blokkok módszere Ebben a teljes szoftvert több modulra bontják, és az egyes modulok többverziós megvalósításával, valamint a modulok önteszteléssel egybekötött újrafuttatásával érhetjük el a hibatűrést. 29

30 Javító blokkok módszere Egy-egy modul azonos funkciójú verziói alkotnak egy blokkot. Mindegyik blokkhoz tartozik egy ún. elfogadási teszt (acceptance test) Ha egy modulverziót elfogad a teszt, újabb verzióra nem kerül sor. Ha egy modulverzió hibásnak bizonyul a teszt alapján, akkor a soron következő tartalékmodul futtatására kerül sor, a blokkon belül mindaddig, amíg csak van futtatható modulverzió. 30

31 Javító blokkok módszere Az elfogadási tesztek megírása igen komoly szellemi ráfordítást igényel. Néhány követendő irányelv lehet a következő: Annak ellenőrzése, hogy egy kiszámított érték az elfogadható normális fizikai tartományba esik-e (például, hőmérséklet vagy nyomás). Nem történt 0-val való osztás. Nem történt címtartományon kívüli címzés, a tömbdeklarációk figyelembevételével. Egy-egy fontos számérték meghatározása alternatív algoritmussal is megtörténik. 31

32 Az ALCATEL ELEKTRA számítógépes vasútirányító rendszer vasúti pályaudvarok forgalmának irányítására szolgál biztonságkritikus rendszer, kötelezően előírt hibatűréssel kétoldalú információs kapcsolat bejövő információ a vonatok, szerelvények mozgása, helyzete kimenő információ a külsőtéri berendezések automatizált vezérlése 32

33 Az ALCATEL ELEKTRA Vasúti irányítórendszer vázlata Számítógépes irányítórendszer Vasúti pályaudvar irányító központja Hardver interfész Külsőtéri berendezés: jelzőlámpák, váltók Pályaudvar 33

34 Az ALCATEL ELEKTRA Az ALCATEL-ELEKTRA megkettőzött párhuzamos felépítésű rendszer, amelyben a két párhuzamos csatornához (A és B csatorna)) egymástól eltérő fejlesztésű szoftverek tartoznak. Az A csatorna elnevezése: logikai csatorna. A B elnevezése: biztonsági csatorna. 34

35 Az ALCATEL ELEKTRA 1. Számítógéprendszer 2. Számítógéprendszer A Csatorna Logikai csatorna Összehasonlító B Csatorna Biztonsági csatorna Hardver interfész Irányított folyamat 35

36 Az ALCATEL ELEKTRA Az A csatorna szoftvere egy CHILL programozási nyelven elkészített procedurális végrehajtású program. (A CHILL magas szintű programnyelv, a telekommunikáció területén fejlesztett valós idejű (real-time) rendszereknél terjedt el a felhasználása.) A B csatorna szoftvere nem procedurális program, hanem egy önálló szakértői rendszer. Elnevezése: SAFETY BAG (biztonsági csomag). Létrehozása a PAMELA nevű fejlesztői környezetben ment végbe. 36

37 Az ALCATEL ELEKTRA Az A jelű csatorna a forgalomirányítás bejövő jeleit dolgozza fel logikailag, az adott helyzetet elemzi, kiértékeli, és a szükséges vezérlő jeleket küldi ki. A B csatorna a biztonsági működést szolgálja. A bejövő jeleket elemzi, döntést hoz, majd megvizsgálja az A csatorna döntését. Ha azt elfogadja, az A intézkedése kimegy. Ha nem fogadja el, akkor a következő esetek lehetségesek: B veszi át az intézkedést. B tiltó jelet ad ki a forgalom korlátozására. B leállítja a forgalmat. 37

38 Az ALCATEL ELEKTRA A döntéshozatalhoz mindkét csatorna a TMR-struktúrát alkalmazza. A csatornák több ponton el vannak látva öntesztelő egységekkel is. Hibadetektálás esetén a hiba helye az áramköri kártya szintjéig automatizáltan behatárolódik. Egyes kártyák üzem közben is kicserélhetők. 38

39 Az ALCATEL ELEKTRA Az ELEKTRA-szisztéma hibalefedési képessége A párhuzamosan, valamint a TMR-ben szervezett működtetés nemcsak az állandósult, hanem az átmeneti hardver-hibák felfedésére is alkalmas. A két csatorna egymástól gyökeresen eltérő szoftvermegoldása lényegesen növeli a biztonságot. Olyan üzemelési veszélyek elkerülése is lehetővé válik, amelyekkel a tervezési folyamatban nem kalkuláltak. 39

40 Az ALCATEL ELEKTRA A lehetséges hibák felosztása H E : Az előre feltételezett és detektálható hardver-hibák H N : Olyan hibák, amelyek bekövetkezésével nem kell számolni, felismerésük az ELEKTRÁ-n kívül H I : A biztonságra nem ható, irreleváns hibák köre H U : Azon hibák köre, amelyekről nincs semmilyen előzetes tudomásunk 40

41 Az ALCATEL ELEKTRA A lehetséges hibák felosztása H E H: H N H U H I H = H E H N H I H U 41

42 Az ALCATEL ELEKTRA Legyen azoknak a hibáknak a halmaza H A, amelyeket nem ismerünk, és amelyek megnyilvánulása, jelentkezése az A csatorna működésének a következ-ménye. Legyen azoknak a hibáknak a halmaza H B, amelyeket nem ismerünk, és amelyek megnyilvánulása, jelentkezése a B csatorna működésének a következménye. H A H B 42

43 Az ALCATEL ELEKTRA Legyen továbbá azoknak a hibáknak a halmaza H X, amelyeket nem ismerünk, és hatásuk teljesen kívül esik az ELEKTRA működési körén. H A H B H X 43

44 Az ALCATEL ELEKTRA A H A és H B halmazok egymással diszjunkt részei olyan hibákat foglalnak magukban, amelyekre a két csatorna eltérően reagál, így azok a hibák a csatornák közötti működési összehasonlításban detektálódnak. Ezzel szemben nem áll fenn ugyanez a két halmaz közös részére. A hibáknak a H V halmaza, amelyek potenciális katasztrófaveszélyt jelentenek: H V = (H A H B ) H X 44