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 Jelentés S0
Nincs személyi sérülés
S1
Könnyű vagy közepes súlyosságú sérülések
S2
É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 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 Jelentés E0
Elképzelhetetlen
E1
Nagyon alacsony valószínűségű - Ritkábban, mint évente
E2
Alacsony valószínűségű - Évente néhányszor
E3
Közepes valószínűségű – Havonta
E4
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 Jelentés C0
Mindig kezelhető vagy nem befolyásolja a biztonságot
C1
Egyszerűen kezelhető – a résztvevők 99%-a képes kezelni
C2
Általában kezelhető – a résztvevők 90%-a képes kezelni
C3
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 S1
S2
S3
C1
C2
C3
E1
QM
QM
QM
E2
QM
QM
QM
E3
QM
QM
A
E4
QM
A
B
E1
QM
QM
QM
E2
QM
QM
A
E3
QM
A
B
E4
A
B
C
E1
QM
QM
A
E2
QM
A
B
E3
A
B
C
E4
B
C
D
19
ASIL szintek S1
S2
S3
C1
C2
C3
E1
QM
QM
QM
E2
QM
QM
QM
E3
QM
QM
A
E4
QM
A
B
E1
QM
QM
QM
E2
QM
QM
A
E3
QM
A
B
E4
A
E1
QM
E2
QM
E3
A
B
C
E4
B
C
D
B Ha legalább az egyik QM 0-s, a szint szempont biztosan QM A
C A B
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
