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

SZOFTVER-MINŐSÉGBIZTOSÍTÁS

Széchenyi István Egyetem

BIZTONSÁGKRITIKUS RENDSZEREK

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




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 [t0 , t] időintervallumban, feltéve, hogy a t0 ≤ 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




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




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




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




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




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




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




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




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




Hibatűrő rendszerstruktúrák

A redundancia megvalósítása Hardver-redundancia Szoftver-redundancia Információs redundancia Idő-redundancia

11




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




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




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




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




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

16




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




Párhuzamos duplikálás

1. modul Bemenet

Összehasonlító egység

Kimenet

2. modul

18




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




Tartalékelemes üzemeltetés Hibadetektáló egység

Normál modul Átkapcsoló egység Bemenet

Kimenet

Tartalék modul

20




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




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




Hárommodulos redundancia 1. modul Bemenet Kimenet 2. modul

Szavazó egység

3. modul (Többségi szavazás)

23




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




Kétcsatornás szoftverműködés

SW1

SW2

CPU 1

CPU2

Összehasonlító

25




Szoftver-diverzitás

SW1 ≡ SW2 , CPU1 ≡ CPU2 Csak hardver hiba detektálható

SW1 ≠ SW2 Szoftver-diverzitás N-verziós programozás Javító blokkok módszere

26




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




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




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




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




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




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




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




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




Az ALCATEL ELEKTRA 1. Számítógéprendszer

2. Számítógéprendszer

A Csatorna

B Összehasonlító

Logikai csatorna

Csatorna Biztonsági csatorna

Hardver interfész

Irányított folyamat

35




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




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




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




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




Az ALCATEL ELEKTRA

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




Az ALCATEL ELEKTRA

A lehetséges hibák felosztása

HE HN

H:

HU

HI

H = HE ∪ HN ∪ HI ∪ HU

41




Az ALCATEL ELEKTRA Legyen azoknak a hibáknak a halmaza HA, 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 HB, amelyeket nem ismerünk, és amelyek megnyilvánulása, jelentkezése a B csatorna működésének a következménye. HA

HB

42




Az ALCATEL ELEKTRA

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

HA

HB

HX

43




Az ALCATEL ELEKTRA A HA és HB 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 HV halmaza, amelyek potenciális katasztrófaveszélyt jelentenek: HV = (HA ∩ HB) ∪ HX

44

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

Recommend Documents