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

Hasonló dokumentumok
3. Biztonságkritikus rendszerek

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Biztonsági folyamatirányító. rendszerek szoftvere

Szoftverminőségbiztosítás

A szolgáltatásbiztonság alapfogalmai

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Autóipari beágyazott rendszerek. Funkcionális biztonságossági koncepció

biztonságkritikus rendszerek

Biztonságkritikus rendszerek architektúrája (2. rész)

Autóipari beágyazott rendszerek. Kockázatelemzés

Architektúra tervezési példák: Architektúrák biztonságkritikus rendszerekben

MINTA Írásbeli Záróvizsga Mechatronikai mérnök MSc. Debrecen,

BME Járműgyártás és -javítás Tanszék. Javítási ciklusrend kialakítása

Szoftverminőségbiztosítás

Verifikáció és validáció Általános bevezető

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Norway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.

Követelmények a megbízható működés terén. Információbiztonsági osztályozás a megbízható működés szempontjából. T - T üz T

Biztonságkritikus rendszerek Gyakorlat: Architektúrák

Multi-20 modul. Felhasználói dokumentáció 1.1. Készítette: Parrag László. Jóváhagyta: Rubin Informatikai Zrt.

A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata

Dr. BALOGH ALBERT: MEGBÍZHATÓSÁGI ÉS KOCKÁZATKEZELÉSI SZAKKIFEJEZÉSEK FELÜLVIZSGÁLATÁNAK HELYZETE

Új kompakt X20 vezérlő integrált I/O pontokkal

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ. 62 Információtechnológiai szolgáltatás Információtechnológiai szolgáltatás

TM Vasúti átjáró vezérlő. Railroad-crossing controller. Használati útmutató. User's manual

M43. Közelítőkártyás indításgátló készülék rablásgátló funkció lehetőséggel. Telepítési útmutató

Szárazföldi autonóm mobil robotok vezérlőrendszerének kialakítási lehetőségei. Kucsera Péter ZMNE Doktorandusz

5. KOMBINÁCIÓS HÁLÓZATOK LEÍRÁSÁNAK SZABÁLYAI

A/D és D/A konverterek vezérlése számítógéppel

Biztonságkritikus rendszerek architektúrája

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK

Az informatikai katasztrófa elhárítás menete

Rubin SMART COUNTER. Műszaki adatlap 1.1. Státusz: Jóváhagyva Készítette: Forrai Attila Jóváhagyta: Parádi Csaba. Rubin Informatikai Zrt.

Szolgáltatásbiztos rendszerek: Architektúra tervezési példák

A szolgáltatásbiztonság alapfogalmai

TM TM TM-77203

Miskolci Egyetem Általános Informatikai Tanszék

A tesztelés feladata. Verifikáció

Modulzáró ellenőrző kérdések és feladatok (2)

24 V DC áramkörök biztosítása

Adatmodellezés. 1. Fogalmi modell

VTOL UAV. Moduláris fedélzeti elektronika fejlesztése pilóta nélküli repülőgépek számára. Árvai László, Doktorandusz, ZMNE ÁRVAI LÁSZLÓ, ZMNE

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

Karbantartási Utasítás

Közlekedési automatika Biztonsági folyamatirányító rendszerek szoftvere

Szoftverminőségbiztosítás

KÖZLEKEDÉSÜZEMI ÉS KÖZLEKEDÉSGAZDASÁGI TANSZÉK. Prof. Dr. Tánczos Lászlóné 2015

MUST Három fázisú Moduláris UPS. A moduláris UPS előnyei már mindenki számára elérhetőek

Laborinformációs menedzsment rendszerek. validálása. Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH)

Hálózatkezelés Szolgáltatási minőség (QoS)

11.2. A FESZÜLTSÉGLOGIKA

Alkalmazások típusai Szoftverismeretek

Véges állapotú gépek (FSM) tervezése

Irányítástechnikai alapok. Zalotay Péter főiskolai docens KKMF

Hibajavító kódok május 31. Hibajavító kódok 1. 1

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Biztonságkritikus rendszerek architektúrája

TAKARNET24 szolgáltatásai

Osztott jáva programok automatikus tesztelése. Matkó Imre BBTE, Kolozsvár Informatika szak, IV. Év 2007 január

30 MB INFORMATIKAI PROJEKTELLENŐR

USB I/O kártya. 12 relés kimeneti csatornával, 8 digitális bemenettel (TTL) és 8 választható bemenettel, mely analóg illetve TTL módban használható.

TM Fékezés és állomás vezérlő modul

Intelligens beágyazott rendszer üvegházak irányításában

D/A konverter statikus hibáinak mérése

Programozás és Digitális technika I. Pógár István eng.unideb.hu/pogari

Az irányítástechnika alapfogalmai Irányítástechnika MI BSc 1

TM Szervó vezérlő és dekóder

ÁLTALÁNOS JELLEGŰ ELŐÍRÁSOK. A hitelesítési folyamat résztvevőit, az alapelemeket és a főbb kapcsolódási pontokat az 1.

Bevezetés. Adatvédelmi célok

SZOLGÁLTATÁS BIZTOSÍTÁS

A szolgáltatásbiztonság alapfogalmai

Algoritmusok Tervezése. 6. Előadás Algoritmusok 101 Dr. Bécsi Tamás

IoT alapú mezőgazdasági adatgyűjtő prototípus fejlesztési tapasztalatok

Elektronikus közhiteles nyilvántartások Megvalósítási tanulmány

Városi tömegközlekedés és utastájékoztatás szoftver támogatása

Laboratóriumi műszerek megvalósítása ARM alapú mikrovezérlővel és Linux-szal

TERMÉK FEJLESZTÉS PANDUR BÉLA TERMÉK TERVEZÉSE

Az elektronikus közszolgáltatások biztonságáról

AIRPOL PRM frekvenciaváltós csavarkompresszorok. Airpol PRM frekvenciaváltós csavarkompresszorok

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Biztonsági utasítások 3 A véletlen indítás megelőzése 3. Általános leírás 6

Programrendszerek tanúsítása szoftverminőség mérése

Modulzáró ellenőrző kérdések és feladatok (2)

ZL180 Kétmotoros vezérlés 24V-os mototokhoz

Roger UT-2. Kommunikációs interfész V3.0

Funkciópont elemzés: elmélet és gyakorlat

LED DRIVER 6. 6 csatornás 12-24V-os LED meghajtó. (RDM Kompatibilis) Kezelési útmutató

I. Definíciók. 1. Üzletmenet folytonossági terv - katasztrófa terv. Üzletmenet folytonossági tervezés

Hibadetektáló rendszer légtechnikai berendezések számára

Számítógép architektúra

Joint Test Action Group (JTAG)

Informatika Rendszerek Alapjai

Rendszertervezés 2. IR elemzés Dr. Szepesné Stiftinger, Mária

A vizsga részei A vizsga értékelése Gyakorlat i

IMIR fejlesztése, bevezetése és működés-támogatása - módosító hirdetmény. Közbeszerzési Értesítő száma: 2015/99

Foglalkozási napló a 20 /20. tanévre

Átírás:

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 [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

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 Bemenet Normál modul Átkapcsoló egység 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 2. modul Szavazó egység Kimenet 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 SW 1 SW 2 CPU 1 CPU 2 Összehasonlító 25

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

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 Logikai csatorna Összehasonlító B 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 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

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

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

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

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