Biztonságkritikus rendszerek

Átírás

1 Biztonságkritikus rendszerek Biztonságkritikusnak nevezzük azon rendszereket, melyek hibás működése jelentős anyagi kárt okoz, vagy emberek testi épségét, életét veszélyezteti. Autóipari rendszerek esetében tipikusan ilyen például az elektronikus szervókormány, az ABS, ESP, és az adaptív tempomat rendszerek. Más alkalmazási területen is találhatunk ilyen rendszereket, például nukleáris és vegyi üzemek vezérlőrendszerei, orvosi rendszerek, repülésirányító (földi), és vezérlő (fedélzeti) rendszerek, vagy a vasúti biztosító berendezések. A kritikus rendszerek szisztematikus tervezésének és analízisének támogatására alkották meg az IEC61508 [8] szabványt, mely általános irányelveket és módszereket tartalmaz területtől függetlenül. A szabvány autóipari területre specializált változata az ISO Kockázatelemzés Az egyik legfontosabb feladat egy új rendszer fejlesztésének kezdetekor annak meghatározása, hogy a rendszer milyen kockázatot jelent az élet- és vagyonbiztonság szempontjából. Az ISO [9] szabvány ezen analízis elvégzésére egy szisztematikus keretrendszert határoz meg. Az analízist a célrendszer minden funkciójára el kell végezni. Egy-egy funkcióhoz meg kell határozni a lehetséges hibamódokat, majd a hibák által okozott kockázatot. A kockázatokat több szempont szerint kell értékelni: a) a következmények súlyossága szerint, b) a kitettség (előfordulás valószínűsége) szerint, és c) a (vezető általi) kezelhetőség szerint. A szabvány minden szemponthoz egy előre definiált értékkészletet ad meg, ezekből kell a megfelelőt kiválasztani az adott elemhez. Az alábbi táblázatok megadják a lehetséges értékeket: osztályozás S0 S1 S2 jelentés Nincs személyi sérülés Könnyű vagy közepes súlyosságú személyi sérülések Életveszélyes sérülések (túlélés valószínű) S3 Életveszélyes sérülések (túlélés nem valószínű), halálesetek 3. táblázat A kockázat súlyosságának besorolása osztályozás jelentés E0 Elképzelhetetlen E1 Nagyon alacsony valószínűségű E2 Alacsony valószínűségű E3 Közepes valószínűségű E4 Nagy valószínűségű 4. táblázat A kockázat kitettségének besorolása

2 osztályozás C0 C1 C2 C3 jelentés 5. táblázat A kockázat kezelhetőségének besorolása Mindig kezelhető / nem befolyásolja a biztonságot Egyszerűen kezelhető Általában kezelhető Nehezen vagy nem kezelhető A fenti kategóriák hozzárendelése után meg kell határozni az egyes kockázatok biztonsági integritási szintjét, azaz azt, hogy a teljes rendszer szempontjából mennyire kritikusak. Ezt a szabvány az ASIL (Automotive Safety Integrity Level) kategóriák bevezetésével támogatja. Fontos megjegyezni, hogy az ASIL-ben az automotive megkülönböztetés azért került bele, mert az IEC61508 szabvány SIL szintjeihez képest más a jelentésük (az ottani legsúlyosabb szintet az autóipar nem használja az általában több tucat ember halálát és kiemelkedően nagy anyagi kárt jelentene). Az ASIL szintek A és D között értelmezettek, illetve a QM (quality management) szinttel jelezzük, ha egy funkciónak nincs biztonsági relevanciája. A különböző kockázat-besorolások alapján az alábbi táblázat szerint kell meghatározni a az ASIL szintet: C1 C2 C3 S1 E1 QM QM QM E2 QM QM QM E3 QM QM A E4 QM A B S2 E1 QM QM QM E2 QM QM A E3 QM A B E4 A B C S3 E1 QM QM A E2 QM A B E3 A B C E4 B C D 6. táblázat Az ASIL szint meghatározása Ha az S,E,C besorolások közül legalább az egyik 0, akkor az integritási szint QM, tehát az adott kockázatnak nincs biztonságossági relevanciája. Fontos kérdés, hogy hogyan lehet meghatározni a hibamódokat, illetve a különböző mérőszámokat a gyakorlatban. A hibamódok tekintetében sok szisztematikus módszer ismert (hibafa, hibamód és hatás analízis, stb.), de akár informálisan is (például szakértők bevonásával) is meg lehet határozni. A kitettség esetén figyelembe kell

3 venni, hogy milyen körülmények között fordulhat elő a hiba (például csak jeges úton), majd a jármű tulajdonságainak, célközönségének, célterületének figyelembe vételével lehet meghatározni, hogy az élettartam hány százalékában működik veszélyes körülmények között (például egy európai piacra szánt jármű nagyobb valószínűséggel kerül jeges útra, mint egy, az afrikai piacra szánt). A súlyosságot egyrészt baleseti statisztikákból, másrészt szimulációkkal lehet meghatározni. A kezelhetőség meghatározásának egyik leginkább elfogadott módja a járműteszt: zárt tesztpályán hibainjektálással létrehozzák a veszélyes szituációt, és vizsgálják, hogy a tesztvezető milyen eredményességgel képes azt elhárítani. Természetesen itt különbséget kell tenni a vezetők neme, kora, képzettsége, várható koncentrálóképessége szerint is. A mértékek meghatározásához a szabvány is nyújt - nem kötelező - példákat. Például E1 kategóriába soroljuk az évente várhatóan kevesebb mint egyszer bekövetkező eseményeket. Ilyen például a vontatás (vontató autóval), vagy az, hogy egy vasúti átjáróban fullad le valaki a járművel. Minden azonosított (legalább ASIL A szintű) veszélyhez meg kell határozni olyan biztonságossági célokat (safety goal), melyekkel biztosítható az adott veszély kezelése. Ezen célok öröklik a besorolást a veszélytől. Ha egy cél több veszélyt is lefed, akkor a legnagyobb ASIL szintet örökli. A célokhoz meg kell határozni a hibatűrési időt (fault tolerant time interval), mely a beavatkozás legnagyobb késleltetését jelenti, valamint az elérendő biztonságos állapotot (safe state). Szervókormány esetén például a blokkolást előidőző hibák esetén az idő 100ms nagyságrendű, és az elérendő biztonságos állapot a rendszer kikapcsolása (ebben az esetben nincs rásegítés, de a normál mechanikus rendszerrel a jármű - nagyobb erő befektetésével - vezethető marad). Funkcionális biztonságossági koncepció A funkcionális biztonságossági koncepciónak (functional safety concept) a szerepe az ISO26262 szerinti fejlesztésben a biztonságossági követelmények levezetése a biztonságossági célokból. A követelményeket ezek után az előzetes rendszerarchitektúra egyes elemeihez kell rendelni, azaz meg kell határozni mely rendszerkomponens(ek) felelős(ek) egy követelmény megvalósításáért. A koncepciónak része kell legyen a rendszer hibatűrési mechanizmusainak kialakítására szolgáló stratégia is, mely az alábbi kérdésekre adja meg a választ: hiba detektálás és mérséklés módszerei átmenet biztonságos állapotba hibatűrési mechanizmusok kialakítása, hogy egy hiba ne vezethessen a biztonságossági célok megsértéséhez, és a rendszert biztonságos állapotban lehessen tartani (degradációval vagy anélkül) Hibadetektálás és a vezető informálása, hogy a kitettségi időt minimalizálni lehessen (szerviz lámpa, stb.) vezérlő logika, hogy meg lehessen határozni a több különböző helyről érkező (hibákkal kapcsolatos) értesítések közül a legfontosabbakat A stratégia meghatározása után következik a biztonságossági követelmények meghatározása. Ennek során bizonyos szabályokat be kell tartani a szabvány szerint: A követelményeket a célokból és a biztonságos állapotokból kell levezetni Minden biztonságossági célhoz legalább egy követelményt fel kell venni Minden követelményt a következő információk figyelembe vételével kell megfogalmazni

4 üzemmódok hibatűrési idő biztonságos állapot, ha a követelmény lehetővé teszi a biztonságos állapotba való jutást szükség-üzemmód időtartama funkcionális redundancia (pl. többszörözés) Meg kell határozni a vezető értesítési és degradációs koncepciót Ha a biztonságos állapotot nem lehet azonnali lekapcsolással elérni, meg kell határozni egy szükség-üzemmódot Ha a biztonsági célok feltételezik a vezető, vagy más veszélyeztetett személy együttműködését, a koncepciónak tartalmaznia kell ezeket a feltételezéseket. Meg kell határozni a rendszer biztonsági architektúráját is. Ez legtöbbször blokkdiagram formájában történik, mely kiemeli a redundanciákat, illetve a független vezérlési utakat, melyekre a hibatűrési mechanizmusok építenek. A biztonsági architektúra egyes elemeihez hozzá kell rendelni az általuk megvalósítandó biztonságossági követelményeket. A rendszerelemek öröklik a hozzájuk rendelt követelmények ASIL szintjét (illetve ezek közül a legmagasabbat). Ez az adott elem kifejlesztéséhez fontos bemenő információ. Végül az elkészült koncepciót és követelményeket verifikálni kell, hogy meggyőződhessünk arról, hogy konzisztensek a biztonságossági célokkal, illetve, hogy minden célt megfelelően lefednek-e. Emellett a követelményekben megfogalmazott előírások és megoldások hatékonyságát is ellenőrizni kell erre a célra használhatunk prototípusokat, szimulációkat, vagy részletes analízist. ASIL dekompozíció A biztonsági architektúra minden rendszerelemre meghatároz egy ASIL szintet, melyet el kell érni az adott elem megvalósítása során. Minél magasabb a szint, annál költségesebb az elem kifejlesztése. Az ISO26262 szabvány lehetővé teszi azonban, hogy egy magas szintű elemet több, alacsonyabb szintű, de független elemmel helyettesíthessünk. Ez nem feltétlenül jelenti a klasszikus moduláris redundancia bevezetését (ahol több egyforma egységet vezetünk be), hanem lehet két vagy több, különböző egység által biztosított redundancia is (például főprocesszor és felügyeleti processzor, ahol mindkettő képes a biztonságos állapotba kapcsolni a rendszert). A szabvány az alábbi dekompozíciókat támogatja: ASIL D ASIL C + ASIL A ASIL D ASIL B + ASIL B ASIL D ASIL D + QM ASIL C ASIL B + ASIL A ASIL C ASIL C + QM ASIL B ASIL A + ASIL A ASIL B ASIL B + QM ASIL A ASIL A + QM ISO26262 szerinti fejlesztési folyamat Az ISO szabvány meghatározza azt, hogy az egyes rendszerelemek fejlesztésekor milyen tevékenységeket kell elvégezni, illetve milyen termékeket (work product) kell előállítani.

5 37. ábra Termékfejlesztés az ISO szabvány szerint Az ábrán látható, hogy a termékfejlesztést három szinten definiálja a szabvány (a különböző tevékenységek előtti számok a szabvány vonatkozó fejezetét jelölik), és mindegyik szint az úgynevezett V modell szerint szerveződik. A V modell bal szára a szintézis vagy tervezés jellegű tevékenységeket tartalmazza, míg a jobb oldala az analízis vagy tesztelés jellegű tevékenységeket definiálja. Minden szinten a bal oldalon egy adott elem (például a szoftver architektúra) fejlesztése történik, míg a másik oldalon annak ellenőrzése. A fejlesztés a rendszer szinten kezdődik. Itt a biztonságossági koncepció alapján elkészülnek a műszaki biztonságossági követelmények, és megtörténik a rendszer architektúrájának megtervezése. Ezen tevékenység során azonosítják a rendszert alkotó hardver és szoftver komponenseket, melyeket ezután külön lehet kezelni. A hardverfejlesztés során az egyes hardver komponensek fejlesztése és tesztelése történik meg, külön figyelembe véve a hardver specifikus problémákat (véletlen hardver hibák hatásának vizsgálata). Hasonlóan a szoftverfejlesztés során a szoftver specifikus lépések kerülnek végrehajtásra. A rendszer integrálása során az egyes komponensek együttműködését is ellenőrzik, az integrációs tesztek és a biztonságosság verifikálása és validálása során. Végül a rendszer készen áll a gyártásra.

6 A szabvány nem csak az egyes fejlesztési lépéseket definiálja, hanem megadja a különböző integritási szintek esetén használandó módszereket is. Példaként az alábbi ábrán a szoftver egységteszteléshez ajánlott módszerek láthatóak. 38. ábra Szoftver egységteszteléshez használható módszerek A ++ erősen ajánlott, míg a + ajánlott besorolást jelent (az ábrán nem látható O jelölés a nem ajánlott kategória lenne). Látható, hogy vannak olyan teszt típusok, melyeket minden szinten szinte kötelezővé tesz a szabvány, míg bizonyos teszteket (pl. 1d) csak magasabb szinten. A megadott módszerekből a használtak kiválasztása az adott rendszer sajátosságainak megfelelően a résztvevők feladata, de például az erősen ajánlott módszereket (főleg magasabb szinten) célszerű alkalmazni, hiszen egyébként erős érvrendszert kell felépíteni annak alátámasztására, hogy a módszerek elhagyása ellenére is megfelelő biztonsági szintet értek el a fejlesztés során. Gyártás és üzemeltetés Mivel egy biztonságkritikus rendszer biztonságosságát nem csak a fejlesztés befolyásolja, a szabvány kiterjed a gyártás, üzemeltetés, és javítás fázisaira is. Ezek során meg kell határozni a gyártás és a gyártás-ellenőrzés folyamatát, illetve az engedélyezett konfigurációkat (konfigurálható esetben). Szintén követelményeket kell adni a használt gépek minőségére és ellenőrzésére vonatkozóan, illetve a kezelőszemélyzet oktatásával kapcsolatban is. Fontos a különböző elemek összeszerelésének pontos specifikálása és ellenőrzése. Ilyen például a megfelelő szoftver és a kalibrációs értékek programozása a hardverre. Ki kell dolgozni a gyártáskori ellenőrző lépéseket és azok sorrendjét, illetve meg kell határozni az ezekhez szükséges tesztberendezéseket is. Ezek fejlesztése és konfigurálása sok esetben kritikus a gyártott rendszer biztonságosságának szempontjából. Az üzemeltetéssel kapcsolatban fontos, hogy a felhasználó megfelelő tájékoztatást kapjon a rendszer funkciójáról, a várható interakciókról, és a hiba esetén tapasztalható viselkedésről (degradáció, vészjelzések). Ugyancsak definiálni kell az elvárt felhasználói viselkedést is. Fontos kiemelni az eddig megszokott működéshez képesti újdonságokat (például egy automatikus kézifék máshogy működik, mint a hagyományos).

7 A karbantartással kapcsolatban definiálni kell a karbantartási intervallumokat, a szükséges ellenőrzéseket, karbantartási feladatokat, a cseredarabok tárolását, szerelését. Végül meg kell határozni, milyen eljárást kell alkalmazni a cserélt (hibás) darabok, vagy a jármű szétbontása során kinyert elemek megsemmisítésekor. A légzsákok kiszerelése és deaktiválása például jelentős kockázatot rejt. Biztonságossági szempontból a termékhez tartozó végső dokumentum a safety case, vagy biztonságossági jelentés. Ennek célja annak megmutatása (bizonyítékokkal alátámasztva), hogy a rendszer biztonságosnak tekinthető egy adott környezetben. Ez általában egy harmadik személy számára szolgál alapdokumentumként, aki a rendszer fejlesztésében nem vett részt. A safety case ezért világosan, tömören kell, hogy tartalmazza mindazon információkat, melyek alapján a biztonságosság megítélhető. Mivel egyetlen rendszer sem lehet abszolút biztonságos, a cél annak megmutatása, hogy a rendszer elég biztonságos a környezet és a szabványok által meghatározott követelmények szerint. A safety case érveléseket (safety argument) tartalmaz, melyek megmutatják, hogy a rendelkezésre bocsátott bizonyítékok alapján a rendszer biztonságossági céljai és követelményei teljesülnek. Az érvelések lehet termékre vonatkozóak (a tárgya egy műszaki megoldás működése), illetve folyamatra vonatkozóak (a tárgya egy, a fejlesztés során alkalmazott előírás vagy folyamat). Természetesen a safety case-t folyamatosan szinkronizálni kell a rendszerrel, amire vonatkozik, és el kell fogadtatni az illetékes (független) szakértőkkel. Összességében tehát elmondhatjuk, hogy az ISO szabvány egy teljes életciklust átfogó követelményrendszert ad autóipari kritikus rendszerek fejlesztésére, gyártására, és üzemeltetésére.