A funkcionális biztonságra vonatkozó, vagy kapcsolódó szabványok, előírások

Szabó Géza

MSZ-EN 61508 (IEC61508) – Funkcionális biztonság (Elektromos vagy programozható rendszerek)

A szabvány az általános biztonság elérésének és demonstrálásának módját határozza meg.

A korábbi megközelítésekhez képest a biztonság elérésének új módját választja, felismerve, hogy a korszerű, nagy bonyolultságú rendszereknél a már kész rendszer vagy berendezés biztonságos működése csak nehezen (vagy sehogyan sem) ítélhető meg.

A szabvány szellemisége az alábbiakban foglalható össze:

1. Az elvárt biztonság szintjének meghatározása

A rendszerrel vagy berendezéssel szembeni követelményként megengedett veszélyességi gyakoriságot vagy valószínűséget határoznak meg (THR – Tolerable Hazard Rate). Ez a követelmény valamely kockázatelemzés eredménye – figyelembe kell venni a funkció nemteljesülés következményét és a társadalom kockázattűrő képességét, és ezek alapján a megengedett funkció nemteljesülési gyakoriság meghatározható. A leggyakrabban alkalmazott kockázatelemzési eljárások: ALARP, GAMAB, MEM.

Ugyanakkor fontos felismerés, hogy a funkció nemteljesülésért vagy a hardver véletlenszerű meghibásodása, vagy az egyes életciklus-fázisokban elkövetett emberi hibák (hibás specifikáció, hibás szoftver, hibás ellenőrzési eljárás stb.) a felelősek. Amíg a hardver hibák gyakorisága relatíve jól számszerűsíthető és ellenőrizhető, az emberi hibák számszerűsítése nem megoldott. Éppen ezért a THR követelményt a hardver meghibásodásokkal szemben támasztják (és pl. a tervező ez alapján dönt a beépítendő elemek elvárt megbízhatóságáról, illetve a beépítendő redundancia fokáról), majd ez alapján meghatároznak egy másik biztonsági követelményt, a biztonságintegritási szintet (Safety Integrity Level, SIL), amely a teljes életciklussal szemben támaszt követelményeket. Minél alacsonyabb THR érték az előírás (minél kisebb a megengedett funkciótévesztési gyakoriság), annál magasabb a biztonságintegritás szintje. Négy szint létezik, SIL1…SIL4 között, mindegyik szorosan hozzárendelve egy adott THR tartományhoz. (Meg kell jegyezni, hogy léteznek olyan kockázatelemzési eljárások, amelyek közvetlenül a SIL meghatározására irányulnak, pl. kockázati gráf módszere).

2. Teljes életciklusban való gondolkodás

Az elkészítendő rendszer biztonságát alapjaiban érintik a teljes életciklus egyes fázisaiban végrehajtott tevékenységek, hiszen az emberi eredetű hibák bármikor elkövethetőek. Éppen ezért fontos az életciklus tervezése, az egyes fázisokkal szembeni követelmények, a bemeneti információ és az előálló eredmények előzetes meghatározása, valamint az életciklus szigorú betartása, ami az egyes fázisok egymásutániságát, valamint a fázisok közötti átlépés lehetőségeinek szabályozását jelenti.

A teljes életciklus nem csak a rendszer létrehozását, de a működtetést, a majdani módosításokat, illetve a leszerelést is tartalmazza, hiszen az elvárt biztonságot a teljes élettartam során biztosítani kell, és az üzemeltetés, karbantartás ezt nagymértékben képes befolyásolni.

3. A részt vevők szakképzettsége és függetlensége

Az emberi hibák elleni védekezés egyik lehetősége a megfelelő képzettségű személyzet alkalmazása, a másik a többszörös, független személy vagy szervezet által elvégzett ellenőrzések végrehajtása. Az ellenőrzések szintje kettős: verifikálás, vagyis egy fázis eredményeinek a fázis bemeneti információihoz történő visszaellenőrzése (a következő fázisba átlépni csak a sikeres verifikálás után lehet); valamint validálás, vagyis a már elkészült rendszer a kiinduló specifikációhoz történő visszaellenőrzése. Minél magasabb a SIL értéke, annál nagyobb függetlenség biztosítása szükséges.

4. Az egyes életciklus-fázisokban alkalmazott módszerek és eljárások meghatározása

Az emberi hibák kiszűrésének másik módja a helyes eredményt garantáló módszertanok alkalmazásának kényszere. A módszereket a szabvány rendre az egyes életciklus-fázisokhoz rendeli, különböző súlyokkal: M-kötelezően alkalmazandó; HR-nagyon ajánlott; R-ajánlott; NR-nem ajánlott. Magasabb SIL értékekhez több és mélyebb módszertan megkövetelése tartozik.

5. Dokumentáltság

Az életciklus során nagyon sok információnak kell áramlania az egyes fázisok, illetve az egyes fázisokban részt vevők között. Tipikus hibaforrás, amikor egy már megszerzett információt egy későbbi időpontban nem vesznek figyelembe. Ennek kiküszöbölése érdekében az egyes fázisokhoz elvárt dokumentáció egyes elemeit, valamint azok fő tartalmát a szabvány rögzíti.

A fenti öt pont köré épül fel a szabvány olyan módon, hogy az első kötet az általános kérdéseket, a második a hardver vonatkozásokat, míg a harmadik a szoftver vonatkozásokat tárgyalja. A negyedik kötet definíciókat tartalmaz, az ötödik ajánlásokat a kockázatelemzésre vonatkozóan, míg a hatodik és a hetedik kötet a második és a harmadik alkalmazási útmutatója.

MSZ-EN 50126 Vasúti alkalmazások – a megbízhatóság, az üzemkészség, a karbantarthatóság és a biztonság (RAMS) előírása és bizonyítása

MSZ-EN 50128 Vasúti alkalmazások – Távközlési, adatfeldolgozó és biztosítóberendezési rendszerek – Szoftverek vasúti vezérlő és ellenőrzőrendszerekhez.

MSZ-EN 50129 Vasúti alkalmazások – Távközlési, adatfeldolgozó és biztosítóberendezési rendszerek. Elektronikus biztosítóberendezések.

A három egyedi szabvány az MSZ-EN 61508 vasúti ágazatra alkalmazott megfelelője, jól láthatóan a 61508-ból kiindulva.

Az 50126 a teljes vasúti rendszerre vonatkozik, beleértve a járműveket, pályát és vezérlőberendezéseket – gyakorlatilag megfeleltethető a 61508-1-nek.

Az 50129 már csak az elektronikus jelző és biztosítóberendezésekre vonatkozik, gyakorlatilag megfelel a 61508-2-nek, míg az 50128 a szoftver kérdéseket taglalja, megfelelve a 61508-3-nak.

A három szabvány az összes lényegi kérdésben azonos a 61508-al (életciklus, THR és SIL, függetlenség, módszerek és dokumentáltság), lényegi előrelépést talán egyedül a függetlenségi szinteknél bevezetett assessor (biztonságértékelő – a szabvány szerint mindenképpen független szervezet) jelent.

IAEA Software for Computer Based Systems Important to Safety in Nuclear Power Plants – Safety Guide, NS-G-1.1

A Nemzetközi Atomenergia Ügynökség a státuszát meghatározó alapdokumentum alapján jogosult a nukleáris biztonság témakörében, az emberi élet és anyagi javak védelmének céljából nukleáris biztonsági szabványok kibocsátására. E szabványok három alkategóriába kerülnek besorolásra:

• Safety Fundamentals – a biztonság alapjai;

• Safety Requirements – biztonsági követelmények;

• Safety Guides – biztonsági ajánlások.

A szabványok egyike sem kötelező a tagországokra nézve, de – az IAEA megfogalmazása szerint „adoptálhatják azokat”. Kötelezőek azonban a szabványok az IAEA-ra nézve, illetve az olyan esetekben, amikor egy adott tevékenységben az IAEA is részt vesz.

A dokumentum célja a biztonság bizonyításához szükséges tények és dokumentumok összeállításának elősegítése az életciklus minden egyes fázisában. Az ajánlás minden típusú szoftverre alkalmazható, legyen az már létező, firmware jellegű vagy célszoftver. Az ajánlás a szoftverek fejlesztőinek, független biztonsági elemzőinek és jóváhagyóinak (engedélyezőinek) készül.

Az ajánlás két részre tagolható: az első részben (2-4 fejezetek, az 1. fejezet a bevezetés) a szoftver létrehozását megelőző, a rendszertervezéshez kapcsolódó, illetve általános tevékenységekkel kapcsolatos ajánlások fogalmazódnak meg, a második részben (5-15 fejezetek) az egyes életciklus-fázisokhoz kapcsolódó konkrét ajánlások fogalmazódnak meg. Az egyes életciklus-fázisoknál megtalálhatóak a tényleges ajánlások (Recommendations), valamint az előállítandó dokumentumokra vonatkozó részek (Documents).

Már a fentiekből is kiderül, hogy az ajánlás életciklus-szemléletű, vagyis a biztonság elérését, valamint a biztonság szintjének bizonyítását az életciklus minden fázisában alá kell támasztani.

Az életciklus-fázisokat, valamint azok kapcsolatát az 1. ábra szemlélteti (forrás az ajánlás- az ábrán az életciklus-fázisok neve utáni szám a fázissal foglalkozó fejezetet jelöli).

Az ajánlás által lefedett életciklus fázisok:

A számítógépes rendszerre vonatkozó követelmények meghatározása (Computer System Requirements)

• A számítógépes rendszer tervezése (Computer System Design)

• A szoftverkövetelmények meghatározása (Software Requirements)

• A szoftver tervezése (Software Design)

• A szoftver megvalósítása (Software Implementation)

• A HW-SW rendszer integrálása (Computer System Integration)

• Installálás és rendszerintegrálás a teljes rendszer vonatkozásában (Installation and System Integration)

• Üzemeltetés és módosítások (Operation and post-delivery modifications)

 Az ábra a fázisokon kívül az alábbi tevékenységeket tartalmazza:

• Verifikálás – egy fázis eredményének és a fázis kiinduló követelményeinek összevetése (Verification)

• Validálás – a teljes folyamat eredménye és a kiinduló követelmények összevetése

• Üzembe helyezési tevékenységek – beleértve a teljes rendszer követelménymegfelelőségének vizsgálatát (Commissioning)

 1. ábra: életciklus az IAEA NS-G-1.1 szerint

A számítógépes rendszerre vonatkozó követelmények meghatározása

A számítógépes rendszer funkcionális és nem funkcionális követelményeinek (pl. elválasztások szükségessége, diverzitás stb.) meghatározása – valójában a rendszer elvárt viselkedését írja le. Integráns része a rendszer kapcsolatainak (interfészeinek) pontos leírása – ebben a fázisban azonban csak funkcionális szinten.

 Néhány ajánlás a követelményekkel kapcsolatban: A követelményeknek megvalósítás-függetleneknek kell lenniük. A leíráshoz célszerű jól definiált formalizmust alkalmazni. A követelményeknek az életciklusban részt vevők számára érthetőeknek, valamint ellenőrizhetőeknek kell lenniük. A követelményrendszert ellenőrizni (validálni) szükséges.

 A számítógépes rendszer tervezése

A számítógépes rendszer kiinduló terve a követelmények szisztematikus allokálásából származik. Értelemszerűen a rendszernek a követelményekben leírt összes interfészt biztosítania kell.

Amennyiben a biztonsági rendszer nem biztonsági funkciókat is megvalósít, elemezni kell, vajon a teljes rendszernek biztonságinak kell-e lennie. A megfelelő megbízhatóság elérése érdekében a lehetőségek szerint a nem biztonsági funkciókat különállóan kell megvalósítani. A szétválasztás után a nem biztonsági funkciókat kevésbé szigorú és magasabb erőforrás-kihasználású módszerekkel lehet megvalósítani.

A véletlenszerű meghibásodások ellen redundanciával lehet védekezni, ez esetben azonban a közös okú hibákat figyelembe kell venni. Az egymásra-hatásokból származó hibák hatásait elektromos és fizikai függetlenség kialakításával kell biztosítani. A közös okú hibák ellen diverzitással lehet védekezni.

A rendszernek hibafelfedő képességekkel kell rendelkeznie. Ha egy hiba csekély súlyú a biztonsági reakció kiváltásához, akkor az operátorokat kell értesíteni a hibáról.

A szoftverkövetelmények meghatározása

A szoftverkövetelmények a rendszerkövetelmények azon része, amelyet szoftveres módon kívánnak megvalósítani. Így a rendszerkövetelmények vagy hardver, vagy szoftver követelményekké válnak. A szoftver követelmények között olyanok is szerepelnek, amelyeket a hardver megvalósítás indukál, így a szoftverkövetelmények meghatározása a hardver tervezéssel szorosan összekötött folyamat.

Amennyiben a rendszerkövetelmények kellően részletesek és kellően formalizáltak, valamint a kód létrehozása automatikus kódgenerátorok segítségével történik, a szoftverspecifikáció létrehozása nem szükséges.

A szoftver tervezése

A szoftver tervezése az a folyamat, amikor a szoftverkövetelményeket együttműködő szoftver-modulokká alakítják, megadva az egyes modulok specifikációját. A tervezésnek bizonyítható módon az összes követelményt le kell fednie. A szoftver architektúrája és a modulokra bontás szorosan összefügg. Az architektúra tartalmazza az összes folyamatot, adattípust és kommunikációs csatornát.

A szoftver megvalósítása

A fázis végére előáll a forrás- és tárgykódú szoftver, amely teljesíti a specifikációt.

A létrejövő kódnak ellenőrizhetőnek kell lennie. Amennyiben az ellenőrzés manuálisan, szakember által történik, a kódnak olvashatónak és kellően magyarázottnak kell lennie.

Mivel a kód első verziója ritkán megfelelő, a verziók azonosítására, a verziókontrolra gondot kell fordítani.

 Az alkalmazott programnyelvnek szintaktikailag és szemantikailag teljesen dokumentáltnak kell lennie. A géporientált nyelvekkel szemben előnyben kell részesíteni a folyamatorientált nyelveket.

A HW-SW rendszer integrálása

A fázis az alábbi részekből áll:

• ·        A szoftver hardverre töltése,

• ·        A HW-SW interakció tesztelése,

• ·        SW működőképesség teszt

 Az integráció terveinek a rendszerkövetelményekből kell származniuk. Az integrációs teszteket végrehajtóknak a szoftver készítőitől eltérő személyeknek kell lenniük. Amennyire lehetséges, a végrehajtott teszteknek fehérdoboz-teszteknek kell lenniük.

Installálás és rendszerintegrálás a teljes rendszer vonatkozásában

A már kitesztelt rendszert az üzemeltetés helyére szállítva és az ottani teljes rendszerbe integrálva megvalósul a végső integráció. Erre csak a számítógépes rendszer sikeres validációja után kerülhet sor. A teljes rendszerintegráció során kiterjedt próbaüzemet célszerű végrehajtani.

Összefoglalóan megállapítható, hogy az ajánlás:

• ·        teljes életciklusban gondolkodik, az életciklus tervezendő.

• ·        az egyes életciklus-fázisokhoz módszertant rendel (itt ajánlások formájában, és nem egyedi, már létező eljárások és módszerek meghivatkozásával, hanem egyedi tanácsokkal),

• ·        bizonyos szintű résztvevői függetlenséget ír elő, bár erre jelentős hangsúlyt nem helyez,

• ·        utal a biztonsági szintek alkalmazásának lehetőségére, bár erre súlyt nem helyez.