Biztonságkritikus rendszerek

Átírás

1 Biztonságkritikus rendszerek Rendszertervezés és -integráció előadás dr. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék BME-MIT

2 Mik azok a biztonságkritikus rendszerek? A hibázás, azaz a specifikáció nem teljesítése balesethez, környezeti kárhoz vezethet Miért kell velük külön foglalkozni? o Speciális veszély analízis és követelmények Mely funkciók, hibák vezethetnek balesethez? Milyen biztonsággal teljesíthetők a követelmények? o Speciális fejlesztési megoldások szükségesek Redundáns architektúra, hibatűrés Kockázatcsökkentési módszerek Biztonságigazolás, szisztematikus tesztelés,... o Szabványok, előírások vonatkoznak a fejlesztésre IEC 61508: DO 178B: EN 5012x: ISO 26262: Programozható elektronikai rendszerek Repülőgép-fedélzeti beágyazott rendszerek Vasúti jelzőrendszerek Gépjármű elektronikai rendszerek biztonsága BME-MIT 3.

3 Baleseti példák A balesete Varsóban (1993. szept. 14.) o Oldalszél: A bal kerék 9 másodperccel később ért földet, mint a jobb o Intelligens fékezés vezérlés: Kerekek terhelése + forgása is kell o Késői fékezés túlfutás ütközés Toyota gépkocsi balesete San Diegóban, aug. o Szőnyeg miatt beragadt gázpedál padlógáz o Miért nem volt elég hatásos a fékezés? a sebességváltó üresbe állítása (D N)? a motor lekapcsolása? BME-MIT 4.

4 Tapasztalatok balesetek elemzése alapján A baleset tipikusan összetett eseményszekvencia o Tervezési fázisban előre kellene látni A baleset általában meghibásodás következménye o A detektálatlan hiba tipikusan veszélyt jelent o De előfordulhat veszély hibátlan működés esetén is Biztonság a rendszer egészének tulajdonsága o Több lehet, mint mérnöki probléma (pl. ergonómia) o Tervezési folyamat során kell figyelembe venni o Új technológiák, új környezet elemzése szükséges BME-MIT 5.

5 Néhány adat Biztonsági problémák javítása o Toyota recalls 160,000 cars with hybrid engines due to a failure of its engine control software. (October 2005) o Nissan recalls 16,365 Murano and Infiniti EX 35 vehicles in February 2008 due to a software problem causing airbag failure. o Defibtech issues a worldwide recall of two of its defibrillator products due to faulty self-test software that may clear a previously detected low battery condition. The issue affects approximately 42,000 units worldwide. (2007) Biztonságkritikus szoftver fejlesztése o 5-10 mérnökév / kloc fejlesztési ráfordítás o Ennek 45-75%-a az ellenőrzésre hiba / kloc jön létre a fejlesztés során 0,1-10 hiba / kloc maradhat az üzembe helyezésig o Példák: US Space Shuttle fejlesztése: 3 millió kódsor, 3 milliárd USD Vasúti szoftverek: 100 EUR / kódsor BME-MIT 6.

6 1. Követelmények Mivel foglalkozunk majd? o Biztonság, szolgáltatásbiztonság 2. Architektúra tervezés o Jellegzetes tervezési minták 3. Biztonsági és megbízhatósági analízis o Veszély analízis o Kockázatcsökkentés 4. Modellalapú tervezés o Verifikáció a tervezési folyamat során BME-MIT 7.

7 Biztonsági követelmények BME-MIT 9.

8 Terminológia Baleset (accident): Nemkívánatos, be nem tervezett sérülés, veszteség Veszély (hazard), veszélyes állapot: Olyan állapot, amely adott környezeti feltételek mellett balesethez vezet Kockázat (risk): Veszély jellemzése: következmény szintje + gyakorisága Biztonság(osság) (safety): Balesetektől való mentesség (ideális eset!) Elfogadhatatlan kockázattól való mentesség Biztonsági funkció ( rendszer, szoftver is): Veszélyes állapotokkal kapcsolatba hozható a hibás vagy hiányzó végrehajtása BME-MIT 10.

9 Terminológia Olyan állapot, amely adott környezeti feltételek mellett balesethez vezet Nemkívánatos, be nem tervezett fizikai sérülés vagy egészségkárosodás Elfogadhatatlan kockázattól való mentesség (Ideális eset: Balesetektől való mentesség) Veszély Baleset Biztonság Kockázat Biztonsági funkció Veszélyes állapotokkal kapcsolatba hozható a hibás vagy hiányzó végrehajtása Veszély jellemzése: Következmény szintje + gyakorisága BME-MIT 11.

10 Kiindulás: Veszélyanalízis és kockázatelemzés gyakoriság trigger szint ok veszély hatás Biztonság: Elfogadhatatlan kockázattól való mentesség Kockázat: o Veszély következmény szintje és gyakorisága határozza meg Milyen kockázat elviselhető? o Példa 1: Házak méretezése 50 év alatt >10% valószínűséggel előforduló földrengésre o Példa 2: Gátak méretezése a 100 éves legmagasabb vízállásra o Valószínűségi vagy gyakorisági megadások tipikusak BME-MIT 13.

11 Előírások biztonsági funkciókra Biztonsági funkció kockázatelemzése alapján előírások adhatók o Nem folytonos üzemmód: A funkció meghívása esetén a veszélyt okozó hibajelenség valószínűségére o Folytonos üzemmód: Veszélyt okozó hibajelenség gyakoriságára Elviselhető veszélygyakoriság: Tolerable Hazard Rate (THR) THR kategóriák: Biztonságintegritási szint Ha 15 év az élettartam, akkor ez alatt kb. 750 berendezésből 1-ben lesz hiba SIL Biztonságkritikus funkció hibája / óra THR < THR < THR < THR < 10-8 Hiba nélküli működés > év?? BME-MIT 14.

12 SIL meghatározás alapelve A VIZSGÁLT FUNKCIÓ Veszély gyakoriság növekedés Veszélyes esemény gyakorisága Rendszer biztonságintegritási szint 4 Szoftver biztonságintegritási szint 4 Kockázat THR SIL 3 3 Veszélyes esemény következménye Következmények súlyosságának növekedése Kockázatelemzés -> Funkció THR -> Funkció SIL -> (Al)rendszer SIL BME-MIT 15.

13 Biztonsági követelmények Biztonsági követelmények specifikációja o Funkcionális biztonsági követelmények Mit kell csinálnia a biztonsági funkciónak? o Biztonságintegritási követelmények Mi annak a bizonyossági foka, hogy a biztonságkritikus rendszer a biztonsági funkciót kielégítően megvalósítja adott feltételek és időtartam mellett? Biztonságintegritási szintek: SIL 1, 2, 3, 4 (növekvő) A biztonságintegritás teljesítésének ellenőrzése o Véletlen meghibásodásokra: Számításokkal ellenőrizhető gyakoriság/valószínűség o Szisztematikus meghibásodásokra (pl. szoftver): Számításokkal nem ellenőrizhető valószínűség Módszer- és eszközkészlet előírt a fejlesztés során BME-MIT 16.

14 Biztonsági követelmények felépítése Rendszerkövetelmények specifikációja Nem biztonsági követelmények Biztonsági követelmények Biztonsági követelmények specifikációja Szoftver komponensek esetén Szisztematikus meghibásodási integritás Biztonságintegritási követelmények Véletlen meghibásodási integritás Funkcionális biztonsági követelmények Hardver komponensek esetén BME-MIT 17.

15 Példa biztonsági követelményre Fűrészgép, a forgó korong előtt védőráccsal o Tisztításhoz a védőrácsot fel kell húzni Veszély analízis: Kezelőt baleset érheti tisztításkor, ha a motor be van kapcsolva o Ha a védőrácsot 10 mm-nél jobban felhúzzák, és a motor 1 másodperc alatt nem áll le o 20 gép van, 500-szor kell tisztítást végezni az élettartam alatt; ez alatt legfeljebb 1-szer elviselhető, hogy a leállítás ne működjön o Ha a leállítás nem működik, még nem feltétlenül okoz balesetet (a kezelő is óvatos és figyeli a motort) Biztonsági funkció: Védőkapcsolás a motorhoz Funkcionális biztonsági követelmény: o Ha a védőrácsot 4 mm-re felhúzzák, a motort 0,8 s alatt leállítja Biztonságintegritási követelmény: o A védőkapcsolás hibájának valószínűsége legyen kisebb, mint 10-4 BME-MIT 18.

16 A szolgáltatásra vonatkozó további minőségi követelmények (A biztonság önmagában nem elég) BME-MIT 19.

17 A szolgáltatás használhatóságának jellemzése Jellegzetes szolgáltatásminőségi követelmények: o Megbízhatóság, rendelkezésre állás, adatintegritás,... o Ezek a használat közben előforduló hibáktól is függenek (nem elég az előállítási folyamat jó minősége) Összetett jellemző: Szolgáltatásbiztonság o Angol terminológia: Dependability o Definíció: Képesség olyan szolgáltatás nyújtására, amiben igazoltan bízni lehet Igazoltan: elemzésen, méréseken alapul Bizalom: szolgáltatás az igényeket kielégíti o Mennyire kerülhetők el illetve kezelhetők a szolgáltatásokat érintő hibahatások? BME-MIT 20.

18 Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák Fejlesztési folyamat jellemzői: Jobb minőségbiztosítás, jobb módszertanok De növekvő bonyolultság, nehezebb ellenőrzés Szokásos becsült értékek 1000 kódsorra: Jó kézi fejlesztés és tesztelés: <10 hiba marad Automatizált fejlesztés: ~1-2 hiba marad Formális módszerek használata: <1 hiba marad Hardver hibák Konfigurációs hibák Kezelői hibák BME-MIT 22.

19 Hibahatások Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák Hardver hibák Konfigurációs hibák Kezelői hibák Technológia korlátai: Jobb minőségbiztosítás, jobb anyagok De növekvő érzékenység Szokásos becsült értékek: CPU: hiba/óra RAM: hiba/óra LCD: ~ 2 3 év élettartam BME-MIT 23.

20 Hibahatások kiküszöbölése Fejlesztési folyamat Működő termék Tervezési hibák Implementációs hibák Hardver hibák Konfigurációs hibák Kezelői hibák Ellenőrzések a tervezés során Hibatűrés működés közben BME-MIT 24.

21 Szolgáltatásbiztonság alapjellemzői Rendelkezésre állás (availability): o Helyes szolgáltatás valószínűsége (közben hiba esetén javítás végezhető) Megbízhatóság (reliability): o Folyamatosan helyes szolgáltatás valószínűsége (az első hibáig tekinthető megbízhatónak) Biztonságosság (safety): o Elfogadhatatlan kockázattól való mentesség Integritás (integrity): o Hibás változás, változtatás elkerülésének lehetősége Karbantarthatóság (maintainability): o Javítás és fejlesztés lehetősége BME-MIT 25.

22 Definíciók: Várható értékek Állapot particionálás s(t) rendszerállapot esetén o Hibamentes (Up) illetve Hibás (Down) állapotpartíció s(t) U D u1 d1 u2 d2 u3 d3 u4 d4 u5 d5... Várható értékek: o Első hiba bekövetkezése: (Mean Time to First Failure) o Hibamentes működési idő: (Mean Up Time, Mean Time To Failure) o Hibás működési idő: (Mean Down Time, Mean Time To Repair) o Hibák közötti idő: (Mean Time Between Failures) MTFF = E{u1} Javított rendszer esetén MUT = MTTF = E{ui} MDT = MTTR = E{di} MTBF = MUT + MDT BME-MIT 26. t

23 Definíciók: Valószínűség időfüggvények Rendelkezésre állás: a(t) = P{ s(t) U } Megbízhatóság: r(t) = P{ s(t ) U, t <t } Készenlét: K=lim t a(t) (közben meghibásodhat) (t-ig nem hibásodhat meg) (rendszeresen javított) Jelölhető A-val is: K = A = MTTF / (MTTF + MTTR) 1.0 a(t) K 0 r(t) t BME-MIT 27.

24 Készenlét tipikus követelményei Készenlét Max. kiesés egy év alatt 99% ~ 3,5 nap 99,9% ~ 9 óra 99,99% ( 4 kilences ) ~ 1 óra 99,999% ( 5 kilences ) ~ 5 perc 99,9999% ( 6 kilences ) ~ 32 másodperc 99,99999% ~ 3 másodperc Komponensekből felépített rendszer készenléte, ahol egy komponens készenléte 95%: 2 komponensből álló rendszer: 90% 5 komponensből álló rendszer: 77% 10 komponensből álló rendszer: 60% BME-MIT 28.

25 Komponens jellemző (katalógusadat) Meghibásodási tényező (gyakoriság): (t) Kezdeti hibák (gyártás utáni teszt) o A komponens mekkora valószínűséggel fog éppen t időpont környezetében elromlani, feltéve, hogy t-ig jól működött (t) t = P{ s(t+ t) D s(t) U }, miközben t 0 o Másképp is felírható, a megbízhatóság definíciója alapján: 1 dr( t) ( t), így r( t) e r() t dt o Elektronikai alkatrészekre: (t) Használati tartomány () t dt Itt r( t) e t BME-MIT 29. t 0 MTFF E U r() t dt 1 0 t 1 Öregedési tartomány (elavulás)

26 Példa: Egy DMI fejlesztése: Célkitűzés EVC: European Vital Computer (fedélzeti) Mozdonyvezető Karbantartó központ DMI EVC Jellegzetességek: Biztonságkritikus működés o Információ megjelenítése o Vezetői parancsok feldolgozása o Adatátvitel az EVC-hez Biztonságos vezeték nélküli kommunikáció o Konfiguráció o Diagnosztika o Szoftver frissítés BME-MIT 30.

27 Példa: Egy DMI fejlesztése: Prototípus BME-MIT

28 Példa: Egy DMI fejlesztése: Követelmények Biztonság: o Biztonságintegritási szint: SIL 2 o Biztonsági funkció elviselhető hibája óránként (Tolerable Hazard Rate): 10-7 <= THR < 10-6 Megbízhatóság: o Mean Up Time: MUT > 5000 óra (5000 óra: ~ 7 hónap) Rendelkezésre állás (készenlét): o A = MUT / (MUT+MDT), A > Hibás állapot: évenként kevesebb, mint 42 óra MDT < 24 óra, ha a fenti MUT biztosítható BME-MIT

29 Mi befolyásolja a szolgáltatásbiztonságot? Hibaok: A hiba feltételezett oka Érintett rendszer vagy komponens Hiba: Hibajelenséghez vezető állapot Hibajelenség: A specifikációnak nem megfelelő szolgáltatás Hibaok Hiba Hibajelenség hatáslánc példák: Hibaok Hiba Hibajelenség Kozmikus sugárzás egy bitet átbillent a memóriában Programozó csökkentés helyett növel egy változót Hibás memóriacella olvasása Vezérlés ráfut, a változó értéke hibás lesz Robotkar a falnak ütközik A számítás végeredménye rossz BME-MIT 33.

30 A meghibásodás jellemzői Hibaok Térbeli jellemzők Időbeli jellemzők Belső Külső Időleges (tranziens) Állandósult Fizikai (hardver) Fizikai (környezet) Tervezési (ált. szoftver) Adat (bemenet) Szoftver hiba: Állandósult, tervezési hiba (szisztematikus meghibásodás) Hiba aktiválás a működési profil (bemenetek) függvénye BME-MIT 34.

31 Eszközök a szolgáltatásbiztonság növelésére Hiba megelőzés: Hibaok megakadályozása o Fizikai hibák: Jó minőségű alkatrészek, árnyékolás,... o Tervezési hibák: Jó fejlesztési módszerek Hiba megszüntetés: o Tervezési fázis: Ellenőrzések (verifikáció, validáció) o Prototípus fázis: Tesztelés, diagnosztika, javítás Hibatűrés: Szolgáltatást nyújtani hiba esetén is o Működés közben: Hibakezelés, redundancia aktiválás Hiba előrejelzés: Hibák és hatásuk becslése o Mérés és jóslás, ez alapján megelőző karbantartás BME-MIT 35.

32 Biztonságkritikus rendszerek fejlesztése BME-MIT 36.

33 Ismétlés: Biztonsági követelmények Funkcionális és biztonságintegritási követelmények o Meghatározás: Kockázatelemzés alapján o Biztonságintegritási szint: SIL 1, 2, 3, 4 Folyamatos működés: Veszélyt okozó hibajelenség gyakorisága Nem folyamatos: Veszélyt okozó hibajelenség valószínűsége A SIL követelmény teljesítésének ellenőrzése o Véletlen meghibásodásokra: Számításokkal ellenőrizhető gyakoriság/valószínűség o Szisztematikus meghibásodásokra (pl. szoftver): Számításokkal nem ellenőrizhető valószínűség Módszer- és eszközkészlet előírt a fejlesztés során BME-MIT 37.

34 A szabványok szerepe Teljes hibamentesség nem garantálható komplex rendszer (pl. szoftver) esetén o Cél: Bennmaradó hibák számának csökkentése Szisztematikus meghibásodásokra: Komplex megoldás-csomag az egyes biztonságintegritási szintekhez 1. Fejlesztési folyamat (életciklus modell) 2. Előírt technikák és intézkedések (megoldás-csomag) Egy-egy szabványban módszer (+kombinációjuk) 3. Előírt dokumentáció 4. Szervezeti rend (felelősségek) BME-MIT 38.

35 1. A fejlesztési folyamat Általában jól definiált fázisokat tartalmaz o Előre definiált fejlesztési lépések o Jól meghatározott specifikáció, ismert környezet Szigorú feltételekhez kötött előrelépés: Hangsúlyos a fejlesztési lépések ellenőrzése o Hibák kockázata nagy (felelősség) o Üzembehelyezés utáni javítás költsége nagy o Hatósági engedélyezés szükséges Szabványokban ajánlott fejlesztési folyamat o Jellegzetes az ún. V modell BME-MIT 39.

36 Ellenőrzések tervezése a V-modellben Üzemeltetés, karbantartás Követelmények elemzése Rsz. validáció tervezés Rendszer validáció Rendszer specifikálás Rendszerteszt tervezés Rendszer verifikáció Architektúra tervezés Integrációs teszt tervezés Rendszer integrálás Modul tervezés Modul teszt tervezés Modul verifikáció Modul implementáció BME-MIT 40.

37 A verifikáció és validáció szerepe Verifikáció (igazolás): o Jól fejlesztem-e a rendszert? Validáció (érvényesítés): o Jó rendszert fejlesztettem-e? Követelmények validáció Egy fejlesztési lépés eredménye megfelelő-e: Tervek (formális) ellenőrzése, szimuláció, tesztelés A rendszer megfelel-e a felhasználói elvárásoknak: Tesztelés (használati környezetben), mérések Rendszer t 1 Specifikáció verifikáció Rendszer verifikáció Tervek Implementáció Modulok BME-MIT 41.

38 2. Módszerek és intézkedések megadása Tesztelés MÓDSZER / INTÉZKEDÉS Említés helye SW- SIL0 SW- SIL1 SW- SIL2 SW- SIL3 1. Valószínűségi tesztelés B47 - R R HR HR 2. Teljesítmény tesztelés D6 - HR HR M M 3. Funkcionális és fekete doboz tesztelés SW- SIL4 D3 HR HR HR M M 4. Modellezés D5 - R R R R Követelmény: Előírások: M HR R 1. Az 1, 2, 3 és 4 szoftver-biztonságintegritási szintek esetén a 2. és 3. módszer kombinációja jóváhagyottnak tekintendő. Kötelező Nyomatékosan ajánlott (elhagyása indoklást igényel) Ajánlott (kombinációból kihagyható) Nincs javaslat vagy ellenérv NR Ellenjavallt (használata indoklást igényel) Módszerkombinációk választhatók BME-MIT 42.

39 Példa: A technikák további finomítása Funkcionális és fekete doboz tesztelés (D3): Teljesítmény tesztelés (D6): BME-MIT 43.

40 Példa: Módszerek és intézkedések megadása IEC 61508: Functional safety in electrical / electronic / programmable electronic safety-related systems Példa: Szoftver architektúra tervezés BME-MIT 44.

41 3. A dokumentáció követelményei Dokumentáció típusa o Átfogó (pl. fejlesztési terv, verifikációs terv) o Életciklus fázishoz kötődő (pl. teszt jelentés) Dokumentum kereszt-referencia táblázat o Melyik életciklus fázishoz milyen dokumentáció o Dokumentumok egymásra épülése Dokumentumok követhetősége szükséges o Ugyanazon terminológia, rövidítések, elnevezések Dokumentumok összevonhatók o Részlet nem veszhet el o De független szereplők dokumentumai nem vonhatók össze BME-MIT 45.

42 Példa: Előírt dokumentáció (EN50128) Szoftvertervezési fázis Szoftverfejlesztési terv Szoftver-minőségbiztosítási terv Szoftverkonfiguráció menedzselési terv Szoftverigazolási terv Szoftverintegrációs tesztterv Szoftver/hardver-integrációs tesztterv Szoftverérvényesítési terv Szoftver-karbantartási terv Rendszerfejlesztési fázis Rendszerkövetelmény-specifikáció Rendszerbiztonsági követelményspecifikáció Rendszerarchitektúra-leírás Rendszerbiztonsági terv Szoftverkövetelmény-specifikációs fázis Szoftverkövetelmény-specifikáció Szoftverkövetelmény-tesztspecifikáció Szoftverkövetelmény-igazolójelentés Szoftver architektúra és kialakítási fázis Szoftverarchitektúra-specifikáció Szoftverkialakítási specifikáció Szoftver architektúra és kialakítási igazolójelentés Szoftver karbantartási fázis Szoftver karbantartási jegyzőkönyvek Szoftver változtatási jelentések Szoftverértékelési fázis Szoftverértékelési jelentés Szoftverérvényesítési fázis Szoftverérvényesítési jelentés Szoftver/hardver-integráció fázisa Szoftver/Hardver-integrációs tesztjelentés Szoftverintegráció fázisa Szoftverintegrációs tesztjelentés Szoftvermodul kialakítási fázis Szoftvermodul-tervezési specifikáció Szoftvermodul-tesztspecifikáció Szoftvermodul-igazolójelentés Szoftvermodul tesztelési fázis Szoftvermodul-tesztjelentés EN 50128: kb. 30 dokumentum! Kódolási fázis Szoftver forráskód és támogató dokumentáció Szoftver forráskód-igazolójelentés BME-MIT 46.

43 4. Szervezeti rend Minőségi illetve biztonsági szervezet létrehozása a biztonságmenedzselés bizonyítása o ISO 9001 vonatkozó részeinek alkalmazása o Konfigurációmenedzselés Képzettség (alkalmasság) igazolása Szerepkörök: o TER: o VER: o VAL: o ÉRT: o MGR: Projekt menedzser o MIN: Minőségbiztosítási felelős Tervező (elemző, tervező, kódoló, unit tesztelő) Verifikátor (igazoló) Validátor (érvényesítő) Értékelő (független felülvizsgáló) BME-MIT 47.

44 Példa: Minimális függetlenség követelményei SIL 0: Szervezet Személy TER, VER, VAL ÉRT SIL 1 és 2: TER VER, VAL ÉRT SIL 3 és 4: MGR ÉRT TER VER, VAL vagy: MGR ÉRT TER VER VAL BME-MIT 48.

45 Összefoglalás Biztonságkritikus rendszerek alapfogalmai o Veszély, kockázat o THR és biztonságintegritási szintek Szolgáltatásbiztonság o Jellemzők o Hibaok -> hiba -> hibajelenség hatáslánc o Eszközök a szolgáltatásbiztonság növelésére Fejlesztési folyamat specialitásai o Módszerek és technikák o Életciklus és dokumentáció: Jól meghatározott fázisok o Szervezeti rend BME-MIT 49.