Autóipari beágyazott rendszerek Kockázatelemzés 1
Biztonságkritikus rendszer Beágyazott rendszer Aminek hibája Anyagi vagyont, vagy Emberéletet veszélyeztet Tipikus példák ABS, ESP, elektronikus szervokormány 2
Elvárt megbízhatóság Példa: IEC61508 4 biztonsági szintet különböztet meg A legmagasabb (SIL4) szinten: <10-8 hiba/óra ~11000 év hiba nélkül!!! Teszteléssel lehetetlen bizonyítani! Szisztematikus analízisre van szükség Fontos: autóiparban nincs abszolút 0 cél! 3
Biztonságkritikus rendszer Fontos a szisztematikus fejlesztés Tervezés Analízis Ellenőrzés Különböző szabványok IEC 61508 általános szabvány ISO 26262 autóipari szabvány (2011) 4
Alapfogalmak Rendszer típusok Fail silent hiba esetén lekapcsolja a kimenetét Csak ha van egyéb tartalék (pl. ABS) Fail safe hiba esetén biztonságos állapotba viszi a rendszert Példa: vasúton minden jelző vörös Fail operational hiba esetén is fenntartja a szolgáltatást (esetleg degradálva) Belső tartalékkal rendelkezik a hiba kompenzálására 5
Honnan jönnek a hibák? Fejlesztési folyamat Specifikációs hibák Tervezési hibák Implementációs hibák à verifikáció és validáció szükséges Működés közben Hardver hibák Konfigurációs / környezeti hibák Kezelői hibák à hibatűrés szükséges 6
Fejlesztési hibák Statisztikák alapján Tipikus kódméret 10-1000 kloc Fejlesztési idő 0,1-0,5 mérnökév / kloc (nagyméretű SW) 5-10 mérnökév / kloc (kriitkus SW) Hiba eltávolítás 45-75% ráfordítás Hibasűrűség változása 10-200 hiba / kloc a fejlesztés során 0,1 10 hiba /kloc a maradó hiba (ellenőrzés után) 7
Szoftver hibák Probléma 1-10 hiba / kloc marad a rendszerben Nem csökkenthető 0-ra A költségek exponenciálisan nőnek A hiba rejtőzködési ideje néhány naptól sok-sok évig változhat Megoldás A rendszer szoftver hiba esetén is biztonságos kell, hogy maradjon 8
Verifikáció és validáció Verifikáció (igazolás) A fejlesztési fázisok összhangjának ellenőrzése A tervek/implementáció és a specifikációja közötti megfelelés ellenőrzése Objektív, automatizálható folyamat Hibamodell: tervezési, implementációs hibák Validáció (érvényesítés) A fejlesztés eredményeinek ellenőrzése A kész rendszer és a felhasználói követelmények, elvárások összevetése Szubjektív (elfogadási ellenőrzés) Hibamodell: követelmények hiányosságait is feltárja 9
Rendszerek értékelése Biztonsági szempontból Mekkora kárt okoz a hibás működés? Mekkora a hiba esélye? Milyen lehetőség van a hiba kompenzálására? à hazard analysis (kockázatelemzés) 10
Kockázatelemzés ISO26262 Szisztematikus keretrendszer A rendszer minden funkciójára el kell végezni Több értékelési szempont van Következményes súlyossága Előfordulás valószínűsége Kezelhetőség Előre definiált szintekkel 11
Kockázatelemzés Következményes súlyossága (severity) osztályozás S0 S1 S2 S3 Jelentés Nincs személyi sérülés Könnyű vagy közepes súlyosságú sérülések Életveszélyes sérülések (túlélés valószínű) Életveszélyes sérülések (túlélés nem valószínű), halálesetek 12
Súlyosság meghatározása Baleseti statisztikákból Hasonló helyzetek vizsgálata Nem csak a sofőr számít! Többi utas Más járművek utasai Gyalogosok A jármű relatív mérete is számít Autó vs. vonat Autó vs. kerékpár 13
Kockázatelemzés Kitettség (exposure) osztályozás E0 E1 E2 E3 E4 Jelentés Elképzelhetetlen Nagyon alacsony valószínűségű - Ritkábban, mint évente Alacsony valószínűségű - Évente néhányszor Közepes valószínűségű Havonta Nagy valószínűségű - Szinte minden utazáskor 14
Kitettség meghatározása Szisztematikus módszerek a hibamódok meghatározására Hibafa FMEA Ezekkel nagyságrendi becslés is készíthető a valószínűségre Néha nehéz a komponens hibákból rendszer szintű hibát megállapítani Szakértők Mindig a legrosszabb esetet kell figyelembe venni A kitettség kontextusfüggő Függ a célpiactól Függ a felhasználási körülményektől 15
Kockázatelemzés Kezelhetőség (controllability) osztályozás C0 C1 C2 C3 Jelentés Mindig kezelhető vagy nem befolyásolja a biztonságot Egyszerűen kezelhető a résztvevők 99%-a képes kezelni Általában kezelhető a résztvevők 90%-a képes kezelni Nehezen kezelhető, vagy kezelhetetlen a résztvevők kevesebb, mint 90%-a képes kezelni 16
Kezelhetőség meghatározása Vezetési tesztek Probléma C0, C1 szinthez túl sok próba kellene C3 szinthez nem kell semmi (nem feltételez semmit) Fontos a célközönség is 17
Biztonság-integritási szint ISO26262 A fenti értékelés alapján biztonsági integritási szintet (safety integrity level) határozunk meg ASIL A D Ha nincs biztonsági relevancia, a szint QM quality management A szabvány táblázatot ad a szint meghatározásához 18
ASIL szintek 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 19
ASIL szintek 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 Ha legalább az egyik szempont 0-s, a szint biztosan QM E4 A B C S3 E1 QM QM A E2 QM A B E3 A B C E4 B C D 20
Analízis eredménye Funkciónként meghatározta A veszélyeket Azok súlyosságát És ASIL szintjét Biztonsági cél (safety goal) Minden azonosított veszélyhez meg kell határozni olyan célokat, melyekkel biztosítható a veszély kezelése Ezen célok öröklik az ASIL szintet Ha több veszélyt is lefednek, akkor a legmagasabb szintet Meg kell határozni a beavatkozás legnagyobb megengedett késleltetését is (fault tolerant time interval) Meg kell határozni a biztonságos állapotot 21