Biztonsági folyamatirányító. rendszerek szoftvere

Átírás

1 Biztonsági folyamatirányító rendszerek szoftvere 1

2 Biztonsági folyamatirányító rendszerek szoftvere Tartalom Szoftverek szerepe a folyamatirányító rendszerekben Szoftverek megbízhatósága Szoftver életciklus Biztonsági szoftverekkel szemben támasztott követelmények Szoftverírás Tesztelés 2

3 Szoftverek szerepe a folyamatirányító rendszerekben Programozott irányítórendszerek Célgépek Nincs operációs rendszer Egyszerű szoftver Pl. egy-chipes mikrokontrollerek Univerzális alkalmazású rendszerek Moduláris hardver (általában kártya rendszerű) Tagolt szoftverfelépítés 3

4 Tagolt szoftverfelépítés KONFIGURÁCIÓ Az adott alkalmazási hely konfigurációja; általában adatbázis ALKALMAZÓI/FELHASZNÁLÓI SZOFTVER Alkalmazás-specifikus funkciók, pl. általános jelzőlámpa vezérlés OPERÁCIÓS RENDSZER A folyamatirányítással kapcsolatos általános alapfunkciók 4

5 Az operációs rendszer feladatai A folyamatirányító rendszerek szoftvere általában ciklikus működésű: INICIALIZÁLÁS BEMENETEK BEOLVASÁSA FELDOLGOZÁS KIMENETEK KIÍRÁSA 5

6 Szoftverek megbízhatósága A szoftver akkor működőképes és így biztonságos, ha a követelményeket (specifikáció) jól fogalmaztuk meg, és a megvalósítás (implementáció) is helyes. A szoftverek megbízhatósága (helyes működésének valószínűsége) független az időtől (amennyiben nem változtattuk meg). Szoftverek esetében nem beszélhetünk meghibásodásról: A szoftver megbízhatóságát csak az eredeti, szisztematikus, specifikációs, tervezési és megvalósítási hibák csökkentik. A szoftvert tároló alkatrész meghibásodása hardvermeghibásodás. DE! Emberi beavatkozással egy jó szoftvert is el lehet rontani, például: Újra-bekerülési hiba: átlagosan minden harmadik hibajavítással újabb hibát idézünk elő. 6

7 VALIDÁCIÓ VERIFIKÁCIÓ Szoftver-életciklus 1 SPECIFIKÁCIÓ A szoftver feladatának meghatározása 2 SZOFTVER TERVEZÉS 3 KÓDOLÁS 4 KARBANTARTÁS Hibák javítása Módosítások 7

8 Követelmények a biztonsági szoftverekkel szemben Cél: hibamentesség. Szoftver-megbízhatóságot növelő módszerek Jól strukturáltság Moduláris felépítés Áttekinthetőség szükséges az ellenőrzéshez is Modulonként kevés be/kimenet (lehetőleg 1-1) könnyű tesztelni Jól definiált interfészek Feltétel nélküli ugrások (GOTO) kerülése Tesztelhetőség kialakítása tesztelés-barát tervezés Jól dokumentáltság Funkciók leírása Interfészek leírása Nem-biztonsági részek: arra kell ügyelni, hogy a nem-biztonsági rész semmilyen módon ne legyen hatással a biztonsági részekre visszahatásmentesség. 8

9 Szoftverírás Programozási koncepciók Defenzív programozás: számítok arra, hogy a programozás során hibákat fogok elkövetni. Passzív ellenőrzések: pl. ellenőrző összegek, hihetőségvizsgálat Aktív ellenőrzések: adatáramlástól független ellenőrzés, így tesztelhetők a ritkán aktív lefutási ágak is. CASE: Computer Aided Software Engineering Automatikus programgenerátorok: a generátor program helyességét kell bizonyítani. 9

10 Szoftver tesztelés Az eredeti hibák kiküszöbölésének leggyakoribb eljárása a hibaeltávolítás. Lépései: tesztelés diagnózis javítás. Tesztelés Statikus: a rendszer működtetése nélküli tesztelés. Ez végrehajtható a rendszeren magán vagy a rendszer alkalmas modelljén végrehajtott vizsgálatokkal. Dinamikus tesztelés: a rendszer működtetése révén megfelelőségi tesztek / pozitív tesztek hibakereső tesztelés funkcionális/black boksz tesztek és strukturális tesztek 10

11 Biztonsági architektúrák 1 hardver, 1 szoftver Lehet, h. a szoftver jól van megírva, de a hardver véletlen hibái ellen semmi nem véd. A

12 Biztonsági architektúrák 1 hardver, 2 szoftver Két különböző (diverz) szoftver fut (A és B) ugyanazon a gépen. Két szoftver futhat párhuzamosan, vagy egymás után. Az összehasonlító felfedi, ha a két szoftver mást mond felfedhetők a specifikációs és programozási hibák Mivel a két program eltérő, ezért egy HW hiba nem egyformán hat a két szoftverre, így a véletlen HW hibák is felfedhetők Pl. Ebilock (svéd) elektronikus bb. A B ÖH

13 Biztonsági architektúrák 2 hardver, 1 szoftver 2-ből 2 rendszer (2v2) Véd a hardver véletlen meghibásodásai ellen A szoftvert eleve jóra kell készíteni, mert az architektúra nem véd a specifikációs és programozási hibák ellen. Pl. Siemens SIMIS-elv A ÖH A

14 Simis-elv 2v2 konfiguráció Data input 2 mikroszámítógép Microcomputer 1 Input Input Microcomputer 2 óraszinkron utasításszinkron Processor Memory Output Data exchange Data exchange Comparison Synchronisation Synchronisation Comparison Output Processor Memory a mikroszámítógépektől független 2 összehasonlító összehasonlítja a kimeneteket és a Channel 1 Channel 2 processzor tartalmakat (memóriát)

15 Biztonsági architektúrák 2 hardver, 2 szoftver Az architektúra véd a véletlen hardver hibák ellen és a szoftver hibák ellen. A két csatornában eltérő specifikációval, eltérő programnyelven kifejlesztett programok futnak Pl. Thales Elektra A ÖH B

16 Rendelkezésre állás Az eddig bemutatott architektúrák biztonságosak ugyan, de már egy hiba esetén is működésképtelenek. Módszerek a rendelkezésre állás növelésére: 1. Tartalékolás Egycsatornás rendszer: redundancia 2v2 2 (2v2) (pl. SIMIS IS: SIMIS PC) 2v2 2v3 (pl. SIMIS IS: ECC számítógépek)

17 2v3 3 mikroszámítógép 6 független összehasonlító egység a 3. csatorna is aktív hiba esetén a hibás csatorna/modul leáll tovább működik 2v2 rendszerként

18 Data input Microcomputer A Microcomputer B computer C Micro- Input Input Input A Data exchange Data exchange Data exchange Data exchange Data exchange Data exchange A B B Processor Memory Processor Memory Processor Memory C Synchronisation Synchronisation Synchronisation C D D E Comparison Comparison Comparison Comparison Comparison Comparison E Output & Output & Output & Channel A Channel B Channel C 3 mikroszámítógép 6 független összehasonlító egység a 3. csatorna is aktív hiba esetén a hibás csatorna/modul leáll tovább működik 2v2 rendszerként

19 SIMIS PC 2 (2v2) diverz számítógéprendszer Kereskedelmi forgalomban kapható számítógépek és operációs rendszerek AMD, Intel alaplap/processzor Win2000, Linux operációs rendszerek a diverzitás, és az ECC-kben való összehasonlítás miatt lehetséges ezek alkalmazása Összehasonlítás az ECC-kben történik (időablakkal)

20 DEL PB ECC-CU DEL PB ECC-CU DEL PB ECC-CU SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR SOM F1 - F8 SOM PSS ERR F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR SOM F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR SOM F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR SOM F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 PSS HS2 POM ERR M2+ M1+ M2- M1- L SHIFT HS1 R PSS HS2 POM ERR M2+ M1+ M2- M1- SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS L SHIFT HS1 R PSS HS2 POM ERR M2+ M1+ M2- M1- L SHIFT HS1 R DEL PB ECC-CU DEL PB ECC-CU DEL PB ECC-CU SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR SOM F1 - F8 PSS ERR F1 F2 F3 F4 F5 F6 F7 F8 SOM F1 - F8 SOM PSS ERR F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 SOM PSS ERR F1 - F8 F1 F2 F3 F4 F5 F6 F7 F8 PSS ERR F1 F2 F3 F4 F5 F6 F7 F8 SOM F1 - F8 PSS HS2 POM ERR M2+ M1+ M2- M1- L SHIFT HS1 R PSS HS2 POM ERR M2+ M1+ M2- M1- SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS SIEMENS L SHIFT HS1 R PSS HS2 POM ERR M2+ M1+ M2- M1- L SHIFT HS1 R SIMIS PC SIMIS PC 2 x 2-ből 2 rendszer EIM ECC 3-ból 2 rendszer 2 (2v2) diverz számítógéprendszer Kereskedelmi forgalomban kapható számítógépek és operációs rendszerek AMD, Intel alaplap/processzor Win2000, Linux operációs rendszerek a diverzitás, és az ECC-kben való összehasonlítás miatt lehetséges ezek alkalmazása Összehasonlítás az ECC-kben történik (időablakkal)

21 Alcatel ELEKTRA 1 Két diverz szoftver csatorna A két csatornában lévő gépeknek egyenként van 2-es vagy 3- as redundanciájuk A biztosítóberendezés szintekre oszlik: Kezelés/visszajelentés Központi szint Perifériavezérlés Az egyes számítógépek és a perifériavezérlőket pont-pont kábelezés köti össze Hardverbázis: 486-os processzorok Vágányúti logika: táblázatos, vágányutas elvű

22 ELEKTRA Rendszerfelépítés kezelőfelület kapcsoló 2 VCA VCB 2 VOTRICS 3 CCA CCB 3 VOTRICS 2 PCA PCB 2 Perifériavezérlő kártyák