3. Biztonságkritikus rendszerek
|
|
- Erik Ottó Budai
- 7 évvel ezelőtt
- Látták:
Á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
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észletesebbenMiskolci 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észletesebbenVerifiká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észletesebbenBME 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észletesebbenSzoftverminő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észletesebbenHibatű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észletesebbenAutó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észletesebbenA 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észletesebbenAutó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észletesebbenDr. 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észletesebbenBiztonsá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észletesebbenA 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észletesebbenJogi 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észletesebbenOpenCL 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észletesebbenRubin 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észletesebbenA 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észletesebbenCloud 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észletesebbenbiztonsá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észletesebbenKö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észletesebbenIT ü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észletesebbenBiztonsá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észletesebbenBevezeté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észletesebbenMiskolci 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észletesebbenA 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észletesebbenBiztonsá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észletesebbenSzoftverminő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észletesebbenModulzá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észletesebbenInformá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észletesebbenModulzá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észletesebbenFMEA 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észletesebbenTM 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észletesebbenAdatmodellezé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észletesebbenII. 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észletesebbenOsztott 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észletesebbenA 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észletesebbenSzoftver 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észletesebbenHibajaví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észletesebbenA 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észletesebbenMŰ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észletesebbenA 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észletesebbenA 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észletesebbenMŰ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észletesebbenKé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észletesebbenMuha 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észletesebbenMegbí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észletesebbenQAA73 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észletesebbenNemzeti 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észletesebbenSTATISZTIKA. 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észletesebben5. 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észletesebbenProgramtervezé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észletesebbenAlkalmazá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észletesebbenInformatika é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észletesebbenEnabling 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észletesebbenJava 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észletesebbenGrid 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észletesebbenMUST 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észletesebben24 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észletesebbenESZKÖ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észletesebbenAlgoritmusok 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észletesebbenMá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észletesebbenFEGYVERNEKI 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észletesebbenUtolsó 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észletesebbenTá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észletesebbenUnit 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észletesebbenSZÁ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észletesebbenRoger 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észletesebbenKontrol 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észletesebbenVé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észletesebbenBAGME11NNF 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észletesebbenINFO 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észletesebbenA 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 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észletesebbenInterfé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észletesebbenEM4028 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.
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észletesebbenOperá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észletesebbenFL-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észletesebbenSzá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észletesebbenX. 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észletesebbenBeszá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észletesebbenIsmerkedjü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észletesebbenADATBÁ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észletesebben12. 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észletesebbenEllá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észletesebbenGá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észletesebbenC 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észletesebbenI. 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észletesebbenA 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észletesebbenJ 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észletesebbenHibatű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észletesebbenAz 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észletesebbenMó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észletesebbenA 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észletesebbenBeszerzé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észletesebbenAz 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észletesebben8.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észletesebbenProgramrendszerek 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észletesebbenFeladat. 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észletesebbenInformatika 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észletesebbenCES 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