SZÁMÍTÓGÉPEK ALKALMAZÁSA KRITIKUS TERÜLETEKEN (2)

BIZTONSÁGKRITIKUS SZÁMÍTÓGÉP RENDSZEREK Kritikus rendszer: valamely jellemzőjével szemben a szokásosnál nagyobbak a követelmények Saftey--Critical Computer Systems Saftey

1

SAFETY--CRITICAL COMPUTER SYSTEMS SAFETY 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Bevezetés Biztonsági kritériumok Veszélyelemzés Kockázatelemzés Biztonságkritikus rendszerek fejlesztése Hibatűrés Rendszer--megbízhatóság Rendszer Biztonságkritikus hardver Biztonságkritikus szoftver PLC--k PLC Formális módszerek Verifikáció, validáció, tesztelés Minőség--menedzsment Minőség Tanúsítás Nagy integritású rendszerek Saftey--Critical Computer Systems Saftey

2

1. Bevezetés Számítógépek alkalmazása kritikus területeken A biztonság Biztonsági rendszerek fejlesztése Költség--haszon Költség

Saftey--Critical Computer Systems Saftey

3

SZÁMÍTÓGÉPEK ALKALMAZÁSA KRITIKUS TERÜLETEKEN (1) Mikroprocesszor 19701970-es évek eleje Folyamatos árcsökkenés a számítógépszámítógép-bázisú technológiánál A számítógépszámítógép-használat drámai növekedése (több gép, mint ember) A processzorokat túlnyomórészt nem asztali vagy más hagyományos számítógép formában használják: beágyazott rendszerek (embedded systems) Spektrum: mosógéptől a korszerű, bonyolult repülőgéprepülőgépirányításig, az ABSABS-től a nukleáris erőművek védelmi rendszeréig Milliós darabszámban: autóipar, háztartási gépek Ipari, közlekedési folyamatirányító rendszerek


4

SZÁMÍTÓGÉPEK ALKALMAZÁSA KRITIKUS TERÜLETEKEN (2) Különbség az általános célú és a beágyazott rendszerek között: – a hibás működés várható következményei

A beágyazott rendszerek hibás működése közvetlen sérülés, környezetkárosodás okozója lehet: – – – –

atomerőmű repülőgép autó motormotor- vagy fékvezérlés vasúti közlekedés

Az ipar módszereket fejlesztett ki a kockázatok megfelelő kezelésére (ezekkel foglalkozunk a későbbiekben) Számos esetben (pl. háztartási gépek) a beágyazott rendszer hibájából adódó veszélyeztetés nem annyira nyilvánvaló Gyakorlatilag bármely rendszer, amely energiát irányít, képes károkozásra (pl. hiba folytán bekapcsolódva marad egy mosógép vagy kenyérpirító fűtése - tűzeset - halálozás)


5

A biztonság fogalma Egy lehetséges definíció: A biztonság egy rendszer azon tulajdonsága, hogy nem veszélyezteti az emberi életet, illetve a környezetet Az előbbi alapján: A biztonsági rendszer olyan rendszer, amelynek révén egy rendszer vagy berendezés biztonsága elérhető Safety--related system= safetySafety safety-critical system Terjedelem: mikrokapcsolótól az erőművi védelmi rendszerig Feladat lehet: – Kifejezetten biztonsági – Egyéb feladatok mellett biztonsági is (pl. robotpilóta vagy vasúti bizt. ber.)

Abszolút biztonság helyett az alkalmazásnak megfelelő biztonság elérése A megfelelőség megítélése gyakran szubjektív (pl. repüléstől való félelem - az autózás veszélyesebb) Saftey--Critical Computer Systems Saftey

6

A biztonság - Integritási szintek

A biztonság megfelelőségének megítélését számos technika segíti A hibás működés következményei az egyes alkalmazási területeken rendkívül különbözőek lehetnek Az integritási szintek tükrözik a helyes működés fontosságát Egy projekthez rendelt biztonsági integritási szint meghatározza az alkalmazandó fejlesztési, tervezési, gyártási, üzemeltetési módszereket Minden rendszerfejlesztéskor meg kell állapítani a biztonsági vonatkozásokat – veszélyelemzés – kockázatelemzés

Az előbbiek alapján meg kell határozni az integritási szintet


7

A biztonság terjedelme A biztonsági vonatkozások a rendszer életének valamennyi fázisát érintik, a koncepciótól az üzemen kívül helyezésig A HW és a SW integrált szerepe a biztonság elérésében Érzékelők, beavatkozók, kábelezés, csatlakozók, tápellátás Kezelő és karbantartó személyzet szerepe a biztonságban A biztonság eléréséhez kevés a jó tervezés: – Gyártási, szerelési, kezelési, üzemeltetési hibák

A biztonság és minőség minőség--menedzsment kapcsolata A biztonsági kérdések érintettjei: – – – –

A megrendelő, az esetleges független szakértő és a hatóság A tervező és a gyártó A szerelő, a kezelő és a karbantartó (üzemeltető) A lakosság mint egy káresemény elszenvedője


8

Számítógépek biztonsági vonatkozásai

A rendszerek elsődleges biztonsága (a HW által okozott közvetlen veszélyeztetés, pl. villamos áramütés, tűz) Funkcionális biztonság (HW és SW korrekt működése a folyamatirányításban) - ezzel foglalkozunk Indirekt biztonság (pl. számítógépszámítógép-hiba közvetett hatása egy biztonsági információs rendszerre) A fejlesztéshez használt HW és SW eszközök (tool(tool-ok) helyes működésének fontossága a biztonság szempontjából


9

Biztonsági rendszerek fajtái Irányító rendszerek (control systems) - Védelmi rendszerek (protection system PES - Programmable Electronic System PLC - Programmable Logic Controller Nem mindenhez kell számítógép - elég lehet egy termosztát

Irányított rendszer (EUC, Equipment Under Control)

Érzékelők (Sensors)

Irányított rendszer

Beavatkozók (Actuators)

Érzékelők

Beavatk.

Hardver Szoftver

Irányító v. védelmi rendszer Saftey--Critical Computer Systems Saftey

10

Számítógépek a biztonsági rendszerekben (1) A számítógépes rendszerek előnyei – Nagy teljesítmény (sok be be--/kimenet kezelése, gyors számítás), kis fogyasztás, kis helyigény olyan komplex feladatok is megoldhatók, amelyek hagyományosan nem

– Extrém megbízhatóság (nagy integráltság, kevés alkatrész, kevés összeköttetés) – Flexibilitás (SW változtatás, HW marad) Viszonylag olcsó módosítás

– A legtöbb esetben alacsonyabb létesítési költség, mint a hagyományosnál - különösen igaz nagy komplexitásnál (kis volumenű projekteknél a fejlesztési, különösen a SW költségek dominálnak!) – A nagy teljesítmény lehetővé teszi bonyolult stratégiák alkalmazását is Öndiagnosztikai rutinok futtatása Feltételek meglétének, tartományok határainak figyelése, ellenőrzése Összetett, komplikált függőségek megvalósítása. Saftey--Critical Computer Systems Saftey

11

Számítógépek a biztonsági rendszerekben (2) A számítógépes rendszerek hátrányai – A legfontosabb éppen a lényegéből adódó nagy komplexitás VLSI - elemek százezrei, rendkívül komplex viselkedés A szoftver nem kevésbé komplex - még egy viszonylag egyszerű programnak is lehet több ezer végrehajtási útvonala A komplex rendszereket nehezebb tervezni, valószínűbb a tervezési hiba Nehezebb tesztelni is, valószínűleg több detektálatlan hiba marad bennük Nehezebben áttekinthetők és érthetők, ezért könnyebb elkövetni installációs vagy üzemeltetési hibát

– Lehetséges meghibásodási módjainak száma (VLSI) rendkívül nagy (praktikusan végtelen) Kimerítő tesztelés és teljes körű hibadetektálás lehetetlen (v.ö. diszkrét elemek) A SW tesztelhetősége legalább annyira problematikus (v.ö. A SW egyre nagyobb szerepével a biztonsági rendszerekben)


12

Biztonsági rendszerek fejlesztése (1) Rendszer--követelmények Rendszer – Funkcionális követelmények megfogalmazása, leírása Hiányosságok, problémák - pedig ez a fejlesztés alapja!!!***

Veszély-- és kockázatelemzés Veszély – Potenciális veszélyforrások, veszélyeztetések meghatározása – Integritási szint hozzárendelése a rendszerhez – Rendszer biztonsági követelmények Mit kell Mit nem szabad

Rendszerspecifikáció - a fejlesztés, tesztelés alapja!!! – Milyen legyen a rendszer, hogy kielégítse a funkcionális és biztonsági követelményeket – Specifikációs hibák (természetes nyelv) Nem teljesség Ellentmondás Félreérthetőség Többértelműség


13

Biztonsági rendszerek fejlesztése (2) Rendszer--architektúra meghatározása (top Rendszer (top--level) – HWHW-SW bontás Biztonsági követelmények Sorozatnagyság Működési idő követelmények Egyéb

Felbontás jól menedzselhető modulokra – Egyszerűbb fejlesztés, tesztelés – Modulspecifikációk a fejlesztéshez, teszteléshez

Modul szintű fejlesztés, megvalósítás, tesztelés – A tesztelés a verifikáció része (a modul teljesíti a specifikációt)

Rendszerintegráció – Fokozatos – Egylépcsős


14

Biztonsági rendszerek fejlesztése (3)

A teljes rendszer verifikálása és validálása - V&V – Verifikáció - annak kimutatása, hogy a modul vagy rendszer teljesíti a specifikációját – Validáció - annak kimutatása, hogy a rendszer megfelel a céljának - specifikációs hibák!!! – A verifikáló és a validáló személyére különböző fokú függetlenséget írnak elő a szabványok

Tanúsítás, engedélyezés – Szabványok, irányelvek - előírt, ajánlott fejlesztési technikák – Hatóság szerepe


15

Fejlesztési életciklus V-modell

Követelmények

• szekvenciák • belső ciklusok • párhuzamos ágak • információáramlás

Veszély- és kockázatelemzés

Tanúsítás

Rendszer validáció

Specifikáció

Architektúra tervezés TOPDOWN

Kész rendszer

Modul tervezés

Rendszer verifikáció

Rendszer integráció, tesztelés

BOTTOMUP

Modul gyártás, tesztelés Saftey--Critical Computer Systems Saftey

16

Hibaok, hiba, rendszer-meghibásodás Hibaok - fault – valamilyen hiányosság a rendszerben (HW - SW, tervezés) – Véletlenszerű (csak HW) - rendszerviselkedés megjóslása – Szisztematikus (HW: specifikációs, fejlesztési stb., az összes SW) Nem véletlenszerű - a rendszerviselkedés nehezen jósolható

– Tartós – Átmeneti - hatása lehet tartós

Hiba - error – A hibaok aktiválódik, megjelenik (HW - SW) – A rendszer vagy egy alrendszer kívánt működéstől való eltérése

Rendszer--meghibásodás – system failure Rendszer – A rendszer nem hajtja végre a megkövetelt funkciókat – Biztonságkritikus rendszerek: rendszerek: a hiba lehetőleg ne okozzon rendszerrendszermeghibásodást

Hibamentes rendszerek – Tökéletes fejlesztés nem érhető el – A rendszer HWHW-elemei működés közben meghibásodhatnak


17

Biztonságkritikus rendszerek - hiba-menedzselés Nem-kritikus rendszerek - a jó teljesítményhez általában Nemelegendő: – Jó fejlesztés/tervezés – Jó minőségű elemek

Kritikus rendszerek - kiegészítő intézkedések szükségesek a hibák uralásához – A hibaokok elkerülése - megelőzés a fejlesztésben – A hibaokok eltávolítása - HW és SW tesztelési technikák, üzembe helyezés előtt – A hibák detektálása - üzem közben, a hibák hatásának mérséklésére – Hibatűrés - a rendszert úgy alakítják ki, hogy a benne jelenlévő hiba ellenére is megfelelően működjön

Hibamenedzselési technikák kombinációja – Önmagában egyik technika sem tökéletesen hatékony – A rendszer rendszer--meghibásodások kívánt/elfogadható szintjének elérése


18

Költség - Haszon (1) A biztonság drága Kompromisszumot kell találni a biztonság és a költségek között Tapasztalat: – A megfelelő biztonság elérését célzó szisztematikus eljárások költsége alacsonyabb, mint a bekövetkezett baleset következményeinek helyreállítása

Mennyi az emberi élet vagy a szenvedés pénzbeli értéke? Sebességcsökkentés - balesetcsökkenés – Készek vagyunk elfogadni a nagyobb eljutási időt és az utak zsúfoltságának növelését emberéletek megmentéséért? •

A biztonság növelésének árát megfizetikmegfizetik-e a felhasználók? A biztonság mekkora foka fogadható el?


19

Költség - Haszon (2) Mekkora biztonsági ráfordítások fogadhatók el? – Gyártó/üzemeltető – Vevő/utas

Bizonyos kockázatok speciális esetekben elfogadhatók az emberiség egészének vagy egy ország népének érdekében Hol a határ? Mekkora kockázat fogadható el? Mekkora haszonnal kell hogy ez járjon? Ki viseli a kockázatot és kié a haszon? – Befolyásolja az elfogadható kockázati szintet (pl. nagy sebesség versenypályán vagy országúton)

Válasz: VeszélyVeszély- és kockázatelemzés Saftey--Critical Computer Systems Saftey

20

Jogi vonatkozások A gyártó, illetve az üzemeltető felelős az okozott kárért A biztonság növelhető, de nem lehet abszolút – viszont számos olyan technika van, amellyel növelhetjük bizalmunkat a rendszer biztonságában

A felelősség megállapításának anyagi következményei igen nagyok lehetnek A gyártónak védenie kell magát – Megfelelő gondossággal kell eljárni a termék kialakításakor – Megfelelő figyelmeztetésekkel a felelősséget a használóra lehet hárítani (részben) – Biztosítás - igen költséges lehet

A rendszer olyan biztonságos, amennyire az ésszerűen elvárható - „state of the art” – Demonstrálni kell az alkalmazott fejlesztési, tervezési technikákat – A szabványoknak, irányelveknek való megfelelőség – Eltérés esetén igen nehéz a helyesség bizonyítása

A tervező kötelezettsége – A tervező, a vállalat többi dolgozójával együtt felelős az általa fejlesztett/tervezett termékért (szakmai, társadalmi, morális stb. felelősség) Saftey--Critical Computer Systems Saftey

21

2. Biztonsági kritériumok Bevezetés Rendszer követelmények Biztonsági követelmények Biztonságigazolás Saftey--Critical Computer Systems Saftey

22

Bevezetés Követelményrendszer – A megrendelő követelményeinek egyértelmű megfogalmazása – Funkcionális követelmények – Nem Nem--funkcionális követelmények (méret, karbantarthatóság, költségek stb.)

Biztonsági rendszernél: biztonsági követelmények rendszere – Mit követelünk a rendszertől a megfelelő biztonság érdekében – Részben funkcionális követelmények: Mit kell tenni (pl. a veszélyforrás aktivitásakor a biztonsági kapu zárva legyen) Mit nem szabad tenni (pl. nyitott biztonsági kapunál a veszélyforrást ne lehessen aktiválni)

– Egyéb fontos követelmények (általános rendszerjellemzők), pl.: Megbízhatóság (működőképesség, rendelkezésreállás, karbantarthatóság) Fail--safe működés Fail Rendszerintegritás, adatintegritás A rendszer helyreállíthatósága


23

Rendszer követelmények (1) Az egyes követelmények fontossága alkalmazásfüggő Megbízhatóság - Dependability: RAMS – a rendszernek az a tulajdonsága, amely lehetővé teszi a rendszer szolgáltatása iránti bizalmat

Működőképesség (túlélési valószínűség) - Reliability – annak a valószínűsége, hogy egy rendszer meghibásodása csak az adott időpont után következik be - a megelőző időszakra vonatkozik A rendszer a megfigyelési időpont elején működőképes volt Az adott időpontban is specifikációjának megfelelően működik Közben sem hajtottak végre rajta javítást

– Igen fontos a tervezett működési időtartam - alkalmazásfüggő Ha a javítás igen költséges vagy lehetetlen - hosszú működési idő – Kommunikációs műholdak – Űrrobotok – Pacemaker Pacemaker--ek

Speciális, „küldetéses” katonai alkalmazásoknál elegendő lehet néhány perc/óra is

– Különleges jelentőségű a működőképesség olyan alkalmazásoknál, ahol a biztonság alapvetően a működőképességen alapul, pl. Repülés--kritikus rendszerek Repülés Saftey--Critical Computer Systems Saftey

24

Rendszer követelmények (2) Rendelkezésreállás - Availability – annak a valószínűsége, hogy egy rendszer az adott időpontban működőképes - szintén időfüggő, de időpontra vonatkozik – Időszakra vonatkoztatott értéke átlagérték (MTBF, MTTR) – A magas rendelkezésreállás általános célkitűzés, nemcsak biztonsági rendszereknél, pl. az inaktív idő bevételkiesést jelent Időosztásos számítógép rendszerek Banki rendszerek Telefonközpontok

– Ilyen rendszereknél ez még fontosabb lehet, mint a nagy túlélési valószínűség, ha gyorsan javíthatóak – Biztonságkritikus rendszereknél egyértelműen nagy a jelentősége Értéke közel 100% kell legyen Ezért gyakran inkább a rendelkezésre nem állás értékét adják meg Különösen a nem folyamatos üzeműeknél, üzeműeknél, pl. atomerőmű védelmi rendszerénél nagy a jelentősége, inkább, mint a túlélési valószínűségé


25

Rendszer követelmények (3) Karbantarthatóság - Maintainability – annak a valószínűsége, hogy egy meghibásodott rendszert az adott időpontra ismét üzembe helyeznek – Megelőző karbantartás: megtartja a rendszer tervezett működési feltételeit – Javító karbantartás: visszaállítja a rendszer tervezett működési feltételeit – MTTR igen fontos biztonságkritikus rendszereknél – A karbantartás módja alkalmazásfüggő Működés közben (pl. 2x(2v2) vagy más tartalékolt rendszernél) Rövididejű leállással (kártyacsere nem tartalékolt rendszernél) Üzemszünetben (pl. repülőgép, más járművek szervizben)

– A karbantartással indukált hibák Nem minden javítás sikeres (SW is!!!) Új, az előbbitől független hiba kerül a rendszerbe (SW is!!!)


26

Rendszer követelmények (4) Fail--safe működés Fail – Biztonságos kimeneti állapottal rendelkező rendszerek hiba esetén ebbe az állapotukba kerülnek, és ezt maguktól nem (csak megfelelő javítás, újbóli indítás után) hagyhatják el – Pl. vasúti biztosítóberendezés: minden jelző vörös lesz, a váltók korábbi állapotukban rögzítve maradnak, a vonatok megállnak. – Sok rendszer nem rendelkezik ilyen biztonsági állapottal Pl. fly fly--byby-wire rendszer számítógépének nincs biztonságos kimeneti állapota - a repülőgép számára ilyen csak a földön van!

Rendszerintegritás (eredeti, a jelenleg alkalmazottól eltérő jelentés!) – A rendszer képessége arra, hogy működése közben detektálja a hibákat, és értesítse erről a kezelőt (pl. autopilot meghibásodás) – E vonatkozásban a hibadetektálás fontosabb, mint a hibatűrés – Különösen fontos a fail fail--safe rendszereknél

Az integritás tágabb értelmezései - közel a „„dependability dependability””-hez – Nagy integritású rendszerek – Biztonsági integritási szint Saftey--Critical Computer Systems Saftey

27

Rendszer követelmények (5) Adatintegritás - a rendszer képessége – Adatbázisa sérülésének megelőzésére – A fellépő hibák detektálására, lehetőleg javítására – Nem biztonsági rendszernél is fontos lehet (banki, biztosítási rendszer, ahol az adat sokba kerül, értékes)

A rendszer helyreállíthatósága – A hibatűrésre való tervezés ellenére felléphetnek rendszerhibák, leállások – Tranziens jelenségek is okozhatják, pl. közeli villámlás Áramellátási „tüske”

– Gyors, automatikus újraindítás különösen fontos, ha nincs failfail-safe állapot

– Alkalmazásfüggően szükséges lehet A rendszer aktuális állapotának meghatározása Megfelelő újraindítási eljárás végrehajtása, inicializálás A biztonság fenntartása


28

A rendszer követelmények konfliktusa Hagyományos követelménykövetelmény-konfliktusok – Nagy teljesítmény - alacsony ár – Méret - funkcionalitás

Követelmény--konfliktusok fail Követelmény fail--safe biztonsági rendszernél – Biztonság - működőképesség – Biztonság - rendelkezésreállás

A konfliktus feloldása – Kompromisszum a biztonság és a funkcionalitás között (alkalmazásfüggő) – Mind a biztonság, mind a funkcionalitás szükséges mértékét a veszély-- és kockázatelemzés alapján kell meghatározni veszély


29

Biztonsági követelmények meghatározása (1) 1. A rendszerhez kapcsolódó potenciális veszélyeztetések

meghatározása – Milyen módon tud ártani a rendszer?

2. Az előbbi veszélyeztetések osztályozása - Kockázat – A veszélyeztetésből adódó baleset következményeinek súlyossága – A veszélyeztetés fellépésének gyakorisága

3. A veszélyeztetések kezelésének (menedzselésének

meghatározása) 4. A megfelelő biztonsági követelmények hozzárendelése – megbízhatóság, rendelkezésre állás, fail fail--safe működés stb.

5. A biztonságintegritási szint meghatározása (SIL) 6. A SIL SIL--hez tartozó fejlesztési módszerek specifikálása


30

Biztonsági követelmények meghatározása (2) A veszélyeztetések meghatározása – A rendszerek kimenetük révén tudnak kárt okozni – Minden potenciálisan veszélyeztető kimenethez meg kell határozni, milyen módon árthat a rendszer – Azt, hogy egy rendszer milyen módon árthat környezetének, veszélyeztetésnek nevezzük. a veszélyeztetés súlyossága: milyen súlyos sérülés lehet a következménye a veszélyeztetés természete: fontos ahhoz, hogy kezeljük


31

Biztonsági követelmények meghatározása (2a) A veszélyeztetés természetének kérdései – A veszélyeztetés gyakran teljesen a rendszer közvetlen hatása pl. lézerfény ki/bekapcsolás

– A veszélyeztetés néha abból adódik, hogy az irányított jellemző csak késéssel követi az irányító jelet pl. energiatárolós esetek - feltöltött kondenzátor, jármű mozgási energiája stb. függőségek függőségek!!! !!!

– Lehet, hogy a veszélyforrásra az irányító rendszernek nincs közvetlen hatása pl. közúti csomópont jelzőlámpáinak a járművek és a gyalogosok viselkedésére) figyelmeztető rendszerek az emberek távoltartására, amíg a veszély el nem múlik (pl. gyalogoslámpa, gázérzékelő/gázérzékelő/-kijelző)

– Az irányítórendszer meghibásodásából adódó veszélyeztetés különösen, ha failfail-safe állapot nem lehetséges (pl. repülés) - csak a működőképesség megtartásával előzhető meg – követelmények

A veszélyeztetések kockázatának elemzése – ld. később Saftey--Critical Computer Systems Saftey

32

Biztonsági követelmények meghatározása (3) Az egyes veszélyeztetések kezelési módszereinek meghatározása – A rendszer minden egyes „akciójához” meg kell határozni a biztonságos működés feltételeit – Amelyik „akcióhoz” ez nem lehetséges, azt le kell tiltani (újratervezés) – A biztonságos működés meghatározott feltételei a biztonsági követelmények részét képezik – A biztonsági követelmények dokumentációjában az egyes potenciális veszélyforrásokhoz hozzá kell rendelni az adott veszélyforrás hatását kiküszöbölő biztonsági mechanizmust, függőséget

Meg kell határozni – A megfelelő működőképességi, rendelkezésreállási követelményeket – A megfelelő biztonsági integritási szinteket – Az integritási szintnek megfelelő fejlesztési módszereket


33

A szabványok szerepe Az egyes iparágak biztonsági alkalmazási tapasztalatainak foglalata Segíti a fejlesztőt, gyártót, hogy a termék bizonyos minőségi szintet elérjen Segít annak igazolásában, hogy a terméket hatékony módszerekkel fejlesztették Támogatja az egységes szemléletet, megközelítést - különböző fejlesztők, gyártók esetén is Irányelveket kínál a fejlesztési, tervezési technikákhoz Vitás esetekben jogalapként szolgál


34

A szabványok alkalmazásának szigorúsága Egyes iparágakban előírják – A rendszerkövetelményeket és – Az alkalmazandó fejlesztési módszereket, valamint megadják – Az elfogadás kritériumait (tanúsítás)

Más területeken az alkalmazás rugalmasabb – Az engedélyező hatóság tárgyalja meg a fejlesztővel az alkalmazandó fejlesztési, tervezési módszereket – Engedélyezés vagy egy speciális szabványnak való megfelelőség vagy a cég által javasolt alternatív módszer alapján

– Maguk a szabványok is tartalmazhatnak alternatív módszereket – A hatóság esetleg preferál ezek közül egyeseket – Különleges esetben engedélyezhető a szabványtól való eltérés (pl. eltérő rendszerkövetelmények).


35

Alkalmazási irányelvek

Kevésbé formálisak, mint a szabványok A szabványok gyakorlati alkalmazásaihoz adnak útmutatást – Vezérfonal ahhoz, hogy hogyan állítható elő egy rendszer egy adott szabvány előírásainak megfelelően

Az adott iparágbeli projekteken túlmutató, általánosabb információt is adhat Egyes szabványok a követelmények, előírások mellet alkalmazási irányelveket is tartalmaznak


36

Ágazat-specifikus szabványok, alkalmazási irányelvek Példa ágazatokra – Polgári és katonai repülés – Atomenergia ipar – Bányászat

Azonosítják és tárgyalják az ágazatra jellemző főbb veszélyforrásokat A kockázati szintekhez működőképességi és rendelkezésreállási követelményeket rendelnek - érvényesek – Mind a hatóság, – Mind az ipar számára.

Az ágazaton belüli projektek számára megalapozzák a biztonsági követelmények megfogalmazását


37

Biztonságigazolás (Safety Case)

Kritikus rendszerek üzembehelyezését hatóságilag kell engedélyezni Az engedélyezési eljárás számára, a rendszer biztonsági megítéléséhez a gyártó vagy az üzemeltető biztonságigazolást kell készítsen – Az alkalmazott (kockázat)becslési és fejlesztési technikák bemutatása – Minden a biztonságot befolyásoló szempontot és azok kezelését be kell mutatni, beleértve – a biztonságos üzemvitelre vonatkozó előírásokat is


38

Biztonságigazolás (Safety Case) - folytatás

A biztonságigazolás érvelési rendszere – inkább mérnöki megítélésen, mintsem szigorú formális logikán alapul, – általában valószínűségi alapú kockázatbecsléssel támogatva

A biztonságigazolás azt dokumentálja, hogy – A rendszerrel kapcsolatos kockázatokat gondosan figyelembe vették, és – Megfelelő intézkedéseket tettek e kockázatok kezelésére – Nem pedig azt, hogy a rendszer biztonságos (abszolút biztonságos rendszer nincs!!!)


39

3. Veszélyelemzés

Bevezetés Elemzési módszerek Hibamód és -hatás elemzés Veszély-- és működőképesség elemzés Veszély Hibafa elemzés Veszélyelemzés a fejlesztési életciklusban


40

Bevezetés (1) Egy rendszer biztonságnövelésének valószínűleg legfontosabb mechanizmusa azon módozatok meghatározása, amelyek révén a rendszer károkat okozhat A talált módozatokat értékelni kell, és – ha szignifikánsnak találták őket, akkor – intézkedéseket kell tenni megszüntetésükre vagy hatásuk mérséklésére

A károkat okozható helyzeteket veszélyeztetésnek nevezzük: A veszélyeztetés olyan helyzet, amelyben személyek vagy a környezet ténylegesen vagy potenciálisan veszélyben van


41

Bevezetés (2)

Példák a mindennapi életből: – Egy gyalogost az utcán elüthet egy autó – Egy embert a mezőn a viharban villám sújthat

Ha az előbbiek közül valamelyik esemény bekövetkezik, balesetről beszélünk - A veszélyeztetés a baleset lehetősége Minden veszélyeztetéshez hozzárendelnek egy bizonyos kockázatot,, amely függ kockázatot – Az esemény bekövetkezésének valószínűségétől és – A valószínű következményektől


42

Elemzési módszerek Egyes módszerek ágazatágazat-specifikusak, mások teljesen általánosan használatosak. A leggyakoribb veszélyelemző módszerek: Hibamód és -hatás elemzés - failure modes and effects analysis (FMEA) Hibamód, -hatás és kritikusság elemzés - failure modes, effects and criticality analysis (FMECA) Veszély-- és működőképesség elemzés - Hazard Veszély and operability studies (HAZOP) Eseményfa elemzés - event tree analysis (ETA) Hibafa elemzés - fault tree analysis (FTA)


43

Hibamód és -hatás elemzés (FMEA) Az elemzés végrehajtható – Hardver elemekre vagy – Funkciókra vonatkoztatva

Feltevésekkel él az elemek/funkciók lehetséges hibamódjairól, majd meghatározza ezek hatását – az adott egységre és – a teljes rendszerre

Ennek során figyelembe veszi a rendszer valamennyi elemének/funkciójának valamennyi lehetséges hibamódját Esetenként javaslatot tesz a talált problémák orvoslására.


44

Hibamód és -hatás elemzés (FMEA)


45

FMEA - biztonságigazoláshoz jelfogók: – – –

érintkező nemzárása, jelfogó el nem ejtése, jelfogó meg nem húzása,

UOM 1

+96V = TMS

diódák: – –

TMS

MI

rövidzár, szakadás,

Szi

ellenállások, potencióméterek: – – –

szakadás, ellenállásnövekedés, rövidzár (csak fémrétegnél),

TMS

–

TMS

Szi

A6

szakadás,

vezetőpálya a NYÁK-lapon (kártya vagy backpanel): –

szakadás.

MI

T21

TZ

Szi

TMS

MI

T3 MI

MI

Áramkomparátor

Rb=50Ω Ih=100mA

MV

Szi

KiK

MI

MI

TMI 1 2 3

MI

T11 T21

érszakadás, szakadás,

T11

TCs

T12

T22

szekrény belső huzalozás: –

9

MV MI

belsőtéri rendszerkábelek: –

MI

Vt 96V =

rövidzár, szakadás, kapacitáscsökkenés,

kismegszakítók:

6

6a

kondenzátorok: – – –

5

ÜT

TCs

T3

KiK

KiK MI *

*

MI

4

FMEA bizt. ig. Jelfogó neve

Kártya

Térközjelzők Megállj! segédjelfogó (TMS)

ÜT1-S

Érintkező

emzárás következménye

II.5/6

a térközjelzők Megállj!-ra kapcsolt állapotában antivalenciahiba a SIMIS-IS bemenetén, zavarjelzés a kezelőfelületen

I.5/6

a Térközjelzők Megállj! kezelés hatástalan

II.3/4

a vonali hurok áramkör nem épül fel, a Térközjelzők Megállj! kezelés hatástalan

I.3/4

a vonali hurok áramkör nem épül fel, a Térközjelzők Megállj! kezelés hatástalan

II.1/2

a vonali hurok áramkör nem épül fel, hamisfoglaltság-visszajelentések a térközből, vonat nem indítható, menetirány nem fordítható

I.1/2

a vonali hurok áramkör nem épül fel, hamisfoglaltság-visszajelentések a térközből, vonat nem indítható, menetirány nem fordítható

El nem ejtés következménye

kijárat esetén a térközjelzők szándékolatlanul Megállj! állásban maradnak

Meg nem húzás következménye

a Térközjelzők Megállj! kezelés hatástalan

Az FMEA alkalmazása A fejlesztési folyamat legkülönbözőbb fázisaiban alkalmazható Az életciklus korai fázisában, funkciókra alkalmazva, a SIL meghatározásában játszhat szerepet A rendszer kialakításának jóval későbbi fázisaiban már hardver elemekre is alkalmazható biztonságigazolás Kiválóan alkalmas az egyes szinteken az elemzés finomítására – Motorhiba hatása a repülőgépre – Üzemanyag Üzemanyag--szivattyú hibájának hatása a motorra – szelephiba hatása az üzemanyag üzemanyag--szivattyúra

Az analízis kiegészíthető valószínűségi információval is Gyakran „szállít” bemenő adatokat az FTA számára


49

Az FMEA értékelése Mivel a módszer minden lehetséges hibát figyelembe vesz, különösen alkalmas az egyszeres hibák detektálási feltételeinek meghatározására Ugyanakkor nem veszi figyelembe a többszörös hibákat Mivel minden hibát figyelembe vesz, igen sok ráfordítást igényelnek azok a hibák, amelyek nem okoznak veszélyeztetést Nagy, komplex rendszerek esetén rendkívül ráfordításráfordítás-igényes Ezért sok esetben csak a fejlesztési folyamat végső fázisaiban, és csak a kritikus területek vizsgálatára alkalmazzák


50

Hibamód, -hatás és kritikusság elemzés (FMECA)

A FMEA kiterjesztése Figyelembe veszi az elemek meghibásodásainak fontosságát is: – az egyes hibák következményeit és – fellépésének gyakoriságát vagy valószínűségét

Ezzel meghatározza a rendszer azon részeit, amelyekben a hibák a leginkább kritikusak Ezáltal lehetővé teszi, hogy az erőfeszítéseket arra a területre irányítsák, ahol azokra a legnagyobb szükség van


51

Veszély- és működőképesség elemzés (HAZOP) Eredetileg vegyipari, ma már széleskörű alkalmazás „Guide words words”” - „Mi történik, ha _” típusú kérdésekre adott válaszokkal igyekszik meghatározni a normál működési feltételektől való eltérések hatásait, pl.: – Mi történik, ha megnő a hőmérséklet? – Mi történik, ha csökken a nyomás?

Különösen alkalmas a paraméterváltozások és az előírt tartományokból való kilépések (out (out--of of--range range)) biztonságra gyakorolt hatásának vizsgálatára Elemző team - jártasság – A fejlesztési módszerekben – Az adott alkalmazási területen – A HAZOP és más veszélyelemzési technikák területén

Rendkívül munkamunka- és időigényes Saftey--Critical Computer Systems Saftey

52

Vezérszavak (guide words)

HAZOP példa

Eseményfa elemzés (ETA) A kiindulópont egy olyan esemény, amely hatással lehet a rendszerre (de önmagában nem feltétlenül veszélyeztető) A kiinduló esemény hatását rendre kombináljuk minden további, számbajövő esemény hatásával A hatást – mind normál, – mind hibás működésre vizsgálják

Fa Fa--struktúra szerű szétágazás - „n” esemény: 2n ág Igazi haszna komplexebb esetekben van, amikor az eredmény nem annyira nyilvánvaló


55

ETA példa

Hibafa elemzés (FTA) Az elemzés fordított irányban halad, mint az ETAETA-nál: – Egy már - esetleg FMEA vagy HAZOP révén - azonosított, veszélyeztető hatású, ún. csúcseseményből kiindulva – visszafelé haladva határozzuk meg a csúcseseményt kiváltó ún. elemi eseményeket

A hatások kombinálásánál logikai (Boole) operátorokat használunk A hibafában csak azok az események szerepelnek, amelyek veszélyeztető hatásúak, így az FTAFTA-struktúra jóval egyszerűbb lehet, mint az ETAETA-struktúra


57

Valószínűségi veszélyelemzés A veszélyek azonosításra használatos, eddig tárgyalt módszerek többsége alkalmas a veszély valószínűségének vagy fellépési gyakoriságának meghatározására is FMECA esetében az egyes hibamódokhoz rendelt kritikussági szám lehetővé teszi, hogy az elemzést a legfontosabb területekre koncentrálják ETA vagy FTA esetében az egyes ágakhoz rendelik hozzá a megfelelő valószínűségeket és végeredményként kapjuk az eseménykombinációk, illetve a csúcsesemény valószínűségét Az eredmények érvényessége - helyes fastruktúra esetén - a kiinduló valószínűségi adatok helyességétől függ. Ezen adatok lehetnek – Statisztikai vagy – Becsült adatok


58

Veszélyelemzés az életciklusban Az elemzés révén feltárt veszélyforrások – nemcsak a rendszerkialakítást, – hanem a fejlesztési módszerek megválasztását is befolyásolják

Ha az előzetes elemzés szerint a fejlesztendő rendszer biztonsági felelősségű, akkor a veszélyelemzést folytatni kell a teljes fejlesztési folyamatban Előzetes veszélyazonosítás, elemzés (Preliminary hazard identification – PHI, Preliminary hazard analysis – PHA) Biztonsági felülvizsgálatok (Safety reviews) Safety plan System hazard analysis System risk assessment Independent safety audit


59

Preliminary hazard identification - PHI Az aktuális veszélyeztetések befolyásolják a rendszer kialakítását, fejlesztését és használatát Ezért az életciklus lehető legkorábbi fázisában (koncepció kialakítása) azonosítani kell a veszélyforrásokat, hogy a megfelelő intézkedéseket meg lehessen tenni Ennek alapján a rendszer jellemzőit úgy alakítják ki, illetve át, hogy a veszélyeztetést – megszüntessék vagy – csökkentsék, vagy – a hatását (súlyosságát) csökkentsék

Ezt a veszélyazonosítást minden beágyazott rendszerre el kell végezni A vizsgálatot szisztematikus módszerrel kell végezni, pl. HAZOP – Mind a működési körülményekre, – Mind a hibákra vonatkozóan

Korábban létesített hasonló rendszerek baleseti adatai lényeges segítséget jelenthetnek Saftey--Critical Computer Systems Saftey

60

Preliminary hazard list A PHI eredményeit az előzetes veszélyeztetési listában rögzítik Amennyiben lényeges veszélyeztetést találtak, ez a lista lesz a későbbi veszélyelemzés alapja Amennyiben nem találtak lényeges veszélyeztetést, további elemzés nem szükséges, a rendszer nem biztonságkritikus – Ilyenkor a lista annak bizonyítéka, hogy a veszélyeztetések azonosítását elvégezték

Biztonságkritikus rendszereknél az azonosított veszélyeztetéseket bejegyzik a biztonsági naplóba (hazard log). A naplóban folyamatosan rögzítik a rendszerrel kapcsolatos biztonsági kérdéseket/felmerült problémákat és kezelésüket. Saftey--Critical Computer Systems Saftey

61

Preliminary hazard analysis - PHA A biztonsági követelményeket meghatározó fázis megalapozója Segíti a viszonylag korai döntést – A rendszer rendszer--architektúrát és – Az alkalmazandó technikákat illetően

Támogatja a későbbi veszélyveszély- és biztonsági elemzési tevékenységeket. Pl. amennyire korán csak lehet, – a veszélyeztetések súlyosság szerinti osztályozása, és – a fő funkciókhoz integritási szint hozzárendelése

A PHI során azonosított veszélyeztetések részletes elemzése valamilyen szisztematikus eljárással (HAZOP stb.) Minden egyes veszélyeztetést a rendszer funkcionális követelményeivel összevetve vesznek figyelembe – A biztonsági következmények meghatározása és – Az egyes kialakítási alternatívák megítélése céljából Saftey--Critical Computer Systems Saftey

62

Preliminary hazard analysis report

Lényeges háttér információk a rendszerről és a vele kapcsolatos veszélyeztetésekről – A rendszer és környezetének rövid leírása – A rendszer funkcióinak és biztonsági jellemzőinek áttekintése – A rendszer biztonsági célkitűzései – A kockázat és az integritási szint megítélése – A meghibásodási ráta és a biztonsági szint megcélzott értéke – Az elemzésben felhasznált adatok forrása – A felhasznált dokumentációk bibliográfiája


63

Safety reviews A fejlesztési folyamat során a projektet számos alaklommal vetik biztonsági felülvizsgálat alá A felülvizsgálatok valamennyi biztonsági szempontra kiterjednek A vizsgálatok számára a különböző jelentések és elemzések szolgáltatnak adatot A vizsgálatok eredményeit a biztonsági naplóban rögzítik (referencia a továbbiakhoz) Az első általában a PHA fázist követi Amennyiben a rendszer a PHA és az ezt követő biztonsági felülvizsgálatok alapján – viszonylag kevéssé kritikusnak tűnik, – további részletesebb veszélyelemzés nem szükséges, illetve – gazdaságilag nem indokolható

Ilyen esetben a fejlesztést az integritási szintnek megfelelő módszerekkel folytatják Saftey--Critical Computer Systems Saftey

64

Safety plan A közepesen és a nagyobb mértékben kritikus rendszerek számára – részletes biztonsági tervet készítenek – és a projekt folyamán aktualizálják

Milyen módon érik el a kívánt biztonságot? A követendő szabványok, irányelvek felsorolása Hogyan teljesítik ezek előírásait? A további veszélyveszély- és kockázatelemzésért felelős menedzsment--struktúra (nevesítve) menedzsment


65

System hazard analysis - SHA A nagyobb mértékben kritikus rendszerek számára szükséges további biztonsági elemzés Cél: a PHA eredményeinek kiterjesztése, finomítása – a rendszer és komponensei részletes funkcióinak figyelembevételével.

Kiindulás: – a rendszerkövetelmények és – a PHA eredményei

A projekt előrehaladásával az elemzés mindinkább a követelményeket megvalósító alrendszerekre és komponensekre irányul A veszélyeztetések feltárása többféle analízisanalízis-technikát is igényelhet. A már bemutatottakon kívül ilyen pl. – A Markov Markov--modellezés és – A megbízhatósági blokkdiagramok módszere


66

System risk assessment Az SHA eredményeit hasznosító kockázatelemzés Vizsgálja a különböző veszélyeztetések – hatásait és – Megjelenési gyakoriságát vagy valószínűségét

Kijelöli az egyes rendszerkomponensekhez tartozó integritási szinteket

Az SHA és a hozzá csatlakozó kockázatelemzés részleteit az SHA jelentésben, valamint a biztonsági naplóban rögzítik


67

Independent safety audit (1) A leginkább kritikus rendszerek projektjében egy független tanúsító csoport hajtja végre a biztonsági felülvizsgálatot A tanúsításhoz az adatokat a biztonsági naplóból és a különböző veszélyelemzési jelentésekből veszik Igazolják a fejlesztőmunka alaposságát és az eredmények korrektségét

A felülvizsgálat eredményeit független biztonsági felülvizsgálati jelentésben rögzítik, amely az engedélyezés elnyeréséhez készített biztonságigazolásnak fontos része.


68

Independent safety audit (2) A fejlesztő és a tanúsító függetlenségét kevésbé kritikus projekteknél is biztosítani kell 1. független személy 2. független osztály 3. független szervezet

A nagyobb függetlenség növeli a rendszer korrektsége iránti bizalmat A függetlenség növelésének gazdasági akadályai lehetnek Független tanúsító csapat működése – nagy jelentőségű a projektdokumentáció teljessége szempontjából, – ugyanakkor fegyelmezett munkát követel a fejlesztőktől

A különböző dokumentációkban szereplő elemzések és eredmények egészen a forrásokig visszakövethetők kell legyenek a független verifikálás érdekében Saftey--Critical Computer Systems Saftey

69

4. Kockázatelemzés Bevezetés A hibás működés következményei súlyosság A hibás működés valószínűsége gyakoriság Kockázatosztályozás Az elfogadható kockázat Integritási szintek Társadalmi, etikai szempontok Saftey--Critical Computer Systems Saftey

70

Biztonsági kockázat Valamely veszélyeztető hatás jelentőségét egy alkalmazásban az ún. biztonsági kockázat fejezi ki. Biztonsági kockázat: • a veszélyeztetésből adódó baleset bekövetkezési valószínűségének vagy gyakoriságának és • a keletkező sérülések súlyosságának kombinációja. Gyakoriság

Kockázat Súlyosság

A kockázat meghatározható • mennyiségileg • minőségileg (kockázatosztályozás) Saftey--Critical Computer Systems Saftey

71

Példa a kockázat számszerű kifejezésére (1)

Valamely speciális alkatrész meghibásodása robbanást okozhat egy rendszerben, aminek következtében 100 ember halhat meg. Az alkatrész átlagosan 10 000 évenként egyszer hibásodik meg. Mekkora az alkatrészhibához kapcsolódó kockázat? Kockázat = súlyosság x gyakoriság = 100 ember halála/hiba x 0,0001 hiba/év Kockázat = 0,01 ember halála/év


72

Példa a kockázat számszerű kifejezésére (2)

Globális kockázat és individuális kockázat Egy 50 milliós lakosságú országban évente átlagosan 25 embert ér halálos villámcsapás. Mekkora a villámcsapásból adódó halálozás kockázata? Évente a lakosság 25/50 000 000=5x10-7 részét éri villámcsapás. Az egyes emberek számára ennyi annak a valószínűsége, hogy az adott évben villámcsapás éri őket. A lakosság egészére vonatkozó kockázat: 5x10-7 halál/ember-év


73

A kockázat minőségi meghatározása Alap paraméterek – súlyosság – gyakoriság

Kiegészítő paraméterek – veszélyzónában való tartózkodás – baleset elkerülésének lehetősége

Kárkihatási kategóriák (súlyosság) a polgári repülésben (példa) Figyelembe veszi • a repülőgépre gyakorolt hatást • a személyzetre gyakorolt hatást • az utasok biztonságára várhatóan gyakorolt hatást Kategória

Definíció

Katasztrofális (Catastrophic)

megakadályozza a biztonságos továbbrepülést, és a leszállást

Veszélyes (Hazardous)

_

Lényeges (Major)

_

Nem lényeges (Minor)

nem csökkenti érdemben a repülés biztonságát, kisebb funkcionális visszaesés, szükséges lehet a személyzet beavatkozása, de túlterhelést még nem jelent számukra

Hatástalan (No effect)

_ Saftey--Critical Computer Systems Saftey

75

Katonai számítógépes bizt. krit. rendszerek kárkihatási kategóriái Interim Defence Standard 00-56 (UK, 1995) Kategória

Definíció

Katasztrofális

Több haláleset

Kritikus

Egy haláleset és/vagy súlyos sérülés vagy betegség

Marginális

Egy súlyos sérülés vagy betegség és/vagy több könnyebb sérülés vagy betegség

Elhanyagolható

Legfeljebb kisebb sérülés vagy betegség

Kockázatosztályozás - Kárkihatási kategóriák (példa) (IEC 61508)

Kategória

Leírás

Következmények

4

Katasztrofális

Több haláleset és súlyos sérült

3

Kritikus

Egy haláleset és/vagy több súlyos sérült

2

Csekély

Egy súlyos sérült; több kisebb sérülés

1

Elhanyagolható

Legfeljebb egy kisebb sérülés


77

Gyakoriság/valószínűség Megadása – a veszélyeztetés valószínűsége, gyakorisága (nem konzekvensek a szabványok!) – esemény / üzemóra, üzemév – élettartam alatt várható események száma – védelmi (on-demand) rendszerek: elvárt működéshez viszonyítva

Gyakoriságok – polgári repülés „Probability per operating hour” ~gyakoriság 100 Gyakori Valószínű

10-1 10-2

Ésszerűen valószínű

10-3 10-4 10-5

„Távoli”

10-6

Valószínűtlen Nagyon távoli

10-7 10-8 10-9

Rendkívül valószínűtlen

Rendkívül valószínűtlen

Gyakoriságok – katonai rendszerek (UK) Gyakoriság Gyakori

Előfordulás az összes ilyen rendszer üzemideje alatt Folyamatosan tapasztalható

Valószínű

Gyakran megtörténik

Esetenként

Néhányszor megtörténik

Távoli

Párszor megtörténik

Valószínűtlen

Nem valószínű, de kivételesen előfordulhat

Hihetetlen

Kifejezetten valószínűtlen, hogy egyáltalán megtörténik

Kockázatosztályozás - Veszélybekövetkezési gyakoriság (példa)

CENELEC 50126 (vasúti szabvány) Szint

Leírás

Fogalom

Fellépési gyakoriság [h-1]

A

gyakori

Feltételezhetően gyakran fellép; a veszélyeztetés állandóan jelen van

> 10-3

B

valószínű

Többször fellép; várható, hogy a veszélyeztetés gyakran fellép

10-3 _ 10-4

C

néha

Várható, hogy a veszélyeztetés többször bekövetkezik

10-4 _ 10-5

D

alig

Várható hogy a veszélyeztetés a rendszer életében bekövetkezik

10-5 _ 10-7

E

valószínűtlen

Valószínűtlen; azzal lehet számolni, hogy a veszély csak kivételesen lép fel

10-7 _ 10-9

F

rendkívül valószínűtlen

Rendkívül valószínűtlen bekövetkezés; azzal lehet számolni, hogy a veszély nem lép fel


<10-9

81

Kockázat osztályozás A gyakoriság és a súlyosság kombinációja Mátrixos formában Gyakran már a kockázat elfogadási kritériumokat is tartalmazza

Kockázatosztályozás Katonai rendszerek (UK) Következmény Gyakoriság

Katasztrofális

Kritikus

Marginális

Elhanyagolható

Gyakori

A

A

A

B

Valószínű

A

A

B

C

Esetenként

A

B

C

C

Távoli

B

C

C

D

Valószínűtlen

C

C

D

D

Hihetetlen

D

D

D

D

Kockázati osztályok (példa)

Kárkihatási kategóriák

Valószínűségi szint

Katasztrofális 4

gyakori

A

valószínű

B

néha

C

alig

D

valószínűtlen

E


F

Kritikus 3

Csekély 2

Elhanyagolható 1

K4 K3

K2

K1


84

Kockázati gráf - Követelményosztályok (DIN 19250) S - kárkihatás súlyossága A - a veszélyövezetben tartózkodás időtartama/gyakorisága G - menekülési lehetőség W - a veszélyeztetés valószínűsége W3 W2 W1 S1

1

–

–

G1

2

1

–

S2 A1

G2

3

2

1

A2

G1

4

3

2

G2

5

4

3

6

5

4

7

6

5

8

7

6

S3 A1 A2

S4 Saftey--Critical Computer Systems Saftey

85

KOCKÁZATCSÖKKENTÉS KOCKÁZATTŰRÉS


86

Kockázatmentesség, kockázatcsökkentés

Társadalmi igény: • kockázatmentesség (veszélyforrás-specifikus) - a potenciális veszélyeztető hatás megszüntetése - a veszélyforrás helyének/hatókörének elkerülése • kockázatcsökkentés • elfogadott kockázati szint (kockázattűrés) - érdekegyeztetés (a kockázat okozója, elszenvedője,hatóság) - költségek – elérhető eredmény


87

Kockázattűrési megközelítések MEM – Minumum endogeneous mortality – minimális „halandóság” – 5-15 év között az értéke 2×10-4 haláleset/fő/év – Feltételezése szerint egyidejűleg max. 20 műszaki rendszer veszélyeztethet egy egyént – egy rendszerre 10-5 haláleset/fő/év jut – azaz 10-9 haláleset/fő/óra

Kockázattűrési megközelítések GAME / GAMAB – Globalement Au Moins Equivalent – Egy új rendszer nem lehet rosszabb, mint a régiek – Mi van új rendszer esetén?

Kockázatcsökkentés – Az ALARP elv As Low As Reasonably Practicable Olyan alacsony, amennyire ésszerűen megvalósítható Az egységnyi ráfordítással elérhető kockázatcsökkentés

K3

K2 K1

ALARP terület

K4

Elfogadhatatlan kockázat Akkor fogadható el, ha a csökkentés kivitelezhetetlen, vagy költségei aránytalanok

Feltételesen elfogadható kockázat

Elhanyagolható kockázat Saftey--Critical Computer Systems Saftey

90

Kockázatosztályozás Katonai rendszerek (UK) Következmény Gyakoriság

Katasztrofális

Kritikus

Marginális

Elhanyagolható

Gyakori

A

A

A

B

Valószínű

A

A

B

C

Esetenként

A

B

C

C

Távoli

B

C

C

D

Valószínűtlen

C

C

D

D

Hihetetlen

D

D

D

D

Kockázat elfogadás Katonai rendszerek (UK) Kockázati osztály

Értelmezés

A

Nem tolerálható

B

Nem kívánatos, csak akkor fogadható el, ha a kockázatcsökkentés nem lehetséges

C

A projekt biztonsági áttekintő bizottsága ajánlásával elfogadható

D

Normál projekt áttekintés alapján elfogadható

Kockázati osztályok (példa)

Kárkihatási kategóriák

Valószínűségi szint

Katasztrofális 4

gyakori

A

valószínű

B

néha

C

alig

D

valószínűtlen

E


F

Kritikus 3

Csekély 2

Elhanyagolható 1

K4 K3

K2

K1


93

Kockázat elfogadás K4 - elfogadhatatlan kockázat; K3 - nem kívánatos kockázat – csak akkor fogadható el, ha a kockázatcsökkentés kivihetetlen, vagy – költségei az eredményhez képest rendkívül aránytalanok

K2 – elfogadható kockázat, – ha a kockázatcsökkentés költségei meghaladnák az eredményt – nem fogadható el, ha kis ráfordítással jó eredmény érhető el

K1 – elhanyagolható kockázat

A kockázattűrés függése a felelősségtől Kockázattűrés

haláleset fő ∗ óra

Kizárólag saját felelősség Pl. teljesítménysportok

10-4

Túlnyomóan saját felelősség Pl. egyéni közlekedés

10-5 10-6

Túlnyomóan idegen felelősség Pl. tömegközlekedés

Alapkockázat

Kizárólag idegen felelősség Pl. erőművek közelében

10-7 10-8 idegen

idegen/saját

saját /idegen


saját

felelősség 95

Társadalmi, etikai szempontok (1) Az integritási szint, a biztonság növeléséért teendő erőfeszítések meghatározása nemcsak mérnöki feladat társadalmi vonatkozásai is vannak - közvetve az emberi élet, a sérülések pénzben vagy másként kifejezett értékéről is szó van Az áldozat „értékének” megítélése különböző (csecsemő, kenyérkereső, idős ember - pl. becsült keresetkiesés) Az élet megőrzésének költségei eltérő körülmények között igen különbözőek lehetnek – Minimum: amennyit költenénk rá – Maximum: amennyit már nem költenénk rá

Különböző példákból az arány akár 1:1000 is lehet


96

Társadalmi, etikai szempontok (2) A kockázat társadalmi megítélése nagymértékben függ a kockázat jellegétől – A tömegbalesetet súlyosabbnak ítélik meg, mintha ugyanannyi ember hal meg egyenként (vasút, repülő - közút)

Erősen befolyásolja a megítélést, hogy mennyire van befolyásunk az eseményekre – Atomerőművi katasztrófa - nem tudjuk megvédeni magunkat – Autó elgázol - sajnos nem mindig befolyásolható, csak gondoljuk

Érzelmi tényező – Egy űrhajó meghibásodása kevesebb életet kockáztat, mint egy utasszállító gépé, elvesztését mégis nemzeti katasztrófaként élik meg

Irányelvek, amelyek a kockázat megítélésének nemcsak a műszaki, hanem a társadalmi vonatkozásait is figyelembe veszik Saftey--Critical Computer Systems Saftey

97

Társadalmi, etikai szempontok (3) Abszolút biztonság nincs – Ilyen követelménnyel nem lehetne semmilyen műszaki berendezést létesíteni, üzemeltetni

Célunk megfelelő biztonságú rendszerek létesítése, üzemeltetése A szabványok minimális integritási szinteket írnak elő - a hatóságok ezt követelik meg A mérnök számára ez alapozza meg a döntést a fejlesztendő rendszer biztonsági megfelelősségével kapcsolatban Emellett azonban a mérnök szakmai és morális felelősséget visel azért, hogy a rendszer olyan biztonságos legyen, amennyire csak lehet Saftey--Critical Computer Systems Saftey

98

Biztonsági funkciók Teljes funkcionalitás Biztonsági funkciók

Irányító funkciók

Gyakoriság Kockázat osztályozás

Veszélyelemzés

Kockázatcsökkentés

Súlyosság

IRÁNYÍTANDÓ FOLYAMAT Saftey--Critical Computer Systems Saftey

IRÁNYÍTÓ RENDSZER 99

Kockázatcsökkentés – Kockázatmenedzselés

A veszélyeztetésből adódó kockázat

Az elfogadható kockázat

A maradék kockázat

Szükséges kockázatcsökkentés

Tényleges kockázatcsökkentés

Km

Ke


Kv

kockázat

100

Biztonsági integritás A biztonsági integritás (safety integrity – a biztonság sértetlensége) annak valószínűsége, hogy egy biztonsági rendszer • az előírt biztonsági funkciókat • egy adott időszakban • meghatározott körülmények között megfelelően végrehajtja: nem lépett fel veszélyeztető meghibásodás.

B PB(t)

Biztonsági integritási szintek (Safety Integrity Levels) Integritási szintek

PB(t) = 1 - PV(t) V P (t) V

PB(t) ≥ PBmin ↔ PV(t) ≤ PVmax

Megnevezés

4

Igen magas

3

Magas

2

Közepes

1

Alacsony

0

Nem biztonsági


PÉLDA!

101

A biztonsági integritási szintek száma és értelmezése A biztonsági integritási szintek száma a különböző alkalmazási területeken: 1_8

Biztonságintegritási szintek SIL

Az irányító rendszer veszélyes meghibásodásának valószínűsége [h-1]

A védelmi rendszer elmaradt működéseinek aránya az összes kívánt működéshez képest

4

10-9 _ 10-8

10-5 _ 10-4

3

10-8 _ 10-7

10-4 _ 10-3

2

10-7 _ 10-6

10-3 _ 10-2

1

10-6 _ 10-5

10-2 _ 10-1

0

---

---

PÉLDA!


102

Biztonsági funkciók – Biztonsági integritás Teljes funkcionalitás Biztonsági funkciók Gyakoriság

Normál működés Kockázat osztályozás

Veszélyelemzés

Irányító funkciók

Súlyosság

Kockázatcsökkentés

Hibák elleni védettség Biztonsági integritás

IRÁNYÍTANDÓ FOLYAMAT Saftey--Critical Computer Systems Saftey

Saját (belső) biztonság

IRÁNYÍTÓ RENDSZER 103

HIBÁK ELKERÜLÉSE/KEZELÉSE (DIN VDE 0801) A HIBA FAJTÁJA

A KÖVETELMÉNYOSZTÁLYOKNAK MEGFELELŐ KÜLÖNLEGES BIZTONSÁGI INTÉZKEDÉSEK 1

2

3

4

5

6

7

8

Egyszeres Véletlen

hiba

HW hiba

Többszörös

E

K

hiba

Szisztema-

HW

tikus hiba,

hiba

közös

SW

módusú is

hiba

Kezelési, karbantartási hibák, manipulációk

Hibák, zavarok az üzem és a környezet befolyása révén

M

E

ALAPINTÉZKEDÉSEK

ALAPINTÉZK.

K

E

E

ALAPINT.

M

HIBAKEZELÉS

K

M

ELKERÜLÉS

K

M

HIBAKEZELÉS

M

ELKERÜLÉS

K E

ALAPINT.

HIBAKEZELÉS

K

M

HIBAKEZELÉS

E

K

M

ELKERÜLÉS

E

K

M

HIBAKEZELÉS

E

K

M

ELKERÜLÉS

E

K

Saftey-CriticalKComputer ESaftey - egyszerű - közepesSystems M - magas

M

HIBAKEZELÉS

104

A biztonsági irányítórendszerek szabványai, irányelvei Általános Nemzetközi

IEC 1508

Európai, nemzeti

IEC – International Electrotechnical Commission

Ágazati

CENELEC

Defence Standards (védelmi szabványok) Polgári repülés

EN – Européen Norme Atomenergetikai rendszerek CENELEC – Comité Européen des Normalisation ELECtrotechniques

Vasúti alkalmazások

MSZ EN

ISO Saftey--Critical Computer Systems Saftey

105

5.Biztonságkritikus rendszerek fejlesztése Bevezetés Életciklus modellek A biztonsági életciklus Fejlesztési modellek Biztonságra tervezés Karbantarthatóság A biztonság emberi tényezői Biztonsági elemzés Biztonság--menedzsment Biztonság Saftey--Critical Computer Systems Saftey

106

Bevezetés A rendszerhez kapcsolódó veszélyek azonosítása, értékelése > rendszerkövetelmények A követelményeknek megfelelő rendszer kialakítása

1. 2.

Különböző fejlesztési technikák a rendszer biztonságának elérésére Inherens módon biztonságos rendszer

1. – –

Sem normál, sem hiba hiba--üzemmódban nem képes ártani Gyakran nem megvalósítható (a folyamattól és nem az irányító rendszertől függ)

A veszélyeztetés fellépésének megelőzése, minimálása

2. –

Folyamatirányító rendszerek, függőségek, „sorompók” alkalmazása

Törekvés a fellépő veszélyeztetés kezelésére

3. –

Fail Fail--safe technikák, a fellépő veszélyeztetések „uralása”

A fellépő veszélyeztetések hatásának mérséklése

4. – –

Figyelmeztető készülékek, a személyzet felkészítése a veszélyhelyzetben követendő eljárásra Saftey--Critical Computer Systems Saftey

107

Életciklus modellek A fejlesztési projekt – fázisainak és – az egyes fázisok kapcsolatrendszerének – ábrázolása

Különböző célok - különböző modellek – előnyök – hátrányok


108

Bővített „V”-modell (ábra) Többlet--információ Többlet – Az egyes fázisok „terméke” (dokumentáció stb.) – A fázisok közötti információáramlás

Még ez is erősen egyszerűsített – Nem mutatja az iterációkat (bonyolult lenne) Fázisokon belül Fázisok között

– Nem időzített modell – Nem mutatja Az egyes fázisokban párhuzamosan és a több fázison keresztül folytatandó tevékenységeket


109

IEC 61508 biztonsági életciklus modell (1) A teljes (nemcsak a fejlesztési) életciklus valamennyi tevékenysége – kezdve a koncepciós fázistól – mindaddig, amíg a rendszer használatra alkalmatlanná nem válik

Minden fázishoz tartozik biztonsági célú tevékenység, pl. – Veszély Veszély-- és kockázatelemzés

A fejlesztést követő fázisok is befolyásolják a biztonságot Megvalósítási módok – – – –

Villamos/elektronikus/programozható technológiák Egyéb (mechanikai, hidraulikai stb.) technológiák Külső (rendszeren kívüli) kockázatcsökkentési lehetőségek A biztonság érdekében mindig a legegyszerűbbet kell választani! Saftey--Critical Computer Systems Saftey

110

IEC 61508 biztonsági életciklus modell (2) Párhuzamos tervezési tevékenységek a későbbi fázisok számára Ez a modell is egyszerűsített, pl. – Nem mutatja az értékelési és verifikációs tevékenységeket - ezek minden fázisnál szükségesek a továbblépés előtt

A modell bármely integritási szint esetén használható – Az egyes fázisokban szükséges tevékenységek azonban a SILSIL-től függően erősen eltérhetnek Saftey--Critical Computer Systems Saftey

111

Fejlesztési módszerek A kevésbé kritikus rendszerekhez képest dominál a dependability – elérése és – ennek dokumentálása

Minden egyes fázis a helyes végrehajtás érdekében legyen – Jól strukturált – Jól dokumentált Saftey--Critical Computer Systems Saftey

112

Fejlesztési módszerek, lépések Felhasználói követelmények – Funkcionális – Biztonsági

Előzetes veszélyelemzés Specifikáció - a specifikáció animációja Top--level design Top Részletes tervezés A modulok megvalósítása és tesztelése Rendszer--integráció és rendszerteszt Rendszer Engedélyezés Saftey--Critical Computer Systems Saftey

113

Specifikáció A rendszer működésének leírása – – – –

Funkciók Együttműködés más rendszerekkel Operátori kapcsolatok Biztonsági jellemzők Tervezési „kényszerek”

Konzultációk a megbízó és a szállító között A szerződéses kapcsolat alapja A fejlesztési folyamat végén bizonyítani kell, hogy az eredmény minden tekintetben megfelel a specifikációnak (és remélhetőleg a megbízói követelményeknek) Saftey--Critical Computer Systems Saftey

114

Az ideális specifikáció tulajdonságai Korrekt Teljes (nemcsak normál körülményekre) Konzisztens (ellentmondásmentes) Féreérthetetlen (természetes nyelvek!) „Here is a picture of a man eating lion.”

– A természetes nyelven írt specifikációk helyességének ellenőrzése nehéz

Lehetősége – Strukturált szerkezet (félformális) – Formális matematikai módszerek Saftey--Critical Computer Systems Saftey

115

A specifikáció hibái A biztonságkritikus rendszerek egyik legnagyobb problémája a hibás specifikáció – A felhasználói követelmények meg nem felelősége – A specifikáció nem felel meg a felhasználói követelményeknek

A specifikációs hibák gyakran csak a kész rendszer vizsgálatakor derülnek ki, amikor a hibajavítás már igen költséges Saftey--Critical Computer Systems Saftey

116

A specifikáció animálása Egy lehetőség az animáció (SW prototipus) – Nem feltétlenül a teljes specifikációra terjed ki – Speciális szempontokra irányulhat, pl. Belső logikai funkciók MMI Általában nem veszi figyelembe – Az időzítési követelményeket – A hibatűrést – A beépített teszteket A prototípust a végső termékben nem használjuk, így fejlesztése sokkal kevésbé szigorú, szigorú, illetve ráfordításráfordítás-igényes Az animáció a specifikáció szimulációja a specifikáció validálására Az általános értelemben vett szimuláció a kifejlesztett rendszer szimulációja a fejlesztés helyességének vizsgálatára – Olcsóbb, mint a fizikai prototípus vizsgálata Saftey--Critical Computer Systems Saftey

117

Top-level design - Detailed design Rendszerfunkciók szétbontása – Hardver – Szoftver

Architektúrák kidolgozása (HW és SW) – Modulokra bontás (hierarchikus struktúra) – Modulkapcsolatok meghatározása (interfész) – Meghatározni a modulok Funkcióit Biztonsági jellemzőit

– Lényeges SW adatsruktúrák meghatározása

Modulok részletes tervezése – A dekompozíció gyakran iteratív (szubmodulok) Saftey--Critical Computer Systems Saftey

118

A modulok megvalósítása

HW és SW modul implementáció Programnyelv választása – A programnyelv tulajdonságai – Fejlesztő eszközök elérhetősége – A fejlesztő csapat gyakorlottsága, tapasztalatai


119

A modulok tesztelése Annak igazolása, hogy a modul megfelel specifikációjának – Dinamikus A HW/SW modul működtetésével Tesztkörnyezet – Adja a bemenő jeleket – Fogadja és értékeli a kimenő jeleket Számos jellemző, így pl. a válaszidő is vizsgálható – Statikus (analízis) A modul működtetése nélkül A tervezés felülvizsgálata Statikus kódelemzés Vizsgálhatók olyan jellemzők, amelyek dinamikussal, pl. a tesztek nagy száma vagy más ok miatt, nem vizsgálhatók Saftey--minden Saftey Critical Computer Systems pl. az időzítések Nem vizsgálható jellemző,

120

Begin Teszt tervezés Teszt specifikáció

A TESZTELÉS FOLYAMATA

Tesztesetek végrehajtása Feljegyzés, értékelés Teljesség ellenőrzése End


121

Tesztelési terv, teszt-esetek

Tesztelési terv – A teszt teszt--eseteket meghatározó technika megadása – A tesztelési eljárás megfelelőségét értékelő módszerek – A tesztelendő rendszer fejlesztését és teszt teszt-tervezését végzők függetlensége – A teszt teszt--környezet – A tesztelés teljességének kritériumai

Teszt--esetek meghatározása Teszt – A tesztelendő rendszer kezdeti állapota – A bemenetek – A várt válaszok Saftey--Critical Computer Systems Saftey

122

Rendszer integráció Progresszív integráció - hagyományos – A modulok kis csoportját (minimális rendszer) tesztelik, a hibákat javítják – Fokozatosan újabb modulokkal bővítenek, tesztelnek, javítanak – Az egyszerű kezdés és a kis lépésekben való bővítés miatt egyszerű a hibadetektálás és a diagnózis – Hátrány Hátrány:: A teljes rendszer jellemzői csak az integráció befejeztével vizsgálhatók - az ilyen funkciókkal kapcsolatos hibák késői, drága feltárása, javítása „Big bang” módszer – Tesztelés csak az integráció befejeztét követően – Feltételezés Feltételezés:: a modulok kialakítása és tesztelése megfelelő volt – Előny Előny:: a durva követelménykövetelmény- vagy specifikációs hibák viszonylag korán kiderülnek, javításuk kevésbé költséges – Hátrány Hátrány:: a tesztelendő rendszer bonyolultsága miatt a tesztelés feladata jóval nehezebb


123

Rendszerteszt, engedélyezés A rendszer integrációt követően – A teljes rendszer megfelel a specifikációnak – Dinamikus és statikus módszerek kombinációja – Szimulált vagy valós környezetben

Független tanúsító (az engedélyezéshez) – A fejlesztés valamennyi fázisát megfelelő gondossággal és kompetenciával hajtották végre – Dokumentálni kell Valamennyi munkafázist A tesztelés részleteit és eredményeit

– A tanúsítás folyamatát már a projekt elején tervezni kell – A szabványok, irányelvek megadják az egyes fejlesztési fázisokban szükséges dokumentációk listáját


124

Biztonságra tervezés A rendszertervezés nemcsak a fejlesztési, hanem bármely ezt követő fázisban is szükséges lehet, pl. – Tesztelést követő hibajavítás – Üzemeltetés közben talált hiba – Követelmény módosítás

A tervezési folyamat aktivitásai – Absztrakció: Absztrakció: az általánosítás, a lényeg megfogásának folyamata – Dekompozíció Dekompozíció:: egy objektumnak kisebb részekre bontása; a kapcsolatok, interfészek, struktúrák elemzése; modularizálás – Kidolgozás Kidolgozás:: a jellemzők részletezése, „hozzáadása” – Döntéshozatal Döntéshozatal:: az alternatív stratégiák számbavétele és kiválasztása


125

Biztonságra tervezés - hibamenedzselés Rendszer architektúra – Alapvetően befolyásolja a rendszer hibatűrő képességét – Védelmet nyújt A véletlen hardverhibák és Néhány szisztematikus hiba hatása ellen

– Nem nyújt védelmet a specifikációs hibák hatása ellen

Megbízhatósági tervezés – Elsődlegesen a hardver hibákra való érzékenység – Ajánlott számításokat végezni a szisztematikus HW és SW hibák hatásának jóslására is

Minőség--menedzsment Minőség – A teljes életciklust átfogja – Valamennyi hibatípusra vonatkozik Saftey--Critical Computer Systems Saftey

126

Hierarchikus tervezés (1) A hierarchikus tervezés lépései – A rendszer felbontása HW HW--re és SW SW--re – Mind a HW, mind a SW felbontása rétegekre (layers) – A felsőbb rétegek moduljainak helyes működése az alsóbb rétegek helyes működésétől függ

Hierarchikus tervezéssel egy bonyolult rendszer jól menedzselhető bonyolultságú modulokra bontható Ez azonban a teljes rendszer bonyolultságának növekedését is jelenti a modulmodul-interfészek miatt A túlzott felbontás az alsóbb szintek „elrejtőzésének” irányában hat, így nehezítheti a HW, ill. a SW struktúra átláthatóságát, megérthetőségét


127

Hierarchikus tervezés (2) Példa: Példa: – az alsó szintek reprezentálhatnak processzorokat, kontrollereket, szenzorokat – A felső szintek felhasználói szoftvernek vagy magas szintű HW logikának felelhetnek meg – A közbenső rétegek kommunikációs szoftvert és készülékmeghajtókat képviselhetnek Ábra


128

Hierarchikus tervezés (3) „Downward--only functional dependence” elv „Downward – Az alsóbb rétegek funkciói rejtve vannak a felsőbb rétegek elől – Megakadályozza, hogy a felsőbb szintek közvetlenül aktiválhassanak potenciálisan veszélyes funkciókat – Kivétel a biztonságos működés érdekében nagy megbízhatóságúra (dependable) kialakított alsóbb szintű modulok használata

Példa – Az alsó rétegek viszonylag egyszerű és megbízható szoftver vagy hardver modulokat tartalmazhatnak, aktuátorok vezérlésére – Ha valamely aktuátor inkorrekt vezérlése potenciálisan veszélyes lehet, biztonsági függéssel lehet ezt kizárni Saftey--Critical Computer Systems Saftey (fénysorompó stb.)

129

Hierarchikus tervezés (4) A biztonsági függés megvalósítása – Egyszerűbb esetben az aktiváló mechanizmus és a biztonsági függés egyetlen modulban van megvalósítva (encapsulated encapsulated)) – Bonyolultabb rendszerekben a függőség több alsóbb szintű modultól is igényelhet jeleket. Ilyenkor a biztonságot a felsőbb szintű modulok nyújtják. Ezek helyes működése az alacsonyabb szintektől függ – Az így létrejövő többrétegű hierarchiában a magasabb szintű működés el van választva a biztonsági funkciókat megvalósító eszközöktől


130

Hierarchikus tervezés (5) A biztonsági függés megvalósítása (folyt.) – Egyes esetekben a rendszer felbontása megoldható úgy, hogy valamennyi biztonsági funkciót, beleértve a függőségeket, az alsó szintű modulok valósítsanak meg – Emellett e modulok kialakíthatók egymástól „elszigetelten”, így működésük egymástól független lesz – Előny Előny:: Csak a viszonylag egyszerűbb alsó szintű modulokat kell a magasabb integritásnak megfelelően kialakítani A bonyolultabb magasabb szintű moduloknál elegendő az alacsonyabb integritási szint Ezáltal lényegesen csökken a nagy biztonsági szinten fejlesztendő részek aránya, és ennek megfelelően a fejlesztési költségek


131

Hierarchikus tervezés (6) A biztonsági függés megvalósítása (folyt.) – Példa: Példa: Hibatűrés megvalósítása hierarchikus struktúrában az alsóbb szinteken, a magasabb szintektől „elrejtve” Ez lehetővé teszi az egyes alsó szintű modulok hibáinak a felsőbb szintek irányában való maszkolását – Sajnos gyakran a magasabb szintű funkciók is integráns részei kell legyenek a biztonság megvalósításának – A modulok szükséges elválasztása szintén problematikus lehet


132

Biztonsági mag Biztonsági mag – Viszonylag egyszerű elrendezés – Általában HW/SW kombináció, a kritikus rendszer „szívében” – Kis mérete, egyszerű felépítése egyszerű fejlesztést és tesztelést tesz lehetővé a biztonság megbízható módon történő szavatolására – Tipikusan biztonsági funkciókat hajt végre vagy az operációs rendszer kritikus feladatokat ellátó részeiből áll – A megoldás eredményessége attól függ, hogy mennyire védhető a biztonsági mag a működését befolyásoló külső hatások ellen – A védelem lehet Fizikai (külön hardver) Logikai (szoftver mag, a többi résztől elkülönítve) Saftey--Critical Computer Systems Saftey

133

Tűzfal Tűzfal – Elválasztja a biztonsági és a nem biztonsági részt (előbbi a tűzfal mögött) – HW esetén fizikai akadályt jelent a káros hatásokkal, pl.alkatrész meghibásodásával szemben – SW esetén logikai akadályt képez (megakadályozza a falon kívüli SW hibájának a falon belüli kritikus SWSW-re való hatását) – Ezt elérendő, a védett területen belül meg kell akadályozni az adatokhoz és a programkódhoz való illetéktelen hozzáférést, illetve ezek illetéktelen módosítását: SAFETY <> SECURITY


134

Karbantarthatóság


135

SZÁMÍTÓGÉPEK ALKALMAZÁSA KRITIKUS TERÜLETEKEN (2)

Recommend Documents