3. Biztonságkritikus rendszerek

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "3. Biztonságkritikus rendszerek"

Átírás

1 3. Biztonságkritikus rendszerek Ebben a fejezetben az informatikai rendszerek azon csoportjával a biztonságkritikus rendszerekkel foglakozunk, ahol kiemelt jelentősége van a biztonságnak. A legnagyobb mértékben itt jelentkezik a fejlesztési és tesztelési eljárások esetén a szigorú szabályozás. A biztonságkritikus rendszerek kategóriájába tartozó szoftverekre vonatkozó előírások nem mindegyike vonatkozik a nem biztonságkritikus szoftverekre, viszont a biztonságkritikus alapelvek figyelembe vétele a nem biztonságkritikus szoftverek minőségi javulását eredményezheti Alapfogalmak, követelmények A biztonságkritikus rendszerek olyan informatikai rendszerek, amelyek azzal az elsődleges követelménnyel üzemeltethetők, hogy ne veszélyeztessenek emberi életet, egészséget, ne okozzanak gazdasági vagy környezeti károkat. Példák biztonságkritikus rendszerekre: közlekedés (szárazföldi, vízi, légi) irányítása, vezérlése, egészségügyi informatika rendszerek, hadászatban használt informatikai rendszerek, gazdasági folyamatokat kezelő rendszerek (bankok, tőzsde). Az említett példákban jól látható, hogy az adott informatikai rendszer hibás működése esetén milyen jellegű károk jelentkezhetnek. Az első három pontban (közlekedés, egészségügy, hadászat) az emberi élet veszélyeztetésének, illetve például a környezeti károk kockázata merülhet fel, míg a gazdasági folyamatok esetén a gazdásági károk kockázata. A példákban is említett informatikai rendszerek esetén azonban nem elégséges, hogy az informatikai rendszer biztonságkritikus módon működjön. Az ilyen rendszerek esetén alapvetően elvárt tulajdonság a megbízhatóság, a folyamatos működés is. A megfelelő megbízhatósági szint eléréséhez hibatűrő rendszerek alkalmazására van szükség. A hibatűrő rendszerek olyan informatikai rendszerek, amelyek képesek elvégezni, ill. tovább folytatni előírt feladatainak helyes végrehajtását a hardver meghibásodásakor, illetve szoftver-hibák esetén is. A hibatűrés nem jelenti azonban azt, hogy az informatikai rendszer ugyanazzal a képességgel, illetve teljesítménnyel működik a különböző (hardver, szoftver hibák) esetén is, csupán azt, hogy a működése nem áll le. Előfordulhat persze, hogy a teljesítménye lecsökken, esetleg nem mindegyik funkcióját képes ellátni, viszont az alapvető feladatait még végre tudja hajtani. A hibatűrő rendszerek tervezésekor olyan tervezési célokat kell elérni, amelyek előre megadott követelmények teljesítését célozzák meg. 10

2 Minőségi és megbízhatósági követelmények Megbízhatóság (Reliability): Annak a feltételes valószínűsége, hogy a rendszer hibátlanul működik a [t 1, t 2 ] időintervallumban, feltéve, hogy a t t 1 időpontban hibátlanul működött. A megbízhatósági érték tehát annak a valószínűségét fejezi ki, hogy a rendszer a [t 1, t 2 ] időintervallumban végig hibátlanul működik. Ez az érték az intervallum hosszának a növekedésével nyilvánvalóan csökken, hiszen a hosszabb intervallum működési feltételének a teljesülése nyílván magában tartalmazza a rövidebb intervallumra vonatkozó működési teljesülést. Ezt a paramétert elsősorban olyan rendszerek jellemzésére használják, ahol egy rövid időre sincs megengedve a hibás működés, vagy pedig nincs mód a javításra. Például egy repülőgép esetén a megbízhatóságra vonatkozó működési idő a repülési idő, illetve egy nem javítható űrszondánál a működési idő többéves nagyságrendű is lehet. A megbízhatóság és a hibatűrés nem ugyanazt jelenti. A hibatűrés olyan technika, amely javítja a megbízhatóságot, de ettől még nem biztos, hogy valóban magas lesz a megbízhatóság. Ha egy rendszer ki tud védeni hardver hibákat, de azok nagy gyakorisággal jelentkeznek, akkor megbízhatóság értéke még alacsony is lehet. Másrészről pedig, ha egy nagy megbízhatóságú rendszerbe nincs beépítve hibatűrés, akkor az első hiba fellépésétől kezdve rosszul fog működni Rendelkezésre állás (Availability): Annak a valószínűsége, hogy a rendszer helyesen működik a t időpontban, vagyis a t időpontban rendelkezésre áll. A megbízhatóság és a rendelkezésre állás között az a lényeges különbség, hogy az előbbi egy időintervallumban az eszköz működésének folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a egy időpillanatban legyen a működés helyes. Az rendelkezésre állás mérőszáma azért fontos, mert az informatikai rendszert nem állandóan használják egy feladatra, hanem gyakori megszakításokkal és ilyen esetekben megnövekszik a közbenső karbantartás és javítás szerepe, amely a rendelkezésre állás magas szinten tartását szolgálja. Biztonságosság (Safety): Annak a valószínűsége, hogy a rendszer helyesen vagy hibásan működik egy adott időpillanatban, de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem befolyásolja károsan más rendszerek működését, azaz annak valószínűsége, hogy a rendszer az adott időpillanatban biztonságosan működik. A biztonságosság igen szorosan összefügg a hibatűréssel. Például ha egy informatikai rendszerben valamilyen meghibásodás lép fel, aminek következtében már nem lesz képes a rendszer az előírt funkcióit ellátni. Ebben az esetben a biztonságosság fenntartása úgy oldható meg, hogy a rendszer olyan sorrendben hagy fel, egymás után, a funkciók ellátásával, ami a katasztrófa elkerülését teszi lehetővé. Ez a fokozatos leépülés (graceful degradation) módszere. A fokozatos leépülés egy rendszer azon képessége, hogy automatikusan képes csökkenteni teljesítőképességét, a hardver- és szoftver-hibák biztonságosságra vonatkozó hatásának ellensúlyozására. További lehetséges vészmegoldási módszer, hogy a rendszer utolsó intézkedéseként mindent úgy állít le, hogy a katasztrófa semmiképpen ne tudjon bekövetkezni. Például egy közlekedésirányítási rendszer olyan utasításokat ad, hogy semmilyen jármű 11

3 sem mozoghat, vagy egy közlekedési jelzőlámpa vezérlő rendszer minden irányban a villogó sárga jelzést állítja be. Teljesítőképesség (Performability): Annak a valószínűsége, hogy a rendszer teljesítőképessége egy adott időpillanatban eléri vagy meghaladja a megadott szintet. A teljesítőképesség azt fejezi ki, hogy a hiba esetén milyen csökkent szinten képes még a rendszer megfelelően működni. A korábban említett fokozatos leépülés megvalósítása nem más, mint a teljesítőképesség előre megtervezett módon való fokozatos csökkentése, a biztonság fenntartása érdekében. Karbantarthatóság (Maintainability): Annak a valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető egy bizonyos időtartam alatt, beleértve a hiba helyének meghatározását, a fizikai javítást, a csere esetleges elvégzését, illetve az újraindítást. A karbantarthatóság magas szinten tartása feltétlenül megköveteli a rendszer beépített öntesztelését (built-in self-testing, BIST), valamint az automatizált diagnózis elvégzését, amely a hiba helyének meghatározására irányul. A tesztelési és hibakeresési feladatok végrehajtásához külön hardver és/vagy szoftver egységek felhasználására lehet szükség, amelyek a hibatűrő rendszer részét képezik. A hibatűrésre vonatkozóan négy fő alkalmazási területet különböztethetünk meg: 1. Hosszú élettartamú alkalmazások: Az ide tartozó rendszerek rendszerint több éves időtartamban működnek, általában a javításra kevés lehetőséggel. Például: Ember nélküli repülés, űrrepülés, műholdak, űrszondák. Egy-egy űrszonda akár tíz éven túl is teljesíti küldetését, amikor távoli bolygók közelébe kell jutnia, a megbízhatósági értékének 95% felett kell lenni. Az űrszondákon a biztonságos működés elérése érdekében mindegyik egységnek, blokknak van másodlagos tartaléka. Ez nemcsak az informatikai egységekre, hanem a különböző navigációs, távmérő, rádiós, stb. blokkokra is fennáll. 2. Kritikus számítások: Ez a felhasználási terület az előbbinek az ellenkezője. A hibatűrés szempontjából itt az a fontos, hogy a viszonylag rövid működési időtartam alatt, amíg egy kritikus működési, számítási szakaszban üzemel a rendszer, a megbízhatósága garantáltan magas legyen. Például: Repülőgépeknél, űreszközöknél a felszállás és a leszállás legkritikusabb ideje alatt nem szabad hibának történnie. Vegyi üzemek vezérlő rendszereiben kiemelt fontosságú lehet egy-egy kritikus munkafolyamat esetén a helyes működés. 3. Elhalasztott karbantartás: Ebben a felhasználási területben olyan esetekről van szó, ahol a karbantartási műveleteket igen nehéz, vagy igen költséges elvégezni. Például a távoli helyeken üzemeltetett feldolgozó állomások, vagy az űrbeli alkalmazások. Egy-egy ilyen rendszer karbantartása egy későbbi, megfelelő időpontban történik meg, és a két karbantartási procedúra között kiemelten szükséges a hibatűrő működés. 4. Magas szintű rendelkezésre állás: Ez a terület a változó mértékben igénybe vett rendszerekre vonatkozik. Ide sorolhatók például az on-line tranzakció-feldolgozást végző rendszerek (banki alkalmazások), ahol a felhasználói igények véletlenszerűen jelentkeznek, és ezekre azonnali reagálás (feldolgozás, kiszolgálás) a követelmény. 12

4 3.2. Redundancia megoldások (hardver, szoftver) Annak érdekében, hogy a hibatűrő informatikai rendszer a normál funkcióikon kívül a saját hibás működés felismerésére és az ilyenkor megvalósítandó feladatokra is képesek legyenek, a hibatűrés megvalósítása mindenképpen előre betervezett redundanciával kell, hogy történjen. A redundancia jelen lehet mind a hardverben, mindpedig a szoftverben is. Azonban egyedül egyik fő komponens sem képes a másik hibáját felismerni és funkcióját ellátni. Természetesen a szoftver és a hardver egymással összhangban üzemel, amibe az is beletartozik, hogy a hibafelismerésben és az ilyenkor szükséges feladatokban is kiegészítik, vagy átfedik egymás tevékenységét. A hibatűrő rendszerek felépítése sok esetben olyan, hogy a hardver is hozzájárul a szoftver-hibák felismeréséhez, és viszont, a szoftver is részt vehet a hardver-hibák észlelésében. A redundancia megvalósítására négy terület vált alkalmassá. 1. Hardver redundancia: A hibatűrés elérése érdekében kiegészítő hardver elemeket alkalmaznak, különböző funkciókkal. A funkciók egyrészt a működéshez kapcsolódó tesztelést (beépített öntesztelést), másrészt pedig egyes elemek ismétlését (tartalékként) jelentik általában. 2. Szoftver redundancia: A hibatűrés elérése érdekében kiegészítő szoftverelemeket, ill. szoftverrel megvalósított módszereket alkalmaznak. Itt is számításba kell vennünk a szoftvert az öntesztelés megvalósításában, valamint az ismétlődő funkciók ellátásában. 3. Információs redundancia: A működési biztonság növelése érdekében többletinformációt, többletbiteket használnak fel. Ezáltal a hibák detektálására és javítására kerülhet sor. Ilyen elterjedt megoldások például a paritásbitek, hibadetektáló kódok, hibajavító kódok, ellenőrzőösszegek használata. A hibajavító kódok nemcsak detektálásra, hanem javításra, vagyis a hiba elfedésére, hatásának megszüntetésére is alkalmasak. Az ilyen megoldások a kommunikációs folyamatokban, továbbá a memóriákban, illetve a központi feldolgozó egységekben (CPU) terjedtek el elsősorban. Megvalósításuk egyaránt történhet hardveres és szoftveres úton is. 4. Idő redundancia: A szükségesnél hosszabb feldolgozási idő igénybevétele. A cél itt is a hibák detektálása és javítása. A legelterjedtebb megoldás a feldolgozás, a számítások ismételt lefolytatása, az eredmények összehasonlításával egybekötve. Ezzel elérhető az, hogy a rendszerben fellépő átmeneti hibát, amely az egyik végrehajtás alatt érvényesült, egy újabb végrehajtással ki lehessen küszöbölni. Az időtöbblet tehát így a hiba detektálását és javítását is lehetővé teszi. A megvalósítás egyaránt történhet hardverrel és szoftverrel is. A gyakorlatban a fenti négy elv kombinációját alkalmazzák. Igen sok esetben mind a négy redundanciát beépítik a biztonságkritikus rendszerekbe. 13

5 A hardver redundancia megvalósítása A következőkben három jellegzetes megoldást ismertetünk a hardver redundancia megvalósítására: a párhuzamos duplikálást, a tartalékelemes üzemeltetést és a hárommodulos redundanciát. Párhuzamos duplikálás A párhuzamos duplikálás az egyik legrégebbi megoldás az a kézenfekvő struktúra ugyanazon hardver egységnek a megkettőzése és párhuzamos működtetése. Ebben az esetben mindkét egység ugyanazokat a bemenő jeleket kapja, és helyes működés esetén ugyanazokat az eredményeket is kell produkálniuk. Az eredmények megfigyelése és összevetése egy külön beiktatott összehasonlító egység feladata. Abban az esetben, ha a két modul eredménye egyezik, akkor az egyik egység jelei jutnak tovább a feldolgozási folyamatban. Abban az esetben viszont, ha a két eredmény nem egyezik, akkor az az egyik egység hibás működését jelenti. A párhuzamos duplikálás struktúrája tehát a hibát csak detektálni tudja, annak javítását viszont nem képes megoldani. Ilyenkor célszerű megoldás lehet a további működés biztonságot nem sértő leállítása. A párhuzamos duplikálás struktúrája a 3.1. ábrán látható. A duplikált egységek bármilyen bonyolultságú modulok lehetnek, tetszőleges számú különböző típusú egységpárost lehet egy rendszeren belül kialakítani, például aritmetikai logikai egységet, vagy háttértárolókat, hálózati összeköttetést. A legmagasabb szintű megoldás az, amikor egy teljes számítógép megkettőzése valósul meg. Tartalékelemes üzemeltetés A tartalékelemes üzemeltetés struktúrájában is két azonos egység vesz részt, de csak az egyik, a normál egység végez üzemszerű tevékenységet, a másik tartalékként szerepel (3.2. ábra). Azt, hogy melyik egység jelei jutnak a kimenetre, az átkapcsoló modul intézi el, a hibadetektor modul utasítása alapján. A hibadetektor rendelkezik azzal a képességgel, hogy meg tudja állapítani a helyes-hibás működést az általa ellenőrzött modulról. Ha a normál modult hibásnak ítéli, akkor a tartalékmodul használatára kerül sor. Ha az is meghibásodna, a működést felfüggesztheti, akár oly módon, hogy az a további működés biztonságát nem befolyásolja. A tartalékmodult kétféle állapotban használhatjuk a normál üzemelés folyamán. Az egyikben nincs bekapcsolva (hideg tartalék), a másikban állandóan be van kapcsolva, és működést fejt ki (meleg tartalék). A hideg tartalék alkalmazása egyrészt energia-takarékossági okokból, másrészt pedig az élettartam meghosszabbítása érdekében célszerű. 14

6 Hárommodulos redundancia (TMR) A párhuzamos duplikálás és tartalékelemes üzemeltetés struktúrájában láthattuk, hogy a hibatűrés megvalósítására nem elegendő két egység. A cél elérése legalább három egység beiktatását igényli. Egy ilyen struktúra, a hárommodulos redundancia (Triple Modular Redundancy, TMR.) látható a 3.3. ábrán. A TMR-struktúrában a három megismételt modul kimenetei egy úgynevezett szavazóegységre (voting unit) kerülnek, amely a többségi szavazás elvén működik. Ez azt jelenti, hogy a kimenetre az a jel megy tovább, amely legalább két modulnál azonos. Ha tehát egy modul meghibásodik, akkor a másik kettő azonosan működése érvényesül (függetlenül attól, hogy az helyes vagy azonosan helytelen). A TMR struktúra tehát képes egyrészt a hibás modul hibáját detektálni, mivel az megállapítható, hogy melyik tért el a másik kettőtől, másrészt pedig javítani is képes azt, mivel a hiba hatása nem jut érvényre a teljes működésben, feltéve persze, hogy csak egy modul hibázik. Ha két vagy három modul hibásodna meg, akkor várhatóan három különböző jel jutna a szavazóra, amely ilyenkor detektálná a hibás működést, aminek alapján egy biztonságra törekvő leállítás, vagy tartalékegység beléptetése következhet. Feltételezzük persze, de nem zárhatjuk azonban ki, hogy a modulok hibás működése nem eredményez azonosan helytelen kimenete. Ennek a valószínűsége azonban elhanyagolhatóan csekély. 15

7 A TMR struktúra egyetlen hibás modul esetén alkalmas a hibajavításra. Az eltűrt hibás modulok száma úgy növelhető, hogy növeljük a párhuzamosan dolgozó modulok számát, de mindig úgy, hogy ez a szám páratlan legyen a többségi szavazással összhangban. Ekkor ugyanis a szavazásnál nem fordulhat elő holtverseny. Ha egy rendszerben N db modult használunk (n 3), akkor a többségi szavazáson alapuló redundancia (n 1) / 2 db modul hibás működését képes tolerálni. Ez a szám öt modulnál kettő, hét modulnál három. A modulok számának növelése egyrészt nem jár arányosan egyértelmű javulással, mivel a meghibásodások valószínűsége is növekszik, másrészt viszont az (n 1) / 2 db modul együttes meghibásodásának a valószínűsége nagyobb n esetén jóval kisebb. A gyakorlatban alkalmazott informatikai rendszerekben a többmodulos redundancia esetén, a gazdaságossági szempontokat is figyelembe véve, a hárommodulos TMR konstrukció terjedt el és vált be leginkább. A szoftver redundancia megvalósítása Egy rendszer hibatűrő képességét szeretnénk a legmagasabb szinten tartani. Ez nem csupán a hardver hibák, hanem a szoftver hibák kezelését is megköveteli. Ez nyílván plusz szoftvert, vagy esetleg szoftverkomponenst igényel. Ugyanakkor a hardverhibák menedzselése is többlet-szoftver alkalmazásokat igényelhet. Informatikai rendszerek hibatűrésének szoftveres kezelése két céllal valósulhat meg. Egyrészt a rendszer szoftver komponenseire vonatkozó hibák detektálása, illetve korrigálása céljából, másrészt a szoftver hibák mellett a hardver hibáinak a kezelése céljából is. A második eset magában foglalja az elsőt is, ezért követendő megoldásként ezt érdemes használni. A hardveres párhuzamos duplikálás struktúrájából kiindulva vizsgáljuk meg azt a lehetőséget, amelyben a hardver megkettőzése szerepel (3.4. ábra). Tegyük fel, hogy mindkét csatornában ugyanazt a szoftvert telepítettük, és a csatornák CPU-ja is megegyezik, vagyis SW1 SW2, valamint CPU1 CPU2. 16

8 Ebben az esetben a szoftverben előforduló hibák detektálására semmilyen további lehetőség nincs, mivel mindkét csatorna azonosan működik, függetlenül attól, hogy az eredmény helyes vagy helytelen. Így viszont az összehasonlító helyes működésnek érzékeli a hibás, de azonos kimeneteket is. A hárommodulos redundanciát alkalmazó rendszerben sem lesz jobb a helyzet. Ha a szoftverkomponens hibás az egyik ágon, helytelen eredményt fog adni a másik ágon is. Szoftveres hibák felderítését csak úgy végezhetjük el, ha nem ugyanazt a szoftvert használjuk, azaz a különböző csatornák szoftverje nem lesz azonos, viszont ugyanazt a működést kell végezniük. Ezt az elvet szoftver diverzitásnak nevezzük. A következőkben két olyan megoldást mutatunk be, amely a szoftver hibatűrést szolgálja a szoftver diverzitási elv érvényesítésével. N-verziós programozás Az N-verziós programozásban a teljes szoftvert több (N) db példányban készítjük el. Feltételezzük, hogy a különböző verziókban a bennük lévő hibák is különböznek és elenyészően kicsi annak a valószínűsége, hogy ugyanaz a hiba több verzióban is előforduljon. Ennek a célnak az elérése érdekében célszerű, ha egymástól független, különböző fejlesztő csoportok készítik el a különböző. Természetesen sokkal praktikusabb, ha az egymástól független, különböző fejlesztő csoportok eltérő programozási nyelveket alkalmazva oldják meg a programozási feladatukat. A fejlesztő csoportok ugyanazt a specifikációt valósítják meg. Eltérő nyelvek esetén az egymástól való függetlenségük azt a célt szolgálja, hogy nehogy ugyanazokat a hibákat kövessék el és vigyék bele a szoftverbe. Az N-verziós programozást használó rendszer a következők szerint működik: 1. Az N program ugyanazt a bemenetet használva lefut és szolgáltatja a kimenetet. Ez a számítógépes szervezéstől függően történhet akár párhuzamosan, akár sorosan is. Párhuzamos 17

9 esetben mindegyik programhoz egy dedikált CPU-t használunk, azaz N db CPU vesz részt a feldolgozásban. Soros esetben viszont csak egyetlen CPU végzi el a különböző programverziók végrehajtását egymás után. Természetesen, ha N-nél kevesebb (de 1-nél több) CPU áll rendelkezésre, akkor bizonyos programverziók párhuzamosan, bizonyosak pedig sorosan futhatnak. Így kombinálhatjuk a párhuzamos és a soros megoldást is. 2. Egy erre a célra készített összehasonlító program elvégzi az N db programverzió kimeneteinek az összehasonlítását. N = 2 esetén csak a hibadetektálás ténye derül ki. A hibás szoftver-komponensre, vagy a hibás hardverre nem tudunk következtetni, az összehasonlító program csupán két különböző kimenetet lát, nem tudja eldönteni melyik a helyes és melyik a helytelen. Hatékonyabb megoldást érhetünk el az N = 3 esetén, ahol mód nyílik a hárommodulos redundanciánál megismert többségi szavazás alkalmazására, egy a szavazást megvalósító programkomponens segítségével. Ez a megoldás lehetővé teszi a hibás szoftver meghatározását, és hibájának eltűrését is. A számítógépes megoldás meglehetősen költséges, hiszen ugyanazt a szoftvert egyrészt többszörösen kell kifejleszteni, másrészt a végrehajtás szervezése is további költségeket jelent. Párhuzamos feldolgozás esetén több processzorra, soros feldolgozás esetén több időre van szükség, illetve a futási eredmények eltárolásáról és összehasonlításáról is külön kell gondoskodni. A javító blokkok módszere A szoftverhibák kezelésének egy másik módszere az ún. javító blokkok (recovery blocks) alkalmazása. A javító blokkok módszere szerint a teljes szoftvert több modulra, komponensre bontják, és az egyes modulokat többverziós módon valósítják meg, majd a modulok önteszteléssel egybekötött újrafuttatásával érhetjük el a megfelelő színtű hibatűrést. Egy-egy modul azonos funkciójú verziói alkotnak egy blokkot. Mindegyik blokkhoz tartozik egy öntesztelést végző úgynevezett elfogadási teszt (acceptance test), ami egy külön program az esetleges hibás működés detektálására. A feldolgozásban a modulok egymás utáni futtatására kerül sor, ahol minden futást az elfogadási teszt végrehajtása követ. Ha egy modulverziót elfogad az elfogadási teszt, az adott blokk újabb programverziójának futtatására már nem kerül sor, a következő blokk első programverziójával folytatódik a végrehajtás. Ha egy modulverzió hibásnak bizonyul a teszt alapján, akkor a soron következő tartalékmodul futtatására kerül sor, a blokkon belül. Ha ez is hibás az elfogadási teszt szerint, újabb modulra kerül sor, mindaddig, amíg csak van futtatható modulverzió. A javítás (felépülés, recovery) elve akkor érvényesül egy blokkban, ha egy hibás modult egy jó modul futása követ. Ha egy blokkban mindegyik modulverzió hibásnak bizonyul, akkor a teljes futás véget ér, ekkor a hiba javítása ugyan nem, de annak detektálása megtörtént. A javító blokkok módszerének egy lényeges szervezési kérdése, hogy egy új blokk futtatása előtt mindig el kell menteni az addig előállt összes adatot egy független tárba. Ha hibát talál az ellenőrzés, az új programverzió futtatása ebből az elmentett állapotból kell hogy történjen. 18

10 Az elfogadási tesztek elkészítés nem egy egyszerű feladat, a programmodul és a működési környezet alapos ismeretét igényli. Az elfogadási tesztek készítésének néhány követendő irányelve a következő: Annak ellenőrzése, hogy egy kiszámított érték az elfogadható normális fizikai tartományba esik-e (például, hőmérséklet vagy nyomás). Nem történt 0-val való osztás. Nem történt címtartományon kívüli címzés, a tömbdeklarációk figyelembevételével. Egy-egy fontos számérték meghatározása alternatív algoritmussal is megtörténhet. A javító blokkok módszerét előszeretettel használják az elosztott számítógépes rendszerekben is. Az ilyen rendszerekben több különböző számítógép (csomópont) vesz részt egy-egy feladat megoldásában, az erőforrások összehangolt, automatizált elosztásával. Ilyen szervezésben előfordulhat az is, hogy egy modul ismételt végrehajtására egy másik csomóponton kerül sor, ha az előző csomópont hibásnak bizonyult. Ezzel így nem csupán a szoftveres, hanem a hardveres hibák kezelését (detektálás, javítás) is el lehet végezni. 19

SZOFTVER-MINŐSÉGBIZTOSÍTÁS BIZTONSÁGKRITIKUS RENDSZEREK. Széchenyi István Egyetem. Alapfogalmak

SZOFTVER-MINŐSÉGBIZTOSÍTÁS BIZTONSÁGKRITIKUS RENDSZEREK. Széchenyi István Egyetem. Alapfogalmak Alapfogalmak Biztonságkritikus rendszer: Olyan informatikai rendszer, amely azzal az elsődleges követelménnyel működtetendő, hogy ne veszélyeztesse az emberi életet, egészséget, ne okozzon gazdasági vagy

Részletesebben

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája Készítette: Urbán Norbert Szoftver-minőség A szoftver egy termelő-folyamat végterméke, A minőség azt jelenti,

Részletesebben

Verifikáció és validáció Általános bevezető

Verifikáció és validáció Általános bevezető Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának

Részletesebben

BME Járműgyártás és -javítás Tanszék. Javítási ciklusrend kialakítása

BME Járműgyártás és -javítás Tanszék. Javítási ciklusrend kialakítása BME Járműgyártás és -javítás Tanszék Javítási ciklusrend kialakítása A javítási ciklus naptári napokban, üzemórákban vagy más teljesítmény paraméterben meghatározott időtartam, amely a jármű, gép új állapotától

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2014-15/2 (4) Szoftverminőségbiztosítás Biztonság kritikus szoftverek Hibatűrés Szoftver-diverzitás Biztonság, biztonságosság Mentesség azoktól a feltételektől, melyek halált, sérülést,

Részletesebben

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Hibatűrés Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/ 1 Hibatűrés különféle hibák esetén Hardver tervezési hibák

Részletesebben

Autóipari beágyazott rendszerek. Funkcionális biztonságossági koncepció

Autóipari beágyazott rendszerek. Funkcionális biztonságossági koncepció Autóipari beágyazott rendszerek Funkcionális biztonságossági koncepció 1 Funkcionális biztonsági koncepció Functional safety concept Cél A funkcionális biztonsági követelmények levezetése A biztonsági

Részletesebben

A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata

A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata A Budapesti Értéktőzsde Részvénytársaság Igazgatóságának 110/2003. számú határozata A Budapesti Értéktőzsde Részvénytársaság Igazgatósága A Budapesti Értéktőzsde Részvénytársaság Szabályzata a Távkereskedés

Részletesebben

Autóipari beágyazott rendszerek. Kockázatelemzés

Autóipari beágyazott rendszerek. Kockázatelemzés 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

Részletesebben

Dr. BALOGH ALBERT: MEGBÍZHATÓSÁGI ÉS KOCKÁZATKEZELÉSI SZAKKIFEJEZÉSEK FELÜLVIZSGÁLATÁNAK HELYZETE

Dr. BALOGH ALBERT: MEGBÍZHATÓSÁGI ÉS KOCKÁZATKEZELÉSI SZAKKIFEJEZÉSEK FELÜLVIZSGÁLATÁNAK HELYZETE Dr. BALOGH ALBERT: MEGBÍZHATÓSÁGI ÉS KOCKÁZATKEZELÉSI SZAKKIFEJEZÉSEK FELÜLVIZSGÁLATÁNAK HELYZETE 1 Megbízhatósági terminológia: IEC 50(191):2007 változat (tervezet) Kockázatkezelő irányítási terminológia:

Részletesebben

Biztonságkritikus rendszerek Gyakorlat: Architektúrák

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

Részletesebben

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK

A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK A TESZTELÉS ALAPJAI MIÉRT SZÜKSÉGES A TESZTELÉS? MI A TESZTELÉS? ÁLTALÁNOS TESZTELÉSI ALAPELVEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR,

Részletesebben

Jogi Behajtási Keretrendszer és moduljai üzemeltetése

Jogi Behajtási Keretrendszer és moduljai üzemeltetése 1003/36-1/2017/1003-1. sz. melléklet Jogi Behajtási Keretrendszer és moduljai üzemeltetése MŰSZAKI LEÍRÁS 1. Általános leírás A Jogi Behajtási Keretrendszer (a továbbiakban JBK) a BKK Zrt. jogi behajtási

Részletesebben

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban OpenCL alapú eszközök verifikációja és validációja a gyakorlatban Fekete Tamás 2015. December 3. Szoftver verifikáció és validáció tantárgy Áttekintés Miért és mennyire fontos a megfelelő validáció és

Részletesebben

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0 Készítette: Hajnali Krisztián Jóváhagyta: Varga József Rubin Informatikai Zrt. 1149 Budapest, Egressy út 17-21. telefon: +361 469 4020; fax:

Részletesebben

A szolgáltatásbiztonság alapfogalmai

A szolgáltatásbiztonság alapfogalmai A szolgáltatásbiztonság alapfogalmai Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/edu/courses/szbt 1 Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló tényezők

Részletesebben

Cloud Akkreditációs Szolgáltatás indítása CLAKK projekt. Kozlovszky Miklós, Németh Zsolt, Lovas Róbert 9. LPDS MTA SZTAKI Tudományos nap

Cloud Akkreditációs Szolgáltatás indítása CLAKK projekt. Kozlovszky Miklós, Németh Zsolt, Lovas Róbert 9. LPDS MTA SZTAKI Tudományos nap Cloud Akkreditációs Szolgáltatás indítása CLAKK projekt Kozlovszky Miklós, Németh Zsolt, Lovas Róbert 9. LPDS MTA SZTAKI Tudományos nap Projekt alapadatok Projekt név: Cloud akkreditációs szolgáltatás

Részletesebben

biztonságkritikus rendszerek

biztonságkritikus rendszerek Kockázat, biztonság, biztonságkritikus rendszerek Dr. Sághi Balázs BME Közlekedés- és Járműirányítási Tanszék Tartalom A közlekedéssel szembeni elvárások A kockázat fogalma Kockázatcsökkentés Követelmények

Részletesebben

Követelmények a megbízható működés terén. Információbiztonsági osztályozás a megbízható működés szempontjából. T - T üz T

Követelmények a megbízható működés terén. Információbiztonsági osztályozás a megbízható működés szempontjából. T - T üz T Követelmények a megbízható működés terén Információbiztonsági osztályozás a megbízható működés szempontjából Megbízható működés Az informatikai rendszerek megbízható működését úgy értelmezzük, hogy az

Részletesebben

IT üzemeltetés és IT biztonság a Takarékbankban

IT üzemeltetés és IT biztonság a Takarékbankban IT üzemeltetés és IT biztonság a Takarékbankban Előadó: Rabatin József Üzleti stratégia igények Cél? IT és IT biztonsági stratégia Mit? Felmérés, Feladatok, Felelősség Minőségbiztosítás Mennyiért? Hogyan?

Részletesebben

Biztonságkritikus rendszerek architektúrája (2. rész)

Biztonságkritikus rendszerek architektúrája (2. rész) Biztonságkritikus rendszerek architektúrája (2. rész) 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

Részletesebben

Bevezetés. Adatvédelmi célok

Bevezetés. Adatvédelmi célok Bevezetés Alapfogalmak Adatvédelmi célok Adatok és információk elérhet!ségének biztosítása és védelme Hagyományosan fizikai és adminisztratív eszközökkel Számítógépes környezetben automatizált eszközökkel

Részletesebben

Miskolci Egyetem Általános Informatikai Tanszék

Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

A tesztelés feladata. Verifikáció

A tesztelés feladata. Verifikáció Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a

Részletesebben

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

Biztonsági folyamatirányító. rendszerek szoftvere Biztonsági folyamatirányító rendszerek szoftvere 1 Biztonsági folyamatirányító rendszerek szoftvere Tartalom Szoftverek szerepe a folyamatirányító rendszerekben Szoftverek megbízhatósága Szoftver életciklus

Részletesebben

Szoftverminőségbiztosítás

Szoftverminőségbiztosítás NGB_IN003_1 SZE 2017-18/2 (4) Szoftverminőségbiztosítás Biztonság kritikus szoftverek Hibatűrés Szoftver-diverzitás Biztonság, biztonságosság Mentesség azoktól a feltételektől, melyek halált, sérülést,

Részletesebben

Modulzáró ellenőrző kérdések és feladatok (2)

Modulzáró ellenőrző kérdések és feladatok (2) Modulzáró ellenőrző kérdések és feladatok (2) 1. Definiálja az alábbi, technikai eszközök üzemi megbízhatóságával kapcsolatos fogalmakat (1): Megbízhatóság. Használhatóság. Hibamentesség. Fenntarthatóság.

Részletesebben

Információ menedzsment

Információ menedzsment Információ menedzsment Szendrői Etelka Rendszer- és Szoftvertechnológiai Tanszék szendroi@witch.pmmf.hu Infrastruktúra-menedzsment Informatikai szolgáltatások menedzsmentje Konfigurációkezelés Gyorssegélyszolgálat

Részletesebben

Modulzáró ellenőrző kérdések és feladatok (2)

Modulzáró ellenőrző kérdések és feladatok (2) Modulzáró ellenőrző kérdések és feladatok (2) 1. Definiálja az alábbi, technikai eszközök üzemi megbízhatóságával kapcsolatos fogalmakat (1): Megbízhatóság. Használhatóság. Hibamentesség. Fenntarthatóság.

Részletesebben

FMEA tréning OKTATÁSI SEGÉDLET

FMEA tréning OKTATÁSI SEGÉDLET FMEA tréning OKTATÁSI SEGÉDLET 1. Hibamód és hatás elemzés : FMEA (Failure Mode and Effects Analysis) A fejlett nyugati piacokon csak azok a vállalatok képesek hosszabbtávon megmaradni, melyek gazdaságosan

Részletesebben

TM TM TM-77203

TM TM TM-77203 TM-77201 TM-77202 TM-77203 Árnyékállomás rendszer Használati útmutató 2012 BioDigit Ltd. Minden jog fenntartva. A dokumentum sokszorosítása, tartalmának közzététele bármilyen formában, beleértve az elektronikai

Részletesebben

Adatmodellezés. 1. Fogalmi modell

Adatmodellezés. 1. Fogalmi modell Adatmodellezés MODELL: a bonyolult (és időben változó) valóság leegyszerűsített mása, egy adott vizsgálat céljából. A modellben többnyire a vizsgálat szempontjából releváns jellemzőket (tulajdonságokat)

Részletesebben

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László

II. rész: a rendszer felülvizsgálati stratégia kidolgozását támogató funkciói. Tóth László, Lenkeyné Biró Gyöngyvér, Kuczogi László A kockázat alapú felülvizsgálati és karbantartási stratégia alkalmazása a MOL Rt.-nél megvalósuló Statikus Készülékek Állapot-felügyeleti Rendszerének kialakításában II. rész: a rendszer felülvizsgálati

Részletesebben

Osztott jáva programok automatikus tesztelése. Matkó Imre BBTE, Kolozsvár Informatika szak, IV. Év 2007 január

Osztott jáva programok automatikus tesztelése. Matkó Imre BBTE, Kolozsvár Informatika szak, IV. Év 2007 január Osztott jáva programok automatikus tesztelése Matkó Imre BBTE, Kolozsvár Informatika szak, IV. Év 2007 január Osztott alkalmazások Automatikus tesztelés Tesztelés heurisztikus zaj keltés Tesztelés genetikus

Részletesebben

A vizsga részei A vizsga értékelése Gyakorlat i

A vizsga részei A vizsga értékelése Gyakorlat i Informatika Vizsgaleírások Vizsga jellemzői A vizsga részei A vizsga értékelése Gyakorlat i Szóbeli Osztályozó Javító Időtartam 45 perc 10 perc 80%-tól jeles(5) 60%-79% jó(4) Aránya az értékelésnél Vizsgakövetelmények

Részletesebben

Szoftver karbantartási lépések ellenőrzése

Szoftver karbantartási lépések ellenőrzése Szoftverellenőrzési technikák (vimim148) Szoftver karbantartási lépések ellenőrzése Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.inf.mit.bme.hu/

Részletesebben

Hibajavító kódok május 31. Hibajavító kódok 1. 1

Hibajavító kódok május 31. Hibajavító kódok 1. 1 Hibajavító kódok 2007. május 31. Hibajavító kódok 1. 1 Témavázlat Hibajavító kódolás Blokk-kódok o Hamming-távolság, Hamming-súly o csoportkód o S n -beli u középpontú t sugarú gömb o hibajelzı képesség

Részletesebben

A BIZOTTSÁG (EU).../... VÉGREHAJTÁSI RENDELETE ( )

A BIZOTTSÁG (EU).../... VÉGREHAJTÁSI RENDELETE ( ) EURÓPAI BIZOTTSÁG Brüsszel, 2018.2.28. C(2018) 1116 final A BIZOTTSÁG (EU).../... VÉGREHAJTÁSI RENDELETE (2018.2.28.) a menetíró készülékek és alkatrészeik kialakítására, tesztelésére, beépítésére, működtetésére

Részletesebben

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN

Részletesebben

A szolgáltatásbiztonság alapfogalmai

A szolgáltatásbiztonság alapfogalmai A szolgáltatásbiztonság alapfogalmai Majzik István majzik@mit.bme.hu http://www.mit.bme.hu/oktatas/targyak/vimim146/ 1 Tartalomjegyzék A szolgáltatásbiztonság fogalma A szolgáltatásbiztonságot befolyásoló

Részletesebben

A Szekszárdi I. Béla Gimnázium Helyi Tanterve

A Szekszárdi I. Béla Gimnázium Helyi Tanterve A Szekszárdi I. Béla Gimnázium Helyi Tanterve Négy évfolyamos gimnázium Informatika Készítette: a gimnázium reál munkaközössége 2015. Tartalomjegyzék Alapvetés...3 Egyéb kötelező direktívák:...6 Informatika

Részletesebben

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK STRUKTÚRA ALAPÚ, VAGY FEHÉRDOBOZ TECHNIKÁK TAPASZTALAT ALAPÚ TECHNIKÁK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN

Részletesebben

Képzési program. A képzés megnevezése: CNC szerviz technológus. 1. A képzéssel megszerezhető kompetenciák:

Képzési program. A képzés megnevezése: CNC szerviz technológus. 1. A képzéssel megszerezhető kompetenciák: Képzési program A képzés megnevezése: CNC szerviz technológus 1. A képzéssel megszerezhető kompetenciák: 1.1. Számítógépeket kezel, szoftvereket használ 1.2. Alkalmazza a számítástechnikai ismereteit 1.3.

Részletesebben

Muha Lajos. Az információbiztonsági törvény értelmezése

Muha Lajos. Az információbiztonsági törvény értelmezése Muha Lajos Az információbiztonsági törvény értelmezése kibervédelem? KIBERVÉDELEM KRITIKUS INFORMÁCIÓS INFRASTRUKTÚRÁK VÉDELME ELEKTRONIKUS INFORMÁCIÓS RENDSZEREK VÉDELME Az információvédelem igénye Magyarország

Részletesebben

Megbízhatóság az informatikai rendszerekben

Megbízhatóság az informatikai rendszerekben Megbízhatóság az informatikai rendszerekben Az információ Minden intelligens rendszer hajtóanyaga Az információ minőségi jellemzői Sértetlenség Biztonság Adatvédelem Titkosság Hitelesség Rendelkezésre

Részletesebben

QAA73 kezelési utasítás felhasználóknak, beüzemelőknek

QAA73 kezelési utasítás felhasználóknak, beüzemelőknek QAA7 kezelési utasítás felhasználóknak, beüzemelőknek JELLEMZŐK Működési feszültség Védelem OpenTherm bus Csatlakoztathatóság Vezeték hossz Vezeték ellenálló képessége Teljesítményfelvétel Biztonsági szint

Részletesebben

Nemzeti Alaptanterv Informatika műveltségterület Munkaanyag. 2011. március

Nemzeti Alaptanterv Informatika műveltségterület Munkaanyag. 2011. március Nemzeti Alaptanterv Informatika műveltségterület Munkaanyag 2011. március 1 Informatika Alapelvek, célok Az információ megszerzése, megértése, feldolgozása és felhasználása, vagyis az információs műveltség

Részletesebben

STATISZTIKA. A maradék független a kezelés és blokk hatástól. Maradékok leíró statisztikája. 4. A modell érvényességének ellenőrzése

STATISZTIKA. A maradék független a kezelés és blokk hatástól. Maradékok leíró statisztikája. 4. A modell érvényességének ellenőrzése 4. A modell érvényességének ellenőrzése STATISZTIKA 4. Előadás Variancia-analízis Lineáris modellek 1. Függetlenség 2. Normális eloszlás 3. Azonos varianciák A maradék független a kezelés és blokk hatástól

Részletesebben

5. KOMBINÁCIÓS HÁLÓZATOK LEÍRÁSÁNAK SZABÁLYAI

5. KOMBINÁCIÓS HÁLÓZATOK LEÍRÁSÁNAK SZABÁLYAI 5. KOMBINÁCIÓS HÁLÓZATOK LEÍRÁSÁNAK SZABÁLYAI 1 Kombinációs hálózatok leírását végezhetjük mind adatfolyam-, mind viselkedési szinten. Az adatfolyam szintű leírásokhoz az assign kulcsszót használjuk, a

Részletesebben

Programtervezés. Dr. Iványi Péter

Programtervezés. Dr. Iványi Péter Programtervezés Dr. Iványi Péter 1 A programozás lépései 2 Feladat meghatározás Feladat kiírás Mik az input adatok A megoldáshoz szükséges idő és költség Gyorsan, jót, olcsón 3 Feladat megfogalmazása Egyértelmű

Részletesebben

Alkalmazások típusai Szoftverismeretek

Alkalmazások típusai Szoftverismeretek Alkalmazások típusai Szoftverismeretek Prezentáció tartalma Szoftverek csoportjai Operációs rendszerek Partíciók, fájlrendszerek Tömörítés Vírusok Adatvédelem 2 A szoftver fogalma A szoftver teszi használhatóvá

Részletesebben

Informatika érettségi vizsga

Informatika érettségi vizsga Informatika 11/L/BJ Informatika érettségi vizsga ÍRÁSBELI GYAKORLATI VIZSGA (180 PERC - 120 PONT) SZÓBELI SZÓBELI VIZSGA (30 PERC FELKÉSZÜLÉS 10 PERC FELELET - 30 PONT) Szövegszerkesztés (40 pont) Prezentáció-készítés

Részletesebben

Enabling and Capitalising of Urban Technologies

Enabling and Capitalising of Urban Technologies PILOT TEVÉKENYSÉG Pilot tevékenység neve Laborok megvalósítása a Pinkafeld Campuson Projektirányító / Projekt partner Burgenland GmbH Főiskola Motiváció és Célok / Célcsoport A legjelentősebb villamos

Részletesebben

Java programozási nyelv

Java programozási nyelv Java programozási nyelv 2. rész Vezérlő szerkezetek Nyugat-Magyarországi Egyetem Faipari Mérnöki Kar Informatikai Intézet Soós Sándor 2005. szeptember A Java programozási nyelv Soós Sándor 1/23 Tartalomjegyzék

Részletesebben

Grid menedzsment megoldás az ARC köztesrétegben

Grid menedzsment megoldás az ARC köztesrétegben Grid menedzsment megoldás az ARC köztesrétegben Intézetünk az Új Magyarország Fejlesztési Terv TÁMOP 4.1.3[1] alprojektjének keretén belül dolgozott ki sikeresen egy jól működő megoldást egy olyan problémára,

Részletesebben

MUST 30-120. Három fázisú Moduláris UPS. A moduláris UPS előnyei már mindenki számára elérhetőek

MUST 30-120. Három fázisú Moduláris UPS. A moduláris UPS előnyei már mindenki számára elérhetőek MUST 30-120 Három fázisú Moduláris UPS A moduláris UPS előnyei már mindenki számára elérhetőek MUST30-120 A MUST 30/120 termékcsalád egy szünetmentes áramellátó rendszer, három fázisú be- illetve kimenettel,

Részletesebben

24 V DC áramkörök biztosítása

24 V DC áramkörök biztosítása 24 V C áramkörök biztosítása Taalom 24 V C áramkörök biztosítása 24 V C áramkörök biztosítása Áttekintés.2 WAVEGUAR.4.1 24 V C áramkörök biztosítása 24 V C áramkörök biztosítása Áttekintés WAVEGUAR elektronikus

Részletesebben

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN

ESZKÖZTÁMOGATÁS A TESZTELÉSBEN ESZKÖZTÁMOGATÁS A TESZTELÉSBEN MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA, TURISZTIKA ÉS VENDÉGLÁTÁS TERÜLETEN

Részletesebben

Algoritmusok Tervezése. 6. Előadás Algoritmusok 101 Dr. Bécsi Tamás

Algoritmusok Tervezése. 6. Előadás Algoritmusok 101 Dr. Bécsi Tamás Algoritmusok Tervezése 6. Előadás Algoritmusok 101 Dr. Bécsi Tamás Mi az algoritmus? Lépések sorozata egy feladat elvégzéséhez (legáltalánosabban) Informálisan algoritmusnak nevezünk bármilyen jól definiált

Részletesebben

Már megismert fogalmak áttekintése

Már megismert fogalmak áttekintése Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése Eseménykezelési módszerek 2 Már megismert fogalmak

Részletesebben

FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI

FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI FEGYVERNEKI SÁNDOR, Valószínűség-sZÁMÍTÁs És MATEMATIKAI statisztika 10 X. SZIMULÁCIÓ 1. VÉLETLEN számok A véletlen számok fontos szerepet játszanak a véletlen helyzetek generálásában (pénzérme, dobókocka,

Részletesebben

Utolsó módosítás:

Utolsó módosítás: Utolsó módosítás: 2011. 09. 08. 1 A tantárggyal kapcsolatos adminisztratív kérdésekkel Micskei Zoltánt keressétek. 2 3 4 5 6 7 8 9 10 11 12 13 14 Erősen buzzword-fertőzött terület, manapság mindent szeretnek

Részletesebben

Tájékoztató. Használható segédeszköz: számológép

Tájékoztató. Használható segédeszköz: számológép A 12/2013. (III. 29.) NFM rendelet szakmai és vizsgakövetelménye alapján. Szakképesítés azonosítószáma és megnevezése 54 523 05 Távközlési technikus Tájékoztató A vizsgázó az első lapra írja fel a nevét!

Részletesebben

Unit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22

Unit Teszt. Tóth Zsolt. Miskolci Egyetem. Tóth Zsolt (Miskolci Egyetem) Unit Teszt / 22 Unit Teszt Tóth Zsolt Miskolci Egyetem 2013 Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 1 / 22 Tartalomjegyzék 1 Bevezetés 2 Unit Teszt 3 Példa Tóth Zsolt (Miskolci Egyetem) Unit Teszt 2013 2 / 22 Szoftvertesztelés

Részletesebben

SZÁMÍTÓGÉPEK BELSŐ FELÉPÍTÉSE - 1

SZÁMÍTÓGÉPEK BELSŐ FELÉPÍTÉSE - 1 INFORMATIKAI RENDSZEREK ALAPJAI (INFORMATIKA I.) 1 NEUMANN ARCHITEKTÚRÁJÚ GÉPEK MŰKÖDÉSE SZÁMÍTÓGÉPEK BELSŐ FELÉPÍTÉSE - 1 Ebben a feladatban a következőket fogjuk áttekinteni: Neumann rendszerű számítógép

Részletesebben

Roger UT-2. Kommunikációs interfész V3.0

Roger UT-2. Kommunikációs interfész V3.0 ROGER UT-2 1 Roger UT-2 Kommunikációs interfész V3.0 TELEPÍTŐI KÉZIKÖNYV ROGER UT-2 2 ÁLTALÁNOS LEÍRÁS Az UT-2 elektromos átalakítóként funkcionál az RS232 és az RS485 kommunikációs interfész-ek között.

Részletesebben

Kontrol kártyák használata a laboratóriumi gyakorlatban

Kontrol kártyák használata a laboratóriumi gyakorlatban Kontrol kártyák használata a laboratóriumi gyakorlatban Rikker Tamás tudományos igazgató WESSLING Közhasznú Nonprofit Kft. 2013. január 17. Kis történelem 1920-as években, a Bell Laboratórium telefonjainak

Részletesebben

Véges állapotú gépek (FSM) tervezése

Véges állapotú gépek (FSM) tervezése Véges állapotú gépek (FSM) tervezése F1. A 2. gyakorlaton foglalkoztunk a 3-mal vagy 5-tel osztható 4 bites számok felismerésével. Abban a feladatban a bemenet bitpárhuzamosan, azaz egy időben minden adatbit

Részletesebben

BAGME11NNF Munkavédelmi mérnökasszisztens Galla Jánosné, 2011.

BAGME11NNF Munkavédelmi mérnökasszisztens Galla Jánosné, 2011. BAGME11NNF Munkavédelmi mérnökasszisztens Galla Jánosné, 2011. 1 Mérési hibák súlya és szerepe a mérési eredményben A mérési hibák csoportosítása A hiba rendűsége Mérési bizonytalanság Standard és kiterjesztett

Részletesebben

INFO DIAG DIAGNOSZTIKAI MŰSZER

INFO DIAG DIAGNOSZTIKAI MŰSZER CITROËN DTAV INFO DIAG DIAGNOSZTIKAI MŰSZER LEÁNYVÁLLALATOK / IMPORTŐR ÚJ CITROËN gépjármű FORGALMAZÓK - Új gépjármű felkészítő - Kampánykoordinátor HIVATALOS CITROËN MÁRKASZERVIZEK - Vevőszolgálati vezető,

Részletesebben

A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN

A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN A BIZTONSÁGINTEGRITÁS ÉS A BIZTONSÁGORIENTÁLT ALKALMAZÁSI FELTÉTELEK TELJESÍTÉSE A VASÚTI BIZTOSÍTÓBERENDEZÉSEK TERVEZÉSE ÉS LÉTREHOZÁSA SORÁN Szabó Géza Bevezetés Az előadás célja, vasúti alrendszerekre

Részletesebben

Üzletmenet folytonosság menedzsment [BCM]

Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment [BCM] Üzletmenet folytonosság menedzsment Megfelelőség, kényszer? Felügyeleti előírások Belső előírások Külföldi tulajdonos előírásai Szabványok, sztenderdek, stb Tudatos

Részletesebben

Interfészek. PPT 2007/2008 tavasz.

Interfészek. PPT 2007/2008 tavasz. Interfészek szenasi.sandor@nik.bmf.hu PPT 2007/2008 tavasz http://nik.bmf.hu/ppt 1 Témakörök Polimorfizmus áttekintése Interfészek Interfészek kiterjesztése 2 Már megismert fogalmak áttekintése Objektumorientált

Részletesebben

EM4028 PCI 10/100/1000 MBPS HÁLÓZATI ADAPTER

EM4028 PCI 10/100/1000 MBPS HÁLÓZATI ADAPTER EM4028 PCI 10/100/1000 MBPS HÁLÓZATI ADAPTER 2 MAGYAR EM4028 - PCI 10/100/1000 MBPS HÁLÓZATI ADAPTER Tartalomjegyzék 1.0 Bevezetés... 2 1.1 A csomag tartalma... 2 1.2 Mielőtt elkezdené... 2 2.0 A hardver

Részletesebben

ÁLTALÁNOS JELLEGŰ ELŐÍRÁSOK. A hitelesítési folyamat résztvevőit, az alapelemeket és a főbb kapcsolódási pontokat az 1.

ÁLTALÁNOS JELLEGŰ ELŐÍRÁSOK. A hitelesítési folyamat résztvevőit, az alapelemeket és a főbb kapcsolódási pontokat az 1. A Miniszterelnöki Hivatalt vezető miniszter 2/2002. (IV. 26.) MeHVM irányelve a minősített elektronikus aláírással kapcsolatos szolgáltatásokra és ezek szolgáltatóira vonatkozó biztonsági követelményekről

Részletesebben

Operációs rendszerek. Bemutatkozás

Operációs rendszerek. Bemutatkozás Bevezetés az operációs rendszerek világába dr. Benyó Balázs benyo@sze.hu Bemutatkozás www.sze.hu/~benyo 1 Számítógép HW-SW felépítése felhasználó felhasználó felhasználó Operációs rendszer Operációs rendszer

Részletesebben

FL-11R kézikönyv Viczai design 2010. FL-11R kézikönyv. (Útmutató az FL-11R jelű LED-es villogó modell-leszállófény áramkör használatához)

FL-11R kézikönyv Viczai design 2010. FL-11R kézikönyv. (Útmutató az FL-11R jelű LED-es villogó modell-leszállófény áramkör használatához) FL-11R kézikönyv (Útmutató az FL-11R jelű LED-es villogó modell-leszállófény áramkör használatához) 1. Figyelmeztetések Az eszköz a Philips LXK2 PD12 Q00, LXK2 PD12 R00, LXK2 PD12 S00 típusjelzésű LED-jeihez

Részletesebben

Számítógép architektúra

Számítógép architektúra Budapesti Műszaki Főiskola Regionális Oktatási és Innovációs Központ Székesfehérvár Számítógép architektúra Dr. Seebauer Márta főiskolai tanár seebauer.marta@roik.bmf.hu Irodalmi források Cserny L.: Számítógépek

Részletesebben

X. ANALÓG JELEK ILLESZTÉSE DIGITÁLIS ESZKÖZÖKHÖZ

X. ANALÓG JELEK ILLESZTÉSE DIGITÁLIS ESZKÖZÖKHÖZ X. ANALÓG JELEK ILLESZTÉSE DIGITÁLIS ESZKÖZÖKHÖZ Ma az analóg jelek feldolgozása (is) mindinkább digitális eszközökkel és módszerekkel történik. A feldolgozás előtt az analóg jeleket digitalizálni kell.

Részletesebben

Beszállítás AR Gyártási folyamat KR

Beszállítás AR Gyártási folyamat KR 3. ELŐADÁS TERMELÉSI FOLYAMATOK STRUKTURÁLÓDÁSA 1. Megszakítás nélküli folyamatos gyártás A folyamatos gyártás lényege, hogy a termelési folyamat az első művelettől az utolsóig közvetlenül összekapcsolt,

Részletesebben

Ismerkedjünk tovább a számítógéppel. Alaplap és a processzeor

Ismerkedjünk tovább a számítógéppel. Alaplap és a processzeor Ismerkedjünk tovább a számítógéppel Alaplap és a processzeor Neumann-elvű számítógépek főbb egységei A részek feladatai: Központi egység: Feladata a számítógép vezérlése, és a számítások elvégzése. Operatív

Részletesebben

ADATBÁZIS-KEZELÉS. Adatbázis-kezelő rendszerek

ADATBÁZIS-KEZELÉS. Adatbázis-kezelő rendszerek ADATBÁZIS-KEZELÉS Adatbázis-kezelő rendszerek Adat (Data) Észlelhető, felfogható ismeret Jelsorozat Tény, közlés Valakinek vagy valaminek a jellemzője Adatbázis (Data Base, DB) Hosszú ideig évekig meglévő

Részletesebben

12. tétel. Lemezkezelés

12. tétel. Lemezkezelés 12. tétel 12_12a_1.5 Lemezkezelés (Particionálás, formázás, RAID rendszerek) A partíció a merevlemez egy önálló logikai egysége, amely fájlrendszer tárolására alkalmas. Alapvetően két esetben hozunk létre

Részletesebben

Ellátási lánc optimalizálás P-gráf módszertan alkalmazásával mennyiségi és min ségi paraméterek gyelembevételével

Ellátási lánc optimalizálás P-gráf módszertan alkalmazásával mennyiségi és min ségi paraméterek gyelembevételével Ellátási lánc optimalizálás P-gráf módszertan alkalmazásával mennyiségi és min ségi paraméterek gyelembevételével Pekárdy Milán, Baumgartner János, Süle Zoltán Pannon Egyetem, Veszprém XXXII. Magyar Operációkutatási

Részletesebben

Gázelosztó rendszerek üzemeltetése II. rész

Gázelosztó rendszerek üzemeltetése II. rész Gázelosztó rendszerek üzemeltetése II. rész A gázelosztó vezetéket műszaki-biztonsági szempontból megfelelő állapotban kell tartani!!! RENDSZERESEN ELLENŐRIZNI KELL: tömörségét, elhelyezésére utaló jelzések

Részletesebben

C programozás. { Márton Gyöngyvér, 2009 } { Sapientia, Erdélyi Magyar Tudományegyetem } http://www.ms.sapientia.ro/~mgyongyi

C programozás. { Márton Gyöngyvér, 2009 } { Sapientia, Erdélyi Magyar Tudományegyetem } http://www.ms.sapientia.ro/~mgyongyi C programozás Márton Gyöngyvér, 2009 Sapientia, Erdélyi Magyar Tudományegyetem http://www.ms.sapientia.ro/~mgyongyi 1 Könyvészet Kátai Z.: Programozás C nyelven Brian W. Kernighan, D.M. Ritchie: A C programozási

Részletesebben

I. Definíciók. 1. Üzletmenet folytonossági terv - katasztrófa terv. Üzletmenet folytonossági tervezés

I. Definíciók. 1. Üzletmenet folytonossági terv - katasztrófa terv. Üzletmenet folytonossági tervezés Üzletmenet folytonossági tervezés I. Definíciók II. Első lépés: a kockázatok felmérése III. Az informatikai üzletmenet folytonossági terv komponenseiről IV. Az egyes rendszerek informatikai üzletmenet

Részletesebben

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE

A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE A TESZTELÉS ALAPJAI A TESZTELÉS ALAPVETŐ FOLYAMATA A TESZTELÉS PSZICHOLÓGIÁJA A TESZTELÉS ETIKAI KÓDEXE MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN

Részletesebben

J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ. 62 Információtechnológiai szolgáltatás Információtechnológiai szolgáltatás

J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ. 62 Információtechnológiai szolgáltatás Információtechnológiai szolgáltatás J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ 62 Információtechnológiai szolgáltatás 62.0 Információtechnológiai szolgáltatás 62.01 Számítógépes programozás - a kész programcsomag-kiadás, lásd 58.29

Részletesebben

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Hibatűrés. Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Hibatűrés Majzik István Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék http://www.mit.bme.hu/ 1 Hibatűrés különféle hibák esetén Hardver tervezési hibák

Részletesebben

Az informatikai katasztrófa elhárítás menete

Az informatikai katasztrófa elhárítás menete Az informatikai katasztrófa elhárítás menete A katasztrófa elhárításáért felelős személyek meghatározása Cég vezetője (ügyvezető): A Cég vezetője a katasztrófa elhárítás első számú vezetője. Feladata:

Részletesebben

Módosult a Csatlakoztatási konstrukció az önkormányzati ASP rendszer országos kiterjesztéséhez című felhívás

Módosult a Csatlakoztatási konstrukció az önkormányzati ASP rendszer országos kiterjesztéséhez című felhívás Módosult a Csatlakoztatási konstrukció az önkormányzati ASP rendszer országos kiterjesztéséhez című felhívás A Széchenyi 2020 keretében megjelent Csatlakoztatási konstrukció az önkormányzati ASP rendszer

Részletesebben

A fejlesztési szabványok szerepe a szoftverellenőrzésben

A fejlesztési szabványok szerepe a szoftverellenőrzésben A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés

Részletesebben

Beszerzési és elosztási logisztika. Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV

Beszerzési és elosztási logisztika. Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV Beszerzési és elosztási logisztika Előadó: Telek Péter egy. adj. 2008/09. tanév I. félév GT5SZV 5. Előadás Elosztási folyamat A klasszikus elosztási logisztikai rendszer Az elosztási logisztikai rendszer:

Részletesebben

Az operációs rendszer szerkezete, szolgáltatásai

Az operációs rendszer szerkezete, szolgáltatásai Az operációs rendszer szerkezete, szolgáltatásai Felhasználói programok Rendszerhívások Válaszok Kernel Eszközkezelők Megszakításvezérlés Perifériák Az operációs rendszer szerkezete, szolgáltatásai Felhasználói

Részletesebben

8.3. AZ ASIC TESZTELÉSE

8.3. AZ ASIC TESZTELÉSE 8.3. AZ ASIC ELÉSE Az eddigiekben a terv helyességének vizsgálatára szimulációkat javasoltunk. A VLSI eszközök (közöttük az ASIC) tesztelése egy sokrétűbb feladat. Az ASIC modellezése és a terv vizsgálata

Részletesebben

Programrendszerek tanúsítása szoftverminőség mérése

Programrendszerek tanúsítása szoftverminőség mérése SZEGEDI TUDOMÁNYEGYETEM Programrendszerek tanúsítása szoftverminőség mérése Dr. Gyimóthy Tibor Dr. Ferenc Rudolf Szoftverminőség biztosítás Fő cél: az üzemelő IT rendszerekben csökkenteni a hibák számát

Részletesebben

Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda.

Feladat. Bemenő adatok. Bemenő adatfájlok elvárt formája. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. Például (bemenet/pelda. Berezvai Dániel 1. beadandó/4. feladat 2012. április 13. BEDTACI.ELTE Programozás 3ice@3ice.hu 11. csoport Feladat Madarak életének kutatásával foglalkozó szakemberek különböző településen különböző madárfaj

Részletesebben

Informatika Rendszerek Alapjai

Informatika Rendszerek Alapjai Informatika Rendszerek Alapjai Dr. Kutor László Alapfogalmak Információ-feldolgozó paradigmák Analóg és digitális rendszerek jellemzői Jelek típusai Átalakítás rendszerek között http://uni-obuda.hu/users/kutor/

Részletesebben

CES Hőgenerátor Kezelési útmutató

CES Hőgenerátor Kezelési útmutató CES Hőgenerátor Kezelési útmutató CES KFT. Üzembe helyezés előtt figyelmesen olvassa el! Tartalom Bevezető... 3 C.E.S. kavitációs hőgenerátorok leírása és alkalmazása... 3 2. A C.E.S. kavitációs hőgenerátorok

Részletesebben