Gépészet | Biztonságtechnika » Rendszerbiztonság szervezése és kiépítése

Rendszerbiztonság szervezése és kiépítése ( előadás a System Safety Engineering and Management című könyv alapján ) az Információs Rendszerek minőségbiztosítása című tárgy keretében Összeállította: Szokó Szabolcs Műszaki Informatika IV. Bevezetés A könyv a jelenlegi értelmezés és gyakorlat alapján járja körül a r endszerbiztonság témakörét, tudniillik, hogy a rendszer tervezése közben épíünk bele biztonságot. Mit foglal magában a rendszerbiztonsá tárgyköre ? • A rendszer biztonsági állapotának értékelése végig annak életciklusa során • Annak meghatározása, hogy ez az állapot mennyire elfogadható • A rendszer elfogadható biztonsági szintre emelésével kapcsolatos értékelések • Döntéshozatal használatról vagy ellenintézkedések alkalmazásáról Így, mint látható e t émakör tartalmaz részeket a kockázatfelmérés és -kezelés területéről, viszont nem foglalkozik a biztosítási illetve

kockázatátruházási aspektusokkal. Kiknek szól ez a könyv ? • Ezen módszerek teljesen működő rendszerekre is alkalmazhatóak, ezáltal azon biztonsági szakemberek számára nyújthat segítséget, akik valós rendszerek vizsgálatával és fejlesztésével foglalkoznak • Azon hagyományos munkavédelmi szakemberek számára is hasznos lehet, akik dolgozók munkahelyi védelmével foglalkoznak Mire összpontosít a könyv ? • A könyv nem tartalmazza a biztonság tárgykörének minden elemét. Kevés hangsúly esik például az "a posteriori" (esemény utáni) módszerek és technikák tárgyalására • Központi hangsúlyt kapnak azonban a rendszerbiztonságon belül a balesetek megelőzésének szempontjai. Ezeket, a balesetek bekövetkezésük előtti kiküszöbölését szem előtt tartó módszereket "a priori" (esemény előtti) módszereknek nevezzük. A biztonságnak azon, tudománytárggyá fejlődése óta általánosan követett

formája, mely szerint bekövetkezett balesetekből eredő ismert precedens szolgál alapul a további hasonló balesetek megelőzéséhez, teljesen alkalmatlan azon balesetek esetében, melyeknél a következmények katasztrófával járnak. A rendszerbiztonság megkísérli ezért előre érzékelni, kiszámítani a baleseteket és felbecsülni a t eljes kockázatot végig a r endszer életciklusán keresztül. Ez elvégezhető menedzsment technikák és analitikai (elemző) módszerek egyedi halmazán keresztül. Nyilván minden korszak és minden ember számára mindig ugyanúgy közös cél volt a veszélyektől mentes, biztonságos élet. Az ember állandóan kereste az életszükségletek biztosításának, az élet javításának módjait, kiaknázva a környezet adta lehetőségeket. A képesség, mellyel tökéletesítették környezetüket, mérhetetlenül növekedett amikor az első eszközt kezdték használni, majd egyre jobb technikákat fejlesztettek ki újítások

kimunkálásához. Az emberiség nemsokára technikaivá vált abban az értelemben, hogy biztosítják azokat a körülményeket maguknak, amelyek a l étfenntartáshoz és a f izikai megelégedettséghez szükségesek. A biztonság alapvető szerepet játszott ebben a fejlődésben A biztonság gondolata az emberiség történetének hajnala óta létezik. A korai embereknek jó okuk volt arra, hogy védekező magatartást tanusítsanak: féltek a r engeteg természeti veszélytől, csapástól, mert nem tudták pontosan, mi okozza őket. Később kifejlesztettek egy ösztönös képességet a f enyegetettség, a t ámadás érzékelésére, s megtanulták a veszély kiértékelését, a megfelelő védekező reakciók gyakorlását. Ahogy telt az idő, a biztonság szociális formát vett fel. A fejlődésnek azonban ugyanúgy voltak negatív, mint pozitív hatásai, jóllehet az újítások kielégítették igényeiket, de a változások gyakran adtak előrenemlátott

eseményeket, tényezőket, amelyek veszélyeztették, vagy károsították a társadalom egyes részeit. Az embereknek foglalkozniuk kell azokkal a veszélyforrásokkal, melyek gondatlanságon, fegyelmezettlenségen, őrizet hanyagságán keresztül, vagy eszközök és vagyontényezők nem megfelelő szervezése miatt okoznak károkat. Ezért eszközöket kell kidolgoznunk, melyekkel minimalizálhatók ezek a veszélyek. Ma úgy látjuk, hogy az egyes ember biztonsága otthon, munka közben, utazás alatt, játék közben – ezek környezetében – az egyes iparágak, a t ársadalom és a k ormány közös érdeke és felelőssége. Az utóbbi évszázad adta azt a tudást, mely minden egyén számára biztosította teljes környezetében a biztonságnak egy ésszerű, indokolt fokát. Fontos, hogy úgy találtatott, ez a biztonság az egész társadalom számára költséghatékony, ugyanakkor erkölcsileg kötelező. A rendszerbiztonság fő feladata ilymódon: biztosítani azt,

hogy tisztába kerüljünk a rendszerrel kapcsolatos veszélyeket illetően, mielőtt azt működésre engedélyezzük. A rendszerek használatának elengedhetetlen velejárója a v eszélyforrások felismerése és meghatározása. Ehhez szükség van a t ermék vagy rendszerelemzés elvi módszertanára, melynek jobb megértése érdekében tanulmányozzunk át néhány definíciót ! Definíciók Veszélyforrás (Hazard) Potenciális feltétel, vagy feltételek halmaza – ezek egyaránt lehetnek rendszeren, terméken, működésen belüliek vagy kívüliek – , melyek ha aktiválódnak, akkor a veszélyforrást események sorává alakítja, amik végül káresetben (balesetben) csúcsosodnak ki . A kiváltó okok lehetnek: - alkatrész meghibásodása - a rendszer állapota (nyomás, hőmérséklet) - karbantartás hibája - operátor hibája - más események és feltételek kombinációja. Rendszer (System) Egymásra ható, együttműködő, kapcsolatban álló, vagy

független elemek csoportja, melyek kollektív egységet alkotnak ill. kollektív egységnek tekinthetők A rendszer emberek, eljárások és felszerelések együttese, amelyeket egy meghatározott feladat vagy funkció céljából egyesítenek egy meghatározott környezetben. Az alrendszer a rendszer egy részét jelöli, mely önállóan is rendszert alkothat. Kiváltó ok (Stimulus) Események vagy feltételek egy olyan halmaza, mely az arra érzékeny veszélyforrásokat, annak potenciális állapotából egy olyan állapotba viszi át, amely tulajdont vagy személyeket illetően a rendszer sérülését, kárát eredményezi. Baleset (Accident) Egy dinamikus mechanizmus, mely veszélyforrások aktivációjával kezdődik és események soraként vonul végig a rendszeren logikai sorrendben. Az eredmény végül mindig veszteség A baleset tehát olyan nemkívánt, nem tervezett esemény, melynek eredménye személyi, vagy vagyoni veszteség. Biztonság (Safety) Potenciális

veszélyektől való mentesség. A rendszer fontos jellemvonása, akárcsak a minőség, a függetlenség, vagy a megbízhatóság. Kockázat (Risk) A kockázat kapcsolatos a kár valószínűségével, tulajdonképpen nevezhető a veszteség várható értékének. Ahogy egy veszélyforrás balesetté válhat, úgy a kockázat kapcsolatban áll annak valószínűségével, hogy a stimulus, gyakorisága, intenzítása és időtartama révén a vészforrást kárrá alakítja. A rendszerbiztonság fogalma A rendszerbiztonság tulajdonképpen meghatározott módszerek, képességek alkalmazásáról szól, melyek előrelátó elemzéseket, hibameghatározásokat és -kiszűréseket irányoznak elő végig a rendszer életciklusa folyamán, a koncepcionális fázistól kiindulva a tervezésen, gyártáson, tesztelésen, használaton keresztül egészen a rendszer visszavonásáig. A múltban, némely időszakokban elterjedt volt az ún. esemény utáni filozófia, amelyet követve mindig

a baleset bekövetkezte után kezdtek tanakodni, vizsgálódni, mi okozhatta a bajt, és mit lehetne tenni hasonló okból következő esetek elkerülése érdekében, majd a meglevő rendszert módosították, biztonsági tervezését korrigálták. Ez a filozófia esetenként komoly áldozatokat igényelhet. A rendszerbiztonság fogalma ezzel szemben a tervezett, jól átgondolt, rendszerezett, ún. esemény előtti módszereket támogatja Ennek lényege: a b iztonság egy elfogadható fokának elérése, melyhez a rendszer gyártását és működését megelőzően szükség van: - a rendszer hibaforrásainak időben történő azonosítása és értékelésére, még a kár keletkezése előtt, - hibaforrások kizárására a biztonság egy elfogadható fokának eléréséig, - előzőleg korrekciós lépések meghatározására. A professzionális mérnök számára a biztonság követelmény. Ilyen célból számos mérnök dolgozik űrprogramokban (ICBM- Intercontinental

Ballastic Missile tervezése), műholdak telepítésénél, nukleáris reaktorok építésénél. Sok helyen biztonsági tervezés céljára külön személyzetet alkalmaznak. És az igény nő, ez megfigyelhető különböző vállalatok szervezetének alakulásából, biztonsági részlegek kialakulásából. A hibaforráselemzés az egész rendszerbiztonság szíve. Érdemes megjegyeznünk, hogy ezen hibák nem mindegyike okoz mindenképpen gondot, hiba károkozás nélkül is előfordulhat, és komoly balesetek történtek már hiba (valami nem úgy működött, ahogy tervezték) előfordulása nélkül is. A rendszerbiztonság története 1947: A Repüléstudományok Intézetéhez címzett szakmai folyóiratbeli cikk jelent meg "Tervezés a biztonságért" címmel. Ez volt az egyik első megfogalmazása a rendszerbiztonsági elvnek. 1960-ig: nem vett szerződésszerű irányultságot a fogalom. Addig az a megszokott gyakorlat urlakodott, hogy minden tervező,

menedzser és mérnök feltehetőleg biztosította részét a biztonságért való felelősségben. Tehát ekkor még nem volt előírásszerű szerződési forma a biztonságra vonatkozóan.Később születtek meg a különböző szabványok, specifikációk, követelmények, köszönhetően a biztonság fejlődésének. 1960-as években fejlesztett rakétarendszerek, fegyverrendszerek a hibaforrásvizsgálat új megközelítését igényelték. 1962: Légierő (USA) ballasztikus rakétákkal foglalkozó részlegének kiadványa: "A légierő ballasztikus rakétáinak fejlesztésére irányuló rendszerbiztonsági tervezés". Ez volt az első igazi rendszerbiztonsági alapmű 1963. szeptemberében a dokumentumot felülvizsgálták és az új leírást MIL-S-38130, "Honvédségi specifikáció - Általános követelmények rendszerek, kapcsolódó részrendszerek, valamint eszközök biztonsági tervezésével kapcsolatban." 1966. június: Kis revízióval a

specifikáció Védelmi Minisztérium (Department of Defense - USA) előírásává vált. Ennek neve: MIL-S-381308A 1969: Újabb revízió, melynek eredménye: MIL-STD-882, "Rendszerbiztonsági program rendszerek, kapcsolódó részrendszerek és eszközök számára; Ehhez fűződő követelmények." A Védelmi Minisztérium jóváhagyásával a szabvány kötelezővé vált minden termékre vagy rendszerre irányuló rendszerbiztonsági programra. 1984: Kihírdetésre kerül a MIL-STD-882B. Ez egy specifikusabb, formaira szabott program. A rendszerbiztonság használata a k ereskedelmi iparban is megnőtt, mégpedig a honvédség által fejlesztett módszerek átvételével. Néhány terület: - atomerőmű - finomítás - vegyi üzemek Később a szabvány könnyebb használhatósága érdekében fokozatosan végeztek rajta kisebb változtatásokat. Jó példa erre a software-rendszerek biztonságáról rendelkező részek pótlása a MIL-STD-882-ben. A

rendszerbiztonság célja Alapvető cél, hogy minden személy olyan körülmények között éljen és dolgozzon, amelyben a veszélyforrások ismertek és a potenciális veszély egy elfogadható szintjén szabályozhatóak. A célok elérésére irányuló eljárások Alapvetően két kategória figyelhető meg ezen feladatokkal kapcsolatban: 1. Szabványok előirányzása, a termékek biztonságosabbá tétele, a termékgyártás és használat biztonságosabb körülményeinek megteremtése. 2. A rendszer és operációkutatásban gyökerező kvantitatívabb módszerek A rendszerbiztonsági program feladata a hazárdok eltávolítása a rendszerből. Optimális esetben a p rogram végrehajtása a r endszer éleciklusának kezdeti fázisában elkezdődik, és végigköveti a további fázisokat is. A hazárdok játszák tehát a központi szerepet, melyek kiküszöbölését még a tervezőasztalon meg kell kezdeni. Mérlegelnünk kell a meglevő hazárdok illetve kockázatuk

közötti egyensúlyt. A hazard két legfontosabb és leggyakrabban vizsgált jellemvonása: 1. A veszély fellépésének valószínűsége 2. A veszély komolysága A MIL-STD-882 ezen tényezők értékelésére a következő csoportosításokat javasolja: Hazárdok komolysága I. Katasztrófális II. Kritikus III.Kis jelentőségű IV.Elhanyagolható Halál A rendszer elvesztése Komoly, súlyos sérülés, vagy betegség Nagyobb sérülés a rendszerben Kis sérülés vagy betegség Kisebb sérülés a rendszerben Nincs sérülés, betegség Nincs károsodás a rendszerben Hazárdok valószínűsége A B C D E Gyakori Valószínű Alkalmi Ritka Valószínűtlen Gyakorta előfordul Többször előfordul Néha előfordul Nem valószínű, de van esély az előfordulásra Majdhogynem biztosra vehető, hogy nem tapasztaljuk előfordulását A kétféle kategorizálás táblázatba foglalásával veszélyességi mutatókat (HRI- Hazard Risk Index) képezhetünk. HRI I. 1A, 1B, 1C,

2A, 2B, 3A II. 1D, 2C, 2D, 3B, 3C Elfogadhatatlan Nemkívánatos III. 1E, 2E, 3E, 4A, 4B IV. 4C, 4D, 4E Elfogadható Vizsgálat nélkül elfogadható A követendő rendszerbiztonsági feladatok: Biztonsági menedzsment Biztonsági tervezés Biztonsági elemzések Hazárdmeghatározás Hazárdleírás Okozati események meghatározása Hazárdkezelés Hazárdkezelés kiértékelése Dokumentálás MIL-STD-882 A szabvány egységes követelményrendszert támaszt a b iztonsági program kiépítése és alkalmazása kapcsán, amely azonosítja a veszélyforrásokat és biztosítja azok megfelelő kezelését, hogy ezáltal a menedzsmentnek megfelelő, elfogadható biztonsági szint jöjjön létre. Az USA-ban ezt a szabványt a Védelmi Minisztérium alkalmazta először rendszereire, berendezéseire, módszereire. A rendszer életciklusa Koncepció Konceptuális elemzés Definíció Validáció (érvényesség, helytállóság vizsgálata) Kidolgozás Teljes skálájú

tervezési fejlesztés Gyártás Kivitelezés Alkalmazás Működés - fenntartás (Visszavonás) Rendszer működésének megszüntetése Ezen fázisok között ellenőrzőpontok vannak, amelyek kiértékelésekor dől el, hogy a rendszert továbbengedjük-e léptetni a következő fázisba, vagy további vizsgálatokra van szükség. A rendszerbiztonsági program teljesítése A rendszerbiztonsági program végrehajtása a vállalat felső menedzsmentjének elkötelezettségén összpontosul. A legtöbb ipari szervezetben a program végrehajtásának felelőssége a projekt menedzsmenttel kapcsolódik össze. A projekt menedzsment feladata, felelőssége a termék, vagy a rendszer fejlesztése. Ennek megfelelően meg kell terveznie és implementálnia kell a megfelelő programot, hogy egy biztonságosan tervezett terméket kapjunk végeredményül. Rendszerbiztonsági programterv Rendszerbiztonsági program teljesítésében a l egfontosabb elem az SSPP (System Safety Program Plan

- Rendszerbiztonsági Programterv), miután a felső vezetés és a megrendelő (fogyasztó) elkötelezték magukat egy biztonságos rendszer fejlesztésére. Az SSPP egy formális dokumentum, mely azon biztonsági feladatokat írja le, amelyek ahhoz szükségesek, hogy rendszerbiztonsági követelményeket elégítsenek ki. Az SSPP a következőket végzi: • A teljes termékkel vagy rendszerprogrammal kapcsolatos feladatok leírása • A termék tervezése és fejlesztése folyamán szükséges vezetési vizsgálatok meghatározása • Az életciklus folyamán alkalmazandó biztonsági elemzések módszereinek leírása A mellékelt táblázat (ill. a majd itt következő felsorolás) mutatja azokat a feladatokat, amelyeket az SSPP-ben figyelembe kell vennünk (MIL-STD-882). A táblázat szerkezete: 100-as sorozat: A teljes program definiálását szolgáló rendszerbiztonságmenedzsmentbeli feladatok 200-as sorozat: Hazárdelemző tevékenységek az életciklus alatt 300-as

sorozat: Software-hazárdok elemzése Veszélyforrás elemzés A rendszerbiztonságtervezés definíciója (MIL-STD-882): A rendszerbiztonságtervezés egy műszaki, mérnöki tudományterület, mely különleges ismereteket igényel tudományos és mérnöki elméletek, kritériumok és technikák alkalmazásához, melyekkel meghatározhatók és kezelhetők a veszélyforrások és az azokkal összefüggésben levő kockázati tényezők, mely által a biztonság egy elfogadható foka valósulhat meg. Ezen tevékenységek: Előzetes hazárdlista kidolgozása Előzetes hazárdelemzés végrehajtása Részrendszerek hazárdelemzésének végrehajtása Rendszerhazárd elemzés végrehajtása Működési és kiszolgálási hazárdok elemzésének végrehajtása Egészségügyi hazárd vizsgálat végrehajtása Software hazárd elemzés végrehajtása Kockázatelemzés végrehajtása a részrendszereken és rendszereken, valamint javaslatok a kockázatelfogadással és kezeléssel

kapcsolatban Néhány hazárdelemző módszer elsődlegesen a hazárdok felfedésére irányul, más módszerek a hazárdok okozatait keresik, néhány pedig mindkét funkciót ellátja. Lássunk ezen (táblázaton is szereplő) hazárdelemző módszerek közül néhányat: PHA (Preliminary Hazard Analysis) Az első komolyabb erőfeszítések között szerepel az életciklus tervezési szakaszában. Céljai: - biztonságilag kritikus területek meghatározása a rendszeren belül - hazárdok meghatározása és durva kiértékelése - biztonságtervezési kritériumok figyelembevétele PHL (Preliminary Hazard List) készülhet a PHA-hoz, de attól függetlenűl is. De ha van ilyen, akkor azt a PHA általában felhasználja. A PHA-nak minmálisan az alábbi műveleteket kell magában foglalnia: 1. Hasonló rendszerek biztonsági tapasztalatainak áttekintése 2. Alapvető energiaforrások vizsgálata 3. Biztonsági követelmények és szabályozások áttekintése 4. A részrendszerek,

rendszerelemek közötti interfészek vizsgálata 5. Környezeti hazárdok vizsgálata 6. 7. 8. 9. Működés, teszt, karbantartás és vészeljárások vizsgálata Kiszolgálóegységek, felszerelések ellenőrzése Software-modulok vizsgálata hardware interfészeikkel együtt Biztonságot szolgáló felszerelések megfelelőségének, alkalmazhatóságának vizsgálata PHA dokumentációja Oszlopos formátumú irat, melynek az alábbi információkat kell tartalmaznia: - A vizsgálandó rész vagy részrendszer megnevezése - Rendszerműködési üzemmód, melyben hazárd fenyeget - Hibás üzemmód - Hazárd leírása - Baleset előfordulásakor keletkező hatások leírása - Hazárdsúlyossági kategória - A hazárdkezelés módszereinek általános leírása SSHA (Subsystem Hazard Analysis) Nagyobb rendszerek részrendszereinek tervezési hazárdjainak azonosítására szolgál. Baleseti károkat eredményező működési hibákat hivatott felfedni. Vizsgál: -

komponensből vagy felszerelésből származó hibákat és hibalehetőségeket - software hibákat és hibalehetőségeket - emberi hibát A vizsgálatoknak legkésőbb a definíciós fázisban el kell kezdődnie. Az SSHA dokumentációja - Minden hazárd leírása - Minden hazárd okozati eseményei - Hazárdok közötti interakció - A rendszer biztonságának kiértékelése - A részrendszerek által keltett rendszerhazárdok kezelésére irányuló javaslatok SHA (System Hazard Analysis) Az SHA a teljes rendszert vizsgálja a biztonsági állapot szempontjából (SSHA lényeges kimeneteinek felhasználásával). A hangsúly a részrendszerek közötti interakciók vizsgálatán van, melyhez a szempontok a következőek: 1. A részrendszer követelményeit tartalmazó dokumentumban meghatározott biztonsági kritériumok teljesítése 2. Veszélyes események halmazának felderítése 3. A részrendszer rendszerbiztonsági szintje 4. Szándékolt tervezési módosítások, melyek

hatással lehetnek a biztonságra, ill. növelhetik a kockázatot 5. Software-rendszerek irányító funkciói, melyek hátrányosan befolyásolhatják a rendszer kockázatait software-hibák által 6. Emberi hibák következményei Alkalmazható módszerek: FHA, FTA, FMEA (lsd. később) Az SHA dokumentációja - Leíró információk - Minden hazárd okozati eseményei - Részrendszer interfész problémák - Rendszerkockázat meghatározása - Javaslatok a kockázat kezelésére O&SHA (Operating and Support Hazard Analysis) Az O&SHA végrehajtásának céljai: - A hazárdok okozatainak feltárása - Kockázatcsökkentő alternatívák ajánlása - Elfogadható kockázati szint elérése Az O&SHA végrehajtása alatt az alábbi működési műveleteket kell vizsgálnunk: 1. Rendszerteszt, figyelembe véve a tesztek hatályait, tesztelési környezeteket 2. A rendszer, részrendszer vagy komponensek üzembehelyezése, módosítása a tesztelés vagy a normális

működés alatt 3. Karbantartási műveletek a rendszerteszt vagy a normális működés alatt 4. A rendszer szállítása 5. A rendszer tárolási, raktározási tevékenységei 6. Működés, vagy tesztelés alatt bekövetkezhető balesetek 7. Baleset utáni problémák Az O&SHA dokumentációja - Leíró információk - Hazárdok által okozott események - Rendszerműködési kockázat kiértékelése - A rendszerkockázat elfogadhatóságának logikai kiértékelése - Javaslatok a kockázat kiértékelésére Az itt született kimenetek az SHA során kerülnek felhasználásra. FHA (Fault Hazard Analysis) Az FHA egy induktív módszer, mely használható az SSHA-ban, SHA-ban, vagy az O&SHA-ban. Célja azon hazárdok felderítése, melyek valamilyen egyszerű, egyedi rendellenesség, vagy hiba eredményei. Az FHA legnagyobb gyengesége ezért az, hogy nem veszi észre azokat a hazárdokat, melyeket többszörös hibák együttes bekövetkezése okoz. Az FHA

dokumentációja Komponens megnevezése Hibakeletkezési feltétel Komponens mód Részrendszer mód Rendszer mód Hazárd hatása a részrendszerre Hazárd hatása a rendszerre Környezeti tényezők Másodlagos tényezők Hazárd fokozat Hazárdkezelés FMEA (Failure Mode and Effects Analysis) Az FMEA egyfajta megbízhatósági elemzés, mely azon egyszerű események elemzésére összpontosul, melyek a megbízhatatlanság egy fokát okozzák a rendszerben. Egy ilyenfajta elemzés persze tartalmazhat eseményeket, melyek nem okoznak baleseteket. Az FMEA dokumentációja Komponens meghatározása Komponens funkciója Hibamódok Ezek áktal okozott események Rendszer és részrendszer mód Hibahatások leírása: Rendszer Részrendszer és Környezet szintjén Hiba foka (hatás és valószínűség) Hibakezelés Alkalmazható szabványok és szabályozások FTA (Fault Tree Analysis) Az FTA kidolgozása (1961) óta széles körben elterjedt, mint a rendszerekben fellépő

eseményhalmazok egyik leghatékonyabb elemzési eszköze. A módszert először H.A Watson, a Bell Laboratórium munkatársa agyalta ki ICBM rendszerek kibiztosításának biztonsági kiértékelése céljából. A módszer aztán tovább finomodott, és alkalmassá vált jóval komplexebb rendszerek vizsgálatára is. Ma már számítógépprogramok állnak rendelkezésre a Boole-logikán alapuló eseményfa struktúrák könnyű elemzésére. Az FTA előnyei: 1. Az elemzőt deduktívan a balesettel kapcsolatos eseményekre vezeti 2. Azon rendszerfunkciók egyértelmű ábrázolását biztosítja, melyek egy nemkívánt kimenethez vezetnek 3. Lehetőséget kínál kvalitatív és kvantitatív elemzésre is 4. A rendszerviselkedés könnyen megfigyelhető A fa szerkezete: Következmény (Top Event) Annak kiváltó okai A következmény és az okok közötti, a kapcsolat jellegének megfelelő típusú (OR vagy AND) reláció ábrázolása E három alapvető eszközzel bonyolult

fastruktúrák építhetők. A kétféle fatípus: OR A bemeneti kiváltó okok egyikének bekövetkezése is elegendő a következmény létrjöttéhez. Jelölés: + (pl. három esemény (A, B és C) esetén: E=A+B+C) AND A bemeneti események mindegyikének bekövetkezése szükséges a végkövetkezmény létrejöttéhez. Jelölés: • (pl. három esemény (A, B és C) esetén: E=ABC) Egyes esetekben szükséges lehet más típusú kapcsolatok szemléltetése is (pl. egymást kizáró események esetén az exkluzív OR (XOR). De mindig arra kell törekednünk, úgy kell alakítgatnunk a f át, h ogy az végeredményben csak AND és OR relációkat tartalmazó struktúra legyen. Ez nagyban megkönnyíti az elemzések elvégzését Software-k hibaforrás elemzése (Software Hazard Analysis) Software-k esetében tudjuk, hogy a hibák nem keletkeznek elhasználódásból, tehát nem nagyon alkalmazhatók a t öbbi rendszernél esetleg sikeres sztochasztikus módszerek. A

software-rendszerek nem tudnak használat közben meghibásodni, azok működésüknek kezdetétől magukban hordozzák a hibát! Tehát a r endszer elemzése, mely hazárdok előfordulása után kutat, magában kell foglalja a rögzített, kódolt utasítások elemzését, ha valaki a veszteségek lehetőségeit próbálja megérteni a rendszeren belül. Az ilyenforma elemzést software-biztonsági elemzésnek nevezzük. A software-hibák három fajtáját különböztetjük meg: 1. Valódi hibák, melyeket a programozó ejt a kódolásban Ezek azt eredményezik, hogy a software nem a rendeltetésének megfelelően dolgozik. 2. Rossz software-specifikáció vagy programozói specifikáció értelmezéséből eredő hibák 3. Hardware meghibásodásából eredő hibák A software biztonsági program elemei A sw fejlesztési folyamat esetenként párhuzamosan haladhat a h w fejlesztéssel. A sw hiba elemzési feladatokat a fejlesztés minden fázisában végre kell hajtani, ha a

rendszer tartalmaz lényeges software elemeket. Software elemzési feladatok: SHEA (Software Hazardous Effects Analysis) Az elemzés a software fejlesztés követelményeket felállító szakaszában kezdődik. Az SHEA a lehetséges problémás területekre koncentrál a software-n belül. Az SHEA elemei: Software funkció Funkcióleírás Rendszerhazárd Hazárdkategória Biztonsági hatás Ajánlott követelmények Megjegyzések Állapot Az elemzéshez jól használható az FTA. SRHA (Software Requirements Hazard Analysis) A rendszerépítés koncepció-szakaszában hajtják végre az elemzést, de ez folytatódhat a definíció és a f ejlesztés fázisaiban. Célja: Hibás követelményeken alapuló, biztonságot nélkülöző funkciók felfedése (2. típusú hibák) Az elemzés használja a PHA eredményeit A dokumentum tartalma: 1. Specifikációs elemek vagy rendszerfunkciók 2. Kapcsolódó software struktúra 3. Kapcsolódó software funkciók 4. Lehetséges veszélyes

hatások 5. Hazárdok javasolt kezelése 6. Kapcsolódó tesztelési követelmények TDHA (Top-Level Design Hazard Analysis) Az elemzés funkcionális software-modulok vizsgálatát végzi. Inputként felhasználhatóak az SRHA eredményei, általában a definíciós fázisban végzik, de folytatódhat a kidolgozási fázisban. Software-modulokat definiál és azok funkcióit vizsgálja, lehetséges veszélyes hatások után kutatva. A kritikus modulokat tovább vizsgálják, melyek esetleg a PHA, SSHA vagy SRHA elvégzése után már ismertek voltak. A dokumentáció tartalma: 1. Software funkcionális modulok leírása 2. Lehetséges veszélyes hatások 3. Software-modul függőségek 4. Lehetséges software tervezési módszerek a hazárdok kezelésére 5. Ajánlott tesztkövetelmények DDHA (Detailed Design Hazard Analysi) Az elemzés a TDHA-t követően kerül végrehajtásra. A TDHA által kidolgozottak szerint az elfogadható biztonsági fejlesztés implementációs módszereit

vizsgálja. Általában a definíciós és fejelesztési fázis alatt hajtják végre. Azt vizsgálja, hogy a modulok funkciójának implementációjában a hazárdok nem lépnek-e túl egy elfogadható biztonsági és kockázati szintet. Nem vizsgál kódot, sőt nem is szoktak kódolni, amíg el nem készült a DDHA Az analízis felhasználja a PHA, SSHA, SRHA és TDHA által szolgáltatott eredményeket. Ez az analízis biztosít utolsó lehetőséget a software funkciók kódolásának biztonsági előírásainak rögzítéséhez. A dokumentáció tartalma: 1. Software-modulok leírása 2. Lehetséges veszélyes hatások 3. Ajánlott kódolási megközelítések a hazárdok kezelésére 4. Biztonságilag kritikus software-modulok meghatározása 5. Ajánlott tesztelési követelmények CSHA (Code-Level Software Hazard Analysis) Az elemzést a DDHA-t követően hajtják végre, mely biztosítja, hogy a kódolásra csak az összes elfogadhatatlan hazárd kiemelése után

kerüljön sor. A kifejlesztési fázis alatt hajtják végre. Az analízis a software modulok kódjait elemzi olyan szempontból, hogy az megfelel-e a korábbi elemzések által támasztott követelményeknek és hogy a k ódolás folyamatába nem került-e újabb hazárd, figyelembe veszi a TDHA és DDHA kimeneteit. Elsősorban az 1 típusú hibák elkerülését kísérli meg biztosítani. A CSHA adja az utolsó alkalmat a kód vizsgálatára és javítására, mielőtt a rendszer tesztelésre kerül. Lényeges kikötés, hogy a kódolás folyamata ne csökkentse a korábban elfogadhatónak bizonyuló biztonságot